Sicherheit für Ihre Google Cloud Landing Zone festlegen

Last reviewed 2023-08-31 UTC

In diesem Dokument werden wichtige Sicherheitsentscheidungen und empfohlene Optionen vorgestellt, die Sie beim Entwerfen einer Google Cloud-Landing-Zone bedenken müssen. Es ist Teil einer Reihe über Landing-Zones und richtet sich an Sicherheitsexperten, CISOs und Architekten, die die Entscheidungen verstehen möchten, die sie beim Entwerfen einer Landing-Zone in Google Cloud treffen.

In diesem Dokument wird davon ausgegangen, dass ein zentrales Team wie das Sicherheits- oder Plattformteam diese Sicherheitskontrollen für die Landing-Zone durchsetzt. Da der Schwerpunkt dieses Dokuments auf dem Design von Umgebungen für Unternehmen liegt, sind einige hier beschriebene Strategien für kleine Teams möglicherweise weniger relevant.

Entscheidungspunkte zur Sicherung der Google Cloud-Landing-Zone

Um das beste Sicherheitsdesign für Ihre Organisation auszuwählen, müssen Sie die folgenden Entscheidungen treffen:

Architekturaufbau

In der in diesem Dokument beschriebenen Beispielarchitektur werden gängige Sicherheitsdesignmuster verwendet. Ihre spezifischen Kontrollen können je nach Faktoren wie der Branche Ihres Unternehmens, Zielarbeitslasten oder zusätzlichen Compliance-Anforderungen variieren. Das folgende Diagramm zeigt die Sicherheitskontrollenarchitektur, die Sie in Ihrer Landing-Zone anwenden, wenn Sie den Empfehlungen in diesem Dokument folgen.

Beispiel für eine Architektur der Sicherheitskontrolle.

Das obige Diagramm zeigt Folgendes:

  • Die Verwaltung von Dienstkontoschlüsseln verringert das Risiko von langlebigen Anmeldedaten für Dienstkonten.
  • VPC Service Controls definiert einen Perimeter um sensible Ressourcen herum, mit dem der Zugriff von außerhalb des Perimeters eingeschränkt werden kann.
  • Security Command Center überwacht die Umgebung auf unsichere Konfigurationen und Bedrohungen.
  • Eine zentrale Logsenke erfasst Audit-Logs aus allen Projekten.
  • In der Standardverschlüsselung von Google werden alle Daten verschlüsselt, die auf dem Laufwerk gespeichert bleiben.
  • Die Standardverschlüsselung von Google bei der Übertragung gilt für Netzwerkpfade der Layers 3 und 4.
  • Mit Access Transparency erhalten Sie Einblicke und die Kontrolle darüber, wie Google auf Ihre Umgebung zugreifen kann.

Entscheiden, wie nichtflüchtige Anmeldedaten für Dienstkonten eingeschränkt werden sollen

Dienstkonten sind Maschinenidentitäten, mit denen Sie Arbeitslasten IAM-Rollen zuweisen, die den Zugriff auf Google Cloud APIs ermöglichen. Ein Dienstkontoschlüssel ist ein nichtflüchtiger Satz Anmeldedaten. Nichtflüchtige Anmeldedaten stellen ein potenziell hohes Risiko dar. Wir raten davon ab, Entwicklern die freie Erstellung von Dienstkontenschlüsseln zu gestatten.

Wenn ein Entwickler beispielsweise den Dienstkontoschlüssel versehentlich in einem öffentlichen Git-Repository festschreibt, kann sich ein externer Angreifer mit diesen Anmeldedaten authentifizieren. Ein weiteres Beispiel: Wenn der Dienstkontoschlüssel in einem internen Repository gespeichert ist, kann ein böswilliger Insider, der den Schlüssel lesen kann, mithilfe der Anmeldedaten seine eigenen Google Cloud-Berechtigungen eskalieren.

Wenn Sie eine Strategie zum Verwalten dieser nichtflüchtigen Anmeldedaten definieren möchten, müssen Sie umsetzbare Alternativen angeben, die Verbreitung nichtflüchtiger Anmeldedaten einschränken und deren Verwendung verwalten. Informationen zu Alternativen zu Dienstkontoschlüsseln finden Sie unter Beste Authentifizierungsmethode für Ihren Anwendungsfall auswählen.

In den folgenden Abschnitten werden die Optionen zum Einschränken der nichtflüchtigen Anmeldedaten beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die anderen in den folgenden Abschnitten beschriebenen Optionen sind Alternativen, die Sie berücksichtigen können, wenn Option 1 nicht für Ihre spezifische Organisation gilt.

Für alle Organisationen, die nach dem 23. Mai 2024 erstellt wurden, werden standardmäßig sichere Organisationsrichtlinien erzwungen, wenn die Organisationsressource zum ersten Mal erstellt wird. Durch diese Änderung wird Option 1 zur Standardoption.

Option 1: Verwendung von Dienstkontoschlüsseln einschränken

