Best Practices für Vorgänge

In diesem Abschnitt werden Vorgänge beschrieben, die Sie beim Bereitstellen und Ausführen zusätzlicher Arbeitslasten in Ihrer Google Cloud-Umgebung berücksichtigen müssen. Dieser Abschnitt ist nicht als umfassender Leitfaden für alle Vorgänge in Ihrer Cloud-Umgebung gedacht. Er enthält jedoch Entscheidungen im Zusammenhang mit den architektonischen Empfehlungen und Ressourcen, die vom Blueprint bereitgestellt werden.

Ressourcen für die Stiftung aktualisieren

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

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 Projekt-Factory-Modul der Automatisierungspipeline erstellen, müssen Sie verschiedene Attribute konfigurieren. Der Prozess zum Entwerfen und Erstellen von Projekten für neue Arbeitslasten sollte Entscheidungen zu den folgenden Punkten umfassen:

• Zu aktivierende Google Cloud APIs
• 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 angewendet werden sollen
• Der Ordner, in dem das Projekt bereitgestellt wird
• Welches Abrechnungskonto verwenden?
• 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 Liste der konfigurierbaren Attribute für jedes Projekt finden Sie in der Automatisierungspipeline unter Eingabevariablen für die Projekt-Factory.

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 den Gruppen dann IAM-Rollen zuzuweisen. Beachten Sie immer das Prinzip der geringsten Berechtigung.

Wir empfehlen außerdem, den IAM Recommender zu verwenden, um Zulassungsrichtlinien zu identifizieren, die Rollen mit zu vielen Berechtigungen gewähren. Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu überprüfen oder automatisch in Ihre Bereitstellungspipelines anzuwenden.

Änderungen zwischen dem Netzwerkteam und dem Anwendungsteam koordinieren

Bei den Netzwerktopologien, die mit dem Blueprint bereitgestellt werden, wird davon ausgegangen, dass Sie ein Team für die Verwaltung von Netzwerkressourcen und separate Teams für die Bereitstellung von Ressourcen für die Arbeitslastinfrastruktur haben. Beim Bereitstellen der Infrastruktur müssen die Arbeitslastteams Firewallregeln erstellen, um die vorgesehenen Zugriffspfade zwischen den Komponenten ihrer Arbeitslast zuzulassen. 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 Arbeitslastteam 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-Dienstportfolio, das Empfehlungen zur Optimierung Ihrer Umgebung enthält. So liefern beispielsweise Firewall-Erkenntnisse oder der Recommender für unbeaufsichtigte Projekte umsetzbare Empfehlungen, mit denen Sie Ihren Sicherheitsstatus verbessern können.

Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu überprüfen oder automatisch in Ihre Bereitstellungspipelines anzuwenden. 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.

Der 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 auf Google 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 Kontrollmaßnahmen wie die 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.

Ressourcen mit VPC Service Controls schützen

Mit dem Blueprint können Sie Ihre Umgebung für VPC Service Controls vorbereiten, indem Sie die Basis- und eingeschränkten Netzwerke trennen. Standardmäßig sind VPC Service Controls jedoch nicht im Terraform-Code aktiviert, da dies zu Unterbrechungen führen kann.

Ein Perimeter verhindert den Zugriff auf eingeschränkte Google Cloud-Dienste durch Traffic, der außerhalb des Perimeters stammt. Dazu gehören die Console, Entwickler-Workstations 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 definieren, 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 Allow-Richtlinien für die detaillierte Zugriffssteuerung auf 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 so gestalten müssen, dass sie den Diensttraffic innerhalb Ihrer Google Cloud-Organisation genau steuern, empfehlen wir, die Bedrohungen, die von einer komplexeren Perimeterstruktur behandelt werden, und die Zugriffspfade zwischen den Perimetern, die für beabsichtigte Vorgänge benötigt werden, anzugehen.

Berücksichtigen Sie bei der Einführung von VPC Service Controls Folgendes:

• 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

• Informationen zum Entwerfen und Implementieren eines Perimeters mithilfe der Best Practices zum Aktivieren von VPC Service Controls

Nachdem der Perimeter aktiviert wurde, 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 nie ohne Tests in der Produktion bereitzustellen. Bei Arbeitslastressourcen wird dieser Ansatz durch separate Umgebungen für Entwicklung, Nicht-Produktion und Produktion unterstützt. 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, in denen ein Remotezugriff erforderlich ist, 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 Kontolebensdauerverwaltung, die Bestätigung in zwei Schritten und die Protokollierung von Prüfungen durchzusetzen. 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 Cloud zu speichern.

In jedem Fall kann ein Nutzer mit SSH- oder RDP-Zugriff auf eine VM ein Risiko für die Eskalierung von Berechtigungen darstellen. Berücksichtigen Sie dies bei der Gestaltung Ihres Zugriffsmodells. Der Nutzer kann Code mit den Berechtigungen des zugehörigen Dienstkontos auf dieser VM ausführen oder den Metadatenserver abfragen, um das Zugriffstoken aufzurufen, das zur Authentifizierung von API-Anfragen verwendet wird. Dieser Zugriff kann dann eine Rechteausweitung darstellen, wenn Sie nicht beabsichtigt haben, dass der Nutzer mit den Berechtigungen des Dienstkontos arbeitet.

Überschreitungen des Budgets durch Budgetbenachrichtigungen vermeiden

Der Blueprint implementiert Best Practices zur Kostenverwaltung, die im Google Cloud-Architektur-Framework: Kostenoptimierung vorgestellt wurden. Dazu gehören:

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

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

• Legen Sie Budgets und Benachrichtigungsgrenzwerte fest.

