ログバケットの CMEK を構成する

このドキュメントでは、ログバケットに保存されているログに顧客管理の暗号鍵（CMEK）を構成する手順について説明します。このドキュメントでは、これらの鍵の管理方法と、CMEK の使用に関連する制限事項についても説明します。

CMEK は、組織またはフォルダのデフォルトのリソース設定として構成できます。構成すると、Cloud Logging は、組織またはフォルダ内のすべての新しいログバケットをカスタマー マネージド キーで暗号化します。ログバケットの作成時に鍵を指定しない場合、デフォルトの鍵が使用されます。詳細については、Cloud Logging の CMEK を構成するをご覧ください。

概要

Cloud Logging では、お客様のコンテンツを保存時に暗号化するのがデフォルトの動作です。Logging によってログバケットに保存されたデータは、暗号鍵を使用して暗号化されます。これはエンベロープ暗号化と呼ばれるプロセスです。ロギングデータにアクセスするには、これらの鍵暗号鍵にアクセスする必要があります。この鍵は Google Cloud がお客様の代わりに管理します。

お客様の組織には、デフォルトの保存時の暗号化で提供されない規制、コンプライアンス関連の暗号化、高度な暗号化要件がある場合があります。組織の要件を満たすため、データを保護する暗号鍵を Google Cloud が管理するのではなく、お客様が鍵を管理できます。

CMEK の使用状況に関する具体的な情報（利点や制限など）については、顧客管理の暗号鍵をご覧ください。

対称暗号化では、セキュリティのために、定期的に自動で鍵をローテーションすることをおすすめします。詳細については、鍵のローテーションをご覧ください。

注: ログバケットを作成した後で、ログバケットを再構成して CMEK を変更または削除することはできません。

前提条件

次の手順を行います。

1. CMEK を使用する場合、いくつかの制限事項があります。CMEK を有効にしてログバケットを作成する前に、制限事項を確認してください。

2. In the Google Cloud console, activate Cloud Shell.

   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.

3. 鍵を作成する Google Cloud プロジェクトを構成します。

   1. 鍵の作成に必要な権限を取得するには、プロジェクトまたは親リソースの Cloud KMS 管理者（roles/cloudkms.admin）IAM ロールの付与を管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

      必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

   2. Cloud KMS API を有効化します。

   3. キーリングと鍵を作成します。

      Cloud Logging では、任意のリージョンの鍵を使用できます。ただし、ログバケットを作成するときは、ログバケットのロケーションが鍵のロケーションと一致する必要があります。サポートされているリージョンの詳細については、以下をご覧ください。

      • Cloud KMS のロケーション
      • Logging のサポートされているリージョン

      globalリージョンで作成されたログバケットに CMEK を構成することはできません。

4. ログバケットを作成する Google Cloud プロジェクトに対して、次の Cloud Logging 権限があることを確認します。

   • logging.settings.get
   • logging.buckets.get
   • logging.buckets.list
   • logging.buckets.create
   • logging.buckets.update

CMEK を有効にする

前提条件の手順を完了したら、個々のログバケットで CMEK を有効にする手順を行います。

サービス アカウント ID を特定する

CMEK が適用される Google Cloud リソースに関連付けられているサービス アカウント ID を特定するには、次の操作を行います。

1. 次の gcloud logging settings describe コマンドを実行します。

   gcloud logging settings describe --project=BUCKET_PROJECT_ID
   

   前のコマンドを実行する前に、次のように置き換えます。

   • BUCKET_PROJECT_ID: ログバケットを作成する Google Cloud プロジェクトの名前。

   上記のコマンドは、指定されたリソース用のサービス アカウントがまだ存在しない場合に生成し、そのサービス アカウントの ID が kmsServiceAccountId フィールドに返されます。

   kmsServiceAccountId: [e-mail]
   loggingServiceAccountId: [e-mail]
   name: projects/BUCKET_PROJECT_ID/settings
   

   kmsServiceAccountId フィールドには、Cloud Logging が Cloud Key Management Service の呼び出しに使用するサービス アカウントが一覧表示されます。

