Handbuch

Präventive Schutzmaßnahmen in einer Organisation durchsetzen, z. B. das Einschränken von Ressourcenstandorten oder das Deaktivieren der Erstellung von Dienstkontoschlüsseln.

→Organisationsrichtlinien-Einschränkungen (z. B. `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) auf Organisations- oder Ordnerebene anwenden.

Warum: Organisationsrichtlinien werden auf API-Ebene vererbt und durchgesetzt, wodurch nicht konforme Aktionen verhindert werden, bevor sie auftreten. Dies ist effektiver als reaktive Erkennung und Behebung.

Referenz↗

Eine Organisation mit mehreren Abteilungen und Umgebungen strukturieren, um Richtlinien und Zugriffssteuerung effektiv zu verwalten.

→Eine Ordnerhierarchie entwerfen, typischerweise: Organisation > Geschäftseinheit (Ordner) > Umgebung (z. B. Prod, Staging) (Unterordner) > Projekte.

Warum: Diese Struktur ermöglicht eine granulare Richtlinienvererbung. Allgemeine Richtlinien werden auf BU-Ebene festgelegt, während umgebungsspezifische Richtlinien (z. B. restriktiver für `prod`) auf Umgebungsebene festgelegt werden.

Logs aus allen Projekten für Compliance, Sicherheitsanalyse und operative Fehlerbehebung mit Kostenoptimierung aggregieren.

→Eine aggregierte Log-Senke auf Organisationsebene erstellen. Logs je nach Bedarf an mehrere Ziele weiterleiten: BigQuery für die Analyse, Cloud Storage (Coldline/Archive) für langfristige/kostengünstige Archivierung und Pub/Sub für Echtzeit-Streaming an ein SIEM.

Warum: Dieser gestaffelte Ansatz optimiert sowohl Kosten als auch Fähigkeiten. BigQuery bietet leistungsstarke Abfragen, während Cloud Storage eine kostengünstige Archivierung ermöglicht. Die Verwendung eines einzigen Ziels ist entweder zu teuer oder für alle Anwendungsfälle nicht leistungsfähig genug.

Referenz↗

Datenexfiltration aus verwalteten Diensten wie BigQuery und Cloud Storage verhindern, indem der Zugriff nur von autorisierten Netzwerken oder Identitäten zugelassen wird.

→Einen VPC Service Controls-Perimeter um Projekte mit sensiblen Daten erstellen. Zugriffsstufen definieren, um den Zugriff von bestimmten IP-Bereichen (Unternehmensnetzwerk) oder Geräten zu erlauben.

Warum: VPC Service Controls erstellt einen virtuellen Perimeter um API-basierte Dienste, wodurch Risiken durch gestohlene Anmeldeinformationen oder falsch konfigurierte IAM-Richtlinien gemindert werden, indem der Zugriff von außerhalb des Perimeters blockiert wird.

Sicherheitsmaßnahmen festlegen, die von Projektbesitzern nicht außer Kraft gesetzt werden können, z. B. die Vergabe einer bestimmten Rolle verhindern.

→IAM-Ablehnungsrichtlinien (Deny Policies) auf Organisations- oder Ordnerebene implementieren. Diese Richtlinien verweigern explizit Berechtigungen und überschreiben immer alle `allow`-Richtlinien.

Warum: Ablehnungsrichtlinien bieten eine leistungsstarke Möglichkeit, organisationsweite Sicherheitskontrollen durchzusetzen, die auf niedrigeren Ebenen der Ressourcenhierarchie nicht umgangen werden können, und gewährleisten so eine konsistente Sicherheitslage.

Sicherstellen, dass alle neuen Projekte mit einer standardmäßigen Basiskonfiguration (Netzwerk, IAM, Logging usw.) bereitgestellt werden.

→Infrastructure as Code (z. B. Terraform mit Cloud Build) verwenden, um eine "Landing Zone" zu erstellen. Die Projekterstellung und -konfiguration über eine Pipeline automatisieren.

Warum: Automatisierung gewährleistet Konsistenz, reduziert manuelle Fehler und beschleunigt die Projektbereitstellung. Sie kodifiziert Best Practices und macht die Governance auditierbar und wiederholbar.

Externen Systemen (wie GitHub Actions oder lokalen CI/CD-Systemen) den Zugriff auf GCP-Ressourcen ermöglichen, ohne langlebige Dienstkontoschlüssel zu verwenden.

→Workload Identity Federation konfigurieren. Einen Provider erstellen, der dem externen IdP (z. B. GitHub OIDC) vertraut, und externe Identitäten einem GCP-Dienstkonto zuordnen. Attributbedingungen verwenden, um den Zugriff auf bestimmte Repositories/Branches zu beschränken.

Warum: Dies eliminiert die Notwendigkeit, Dienstkontoschlüssel zu verwalten und zu rotieren, was ein erhebliches Sicherheitsrisiko darstellt. Es bietet kurzlebige, identitätsbasierte Anmeldeinformationen.

Netzwerkverwaltung (VPCs, Subnetze, Firewalls) zentralisieren und gleichzeitig separaten Teams ermöglichen, ihre eigenen Projektressourcen zu verwalten.

→Shared VPC implementieren. Ein "Host-Projekt" für Netzwerkressourcen und "Service-Projekte" für Anwendungs-Workloads erstellen. `roles/compute.networkUser` an Service-Projektidentitäten vergeben.

Warum: Shared VPC entkoppelt die Netzwerkverwaltung von der Projektverwaltung, bietet zentrale Kontrolle und Sicherheit und gewährt Teams gleichzeitig Autonomie. Es skaliert besser und ist für diesen Anwendungsfall sicherer als VPC Peering.

GKE-Clusterkonfigurationen und -Anwendungen deklarativ aus einem Git-Repository verwalten.

→Ein Git-Repository als Single Source of Truth für Manifeste verwenden. Config Sync in den GKE-Clustern installieren, um den Cluster-Status kontinuierlich mit der Konfiguration im Repository abzugleichen.

Warum: GitOps bietet eine auditierbare, versionskontrollierte und automatisierte Möglichkeit zur Verwaltung von Kubernetes. Es trennt CI (Erstellen von Artefakten) von CD (Synchronisieren des Zustands).

Verhindern, dass Container-Images mit kritischen Schwachstellen bereitgestellt werden.

→Automatische Schwachstellenprüfung in Artifact Registry aktivieren. In der Cloud Build-Pipeline einen Schritt hinzufügen, der die Container Analysis API verwendet, um Schwachstellen zu überprüfen und den Build fehlschlagen lässt, wenn kritische Probleme gefunden werden.

Warum: Dies erstellt ein automatisiertes Qualitäts-Gate in der CI-Pipeline und verhindert, dass anfällige Artefakte jemals einen bereitstellbaren Zustand erreichen. Es verlagert die Sicherheit nach links ("shifts security left").

Zur Laufzeit durchsetzen, dass nur vertrauenswürdige, signierte Container-Images in GKE oder Cloud Run bereitgestellt werden können.

→Binary Authorization implementieren. Attestoren erstellen (z. B. für bestandene Schwachstellenscans, QA-Abnahme). Die CI-Pipeline konfigurieren, um Attestierungen zu erstellen. Eine Richtlinie für GKE/Cloud Run durchsetzen, die spezifische Attestierungen für die Bereitstellung erfordert.

Warum: Binary Authorization bietet eine starke, richtlinienbasierte Durchsetzung zum Zeitpunkt der Bereitstellung. Es schützt vor der Bereitstellung kompromittierter oder ungeprüfter Images, selbst wenn sie es ins Register schaffen.

Referenz↗

Auf sensible Informationen wie API-Schlüssel oder Passwörter während eines Cloud Build-Laufs zugreifen, ohne sie in Logs oder Quellcode preiszugeben.

→Geheimnisse im Secret Manager speichern. In der `cloudbuild.yaml` das Feld `availableSecrets` verwenden, um das Geheimnis als Umgebungsvariable oder Datei zu mounten.

Warum: Dies ist die native, sichere Integration. Cloud Build übernimmt die Authentifizierung und redigiert automatisch die Geheimniswerte aus den Logs, wodurch eine versehentliche Offenlegung verhindert wird.

Eine überprüfbare Herkunftskette für Softwareartefakte etablieren, um sicherzustellen, dass sie von einem vertrauenswürdigen System aus vertrauenswürdigem Quellcode erstellt wurden.

→Cloud Build verwenden, um SLSA-konforme Herkunftsattestierungen zu generieren. Diese Attestierungen zusammen mit den Images in Artifact Registry speichern. Binary Authorization verwenden, um die Herkunft vor der Bereitstellung zu überprüfen.

Warum: SLSA bietet einen Rahmen zur Härtung der Softwarelieferkette. Diese Kombination von Tools bietet eine durchgängige, überprüfbare Vertrauenskette von der Quelle bis zur Produktion.

CI/CD-Jobs ausführen, die auf Ressourcen in einer privaten VPC zugreifen müssen, wie z. B. ein privates Artifact Registry oder eine Cloud SQL-Datenbank.

→Einen privaten Cloud Build-Pool erstellen und VPC-Peering zwischen dem Netzwerk des Pools und Ihrer Ziel-VPC konfigurieren. Builds so konfigurieren, dass sie in diesem Pool ausgeführt werden.

Warum: Private Pools bieten Netzwerkisolation und ermöglichen Builds den sicheren Zugriff auf Ressourcen in einem privaten Netzwerk, ohne sie dem Internet auszusetzen.

Alte oder ungenutzte Container-Images automatisch löschen, um Speicherkosten zu verwalten und gleichzeitig wichtige Images zu behalten.

→Aufräumrichtlinien für Artifact Registry konfigurieren. Eine `keep`-Richtlinie für Tags wie `production` und `latest` verwenden. `delete`-Richtlinien basierend auf Alter, Tag-Mustern und Versionsanzahl für andere Images verwenden.

Warum: Aufräumrichtlinien bieten eine deklarative, automatisierte Möglichkeit zur Verwaltung des Image-Lebenszyklus, die Kostenersparnisse mit der Notwendigkeit abwägt, Produktions- und aktuelle Entwicklungsartefakte zu behalten.

Eine mehrstufige Bereitstellung von der Entwicklung über Staging bis zur Produktion mit Genehmigungen und unterschiedlichen Strategien pro Umgebung automatisieren.

→Eine einzige Cloud Deploy-Lieferpipeline mit einer Abfolge von Zielen (Dev, Staging, Prod) definieren. `requireApproval: true` für das Produktionsziel konfigurieren und verschiedene Bereitstellungsstrategien (z. B. Canary) für jedes Ziel angeben.

Warum: Cloud Deploy bietet einen verwalteten, auditierbaren Continuous Delivery-Dienst. Es vereinfacht progressive Bereitstellungsmuster wie Canary- und Blue/Green-Deployments mit integrierten Genehmigungen und Rollbacks.

Metriken definieren, um die Zuverlässigkeit eines Dienstes aus der Benutzerperspektive zu messen.

→Service Level Indicators (SLIs) basierend auf benutzerrelevanten Aspekten definieren: Verfügbarkeit (Prozentsatz erfolgreicher Anfragen), Latenz (Prozentsatz der Anfragen, die schneller als ein Schwellenwert sind) und Korrektheit/Aktualität (Prozentsatz der korrekt verarbeiteten oder aktuellen Daten).

Warum: SLIs müssen die Benutzerzufriedenheit messen, nicht die interne Servergesundheit. Metriken wie CPU-Auslastung sind Ursachen, während hohe Latenz ein Symptom ist. SRE konzentriert sich auf die Überwachung und Verwaltung von Symptomen.

Früh genug über SLO-Verletzungen benachrichtigt werden, um reagieren zu können, ohne von Alerts für kleinere, vorübergehende Probleme überflutet zu werden.

→Alarme basierend auf der SLO-Burn-Rate konfigurieren (die Geschwindigkeit, mit der das Fehlerbudget verbraucht wird). Multi-Window-Alarme verwenden: eine hohe Burn-Rate über ein kurzes Zeitfenster für kritische Seiten und eine niedrigere Burn-Rate über ein langes Zeitfenster für nicht dringende Tickets.

Warum: Burn-Rate-Alerting ist prädiktiv. Es alarmiert über die *Rate* des Scheiterns, die ein echtes Problem anzeigt, anstatt einer einzelnen fehlgeschlagenen Anfrage, wodurch die Alarmmüdigkeit reduziert und der Fokus auf das Wesentliche gelegt wird.

Referenz↗

Latenzprobleme in einer Microservices-Architektur durch Verständnis des vollständigen Lebenszyklus einer Anfrage diagnostizieren.

→Dienste mit OpenTelemetry SDKs instrumentieren und Traces an Cloud Trace exportieren. Sicherstellen, dass der Trace-Kontext über Dienstaufrufe hinweg (einschließlich über Nachrichtenwarteschlangen wie Pub/Sub) weitergegeben wird.

Warum: OpenTelemetry bietet einen herstellerneutralen Standard für die Instrumentierung. Cloud Trace visualisiert den End-to-End-Anfragefluss und erleichtert es, Engpässe in Diensten oder Operationen zu identifizieren.

Sicherstellen, dass Anwendungslogs in GKE korrekt geparst, durchsuchbar sind und die richtige Schweregradstufe in Cloud Logging aufweisen.

→Anwendungen so konfigurieren, dass sie Logs in JSON-Format an `stdout`/`stderr` schreiben. Ein `severity`-Feld einschließen, das den erwarteten Werten von Google Cloud (z. B. "INFO", "ERROR") entspricht.

Warum: Der Standard-Logging-Agent von GKE erfasst und parst JSON-Logs von stdout automatisch, wodurch sie in Cloud Logging strukturiert und abfragbar werden, ohne dass ein Sidecar oder ein benutzerdefinierter Agent erforderlich ist.

SLO-Compliance und Fehlerbudgetverbrauch für einen Dienst verfolgen, visualisieren und benachrichtigen.

→Die Dienstüberwachungsfunktion von Cloud Monitoring verwenden. Einen Dienst definieren, SLIs erstellen (z. B. Verfügbarkeit von einem Load Balancer), SLO-Ziele festlegen und Burn-Rate-Alerting-Richtlinien konfigurieren.

Warum: Diese native Funktion automatisiert die komplexen Berechnungen von SLO-Compliance und Fehlerbudgets, bietet vorgefertigte Dashboards und integriert sich in das Alarmsystem.

Die Ursache eines Problems schnell finden, indem Metriken, Traces und Logs verknüpft werden.

→Sicherstellen, dass Trace-IDs in strukturierten Logs enthalten sind. Cloud Monitoring-Funktionen wie Trace-Exemplare in Metrikdiagrammen verwenden, um während einer Metrikanomalie zu einem spezifischen Trace zu springen und von diesem Trace zu den korrelierten Logs zu wechseln.

Warum: Die Fähigkeit, nahtlos zwischen den drei Säulen der Observability (Metriken, Logs, Traces) zu wechseln, ist entscheidend für die Reduzierung der Mean Time to Resolution (MTTR).

Benutzerdefinierte Metriken und Alarme für anwendungsspezifische Ereignisse erstellen, die nur in Logdaten verfügbar sind, wie Benutzerregistrierungen oder Zahlungsausfälle.

→In Cloud Logging eine logbasierte Metrik erstellen. Einen Filter definieren, um die relevanten Logeinträge abzugleichen, und den Metriktyp (Zähler oder Verteilung) konfigurieren. Diese benutzerdefinierte Metrik in Dashboards und Alarmrichtlinien verwenden.

Warum: Logbasierte Metriken ermöglichen es, unstrukturierte oder semi-strukturierte Logdaten in strukturierte Zeitreihendaten umzuwandeln, wodurch die Überwachung und Alarmierung von KPIs auf Geschäftsebene ohne Änderung des Anwendungscodes vereinfacht wird.

Datenbankleistungsprobleme, wie langsame Abfragen, diagnostizieren, ohne die Datenbank zusätzlich zu belasten.

→Cloud SQL Insights und Query Insights für die Cloud SQL-Instanz aktivieren. Das Dashboard verwenden, um Abfragen mit hoher Last zu identifizieren, Ausführungspläne zu analysieren und Leistungstrends zu sehen.

Warum: Query Insights bietet eine leichtgewichtige, agentenlose Überwachung der Abfrageleistung. Es hilft Datenbankadministratoren und Entwicklern, ineffiziente Abfragen ohne den Overhead traditioneller Profiling-Tools zu identifizieren.

Kritische User Journeys oder API-Verfügbarkeit proaktiv aus externer Perspektive überwachen.

→Cloud Monitoring Uptime Checks für einfache HTTP/TCP-Prüfungen verwenden. Für mehrstufige Benutzerabläufe (z. B. Anmeldung, In den Warenkorb legen, Kasse) Synthetic Monitors verwenden, die benutzerdefinierte Skripte (z. B. Puppeteer) in einer verwalteten Umgebung ausführen.

Warum: Synthetisches Monitoring simuliert echte Benutzerinteraktionen und ermöglicht es Ihnen, Probleme zu erkennen, bevor Benutzer es tun. Es testet den gesamten Stack von außen nach innen.

Die Notwendigkeit der Dienstzuverlässigkeit mit der Notwendigkeit, neue Funktionen zu veröffentlichen, in Einklang bringen.

→Ein Service Level Objective (SLO) definieren (z. B. 99,9 % Verfügbarkeit). Die verbleibenden 0,1 % sind das Fehlerbudget. Ist das Budget weitgehend intakt, Funktionen ausliefern. Ist das Budget aufgebraucht, Funktionsveröffentlichungen stoppen und sich auf Zuverlässigkeitsverbesserungen konzentrieren.

Warum: Das Fehlerbudget bietet einen datengesteuerten Rahmen für Risikobewertungen und stimmt Engineering-, Produkt-- und Business-Teams auf ein gemeinsames Ziel ab.

Aus Vorfällen lernen, um deren Wiederholung zu verhindern, und gleichzeitig eine Kultur der psychologischen Sicherheit fördern.

→Nach Vorfällen schuldfreie Postmortems durchführen. Die Untersuchung auf systemische Faktoren, Prozesslücken und Tooling-Fehler konzentrieren, nicht auf die Zuweisung von Schuld an Einzelpersonen. Das Ergebnis sollte eine Liste umsetzbarer Verbesserungsmaßnahmen sein.

Warum: Eine schuldfreie Kultur fördert eine ehrliche und offene Kommunikation, was zu einem genaueren Verständnis der Ursachen eines Vorfalls und effektiveren Präventionsmaßnahmen führt.

Die Reaktion auf einen schwerwiegenden Vorfall effektiv koordinieren, um Verwirrung und doppelte Anstrengungen zu vermeiden.

→Ein Incident Command System (ICS) mit klar definierten Rollen implementieren: Incident Commander (Gesamtkoordination), Operations Lead (technische Untersuchung/Behebung) und Communications Lead (Stakeholder-Updates).

Warum: ICS bietet eine standardisierte, skalierbare Struktur für die Incident Response, die klare Autoritäts- und Kommunikationslinien gewährleistet, was für die schnelle Lösung komplexer Probleme entscheidend ist.

Die Leistung einer Softwarelieferorganisation messen.

→Die vier wichtigen DORA-Metriken verfolgen: Bereitstellungshäufigkeit (wie oft), Vorlaufzeit für Änderungen (wie schnell vom Commit zur Bereitstellung), Änderungsfehlerrate (welcher Prozentsatz der Bereitstellungen führt zu Fehlern) und Zeit zur Wiederherstellung des Dienstes (MTTR).

Warum: Diese vier Metriken bieten eine ausgewogene Sicht auf die Entwicklungsgeschwindigkeit und die Betriebs stabilität und haben sich als korrelierend mit hochleistungsfähigen Organisationen erwiesen.

Ein SRE-Team verbringt zu viel Zeit mit manuellen, repetitiven Betriebsaufgaben (Toil), wodurch keine Zeit für Engineering-Projekte bleibt.

→Die zeitaufwändigsten Toil-Aufgaben identifizieren und quantifizieren. Diese Aufgaben priorisieren und automatisieren (z. B. Autoscaling statt manueller Skalierung implementieren, automatische Behebung für häufige Alerts). Toil auf < 50 % der Ingenieurzeit begrenzen.

Warum: Toil beeinträchtigt Produktivität und Moral. Eine systematische Reduzierung durch Automatisierung gibt Ingenieuren die Freiheit, an langfristigen Zuverlässigkeitsverbesserungen zu arbeiten.

Cloud-Kosten in einer gemeinsamen Infrastruktur präzise verschiedenen Teams, Diensten oder Umgebungen zuordnen.

→Eine konsistente Labeling-/Tagging-Strategie implementieren. Diese Labels verwenden, um in Cloud Billing-Berichten zu filtern. Für GKE die GKE-Kostenverteilung aktivieren, um Kosten nach Namespace oder Workload aufzuschlüsseln.

Warum: Eine genaue Kostenverteilung schafft Transparenz, was die Verantwortlichkeit fördert. Teams, die ihre Ausgaben sehen können, sind in der Lage, diese zu optimieren.

Compute-Kosten für eine vielfältige Reihe von Workloads (stabil, unterbrechbar, Entwicklungs-/Testumgebungen) optimieren.

→Die Workload an das Preismodell anpassen. Committed Use Discounts (CUDs) für stabile, 24/7 Workloads verwenden. Spot VMs für fehlertolerante, unterbrechbare Jobs (z. B. Batch-Verarbeitung) nutzen. Entwicklungs-/Testumgebungen so planen, dass sie außerhalb der Geschäftszeiten heruntergefahren werden.

Warum: Ein „Einheits“-Ansatz für die Compute-Preisgestaltung ist ineffizient. Die Verwendung des richtigen Tools für die jeweilige Aufgabe kann zu erheblichen Einsparungen (>70%) führen, ohne die Leistung zu beeinträchtigen.

GKE-Kosten und -Leistung optimieren, indem sichergestellt wird, dass Pods angemessene Mengen an CPU und Speicher anfordern.

→Den Vertical Pod Autoscaler (VPA) im `recommendation`-Modus bereitstellen. Seine Vorschläge analysieren, um die Pod-Ressourcenanforderungen (`requests`) anzupassen. Nach Überprüfung in den `auto`-Modus für kontinuierliches Right-Sizing wechseln.

Warum: Die Überprovisionierung von Pods verschwendet Geld, während die Unterprovisionierung Leistungsprobleme (Drosselung, OOMKilled) verursacht. VPA verwendet tatsächliche Nutzungsdaten, um genaue Größenempfehlungen zu geben und so Effizienz und Stabilität zu verbessern.

Latenz, die durch Kaltstarts für einen Cloud Run-Dienst verursacht wird, reduzieren.

→Einen `min-instances`-Wert konfigurieren, um eine Reihe von Instanzen warm zu halten. Zusätzlich das Container-Image (kleineres Basis-Image, weniger Schichten) und den Anwendungsstartcode (Lazy Initialization) optimieren.

Warum: `min-instances` ist der direkteste Weg, Kaltstarts zu reduzieren, hat aber Kosten. Die Kombination mit Container- und Code-Optimierung bietet einen ausgewogenen Ansatz für Leistung und Kosten.

Kosten für eine groß angelegte BigQuery-Analyse-Workload mit variablen Abfragemustern optimieren.

→Von On-Demand-Preisen zu BigQuery Editions (Slots) wechseln. Eine Basis-Slot-Zusage für vorhersehbare Last kaufen und Autoscaling für Spitzenlasten aktivieren. Zusätzlich Abfragen durch die Verwendung partitionierter/geclusterter Tabellen und Vermeidung von `SELECT *` optimieren.

Warum: Für konsistente Workloads ist das slotbasierte Pricing kostengünstiger als On-Demand. Autoscaling bietet Flexibilität für Lastspitzen bei gleichzeitiger Kostenkontrolle. Abfrage- und Tabellenoptimierung reduziert die verarbeitete Datenmenge, was die Kosten direkt senkt.

Hohe Netzwerk-Egress-Kosten für eine global verteilte Anwendung reduzieren.

→Cloud CDN verwenden, um statische Inhalte am Edge, näher an den Benutzern, zwischenzuspeichern. Für dynamischen Traffic die geeignete Network Service Tier wählen (Premium für Leistung, Standard für Kosteneinsparungen). Daten regional verarbeiten, um regionsübergreifenden Traffic zu minimieren.

Warum: Egress ist ein wesentlicher Kostentreiber. CDN entlastet den Ursprungsserver, wodurch der Egress direkt reduziert wird. Der durchdachte Einsatz von Netzwerk-Tiers und regionaler Datenverarbeitung kann die Kosten erheblich senken.