Best Practices für Vorgänge

Last reviewed 2023-12-20 UTC

In diesem Abschnitt werden Vorgänge vorgestellt, die Sie für die Bereitstellung und den Betrieb zusätzlicher Arbeitslasten in der Google Cloud-Umgebung berücksichtigen müssen. In diesem Abschnitt werden nicht alle Vorgänge in Ihrer Cloud-Umgebung aufgelistet. Es werden jedoch Entscheidungen in Bezug auf die vom Blueprint bereitgestellten Architekturempfehlungen und -ressourcen vorgestellt.

Grundlagenressourcen aktualisieren

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

Zum Ändern von Grundlagenressourcen empfehlen wir, alle Änderungen über die Grundlagenpipeline vorzunehmen. Eine Einführung in den Ablauf des Schreibens von Code, Zusammenführen 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 folgenden Themen enthalten:

  • Welche Google Cloud APIs aktiviert werden sollen
  • Welche freigegebene VPC verwendet werden soll oder ob ein neues VPC-Netzwerk erstellt werden soll
  • Welche IAM-Rollen für die 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
  • Zu verwendendes Rechnungskonto
  • 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 das Projekt-Factory in der Automatisierungspipeline.

Berechtigungen in großem Umfang verwalten

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

Wir empfehlen außerdem die Verwendung des IAM Recommenders, um Zulassungsrichtlinien zu ermitteln, die überprivilegierte Rollen gewähren. Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu prüfen oder Empfehlungen automatisch auf Ihre Bereitstellungspipelines anzuwenden.

Änderungen zwischen dem Netzwerk- und dem Anwendungsteam

Bei den vom Blueprint bereitgestellten Netzwerktopologien wird davon ausgegangen, dass Sie ein Team für die Verwaltung von Netzwerkressourcen und separate Teams für die Bereitstellung von Arbeitslastinfrastrukturressourcen haben. Wenn die Arbeitslastteams die Infrastruktur bereitstellen, müssen sie Firewallregeln erstellen, um die beabsichtigten 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 zentralisierten Netzwerkressourcen zu koordinieren, die für die Bereitstellung von Anwendungen erforderlich sind. Sie können 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-Portfolio von Diensten, um Empfehlungen zur Optimierung Ihrer Umgebung zu geben. Beispielsweise bieten Firewallstatistiken oder der Recommender für unbeaufsichtigte Projekte umsetzbare Empfehlungen zur Verbesserung des Sicherheitsstatus.

Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu prüfen oder Empfehlungen automatisch auf Ihre Bereitstellungspipelines anzuwenden. Entscheiden Sie, welche Empfehlungen von einem zentralen Team verwaltet werden sollen und welche Verantwortung für Arbeitslastinhaber 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 erzwingen.

Mit dem Blueprint wird beispielsweise die Einschränkung iam.disableServiceAccountKeyCreation erzwungen. 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. eine Es gibt jedoch Anwendungsfälle, die sich nur mit einem Dienstkontoschlüssel authentifizieren können, z. B. einem lokalen 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, solange zusätzliche Kompensationskontrollen 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 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 Es müssen zusätzliche Steuerelemente vorhanden sein, um dies auszugleichen. Wenn Sie einer Arbeitslast eine Ausnahme gewähren, ändern Sie die Einschränkung der Organisationsrichtlinie so eingeschränkt wie möglich. Sie können auch Organisationsrichtlinien Einschränkungen 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

Der Blueprint hilft Ihnen, Ihre Umgebung für VPC Service Controls vorzubereiten, indem Sie die Basis- und eingeschränkten Netzwerke trennen. Standardmäßig aktiviert der Terraform-Code jedoch VPC Service Controls nicht, da diese Aktivierung einen störenden Prozess verursachen kann.

Ein Perimeter verweigert den Zugriff auf eingeschränkte Google Cloud-Dienste über Traffic, der von außerhalb des Perimeters stammt, einschließlich der Console, Entwickler-Workstations und der für die Bereitstellung von Ressourcen verwendeten Grundlagenpipeline. Wenn Sie VPC Service Controls verwenden, müssen Sie Ausnahmen für den Perimeter entwerfen, die die gewünschten Zugriffspfade zulassen.

