このドキュメントでは、Memorystore for Redis Cluster のクラスタで Cloud Key Management Service（Cloud KMS）の顧客管理の暗号鍵（CMEK）を使用する方法について説明します。また、永続ストレージに保存されるデータと、鍵のライフサイクル イベント中のクラスタの動作についても説明します。
CMEK を使用すると、保存データを保護する暗号鍵を制御できます。Cloud KMS で独自の鍵を管理することで、鍵のアクセス、ローテーション、使用をより細かく制御できるため、厳格なコンプライアンス要件と規制要件を満たすことができます。
CMEK を実装すると、バックアップや永続ファイルなどの永続データに対するセキュリティと制御が強化されます。CMEK は新しいクラスタでのみ有効にできます。既存のクラスタに CMEK を適用することはできません。
CMEK を使用すべきユーザー
CMEK は、機密データや規制対象データを保管し、独自の暗号鍵を管理する必要がある組織を対象としています。このデータの暗号化に CMEK を使用するかどうかについては、 CMEK を使用するかどうかを決定するをご覧ください。
顧客管理の暗号化
CMEK を使用すると、暗号鍵を使用してクラスタ内の保存データを保護できます。このデータを暗号化するために、Memorystore for Redis Cluster は Google が管理するデータ暗号鍵（DEK）と顧客管理の鍵暗号鍵（KEK）を使用します。
次のレベルの暗号化が可能です。
- DEK 暗号化: DEK は Memorystore for Redis Cluster のデータを暗号化します。
- KEK 暗号化: KEK は DEK を暗号化します。
Memorystore for Redis Cluster は KEK を使用して DEK を暗号化し、DEK を使用して保存データを暗号化します。CMEK を使用すると、クラスタ内の DEK を暗号化する KEK を管理できます。
次の図は、クラスタが CMEK を使用してデータを暗号化する方法を示しています。Google のストレージ インフラストラクチャにアップロードされたデータはチャンク化され、各チャンクは独自の DEK で暗号化されます。Cloud KMS は DEK を暗号化する KEK を提供し、Google のストレージ インフラストラクチャは暗号化されたデータチャンクと暗号化された DEK の両方をシステム全体に分散します。
次の図は、Memorystore for Redis Cluster が CMEK で暗号化されたデータを復号する方法を示しています。この暗号化されたデータにアクセスするために、Memorystore for Redis Cluster は KEK を管理する Cloud KMS にリクエストを送信して DEK を復号します。Cloud KMS は復号された DEK を返し、クラスタはこれを使用して保存データを復号します。
CMEK を使用して暗号化されるデータ
CMEK は、永続ストレージに保存されている次のタイプの顧客データを暗号化します。
- バックアップ: バックアップを使用すると、 データを特定の時点に復元し、データをエクスポートして分析できます。バックアップは、障害復旧、データ移行、データ共有、コンプライアンスのシナリオにも役立ちます。
- 永続性:
Memorystore for Redis Cluster は、次の 2 種類の永続性をサポートしています:
- RDB 永続性: Redis データベース（RDB）機能は、耐久性の高いストレージにデータのスナップショットを保存することでデータを保護します。
- AOF 永続性: この機能は、データの耐久性を優先します。すべての書き込みコマンドを Append-Only File（AOF）と呼ばれるログファイルに記録することで、データを耐久的に保存します。システム障害または再起動が発生した場合、サーバーは AOF ファイル コマンドを順番に再生してデータを復元します。
CMEK コンポーネント
以降のセクションでは、CMEK アーキテクチャを構成するサービス アカウント、暗号鍵、鍵バージョン、組織ポリシーの要件と動作について説明します。
サービス アカウント
CMEK 対応クラスタを作成するには、次の形式を使用する Memorystore for Redis Cluster サービス アカウントに roles/cloudkms.cryptoKeyEncrypterDecrypter ロールを付与する必要があります。
service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com
この権限を付与することで、サービス アカウントは Cloud KMS から鍵のアクセスをリクエストできるようになります。
キー
Cloud KMS でキーリングを作成し、対称暗号化アルゴリズムを使用する暗号鍵を作成する必要があります。クラスタを作成するときに、この鍵を選択してクラスタを暗号化します。鍵とクラスタの両方に 1 つのプロジェクトを作成することも、それぞれに異なるプロジェクトを作成することもできます。
CMEK はすべてのクラスタ ロケーションで使用できます。キーリングと鍵は、クラスタを作成するリージョンと同じリージョンに作成する必要があります。マルチリージョン クラスタの場合は、キーリングと鍵をクラスタと同じロケーションに設定する必要があります。 リージョンまたはロケーションが一致しない場合、クラスタの作成リクエストは失敗します。
鍵のリソース ID には、CMEK は次の形式を使用します。
projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME
既存の鍵のリソース ID を確認する方法については、 Cloud KMS リソース ID の取得をご覧ください。
外部鍵
CMEK 戦略の一環として、外部鍵を使用できます。これを行うには、 Cloud External Key Manager（Cloud EKM）を使用して、 Google Cloud 管理対象の外部鍵を使用して 内のデータを暗号化します。
Cloud EKM 鍵を使用する場合、Google は外部管理鍵の可用性をコントロールできません。クラスタの作成時に鍵が使用できない場合、Memorystore for Redis Cluster はクラスタを作成しません。
鍵バージョン
Cloud KMS は、データの暗号化と復号に使用する暗号鍵マテリアルを鍵バージョンに保存します。1 つの鍵に複数の鍵バージョンを含めることができます。鍵をローテーションするたびに、鍵バージョンが作成されます。
以降のセクションでは、鍵バージョンの無効化、破棄、ローテーション、有効化、復元など、鍵のライフサイクル イベント中にクラスタとその保護データがどのように動作するかについて説明します。また、Cloud KMS 鍵へのアクセス権を取り消したり、Cloud KMS 鍵を置き換えたりした場合の影響についても説明し、データを手動で再暗号化する方法についても説明します。
CMEK 鍵バージョンの無効化または破棄
データ漏洩の修復など、CMEK で暗号化されたデータに永続的にアクセスできないようにする必要が生じることも考えられます。この高保証のデータ破棄（暗号シュレッディングとも呼ばれます）を実現するには、鍵バージョンを破棄します。 鍵バージョンの破棄の詳細については、 鍵バージョンの破棄と復元をご覧ください。
メインの鍵バージョンを無効または破棄すると、バックアップと永続性に次の条件が適用されます。
バックアップ
メインの鍵バージョンを破棄すると、クラスタのバックアップに次の制限が適用されます。
- オンデマンド バックアップまたは自動バックアップを作成できません。ただし、古い鍵バージョンを有効にすると、この鍵バージョンを使用して作成したバックアップにアクセスできます。
- メインの鍵バージョンを有効または復元するまで、自動バックアップを更新または再有効化することはできません。詳細については、メインの CMEK 鍵バージョンを有効にするか復元するをご覧ください。
永続性
メインの鍵バージョンを破棄すると、クラスタの永続性に次の制限が適用されます。
- 永続性を使用するようにクラスタを構成すると、鍵バージョンが使用できなくなったときに、Memorystore for Redis Cluster は永続性を無効にします。永続性の使用に対して課金されなくなります。
- Memorystore for Redis Cluster は、CMEK を使用して新しいデータを永続ストレージにフラッシュしません。
- Memorystore for Redis Cluster は、永続ストレージに存在する既存のデータを読み取ることができません。
- メインの鍵バージョンを有効または復元するまで、永続性を更新または再有効化することはできません。
メインの鍵バージョンを有効にしても、古い鍵バージョンを無効または破棄すると、バックアップと永続性に次の条件が適用されます。
- バックアップを作成できます。ただし、無効または破棄された古い鍵バージョンでバックアップが暗号化されている場合、バックアップにはアクセスできません。
- 永続性を有効にすると、有効なままになります。永続性で使用されている古い鍵バージョンが無効または破棄されると、Memorystore for Redis Cluster はメンテナンスで使用されるものと同様の更新を実行し、メインの鍵バージョンでデータを再暗号化します。
Cloud KMS 鍵へのアクセス権を取り消す
鍵を無効にするか、鍵の IAM 権限を削除して、有効な Cloud KMS 鍵へのアクセス権を取り消すと、Memorystore for Redis Cluster はプライマリ キャッシュの可用性を優先します。 通常のインメモリ キャッシュ オペレーションは引き続きトラフィックを処理します。
ただし、バックアップと永続性は無効になります。Memorystore for Redis Cluster は、ディスクへの新しいデータの書き込みを直ちに停止し、顧客が暗号化したディスクからメモリにデータを読み取りません。
メインの CMEK 鍵バージョンをローテーションする
メインの鍵バージョンをローテーションして新しいメインの鍵バージョンを作成すると、バックアップと永続性に次の条件が適用されます。
- CMEK の最新のメインの鍵バージョンで新しいバックアップが暗号化されます。
- 既存のバックアップは再暗号化されません。
- 永続性の場合、ノードは何も行いません。ノードは、次のメンテナンス イベントまで古い鍵バージョンを引き続き使用します。
CMEK で保護されたデータを手動で再暗号化する
Memorystore for Redis Cluster は、保存データのオンデマンド再暗号化をサポートしていません。 新しい鍵バージョンを使用して、既存のバックアップまたはアクティブな永続ファイルを再暗号化するプロセスを手動でトリガーすることはできません。ただし、新しい鍵バージョンを使用して、新しく書き込まれたデータを暗号化できます。
鍵をローテーションし、クラスタで新しい鍵バージョンを強制的に使用する必要がある場合、バックアップと永続性に次の条件が適用されます。
バックアップ
既存のバックアップを再暗号化することはできません。コンプライアンスにより、すべてのデータを最新の鍵で暗号化する必要がある場合は、この鍵を使用してバックアップを作成し、既存のバックアップを手動で削除します。このバックアップを Cloud Storage バケットにエクスポートして、Cloud Storage 暗号鍵を使用することもできます。
永続性
クラスタで新しい Cloud KMS 鍵を強制的に使用するには、クラスタでシミュレートされたメンテナンスを実行します。このオペレーションが完了すると、Memorystore for Redis Cluster は更新されたメインの鍵バージョンを使用して永続データを書き込むことができます。
保護された Cloud KMS 鍵を置き換える
保護された Cloud KMS 鍵を別の鍵または新しいメインの鍵バージョンに置き換えると、Memorystore for Redis Cluster はこの変更を今後のオペレーションにのみ適用します。
保護された鍵を置き換えると、リソースに次のような影響があります。
- バックアップ: 後続のすべてのバックアップは、新しい鍵を使用して暗号化されます。 既存のバックアップは元の鍵を維持します。
- 永続性: 次回クラスタが再起動するか、メンテナンス イベントが発生したときに、新しい鍵が使用されます。
- プライマリ キャッシュ: この鍵を置き換えても影響はありません。CMEK は、インメモリ データが保存データと見なされないため、インメモリ データを暗号化しません。
メインの CMEK 鍵バージョンを有効にするか復元する
メインの鍵バージョンを有効または復元すると、バックアップと永続性に次の条件が適用されます。
- オンデマンド バックアップと自動バックアップを再度作成できます。
- Memorystore for Redis Cluster は、メンテナンスで使用されるものと同様の更新を実行し、永続性を再度有効にします。
組織ポリシーの制約
Memorystore for Redis Cluster は、CMEK の組織ポリシーの制約をサポートしています。これらの制約を使用すると、クラスタに CMEK 保護を適用し、この保護に使用できる Cloud KMS 鍵を制限できます。
次の組織ポリシーの制約を構成できます。
constraints/gcp.restrictNonCmekServices: この制約を使用して、クラスタに CMEK 保護を適用します。Memorystore for Redis Cluster API がこの制約のサービスのDenyポリシーリストにある場合、CMEK で保護されていないクラスタを作成することはできません。constraints/gcp.restrictCmekCryptoKeyProjects: この制約を使用して、CMEK 保護に使用できる Cloud KMS 鍵を制限します。この制約を構成すると、CMEK 暗号化を使用するクラスタは、許可されたプロジェクト、フォルダ、または組織の鍵を使用する必要があります。
Memorystore for Redis Cluster と Memorystore for Redis
は同じエンドポイント（redis.googleapis.com）を共有しているため、Memorystore for Redis インスタンスとは別に
クラスタに CMEK を適用することはできません。
Google が Memorystore for Redis Cluster 用に管理する CMEK 関連の組織ポリシーの制約の詳細については、組織ポリシーの制約をご覧ください。
料金
Memorystore for Redis Cluster では、CMEK を有効にしたクラスタに対して他のクラスタと同様に課金されます。追加料金は発生しません。詳細については、 Memorystore for Redis Cluster の料金をご覧ください。
Cloud KMS API を使用して CMEK を管理します。 CMEK を使用してクラスタを作成すると、Memorystore は鍵を定期的に使用してデータを暗号化します。
Memorystore for Redis Cluster が鍵を使用すると、Cloud KMS から鍵の費用と暗号化 / 復号オペレーションの費用が請求されます。詳細については、Cloud KMS の料金をご覧ください。
制限事項
Memorystore for Redis Cluster で CMEK を使用する場合、次の制限が適用されます。
- 既存のクラスタで CMEK を有効にすることはできません。
- 鍵、キーリング、クラスタは同じリージョンに配置する必要があります。
- 鍵には対称暗号化アルゴリズムを使用する必要があります。
- Cloud KMS の暗号化と復号の割合は、割り当ての対象になります。
次のステップ
- CMEK の詳細を見る。
- CMEK を使用してデータ セキュリティを強化する方法を確認する。
- バックアップについての詳細を学習する。
- 永続性の詳細を学習する。