Es wird empfohlen, Nutzern das Herunterladen von Dienstkontoschlüsseln nicht zu erlauben, da offengelegte Schlüssel oft für Angriffe verwendet werden. Die Beschränkung der Verwendung von nichtflüchtigen Dienstkontoschlüsseln ist eine Option, die Risiko und Aufwand der manuellen Verwaltung von Dienstkontoschlüsseln verringern kann.

Beachten Sie beim Implementieren dieser Option Folgendes:

  • Wenn Sie verhindern möchten, dass Entwickler nichtflüchtige Anmeldedaten erstellen und herunterladen, konfigurieren Sie eine Einschränkung als Organisationsrichtlinie constraints/iam.disableServiceAccountKeyCreation.
  • Informieren Sie Ihre Teams über sichere Alternativen zu Dienstkontoschlüsseln. Wenn beispielsweise Nutzer und Anwendungen, die sich außerhalb Ihrer Google Cloud-Umgebung befinden, ein Dienstkonto verwenden müssen, können sie die Identitätsübernahme des Dienstkontos oder die Identitätsföderation von Arbeitslasten anstelle eines Dienstkontoschlüssels zur Authentifizierung verwenden.
  • Entwerfen Sie ein Verfahren, mit dem Teams eine Ausnahme von dieser Richtlinie anfordern können, wenn der Download eines Dienstkontoschlüssels die einzige praktikable Option ist. Beispiel: Für das SaaS-Produkt eines Drittanbieters ist möglicherweise ein Dienstkontoschlüssel erforderlich, um Logs aus der Google Cloud-Umgebung zu lesen.

Vermeiden Sie diese Option, wenn Sie bereits Tools zum Generieren kurzlebiger API-Anmeldedaten für Dienstkonten haben.

Hier finden Sie weitere Informationen:

Option 2: Zusätzliche Zugriffsverwaltungstools zum Generieren kurzlebiger Anmeldedaten nutzen

Als Alternative zur Einschränkung der Verwendung nichtflüchtiger Dienstkontoschlüssel können Sie kurzlebige Anmeldedaten für Dienstkonten generieren. Kurzlebige Anmeldedaten führen zu weniger Risiken als nichtflüchtige Anmeldedaten wie Dienstkontoschlüssel. Sie können eigene Tools entwickeln oder Lösungen von Drittanbietern wie HashiCorp Vault verwenden, um kurzlebige Anmeldedaten zu generieren.

Verwenden Sie diese Option, wenn Sie bereits in ein Tool eines Drittanbieters zur Erstellung kurzlebiger Anmeldedaten für die Zugriffssteuerung investiert haben oder über ein ausreichendes Budget und ausreichende Kapazitäten verfügen, um Ihre eigene Lösung zu entwickeln.

Vermeiden Sie diese Option, wenn Sie keine vorhandenen Tools zum Zuweisen kurzlebiger Anmeldedaten haben oder Ihnen die Kapazitäten fehlen, um eine eigene Lösung zu erstellen.

Weitere Informationen finden Sie unter Kurzlebige Anmeldedaten für das Dienstkonto erstellen.

Entscheiden, wie die Daten-Exfiltration über Google APIs minimiert werden soll

Google APIs haben öffentliche Endpunkte, die allen Kunden zur Verfügung stehen. Obwohl jede API-Ressource in Ihrer Google Cloud-Umgebung den IAM-Zugriffskontrollen unterliegt, besteht das Risiko, dass auf Daten mit gestohlenen Anmeldeinformationen zugegriffen wird, sie durch böswillige Insider oder kompromittierten Code exfiltriert werden oder durch eine falsch konfigurierte IAM-Richtlinie offengelegt werden.

VPC Service Controls ist eine Lösung, mit der diese Risiken behoben werden. VPC Service Controls erhöht jedoch auch die Komplexität Ihres Zugriffsmodells. Daher müssen Sie VPC Service Controls so entwickeln, dass es Ihren jeweiligen Umgebungen und Anwendungsfällen entspricht.

In den folgenden Abschnitten werden die Optionen zum Minimieren der Daten-Exfiltration über Google APIs beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die anderen in den folgenden Abschnitten beschriebenen Optionen sind Alternativen, die Sie berücksichtigen können, wenn Option 1 nicht für Ihren spezifischen Anwendungsfall gilt.

Option 1: VPC Service Controls über Ihre gesamte Umgebung hinweg konfigurieren

Wir empfehlen, Ihre Umgebung innerhalb eines oder mehrerer, alle unterstützten APIs einschränkender VPC Service Controls-Perimeter zu entwerfen. Konfigurieren Sie Ausnahmen für den Perimeter über Zugriffsebenen oder Ingress-Richtlinien, damit Entwickler auf die erforderlichen Dienste zugreifen können, einschließlich Konsolenzugriff.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Die Dienste, die Sie verwenden möchten, unterstützen VPC Service Controls. Weiter erfordern Ihre Arbeitslasten keinen uneingeschränkten Internetzugang.
  • Sie speichern sensible Daten in Google Cloud, die bei Exfiltration einen bedeutenden Verlust bedingen würden.
  • Sie verfügen über konsistente Attribute für den Entwicklerzugriff, die als Ausnahmen vom Perimeter konfiguriert werden können, sodass die Nutzer auf die Daten zugreifen können, die sie benötigen.

