Best Practices für Vorgänge

Last reviewed 2025-05-15 UTC

In diesem Abschnitt werden Vorgänge vorgestellt, die Sie bei der Bereitstellung und dem Betrieb zusätzlicher Arbeitslasten in Ihrer Google Cloud -Umgebung berücksichtigen müssen. Dieser Abschnitt soll nicht alle Vorgänge in Ihrer Cloudumgebung abdecken, sondern Entscheidungen im Zusammenhang mit den Architekturempfehlungen und Ressourcen vorstellen, die vom Blueprint bereitgestellt werden.

Fundamentale Ressourcen aktualisieren

Der Blueprint bietet zwar einen übersichtlichen Ausgangspunkt für Ihre Grundlagenumgebung, doch können Ihre Grundlagenanforderungen im Laufe der Zeit wachsen. Nach der ersten Bereitstellung können Sie Konfigurationseinstellungen anpassen oder neue freigegebene Dienste erstellen, die von allen Arbeitslasten genutzt werden können.

Wir empfehlen, alle Änderungen an Grundlagenressourcen über die Grundlagenpipeline vorzunehmen. Eine Einführung in den Ablauf des Schreibens und Zusammenführens von Code und Auslösen der Bereitstellungspipelines finden Sie unter Verzweigungsstrategie.

Attribute für neue Arbeitslastprojekte festlegen

Wenn Sie neue Projekte über das Projektfactory-Modul der Automatisierungspipeline erstellen, müssen Sie verschiedene Attribute konfigurieren. Ihr Prozess zum Entwerfen und Erstellen von Projekten für neue Arbeitslasten sollte Entscheidungen für Folgendes umfassen:

• Welche Google Cloud APIs müssen aktiviert werden?
• Welche freigegebene VPC verwendet werden soll oder ob ein neues VPC-Netzwerk erstellt werden soll
• Welche IAM-Rollen für das erste project-service-account erstellt werden sollen, die von der Pipeline erstellt wird
• Welche Projektlabels sollen angewendet werden?
• Der Ordner, in dem das Projekt bereitgestellt wird
• Welches Abrechnungskonto soll verwendet werden?
• Ob das Projekt einem VPC Service Controls-Perimeter hinzugefügt werden soll
• Ob ein Budget und ein Schwellenwert für Abrechnungsbenachrichtigungen für das Projekt konfiguriert werden sollen

Eine vollständige Referenz der konfigurierbaren Attribute für jedes Projekt finden Sie in den Eingabevariablen für die Projekterstellung in der Automatisierungspipeline.

Berechtigungen in großem Umfang verwalten

Wenn Sie Arbeitslastprojekte auf Ihrer Grundlage bereitstellen, müssen Sie überlegen, wie Sie den vorgesehenen Entwicklern und Nutzern dieser Projekte Zugriff gewähren. Wir empfehlen, Nutzer einer Gruppe hinzuzufügen, die von Ihrem vorhandenen Identitätsanbieter verwaltet wird, die Gruppen mit Cloud Identity zu synchronisieren und dann IAM-Rollen auf die Gruppen anzuwenden. Beachten Sie immer das Prinzip der geringsten Berechtigung.

Wir empfehlen außerdem, IAM Recommender zu verwenden, um Zulassungsrichtlinien zu identifizieren, die Rollen mit zu vielen Berechtigungen gewähren. Entwickeln Sie einen Prozess, mit dem Sie Empfehlungen regelmäßig überprüfen oder automatisch in Ihre Bereitstellungspipelines einfügen können.

Änderungen zwischen dem Netzwerkteam und dem Anwendungsteam koordinieren

