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
54
復号できなくなると怖いので、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
8.9k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
490
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
490
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
21k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
PRO
3
1.3k
始めないともったいない!SLO運用で得られる3つのメリット
iwamot
PRO
1
150
あなたの人生も変わるかも?AWS認定2つで始まったウソみたいな話
iwamot
PRO
3
8.1k
効率的な技術組織が作れる!書籍『チームトポロジー』要点まとめ
iwamot
PRO
2
390
Other Decks in Technology
See All in Technology
AWS re:Inforce 2025 re:Cap Update Pickup & AWS Control Tower の運用における考慮ポイント
htan
1
220
形式手法特論:位相空間としての並行プログラミング #kernelvm / Kernel VM Study Tokyo 18th
ytaka23
3
1.1k
Amazon Q Developerを活用したアーキテクチャのリファクタリング
k1nakayama
2
200
リリース2ヶ月で収益化した話
kent_code3
1
220
JAWS AI/ML #30 AI コーディング IDE "Kiro" を触ってみよう
inariku
3
340
【Λ(らむだ)】最近のアプデ情報 / RPALT20250729
lambda
0
230
反脆弱性(アンチフラジャイル)とデータ基盤構築
cuebic9bic
3
170
2025新卒研修・HTML/CSS #弁護士ドットコム
bengo4com
3
13k
LLM 機能を支える Langfuse / ClickHouse のサーバレス化
yuu26
7
1.1k
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2.2k
Kiroでインフラ要件定義~テスト を実施してみた
nagisa53
3
320
Tableau API連携の罠!?脱スプシを夢見たはずが、逆に依存を深めた話
cuebic9bic
3
220
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.7k
4 Signs Your Business is Dying
shpigford
184
22k
How to train your dragon (web standard)
notwaldorf
96
6.2k
A better future with KSS
kneath
239
17k
BBQ
matthewcrist
89
9.8k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
How STYLIGHT went responsive
nonsquared
100
5.7k
The Cost Of JavaScript in 2023
addyosmani
51
8.8k
The Invisible Side of Design
smashingmag
301
51k
A designer walks into a library…
pauljervisheath
207
24k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
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キーの削除を「面倒」にしたら安心できた うっかり削除すると、復号できなくなるので怖い 削除を「面倒」にする案がひらめき、実装した 「うっかり」は防ぎつつ「ちゃんと考えれば削除できる」状態が実現できた 学び:危険な操作を「面倒」にする案、広く応用できそう 何かないか考えてみよう