Vermeiden Sie diese Option, wenn Ihre Arbeitslasten uneingeschränkten Internetzugang oder Dienste benötigen, die nicht von VPC Service Controls unterstützt werden.

Hier finden Sie weitere Informationen:

Option 2: VPC Service Controls für einen Teil Ihrer Umgebung konfigurieren

Statt VPC Service Controls allgemein in der gesamten Umgebung zu konfigurieren, können Sie VPC Service Controls nur für die Teilmenge an Projekten konfigurieren, die sensible Daten und vertrauliche Arbeitslasten enthalten. Mit dieser Option können Sie für die meisten Projekte ein Design und Betrieb einfacher gestalten und gleichzeitig den Datenschutz für Projekte mit sensiblen Daten priorisieren.

Sie können diese Alternative beispielsweise verwenden, wenn eine begrenzte Anzahl von Projekten BigQuery-Datasets mit sensiblen Daten enthält. Sie können einen Dienstperimeter nur für diese Projekte definieren und Regeln für eingehenden und ausgehenden Traffic definieren, um eingeschränkten Ausnahmen für die Analysten zu ermöglichen, die diese Datasets verwenden müssen.

Ein weiteres Beispiel wäre eine Anwendung mit einer Architektur mit drei Ebenen, in der sich einige Komponenten außerhalb des Perimeters befinden können. Die Präsentationsebene, die eingehenden Traffic von Nutzern zulässt, kann ein Projekt außerhalb des Perimeters sein. Die Anwendungs- und Datenebenen, die sensible Daten enthalten, können separate Projekte innerhalb des Dienstperimeters sein. Sie definieren Regeln für ein- und ausgehenden Traffic für den Perimeter, damit die Ebenen über den Perimeter hinaus bei kontrolliertem Zugriff kommunizieren können.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Nur begrenzte und klar definierte Projekte enthalten vertrauliche Daten. Andere Projekte enthalten Daten mit geringerem Risiko.
  • Einige Arbeitslasten werden rein intern ausgeführt, für andere ist jedoch ein öffentlicher Internetzugang erforderlich, oder es bestehen Abhängigkeiten von Diensten, die nicht von VPC Service Controls unterstützt werden.
  • Die projektübergreifende Konfiguration von VPC Service Controls verursacht zu viel Overhead oder erfordert zu viele Problemumgehungen

Vermeiden Sie diese Option, wenn viele Projekte möglicherweise sensible Daten enthalten.

Weitere Informationen finden Sie unter Best Practices zum Aktivieren von VPC Service Controls

Option 3: VPC Service Controls nicht konfigurieren

Eine weitere Alternative zur umfassenden Konfiguration von VPC Service Controls in Ihrer Umgebung ist der Verzicht auf VPC Service Controls, insbesondere wenn der betriebliche Mehraufwand den Wert von VPC Service Controls überwiegt.

Angenommen, Ihre Organisation hat kein konsistentes Muster für den Entwicklerzugriff, das als Grundlage für eine Richtlinie für eingehenden Traffic dienen könnte. Vielleicht wird Ihr IT-Betrieb an mehrere Drittanbieter ausgelagert. Entwickler nutzen also weder verwaltete Geräte, noch greifen sie von konsistenten IP-Adressen aus zu. In diesem Szenario können Sie möglicherweise keine Regeln für eingehenden Traffic definieren, um die Perimeter-Ausnahmen zuzulassen, die Entwickler für ihre täglichen Arbeiten benötigen.

Verwenden Sie diese Option in folgenden Fällen:

  • Sie verwenden Dienste, die VPC Service Controls nicht unterstützen.
  • Die Arbeitslasten sind auf das Internet ausgerichtet und enthalten keine sensiblen Daten.
  • Sie haben keine konsistenten Attribute für den Entwicklerzugriff, z. B. verwaltete Geräte oder bekannte IP-Bereiche.

Vermeiden Sie diese Option, wenn Ihre Google Cloud-Umgebung sensible Daten beinhaltet.

Entscheiden, wie Sie kontinuierlich auf unsichere Konfigurationen und Bedrohungen überwachen

Die Einführung von Clouddiensten führt im Vergleich zur Verwendung von lokalen Diensten neue Herausforderungen und Bedrohungen ein. Vorhandene Tools, die langlebige Server überwachen, sind möglicherweise nicht für das Autoscaling oder für flüchtige Dienste geeignet und überwachen serverlose Ressourcen potenziell gar nicht. Daher sollten Sie Sicherheitstools in Betracht ziehen, die mit allen von Ihnen nutzbaren Cloud-Diensten kompatibel sind. Sie sollten auch kontinuierlich auf Cloud-Standards wie die CIS-Benchmarks für Google Cloud achten.

