Best Practices für Sicherheit

Auf dieser Seite werden Best Practices für die Sicherung Ihrer Google Distributed Cloud-Installation beschrieben.

Physische Hardwaresicherheit

Sie sind für die physische Sicherheit der mit Distributed Cloud verbundenen Hardware verantwortlich, z. B. für die Beschränkung des Zugriffs auf autorisiertes Personal.

Der Formfaktor „Distributed Cloud Connected Tack“ bietet die folgenden Sicherheitsfunktionen:

  • Der Zugriff auf die im Rack installierte Hardware ist nur über die vorderen und hinteren Racktüren möglich.
  • Das Rack lässt sich nicht einfach demontieren. Es gibt keine von außen zugänglichen strukturellen Befestigungselemente wie Schrauben, Muttern, Riegel oder Nieten.
  • Die Racktüren sind mit Schlüsselschlössern ausgestattet. Google stellt Ihnen eine Kopie des Schlüssels zur Verfügung und bewahrt eine Kopie sicher auf.
  • Bei Installationen mit mehreren Racks sind alle Rack-Schlösser gleichschließend.
  • Die Racktüren haben ein perforiertes, manipulationssicheres Metallgitter zur Belüftung.
  • Während der Installation wird das Rack mit den Transportstreben und ‑winkeln sicher am Boden des Installationsorts verschraubt.

Der Formfaktor des verbundenen Servers von Distributed Cloud bietet die folgenden Sicherheitsfunktionen:

  • Ein Einbruchssensor. Wenn eine unbefugte Person das Gerät physisch öffnet, werden Sie und Google sofort über den physischen Eingriff benachrichtigt.

Wenn Sie weitere Fragen zur Sicherheit des physischen Racks haben, wenden Sie sich an Ihren Google Cloud Kundenbetreuer.

Plattformsicherheit

Die verbundene Hardwareplattform von Distributed Cloud bietet die folgenden Sicherheitsfunktionen:

  • Trusted Platform Module (TPM). Das TPM ist der Root of Trust, der Verschlüsselungsschlüssel für alle Daten generiert und speichert, die auf Distributed Cloud Connected gespeichert, empfangen und übertragen werden.

  • Plattformzertifikat Das Plattformzertifikat ist ein kryptografisch sicherer Datensatz der Fertigungs- und TPM-Identität. Das Zertifikat dient als Nachweis für die Integrität der Lieferkette für mit Distributed Cloud verbundene Hardware.

  • Port-Sperre: Alle externen und internen Ports außer Ethernet-Ports, z. B. USB- und RS-232-Konsolenports, sind auf Firmware-Ebene deaktiviert und werden nur für Wartungsarbeiten aktiviert.

Sicherheit des lokalen Speichers

Die Hardware von Distributed Cloud Connected wird je nach Formfaktor mit den folgenden Arten von internem Speicher ausgeliefert:

  • Racks mit Distributed Cloud-Verbindung werden mit Solid-State-Laufwerken (SSDs) geliefert.
  • Distributed Cloud Connected-Server werden mit selbstverschlüsselnden Festplatten (Self-Encrypting Disk, SED) ausgeliefert.

Distributed Cloud Connected verwendet Linux Unified Key Setup (LUKS), um die logischen Volumes auf jedem Distributed Cloud Connected-Knoten zu verschlüsseln. Sie haben die Möglichkeit, kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) oderGoogle-owned and managed keys zu verwenden, um den LUKS-Laufwerkverschlüsselungsschlüssel (Data Encryption Key, DEK) zu verpacken. Wenn Sie einem Knotenpool einen Knoten zuweisen, generiert der Knoten einen LUKS-DEK und umschließt ihn entweder mit einer von Google verwalteten LUKS-Passphrase, auch als Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) bezeichnet, oder mit einem von Ihnen über Cloud KMS bereitgestellten KEK. Sie können auswählen, ob Sie Cloud KMS beim Erstellen eines Knotenpools verwenden möchten. Distributed Cloud Connected lässt sich über das Modell der Umschlagverschlüsselung in Cloud KMS einbinden.

In Distributed Cloud Connected werden die LUKS- und SED-Passphrasen automatisch in regelmäßigen Abständen rotiert.

