このページでは、Google Cloud Managed Service for Apache Kafka クラスタ用に顧客管理の暗号鍵（CMEK）を構成する方法について説明します。
メッセージの暗号化の概要
デフォルトでは、Managed Service for Apache Kafka は Google-owned and Google-managed encryption keysを使用して保存時のメッセージを暗号化します。特別な設定は必要ありません。
Managed Service for Apache Kafka の保存データを保護するために使用される暗号鍵をより詳細に制御する必要がある場合は、クラスタの作成時に CMEK を設定できます。CMEK はユーザーが所有する暗号鍵です。これらは Cloud Key Management Service（Cloud KMS）で管理および保存されます。CMEK を使用してクラスタを構成すると、サービスは自動的にその鍵を使用して、保存時のすべてのクラスタデータを暗号化します。CMEK を使用すると、使用パターンによっては追加費用が発生する可能性があります。
Managed Service for Apache Kafka クラスタに関連付けられた CMEK は、鍵暗号鍵（KEK）です。KEK は、データ暗号鍵（DEK）の暗号化に使用されます。DEK は、ブローカーに接続された永続ディスク上の保存データと、Cloud Storage の階層型ストレージ内のデータの読み取りと書き込みに使用されます。
Managed Service for Apache Kafka リソースはリージョン リソースであるため、Kafka クラスタと同じリージョンに CMEK を作成することをおすすめします。
必要なロールと権限
マネージド Kafka サービス アカウントには、CMEK を使用してデータを暗号化および復号する権限が必要です。
Cloud KMS 鍵に対する Cloud KMS 暗号鍵の暗号化/復号（roles/cloudkms.cryptoKeyEncrypterDecrypter）ロールをサービス アカウントに付与します。
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
次のように置き換えます。
KEY: 鍵の名前。
KEY_RING: 鍵が配置されているキーリングの名前。
LOCATION: キーリングの Cloud KMS のロケーション。
PROJECT_NUMBER: Managed Service for Apache Kafka クラスタを含むGoogle Cloud プロジェクトのプロジェクト番号。
Cloud KMS 鍵に対するロールの付与の詳細については、リソースに対するロールの付与をご覧ください。
鍵のローテーション
クラスタに関連付けられている鍵は変更できません。代わりに、新しい鍵バージョンを作成して鍵のメイン バージョンとして設定することで、鍵をローテーションできます。
ブローカーにアタッチされたディスクの場合、新しい KEK はブローカーが再起動された後にのみ有効になります。クラスタの容量構成を更新することで、ブローカーのローリング再起動を強制的に行うことができます。たとえば、クラスタの RAM 容量を変更できます。
新しいパーティション セグメント ファイルはすべて、新しい主キー バージョンを使用して階層型ストレージに書き込まれます。新しい主キー バージョンが選択された後、数分の遅延が発生する可能性があります。
監査ログ
鍵が有効になったとき、無効になったとき、またはメッセージの暗号化と復号のために Managed Service for Apache Kafka によって鍵が使用されたときに、Cloud KMS は監査ログを生成します。これは、パブリッシュまたは配信の利用可能性に関する問題のデバッグに役立ちます。
Cloud KMS 鍵 ID は、Managed Service for Apache Kafka クラスタ リソースの監査ログに関連付けられます。Managed Service for Apache Kafka では、監査ログに他の Cloud KMS 関連情報は含まれません。
CMEK を無効にしてから再度有効にする
CMEK を無効にするには、次の 2 つの方法があります。次のいずれかを行います。
クラスタに関連付けられている Cloud KMS 鍵を無効にします。このアプローチは、そのキーに関連付けられているすべての Cloud リソースに影響します。
Identity and Access Management（IAM）を使用して、Managed Service for Apache Kafka サービス エージェント（
service-${PROJECT_NUMBER}@gcp-sa-managedkafka.iam.gserviceaccount.com）からCryptoKey 暗号化/復号ロールを取り消します。このアプローチは、プロジェクト内のすべての Managed Service for Apache Kafka クラスタと、CMEK を使用して暗号化されたメッセージに影響します。
いずれのオペレーションでも即時のアクセス取り消しは保証されませんが、通常は IAM の変更のほうがより速く反映されます。
詳細については、Cloud KMS リソースの整合性とアクセス権の変更の伝播をご覧ください。
Managed Service for Apache Kafka が Cloud KMS 鍵にアクセスできない場合、メッセージのパブリッシュと配信はエラーで失敗します。配信とパブリッシュを再開するには、Cloud KMS 鍵へのアクセスを復元します。
Cloud KMS 鍵が Managed Service for Apache Kafka にアクセスできるようになると、パブリッシュは 12 時間以内に利用可能になり、メッセージの配信は 2 時間以内に再開します。
Cloud KMS が 1 分未満で断続的に停止しても、公開と配信が大幅に中断されることはありませんが、Cloud KMS が長期にわたって使用不能になった場合は鍵の取り消しと同じ影響が及ぼされます。
制限事項
クラスタに関連付けられている鍵は変更できません。代わりに、新しいバージョンを作成して鍵をローテーションできます。
非プライマリ キー バージョンを無効にしても、ローカル ディスクは変更なしで引き続き動作します。各ブローカーは、再起動時に新しい KEK をダウンロードします。ただし、Cloud Storage は元のバージョンで暗号化されたトピック セグメント ファイルにアクセスできません。そのため、これらのセグメント ファイルからメッセージを消費できない可能性があります。古いデータを使用できない場合があります。
鍵のプライマリ バージョンを無効にすると、ブローカーは新しいセグメント ファイルを階層化ストレージに書き込むことができなくなり、ローカル ディスクの使用率が増加します。また、ブローカーの再起動も失敗します。再起動は、ユーザーが事前にトリガーすることも、サービスが開始したクラスタの更新によっていつでもトリガーすることもできます。
Managed Service for Apache Kafka サービス エージェントから鍵へのアクセス権を削除すると、主キーと非主キーの両方のバージョンを無効にした場合と同様の動作になります。
鍵を削除すると、クラスタはシャットダウンがスケジュール設定され、復元できなくなります。
保存データの再暗号化をリクエストすることはできません。CMEK は KEK として使用されますが、再暗号化にはデータ暗号鍵の変更が必要です。
次のステップ
ディスク暗号化の詳細については、ディスクの暗号化についてをご覧ください。
Cloud Storage での暗号化の詳細については、顧客管理の暗号鍵をご覧ください。