In den folgenden Abschnitten werden die Optionen für das kontinuierliche Monitoring beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die anderen in den folgenden Abschnitten beschriebenen Optionen sind Alternativen, die Sie berücksichtigen können, wenn Option 1 nicht für Ihren spezifischen Anwendungsfall gilt.

Option 1: Security Command Center verwenden

Wir empfehlen, Security Command Center auf Organisationsebene zu aktivieren. Das verbessert Ihren Sicherheitsstatus durch folgende Elemente:

  • Angriffsflächen und Sicherheitsmaßnahmen für Ihre Daten verstehen
  • Asset-Inventar und -Erkennung bereitstellen
  • Konfigurationsfehler, Sicherheitslücken und Bedrohungen erkennen
  • Risiken mindern und beheben

Wenn Sie Security Command Center zu Beginn Ihres Landing-Zone-Builds aktivieren, hat das Sicherheitsteam Ihrer Organisation nahezu in Echtzeit Einblick in unsichere Konfigurationen, Bedrohungen und Handlungsoptionen. Diese Transparenz hilft Ihrem Sicherheitsteam bei der Beurteilung, ob die Landing-Zone ihren Anforderungen entspricht und ob die Entwickler mit der Bereitstellung der Anwendungen beginnen können.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Sie benötigen ein Tool für Sicherheitsstatus-Management und Bedrohungserkennung, das ohne zusätzlichen Integrationsaufwand in alle Google Cloud-Dienste eingebunden ist.
  • Sie möchten die Bedrohungsinformationen, Strategien zum maschinellen Lernen und sonstige erweiterte Methoden nutzen, die Google zum Schutz seiner eigenen Dienste verwendet.
  • Ihr vorhandenes Sicherheitsbetriebszentrum (SOC, Security Operations Center) hat nicht die erforderlichen Fähigkeiten oder Kapazitäten, um Bedrohungsinformationen aus einem großen Volumen an Cloudlogs zu generieren.

Vermeiden Sie diese Option, falls Ihre vorhandenen Sicherheitstools flüchtige oder serverlose Cloud-Ressourcen vollständig abfangen, unsichere Konfigurationen überwachen und Bedrohungen in großem Maßstab in einer Cloud-Umgebung erkennen können.

Option 2: Vorhandene Sicherheitstools für die Verwaltung des Cloud-Sicherheitsverhaltens und die Bedrohungserkennung verwenden

Als Alternative zur Verwendung von Security Command Center können Sie andere Managementtools des Cloud-Sicherheitsstatus in Betracht ziehen. Es gibt verschiedene Drittanbietertools, die ähnliche Funktionen wie Security Command Center haben. Sie haben möglicherweise bereits in cloudnative Tools investiert, die sich auf Multi-Cloud-Umgebungen konzentrieren.

Sie können Security Command Center und Tools von Drittanbietern auch zusammen verwenden. So können Sie beispielsweise die Ergebnisbenachrichtigungen aus dem Security Command Center in ein anderes Tool übernehmen oder einen Sicherheitsdienst eines Drittanbieters in das Dashboard des Security Command Center hinzufügen. Ein weiteres Beispiel wäre möglicherweise die Speicherung von Logs in einem vorhandenen SIEM-System, damit das SOC-Team Bedrohungen analysieren kann. Sie könnten Ihr bestehendes SIEM so konfigurieren, dass es nur die Ergebnisbenachrichtigungen aufnimmt, die das Security Command Center produziert, anstatt eine große Menge an Logs aufzunehmen und von einem SOC-Team zu erwarten, dass es die Rohdatenlogs analysiert, um einen Einblick zu erhalten.

Verwenden Sie diese Option, wenn Ihre vorhandenen Sicherheitstools flüchtige oder serverlose Cloud-Ressourcen vollständig abfangen, unsichere Konfigurationen überwachen und Bedrohungen in großem Maßstab in einer Cloud-Umgebung erkennen können.

Vermeiden Sie diese Strategie, wenn Folgendes zutrifft:

  • Ihr vorhandenes SOC hat nicht die erforderlichen Fähigkeiten oder Kapazitäten, um Bedrohungsinformationen aus einem großen Volumen an Cloudlogs zu generieren.
  • Die Integration mehrerer Tools von Drittanbietern in mehrere Google Cloud-Dienste führt zu mehr Komplexität als Nutzen.

Hier finden Sie weitere Informationen:

Entscheiden, wie die erforderlichen Logs zentral zusammengefasst werden

Die meisten Audit-Logs werden in dem Google Cloud-Projekt gespeichert, von dem sie erstellt wurden. Wenn Ihre Umgebung wächst, kann es für einen Prüfer unmöglich sein, die Logs in jedem einzelnen Projekt zu prüfen. Daher müssen Sie entscheiden, wie Logs zentralisiert und aggregiert werden, um Ihre internen Audit- und Sicherheitsvorgänge zu unterstützen.