Bei den von der Blueprint bereitgestellten Netzwerktopologien wird davon ausgegangen, dass Sie ein Team haben, das für die Verwaltung von Netzwerkressourcen zuständig ist, und separate Teams, die für die Bereitstellung von Infrastrukturressourcen für Arbeitslasten zuständig sind. Wenn die Arbeitslastteams Infrastruktur bereitstellen, müssen sie Firewallregeln erstellen, um die beabsichtigten Zugriffspfade zwischen den Komponenten ihrer Arbeitslast zu ermöglichen. Sie sind jedoch nicht berechtigt, die Netzwerk-Firewallrichtlinien selbst zu ändern.

Planen Sie, wie Teams zusammenarbeiten, um die Änderungen an den zentralen Netzwerkressourcen zu koordinieren, die für die Bereitstellung von Anwendungen erforderlich sind. Sie könnten beispielsweise einen Prozess entwerfen, bei dem ein Arbeitslastenteam Tags für seine Anwendungen anfordert. Das Netzwerkteam erstellt dann die Tags und fügt der Netzwerk-Firewallrichtlinie Regeln hinzu, die den Traffic zwischen Ressourcen mit den Tags ermöglichen, und delegiert die IAM-Rollen zur Verwendung der Tags an das Arbeitslastteam.

Umgebung mit dem Active Assist-Portfolio optimieren

Zusätzlich zum IAM-Recommender bietet Google Cloud das Active Assist-Portfolio von Diensten an,um Empfehlungen zur Optimierung Ihrer Umgebung zu geben. Beispielsweise bieten Firewall-Statistiken oder der Recommender für unbeaufsichtigte Projekte umsetzbare Empfehlungen, mit denen Sie Ihren Sicherheitsstatus verbessern können.

Entwickeln Sie einen Prozess, mit dem Sie Empfehlungen regelmäßig prüfen oder automatisch in Ihre Bereitstellungspipelines einfügen können. Entscheiden Sie, welche Empfehlungen von einem zentralen Team verwaltet werden sollen und welche Verantwortung bei Arbeitslastinhabern liegt. Wenden Sie dann IAM-Rollen an, um entsprechend auf die Empfehlungen zuzugreifen.

Ausnahmen von Organisationsrichtlinien gewähren

Der Blueprint erzwingt eine Reihe von Einschränkungen für Organisationsrichtlinien, die den meisten Kunden in den meisten Szenarien empfohlen werden. Sie können jedoch auch legitime Anwendungsfälle haben, die nur begrenzte Ausnahmen von den Organisationsrichtlinien erfordern, die Sie umfassend erzwingen.

Das Blueprint erzwingt beispielsweise die Einschränkung iam.disableServiceAccountKeyCreation. Diese Einschränkung ist eine wichtige Sicherheitskontrolle, da ein gehackter Dienstkontoschlüssel erhebliche negative Auswirkungen haben kann. In den meisten Szenarien sollten sicherere Alternativen zu Dienstkontoschlüsseln für die Authentifizierung verwendet werden. Es gibt jedoch Anwendungsfälle, die sich nur mit einem Dienstkontoschlüssel authentifizieren können, z. B. ein lokaler Server, der Zugriff aufGoogle Cloud -Dienste benötigt und die Workload Identity-Föderation nicht verwenden kann. In diesem Szenario können Sie eine Ausnahme von der Richtlinie zulassen, sofern zusätzliche ausgleichende Kontrollen wie Best Practices für die Verwaltung von Dienstkontoschlüsseln erzwungen werden.

Daher sollten Sie einen Prozess für Arbeitslasten entwickeln, um eine Ausnahme von Richtlinien anzufordern, und dafür sorgen, dass die Entscheidungsträger, die für die Erteilung von Ausnahmen verantwortlich sind, über das technische Wissen zur Validierung des Anwendungsfalls und zur Beratung darüber verfügen, ob zusätzliche Steuerelemente vorhanden sein müssen, um einen Ausgleich zu schaffen. Wenn Sie einer Arbeitslast eine Ausnahme gewähren, legen Sie die Einschränkung der Organisationsrichtlinie so eng wie möglich fest. Sie können auch Organisationsrichtlinien Einschränkungen bedingt hinzufügen, indem Sie ein Tag definieren, das eine Ausnahme oder Erzwingung für Richtlinien gewährt, und das Tag dann auf Projekte und Ordner anwenden.