Außerdem führt jede mit Distributed Cloud verbundene Maschine bei jedem Kaltstart Folgendes aus:

  • Wenn Sie Cloud KMS nicht verwenden, generiert der Computer einen neuen KEK (LUKS-Passphrase) und richtet von Anfang an verschlüsselten Speicher ein.

  • Wenn Sie Cloud KMS verwenden, ruft der Computer den KEK aus Cloud KMS ab und entsperrt die vorhandenen logischen Volumes, die Ihre Daten enthalten.

Unterstützung für kundenverwaltete Verschlüsselungsschlüssel (CMEK) für lokalen Speicher konfigurieren

In Google Distributed Cloud Connected, Version 1.9.0 werden ruhende Kundeninhalte standardmäßig verschlüsselt. Die Verschlüsselung wird von Distributed Cloud Connected übernommen. Weitere Maßnahmen Ihrerseits sind nicht erforderlich. Diese Option heißt Google-Standardverschlüsselung.

Wenn Sie Ihre Verschlüsselungsschlüssel selbst verwalten möchten, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEKs, Customer-Managed Encryption Keys) in Cloud KMS mit CMEK-integrierten Diensten wie Distributed Cloud Connected verwenden. Mit Cloud KMS-Schlüsseln haben Sie die Kontrolle über Schutzlevel, Speicherort, Rotationszeitplan, Nutzungs- und Zugriffsberechtigungen sowie über kryptografische Grenzen. Mit Cloud KMS können Sie außerdem Audit-Logs aufrufen und den Lebenszyklus von Schlüsseln steuern. Statt es Google zu überlassen, die symmetrischen Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs) zum Schutz Ihrer Daten zu besitzen und zu verwalten, können Sie diese auch über Cloud KMS steuern und verwalten.

Nachdem Sie Ihre Ressourcen mit CMEKs eingerichtet haben, ähnelt der Zugriff auf Ihre Distributed Cloud Connected-Ressourcen der Verwendung der Google-Standardverschlüsselung. Weitere Informationen zu Ihren Verschlüsselungsoptionen finden Sie unter Kundenverwaltete Verschlüsselungsschlüssel (CMEK).

So aktivieren Sie die Cloud KMS-Integration mit Distributed Cloud Connected:

  1. Erstellen Sie einen Schlüsselbund, einen symmetrischen Schlüssel und eine oder mehrere Schlüsselversionen, die mit Distributed Cloud Connected verwendet werden sollen. Sie müssen diese Artefakte in derselben Google Cloud Region wie Ihre mit Distributed Cloud verbundene Installation erstellen. Eine Anleitung finden Sie unter Schlüssel erstellen.

  2. Weisen Sie dem Dienstkonto für Distributed Cloud Connected in IhremGoogle Cloud -Projekt die Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler-Rolle (roles/cloudkms.cryptoKeyEncrypterDecrypter) zu. Sie müssen dies für jede Schlüsselversion tun, die Sie mit Distributed Cloud Connect verwenden möchten. Wenn Sie diese Rolle widerrufen, nachdem Sie Ihre mit Distributed Cloud verbundene Installation in Cloud KMS eingebunden haben, verlieren Sie den Zugriff auf Daten, die auf den mit Distributed Cloud verbundenen Maschinen gespeichert sind.

  3. Erstellen Sie einen Knotenpool mit dem Flag --local-disk-kms-key und geben Sie den vollständigen Pfad zur Schlüsselversion an, die Sie mit diesem Knotenpool verwenden möchten.

  4. Erstellen Sie einen Cluster mit dem Flag --control-plane-kms-key und geben Sie den vollständigen Pfad zur Schlüsselversion an, die Sie mit dem Knoten verwenden möchten, auf dem die Steuerungsebene des Clusters ausgeführt wird.

  5. Optional können Sie beim Erstellen des Clusters das Flag --offline-reboot-ttl verwenden, um ein Zeitfenster anzugeben, in dem neu gestartete Knoten dem Cluster wieder beitreten können, während der Cluster im Survivability-Modus ausgeführt wird. Wenn Sie dieses Zeitfenster nicht angeben, können neu gestartete Knoten dem Cluster erst wieder beitreten, wenn der Survivability-Modus beendet wird.

    ACHTUNG: Wenn Sie ein Zeitüberschreitungsfenster für den Neustart angeben, können Knoten, die offline gegangen sind, neu starten und dem Cluster wieder beitreten, auch wenn Sie den Speicherschlüssel für die angegebene Zeit deaktivieren oder löschen.

