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
75
復号できなくなると怖いので、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
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
8
1.2k
Developer Certificate of Origin、よさそう
iwamot
PRO
0
16
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版
iwamot
PRO
1
82
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
14
11k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1.1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
550
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
550
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
22k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
PRO
3
1.3k
Other Decks in Technology
See All in Technology
エンタメとAIのための3Dパラレルワールド構築(GPU UNITE 2025 特別講演)
pfn
PRO
0
610
サイバーエージェント流クラウドコスト削減施策「みんなで金塊堀太郎」
kurochan
4
2.2k
Findy Team+ QAチーム これからのチャレンジ!
findy_eventslides
0
490
NLPコロキウム20251022_超効率化への挑戦: LLM 1bit量子化のロードマップ
yumaichikawa
1
150
AIとともに歩んでいくデザイナーの役割の変化
lycorptech_jp
PRO
0
740
データ戦略部門 紹介資料
sansan33
PRO
1
3.8k
「魔法少女まどか☆マギカ Magia Exedra」のIPのキャラクターを描くための3Dルック開発
gree_tech
PRO
0
120
[OCI Skill Mapping] AWSユーザーのためのOCI – IaaS編(Compute/Storage/Networking) (2025年10月8日開催)
oracle4engineer
PRO
1
130
フレームワークを意識させないワークショップづくり
keigosuda
0
230
Railsの話をしよう
yahonda
0
170
CNCFの視点で捉えるPlatform Engineering - 最新動向と展望 / Platform Engineering from the CNCF Perspective
hhiroshell
0
110
Implementing and Evaluating a High-Level Language with WasmGC and the Wasm Component Model: Scala’s Case
tanishiking
0
150
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
Build your cross-platform service in a week with App Engine
jlugia
232
18k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
A designer walks into a library…
pauljervisheath
209
24k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Making Projects Easy
brettharned
120
6.4k
Practical Orchestrator
shlominoach
190
11k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
It's Worth the Effort
3n
187
28k
Reflections from 52 weeks, 52 projects
jeffersonlam
353
21k
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キーの削除を「面倒」にしたら安心できた うっかり削除すると、復号できなくなるので怖い 削除を「面倒」にする案がひらめき、実装した 「うっかり」は防ぎつつ「ちゃんと考えれば削除できる」状態が実現できた 学び:危険な操作を「面倒」にする案、広く応用できそう 何かないか考えてみよう