Protect your resources with VPC Service Controls

Mit dem Blueprint können Sie Ihre Umgebung für VPC Service Controls vorbereiten, indem Sie erforderliche Konfigurationen wie die eingeschränkte VIP erzwingen. Das Blueprint stellt VPC Service Controls jedoch anfangs nur im Probelaufmodus bereit, da die Umstellung auf den erzwungenen Modus ein störender Prozess sein kann, der eine für Ihre Organisation spezifische Planung erfordert.

Ein Perimeter verweigert den Zugriff auf eingeschränkte Google Cloud Dienste für Traffic, der seinen Ursprung außerhalb des Perimeters hat. Dazu gehören die Console, Entwicklerarbeitsplätze und die Foundation-Pipeline, die zum Bereitstellen von Ressourcen verwendet wird. Wenn Sie VPC Service Controls verwenden, müssen Sie Ausnahmen für den Perimeter festlegen, die die gewünschten Zugriffspfade zulassen.

Ein VPC Service Controls-Perimeter ist für Exfiltrationskontrollen zwischen Ihrer Google Cloud -Organisation und externen Quellen vorgesehen. Der Perimeter soll keine Zulassungsrichtlinien für die detaillierte Zugriffssteuerung für einzelne Projekte oder Ressourcen ersetzen oder duplizieren. Wenn Sie einen Perimeter entwerfen und einrichten, empfehlen wir die Verwendung eines gemeinsamen einheitlichen Perimeters für einen geringeren Verwaltungsaufwand.

Wenn Sie mehrere Perimeter entwerfen müssen, um den Diensttraffic in Ihrer Google Cloud Organisation detailliert zu steuern, empfehlen wir, die Bedrohungen, die durch eine komplexere Perimeterstruktur abgedeckt werden, und die für die beabsichtigten Vorgänge erforderlichen Zugriffspfade zwischen den Perimetern klar zu definieren.

Wenn Sie VPC Service Controls einführen möchten, sollten Sie Folgendes berücksichtigen:

• Welche Ihrer Anwendungsfälle erfordern VPC Service Controls.
• Ob die erforderlichen Google Cloud Dienste VPC Service Controls unterstützen.
• Wie der Break-Glass-Zugriff konfiguriert werden soll, um den Perimeter zu ändern, falls er Ihre Automatisierungspipelines stört
• Best Practices zum Aktivieren von VPC Service Controls zum Entwerfen und Implementieren Ihres Perimeters

Nachdem Sie den Perimeter vom Probelauf- in den Erzwingungsmodus geändert haben, sollten Sie einen Prozess entwickeln, mit dem neue Projekte konsistent zum richtigen Perimeter hinzugefügt werden. Außerdem sollten Sie Ausnahmen planen, wenn Entwickler einen neuen Anwendungsfall haben, der von Ihrer aktuellen Perimeter-Konfiguration abgelehnt wird.

Organisationsweite Änderungen in einer separaten Organisation testen

Wir empfehlen, Änderungen niemals ohne Tests in der Produktionsumgebung bereitzustellen. Für Arbeitslastressourcen wird dieser Ansatz durch separate Umgebungen für Entwicklung, Nicht-Produktion und Produktion erleichtert. Einige Ressourcen in der Organisation haben jedoch keine separaten Umgebungen, um Tests zu ermöglichen.

Bei Änderungen auf Organisationsebene oder anderen Änderungen, die sich auf Produktionsumgebungen wie die Konfiguration zwischen Ihrem Identitätsanbieter und Cloud Identity auswirken können, sollten Sie eine separate Organisation zu Testzwecken erstellen.

Fernzugriff auf virtuelle Maschinen steuern