Sie sind dafür verantwortlich, Budgets zu planen und Abrechnungsbenachrichtigungen zu konfigurieren. Mit dem Blueprint werden Budgetwarnungen für Arbeitslastprojekte erstellt, wenn die prognostizierten Ausgaben voraussichtlich 120% des Budgets erreichen. Mit diesem Ansatz kann ein zentrales Team Fälle mit erheblichen Mehrausgaben erkennen und beheben. Eine erhebliche, unerwartete Steigerung der Ausgaben ohne klaren Grund kann ein Indikator für einen Sicherheitsvorfall sein und sollte sowohl aus Kostenkontroll- als auch aus Sicherheitsperspektive untersucht werden.

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 in Verbindung stehen, anstatt detaillierte Budgets für jedes Projekt festzulegen. Wir empfehlen außerdem, die Budget- und Benachrichtigungseinstellungen an die Eigentümer der Arbeitslast zu delegieren, die für die tägliche Überwachung detailliertere Benachrichtigungsgrenzwerte festlegen können.

Eine Anleitung zum Erstellen von FinOps-Funktionen, einschließlich der Budgetprognose für Arbeitslasten, finden Sie unter Erste Schritte mit FinOps in Google Cloud.

Kosten auf interne Kostenstellen verteilen

In der Console können Sie Ihre Abrechnungsberichte aufrufen, um Kosten in mehreren Dimensionen aufzurufen 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 anhand von Projektlabel-Metadaten wie billingcode auf benutzerdefinierte Dimensionen wie Ihre internen Kostenstellen verteilen.

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 nach BigQuery exportieren.

Wenn Sie eine interne Abrechnung oder eine Kostenaufschlüsselung zwischen Kostenstellen benötigen, müssen Sie die Daten aus dieser Abfrage in Ihre internen Prozesse einbinden.

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-Protokolle und -Ergebnisse nur in Google Cloud aufbewahren. In diesem Fall müssen Ihre bestehenden Teams den richtigen Zugriff und die richtige Schulung haben, um direkt in Google Cloud mit Protokollen 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 und ihre Erweiterung für Ihre zusätzlichen Anforderungen zusammengefasst:

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

Verschlüsselungsschlüssel mit dem 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 Ihnen, zu prüfen, ob die Standardverschlüsselung ausreicht oder ob Sie aufgrund einer Complianceanforderung Cloud KMS verwenden müssen, um Schlüssel selbst 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 für die zentrale Verwaltung von Verschlüsselungsschlüsseln bereit. So kann ein zentrales Team Verschlüsselungsschlüssel prüfen und verwalten, die von Ressourcen in Arbeitslastprojekten verwendet werden, um rechtliche 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 vom Kunden verwaltete 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, sensible Secrets wie API-Schlüssel, Passwörter und private Zertifikate niemals in Quellcode-Repositories zu committen. Ü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 Lesen dieser Geheimnisse gewähren.

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 von Entwicklern die von Anwendungen verwendeten Geheimnisse prüfen und verwalten, um rechtliche 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.

Notfallzugriff auf hoch privilegierte Konten 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 Ihnen, Notfallkonten (manchmal auch als Notfall- oder Wartungskonten bezeichnet) zu planen, die im Notfall oder bei Ausfällen der Automatisierungsprozesse einen hoch privilegierten Zugriff auf Ihre Umgebung haben.

In der folgenden Tabelle sind einige Beispiele für die Verwendung von Notfallkonten aufgeführt.

Die Art und Weise, wie Sie den Notfallzugriff ermöglichen, hängt von den vorhandenen Tools und Verfahren ab. Beispiele für solche Mechanismen:

• 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. Die Entwicklerin Dana könnte beispielsweise die Identität dana@beispiel.de für die tägliche Nutzung und admin-dana@beispiel.de für den Notfallzugriff haben.
• Verwenden Sie eine Anwendung wie den privilegierten Just-in-Time-Zugriff, mit der Entwickler privilegierte Rollen selbst eskalieren können.

Unabhängig vom verwendeten Mechanismus sollten Sie überlegen, wie Sie die folgenden Fragen operativ beantworten:

• Wie legen Sie den Umfang und die Detailgenauigkeit des Notfallzugriffs fest? Beispielsweise können Sie für unterschiedliche Geschäftseinheiten unterschiedliche Break-Glass-Mechanismen entwerfen, damit diese sich nicht gegenseitig stören.
• Wie verhindert Ihr Mechanismus Missbrauch? Benötige ich 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 und benachrichtigen Sie bei einem Notfallzugriff? Sie können beispielsweise ein benutzerdefiniertes Modul für die Ereignisbedrohungserkennung konfigurieren, um eine Sicherheitsanfrage zu erstellen, wenn ein vordefiniertes Notfallkonto verwendet wird.
• Wie entfernen Sie den Notfallzugriff und nehmen Sie den normalen Betrieb wieder auf, nachdem der Vorfall vorbei ist?

Für häufige Aufgaben zur Berechtigungserweiterung und zum Zurückrollen von Änderungen empfehlen wir, automatisierte Workflows zu entwerfen, bei denen ein Nutzer die Aktion ausführen kann, ohne dass eine Berechtigungserweiterung für seine Nutzeridentität erforderlich ist. Dieser Ansatz kann dazu beitragen, menschliche Fehler zu reduzieren und die Sicherheit zu 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 verwenden, um alle Produktionsänderungen mithilfe von Automatisierung, sicheren Proxys oder geprüften Notfallzugriffsmethoden vorzunehmen. Google stellt die SRE-Bücher für Kunden zur Verfügung, die den SRE-Ansatz von Google übernehmen möchten.

Nächste Schritte

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