Wenn Sie für einen Cluster oder Knotenpool wieder eine Google-owned and Google-managed encryption keyverwenden möchten, verwenden Sie das Flag --use-google-managed-key, wie in einem der folgenden Abschnitte beschrieben:

Weitere Informationen finden Sie in der Cloud KMS-Dokumentation unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

Datenwiederherstellung und ‑sicherungen

Sie sind dafür verantwortlich, funktionierende redundante Sicherungen aller Daten zu erstellen, die Sie auf mit Distributed Cloud verbundener Hardware speichern, und diese Daten zu exportieren, wenn Sie die mit Distributed Cloud verbundene Hardware an Google oder den von Google zertifizierten Systemintegrator (SI) zurückgeben, der Ihnen die Hardware verkauft hat.

Wenn ein Fehler bei der mit Distributed Cloud verbundenen Hardware auftritt und Google oder ein von Google zertifizierter SI Reparaturen vor Ort durchführt, werden alle Speichermedien von der mit Distributed Cloud verbundenen Maschine entfernt, die gewartet wird. Sie werden entweder für die Dauer der Reparatur in Ihre Obhut gegeben oder sicher gelöscht und dann zur Vernichtung gesendet.

Wenn Sie die Distributed Cloud-Hardware von einem von Google zertifizierten SI erworben haben und Distributed Cloud nicht mehr verwenden, die Hardware aber behalten und für andere Zwecke nutzen möchten, löscht das SI bei der Außerbetriebnahme alle Google-Software und Ihre Daten von der Distributed Cloud-Hardware.

Netzwerksicherheit

Der Netzwerkverkehr zwischen der mit Distributed Cloud verbundenen Hardware und Google Cloudwird entweder mit MASQUE-Tunneln oder mit TLS verschlüsselt, wobei Zertifikate pro Maschine verwendet werden. In Distributed Cloud Connected werden diese Zertifikate automatisch in regelmäßigen Abständen rotiert.

Die Schritte, die zum Sichern des Netzwerk-Traffics erforderlich sind, der in Ihre mit Distributed Cloud verbundene Installation ein- und ausgeht, hängen von Ihren geschäftlichen Anforderungen und der Netzwerksicherheitsrichtlinie Ihrer Organisation ab. Außerdem empfehlen wir Folgendes:

  • Lassen Sie nur eingehende Verbindungen zu virtuellen IP-Adresspools zu, die vom integrierten Load Balancer von Distributed Cloud Connect und von Distributed Cloud-Subnetzwerken bereitgestellt werden.

  • Eingehende Verbindungen von externen Netzwerkressourcen zu Subnetzwerken, die die Ebenen Systemverwaltung und Dienstverwaltung bedienen, sind nicht zulässig.

  • Eingehende Verbindungen von externen Netzwerkressourcen zu IP-Adressen lokaler Endpunkte der Steuerungsebene nicht zulassen. Weitere Informationen finden Sie unter Überlebensmodus.

Weitere Informationen zum Vorbereiten Ihres lokalen Netzwerks für die Verbindung von Distributed Cloud-Hardware finden Sie unter Netzwerk.

Bei Bereitstellungen mit mehreren Racks unterstützt Distributed Cloud Connected die Media Access Control (MAC) Security (L2 MACsec) auf Layer 2 auf Ethernet-Frame-Ebene zwischen den Aggregatorswitches in Ihrem Basis-Rack und den ToR-Switches in Ihren Standalone-Racks.

Sie müssen diese Funktion bei der Bestellung Ihrer mit Distributed Cloud verbundenen Hardware anfordern. Sie kann nicht aktiviert werden, nachdem Distributed Cloud Connected in Ihren Räumlichkeiten bereitgestellt wurde.

Distributed Cloud Connected verwendet MACsec, um Ethernet-Geräte zu authentifizieren, die Integrität jedes übertragenen Ethernet-Frames zu prüfen und jeden übertragenen Frame zu verschlüsseln.

Dazu müssen Schlüssel eingerichtet werden, die zwischen allen an einer Ethernet-Übertragungssitzung beteiligten Geräten überprüft werden, bevor Ethernet-Traffic fließen darf. Sobald die Schlüsselvereinbarung überprüft wurde, beginnt der Absender, jedes übertragene Ethernet-Frame mit Sicherheitstags und Integritätsprüfwerten zu versehen, die der Empfänger beim Empfang jedes Frames überprüft.

