G-gen の杉村です。Google Cloud の鍵管理サービスである Cloud KMS (Cloud Key Management Service) を徹底解説します。

Cloud KMS とは

Cloud KMS は Google Cloud (旧称 GCP) の鍵管理サービスです。正式名称は Cloud Key Management Service ですが、KMS と略されることがほとんどです。

Google Cloud で秘密鍵を作成・保管・管理でき、鍵は各種 Google Cloud サービスのストレージを暗号化すること等に用いることができます。例として Cloud Storage バケットや、Compute Engine の永続ディスク、BigQuery のデータセットなどが暗号化の対象です。

Google Cloud サービスに保存されるデータはデフォルトで暗号化されており、このときは Google 側で自動的に鍵が管理・ローテーションされるため、ユーザー側で意識する必要はありません。

しかし監査上の理由や非常に強固なセキュリティが求められる場合等において、ユーザー側で独自に鍵を管理してこれを用いて暗号化したい場合があります。このときに Cloud KMS の鍵を利用することができます。

Cloud KMS には、ユーザー側で生成した鍵をアップロードして保管することもできますし、Cloud KMS で独自の鍵を生成させることもできます。さらに Cloud HSM と呼ばれるフルマネージドの HSM (Hardware Security Module) を用いて鍵の生成・ホスティングを行わせることもできます。

Cloud KMS の料金

Cloud KMS の料金は KMS が保持する鍵のバージョンの数と、鍵に対するオペレーションの回数で決まります。

例としてアクティブな対称鍵のバージョン 1 個につき、月額 $0.06 です (2022 年 10 月現在。保護レベル SOFTWARE) 。また料金は日割りされます。

オペレーションに対しては、暗号化/復号オペレーション 10,000 回につき $0.03 です。

最新の正確な料金や計算例は以下のドキュメントをご参照ください。

Cloud Key Management Service の料金

デフォルト暗号化と CMEK

デフォルトの暗号化

Cloud KMS を利用する必要があるかどうかを検討するには「デフォルトの暗号化」と「CMEK (customer-managed encryption keys)」という言葉を理解する必要があります。

まず、Google Cloud サービスのストレージは全て デフォルトの暗号化 という機能で暗号化されています。Compute Engine のディスクや Cloud Storage のバケット、BigQuery のデータセットなどは、我々が何も指定しなくても AES-256 方式で暗号化されています。暗号化鍵は Google によって管理・監査・ローテーションされています。

これによりデータはハードウェアの物理的な盗難や Google の内部犯によるアクセスなどから保護されます。またこれらの管理方式は第三者機関による監査を受けています。

つまり、何もしなくても Google Cloud のストレージ上のデータは高度なセキュリティにより保護されていることになります。

より詳細な情報は以下の公式ホワイトペーパーをご参照ください。

デフォルトの保存データの暗号化

顧客管理の鍵 (CMEK)

一方で Google Cloud サービスの中には、データをデフォルトの暗号化ではなく 顧客管理の鍵 (CMEK = customer-managed encryption keys) で暗号化するよう選択できるものもあります。Compute Engine の永続ディスクや Cloud Storage のバケット、BigQuery のデータセットなどは、リソース作成時にデフォルト暗号化か CMEK 暗号化を選択できるようになっています。

CMEK による暗号化を選択すると、Cloud KMS でユーザー自身が管理する鍵でデータを暗号化することができます。

ただし CMEK を選択することが、必ずしもセキュリティを高めることを意味するわけではありません。デフォルトの暗号化は第三者機関による監査を受けており、十分に安全です。CMEK を選択する必要があるのは、以下のような特殊なセキュリティ要件が存在しているときのみです。

暗号化鍵の存在する国等のロケーションが管理できる必要がある
鍵のローテーションや無効化などの管理がユーザー側で行う必要がある
独自の鍵管理システムで生成・管理する暗号鍵を使う必要がある

ほとんどのケースでは上記のような厳密な鍵管理は必要ありません。かなり高度なセキュリティが求めらていたり、第三者監査の要件として上記のような厳密な制御が求められる場合に、CMEK を利用します。

透過的な暗号化

デフォルトの暗号化も CMEK (customer-managed encryption keys) による暗号化も、いずれもストレージの 透過的な暗号化 です。

