このページでは、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 容量を変更できます。
新しいパーティション セグメント ファイルはすべて、新しいメインの鍵バージョンを使用して階層型ストレージに書き込まれます。新しい主キー バージョンが選択された後、数分遅延することがあります。
監査ログ
鍵の有効化または無効化を行うと、Cloud KMS により監査ログが生成されます。このログは、メッセージの暗号化または復号で Managed Service for Apache Kafka が鍵を使用したときにも生成されます。これは、パブリッシュまたは配信の利用可能性に関する問題のデバッグに役立ちます。
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）から暗号鍵の暗号化/復号のロールを取り消します。このアプローチは、プロジェクト内のすべての 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 の暗号化の詳細については、顧客管理の暗号鍵をご覧ください。