復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた

Cloud Operator Days Tokyo 2025
https://cloudopsdays.com/

Transcript

1. 復号できなくなると怖いので、 AWS KMSキーの削除を「面倒」にしてみた Cloud Operator Days Tokyo 2025 https://cloudopsdays.com/ ENECHANGE株式会社 VPoT兼CTO室マネージャー 岩本隆史
2. 自己紹介 岩本 隆史 (@iwamot) 勤務先：ENECHANGE株式会社 (2021/7～) 全社的な技術戦略の策定・推進 事業部への技術支援のリード AWS Community Builder (2024/3～) カテゴリ：Cloud Operations
3. こんな話です AWS KMSキーの削除が怖くなった 削除を「面倒」にする案がひらめいた 実装してみた 安心できた
4. AWS KMSキーの削除が怖くなった
5. 2025/2/3：不要となったAWS環境の削除を実施 1月末で提供終了したサービス 事業部からの削除依頼を受けた RDS DBインスタンスの最終スナップショットを念のため作成 RDS、ECS、KMSキーなどのリソースを terraform destroy
6. 2025/2/14：このままだと復号不能になると気づく 最終スナップショットがKMSキーで暗号化されていることに気づいた 暗号化したDBインスタンスでは当然の挙動 KMSキーを削除すると、最終スナップショットが復号不能に KMSキーまで terraform destroy したのは浅はかだった ありがたいことに、KMSキーは30日間の削除待機期間に入っていた 危険な操作なので、デフォルトでそうなる
7. 2025/2/17：KMSキーの削除をキャンセル マネジメントコンソールでキャンセルを実施 terraform import でステートを戻し、tfファイルを復活 リポジトリのREADMEに意図を記載 必要な場合にRDSのスナップショットを復元できるよう、KMSキーのみ残し ています。
8. 「うっかり削除」を防ぐ仕組みがないと怖い 待機期間があるとはいえ、気づかずに削除してしまうリスクがある レビューで確実に防げるとも限らない
9. 削除を「面倒」にする案がひらめいた
10. うっかり削除を防ぎたいなら「面倒」にすればよい 本当に不要なキーもあるので、一律に削除を禁ずるのはNG 防ぎたいのは「うっかり削除」 目指すべきは「ちゃんと考えれば削除できる」状態
11. 特定のタグを付けると削除できる仕組みはどうか deletable = true タグが付いているキーのみ削除を許可 削除が拒否されたらSlackに通知 deletable = true タグが付いているか確認するよう促す （権限不足による拒否かもしれないため「付けろ」とまでは言わない） 削除が待機されてもSlackに通知 復号できなくなっても問題ないか、削除予定日時までに確認するよう促す
12. タグでの制御はRCPで実装できそう RCP (Resource Control Policy) AWS Organizationsで使えるポリシーの一種 組織内のリソースへのアクセス条件を一元的に絞れる KMSもサポート対象 S3、STS、SQS、Secrets Managerも（2025年6月現在）
13. 削除拒否／待機の検知はEventBridgeで可能そう ScheduleKeyDeletion APIの呼び出しをEventBridgeルールで検知 エラーが含まれる　 ＝ 拒否イベント エラーが含まれない ＝ 待機イベント 前提：CloudTrailで証跡のログ記録が有効になっていること EventBridge → SNS → Amazon Q Developer → Slackの流れで通知 Amazon Q Developer：旧称 AWS Chatbot
14. 実装してみた
15. 3つのTerraformモジュール Hubモジュール　：メインリージョンの拒否・待機イベントを通知 Spokeモジュール：サブリージョンの拒否・待機イベントを通知 RCPモジュール　：ポリシーの作成～アタッチ
16. Hubモジュール module "hub" { source = "..." sns_topic_arn = aws_sns_topic.this.arn } 拒否・待機イベントを検知するEventBridgeルールを作成 ルールのターゲットとして、指定のSNSトピックを設定 ターゲットにイベントを送信するIAMロールを作成 「SNS → Amazon Q Developer → Slack」には既存モジュールを利用
17. Spokeモジュール module "spoke_us_east_1" { source = "..." providers = { aws = aws.us_east_1 } # サブリージョン hub_event_bus_arn = module.hub.event_bus.arn hub_iam_role_arn = module.hub.iam_role.arn hub_region_name = module.hub.region.name # メインリージョン } 拒否・待機イベントを検知するEventBridgeルールを作成（Hubと同じ） ルールのターゲットとして、Hubのイベントバスを設定 （SNSトピックを変えたくなっても、Hub側を直すだけで済む） ターゲットにイベントを送信するIAMロールとして、Hubのロールを流用 hub_region_name は、Hubと同じリージョンへのデプロイ防止に利用
18. RCPモジュール module "rcp" { source = "..." target_ids = [ local.accounts.prod.id ] } deletable = true タグ未設定のキー削除を禁じるRCPを作成 指定のAWSアカウント（あるいはOU）にアタッチ
19. 安心できた
20. 2025/4/24：変更アナウンス
21. 2025/4/24：全organizationで設定完了 ENECHANGEでは複数のorganizationを運用中 アカウントの追加はほぼないため、Terraformで普通に構築 追加が多ければ、CloudFormation StackSetsによる自動デプロイが楽そう
22. 2025/4/28：初めての拒否通知
23. 2025/4/28：初めての待機通知 → これで安心
24. ️ まとめ
25. KMSキーの削除を「面倒」にしたら安心できた うっかり削除すると、復号できなくなるので怖い 削除を「面倒」にする案がひらめき、実装した 「うっかり」は防ぎつつ「ちゃんと考えれば削除できる」状態が実現できた 学び：危険な操作を「面倒」にする案、広く応用できそう 何かないか考えてみよう