このドキュメントでは、Pub/Sub に顧客管理の暗号鍵(CMEK)を構成する方法について説明します。
Pub/Sub はデフォルトでは、Google が所有する鍵と Google が管理する鍵を使用してメッセージを暗号化します。Google が管理する暗号鍵を使用するのに追加の設定は必要ありません。
CMEK について
CMEK は、ユーザーが所有し、Cloud Key Management Service(Cloud KMS)で管理および保存される暗号鍵です。Pub/Sub データの保護に使用される暗号鍵をより細かく制御する必要がある場合は、CMEK を使用できます。組織によっては、CMEK の使用を義務付けている場合もあります。
CMEK を使用すると、暗号鍵を完全に制御し、ライフサイクル、ローテーション、アクセス ポリシーを管理できます。CMEK を使用して Pub/Sub を構成すると、サービスは指定された鍵を使用してすべてのデータを自動的に暗号化します。CMEK の Cloud KMS の使用量によっては、使用パターンに応じて追加費用が発生する場合があります。
すべてのメッセージは、次の状態とレイヤで暗号化されます。
アプリケーション レイヤでは、メッセージが受信されるとすぐに Pub/Sub が受信メッセージを個別に暗号化します。今回の実装では、次の機能が追加されています。
- データセンターの内部リンクでメッセージを暗号化する
- 顧客管理の暗号鍵(CMEK)を有効にする
Pub/Sub の CMEK
Pub/Sub は、CMEK でエンベロープ暗号化パターンを使用します。 このアプローチでは、メッセージは Cloud KMS によって暗号化されません。Cloud KMS は、各トピックの Pub/Sub によって作成されたデータ暗号鍵(DEK)を暗号化するために使用されます。これらの DEK は Pub/Sub によって暗号化またはラップされた形式でのみ保存されます。DEK を保存する前に、サービスによって DEK が Cloud KMS に送信されて、トピックで指定された鍵暗号鍵(KEK)で暗号化されます。新しい DEK は、トピックごとに、約 6 時間おきに生成されます。
Pub/Sub は、サブスクリプションにメッセージをパブリッシュする前に、トピック用に生成された最新の DEK を使用してメッセージを暗号化します。Pub/Sub は、メッセージをサブスクライバーに配信する直前に復号します。
始める前に
Pub/Sub の CMEK は、Google Cloud コンソールまたは Google Cloud CLI を使用して構成できます。
次の作業を行います。
Cloud KMS API を有効化します。
Cloud KMS でキーリングと鍵を作成します。鍵とキーリングは削除できません。
これらのタスクを行う方法については、Cloud KMS クイックスタート ガイドをご覧ください。
Pub/Sub リソースはグローバルなので、CMEK 対応のトピックを構成するにはグローバルの Cloud KMS 鍵を使用することを強くおすすめします。トピックのパブリッシャーとサブスクライバーのロケーションによっては、リージョンの Cloud KMS 鍵を使用すると、リージョン間のネットワーク リンクに不必要な依存関係が発生することがあります。
CMEK の構成に必要なロールと権限
Pub/Sub は Google Cloud サービス エージェントを使用して Cloud KMS にアクセスします。サービス エージェントはプロジェクトごとに Pub/Sub によって内部的に維持され、デフォルトでは Google Cloud コンソールの [サービス アカウント] ページには表示されません。
Pub/Sub サービス エージェントの形式は service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
です。
Pub/Sub では、CMEK を使用してデータを暗号化および復号するための特定の権限が必要です。
必要なアクセス権を設定するには、次の手順を完了します。
Pub/Sub サービス エージェントに Cloud KMS CryptoKey 暗号化/復号(
roles/cloudkms.cryptoKeyEncrypterDecrypter
)のロールを付与します。gcloud kms keys add-iam-policy-binding CLOUD_KMS_KEY_NAME \ --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com \ --role=roles/cloudkms.cryptoKeyEncrypterDecrypter
次のように置き換えます。
CLOUD_KMS_KEY_NAME: Cloud KMS 鍵の名前
キーの形式は
projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY
です。たとえば、
projects/test-project/locations/us-central1/keyRings/test-keyring/cryptoKeys/test-key
です。PROJECT_NUMBER: Pub/Sub プロジェクトのプロジェクト番号。
IAM ロールの付与の詳細については、リソースに対するロールの付与をご覧ください。
CMEK を使用してトピックを構成する
トピックの CMEK は、Google Cloud コンソールまたは gcloud CLI を使用して構成できます。
Console
CMEK を使用してトピックを作成する手順は次のとおりです。
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
-
CMEK を使用してトピックを作成するには、
gcloud pubsub topics create
コマンドを実行します。gcloud pubsub topics create TOPIC_ID --topic-encryption-key=ENCRYPTION_KEY
次のように置き換えます。
-
TOPIC_ID: トピックの ID または名前。
トピックの名前を指定する方法の詳細については、 トピック、サブスクリプション、スキーマ、スナップショットの命名に関するガイドラインをご覧ください。
-
ENCRYPTION_KEY: トピックに使用する CMEK の ID。
形式は
projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY
です。
-
トピックの CMEK を更新する
Pub/Sub トピックにリンクされている CMEK は柔軟に変更できます。gcloud CLI を使用して CMEK を更新できます。ただし、この変更は過去にさかのぼって適用されることはありません。
鍵が変更される前にトピックに公開されたメッセージは、元の鍵で暗号化されたままになります。CMEK なしでトピックを作成した場合は、後で追加できます。既存のメッセージは、引き続き Google が管理するデフォルトの暗号化で保護されます。トピックの CMEK を変更しても、以前にパブリッシュされたメッセージは再暗号化されません。これらのメッセージは、元に暗号化された鍵で引き続き保護されます。
Pub/Sub には、約 5 分間持続する鍵のキャッシュ メカニズムがあります。Pub/Sub が新しい鍵バージョンを認識して使用を開始するまでに、最長でこの時間かかることがあります。
監査ログ
Cloud KMS は、鍵が有効になったとき、無効になったとき、またはメッセージの暗号化と復号のために Pub/Sub によって鍵が使用されたときに、監査ログを生成します。これは、パブリッシュまたは配信の利用可能性に関する問題のデバッグに役立ちます。
Cloud KMS 鍵は、Pub/Sub トピック リソースの監査ログに関連付けられます。Pub/Sub では他の Cloud KMS 関連情報を含めません。
料金と費用
次の Pub/Sub リクエストについては、CMEK を使用すると、Pub/Sub の料金に基づいて、Cloud KMS サービスへのアクセスに料金が発生します。
CMEK を使用する各トピックで、新しい DEK が 6 時間ごとに暗号化されて保存されます。
鍵は、6 分ごとに DEK を復号するために使用されます。復号は 3 回発生します(Pub/Sub サービスが実行されているリージョン内のゾーンごとに 1 回)。
たとえば、次のようなトピックがあるとします。
少なくとも 1 つのサブスクリプション
同じリージョンのパブリッシャーとサブスクライバーのクライアント
Cloud KMS 暗号オペレーションの数は次のように推定できます。
1 key access for ENCRYPT * (30 days / month * 24 hours / day) / 6 hours + 3 key accesses for DECRYPT * (30 days / month * 24 hours / day * 60 minutes / hour ) / 6 minutes = 21,720 Cloud KMS key access events
実際には、アクセス パターンに応じて鍵の取得頻度が増減することがあります。この数値は推定値としてのみ使用してください。
モニタリングとトラブルシューティング
鍵のアクセスに関する問題が発生すると、次のような影響があります。
メッセージ配信の遅延
パブリッシュ エラー
response_class
と response_code
でグループ化された次の指標を使用して、パブリッシュ エラーと pull リクエストのエラーをモニタリングします。
topic/send_request_count
subscription/pull_request_count
subscription/streaming_pull_response_count
StreamingPull レスポンスのエラー率は 100% です。これは、リクエストが失敗したことではなく、ストリームが終了したことを示します。 StreamingPull をモニタリングするには、FAILED_PRECONDITION
レスポンス コードを調べます。
複数の理由で、パブリッシュとメッセージ配信によって FAILED_PRECONDITION
エラーが発生する場合があります。
Cloud KMS 鍵が無効になる可能性があります。詳しくは、このページの鍵の無効化と再有効化をご覧ください。
Cloud EKM から外部管理の鍵を使用している場合は、Cloud EKM エラー リファレンスをご覧ください。
push サブスクリプションの場合、CMEK 固有の配信の問題を直接検出する方法はありません。代替方法は次のとおりです。
subscription/num_unacked_messages
を使用して push サブスクリプションのバックログのサイズと経過時間をモニタリングします。subscription/oldest_unacked_message_age
で異常な増減をモニタリングします。パブリッシュ エラーと CMEK 監査ログを使用して問題を特定します。
鍵の無効化と再有効化
Pub/Sub がメッセージ データを復号しないようにするには、次の 2 つの方法があります。
推奨: Pub/Sub を使用してトピックに関連付けられた Cloud KMS 鍵を無効にします。このアプローチは、特定の鍵に関連付けられている Pub/Sub トピックとサブスクリプションにのみ影響します。
IAM を使用して、Pub/Sub サービス アカウント(
service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com
)から Pub/Sub 暗号鍵の暗号化 / 復号のロールを取り消します。このアプローチは、プロジェクトのすべての Pub/Sub トピックと、CMEK を使用して暗号化されたメッセージを含むサブスクリプションに影響します。
いずれのオペレーションでも即時のアクセス取り消しは保証されませんが、通常は IAM の変更のほうがより速く反映されます。詳細については、Cloud KMS リソースの整合性とアクセス権の変更の伝播をご覧ください。
Pub/Sub が Cloud KMS 鍵にアクセスできない場合、StreamingPull または pull を使用したメッセージのパブリッシュと配信は、FAILED_PRECONDITION
エラーで失敗します。push エンドポイントへのメッセージ配信は停止します。配信とパブリッシュを再開するには、Cloud KMS 鍵へのアクセスを復元します。
Cloud KMS 鍵が Pub/Sub にアクセスできるようになると、パブリッシュは 12 時間以内に利用可能になり、メッセージの配信は 2 時間以内に再開します。
Cloud KMS が 1 分未満で断続的に停止しても、公開と配信が大幅に中断されることはありませんが、Cloud KMS が長期にわたって使用不能になった場合は鍵の取り消しと同じ影響が及ぼされます。