2. KMS_SERVICE_ACCT_NAME フィールドの形式が cmek-pPROJECT_NUMBER の場合で、VPC Service Controls を使用している場合、またはドメインで制限された共有を有効にする場合、CMEK サービス アカウントを移行する必要があるかどうかを判断します。移行が必要なタイミングと移行手順については、VPC Service Controls とドメインで制限された共有のトラブルシューティングをご覧ください。

暗号化 / 復号のロールを割り当てる

ログバケット レベルで CMEK を構成する場合は、Cloud KMS CryptoKey の暗号化 / 復号 のロールを kmsServiceAccountId フィールドで識別されるサービス アカウントに割り当てることで、Cloud KMS の使用権限をサービス アカウントに付与します。

gcloud kms keys add-iam-policy-binding \
--project=KMS_PROJECT_ID \
--member serviceAccount:[e-mail] \
--role roles/cloudkms.cryptoKeyEncrypterDecrypter \
--location=KMS_KEY_LOCATION \
--keyring=KMS_KEY_RING \
KMS_KEY_NAME

次のコマンドを実行する前に、次のように置き換えます。

• KMS_PROJECT_ID: Cloud KMS を実行している Google Cloud プロジェクトの一意の英数字識別子で、Google Cloud プロジェクト名とランダムに割り当てられた番号で構成されます。この ID を取得する方法については、プロジェクトの識別をご覧ください。
• KMS_SERVICE_ACCT_NAME: gcloud logging settings describe コマンドのレスポンスの kmsServiceAccountId フィールドに表示されるサービス アカウントの名前。
• KMS_KEY_LOCATION: Cloud KMS 鍵のリージョン。
• KMS_KEY_RING: Cloud KMS キーリングの名前。
• KMS_KEY_NAME: Cloud KMS 鍵の名前。次のような形式になります。projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KMS_KEY_RING/cryptoKeys/KEY

ログバケットを作成して Cloud KMS 鍵を指定する

ログバケットを作成してログバケットで CMEK を有効にするには、次の gcloud logging buckets create コマンドを実行します。

gcloud logging buckets create BUCKET_ID \
--location=LOCATION \
--cmek-kms-key-name=KMS_KEY_NAME \
--project=BUCKET_PROJECT_ID

次のコマンドを実行する前に、次のように置き換えます。

• BUCKET_ID: ログバケットの名前または ID。
• LOCATION：ログバケットのロケーション。
• KMS_KEY_NAME: Cloud KMS 鍵の名前。次のような形式になります。projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KMS_KEY_RING/cryptoKeys/KEY
• BUCKET_PROJECT_ID: ログバケットが作成される Google Cloud プロジェクトの名前。

鍵の有効化を確認する

CMEK が有効なログバケットが正常に作成されたことを確認するには、次の gcloud logging buckets list コマンドを実行します。

gcloud logging buckets list --project=BUCKET_PROJECT_ID

前のコマンドを実行する前に、次のように置き換えます。

• BUCKET_PROJECT_ID: ログバケットを保存する Google Cloud プロジェクトの名前。

表形式の出力に、CMEK という列が表示されます。CMEK 列の値が TRUE であれば、ログバケットに対して CMEK が有効になります。

特定のログバケットの詳細（鍵の詳細を含む）を表示するには、次のコマンドを実行します。

gcloud logging buckets describe BUCKET_ID --location=LOCATION --project=BUCKET_PROJECT_ID

Cloud KMS 鍵を管理する

以降のセクションでは、Cloud KMS 鍵の最新の主キーバージョンを使用するようにログバケットを更新する方法について説明します。また、Cloud KMS 鍵の変更、アクセス権の取り消し、無効化の方法についても説明します。

注: Logging が Cloud KMS 鍵へのアクセスを失うと、データ損失やユーザーへの影響が発生します。詳細については、このページの制限事項をご覧ください。

Cloud KMS 鍵をローテーションする

注: Cloud KMS 鍵をローテーションしても、そのアクションは既存のログバケットには適用されません。つまり、鍵をローテーションしても、ログバケットがデータの保護に使用する鍵バージョンは変更されません。ログバケットで使用される鍵のバージョンを変更する方法については、Cloud KMS 鍵をローテーションするをご覧ください。

