顧客管理の暗号鍵（CMEK）
デフォルトでは、Bigtable に保存されるすべてのデータは Google のデフォルトの暗号化を使用して暗号化されます。Bigtable はこの暗号化を自動的に処理および管理するので、お客様は何も行う必要はありません。
データを保護する鍵について特定のコンプライアンスや規制の要件がある場合、Bigtable に顧客管理の暗号鍵（CMEK）を使用できます。Google がデータを保護する暗号鍵を管理するのではなく、ユーザーが Cloud Key Management Service（Cloud KMS）で制御、管理する鍵を使用して、Bigtable インスタンスを保護します。
このページでは、Bigtable 用の CMEK について説明します。CMEK の一般的な用途や使用する理由などの詳細については、Cloud KMS のドキュメントをご覧ください。Bigtable で CMEK 関連のタスクを実行する手順については、CMEK を使用するをご覧ください。
機能
セキュリティ: CMEK は Google のデフォルトの暗号化と同じレベルのセキュリティを提供しますが、管理の自由度が上がります。
データアクセス管理: 管理者は、Bigtable の保存データの保護に使用される鍵をローテーション、アクセス管理、無効化 / 破棄できます。
監査可能性: CMEK 鍵についてのすべてのアクションはログに記録され、Cloud Logging で表示できます。Cloud EKM 鍵では、Key Access Justification がサポートされています。これにより、すべての鍵リクエストに [Justification] フィールドが追加されます。一部の外部鍵管理パートナーでは、この理由に基づいて、これらのリクエストを自動的に承認または拒否できます。
同等のパフォーマンス: Bigtable CMEK で保護されたインスタンスは、Google のデフォルトの暗号化を使用する Bigtable インスタンスと同等のパフォーマンスを提供します。
柔軟性: 複数のプロジェクト、インスタンス、クラスタで同じ CMEK 鍵を使用することも、ビジネスニーズに応じて別の鍵を使用することもできます。
クロスリージョン保護: CMEK は、Bigtable が使用可能な任意のリージョンにクラスタがあるインスタンスで有効にできます。各クラスタは、そのクラスタのリージョン内の CMEK 鍵によって保護されます。
料金
Cloud KMS では、鍵と、その鍵を使用して実行される暗号オペレーションの費用について課金されます。詳細については、Cloud KMS の料金をご覧ください。
Bigtable で暗号化または復号オペレーションを実行するように Cloud KMS 鍵に要求した場合、そのオペレーションに対して課金されます。各暗号化または復号のリクエストは、インスタンス内のすべてのクラスタのすべてのテーブルから送信されます。Bigtable はエンベロープ暗号化を使用するため、想定される暗号オペレーションの数が少なくなると、通常、テーブルあたりの費用は低くなります。CMEK で保護されているインスタンスに多数のテーブルを保存すると、費用が高くなります。
CMEK を有効化したインスタンスを使用するための追加の Bigtable 費用はかかりません。
CMEK による保護対象
CMEK で保護されるインスタンスでは、保存データが CMEK 鍵を使用して Bigtable により保護されます。クラスタ内のすべてのテーブルのデータが、保護の対象になります。HDD ストレージと SSD ストレージの両方で保存されているデータが保護されます。
次に挙げる一部のデータは、CMEK 鍵ではなく、Google のデフォルトの暗号化によって保護されます。
- 範囲境界をマークしてルーティングに使用される行キーの一部
- コアダンプやオペレーション ログなどのデバッグデータ
- 転送中のデータやメモリ内データ
- ガベージ コレクションに使用されるタイムスタンプ値のサブセット
Bigtable では、保存データに対してエンベロープ暗号化を使用します。CMEK 鍵は、Bigtable が使用するほかの鍵の暗号化に、鍵暗号鍵（KEK）として使用されます。CMEK 鍵をローテーションするときは、Bigtable では中間鍵を再暗号化するだけで済みます。
CMEK の有効化
端的に説明すると、Bigtable で CMEK を使用するには、次のようにします。
- インスタンスのクラスタが作成される各リージョンで CMEK 鍵を作成して構成します。
- 新しい Bigtable インスタンスを作成し、インスタンス内の各クラスタの CMEK 鍵を選択します。クラスタの CMEK 鍵は、クラスタと同じリージョンに存在する必要があります。
- 鍵ごとに鍵のローテーションをスケジュールします。
Bigtable を使用するアプリケーションでは、データの読み取り、書き込み、削除の際に、鍵や暗号化構成ファイルを指定する必要はありません。ユーザーが Bigtable サービス エージェントに Cloud KMS 暗号化/復号ロールを付与すると、Bigtable がユーザーに代わって鍵にアクセスできるようになります。
詳細な手順については、CMEK の使用をご覧ください。
Bigtable 用の CMEK を使用する場合に、次のものを使用できます。
- Google Cloud Console
- Google Cloud CLI
- Cloud Bigtable API を呼び出すすべての一般提供（GA）クライアント ライブラリ。
Cloud Bigtable Admin API に直接アクセスすることもできますが、これは API に対して CMEK の呼び出しを行う Bigtable クライアント ライブラリが使用できない場合にのみ使用することを強くおすすめします。
鍵管理
鍵管理オペレーションは、Cloud KMS を使用して実行されます。Bigtable は、Cloud KMS によって鍵の変更が伝播されるまで、その検出や、変更に対する対応ができません。鍵の無効化や破棄などのオペレーションでは、その伝播に最大 4 時間かかることがあります。通常、鍵の権限に対する変更はより早く伝播されます。
CMEK で保護されたインスタンス内に 1 つ以上のテーブルを作成すると、Bigtable は各クラスタ内の各テーブルの鍵を 5 分ごとに検証します。
Bigtable で無効化された鍵が検出されると、インスタンスのすべてのクラスタが無効化されるまで、一度に 1 つのクラスタがカスケード方式で無効化されます。最初にクラスタから鍵が無効化または破棄されたことが伝えられた後、そのインスタンスが無効化されるまで、一部のデータ リクエストは成功し、それ以外ではエラーを返す可能性があります。無効になっているクラスタに送信されるデータ オペレーションは、FAILED_PRECONDITION または NOT_FOUND のエラーを返します。
さらに、Bigtable レプリケーションには結果整合性があるため、クラスタが書き込みリクエストを認識しても、無効にする前にインスタンスの他のクラスタにレプリケーションされていない可能性があります。
1 つの鍵が無効になった後にインスタンス内のすべてのクラスタを自動的に無効にする Bigtable プロセスには、最大数時間かかることがあります。この状態を回避するには、常にインスタンスのすべての鍵を同時に無効にすることをおすすめします。
Bigtable クラスタが無効になると、次の管理オペレーションがインスタンス全体で制限されます。
- クラスタの作成
- クラスタの削除
- テーブルの作成
- 列ファミリーの変更
- テーブルの復元
従来どおり、インスタンスの削除、テーブルの削除、バックアップの削除を行うことができます。
Bigtable の Cloud KMS に対する呼び出しで、以前無効にされた鍵の再有効化が検出されると、Cloud KMS は自動的に Bigtable クラスタへのアクセスを復元します。
Cloud KMS 鍵が破棄されている場合、その鍵で暗号化されたクラスタがある Bigtable インスタンスは完全にアクセスできなくなります。
使用できない鍵のステータスの処理方法
Cloud KMS が使用できない場合のようなまれなケースで、Bigtable が Cloud KMS から鍵のステータスを取得できないことがあります。
Bigtable が Cloud KMS と最初に通信できない状態になったときに有効化された鍵で Bigtable クラスタが保護されている場合、Bigtable は、Cloud KMS 鍵から派生したキャッシュ保存された鍵を最大 1 時間使用して、ベストエフォート ベースで全インスタンス操作を引き続きサポートし、そのようなインシデントがワークロードに与える影響を最小限に抑えます。
1 時間経っても Bigtable が Cloud KMS に接続できない場合は、安全策として、インスタンスをオフラインにする操作を開始します。Bigtable インスタンスのデータは、インスタンスが Cloud KMS に再接続できて鍵がアクティブであるという応答が Cloud KMS から返されるまで、アクセス不能になります。
逆に、Bigtable が最初に Cloud KMS と通信できなくなる前に無効にされた鍵で Bigtable インスタンス内のクラスタが保護されている場合、インスタンスは、Cloud KMS に再接続できるようになり、鍵を再度有効にするまでアクセスできません。
外部の主な考慮事項
Cloud EKM を使用する場合、Google は外部の鍵管理パートナー システム内の外部管理鍵の可用性をコントロールできません。
外部管理の鍵を使用できない場合、Bigtable は、キャッシュ内の鍵バージョンを使用して最大 1 時間クラスタ オペレーションをサポートします。
1 時間経っても Bigtable が Cloud KMS に接続できない場合は、安全策として、インスタンスをオフラインにする操作を開始します。インスタンスが Cloud KMS に再度接続し、鍵がアクティブであるというレスポンスが Cloud KMS から返されるまで、Bigtable インスタンスのデータはアクセス不能になります。
複数のリージョンのクラスタを持つ Bigtable インスタンスに外部キーを使用する場合は、それらのリージョンでキーサポートされていることを確認します。詳細については、外部鍵マネージャーとリージョンをご覧ください。また、同じインスタンスで外部鍵と非外部鍵の組み合わせを使用しないでください。
Cloud Key Management Service で外部鍵を使用する方法については、Cloud External Key Manager（Cloud EKM）をご覧ください。
組織のポリシー
Bigtable では、組織全体で CMEK が使用されるように、組織のポリシーの制約がサポートされています。組織のポリシーの使用方法については、CMEK の組織のポリシーをご覧ください。
バックアップ
他のデータと同様に、バックアップが保存されているクラスタの CMEK 鍵でバックアップが保護されます。バックアップから復元された新しいテーブルは、復元するクラスタの CMEK 鍵により保護されます。CMEK がバックアップと復元オペレーションに与える影響の詳細については、バックアップをご覧ください。バックアップを作成する方法やバックアップから復元する方法については、バックアップを管理をご覧ください。
ロギング
プロジェクトで Cloud KMS API の Cloud KMS 監査ログを有効化している場合は、Bigtable が Cloud KMS に送信するリクエストを Cloud Logging で監査できます。各クラスタのテーブルごとに約 5 分間隔で、いくつかのログエントリを期待できます。
制限事項
CMEK は、クラスタレベルでのみ構成できます。バックアップ、テーブル、アプリ プロファイルで CMEK を構成することはできません。
クラスタの CMEK 鍵は、クラスタと同じリージョンに存在する必要があります。Cloud KMS キーリングを作成するときは、予定している Bigtable ゾーン構成に対応するリージョンを必ず選択してください。
Bigtable リソースの暗号化構成（インスタンス、クラスタ、テーブル、バックアップ）は不変です。
- CMEK 以外のインスタンスは、CMEK を使用するように変換できません。
- CMEK インスタンスは、Google のデフォルト暗号化を使用するように変換できません。
- CMEK 鍵で作成されたクラスタは、別の鍵を使用するように再構成できません。
連続で 30 日を超えて、ユーザーがトリガーしたアクション（鍵の無効化や破棄、暗号化 / 復号ロールの取り消しなど）の結果としてアクセスできなくなった鍵に関連付けられた CMEK で保護された Bigtable リソース（インスタンス、クラスタ、テーブル、バックアップ）は、自動的に削除されます。
無効にした CMEK 鍵を再度有効にして、その鍵で保護されている Bigtable インスタンスへのアクセスを復元すると、データがオンラインに戻るときに一部の Data API リクエストがタイムアウトする場合があります。
CMEK で保護されているインスタンスでテーブルが作成されてから最大 5 分間は、その鍵バージョンと鍵のステータスが不明として報告されることがあります。ただし、その期間中、そのテーブルに書き込まれるデータは CMEK 鍵で保護されます。
Bigtable で使用する鍵のすべてのバージョンではなく、1 つのバージョンのみを無効化または削除すると、予期しない動作が発生する可能性があります。CMEK 鍵は、常にすべてのバージョンを無効化または削除します。