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キーの削除を「面倒」にしてみた CODT 2025 ...
Search
iwamot
PRO
September 05, 2025
Technology
210
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版
2025-09-05
Cloud Operator Days Tokyo 2025
https://cloudopsdays.com/
iwamot
PRO
September 05, 2025
More Decks by iwamot
See All by iwamot
MCP Appsを作ってみよう
iwamot
PRO
4
750
自己紹介
iwamot
PRO
1
97
パワポ作るマンをMCP Apps化してみた
iwamot
PRO
0
740
8万デプロイ
iwamot
PRO
2
380
AIエージェント・マイクロサービス時代。AWSでの手軽な構築法を考えて試してみた
iwamot
PRO
1
120
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
10
2.8k
Developer Certificate of Origin、よさそう
iwamot
PRO
0
100
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
iwamot
PRO
3
170
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
15
12k
Other Decks in Technology
See All in Technology
穢れた技術選定について
watany
3
350
なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren't really working
vtryo
3
3.6k
Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離
kekke_n
1
2.9k
地域 SRE コミュニティ最前線 / SRE NEXT 2026 Discussion Night Track C
muziyoshiz
0
210
個人開発で育てる「大規模設計の苗床」 - AI時代の1人開発から始める業務への知識接続 / The Seedbed for Large-Scale Design - From AI-Era Solo Projects to Professional Knowledge
bitkey
PRO
0
160
アカウントが増えてからでは遅い? ~ マルチアカウント統制の勘所 ~
kenichinakamura
0
220
[2026-07-15] AI Ready なはずだったアーキテクチャと、見えてきた課題・次に目指す状態
wxyzzz
4
2.8k
完全自律ロボットを作りたくて、先に開発を自律させた話(ROS Japan UG #63 LT)
rryz09
0
500
「早く出す」より「事業に効く」 ── 顧客の業務サイクルから逆算するAI時代の二重ループ開発と「変化の設計者」 / devsumi2026
rakus_dev
1
220
AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 / ai-agent-saas-virtualization
flatt_security
2
3.8k
AI駆動開発におけるQAエンジニアの役割事例 〜AI駆動開発の現場から〜
kobayashiyorimitsu
0
500
シンガポールで登壇してきます
yama3133
0
110
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
[SF Ruby Conf 2025] Rails X
palkan
2
1.2k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.6k
Believing is Seeing
oripsolob
1
170
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.7k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
190
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
330
Fashionably flexible responsive web design (full day workshop)
malarkey
408
67k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.6k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.5k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Transcript
復号できなくなると怖いので、 AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版 2025-09-05 Cloud Operator Days
Tokyo 2025 https://cloudopsdays.com/ ENECHANGE株式会社 岩本隆史
どんな話? 暗号化データの復号に必要なキーを、うっかり削除できないようにした話 得られるもの:クラウド運用における、うっかりミスを防ぐ視点 ポイント: 「簡単」ではなく、あえて「面倒」にするという発想
自己紹介 岩本 隆史 @iwamot ENECHANGE株式会社 VPoT 前職:AWS 技術サポート AWS Community
Builder (Cloud Operations)
「面倒」にした経緯
サービス終了に伴い、AWS環境を削除 事業部からの削除リクエストを受諾 DBの最終スナップショットを作成 各種リソースを削除
11日後:復号できなくなることに気づく DBの暗号化キーまで削除しようとしていた(ぼくのうっかりミス) ありがたいことに、削除は保留されていた(デフォルト30日待機) このまま待機期間が過ぎると、スナップショットが復号できなくなる 虫の知らせで、たまたま気づけた
気づいて助かったが、 「うっかり削除」は怖い キーの削除をキャンセルし、事なきを得た とはいえ、今後も「うっかり削除」のリスクが残る
そこで、キーの削除を「面倒」にしてみた deletable = true タグが付いたキーのみ削除を許可するルール AWS Organizationsというサービスのポリシーで実装
リソースコントロールポリシーの実例 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal":
"*", "Action": "kms:ScheduleKeyDeletion", "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceTag/deletable": "true" } } } ] }
Slack通知も実装し、本格導入
タグがないキーは削除が拒否される
タグの付いたキーは削除が待機される
うっかりミスを防ぐ視点
不可逆で、とくに危険な操作はないか 例:クラウド側で、待機期間や復旧可能期間が用意されている操作 AWS Secrets Managerシークレットの削除(デフォルトで7日は待機) Azure Key Vaultの論理的な削除(デフォルトで90日は復旧可能) Google Cloudプロジェクトの削除(デフォルトで30日は待機)
「リーエン」という仕組みで削除を拒否することも可能
ルールによる拒否や、イベントの検知は不要か うっかりミスは原理的に防ぎたい 危険な操作が行われたら、念のためアラートしたい これらのニーズは十分に満たせているか
対応のポイント
あえて「面倒」にするという発想 危険な操作が本当に必要な場合もある → 無条件に拒否はできない 手間をかければ操作できる状態を目指す タグでなくても「面倒」ならよい 承認フェーズを設ける リソースロックをかける(Azureなど)
まとめ
こんな話でした 暗号化データの復号に必要なキーを、うっかり削除できないようにした クラウド運用における、うっかりミスを防ぐ視点 不可逆で、とくに危険な操作はないか ルールによる拒否や、イベントの検知は不要か あえて「面倒」にすべき操作はないか、考えてみませんか?