Da wir empfehlen, die unveränderliche Infrastruktur über die Grundlagenpipeline, die Infrastrukturpipeline und die Anwendungspipeline bereitzustellen, empfehlen wir Ihnen außerdem, Entwicklern nur eingeschränkten Zugriff auf eine virtuelle Maschine über SSH oder RDP für außergewöhnliche Anwendungsfälle zu gewähren.

Für Szenarien, die Fernzugriff erfordern, empfehlen wir, den Nutzerzugriff nach Möglichkeit mit OS Login zu verwalten. Bei diesem Ansatz werden verwaltete Google Cloud Dienste verwendet, um die Zugriffssteuerung, die Verwaltung des Kontolebenszyklus, die Bestätigung in zwei Schritten und das Audit-Logging zu erzwingen. Wenn Sie den Zugriff über SSH-Schlüssel in Metadaten oder RDP-Anmeldedaten zulassen müssen, liegt es in Ihrer Verantwortung, den Lebenszyklus von Anmeldedaten zu verwalten und Anmeldedaten sicher außerhalb von Google Cloudzu speichern.

In jedem Fall kann ein Nutzer mit SSH- oder RDP-Zugriff auf eine VM ein Risiko für die Ausweitung von Berechtigungen darstellen. Sie sollten Ihr Zugriffsmodell daher entsprechend gestalten. Der Nutzer kann Code auf dieser VM mit den Berechtigungen des zugehörigen Dienstkontos ausführen oder den Metadatenserver abfragen, um das Zugriffstoken aufzurufen, das zur Authentifizierung von API-Anfragen verwendet wird. Dieser Zugriff kann dann zu einer Rechteausweitung führen, wenn Sie nicht bewusst beabsichtigt haben, dass der Nutzer mit den Berechtigungen des Dienstkontos arbeitet.

Überschreitungen des Budgets durch Budgetbenachrichtigungen vermeiden

Im Blueprint werden Best Practices aus dem Google Cloud Well-Architected Framework: Cost Optimization zur Kostenverwaltung implementiert, darunter:

• Verwenden Sie ein einzelnes Rechnungskonto für alle Projekte in der Unternehmensgrundlage.

• Weisen Sie jedem Projekt ein billingcode-Metadatenlabel zu, mit dem Kosten zwischen Kostenstellen aufgeteilt werden.

• Budgets und Benachrichtigungsschwellen festlegen

Sie sind für die Planung von Budgets und die Konfiguration von Abrechnungsbenachrichtigungen verantwortlich. Das Blueprint erstellt Budgetbenachrichtigungen für Workload-Projekte, wenn die prognostizierten Ausgaben voraussichtlich 120% des Budgets erreichen. So kann ein zentrales Team Vorfälle mit erheblichen Mehrausgaben erkennen und beheben. Erhebliche unerwartete Ausgabensteigerungen ohne klaren Grund können ein Hinweis auf einen Sicherheitsvorfall sein und sollten sowohl aus Kostenkontroll- als auch aus Sicherheitssicht untersucht werden.

Hinweis :Budgetbenachrichtigungen sind eine andere Art von Benachrichtigung als die Kategorie „Abrechnung“ der wichtigen Kontakte. Budgetbenachrichtigungen beziehen sich auf die Nutzung von Budgets, die Sie für jedes Projekt definieren. Abrechnungsbenachrichtigungen von wichtigen Kontakten beziehen sich auf Preisaktualisierungen, Fehler und Guthaben.

Je nach Anwendungsfall können Sie ein Budget festlegen, das auf den Kosten eines gesamten Umgebungsordners oder aller Projekte basiert, die mit einer bestimmten Kostenstelle verknüpft sind, anstatt detaillierte Budgets für jedes Projekt festzulegen. Wir empfehlen außerdem, die Budget- und Benachrichtigungseinstellungen an die Verantwortlichen für die Arbeitslast zu delegieren, die möglicherweise einen detaillierteren Benachrichtigungsschwellenwert für die tägliche Überwachung festlegen.