Ein VPC Service Controls-Perimeter ist für die Exfiltration zwischen Ihrer Google Cloud-Organisation und externen Quellen vorgesehen. Der Perimeter dient nicht dazu, Zulassungsrichtlinien für eine detaillierte Zugriffssteuerung auf einzelne Projekte oder Ressourcen zu ersetzen oder zu 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.

Prüfen Sie Folgendes, um VPC Service Controls zu übernehmen:

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 in der Produktion niemals ohne Tests 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 erleichtern.

Bei Änderungen auf Organisationsebene oder für andere Ä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.

Remotezugriff 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 einen Remotezugriff erfordern, empfehlen wir, den Nutzerzugriff nach Möglichkeit mit OS Login zu verwalten. Bei diesem Ansatz werden verwaltete Google Cloud-Dienste verwendet, um Zugriffssteuerung, Verwaltung des Kontolebenszyklus, Bestätigung in zwei Schritten und 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 und Speicher zu verwalten und Anmeldedaten sicher außerhalb von Google Cloud bereitzustellen.

In jedem Szenario kann ein Nutzer mit SSH- oder RDP-Zugriff auf eine VM ein Risiko für die Rechteausweitung sein. Berücksichtigen Sie dies bei der Entwicklung Ihres Zugriffsmodells. 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 eine Rechteausweitung sein, wenn der Nutzer absichtlich nicht mit den Berechtigungen des Dienstkontos arbeiten möchte.

Budgetüberschreitungen durch Planung von Budgetbenachrichtigungen minimieren

Der Blueprint implementiert Best Practices, die im Google Cloud-Architektur-Framework: Kostenoptimierung eingeführt wurden, um die Kosten zu verwalten, darunter:

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

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

  • Budgets und Schwellenwerte für Benachrichtigungen festlegen

Es liegt in Ihrer Verantwortung, Budgets zu planen und Abrechnungsbenachrichtigungen zu konfigurieren. Der Blueprint erstellt Budgetbenachrichtigungen für Arbeitslastprojekte, wenn die prognostizierten Ausgaben bei 120% des Budgets liegen. Mit diesem Ansatz kann ein zentrales Team Vorfälle mit erheblichen Budgetüberschreitungen identifizieren und minimieren. Erhebliche unerwartete Ausgabenerhöhungen ohne klare Ursache können ein Indikator für einen Sicherheitsvorfall sein und sollten aus Sicht der Kostenkontrolle und -sicherheit untersucht werden.

Je nach Anwendungsfall können Sie ein Budget festlegen, das auf den Kosten eines gesamten Umgebungsordners oder allen Projekten im Zusammenhang mit einer bestimmten Kostenstelle basiert, anstatt für jedes Projekt detaillierte Budgets festzulegen. Außerdem empfehlen wir, Budget und Benachrichtigungseinstellung an Arbeitslastinhaber zu delegieren, die einen detaillierteren Schwellenwert für Benachrichtigungen für ihre tägliche Überwachung festlegen könnten.

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

Kosten zwischen internen Kostenstellen zuordnen

Mit 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, dass Sie Abrechnungsdaten in ein BigQuery-Dataset im Projekt prj-c-billing-logs exportieren. Mit den exportierten Abrechnungseinträgen können Sie benutzerdefinierte Dimensionen, z. B. Ihre internen Kostenstellen, basierend auf Projektlabel-Metadaten wie billingcode zuweisen.

Die folgende SQL-Abfrage ist eine Beispielabfrage, um die Kosten für alle Projekte zu verstehen, 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 interne Buchhaltung oder Rückbuchung zwischen Kostenstellen benötigen, sind Sie dafür verantwortlich, die aus dieser Abfrage abgerufenen Daten in Ihre internen Prozesse einzubinden.

Ergebnisse aus Erkennungskontrollen in Ihr vorhandenes SIEM aufnehmen

Obwohl die Grundlagenressourcen Ihnen beim Konfigurieren aggregierter Ziele für Audit-Logs und Sicherheitsergebnisse helfen, 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 unerschwinglich sind, können Sie Duplikate vermeiden, indem Sie Google Cloud-Logs und -Ergebnisse nur in Google Cloud aufbewahren. Sorgen Sie in diesem Szenario dafür, dass Ihre vorhandenen Teams den richtigen Zugriff und die richtigen Schulungen haben, um direkt mit Logs und Ergebnissen in Google Cloud 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 Steuerungsbibliothek