Jedes MACsec-konfigurierte Gerät muss von einer Connectivity Association (CA) authentifiziert und mit ihr verknüpft werden. CA-Mitglieder verwenden langlebige CA-Schlüssel (CAKs), um sich im Netzwerk zu identifizieren. Der CAK wird verwendet, um Sitzungsverschlüsselungsschlüssel zu generieren, wenn ein CA-Mitglied Daten mit einem anderen CA-Mitglied im Netzwerk austauschen muss.

MACsec-Richtlinien für Distributed Cloud Connected

Distributed Cloud Connected erzwingt die folgenden MACsec-Richtlinien für alle Ethernet-Verbindungen zwischen Aggregatorswitches des Basis-Racks und eigenständigen ToR-Switches des Racks. Diese Richtlinien können nicht geändert oder deaktiviert werden.

MACsec-Konfiguration

Die gesamte MACsec-Konfiguration für Distributed Cloud, einschließlich der Verschlüsselungsschlüssel, wird von Google verwaltet.

Bei Distributed Cloud Connected sind unverschlüsselte Pakete auf allen internen Ethernet-Verbindungen nicht zulässig. Wenn eine MACsec-Sitzung nicht erfolgreich ausgehandelt werden kann, wird die betroffene Ethernet-Verbindung automatisch getrennt.

MACsec-Schlüsselbund

Ein MACsec-Schlüsselbund ist der Schlüsselspeicher, der alle erforderlichen Schlüssel für eine bestimmte Ethernet-Verbindung enthält. Für eine Bundle-Schnittstelle wird ein eindeutiger Schlüsselbund erstellt. Jeder Schlüsselbund enthält vier primäre Schlüssel und einen Fallback-Schlüssel. Jeder Primärschlüssel hat eine Gültigkeit von 25 %.

MACsec-Fallback

Distributed Cloud Connected konfiguriert zusätzlich zu den vier primären Schlüsseln für jede interne Ethernet-Verbindung einen MACsec-Fallback-Schlüssel. Wenn Distributed Cloud Connected keine MACsec-Sitzung mit den Primärschlüsseln aushandeln kann, wird versucht, eine Fallbacksitzung mit dem Fallbackschlüssel auszuhandeln. Der Fallback-Schlüssel läuft nicht ab.

MACsec-Schlüsselrotation

Die primären MACsec-Schlüssel von Distributed Cloud Connected-Aggregatoren und ToR-Switches werden sofort rotiert, wenn sie ablaufen. Damit die Schlüsselrotation sicher abläuft, haben jeder vorherige und nächste Schlüssel in der Rotation eine Überschneidung von 5 Tagen.

MACsec-Schlüssel für sichere Verknüpfung

Distributed Cloud Connected verwendet einen zufällig generierten MACsec Secure Association Key (SAK), um alle Ethernet-Frames zu verschlüsseln, die über interne Ethernet-Verbindungen übertragen werden. Bei Distributed Cloud Connected wird die Schlüsselneuverhandlung volumebasiert mit Extended Packet Numbering (XPN) durchgeführt. Der SAK wird alle 6 Stunden neu generiert.

Verwenden Sie den folgenden Befehl, um den MACsec-Status einer bestimmten Ethernet-Verbindung zwischen einem Aggregatorswitch im Basis-Rack und einem ToR-Switch in einem Standalone-Rack zu prüfen:

gcloud edge-cloud networking networks get-status default --location=REGION --zone=us-ZONE_NAME

Ersetzen Sie Folgendes:

  • REGION: die Google Cloud -Region, in der das ZielprojektGoogle Cloud erstellt wurde.
  • ZONE_NAME: Der Name der Zielzone, die mit Distributed Cloud verbunden ist.

Der Befehl gibt eine Ausgabe ähnlich der folgenden zurück:

result:
  macsecStatusInternalLinks: SECURE

Mögliche Werte für den Verknüpfungsstatus:

  • SECURE: Die MACsec-Sitzung ist für den Ziellink aktiv.
  • UNSECURE: Die MACsec-Sitzung ist für den Ziellink nicht verfügbar.

Nächste Schritte