Hinweise zur Kostenoptimierung finden Sie unter Kosten mit FinOps-Hub optimieren.

Kosten auf interne Kostenstellen aufteilen

In der Console können Sie Abrechnungsberichte aufrufen, um Kosten in mehreren Dimensionen zu sehen und zu prognostizieren. Zusätzlich zu den vordefinierten Berichten empfehlen wir, Abrechnungsdaten in ein BigQuery-Dataset im Projekt prj-c-billing-export zu exportieren. Mit den exportierten Abrechnungseinträgen können Sie Kosten benutzerdefinierten Dimensionen wie Ihren internen Kostenstellen auf Grundlage von Metadaten für Projektlabels wie billingcode zuordnen.

Die folgende SQL-Abfrage ist eine Beispielabfrage, mit der Sie die Kosten für alle Projekte ermitteln können, die nach dem Projektlabel billingcode gruppiert sind.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Informationen zum Einrichten dieses Exports finden Sie unter Cloud Billing-Daten in BigQuery exportieren.

Wenn Sie eine interne Abrechnung oder Rückbuchung zwischen Kostenstellen benötigen, müssen Sie die Daten, die Sie aus dieser Abfrage erhalten, in Ihre internen Prozesse einbeziehen.

Ergebnisse aus Aufdeckungskontrollen in Ihr vorhandenes SIEM aufnehmen

Die Grundlagenressourcen helfen Ihnen zwar beim Konfigurieren aggregierter Ziele für Audit-Logs und Sicherheitsergebnisse, doch liegt es in Ihrer Verantwortung, zu entscheiden, wie Sie diese Signale nutzen und verwenden.

Wenn Sie Logs aus allen Cloud- und lokalen Umgebungen in einem vorhandenen SIEM aggregieren müssen, entscheiden Sie, wie Sie Logs aus dem prj-c-logging-Projekt und Ergebnissen aus Security Command Center in Ihre vorhandenen Tools und Prozesse aufnehmen möchten. Sie können einen einzelnen Export für alle Logs und Ergebnisse erstellen, wenn ein einzelnes Team für die Überwachung der Sicherheit in Ihrer gesamten Umgebung verantwortlich ist, oder Sie können mehrere Exporte erstellen, die nach den Logs und Ergebnissen gefiltert sind, die für mehrere Teams mit unterschiedlichen Verantwortlichkeiten erforderlich sind.

Wenn das Logvolumen und die Kosten zu hoch sind, können Sie Duplikate vermeiden, indem Sie Google Cloud Logs und ‑Ergebnisse nur inGoogle Cloudbeibehalten. In diesem Fall müssen Sie dafür sorgen, dass Ihre bestehenden Teams den richtigen Zugriff und die richtige Schulung haben, um direkt inGoogle Cloudmit Logs und Ergebnissen zu arbeiten.

• Erstellen Sie für Audit-Logs Logansichten, um einzelnen Teams Zugriff auf eine Teilmenge von Logs in einem zentralisierten Log-Bucket zu gewähren, anstatt Logs in mehrere Buckets zu duplizieren, wodurch die Log-Speicherkosten erhöht werden.
• Gewähren Sie aus Sicherheitsgründen Rollen auf Ordner- und Projektebene für Security Command Center, damit Teams Sicherheitsergebnisse nur für die Projekte, für die sie zuständig sind, direkt in der Console aufrufen und verwalten können.

Kontinuierliche Entwicklung der Bibliothek für Kontrollen

Der Blueprint beginnt mit einer Referenz der Kontrollen, um Bedrohungen zu erkennen und zu verhindern. Wir empfehlen Ihnen, diese Kontrollen zu prüfen und je nach Ihren Anforderungen zusätzliche Kontrollen hinzuzufügen. In der folgenden Tabelle sind die Mechanismen zur Durchsetzung von Governance-Richtlinien zusammengefasst und es wird beschrieben, wie Sie diese für Ihre zusätzlichen Anforderungen erweitern können:

Richtlinienkontrollen, die vom Blueprint erzwungen werden	Anleitung zum Erweitern dieser Kontrollen
Security Command Center erkennt Sicherheitslücken und Bedrohungen aus mehreren Sicherheitsquellen.	Benutzerdefinierte Module für Security Health Analytics und benutzerdefinierte Module für Event Threat Detection definieren
Der Organisationsrichtliniendienst erzwingt eine empfohlene Reihe von Einschränkungen für Organisationsrichtlinien fürGoogle Cloud -Dienste.	Sie können zusätzliche Einschränkungen aus der vorgefertigten Liste verfügbarer Einschränkungen erzwingen oder benutzerdefinierte Einschränkungen erstellen.
Die OPA-Richtlinie (Open Policy Agent) validiert Code in der Foundation-Pipeline auf akzeptable Konfigurationen, bevor er bereitgestellt wird.	Entwickeln Sie zusätzliche Einschränkungen basierend auf den Informationen unter GoogleCloudPlatform/policy-library.
Mit Benachrichtigungen über logbasierte Messwerte und Leistungsmesswerte werden logbasierte Messwerte so konfiguriert, dass bei Änderungen an IAM-Richtlinien und Konfigurationen einiger sensibler Ressourcen Benachrichtigungen ausgelöst werden.	Entwerfen Sie zusätzliche logbasierte Messwerte und Benachrichtigungsrichtlinien für Logereignisse, die in Ihrer Umgebung nicht auftreten sollten.
Eine benutzerdefinierte Lösung für die automatisierte Loganalyse fragt regelmäßig Logs nach verdächtigen Aktivitäten ab und erstellt Security Command Center-Ergebnisse.	Schreiben Sie zusätzliche Abfragen, um Ergebnisse für Sicherheitsereignisse zu erstellen, die Sie überwachen möchten. Verwenden Sie dazu die Analyse von Sicherheitslogs als Referenz.
Eine benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen erstellt Ergebnisse von Security Command Center und kann Abhilfemaßnahmen automatisieren.	Erstellen Sie zusätzliche Cloud Asset Inventory-Feeds, um Änderungen für bestimmte Asset-Typen zu überwachen, und schreiben Sie zusätzliche Cloud Run-Funktionen mit benutzerdefinierter Logik, um auf Richtlinienverstöße zu reagieren.

Diese Kontrollen können sich ändern, wenn sich Ihre Anforderungen undGoogle Cloud -Reife ändern.

Verschlüsselungsschlüssel mit Cloud Key Management Service verwalten

Google Cloud bietet für alle Kundeninhalte eine Standardverschlüsselung inaktiver Daten, aber auch Cloud Key Management Service (Cloud KMS), um Ihnen zusätzliche Kontrolle über Ihre Verschlüsselungsschlüssel für inaktive Daten zu bieten. Wir empfehlen, dass Sie prüfen, ob die Standardverschlüsselung ausreicht oder ob Sie eine Complianceanforderung haben, die Sie dazu verpflichtet, Schlüssel selbst mit Cloud KMS zu verwalten. Weitere Informationen finden Sie unter Entscheiden, wie Sie Compliance-Anforderungen für die Verschlüsselung inaktiver Daten erfüllen.

Der Blueprint stellt ein prj-c-kms-Projekt im gemeinsamen Ordner und ein prj-{env}-kms-Projekt in jedem Umgebungsordner zur zentralen Verwaltung von Verschlüsselungsschlüsseln bereit. So kann ein zentrales Team Verschlüsselungsschlüssel, die von Ressourcen in Arbeitslastprojekten verwendet werden, prüfen und verwalten, um behördliche und Compliance-Anforderungen zu erfüllen.