Der Blueprint beginnt mit einer Referenz der Steuerelemente, um Bedrohungen zu erkennen und zu verhindern. Wir empfehlen Ihnen, diese Steuerelemente zu prüfen und je nach Ihren Anforderungen zusätzliche Steuerelemente hinzuzufügen. In der folgenden Tabelle sind die Mechanismen zur Durchsetzung von Governance-Richtlinien und deren Erweiterung für zusätzliche Anforderungen zusammengefasst:

Durch den Blueprint erzwungene Richtlinienkontrollen Anleitung zum Erweitern dieser Steuerelemente

Security Command Center erkennt Sicherheitslücken und Bedrohungen aus mehreren Sicherheitsquellen.

Definieren Sie benutzerdefinierte Module für Security Health Analytics und benutzerdefinierte Module für Event Threat Detection.

Der Organisationsrichtliniendienst erzwingt eine empfohlene Reihe von Einschränkungen für Organisationsrichtlinien für Google Cloud-Dienste.

Erzwingen Sie zusätzliche Einschränkungen aus der vordefinierten Liste verfügbarer Einschränkungen oder erstellen Sie benutzerdefinierte Einschränkungen.

Die OPA-Richtlinie (Open Policy Agent) validiert Code in der Grundlagenpipeline für akzeptable Konfigurationen vor der Bereitstellung.

Entwickeln Sie zusätzliche Einschränkungen basierend auf der Anleitung unter GoogleCloudPlatform/policy-library.

Benachrichtigungen zu logbasierten Messwerten und Leistungsmesswerten konfigurieren logbasierte Messwerte, um Benachrichtigungen über Änderungen an IAM-Richtlinien und Konfigurationen einiger vertraulicher Ressourcen zu senden.

Entwerfen Sie zusätzliche logbasierte Messwerte und Benachrichtigungsrichtlinien für Logereignisse, die nicht in Ihrer Umgebung auftreten sollten.

Eine benutzerdefinierte Lösung für die automatisierte Loganalyse fragt Logs regelmäßig nach verdächtigen Aktivitäten ab und erstellt Ergebnisse von Security Command Center.

Schreiben Sie zusätzliche Abfragen, um Ergebnisse für Sicherheitsereignisse zu erstellen, die Sie überwachen möchten. Verwenden Sie dazu Sicherheitsloganalysen als Referenz.

Eine benutzerdefinierte Lösung, um auf Asset-Änderungen zu reagieren 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 Functions-Funktionen mit benutzerdefinierter Logik, um auf Richtlinienverstöße zu reagieren.

Diese Kontrollen können sich ändern, wenn sich Ihre Anforderungen und die Reife mit Google Cloud ä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 Compliance-Anforderungen haben, sodass Sie Cloud KMS selbst verwalten müssen. Weitere Informationen finden Sie unter 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 Verwaltung der Verschlüsselungsschlüssel zentral bereit. Mit diesem Ansatz kann ein zentrales Team Verschlüsselungsschlüssel prüfen und verwalten, die von Ressourcen in Arbeitslastprojekten verwendet werden, um regulatorische und Compliance-Anforderungen zu erfüllen.

In Abhängigkeit von Ihrem operativen 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 an Ihr operatives 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 kann.

Anmeldedaten von Anwendungen mit Secret Manager speichern und prüfen

Wir empfehlen, keine vertraulichen Secrets (z. B. API-Schlüssel, Passwörter und private Zertifikate) an Quellcode-Repositories zu übergeben. Übertragen Sie stattdessen das Secret an Secret Manager und weisen Sie dem Nutzer oder Dienstkonto die IAM-Rolle Zugriffsperson für Secret Manager-Secret zu, die muss auf das Secret zugreifen. Wir empfehlen, die IAM-Rolle einem einzelnen Secret zuzuweisen, nicht allen Secrets im Projekt.

Nach Möglichkeit sollten Sie Produktionsschlüssel automatisch in den CI/CD-Pipelines generieren und diese für Nutzer, außer in Break-Glass-Situationen, zugänglich machen. Achten Sie in diesem Szenario darauf, keine IAM-Rollen zum Anzeigen dieser Secrets für Nutzer oder Gruppen zuzuweisen.

