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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
iwamot
PRO
September 05, 2025
Technology
1
150
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版
2025-09-05
Cloud Operator Days Tokyo 2025
https://cloudopsdays.com/
iwamot
PRO
September 05, 2025
Tweet
Share
More Decks by iwamot
See All by iwamot
8万デプロイ
iwamot
PRO
2
270
AIエージェント・マイクロサービス時代。AWSでの手軽な構築法を考えて試してみた
iwamot
PRO
1
70
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
10
2.1k
Developer Certificate of Origin、よさそう
iwamot
PRO
0
55
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
iwamot
PRO
3
120
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
14
12k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1.3k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
660
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
630
Other Decks in Technology
See All in Technology
LINEヤフーにおけるAIOpsの現在地
lycorptech_jp
PRO
5
2.1k
モジュラモノリス導入から4年間の総括:アーキテクチャと組織の相互作用について / Architecture and Organizational Interaction
nazonohito51
3
1.4k
AIエージェント×GitHubで実現するQAナレッジの資産化と業務活用 / QA Knowledge as Assets with AI Agents & GitHub
tknw_hitsuji
0
160
ガバメントクラウドにおけるAWSの長期継続割引について
takeda_h
2
5.4k
品質を経営にどう語るか #jassttokyo / Communicating the Strategic Value of Quality to Executive Leadership
kyonmm
PRO
2
1.1k
Goのerror型がシンプルであることの恩恵について理解する
yamatai1212
1
290
めちゃくちゃ開発するQAエンジニアになって感じたメリットとこれからの課題感
ryuhei0000yamamoto
0
250
Visional 28新卒プロダクト職(エンジニア/デザイナー)向け 会社説明資料 / Visional Company Briefing for Newgrads 28
visional_engineering_and_design
1
110
DDD×仕様駆動で回す高品質開発のプロセス設計
littlehands
4
2k
_Architecture_Modernization_から学ぶ現状理解から設計への道のり.pdf
satohjohn
2
670
A Casual Introduction to RISC-V
omasanori
0
540
How to install a gem
indirect
0
220
Featured
See All Featured
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
160
Abbi's Birthday
coloredviolet
2
5.6k
A Modern Web Designer's Workflow
chriscoyier
698
190k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
310
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.1k
Paper Plane (Part 1)
katiecoart
PRO
0
5.8k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
2.5k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
84
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.5k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.1k
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など)
まとめ
こんな話でした 暗号化データの復号に必要なキーを、うっかり削除できないようにした クラウド運用における、うっかりミスを防ぐ視点 不可逆で、とくに危険な操作はないか ルールによる拒否や、イベントの検知は不要か あえて「面倒」にすべき操作はないか、考えてみませんか?