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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
iwamot
PRO
September 05, 2025
Technology
180
1
Share
復号できなくなると怖いので、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
0
410
8万デプロイ
iwamot
PRO
2
350
AIエージェント・マイクロサービス時代。AWSでの手軽な構築法を考えて試してみた
iwamot
PRO
1
89
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
10
2.5k
Developer Certificate of Origin、よさそう
iwamot
PRO
0
70
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
iwamot
PRO
3
150
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
14
12k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1.3k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
690
Other Decks in Technology
See All in Technology
最新技術を"今は選ばない"という技術選定
leveragestech
PRO
0
340
マンション備え付けのネットワークとLTE回線を組み合わせた ネットワークの安定化の考案
harutiro
1
140
O'Reilly Infrastructure & Ops Superstream: Platform Engineering for Developers, Architects & the Rest of Us
syntasso
0
320
AIAgentと取り組むKaggle
508shuto
2
470
10サービス以上のメール到達率改善を地道に継続的に進めている話 / Continue to improve email delivery rates across multiple services
yamaguchitk333
6
2.3k
AI時代に求められる思考のパラダイムシフト
nrinetcom
PRO
0
110
Oracle AI Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
6
1.7k
JaSSTに関わることで変わった人生観 #jasstnano
makky_tyuyan
0
160
その英語学習、AWSで代替できませんか?
suzutatsu
1
180
続 運用改善、不都合な真実 〜 物理制約のない運用改善はほとんど無価値 / 20260518-ssmjp-kaizen-no-value-without-physical-constraints
opelab
2
290
Claude Code で使える DuckDB Skills を試してみた / DuckDB Skills and Claude Code
masahirokawahara
1
1.9k
Gaussian Splattingの実用化 - 映像制作への展開
gpuunite_official
0
210
Featured
See All Featured
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
1k
How to Ace a Technical Interview
jacobian
281
24k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
250
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.2k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
740
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Code Review Best Practice
trishagee
74
20k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
790
HDC tutorial
michielstock
2
670
The Illustrated Children's Guide to Kubernetes
chrisshort
51
52k
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など)
まとめ
こんな話でした 暗号化データの復号に必要なキーを、うっかり削除できないようにした クラウド運用における、うっかりミスを防ぐ視点 不可逆で、とくに危険な操作はないか ルールによる拒否や、イベントの検知は不要か あえて「面倒」にすべき操作はないか、考えてみませんか?