Cloud KMS 鍵を作成するときに、ローテーション期間を構成できます。Cloud KMS 鍵を手動でローテーションすることもできます。 鍵をローテーションするたびに、その鍵の新しいバージョンが作成されます。

Cloud KMS 鍵をローテーションすると、新しい鍵バージョンは鍵のローテーション後に作成されたログバケットにのみ適用されます。鍵が既存のログバケットで使用されている場合、鍵をローテーションしても、ログバケットでのデータの保護方法は変更されません。

たとえば、ログバケットを作成して CMEK を有効にし、Cloud KMS 鍵をローテーションするとします。作成したログバケットは新しい鍵バージョンを使用しません。代わりに、ログバケットの作成時にプライマリとしてマークされた鍵バージョンでデータを保護し続けます。

Cloud KMS 鍵の最新の主キーバージョンを使用するようにログバケットを更新するには、次の操作を行います。

1. ログバケットの現在の Cloud KMS 鍵を特定します。 詳細については、鍵の有効化を確認するをご覧ください。
2. 使用できる別の Cloud KMS 鍵を特定します。キーリングに鍵が 1 つしかない場合は、鍵を作成します。
3. 前の手順で作成した Cloud KMS 鍵に、ログバケットの Cloud KMS 鍵を変更します。
4. 元の Cloud KMS 鍵に、ログバケットの Cloud KMS 鍵を変更します。

Cloud KMS 鍵を変更する

ログバケットに関連付けられた Cloud KMS 鍵を変更するには、鍵を作成し、ログバケットの CMEK 設定を更新します。

gcloud logging buckets update BUCKET_ID --location=LOCATION \
--cmek-kms-key-name=NEW_KMS_KEY_NAME --project=BUCKET_PROJECT_ID

• BUCKET_ID: ログバケットの名前または ID。
• LOCATION：ログバケットのロケーション。
• NEW_KMS_KEY_NAME: 新しい鍵の名前。
• BUCKET_PROJECT_ID: ログバケットを保存する Google Cloud プロジェクトの名前。

Cloud KMS 鍵へのアクセス権を取り消す

注: Logging が Cloud KMS 鍵へのアクセスを失うと、データ損失やユーザーへの影響が発生します。詳細については、このページの制限事項をご覧ください。

Logging の Cloud KMS 鍵へのアクセス権をいつでも取り消すには、その鍵に対する構成済みサービス アカウントの IAM 権限を削除します。

Logging の鍵へのアクセス権を削除した際、変更が反映されるまで 1 時間ほどかかる場合があります。

リンクされた BigQuery データセットがある場合、BigQuery はこのアクセス権を使用して新しい BigQuery テーブルに鍵を適用することはできません。Logging にリンクされていない鍵を BigQuery テーブルで使用する場合は、BigQuery のドキュメントに従ってそうしてください。Logging の鍵へのアクセス権を取り消して、リンクされた BigQuery データセットがある場合は、同じ鍵に対する BigQuery のアクセス権を取り消すこともできます。

Logging のアクセス権を保持したまま、リンクされたデータセットの鍵への BigQuery のアクセス権を取り消すことはできません。

アクセス権の取り消しの影響の詳細については、制限事項をご覧ください。

鍵への Logging のアクセス権を削除するには、次のコマンドを実行します。

gcloud kms keys remove-iam-policy-binding \
--project=KMS_PROJECT_ID \
--member serviceAccount:[e-mail] \
--role roles/cloudkms.cryptoKeyEncrypterDecrypter \
--location=KMS_KEY_LOCATION \
--keyring=KMS_KEY_RING \
KMS_KEY_NAME

次のコマンドを実行する前に、次のように置き換えます。

