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
1
90
復号できなくなると怖いので、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
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
8
1.3k
Developer Certificate of Origin、よさそう
iwamot
PRO
0
19
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
iwamot
PRO
3
78
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
14
11k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1.1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
560
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
560
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
22k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
PRO
3
1.3k
Other Decks in Technology
See All in Technology
なぜThrottleではなくDebounceだったのか? 700並列リクエストと戦うサーバーサイド実装のすべて
yoshiori
7
2.4k
エンジニアにとってコードと並んで重要な「データ」のお話 - データが動くとコードが見える:関数型=データフロー入門
ismk
0
440
Amazon ECS デプロイツール ecspresso の開発を支える「正しい抽象化」の探求 / YAPC::Fukuoka 2025
fujiwara3
7
860
エンジニア採用と 技術広報の取り組みと注力点/techpr1112
nishiuma
0
130
開発者から見たLLMの進化 202511
ny7760
1
170
Flutterで実装する実践的な攻撃対策とセキュリティ向上
fujikinaga
1
310
AI時代におけるドメイン駆動設計 入門 / Introduction to Domain-Driven Design in the AI Era
fendo181
0
650
旧から新へ: 大規模ウェブクローラの Perl から Go への移行 / YAPC::Fukuoka 2025
motemen
0
200
Digitization部 紹介資料
sansan33
PRO
1
5.9k
データ組織ゼロから投資を得るまでの軌跡と未来図 〜AIの前にやるべきこと〜 / Building a Data Organization from Scratch: The Journey to Securing Investment and a Vision for the Future
kaonavi
0
120
激動の2025年、Modern Data Stackの最新技術動向
sagara
0
1.2k
ソフトウェア開発現代史: 55%が変化に備えていない現実 ─ AI支援型開発時代のReboot Japan #agilejapan
takabow
1
1.2k
Featured
See All Featured
Embracing the Ebb and Flow
colly
88
4.9k
Designing Experiences People Love
moore
142
24k
Done Done
chrislema
186
16k
The Language of Interfaces
destraynor
162
25k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Stop Working from a Prison Cell
hatefulcrawdad
272
21k
How to Think Like a Performance Engineer
csswizardry
28
2.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
The Cult of Friendly URLs
andyhume
79
6.7k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Building an army of robots
kneath
306
46k
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など)
まとめ
こんな話でした 暗号化データの復号に必要なキーを、うっかり削除できないようにした クラウド運用における、うっかりミスを防ぐ視点 不可逆で、とくに危険な操作はないか ルールによる拒否や、イベントの検知は不要か あえて「面倒」にすべき操作はないか、考えてみませんか?