このページでは、AlloyDB for PostgreSQL の顧客管理の暗号鍵（CMEK）について説明します。
この機能の有効にするタイミングや理由など、CMEK の一般的な詳細については、Cloud KMS のドキュメントをご覧ください。
AlloyDB で CMEK を使用する手順については、CMEK を使用するをご覧ください。
Google が管理する暗号化のセルフマネージド オプション
デフォルトでは、AlloyDB のデータを含め、 Google Cloudのすべての保存データが Google が管理するデフォルトの暗号化を使用して保護されます。 Google Cloudは、このデフォルトの暗号化をユーザーの代わりに処理し、管理します。このとき、ユーザー側での追加アクションは不要です。
データを保護する鍵について特定のコンプライアンス要件または規制要件がある場合は、代わりに CMEK を使用できます。CMEK を使用すると、Cloud Key Management Service（KMS）で制御および管理する鍵を使用して AlloyDB クラスタが保護されます。CMEK 鍵は、対称鍵または Cloud HSM 鍵にすることができます。
機能
- データアクセス制御: 管理者は、AlloyDB に保存されたデータの保護に使用する鍵のローテーション、アクセスの管理、無効化や破棄を行うことができます。
- 監査可能性: プロジェクトで Cloud KMS API の監査ロギングを有効にすると、AlloyDB により実行されたものを含む鍵に対するすべてのアクションは、Cloud Logging で記録され、表示されます。
- パフォーマンス: CMEK を使用しても、AlloyDB のパフォーマンスに変更はありません。
料金
AlloyDB では、他のクラスタと同様に CMEK 対応クラスタに対して課金されます。AlloyDB の追加料金は発生しません。詳細については、AlloyDB for PostgreSQL の料金をご覧ください。
AlloyDB が鍵を使用する場合、鍵の費用と暗号化オペレーションと復号オペレーションに対して Cloud KMS から課金されます。詳細については、Cloud Key Management Service の料金をご覧ください。
CMEK による保護対象
AlloyDB は、次の方法で Cloud KMS 鍵を使用して保存データを保護します。
- クラスタで CMEK を有効にすると、AlloyDB は鍵を使用して、ストレージ内のクラスタのすべてのデータを暗号化します。
- オンデマンド バックアップの作成時に CMEK 構成を指定すると、AlloyDB はその鍵を使用してバックアップを暗号化します。
- クラスタの継続的または自動バックアップ構成で CMEK を有効にすると、AlloyDB は鍵を使用して進行中のバックアップを暗号化します。
Google-owned and Google-managed encryption keys を使用する場合でも CMEK を使用する場合でも、AlloyDB には 3 つの暗号化レイヤがあります。
AlloyDB は、保存のために非アクティブなデータをチャンクに分割し、各チャンクを個別の暗号鍵で暗号化します。チャンクのデータを暗号化するために使用される鍵は、データ暗号鍵（DEK）と呼ばれます。
Google で使用する鍵は膨大な数にのぼり、また低レイテンシと高可用性を実現する必要があるため、AlloyDB は各 DEK を暗号化対象のデータの近くに保存します。
AlloyDB は、クラスタによって保持されている鍵暗号鍵（KEK）を使用して各 DEK を暗号化します。
最後に、AlloyDB はクラスタの Cloud Key Management Service ベースの暗号鍵（ Google-owned and Google-managed encryption keyまたは CMEK 鍵）を使用して KEK を暗号化します。
クラスタの保護に使用されている鍵のバージョンを表示することもできます。
CMEK を有効にする
AlloyDB クラスタで CMEK を使用できるようにするには、クラスタの作成時に Cloud KMS 鍵を指定する必要があります。
AlloyDB サービス エージェントに Cloud KMS CryptoKey Encrypter/Decrypter（roles/cloudkms.cryptoKeyEncrypterDecrypter）ロールを付与すると、AlloyDB はユーザーに代わって鍵にアクセスできるようになります。
詳細な手順については、CMEK を使用するをご覧ください。
鍵を管理
すべての鍵管理オペレーションに Cloud KMS を使用します。AlloyDB は、Cloud KMS に伝播されるまで、鍵の変更を検出して操作することはできません。鍵の無効化や破棄などのオペレーションでは、その伝播に最大 3 時間かかることがあります。通常、権限の変更ははるかに速く反映されます。
クラスタが作成されると、AlloyDB は約 5 分ごとに Cloud KMS を呼び出して、鍵が引き続き有効であることを確認します。
AlloyDB が Cloud KMS 鍵が無効化または破棄されたことを検出すると、クラスタのデータにアクセスできなくするオペレーションがすぐに開始されます。AlloyDB の Cloud KMS に対する呼び出しで、以前に無効にした鍵の再有効化が検出されると、アクセスが自動的に復元されます。
外部鍵を使用および管理する
Cloud KMS に存在する鍵を使用する代わりに、サポートされている外部鍵管理パートナーに存在する鍵を使用できます。これを行うには、Cloud External Key Manager（Cloud EKM）を使用して、 Google Cloudの外部にある鍵へのポインタである外部鍵を作成して管理します。詳細については、Cloud External Key Manager をご覧ください。
Cloud EKM で外部鍵を作成したら、クラスタを作成する際にその鍵の ID を指定することで、新しい AlloyDB クラスタに適用できます。この手順は、新しいクラスタに Cloud KMS 鍵を適用する場合と同じです。
Cloud EKM の一部として、Key Access Justifications を使用できます。Key Access Justifications を使用すると、各 Cloud EKM リクエストの理由を確認できます。さらに、示された理由に基づいて、リクエストを自動的に承認または拒否できます。詳細については、概要をご覧ください。
Google では、外部の鍵管理パートナー システムで鍵の可用性を制御することはできません。
鍵の使用不可
AlloyDB クラスタの暗号化に使用されている Cloud KMS 鍵を無効にすると、そのクラスタに属する AlloyDB インスタンスは 30 分以内に停止します。キーを再度有効にすると、インスタンスが再起動します。
Cloud KMS が使用できない場合のようなまれなケースで、AlloyDB が Cloud KMS から鍵のステータスを取得できないことがあります。このシナリオでは、AlloyDB は最大 30 分間、ベスト エフォート方式で完全なクラスタ オペレーションを引き続きサポートし、一時的な停止がワークロードに与える影響を最小限に抑えます。
30 分経過しても AlloyDB が Cloud KMS に接続できない場合、AlloyDB は保護対策としてクラスタをオフラインにする操作を開始します。AlloyDB クラスタのデータは、クラスタが Cloud KMS に再接続し、鍵がアクティブであるという応答が Cloud KMS から返されるまで、アクセス不能になります。
バックアップと復元
AlloyDB は、CMEK またはデフォルトの Google マネージド暗号化を使用してバックアップも保護します。バックアップが CMEK 対応の場合は、バックアップの作成時に KMS 鍵のプライマリ バージョンを使用して暗号化されます。バックアップを作成すると、KMS 鍵がローテーションされても、その鍵と鍵バージョンを変更できません。詳細については、クラスタのバックアップをご覧ください。
バックアップからクラスタを復元すると、復元されたクラスタはデフォルトで Google が管理する暗号化を使用しますが、代わりに使用する CMEK 鍵を指定できます。CMEK を有効化したバックアップを復元するには、バックアップの暗号化に使用した鍵と鍵バージョンの両方が使用できる必要があります。
ロギング
プロジェクトで Cloud KMS API の監査ロギングを有効にしている場合は、Cloud Logging で AlloyDB が Cloud KMS に送信するリクエストを監査できます。これらの Cloud KMS ログエントリは Cloud Logging に表示されます。詳細については、Cloud KMS 鍵の監査ログを表示するをご覧ください。