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

復号できなくなると怖いので、 AWS KMSキーの削除を「面倒」にしてみた Cloud Operator Days Tokyo 2025 https://cloudopsdays.com/ ENECHANGE株式会社
VPoT兼CTO室マネージャー岩本隆史

自己紹介岩本隆史 (@iwamot) 勤務先：ENECHANGE株式会社 (2021/7～) 全社的な技術戦略の策定・推進事業部への技術支援のリード AWS Community
Builder (2024/3～) カテゴリ：Cloud Operations

こんな話です AWS KMSキーの削除が怖くなった削除を「面倒」にする案がひらめいた実装してみた安心できた

AWS KMSキーの削除が怖くなった

2025/2/3：不要となったAWS環境の削除を実施 1月末で提供終了したサービス事業部からの削除依頼を受けた RDS DBインスタンスの最終スナップショットを念のため作成 RDS、ECS、KMSキーなどのリソースを terraform destroy

2025/2/14：このままだと復号不能になると気づく最終スナップショットがKMSキーで暗号化されていることに気づいた暗号化したDBインスタンスでは当然の挙動 KMSキーを削除すると、最終スナップショットが復号不能に KMSキーまで terraform destroy したのは浅はかだったありがたいことに、KMSキーは30日間の削除待機期間に入っていた危険な操作なので、デフォルトでそうなる

2025/2/17：KMSキーの削除をキャンセルマネジメントコンソールでキャンセルを実施 terraform import でステートを戻し、tfファイルを復活リポジトリのREADMEに意図を記載必要な場合にRDSのスナップショットを復元できるよう、KMSキーのみ残しています。

「うっかり削除」を防ぐ仕組みがないと怖い待機期間があるとはいえ、気づかずに削除してしまうリスクがあるレビューで確実に防げるとも限らない

削除を「面倒」にする案がひらめいた

うっかり削除を防ぎたいなら「面倒」にすればよい本当に不要なキーもあるので、一律に削除を禁ずるのはNG 防ぎたいのは「うっかり削除」目指すべきは「ちゃんと考えれば削除できる」状態

特定のタグを付けると削除できる仕組みはどうか deletable = true タグが付いているキーのみ削除を許可削除が拒否されたらSlackに通知 deletable = true タグが付いているか確認するよう促す
（権限不足による拒否かもしれないため「付けろ」とまでは言わない）削除が待機されてもSlackに通知復号できなくなっても問題ないか、削除予定日時までに確認するよう促す

タグでの制御はRCPで実装できそう RCP (Resource Control Policy) AWS Organizationsで使えるポリシーの一種組織内のリソースへのアクセス条件を一元的に絞れる KMSもサポート対象 S3、STS、SQS、Secrets
Managerも（2025年6月現在）

削除拒否／待機の検知はEventBridgeで可能そう ScheduleKeyDeletion APIの呼び出しをEventBridgeルールで検知エラーが含まれる　＝拒否イベントエラーが含まれない＝待機イベント前提：CloudTrailで証跡のログ記録が有効になっていること
EventBridge → SNS → Amazon Q Developer → Slackの流れで通知 Amazon Q Developer：旧称 AWS Chatbot

実装してみた

3つのTerraformモジュール Hubモジュール　：メインリージョンの拒否・待機イベントを通知 Spokeモジュール：サブリージョンの拒否・待機イベントを通知 RCPモジュール　：ポリシーの作成～アタッチ

Hubモジュール module "hub" { source = "..." sns_topic_arn = aws_sns_topic.this.arn
} 拒否・待機イベントを検知するEventBridgeルールを作成ルールのターゲットとして、指定のSNSトピックを設定ターゲットにイベントを送信するIAMロールを作成「SNS → Amazon Q Developer → Slack」には既存モジュールを利用

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と同じリージョンへのデプロイ防止に利用

RCPモジュール module "rcp" { source = "..." target_ids = [
local.accounts.prod.id ] } deletable = true タグ未設定のキー削除を禁じるRCPを作成指定のAWSアカウント（あるいはOU）にアタッチ

安心できた

2025/4/24：変更アナウンス

2025/4/24：全organizationで設定完了 ENECHANGEでは複数のorganizationを運用中アカウントの追加はほぼないため、Terraformで普通に構築追加が多ければ、CloudFormation StackSetsによる自動デプロイが楽そう

2025/4/28：初めての拒否通知

2025/4/28：初めての待機通知 → これで安心

️ まとめ

KMSキーの削除を「面倒」にしたら安心できたうっかり削除すると、復号できなくなるので怖い削除を「面倒」にする案がひらめき、実装した「うっかり」は防ぎつつ「ちゃんと考えれば削除できる」状態が実現できた学び：危険な操作を「面倒」にする案、広く応用できそう何かないか考えてみよう

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

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

iwamot PRO

More Decks by iwamot

Other Decks in Technology

Featured

Transcript