このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。

メッセージ暗号化の構成

このドキュメントでは、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 クイックスタートガイドをご覧ください。

CMEK の構成に必要なロールと権限

Pub/Sub は Google Cloud サービスエージェントを使用して Cloud KMS にアクセスします。サービスエージェントはプロジェクトごとに Pub/Sub によって内部的に維持され、デフォルトでは Google Cloud コンソールの [サービスアカウント] ページに表示されません。

Pub/Sub サービスエージェントの形式は service-${PROJECT_NUMBER}@gcp-sa-pubsub.s3ns-system.iam.gserviceaccount.com です。

Pub/Sub では、CMEK を使用してデータを暗号化および復号するための特定の権限が必要です。

必要なアクセス権を設定するには、次の手順を行います。

Pub/Sub サービスエージェントに Cloud KMS 暗号鍵の暗号化/復号（roles/cloudkms.cryptoKeyEncrypterDecrypter）ロールを付与します。
```
gcloud kms keys add-iam-policy-binding CLOUD_KMS_KEY_NAME \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-pubsub.s3ns-system.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 を使用してトピックを作成するには、次の操作を行います。

Google Cloud コンソールで、Pub/Sub の [トピック] ページに移動します。

トピックに移動
[トピックを作成] をクリックします。
[トピック ID] フィールドに、トピックの ID を入力します。
トピックの命名の詳細については、命名ガイドラインをご覧ください。
[暗号化] で、[Cloud KMS 鍵] をクリックします。
キータイプを選択します。注: [顧客管理の暗号鍵を選択] プルダウンが表示されない場合は、プロジェクトの Cloud KMS API を有効にしてください。
[トピックを作成] をクリックします。

gcloud

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 関連情報を含めません。

モニタリングとトラブルシューティング

鍵のアクセスに関する問題が発生すると、次のような影響があります。

メッセージ配信の遅延
パブリッシュエラー

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.s3ns-system.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 が長期にわたって使用不能になった場合は鍵の取り消しと同じ影響が及ぼされます。