• KMS_PROJECT_ID: Cloud KMS を実行している Google Cloud プロジェクトの一意の英数字識別子で、Google Cloud プロジェクト名とランダムに割り当てられた番号で構成されます。この ID を取得する方法については、プロジェクトの識別をご覧ください。
• KMS_SERVICE_ACCT_NAME: gcloud logging settings describe コマンドのレスポンスの kmsServiceAccountId フィールドに表示されるサービス アカウントの名前。
• KMS_KEY_LOCATION: Cloud KMS 鍵のリージョン。
• KMS_KEY_RING: Cloud KMS キーリングの名前。
• KMS_KEY_NAME: Cloud KMS 鍵の名前。次のような形式になります。projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KMS_KEY_RING/cryptoKeys/KEY

制限事項

既知の制限事項は次のとおりです。

CMEK では Error Reporting が無効になる

Error Reporting を使用する場合は、ログバケットで顧客管理の暗号鍵（CMEK）を有効にしないでください。 詳細については、トラブルシューティングをご覧ください。

ログバケットから CMEK を削除できない

ログバケットを再構成して、CMEK を変更または削除することはできません。

Cloud KMS 鍵が使用できないことによる縮退

Cloud KMS 鍵は、次の両方の条件が満たされている場合に、Logging で使用可能でアクセス可能とみなされます。

• その鍵が有効になっている。
• Logging サービス アカウントに、鍵の暗号化と復号の権限がある。

注: 鍵が使用できなくなった場合、Logging は直近 3 時間分のログをバッファリングします。このスライディングした 3 時間の時間枠より古いログは破棄される可能性があります。Cloud KMS 鍵は、持続するようにログエントリが書き込まれた後、48 時間で 24 時間以上連続して使用可能かつアクセス可能である必要があります。Cloud KMS 鍵が使用できず、アクセスできない場合、ログエントリがストレージに完全に保持されず、破棄される可能性があります。また、鍵のアクセスが修復されるまで、すべてのログをクエリに使用できません。

ロギングでは、すべての鍵が適切に構成され、常に使用可能であることを確認することを強くおすすめします。

障害復旧の喪失

Cloud Logging のプライマリ ストレージで重大な障害が発生した場合、Logging はロギングデータを障害復旧ファイルにミラーリングします。Google Cloud 組織などのリソースで CMEK が有効になっている場合、そのリソースに属するログは構成済みの CMEK 鍵で保護されます。CMEK 鍵にアクセスできない場合、そのリソースの障害復旧ファイルは書き込まれません。

障害復旧ファイルの損失は、通常のロギング オペレーションには影響しません。ただし、ストレージ障害が発生した場合、CMEK が正しく構成されていないリソースから Cloud Logging がログを復元できない場合があります。

サポートの制約

Cloud カスタマーケアでは、鍵が正しく構成されていないか、利用できなくなると、リソースのログを読み取ることができません。

クエリのパフォーマンスが低下する

顧客管理の暗号鍵にアクセスできない場合でも、Cloud Logging は引き続きデータを暗号化し、ログバケットにデータを保存します。ただし、Cloud Logging は、このデータに対してバックグラウンド最適化を実行できません。鍵へのアクセスが回復するとデータは利用可能になりますが、最初はデータが最適化されていない状態で保存されるため、クエリのパフォーマンスが低下する可能性があります。

Cloud EKM 鍵が使用できないことによる縮退

Cloud EKM 鍵を使用する場合、Google Cloud は外部の鍵管理パートナー システム内の外部管理鍵の可用性をコントロールできません。バケットレベルの CMEK では、外部で管理する鍵が使用できない場合、Cloud Logging はログバケットにログの保存を継続しますが、ユーザーはこれらのログにアクセスできません。

外部鍵を使用する場合の考慮事項と可能な代替手段については、Cloud External Key Manager のドキュメントをご覧ください。

リージョン

ログバケットを作成して CMEK を有効にする場合は、鍵のリージョンがデータのリージョン スコープと一致する鍵を使用する必要があります。globalリージョンで作成されたログバケットに CMEK を構成することはできません。

クライアント ライブラリの可用性

Logging のクライアント ライブラリには、CMEK を構成する方法が用意されていません。

割り当て

ロギングの使用量上限について詳しくは、割り当てと上限をご覧ください。

構成エラーのトラブルシューティング

CMEK 構成エラーのトラブルシューティングについては、CMEK と組織の設定エラーのトラブルシューティングをご覧ください。