要旨

Google Cloud を業務で利用するに当たり、顧客管理の鍵で暗号化することが求められたので暗号化をしてみました。

データ暗号化について

暗号化周りは、かなーり複雑なので前提知識を書いてみます。
実際の設定方法は記事の下部にまとめます。

デフォルト暗号鍵と顧客管理の暗号鍵 （CMEK）

Google Cloud は大きく 2種類の暗号鍵を利用することができます。
Google が管理する『デフォルト暗号鍵』と、顧客が管理する『顧客管理の暗号鍵 (CMEK)』です。
(CMEK: Customer-managed encryption keys)

Google Cloud では平文でデータを保存することはできず、デフォルトで全て暗号化されます。
このときに利用されるのが『デフォルト暗号鍵』です。

デフォルト暗号鍵は、Google が管理を行っているため、必要最低限の機密性を求められるようなデータはこれを利用して暗号化することができます。

顧客が機密データを保存する際に使用できるのが『顧客管理の暗号鍵（CMEK）』です。

これは、顧客ごとに異なる暗号鍵を生成して、鍵の権限管理やローテーション管理などを顧客の管理下で実施できるものです。

顧客の機密データを暗号化する際には、CMEK を生成して暗号化することで暗号化の統制を行うことができます。
CMEK は、Cloud KMS を用いてソフトウェアベースで暗号化することや、Cloud HSM を用いてハードウェアベースで暗号化することができます。

紛らわしいものとしては、顧客指定の暗号鍵 （CSEK）があり、これは Google Cloud で鍵管理を行わず、GCE や GCS の保存時などに明示的に鍵を指定するものです。
(CSEK: Customer-supplied encryption keys)

これは、利用用途が限定的なので、基本的には通常データにはデフォルト暗号化を使用し、機密データには CMEK を利用します。
顧客指定の暗号鍵 – Google Cloud

KEK と DEK

データ暗号鍵の世界では、KEK / DEK の概念がよく出てきます。
KEK は Key Encryption Key で、鍵を暗号化する鍵のことです。
DEK は Data Encryption Key で、データを暗号化する鍵のことです。

Google Cloud では、KEK は Cloud KMS のことを指していて、DEK は暗号化の都度生成されています。

平文のデータを暗号化する際に、DEK を都度ランダム生成して、暗号データと、 KEK で暗号化した DEK を保存しています。
また、復号化する際は、暗号化された DEK を KEK で復号化して、データを復号化しています。

この方法のメリットは多く、以下のようなものがあります。

  • 一つの暗号鍵で暗号化される範囲を小さくする
  • 実際の暗号化に使われる暗号鍵 （DEK）を外部に出さない
  • 再暗号化の際の影響範囲を小さくする

Cloud 上での暗号化は、KEK、DEK の考え方でデータを暗号化するのが一般的です。

Google Cloud 上の鍵管理階層

Google Cloud の Cloud KMS では、Key Ring / Key / Version の 3階層で管理されています。
それぞれの用途は以下のようなイメージです。

Key Ring

鍵の管理単位。
用途とか、権限の単位で生成するイメージです。

たとえば、案件単位とか、プロジェクト単位、環境単位（Prod / Dev）など、用途で整理する単位です。
鍵の保存リージョンは、Key Ring 単位での指定となります。

Dual region や Global region に対応したリソース (e.g. GCS、Cloud Spanner) を利用する場合は、対応する鍵の保存リージョンが必要となります。

Key

鍵単位。
論理的な鍵の単位で生成するイメージです。

App / DB で鍵を分けたりするイメージです。

Version

鍵バージョン。
鍵ローテーションがされると、Version が上がります。

KEK は、Version に紐づいていて、Version を上げると新しい KEK が生成されます。
Version に紐づく KEK が実際の暗号化・復号化の用途に供されます。

Re-encrypting

Google Cloud 上の暗号化の際に、気をつける点として多くの種類のデータは鍵をローテーションしても再暗号化されないという特徴があります。

たとえば、鍵の Version を破棄したり、暗号鍵が漏洩した際に鍵バージョンだけローテーションしたりすると、既存で保存されているデータの復号に影響が出ます。

これらの影響をなくすために、新しい鍵バージョンで暗号化し直すことを Re-encrypting (再暗号化) と言います。

Organization Policy

Cloud KMS は、GCE の Persistent Disk や、Cloud SQL のデータ暗号化に利用することができます。

しかし、『利用することが出来る』状態であり、『利用しない』こともできてしまいます。
というか、明示的に指定しない限り利用できません。

暗号化の鍵を指定するのはコンソールの奥深くなので、絶対に作業漏れが発生すると思います。
そのような事態にならないように Organization Policy で暗号化を強制することができます。

Organization Policy で強制することで、GCE や Cloud SQL で暗号化しないデータを作れなくなります。

また、特に制約がない場合、どの Cloud KMS で提供される Key Ring も利用することができてしまいます。
第三者が作成した Key で誤って暗号化を行わないよう、 Organization Policy で Key Ring を提供可能な Project を制約することが必要です。

やってみる

ここでは、以下の作業を行います。