In den folgenden Abschnitten werden die Optionen für das Zusammenfassen von Logs beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die anderen in den folgenden Abschnitten beschriebenen Optionen sind Alternativen, die Sie berücksichtigen können, wenn Option 1 nicht für Ihren spezifischen Anwendungsfall gilt.

Option 1: Logs in Google Cloud mit aggregierten Logsenken aufbewahren

Wir empfehlen Ihnen, eine zentrale organisationsweite Logsenke für Audit-Logs und andere, von Ihrem Sicherheitsteam benötigten Logs zu konfigurieren. Mit dem Tool für den Log-Geltungsbereich können Sie die Logs ermitteln, die Ihr Sicherheitsteam benötigt, und erkennen, ob diese Log-Typen explizit aktiviert werden müssen.

Beispiel: Das Sicherheitsteam erwartet zentrale Aufzeichnungen aller Ressourcen, die Ihre Nutzer erstellen, damit es verdächtige Änderungen überwachen und untersuchen kann. Das Sicherheitsteam benötigt außerdem einen unveränderlichen Datensatz des Datenzugriffs auf bestimmte hochsensible Arbeitslasten. Daher konfiguriert das Sicherheitsteam eine Logsenke, um Audit-Logs zu Administratoraktivitäten aus allen Projekten in einem Loganaylse-Bucket in einem zentralen Projekt zusammenzufassen, das es spontan zur Prüfung aufrufen kann. Anschließend wird eine zweite Logsenke für Audit-Logs zum Datenzugriff aus Projekten mit vertraulichen Arbeitslasten in einen Cloud Storage-Bucket konfiguriert, wobei hier eine langfristige Aufbewahrung erfolgt.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Ihr Sicherheitsteam erwartet eine zentrale Aufzeichnung aller Audit-Logs oder anderer bestimmter Logtypen.
  • Ihr Sicherheitsteam muss Logs in einer Umgebung mit eingeschränktem Zugriff speichern, außerhalb der Kontrolle der Arbeitslasten oder der Teams, die das Log erstellt haben.

Vermeiden Sie diese Strategie, wenn Folgendes zutrifft:

  • Ihre Organisation hat keine zentrale Anforderung für konsistente Audit-Logs über Arbeitslasten hinweg.
  • Einzelne Projektinhaber sind für die Verwaltung ihrer Audit-Logs verantwortlich.

Hier finden Sie weitere Informationen:

Option 2: Erforderliche Audit-Logs in Speicher außerhalb von Google Cloud exportieren

Als Alternative zum ausschließlichen Speichern von Logs in Google Cloud können Sie Audit-Logs nach außerhalb von Google Cloud exportieren. Nachdem Sie die erforderlichen Logtypen in einer gemeinsamen Logsenke in Google Cloud zentralisiert haben, senden Sie den Inhalt dieser Senke zu einer anderen Plattform außerhalb von Google Cloud, um Logs dort zu speichern und zu analysieren.

Sie können beispielsweise einen SIEM-Drittanbieterdienst verwenden, um Audit-Logs für mehrere Cloud-Anbieter zusammenzufassen und zu analysieren. Dieses Tool verfügt über ausreichende Funktionen, um mit serverlosen Cloud-Ressourcen zu arbeiten. Ihr SOC-Team hat die erforderlichen Fähigkeiten und Kapazitäten, um aus diesem großen Logvolumen Informationen zu generieren.

Diese Option kann aufgrund der Kosten für ausgehenden Netzwerktraffic in Google Cloud sowie der Kosten für Speicher und Kapazität in der anderen Umgebung sehr teuer sein. Anstatt jedes verfügbare Log zu exportieren, sollten Sie gezielt auswählen, welche Logs in die externe Umgebung übertragen werden sollen.

Verwenden Sie diese Option, wenn Sie Logs von allen Umgebungen und Cloud-Anbietern an einem einzigen zentralen Ort speichern müssen.

Vermeiden Sie diese Strategie, wenn Folgendes zutrifft:

  • Ihre vorhandenen Systeme haben nicht die Kapazität oder das Budget, um ein großes Volumen zusätzlicher Cloud-Logs aufzunehmen.
  • Ihre vorhandenen Systeme erfordern Integrationsarbeiten für jeden Logtyp und jedes Format.
  • Sie erfassen Logs, ohne klar zu wissen, wie Sie diese verwenden wollen.

Weitere Informationen finden Sie im Blueprint zu den Unternehmensgrundlagen unter Aufdeckungskontrollen.

Entscheiden Sie, wie Sie Compliance-Anforderungen für die Verschlüsselung inaktiver Daten erfüllen

Google Cloud verschlüsselt alle Ihre inaktiven Inhalte automatisch mit einem oder mehreren Verschlüsselungsmechanismen. Je nach Compliance-Anforderungen sind Sie möglicherweise dazu verpflichtet, die Verschlüsselungsschlüssel selbst zu verwalten.

