Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
Search
iwamot
PRO
July 21, 2025
Technology
3
67
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
Cloud Operator Days Tokyo 2025
https://cloudopsdays.com/
iwamot
PRO
July 21, 2025
Tweet
Share
More Decks by iwamot
See All by iwamot
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
13
9.4k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
500
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
500
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
21k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
PRO
3
1.3k
始めないともったいない!SLO運用で得られる3つのメリット
iwamot
PRO
1
160
あなたの人生も変わるかも?AWS認定2つで始まったウソみたいな話
iwamot
PRO
3
8.2k
効率的な技術組織が作れる!書籍『チームトポロジー』要点まとめ
iwamot
PRO
2
420
Other Decks in Technology
See All in Technology
夢の印税生活 / Life on Royalties
tmtms
0
290
DeNA での思い出 / Memories at DeNA
orgachem
PRO
3
1.8k
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
3
870
知られざるprops命名の慣習 アクション編
uhyo
11
2.7k
認知戦の理解と、市民としての対抗策
hogehuga
0
390
モダンフロントエンド 開発研修
recruitengineers
PRO
5
1.9k
JavaScript 研修
recruitengineers
PRO
4
800
開発と脆弱性と脆弱性診断についての話
su3158
1
1.2k
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
260
どこで動かすか、誰が動かすか 〜 kintoneのインフラ基盤刷新と運用体制のシフト 〜
ueokande
0
200
「AI2027」を紐解く ― AGI・ASI・シンギュラリティ
masayamoriofficial
0
120
Android Studio の 新しいAI機能を試してみよう / Try out the new AI features in Android Studio
yanzm
0
280
Featured
See All Featured
Building an army of robots
kneath
306
46k
Balancing Empowerment & Direction
lara
2
590
Designing Experiences People Love
moore
142
24k
Music & Morning Musume
bryan
46
6.8k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Raft: Consensus for Rubyists
vanstee
140
7.1k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
GitHub's CSS Performance
jonrohan
1031
460k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Transcript
復号できなくなると怖いので、 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キーの削除を「面倒」にしたら安心できた うっかり削除すると、復号できなくなるので怖い 削除を「面倒」にする案がひらめき、実装した 「うっかり」は防ぎつつ「ちゃんと考えれば削除できる」状態が実現できた 学び:危険な操作を「面倒」にする案、広く応用できそう 何かないか考えてみよう