Auf dieser Seite wird beschrieben, wie Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für einen Google Cloud Managed Service for Apache Kafka-Cluster konfigurieren.
Übersicht über die Nachrichtenverschlüsselung
Standardmäßig verschlüsselt Managed Service for Apache Kafka ruhende Nachrichten mit Google-owned and Google-managed encryption keys. Es ist keine zusätzliche Einrichtung erforderlich.
Wenn Sie mehr Kontrolle über die Verschlüsselungsschlüssel benötigen, die zum Schutz von Daten im Ruhezustand im Managed Service for Apache Kafka verwendet werden, können Sie beim Erstellen des Clusters einen CMEK festlegen. CMEKs sind Verschlüsselungsschlüssel, die Ihnen gehören. Sie werden im Cloud Key Management Service (Cloud KMS) verwaltet und gespeichert. Wenn Sie einen Cluster mit einem CMEK konfigurieren, verwendet der Dienst diesen Schlüssel automatisch, um alle inaktiven Clusterdaten zu verschlüsseln. Die Verwendung eines CMEK kann je nach Nutzungsmuster zusätzliche Kosten verursachen.
Ein CMEK, der einem Managed Service for Apache Kafka-Cluster zugeordnet ist, ist ein Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK). Der KEK wird zum Verschlüsseln eines Datenverschlüsselungsschlüssels (Data Encryption Key, DEK) verwendet. Der DEK wird dann verwendet, um ruhende Daten auf nichtflüchtigen Speichern, die an Broker angehängt sind, und Daten im mehrstufigen Speicher in Cloud Storage zu lesen und zu schreiben.
Da Managed Service for Apache Kafka-Ressourcen regional sind, empfehlen wir, CMEKs in derselben Region wie den Kafka-Cluster zu erstellen.
Erforderliche Rollen und Berechtigungen
Das Managed Kafka-Dienstkonto muss die Berechtigung haben, Daten mit einem CMEK zu verschlüsseln und zu entschlüsseln.
Weisen Sie dem Dienstkonto die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ (roles/cloudkms.cryptoKeyEncrypterDecrypter) für den Cloud KMS-Schlüssel zu:
gcloud kms keys add-iam-policy-binding KEY \
--keyring=KEY_RING \
--location=LOCATION \
--member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
--role=roles/cloudkms.cryptoKeyEncrypterDecrypter
Ersetzen Sie Folgendes:
KEY: der Name des Schlüssels
KEY_RING: Der Name des Schlüsselbunds, in dem sich der Schlüssel befindet.
LOCATION: der Cloud KMS-Speicherort für den Schlüsselbund.
PROJECT_NUMBER: Die Projektnummer desGoogle Cloud -Projekts, das den Managed Service for Apache Kafka-Cluster enthält.
Weitere Informationen zum Zuweisen von Rollen für einen Cloud KMS-Schlüssel finden Sie unter Rollen für eine Ressource zuweisen.
Schlüssel rotieren
Sie können den mit einem Cluster verknüpften Schlüssel nicht ändern. Stattdessen können Sie einen Schlüssel rotieren, indem Sie eine neue Schlüsselversion erstellen und sie als primäre Version für den Schlüssel festlegen.
Für die an Broker angehängten Laufwerke wird der neue KEK erst nach einem Neustart des Brokers wirksam. Sie können einen rollierenden Neustart von Brokern erzwingen, indem Sie die Kapazitätskonfiguration eines Clusters aktualisieren. Sie können beispielsweise die RAM-Menge des Clusters ändern.
Alle neuen Dateien für Partitionen werden mit der neuen Primärschlüsselversion in den mehrstufigen Speicher geschrieben. Nachdem eine neue Version des primären Schlüssels ausgewählt wurde, kann es einige Minuten dauern, bis sie aktiv ist.
Audit-Logs
Cloud KMS erstellt Audit-Logs, wenn Schlüssel aktiviert, deaktiviert oder von Managed Service for Apache Kafka zum Verschlüsseln und Entschlüsseln von Nachrichten verwendet werden. Dies ist bei Debugging-Problemen mit Veröffentlichungs- oder Lieferungsverfügbarkeit hilfreich.
Cloud KMS-Schlüssel-IDs werden Audit-Logs für Managed Service for Apache Kafka-Clusterressourcen angehängt. Managed Service for Apache Kafka enthält keine weiteren Cloud KMS-bezogenen Informationen in Audit-Logs.
CMEK deaktivieren und wieder aktivieren
Es gibt zwei Möglichkeiten, CMEK zu deaktivieren. Sie haben folgende Möglichkeiten:
Deaktivieren Sie den Cloud KMS-Schlüssel, den Sie dem Cluster zugeordnet haben. Dieser Ansatz betrifft alle Cloud-Ressourcen, die mit diesem Schlüssel verknüpft sind.
Widerrufen Sie die Rolle „CryptoKey Encrypter/Decrypter“ aus dem Dienst-Agent für Managed Service for Apache Kafka (
service-${PROJECT_NUMBER}@gcp-sa-managedkafka.iam.gserviceaccount.com) mit Identity and Access Management (IAM). Dieser Ansatz betrifft alle Managed Service for Apache Kafka-Cluster im Projekt und die Nachrichten, die mit CMEK verschlüsselt wurden.
Obwohl keiner der Vorgänge eine sofortige Zugriffssperre garantiert, werden IAM-Änderungen im Allgemeinen schneller übernommen.
Weitere Informationen finden Sie unter Konsistenz von Cloud KMS-Ressourcen und Weitergabe von Zugriffsänderungen.
Wenn Managed Service for Apache Kafka nicht auf einen Cloud KMS-Schlüssel zugreifen kann, schlägt die Veröffentlichung und Zustellung von Nachrichten mit Fehlern fehl. Wenn Sie die Zustellung und Veröffentlichung fortsetzen möchten, stellen Sie den Zugriff auf den Cloud KMS-Schlüssel wieder her.
Sobald der Cloud KMS-Schlüssel für Managed Service for Apache Kafka verfügbar ist, ist die Veröffentlichung innerhalb von 12 Stunden verfügbar und die Nachrichtenzustellung wird innerhalb von 2 Stunden fortgesetzt.
Obwohl kurzzeitige Cloud KMS-Ausfälle von weniger als einer Minute die Veröffentlichung und Bereitstellung wahrscheinlich nicht wesentlich unterbrechen, hat eine längere Nichtverfügbarkeit von Cloud KMS denselben Effekt wie die Sperrung von Schlüsseln.
Beschränkungen
Sie können den mit einem Cluster verknüpften Schlüssel nicht ändern. Stattdessen können Sie den Schlüssel rotieren, indem Sie neue Versionen erstellen.
Wenn Sie eine nicht primäre Schlüsselversion deaktivieren, funktionieren lokale Laufwerke weiterhin ohne Änderungen. Jeder Broker lädt den neuen KEK beim Neustart herunter. Cloud Storage kann jedoch nicht auf Segmentdateien für Themen zugreifen, die mit der ursprünglichen Version verschlüsselt wurden. Das kann dazu führen, dass Nachrichten aus diesen Segmentdateien nicht genutzt werden können. Möglicherweise können Sie ältere Daten nicht verwenden.
Wenn Sie die primäre Version eines Schlüssels deaktivieren, können die Broker keine neuen Segmentdateien in den mehrstufigen Speicher schreiben, was die Nutzung der lokalen Festplatte erhöht. Außerdem schlagen Broker-Neustarts fehl. Ein Neustart kann jederzeit sowohl von Ihnen proaktiv als auch durch eine vom Dienst initiierte Aktualisierung des Clusters ausgelöst werden.
Wenn Sie den Zugriff auf einen Schlüssel vom Dienstkonto des Managed Service for Apache Kafka entfernen, ist das Verhalten ähnlich wie beim Deaktivieren sowohl der primären als auch der nicht primären Schlüsselversionen.
Wenn Sie einen Schlüssel löschen, wird der Cluster zum Herunterfahren geplant und kann nicht wiederhergestellt werden.
Sie können keine erneute Verschlüsselung der gespeicherten inaktiven Daten anfordern. Der CMEK wird als KEK verwendet, für die Neuverschlüsselung sind jedoch Änderungen an den Datenverschlüsselungsschlüsseln erforderlich.
Nächste Schritte
Weitere Informationen zur Laufwerksverschlüsselung finden Sie unter Laufwerksverschlüsselung.
Weitere Informationen zur Verschlüsselung in Cloud Storage finden Sie unter Kundenverwaltete Verschlüsselungsschlüssel.