In den folgenden Abschnitten werden die Optionen für die Verschlüsselung inaktiver Daten beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die anderen in den folgenden Abschnitten beschriebenen Optionen sind Alternativen, die Sie berücksichtigen können, wenn Option 1 nicht für Ihren spezifischen Anwendungsfall gilt.

Option 1: Standardmäßige Verschlüsselung ruhender Daten akzeptieren

Die Standardverschlüsselung ruhender Daten ist für viele Anwendungsfälle ausreichend, die keine besonderen Compliance-Anforderungen in Sachen Verwaltung von Verschlüsselungsschlüsseln haben.

Beispielsweise erfordert das Sicherheitsteam eines Online-Gaming-Unternehmens, dass alle Kundendaten im inaktiven Zustand verschlüsselt werden. Sie haben keine gesetzlichen Anforderungen an die Schlüsselverwaltung, und nachdem sie die standardmäßige Verschlüsselung inaktiver Daten von Google geprüft haben, sind sie davon überzeugt, dass diese für ihre Bedürfnisse ausreichend ist.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Sie haben keine besonderen Anforderungen an die Verschlüsselung von Daten oder die Verwaltung von Verschlüsselungsschlüsseln.
  • Sie bevorzugen einen verwalteten Dienst gegenüber den Kosten und dem operativen Aufwand der Verwaltung Ihrer eigenen Verschlüsselungsschlüssel.

Vermeiden Sie diese Option, wenn Sie Complianceanforderungen für die Verwaltung eigener Verschlüsselungsschlüssel haben.

Weitere Informationen finden Sie unter Verschlüsselung inaktiver Daten in Google Cloud.

Option 2: Verschlüsselungsschlüssel mit Cloud KMS verwalten

Zusätzlich zur Standardverschlüsselung inaktiver Daten benötigen Sie möglicherweise mehr Kontrolle über die Schlüssel, die zum Verschlüsseln inaktiver Daten in einem Google Cloud-Projekt verwendet werden. Cloud Key Management Service (Cloud KMS) bietet die Möglichkeit, Ihre Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) zu schützen. Beispielsweise müssen Sie in der Finanzdienstleistungsbranche möglicherweise Ihren externen Prüfern mitteilen, wie Sie Ihre eigenen Verschlüsselungsschlüssel für sensible Daten verwalten.

Um die Sicherheit weiter zu verbessern, können Sie Hardwaresicherheitsmodule (HSM) oder die externe Schlüsselverwaltung (External Key Managemant, EKM) mit CMEK konfigurieren. Vom Kunden bereitgestellte Verschlüsselungsschlüssel (CSEK, Customer-Supplied Encryption Keys) werden nicht empfohlen. Bei Szenarien, bei denen in der Vergangenheit CSEK verwendet wurde, ist aktuell der Cloud External Key Manager (Cloud EKM) eine bessere Option, da Cloud EKM Unterstützung für mehr Dienste und eine höhere Verfügbarkeit bietet.

Diese Option erwartet von Anwendungsentwicklern ein gewisses Maß an Verantwortung, da sie den Methoden der Schlüsselverwaltung, die Ihr Sicherheitsteam vorgibt, folgen müssen. Um die Anforderung durchzusetzen, kann Ihr Sicherheitsteam die Erstellung nicht-konformer Ressourcen mit CMEK-Organisationsrichtlinien blockieren.

Verwenden Sie diese Option, wenn eine oder mehrere der folgenden Bedingungen zutreffen:

  • Sie müssen den Lebenszyklus Ihrer eigenen Schlüssel verwalten.
  • Sie sind verpflichtet, kryptografisches Schlüsselmaterial mit einem nach FIPS 140-2 Level 3 zertifizierten HSM zu generieren.
  • Sie sind verpflichtet, kryptografisches Schlüsselmaterial außerhalb von Google Cloud mit Cloud EKM speichern.

Vermeiden Sie diese Strategie, wenn Folgendes zutrifft:

  • Sie haben keine besonderen Anforderungen an die Verschlüsselung von Daten oder die Verwaltung von Verschlüsselungsschlüsseln.
  • Sie bevorzugen einen verwalteten Dienst gegenüber den Kosten und dem operativen Aufwand der Verwaltung Ihrer eigenen Verschlüsselungsschlüssel.

Hier finden Sie weitere Informationen:

Option 3: Daten auf Anwendungsebene tokenisieren, bevor sie im Speicher abgelegt werden

Zusätzlich zur von Google bereitgestellten Standardverschlüsselung können Sie auch eine eigene Lösung entwickeln, um Daten vor dem Speichern in Google Cloud zu tokenisieren.

Beispielsweise muss ein Data Scientist ein Dataset mit personenidentifizierbaren Informationen analysieren, aber der Data Scientist sollte keinen Zugriff zum Lesen der Rohdaten einiger vertraulicher Felder haben. Wenn Sie den Zugriff auf Rohdaten einschränken möchten, können Sie mit Sensitive Data Protection eine Aufnahmepipeline für die Aufnahme und Tokenisierung sensibler Daten entwickeln und die tokenisierten Daten dann in BigQuery speichern.