透過的な暗号化では、ユーザーは暗号化を意識することはありません。ユーザーの知らないところで「勝手に暗号化されている」のが透過的な暗号化です。

例えばユーザーが暗号化された Cloud Storage バケットにオブジェクトをアップロードすると、Cloud Storage のサービス側で自動的にデータが暗号化されて格納されます。データの読み取り時も同様に、ユーザーがデータにアクセスすると Cloud Storage のサービス側で自動的にデータが復号されユーザーに渡されます。

KMS の鍵は Google Cloud リソースであるため IAM 権限を適用可能ですが、透過的な暗号化においては、ユーザーは鍵へのアクセス権を必要としません。透過的なアクセスにおいて KMS 鍵へのアクセス権限が必要なのは、サービスエージェント (Google Cloud サービスがデフォルトで持つ特殊なサービスアカウント) です。

このように、透過的な暗号化はユーザーには全く意識されません (これが「透過的」の言葉の意味です) 。ここから、データの透過的暗号化はアクセス制御観点でのセキュリティの向上には寄与しないことが分かります。データの透過的暗号化が対処できる脅威はあくまで「 物理ストレージ機器の盗難 」「 内部犯によるストレージ機器への物理的アクセス 」等です。

Key と Key ring

Key (キー、鍵)

Key とは

Key (キー、鍵) はその名の通り、Cloud KMS で管理される鍵そのものです。

Key は必ず Key ring (キーリング) に所属しています。Key ring は特定のロケーション (リージョン) に所属するので、Key も必然的に特定のロケーションに存在するリソースです。

鍵は無効化したり、破棄したりすることができます。

鍵の目的

Key は作成時に目的 (Purpose) を指定します。目的は以下の 4 つから選択します。目的は一度選択すると、変更できません。

対称暗号化 (Symmetric encryption)
非対称署名 (Asymmetric signing)
非対称暗号化 (Asymmetric encryption)
MAC 署名 (MAC signing)

上記のうち 1. と 4. は 対称鍵 であり、2. と 3. は 非対称鍵 (秘密鍵と公開鍵のキーペア) です。

非対称鍵では、公開鍵のみをダウンロードすることができます。一方で対称鍵は 一切ダウンロードすることはできません 。KMS の鍵は、KMS 内部でのみ保持・管理・利用されます。

Compute Engine、Cloud Storage、BigQuery などのストレージの CMEK 暗号化に使うのは 1. 対称暗号化鍵です。

対称鍵は、いわゆる共通鍵暗号化に用いられる鍵で、生成される秘密鍵が暗号化と復号の両方に使われます。

非対称鍵は公開鍵・秘密鍵のペアで暗号化・復号を行う鍵です。公開鍵暗号化 (非対称暗号化とも) と呼ばれる手法の暗号化や、署名に用いられます。

「共通鍵暗」「公開鍵暗号」「電子署名」といったワードは Google Cloud やクラウド特有のものではなく、IT 知識として一般的なものですので、各種 Web サイトをご参照ください。

MAC 署名の鍵は HMAC 署名を行うための鍵です。HMAC は Hash Based Message Authentication Code の略でメッセージ認証符号 (MAC) の一つです。システム間メッセージの改ざん検出やなりすまり防止のために使われます。KMS の MAC 署名目的の鍵を使った署名と検証は対称鍵を用いて行われます。

Key のバージョン

Key には複数の バージョン を持たせることができます。またバージョンの一つを プライマリのバージョン (メインのバージョンとも呼称) として指定できます。

鍵の利用時に明示的に指定しない場合、プライマリのバージョンが用いられます。ただし非対称鍵にはプライマリバージョンが無く、常にバージョンを指定する必要があります。

また鍵のバージョンは「有効」「無効」「破棄の予定」「破棄」という状態を持っており、バージョンごとに無効化したり破棄したりすることができます。

保護レベル (ストレージ)

鍵は 保護レベル という属性を持ち、これにより鍵を保存するストレージが決まります。

SOFTWARE
HSM
EXTERNAL
EXTERNAL_VPC

最も使われるケースが多いのが SOFTWARE で、Google Cloud の強固なセキュリティの元に管理されます。

