Nachrichtenverschlüsselung in Managed Service for Apache Kafka konfigurieren

Auf dieser Seite wird beschrieben, wie Sie kundenverwaltete 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 ruhenden Daten in 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 in 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 von 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 zum Lesen und Schreiben von ruhenden Daten auf nichtflüchtigen Speichern verwendet, die an Broker angehängt sind, sowie von Daten im mehrstufigen Speicher in Cloud Storage.

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 zum Verschlüsseln und Entschlüsseln von Daten mit einem CMEK haben.

Weisen Sie dem Dienstkonto die Rolle „Cloud KMS Crypto Key Encrypter/Decrypter“ (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.

Bei den an Broker angehängten Laufwerken 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 Größe des Arbeitsspeichers für den Cluster ä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ärschlüssels ausgewählt wurde, kann es einige Minuten dauern, bis sie wirksam wird.

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. Das ist nützlich, um Probleme mit der Verfügbarkeit von Veröffentlichungen oder der Auslieferung zu beheben.

Cloud KMS-Schlüssel-IDs sind an Audit-Logs für Managed Service for Apache Kafka-Clusterressourcen angehängt. Managed Service for Apache Kafka enthält keine anderen 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 zugewiesen haben. Dieser Ansatz wirkt sich auf alle Cloud-Ressourcen aus, die mit diesem Schlüssel verknüpft sind.

  • Entziehen Sie dem Managed Service for Apache Kafka-Dienst-Agent (service-${PROJECT_NUMBER}@gcp-sa-managedkafka.iam.gserviceaccount.com) die Rolle „CryptoKey Encrypter/Decrypter“ mit Identity and Access Management (IAM). Dieser Ansatz betrifft alle Managed Service for Apache Kafka-Cluster im Projekt und die mit CMEK verschlüsselten Nachrichten.

Obwohl keiner der Vorgänge eine sofortige Zugriffssperre bietet, werden Änderungen am Identity and Access Management (IAM) 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 Übermittlung 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.

Nachdem der Cloud KMS-Schlüssel für Managed Service for Apache Kafka zugänglich ist, ist das Veröffentlichen innerhalb von 12 Stunden möglich und die Nachrichtenzustellung wird innerhalb von 2 Stunden fortgesetzt.

Obwohl kurzzeitige Cloud KMS-Ausfälle von weniger als einer Minute die Veröffentlichung und Zustellung wahrscheinlich nicht wesentlich unterbrechen, hat eine längere Nichtverfügbarkeit von Cloud KMS dieselbe Wirkung wie ein Schlüsselwiderruf.

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 als auch durch eine vom Dienst initiierte Aktualisierung des Clusters ausgelöst werden.

  • Wenn Sie den Zugriff auf einen Schlüssel vom Dienst-Agent des Managed Service for Apache Kafka entfernen, ist das Verhalten ähnlich wie beim Deaktivieren des Primärschlüssels und 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 im Ruhezustand gespeicherten 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

Apache Kafka® ist eine eingetragene Marke der Apache Software Foundation oder ihrer verbundenen Unternehmen in den USA und/oder anderen Ländern.