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
71
復号できなくなると怖いので、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
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版
iwamot
PRO
1
69
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
14
11k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
520
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
530
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
22k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
PRO
3
1.3k
始めないともったいない!SLO運用で得られる3つのメリット
iwamot
PRO
1
160
あなたの人生も変わるかも?AWS認定2つで始まったウソみたいな話
iwamot
PRO
3
8.3k
Other Decks in Technology
See All in Technology
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
1.6k
5000万ダウンロードを超える漫画サービスを支えるログ基盤の設計開発の全て
ldf_tech
0
280
EncryptedSharedPreferences が deprecated になっちゃった!どうしよう! / Oh no! EncryptedSharedPreferences has been deprecated! What should I do?
yanzm
0
820
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
480
組織規模に応じたPlatform Engineeringの実践
hacomono
PRO
0
150
Snowflake Intelligence × Document AIで“使いにくいデータ”を“使えるデータ”に
kevinrobot34
1
170
品質保証に注目したAIプロダクト開発
sansantech
PRO
1
120
Wantedlyの開発組織における生成AIの浸透プロジェクトについて
kotominaga
2
180
Apache Icebergを体験しよう (2025.9.21)
simosako
5
600
Rust In Python
lycorptech_jp
PRO
3
270
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい勘所を集めてみました! - / How to start Scrum that is not written in the Scrum Guide 2nd
takaking22
2
420
Windows 11 version 25H2 への準備はできていますか?
tamaiyutaro
1
110
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Making Projects Easy
brettharned
118
6.4k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Practical Orchestrator
shlominoach
190
11k
Automating Front-end Workflow
addyosmani
1371
200k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Docker and Python
trallard
46
3.6k
Speed Design
sergeychernyshev
32
1.1k
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
The Art of Programming - Codeland 2020
erikaheidi
56
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キーの削除を「面倒」にしたら安心できた うっかり削除すると、復号できなくなるので怖い 削除を「面倒」にする案がひらめき、実装した 「うっかり」は防ぎつつ「ちゃんと考えれば削除できる」状態が実現できた 学び:危険な操作を「面倒」にする案、広く応用できそう 何かないか考えてみよう