HSM はその名の通りフルマネージドの HSM (Hardware Security Module) によって管理されます。料金は SOFTWARE よりも割高です。

EXTERNAL と EXTERNAL_VPC は、KMS ではない外部の鍵管理システムで管理されている鍵を KMS を経由して利用するための保護レベルです。ユーザーの独自の鍵管理システムに KMS 経由でアクセスし、Google Cloud サービスのストレージ暗号化等に用いることができます。この仕組みを利用するために External key manager (EKM) という仕組みを利用します。

Key ring (キーリング)

Key ring (キーリング) はその名の通り、鍵をグルーピングするリソースです。Key ring は特定のロケーション (リージョン) に所属します。Key は作成すると存在した時間だけ料金が発生しますが Key ring には料金が発生しません。

なお「 ロケーション (リージョン) 」と表現していますが、ロケーションとリージョンは厳密には異なります。リージョンという言葉は asia-northeast1 (東京) や asia-northeast2 (大阪) など、特定のリージョンを指します。一方でロケーションという言葉は global や asia (アジア)、us (米国) といったマルチリージョン、また各リージョンの中にあるゾーンなども含めた、より広い概念です。

Key ring は作成するロケーションを指定できますが、asia-northeast1 (東京) など特定の単一リージョンを選ぶこともできますし、global や asia (アジア) などのマルチリージョンとして作成することもできます。

そして Cloud Storage バケットや Compute Engine 永続ディスクの暗号化に使える Key は、同じロケーションに存在する必要があります。asia-northeast1 (東京) のバケットであれば Key も asia-northeast1 (東京) に存在する必要がありますし、 asia マルチリージョンのバケットは asia マルチリージョンの Key でしか暗号化できません。このため、Key ring と Key を作成するロケーションは重要です。

リソースの削除

Key や Key のバージョン、また Key ring を一度作成すると 削除はできません 。

Key ring には費用が発生しないため、実質的な問題はありません。

また Key のバージョンは「破棄」することはできます。破棄したバージョンには料金が発生しません。Key のバージョンを全て削除すれば、Key に料金はかかりません。なお「無効」「破棄の予定」の状態のバージョンには料金が発生することにご注意ください。

これらのリソースは一度作成すると一意の ID が割当てられ、それが永続的に続くとお考えください。

鍵のローテーション・バージョン・状態

ローテーション

Cloud KMS では対称鍵のみ、自動ローテーションを設定できます。また、API により手動ローテーションをオンデマンド実行することも可能です。

ローテーションされると、Key の新しいバージョンが生成され、バージョン番号が 1 増えます。

自動ローテーションの頻度は Key の作成時に指定できるほか、後から変更することも可能です。自動ローテーションの頻度は 1 日～36,500 日の間で指定することが可能で、デフォルトでは 90 日です。

非対称鍵の場合は、手動ローテーションで新しい秘密鍵を作る場合、公開鍵を配布しなおす必要があります。

バージョン

Key には前述の通りバージョンが存在します。Key を新規作成するとバージョンは 1 から始まり、ローテーションするごとに数字が 1 つずつ増えます。

Key のバージョンには一意の ID が割り振られます。

バージョンの無効化と破棄

Key のバージョンは個別に無効化したり、破棄したりすることができます。

重要なポイントとして あるバージョンの Key で暗号化したデータを復号できるのは、そのバージョンだけである という点を理解してください。以下に例を示します。

ある Cloud Storage バケットが、ある Key で暗号化されているとします。あるときオブジェクト A がアップロードされました。このとき Key のプライマリバージョンは 1 だったとします。オブジェクト A はバージョン 1 の Key で暗号化されることになります。

その後のある日、キーがローテーションされ、プライマリバージョンは 2 になりました。この段階ではもちろん、ユーザーは引き続きバージョン 1 で暗号化されたオブジェクト A にアクセスできます。バージョン 1 の Key が有効状態だからです。

あるとき Key のバージョン 1 を何らかの理由で無効化したとします。このときユーザーがこのオブジェクト A にアクセスしようとすると Unable to decrypt with Cloud KMS のエラーが返ります。オブジェクト A を暗号化したバージョン 1 の Key が無効化されているため、Cloud Storage がオブジェクト A を復号できなくなったからです。

状態