Die Tokenisierung ist keine Kontrolle, die Sie zentral in der Landezone erzwingen können. Stattdessen werden durch diese Option die Anwendungsentwickler in die Pflicht genommen, eigene Verschlüsselungen zu konfigurieren, oder ein Plattformteam, das eine Verschlüsselungspipeline als gemeinsam genutzten Dienst entwickelt.

Verwenden Sie diese Option, wenn bestimmte Arbeitslasten sehr sensible Daten haben, die nicht in Rohform verwendet werden dürfen.

Vermeiden Sie diese Option, wenn Cloud KMS für Ihre Anforderungen ausreicht, wie unter Verschlüsselungsschlüssel mit Cloud KMS verwalten beschrieben. Das Verschieben von Daten durch zusätzliche Verschlüsselungs- und Entschlüsselungspipelines erhöht die Kosten, Latenz und Komplexität von Anwendungen.

Hier finden Sie weitere Informationen

Entscheiden, wie Compliance-Anforderungen für die Verschlüsselung bei der Übertragung erfüllt werden sollen

Google Cloud bietet verschiedene Sicherheitsmaßnahmen, um die Authentifizierung, Integrität und Vertraulichkeit von Daten bei der Übertragung zu gewährleisten. Abhängig von Ihren Sicherheits- und Complianceanforderungen können Sie auch die Verschlüsselung auf Anwendungsebene konfigurieren.

In den folgenden Abschnitten werden die Optionen für die Verschlüsselung bei der Übertragung beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die andere in den folgenden Abschnitten beschriebene Option ist eine zusätzliche Funktion, die Sie in Betracht ziehen können, wenn Option 1 für Ihren spezifischen Anwendungsfall nicht ausreicht.

Option 1: Prüfen, ob die Standardverschlüsselung bei der Übertragung ausreicht

Viele Trafficmuster in Ihrer Landing Zone profitieren von der Standardverschlüsselung von Google während der Übertragung.

  • Der gesamte VM-zu-VM-Traffic in einem VPC-Netzwerk und verbundenen VPC-Netzwerken wird auf Ebene 3 oder Ebene 4 verschlüsselt.

  • Traffic aus dem Internet zu Google-Diensten wird am Google Front End (GFE) beendet. GFE führt außerdem Folgendes aus:

    • Beendet den Traffic für eingehenden HTTP(S)-, TCP- und TLS-Proxy-Traffic
    • Bietet Gegenmaßnahmen bei DDoS-Angriffen
    • Leitet Traffic an die Google Cloud-Dienste weiter und führt ein Load-Balancing aus

Ein Traffic-Muster, das konfiguriert werden muss, ist Cloud Interconnect, da Traffic von Ihrer lokalen Umgebung zu Google Cloud standardmäßig nicht verschlüsselt wird. Wenn Sie Cloud Interconnect verwenden, empfehlen wir, MACsec für Cloud Interconnect als Teil Ihrer Landingzone zu aktivieren.

Verwenden Sie diese Option, wenn die Standardverschlüsselung von Google während der Übertragung für Ihre internen Arbeitslasten ausreicht.

Vermeiden Sie diese Strategie, wenn Folgendes zutrifft:

  • Sie lassen eingehenden Internet-Traffic in Ihr VPC-Netzwerk zu.
  • Sie benötigen die Verschlüsselung für Ebene 7 bei der Übertragung zwischen allen internen Rechenressourcen.

In diesen Fällen sollten Sie zusätzliche Kontrollen konfigurieren, wie unter Option 2: Anwendungen müssen die Layer 7-Verschlüsselung bei der Übertragung konfigurieren.

Weitere Informationen finden Sie unter Verschlüsselung bei der Übertragung in Google Cloud.

Option 2: Anwendungen müssen die Layer 7-Verschlüsselung bei der Übertragung konfigurieren

Zusätzlich zur Standardverschlüsselung bei der Übertragung können Sie die Verschlüsselung für Ebene 7 für den Anwendungstraffic konfigurieren. Google Cloud bietet verwaltete Dienste zur Unterstützung von Anwendungen, die eine Verschlüsselung auf Anwendungsebene während der Übertragung benötigen, einschließlich verwalteter Zertifikate und Cloud Service Mesh.

Beispielsweise erstellt ein Entwickler eine neue Anwendung, die eingehenden Traffic aus dem Internet akzeptiert. Sie verwenden einen externen Application Load Balancer mit von Google verwalteten SSL-Zertifikaten, um Dienste hinter einer einzelnen IP-Adresse auszuführen und zu skalieren.

Die Verschlüsselung auf Anwendungsebene ist keine Kontrolle, die Sie zentral in der Landezone erzwingen können. Stattdessen werden durch diese Option die Anwendungsentwickler in die Pflicht genommen, da diese die Verschlüsselung während der Übertragung konfigurieren müssen.