Der Blueprint stellt ein einzelnes prj-c-secrets-Projekt im gemeinsamen Ordner und ein prj-{env}-secrets-Projekt in jedem Umgebungsordner bereit, um Secrets zentral zu verwalten. Mit diesem Ansatz kann ein zentrales Team Secrets prüfen und verwalten, die von Anwendungen verwendet werden, um regulatorische 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 an Ihr operatives Modell.

Break-Glass-Zugriff auf Konten mit umfangreichen Berechtigungen planen

Obwohl wir empfehlen, Änderungen an Grundlagenressourcen über einen versionierten IaC zu verwalten, der von der Grundlagenpipeline bereitgestellt wird, gibt es möglicherweise außergewöhnliche oder Notfallszenarien, die einen privilegierten Zugriff zum direkten Ändern Ihrer Umgebung erfordern. Wir empfehlen, Break-Glass-Konten (manchmal auch als Firecall- oder Notfallkonten bezeichnet) mit hohem privilegierten Zugriff auf Ihre Umgebung zu planen, wenn ein Notfall eintritt oder die Automatisierungsprozesse unterbrochen werden.

In der folgenden Tabelle werden einige Beispielzwecke für Break-Glass-Konten beschrieben.

Break-Glass-Zweck 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, der dann Zugriff auf jede andere IAM-Rolle in der Organisation gewähren kann.

Grundlagenpipeline-Administrator

Notfallzugriff zum Ändern der Ressourcen in Ihrem CICD-Projekt in Google Cloud und im externen Git-Repository für den Fall, dass die Automatisierung der Grundlagenpipeline fehlschlägt.

Operations oder SRE

Ein Betriebs- oder SRE-Team benötigt privilegierten Zugriff, um auf Ausfälle oder Vorfälle zu reagieren. Dies kann Aufgaben wie den Neustart von VMs oder die Wiederherstellung von Daten umfassen.

Ihr Mechanismus für den Zugriff auf Break-Glass hängt von den vorhandenen Tools und Verfahren ab. Einige Beispielmechanismen sind:

  • 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 Sie verwenden die Anmeldedaten eines Kontos mit umfangreichen Berechtigungen.
  • Stellen Sie Konten vorab für Administratoren bereit. Zum Beispiel könnte die Entwicklerin Dana die Identität "dana@example.com" für die tägliche Verwendung und die Rolle "admin-dana@example.com" für den Zugriff auf Break-Glass haben.
  • Verwenden Sie eine Anwendung wie den privilegierten Zugriff mit Just-in-Time-Berechtigung, mit der Entwickler sich mehr privilegierte Rollen selbst eskalieren können.

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

  • Wie entwerfen Sie den Umfang und den Detaillierungsgrad des Break-Glass-Zugriffs? Beispielsweise können Sie für unterschiedliche Geschäftseinheiten einen anderen Break-Glass-Mechanismus entwerfen, damit diese sich nicht gegenseitig stören.
  • Wie verhindert der Mechanismus Missbrauch? Benötigen Sie Genehmigungen? Beispiel: Sie haben aufgeteilte Vorgänge, bei denen eine Person Anmeldedaten enthält und eine Person das MFA-Token enthält.
  • Wie prüfen und melden Sie den Zugriff auf Break-Glass? Sie können beispielsweise ein benutzerdefiniertes Event Threat Detection-Modul konfigurieren, um bei Verwendung eines vordefinierten Break-Glass-Kontos ein Sicherheitsergebnis zu erstellen.
  • Wie entfernen Sie den Zugriff auf Break-Glass und setzen normale Vorgänge fort, nachdem der Vorfall beendet ist?

Für allgemeine Aufgaben zur Rechteausweitung und das Rollback von Änderungen empfehlen wir, automatisierte Workflows zu entwerfen, bei denen ein Nutzer den Vorgang ausführen kann, ohne dass eine Rechteausweitung für die Nutzeridentität erforderlich ist. Dieser Ansatz kann dabei helfen, menschliche Fehler zu reduzieren und die Sicherheit zu verbessern.

Für Systeme, die regelmäßig Eingriffe erfordern, ist die Automatisierung der Lösung möglicherweise die beste Lösung. Google empfiehlt Kunden einen Zero-Touch-Produktionsansatz, um alle Produktionsänderungen mithilfe von Automatisierung, sicheren Proxys oder geprüften Break-Glass vorzunehmen. Google bietet die SRE-Bücher für Kunden an, die den SRE-Ansatz von Google verwenden möchten.

Wie geht es weiter?