Key のバージョンは「有効 ( ENABLED )」「無効 ( DISABLED )」「破棄の予定 ( DESTROY_SCHEDULED )」「破棄 ( DESTROYED )」の 4 つの状態のいずれかを持ちます。

有効 ( ENABLED ) はバージョンが使用可能な状態であることを示します。

無効 ( DISABLED ) はバージョンが明示的に無効化してあり、使用不可の状態です。再度、有効状態に戻すことが可能です。

破棄の予定 ( DESTROY_SCHEDULED ) はバージョンの破棄が指示されており、指定された日時で削除される予定であることを意味します。この状態のバージョンを利用することはできません。この状態のバージョンは「復元」することができます。

この「破棄の予定」という猶予期間はデフォルトでは 24 時間です。期間は Key の作成時にのみ設定でき、あとから変更することはできません。最小は 24 時間で、最大 120 日間です。

鍵の権限管理

Key ring と Key の IAM ポリシー

KMS の Key ring と Key には IAM ポリシーを付与でき、鍵へのアクセスを制御することができます。

IAM ポリシーの意味については当社記事をご参照ください。これ以降の記述は IAM ポリシーや IAM ロールの意味を理解している前提で記載いたします。特に間違いが起きやすいポイントとして Google Cloud の「IAM ポリシー」「IAM ロール」は AWS の「IAM ポリシー」「IAM ロール」とは意味が異なる点にご留意ください。

Key ring に付与した IAM 権限は配下の Key にも継承されます。ただし Key の各バージョンに個別の IAM ポリシーはありません。つまり権限管理の最小単位は Key となります。

誰が権限を必要とするか

鍵へのアクセス権限は誰が必要とするかを考えます。大まかに以下の2通りです。