実施内容

  1. Cloud KMS で CMEK を生成する。
    • ここでは、Cloud KMS 上に Key Ring および Key を作成し、CMEK として提供可能にします。
  2. Organization Policy で CMEK を強制する。
    • ここでは、Organization Policy を用いて、CMEK による暗号化の強制と、CMEK の提供元を 1. で CMEK を作成した Project に強制します。
  3. 確認
    • ここでは、上記の構成により、CMEK で暗号化しないとリソースが作成できないことを確認します。

権限

この手順を実施するためには、 Organization Policy Administrator (roles/orgpolicy.policyAdmin) の権限が必要となります。
パーミッションで示した場合、 orgpolicy.* が必要です。
かなり上位の権限となるため、会社管理の Google Cloud を利用する場合などは権限不足に注意してください。

1. Cloud KMS で CMEK を生成する。

Cloud KMS を用いて、CMEK を管理可能にします。

API の有効化

Cloud Key Management Service (KMS) API

API をまだ有効化していない場合、 Cloud Key Management Service (KMS) API を有効化します。

  • 『有効にする』を選択

認証情報の作成

API / サービス詳細

場合により、認証情報が必要になる場合は、認証情報を追加で有効化します。

  • 『認証情報を作成』 を選択。

  • 『アプリケーションデータ』を選択

  • 『いいえ、使用しません』 を選択
  • 『完了』

コンソールへのアクセス

KMS の管理コンソールへアクセスします。
Key Management

Key ring の作成

Key ring を作成します。
キーリングの作成

  • 『キーリングを作成』 を選択

  • キーリング名に任意の情報を入力
  • ロケーションタイプを選択
    •  注意: GCS の Dual region、Global region を使用する際は、Key rings も マルチリージョン / Global を選択する必要があります。
  •  『作成』 を選択

鍵を作成

画面が自動的に遷移して、鍵作成画面になるため、鍵を作成します。

  • キー名に任意の情報を入力
  • 保護レベルに任意の情報を入力
  • 『作成』 を選択
  • デフォルトの設定値で作成されます。

鍵作成の完了

鍵作成が完了しました。

2. Organization Policy で CMEK を強制する。

Organization Policy を利用して、サービスでの CMEK 利用を強制し、CMEK の提供元を指定したプロジェクトに制限します。

コンソールアクセス

Organization Policies の管理コンソールへアクセスします。

Organization Policies

今回は、以下の制約を行います。

項目 値
利用するサービス Google Cloud Storage
CMEK の提供プロジェクト 『1. Cloud KMS で CMEK を生成する。』で使用したプロジェクト

CMEK の強制

CMEK の指定無しで作成できるリソースを制限します。

  • constraints/gcp.restrictNonCmekServices で検索して、対象を選択します。

  • 『ポリシーを管理』 を選択します。

  • 『カスタマイズ』 を選択します。

  • 『置き換える』 を選択します。

  • 『ルールの追加』 を選択します。

新しいルールに対して以下を入力します。

  • ポリシーの値　『カスタム』
  • ポリシーの種類 『拒否』
  • カスタム値　『storage.googleapis.com』

  • 『ポリシーを設定』 を選択します。

これで、CMEK を選択せずに、 Google Cloud Storage を生成できなくなります。

CMEK 提供元の強制

自身のプロジェクト以外の CMEK を選択不能にします。

  • constraints/gcp.restrictCmekCryptoKeyProjects で検索して、対象を選択します。

  • 『ポリシーを管理』 を選択します。

  • 『カスタマイズ』 を選択します。

  • 『置き換える』 を選択します。

  • 『ルールの追加』 を選択します。

新しいルールに対して以下を入力します。

  • ポリシーの値　『カスタム』
  • ポリシーの種類 『許可』
  • カスタム値　『projects/PROJECT_ID』
  • なお、PROJECT_ID　は CMEK を格納したプロジェクトID を入力。

  • 『ポリシーを設定』

これで、CMEK を提供可能なプロジェクトが制約されます。

3. 確認

Cloud Storage

設定が有効か、GCS を利用して確認してみます。

  • 『作成』 を選択

  • バケット名を入力
  • 『続行』

  • ロケーションを選択
  • ここでのロケーションは、Key rings を作成したものと同一または含まれている必要があります。
  • asia-northeast1 / asia-northeast2 の Dual region の場合、 asia1 の Key ring が必須となります。
  • 『続行』

  • 『続行』

  • データの暗号化について、 Organization Policiesによる制約を受けて 『Google が管理する暗号鍵』 が選択できなくなっています。
  • 顧客管理の暗号鍵を選択して、作成した Key を選択します。

Service Agent (Service が自動生成する Service Account の事) によるアクセス権がない場合、『付与』を選択して付与する。

  • 『作成』 を選択する。

以上で、 Google Cloud のデータを暗号化することができました。

おわりに

Google Cloud では『デフォルト暗号鍵』で最低限の暗号化を行えるため、『顧客管理の暗号鍵 (CMEK)』を利用することは多くないかもしれません。

顧客管理の暗号鍵は、生成、アクセス権の付与、ローテーション、破棄など、顧客側で管理することが可能です。
機密データを暗号化する際には、ぜひ Cloud KMS を用いて顧客データの管理を厳密に行ってください。

以上