Je nach operativem Modell möchten Sie möglicherweise eine einzelne zentralisierte Projektinstanz von Cloud KMS unter der Kontrolle eines einzelnen Teams verwenden, oder Sie möchten Verschlüsselungsschlüssel separat in jeder Umgebung verwalten oder Sie bevorzugen möglicherweise mehrere verteilte Instanzen, damit die Rechenschaftspflicht für Verschlüsselungsschlüssel an die entsprechenden Teams delegiert werden kann Ändern Sie das Terraform-Codebeispiel nach Bedarf entsprechend Ihrem operativen Modell.

Optional können Sie Organisationsrichtlinien für kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) erzwingen, um zu erzwingen, dass bestimmte Ressourcentypen immer einen CMEK-Schlüssel erfordern und dass nur CMEK-Schlüssel aus einer Zulassungsliste vertrauenswürdiger Projekte verwendet werden können.

Anmeldedaten von Anwendungen mit Secret Manager speichern und prüfen

Wir empfehlen, niemals vertrauliche Secrets wie API-Schlüssel, Passwörter und private Zertifikate in Quellcode-Repositories zu übertragen. Übertragen Sie stattdessen das Secret an Secret Manager und weisen Sie dem Nutzer oder Dienstkonto, das auf das Secret zugreifen muss, die IAM-Rolle Zugriffsfunktion für Secret Manager-Secret zu. Wir empfehlen, die IAM-Rolle einem einzelnen Secret zuzuweisen, nicht allen Secrets im Projekt.

Nach Möglichkeit sollten Sie Produktions-Secrets automatisch in den CI/CD-Pipelines generieren und für Nutzer unzugänglich aufbewahren, außer in Break-Glass-Situationen. Achten Sie in diesem Fall darauf, dass Sie keinen Nutzern oder Gruppen IAM-Rollen zum Ansehen dieser Secrets zuweisen.

Der Blueprint stellt ein einzelnes prj-c-secrets-Projekt im gemeinsamen Ordner und ein prj-{env}-secrets-Projekt in jedem Umgebungsordner für die zentrale Verwaltung von Secrets bereit. Mit diesem Ansatz kann ein zentrales Team die von Anwendungen verwendeten Secrets prüfen und verwalten, um behördliche und Compliance-Anforderungen zu erfüllen.

Je nach operativem Modell können Sie eine einzelne zentralisierte Instanz von Secret Manager unter der Kontrolle eines einzelnen Teams verwenden oder Secrets in jeder Umgebung separat verwalten oder mehrere verteilte Instanzen von Secret Manager bevorzugen, damit jedes Arbeitslastteam seine eigenen Secrets verwalten kann. Ändern Sie das Terraform-Codebeispiel nach Bedarf entsprechend Ihrem operativen Modell.

Breakglass-Zugriff auf Konten mit hohen Berechtigungen planen

Wir empfehlen zwar, Änderungen an Grundlagenressourcen über einen versionierten IaC zu verwalten, der von der Grundlagenpipeline bereitgestellt wird, doch kann es außergewöhnliche oder Notfallszenarien geben, die einen privilegierten Zugriff zum direkten Ändern Ihrer Umgebung erfordern. Wir empfehlen, Breakglass-Konten (manchmal auch als Firecall- oder Notfallkonten bezeichnet) zu planen, die im Notfall oder bei Ausfall der Automatisierungsprozesse Zugriff mit hohen Berechtigungen auf Ihre Umgebung haben.

In der folgenden Tabelle werden einige Beispiele für die Verwendung von Breakglass-Konten beschrieben.