鍵の管理 (作成、破棄、ローテーション、無効化、有効化等）
鍵を使った暗号化・復号

前者の「管理」は、Google Cloud の管理者やセキュリティ担当者が権限を持つべきです。クラウド KMS 管理者 (roles/cloudkms.admin) ロールなどをプロジェクト単位、もしくは Key ring / Key 単位で持つことができます。

後者の暗号化・復号権限については、特に CMEK によるストレージ暗号化で考える場面が出てきます。CMEK によるストレージ暗号化は透過的な暗号化であるため、鍵へのアクセス権限を必要とするのは Google Cloud サービス そのものです。正確に言うと Google Cloud サービスは サービスエージェント と呼ばれる特殊なサービスアカウントを持っています。

Comute Engine や Cloud Storage ではプロジェクトに一つ、サービスエージェントがデフォルトで用意されており、他の Google Cloud サービスの API 呼び出しはこのサービスエージェントによって行われています。このサービスエージェントが裏で KMS を使った暗号化・復号、Pub/Sub への通知などを行っているのです。

例として Cloud Storage のサービスエージェントは service-${プロジェクト番号}@gs-project-accounts.iam.gserviceaccount.com という名称で、最初から存在しており、コンソール画面や gcloud コマンドで確認することができます。

作成したばかりの鍵に権限変更も加えていない状態で Cloud Storage バケットの CMEK 暗号化を設定しようとすると、コンソール画面で以下のように促されます (以下は Cloud Storage バケットの作成画面です) 。

上記はプロジェクトの Cloud Storage サービスエージェントに該当の Key に対する cloudkms.cryptoKeyEncrypterDecrypter ロールを与えるように促すメッセージです。この権限を付与することで、Cloud Storage は Key にアクセスし、暗号化・復号を行うことができます。

なお上記ではサービスエージェントによる Key の利用の例を記載しましたが、それ以外にも KMS 鍵を署名作成などの目的で明示的に利用する場合には、利用するクライアント側で Cloud KMS 暗号鍵の署名者 (roles/cloudkms.signer) などの権限が必要です。

Cloud KMS 関連の定義済みロールについては、以下のドキュメントに網羅されています。

Cloud KMS のロール

職掌分散 (Separation of duties)

IT 一般のセキュリティの考え方に 最小権限の原則 と呼ばれるものがあります。個人に業務上必要となる最小の権限だけを与えることを原則とすることでリスクを低減する考え方です。

Cloud KMS でも企業や組織において鍵へのアクセス権限や管理権限を分散し最小限にすることでリスクを下げることがベストプラクティスとされており、これは職掌分散 (Separation of duties) と呼ばれています。

この考えに基づき、大規模利用においては Cloud KMS の鍵を独自の Google Cloud プロジェクトに集約させることが推奨されています。

KMS 専用プロジェクトにはオーナー (Owner) のロールを付与しない
代わりに組織レベルの組織の管理者 (roles/resourcemanager.organizationAdmin) が鍵の権限を管理する
- 組織の管理者は鍵自体への利用権限を持たないが鍵の IAM ポリシーを操作する権限を持つため「管理」と「利用」を分離できる

独自の鍵と外部の鍵

鍵のインポート

KMS には既存の鍵をインポートすることができます。インポートした鍵は Cloud HSM Key もしくはソフトウェア Key としてインポートされます。

インポートできる鍵には鍵の種類・目的別に要件があるためドキュメントをご参照ください。

鍵をインポートする前に Key ring と Key を作成しておきます。インポート後の鍵は、その Key の新しいバージョンとしてインポートされます。

外部の鍵の利用

Cloud External Key Manager (Cloud EKM、外部鍵マネージャー) を用いると Cloud KMS から Fortanix や Futurex といったサードパーティ製の鍵管理システムに接続し、外部鍵管理システムの鍵を KMS 鍵のように利用することができます。

外部鍵管理システムとの接続は「インターネット経由」「VPC 経由」を選択することができます。

EKM で取り込んだ外部鍵は Compute Engine や Cloud Storage、BigQuery で CMEK 暗号化に利用することができます。

暗号化の手法と技術

エンベロープ暗号化

エンベロープ暗号化 という技術があります。これは Cloud KMS による暗号化で使われている技術であり、AWS の KMS 等でも使われています。透過的暗号化においてはユーザーの意識しないところで行われているため、知らなくても業務に支障はありません。

エンベロープ暗号化ではデータを暗号化する鍵そのもの (Data Encryption Key = DEK) とその DEK を暗号化する別の鍵 (Key Encryption Key = KEK) の二段階を用います。

都度生成する DEK でデータを暗号化し、DEK 自体は KMS で生成・管理する KEK で暗号化したうえでデータと一緒に保管します。データを利用するときは KEK で DEK を復号し、復号された DEK でデータを復号します。KEK は KMS の外に出ることはなく、セキュアに管理されます。

文字での解説には限界があるため、図による解説があるドキュメントをいくつかご紹介します。

以下は Google Cloud の公式ドキュメントです。

エンベロープ暗号化

以下は AWS Encryption SDK の公式ドキュメントです。エンベロープ暗号化について図解しています。

AWS Encryption SDK の概念 - エンベロープ暗号化

アルゴリズム

選択できる鍵の暗号化アルゴリズムは、鍵の目的によって異なります。

目的が対称暗号化 / 復号 (Symmetric encrypt/decrypt) の対称鍵の場合、 GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムが利用され、 Galois Counter Mode (GCM) / AES-256 鍵となります。

目的が非対称署名 (Asymmetric signing) の非対称鍵の場合、楕円曲線署名 / RSA 署名アルゴリズムのうち複数の中から選択することができます。また非対称鍵の目的が非対称暗号化 / 復号 (Asymmetric encrypt/decrypt) の場合も、RSA アルゴリズムの中から選択できます。

詳細は以下のドキュメントをご参照ください。

鍵の目的とアルゴリズム

Cloud KMS リソースの整合性

Cloud KMS リソース (Key や Key ring) は、作成・削除・無効化などのオペレーションに対して、リソースごとに異なる整合性を持っています。

KMS リソースに対するオペレーションには 強整合性 と 結果整合性 の 2 種類があります。強整合性オペレーションは実行後に直ちに適用されます。結果整合性のオペレーションは通常は 1 分以内に Google Cloud 内に伝播されますが、最大で 3 時間かかるとされています。

オペレーションごとの整合性は以下のとおりです。

オペレーション名	整合性
Key ring の作成	強整合性
Key の作成	強整合性
Key のバージョンの有効化	強整合性
Key のバージョンの無効化	結果整合性
Key のプライマリ (メイン) バージョンの変更	結果整合性
IAM 権限の変更	結果整合性 (通常は数秒)