はじめに

2023/8/17のアップデートにてCloud KMS の 顧客管理の暗号化キー ( CMEK ) で暗号化された Cloud SQL のインスタンスにて対して、対象キーをローテートした場合でも、最新のキーで再暗号化が可能になりましたので、どのようなものか見ていきます。

CMEK 対応インスタンスの再暗号化について

Google Cloud の公式ドキュメントの CMEK 対応インスタンスまたはレプリカを再暗号化にて方法が解説されています。
Cloud KMS で作成した 顧客管理の暗号化キー ( CMEK ) をローテートした場合、過去のキーを利用せずとも、新たな主キーを利用して、インスタンスの再暗号化が可能であることが記載されています。
※ Cloud KMS のローテートに関しては、鍵のローテーションを参照ください。

Cloud SQL の CMEK を利用した再暗号化をやっていく

では、再暗号化をやっていきます。

CMEK の再暗号化の前提

  • 暗号化前のインスタンスを途中から暗号化することはできません
  • 予め CMEK で暗号化しており、その暗号化キーのバージョンを変えるもので、key id 自体が異なるものを利用するものではありません

※これ以降 CMEK は基本的にキーと表記しております

サービスアカウントの作成

以下のコマンドでサービスアカウントを作成し、このあとに出てくるサービスアカウントによる暗号化アクセスキーへのアクセスキー許可で利用します。

gcloud beta services identity create \
--service=sqladmin.googleapis.com \
--project=<プロジェクト名>

以下のような形でプロンプトに応答があります。

Service identity created: service-XXXXXXXXX@gcp-sa-cloud-sql.iam.gserviceaccount.com

以下のような形でサービスアカウントに対して、Cloud KMSに対する権限を付与します。

gcloud kms keys add-iam-policy-binding <KMSのkey id> \
--location=<region> \
--keyring=<キーリング名> \
--member=serviceAccount:service-XXXXXXXXX@gcp-sa-cloud-sql.iam.gserviceaccount.com \
--role=roles/cloudkms.cryptoKeyEncrypterDecrypter

暗号化する Cloud SQL を作成します。

初めて暗号化する場合、Cloud SQL のサービスアカウントに権限が無いため、付与します。
暗号化の設定項目は以下です。
暗号化メニュー

作成された Cloud SQL へ接続し、適当にDBを作成しサンプルのテーブルを作成します。

バックアップを取得

これ以降のバックアップの挙動も確認するため、手動で取得します。

キーローテート

キーをローテートします。
キーローテート
無事に作成されました。
キーローテート結果

Cloud SQL の再暗号化

インスタンスの暗号化を再暗号化します。
概要の構成の枠にて再暗号化ボタンが登場します。
押すと、こんなメッセージがでます。
Cloud SQL 再暗号化ウインドウ

無事にキーのバージョンが変わりました。
Cloud SQL 再暗号化成功

過去の キー のバージョン無効化

では試しに元々の主キーを無効にしてみます。
過去のキー無効化

その後テーブル情報を閲覧したところ、無事閲覧できました。

再暗号化補足

主キーをローテートし再暗号化すると新たにバックアップが作られます。
以下の通り説明もそれっぽい説明があります。
Cloud SQL 再暗号化バックアップ

確認したところ、この作業はダウンタイムが発生する作業になります。
制限事項にてそれ相当の文言が確認可能です。

以下実際のログベースでの停止の確認です。

再暗号化の時間
再暗号化ログ
mysql のエラーログ
Cloud SQL mysql エラーログ

Cloud SQL のキーの対象バージョンが無いとどうなるか

次にキーを無効化した際の挙動について確認します。
利用中のキーを無効化し、有効なキーで再暗号化ができないか、確認します。
一旦ローテートし、再暗号化せずに無効化するような手順で実施してみます。

ローテート
キーローテート2

以前の主キーが利用されており、再暗号化する、という文言が出力
キー暗号化ウインドウ2

以前の主キーを無効化
数時間かかる、という記載があるので、時間もちょっと気にして見ていきます。
主キー無効化

数分経ちますが、メッセージ通りすぐには見れなくなるわけではないみたいですが、
Cloud SQL の画面を再読み込みしたところ、利用不可とでてきました。
Cloud SQL キー利用不可

データはその後もみれましたが、約30分経過後にアクセスしたときはインスタンス自体にアクセスできなくなっており、1つ目に行った再暗号化は正しく行われたことが確認できました。

ログにも以下のような出力があり、暗号化キーが変わったあと、13分後にこのようなログがでております。
Cloud SQL mysql エラーログ2

試しに再暗号化することで復旧できるか、確認しますが、できませんでした。
どうやら無効化したキーを利用した状態ではインスタンスが停止していまい、新たなキーで再暗号化することはできないようです。
Cloud SQL 再暗号化不可

トラブルシューティングの停止状態にも記載がありますが、停止したインスタンスに対する再暗号化ができないことがわかります。
Cloud SQL log

では無効化したキーを復活させてみると、約10分後ステータスに変化が見られました。
以下の通り、再起動中や、停止、起動中に見られる、更新中の状態で、ステータスが変動していることがわかります。
Cloud SQL 更新中
その後完全に起動しました。
Cloud SQL 起動
では再暗号化も試みたところ、無事に再暗号化もできました。
Cloud SQL 起動後の再暗号化
最初と同様に以前のキーを無効化しても、無事に停止することなく、継続してアクセス可能です。

注意事項

制限事項に記載がある内容ですが、以下注意が必要です。

  • インスタンスのレプリカも暗号化されている場合、プライマリの再暗号化を行ったあと、レプリカの再暗号化も行う必要があります。
  • 再暗号化中は他の管理オペレーションは実行できない。
  • ダウンタイムが発生する
  • 再暗号化後に過去のバックアップを利用する場合、過去のキーが無いと復元できないので、キーを無効化するタイミングはしっかり意識する必要があります。
    • なお、再暗号化後の自動的なバックアップは上記したスクショの通り、新たなキーで暗号化されます

所感

Cloud SQL に対する CMEK の再暗号化機能について試しました。
再暗号化が過去のキーを無効化しても暗号化は継続され、Cloud SQL へのアクセスに問題ないことを確認できました。
無効化による、意図しない Cloud SQL の停止などが起きないように、別の役割のインスタンスがあるような場合、暗号化するキーは分けておいたほうが無難かもしれません。
ついでに確認したキーの無効化して起動しなくなったときは、バックアップからの復旧でないと戻せないのか、と思いましたが、無事に復活することができました(さすがに再暗号化での復旧はできず、、)。
また、 Google Cloud の CMEK での再暗号化できる、というのは AWS の RDS の暗号化と異なる部分ではないかな、と思いましたので、勘違いしないようにしていきたいと思います。
Cloud SQL も Enterprise Plus が出たり、Query Insights などアップデートがあり、可用性や運用面でのアップデートがあるので、今後も見ていきたいと思います。