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 des Distributed Cloud-Racks verantwortlich, z. B. für die Beschränkung des Zugriffs auf autorisiertes Personal. Das Distributed Cloud-Rack selbst hat 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.
Wenn Sie weitere Fragen zur Sicherheit des physischen Racks haben, wenden Sie sich an Ihren Google Cloud Kundenbetreuer.
Sicherheit des lokalen Speichers
In Distributed Cloud wird Linux Unified Key Setup (LUKS) verwendet, um die logischen Volumes auf jedem Distributed Cloud-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 wird in Cloud KMS eingebunden, indem das Modell der Umschlagverschlüsselung verwendet wird.
Außerdem führt jeder Distributed Cloud-Computer 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 (Customer-Managed Encryption Keys, CMEK) für lokalen Speicher aktivieren
So aktivieren Sie die Cloud KMS-Integration in Distributed Cloud:
Erstellen Sie einen Schlüsselbund, einen symmetrischen Schlüssel und eine oder mehrere Schlüsselversionen, die Sie mit Distributed Cloud verwenden können. Sie müssen diese Artefakte in derselben Google Cloud Region wie Ihre Distributed Cloud-Installation erstellen. Eine Anleitung finden Sie unter Schlüssel erstellen.
Weisen Sie dem Distributed Cloud-Dienstkonto 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 verwenden möchten. Wenn Sie diese Rolle widerrufen, nachdem Sie Ihre Distributed Cloud-Installation in Cloud KMS eingebunden haben, verlieren Sie den Zugriff auf Daten, die auf den Distributed Cloud-Maschinen gespeichert sind.Erstellen Sie einen Knotenpool mit dem Flag
--local-disk-kms-keyund geben Sie den vollständigen Pfad zur Schlüsselversion an, die Sie mit diesem Knotenpool verwenden möchten.Erstellen Sie einen Cluster mit dem Flag
--control-plane-kms-keyund 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.
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 Distributed Cloud-Hardware speichern, und diese Daten zu exportieren, wenn Sie die Distributed Cloud-Hardware an Google zurückgeben.
Alle Daten, die sich noch auf der Distributed Cloud-Hardware befinden, wenn sie an Google zurückgegeben wird, werden gelöscht. Wenn ein Fehler bei der Distributed Cloud-Hardware auftritt und Google Reparaturen vor Ort durchführt, werden alle Speichermedien aus dem Distributed Cloud-Computer, der gewartet wird, entfernt und für die Dauer der Reparatur in Ihre Obhut gegeben.
Netzwerksicherheit
Die Schritte, die zum Sichern des Netzwerk-Traffics erforderlich sind, der in Ihre Distributed Cloud-Installation ein- und ausgeht, werden durch Ihre geschäftlichen Anforderungen und die Netzwerksicherheitsrichtlinie Ihrer Organisation bestimmt. Außerdem empfehlen wir Folgendes:
Lassen Sie nur eingehende Verbindungen zu virtuellen IP-Adresspools zu, die vom integrierten Load Balancer von Distributed Cloud 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.