Verwenden Sie diese Option, wenn Anwendungen HTTPS oder SSL-Traffic zwischen Komponenten erfordern.

Erwägen Sie bei dieser Option einige wenige Ausnahmen, wenn Sie Computing-Arbeitslasten in die Cloud migrieren, für die zuvor (als die Anwendungen noch lokal ausgeführt wurden) keine Verschlüsselung für internen Traffic während der Übertragung erforderlich war. Wenn Sie bei einer umfangreichen Migration die Modernisierung von Legacy-Anwendungen vor der Migration erzwingen, kann dies zu inakzeptablen Verzögerungen führen.

Hier finden Sie weitere Informationen:

Entscheiden Sie, welche zusätzlichen Kontrollen für die Verwaltung des Zugriffs auf Cloud-Dienstanbieter erforderlich sind

Die Notwendigkeit des Audits des Cloud-Dienstanbieters (CSP) kann während der Cloud-Einführung ein Problem darstellen. Google Cloud bietet mehrere Kontrollebenen, mit denen der Zugriff auf Cloud-Anbieter überprüft werden kann.

In den folgenden Abschnitten werden die Optionen zum Verwalten des CSP-Zugriffs beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die andere in den folgenden Abschnitten beschriebene Option ist eine zusätzliche Funktion, die Sie in Betracht ziehen können, wenn Option 1 für Ihren spezifischen Anwendungsfall nicht ausreicht.

Option 1: Access Transparency-Logs aktivieren

Access Transparency-Logs erfassen die Aktionen, die von Google-Mitarbeitern in Ihrer Umgebung ausgeführt wurden, z. B. wenn diese Probleme mit einem Supportfall beheben.

Beispiel: Ihr Entwickler fordert von Cloud Customer Care Hilfe bei der Fehlerbehebung an, ein Supportmitarbeiter will sich nun Ihre Umgebung ansehen. Es wird ein Access Transparency-Log generiert, um zu zeigen, welche Aktionen der Supportmitarbeiter durchgeführt hat, einschließlich der Supportfallnummer, die diese Aktionen rechtfertigt.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Sie müssen sicherstellen, dass die Google-Cloud-Mitarbeiter nur aus berechtigten geschäftlichen Gründen auf Ihre Inhalte zugreifen, z. B. um einen Ausfall zu beheben oder Ihre Support-Anfragen zu bearbeiten.
  • Sie haben eine Compliance-Anforderung, um den Zugriff auf sensible Daten zu verfolgen.

Option 2: Access Transparency-Logs und Anbieterzugriffsverwaltung aktivieren

Wenn Ihr Unternehmen eine Compliance-Anforderung hat, eine ausdrückliche Genehmigung zu erteilen, bevor ein CSP auf Ihre Umgebung zugreifen kann, können Sie zusätzlich zu Option 1 Access Transparency mit anderen Kontrollen verwenden, mit denen Sie den Zugriff auf Ihre Daten ausdrücklich genehmigen oder verweigern können.

Die Zugriffsgenehmigung ist eine manuelle Lösung, die dafür sorgt, dass der Kundendienst und die Google-Ingenieure immer dann Ihre explizite Genehmigung benötigen (per E-Mail oder über einen Webhook), wenn sie auf Ihre Inhalte zugreifen müssen.

Key Access Justifications ist eine programmatische Lösung, die jeder Anfrage für mit Cloud EKM konfigurierte Verschlüsselungsschlüssel ein Begründungsfeld hinzufügt.

Verwenden Sie diese Option, wenn Folgendes zutrifft:

  • Sie möchten, dass ein zentrales Team den Zugriff auf Ihre Inhalte durch Google-Mitarbeiter direkt verwaltet.
  • Bei der Zugriffsgenehmigung können Sie das Risiko in Kauf nehmen, dass die zentrale Fähigkeit, jeden Zugriffsantrag zu genehmigen oder abzulehnen, wichtiger ist als der operative Kompromiss, der in einer langsameren Lösung von Supportfällen bestehen könnte.
  • Bei Key Access Justifications verwendet Ihr Unternehmen bereits den Cloud External Key Manager als Teil Ihrer Verschlüsselungsstrategie und möchte eine programmatische Kontrolle über alle Arten des Zugriffs auf verschlüsselte Daten (nicht nur den Zugriff von Google-Mitarbeitern auf Daten).

Vermeiden Sie diese Strategie, wenn Folgendes zutrifft:

  • Die betriebliche Verzögerung, die entstehen kann, wenn ein zentrales Team mit Zugriffsgenehmigungsbefugnis reagieren muss, ist ein inakzeptables Risiko für Arbeitslasten, die eine hohe Verfügbarkeit und eine schnelle Reaktion des Kundendienstes erfordern.

Hier finden Sie weitere Informationen:

Best Practices für die Sicherheit von Google Cloud-Landing-Zones

Beachten Sie neben den in diesem Dokument vorgestellten Entscheidungen folgende Best Practices für die Sicherheit:

Nächste Schritte