Zweck von Break-Glass	Beschreibung
Super Admin	Notfallzugriff auf die Rolle Super Admin, die mit Cloud Identity verwendet wird, um beispielsweise Probleme im Zusammenhang mit der Identitätsföderation oder Multi-Faktor-Authentifizierung zu beheben (MFA).
Organisationsadministrator	Notfallzugriff auf die Rolle Organisationsadministrator, mit der dann Zugriff auf jede andere IAM-Rolle in der Organisation gewährt werden kann.
Grundlagenpipeline-Administrator	Notfallzugriff zum Ändern der Ressourcen in Ihrem CICD-Projekt aufGoogle Cloud und im externen Git-Repository, falls die Automatisierung der Foundation-Pipeline fehlschlägt.
Operations oder SRE	Ein Betriebs- oder SRE-Team benötigt privilegierten Zugriff, um auf Ausfälle oder Vorfälle zu reagieren. Dazu können Aufgaben wie das Neustarten von VMs oder das Wiederherstellen von Daten gehören.

Welche Methode Sie für den Breakglass-Zugriff verwenden, hängt von den vorhandenen Tools und Verfahren ab. Hier einige Beispiele:

• Verwenden Sie Ihre vorhandenen Tools für die privilegierte Zugriffsverwaltung, um einen Nutzer vorübergehend einer Gruppe hinzuzufügen, die mit IAM-Rollen mit hohen Berechtigungen vordefiniert ist, oder verwenden Sie die Anmeldedaten eines Kontos mit umfangreichen Berechtigungen.
• Stellen Sie Konten vorab nur für Administratoren bereit. Entwicklerin Dana könnte beispielsweise die Identität [e-mail] für den täglichen Gebrauch und [e-mail] für den Breakglass-Zugriff haben.
• Verwenden Sie eine Anwendung wie den privilegierten Just-in-Time-Zugriff, mit der Entwickler privilegierte Rollen selbst eskalieren können.

Unabhängig davon, welchen Mechanismus Sie verwenden, sollten Sie sich überlegen, wie Sie die folgenden Fragen operativ beantworten:

• Wie legen Sie den Umfang und die Granularität des Breakglass-Zugriffs fest? Beispielsweise können Sie für unterschiedliche Geschäftseinheiten unterschiedliche Break-Glass-Mechanismen entwerfen, damit diese sich nicht gegenseitig stören.
• Wie wird durch Ihren Mechanismus Missbrauch verhindert? Benötigen Sie Genehmigungen? Beispiel: Sie haben möglicherweise aufgeteilte Vorgänge, bei denen eine Person Anmeldedaten enthält und eine andere Person das MFA-Token enthält.
• Wie prüfen Sie den Breakglass-Zugriff und wie werden Sie darüber benachrichtigt? Sie können beispielsweise ein benutzerdefiniertes Event Threat Detection-Modul konfigurieren, um ein Sicherheitsergebnis zu erstellen, wenn ein vordefiniertes Breakglass-Konto verwendet wird.
• Wie entfernen Sie den Breakglass-Zugriff und nehmen den normalen Betrieb wieder auf, nachdem der Vorfall beendet ist?

Für häufige Aufgaben zur Rechteausweitung und zum Rückgängigmachen von Änderungen empfehlen wir, automatisierte Workflows zu entwickeln, in denen ein Nutzer den Vorgang ausführen kann, ohne dass eine Rechteausweitung für seine Nutzeridentität erforderlich ist. So lassen sich menschliche Fehler reduzieren und die Sicherheit verbessern.

Für Systeme, die regelmäßig Eingriffe erfordern, ist die Automatisierung der Korrektur möglicherweise die beste Lösung. Google empfiehlt Kunden, einen Zero-Touch-Produktionsansatz zu verfolgen, um alle Produktionsänderungen mithilfe von Automatisierung, sicheren Proxys oder geprüften Breakglass-Verfahren vorzunehmen. Google stellt Kunden, die den SRE-Ansatz von Google übernehmen möchten, die SRE-Bücher zur Verfügung.

Nächste Schritte

• Lesen Sie Blueprint bereitstellen (nächstes Dokument in dieser Reihe).