復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版

2025-09-05
Cloud Operator Days Tokyo 2025
https://cloudopsdays.com/

Transcript

1. 復号できなくなると怖いので、 AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版 2025-09-05 Cloud Operator Days Tokyo 2025 https://cloudopsdays.com/ ENECHANGE株式会社 岩本隆史
2. どんな話？ 暗号化データの復号に必要なキーを、うっかり削除できないようにした話 得られるもの：クラウド運用における、うっかりミスを防ぐ視点 ポイント： 「簡単」ではなく、あえて「面倒」にするという発想
3. 自己紹介 岩本 隆史 @iwamot ENECHANGE株式会社 VPoT 前職：AWS 技術サポート AWS Community Builder (Cloud Operations)
4. 「面倒」にした経緯
5. サービス終了に伴い、AWS環境を削除 事業部からの削除リクエストを受諾 DBの最終スナップショットを作成 各種リソースを削除
6. 11日後：復号できなくなることに気づく DBの暗号化キーまで削除しようとしていた（ぼくのうっかりミス） ありがたいことに、削除は保留されていた（デフォルト30日待機） このまま待機期間が過ぎると、スナップショットが復号できなくなる 虫の知らせで、たまたま気づけた
7. 気づいて助かったが、 「うっかり削除」は怖い キーの削除をキャンセルし、事なきを得た とはいえ、今後も「うっかり削除」のリスクが残る
8. そこで、キーの削除を「面倒」にしてみた deletable = true タグが付いたキーのみ削除を許可するルール AWS Organizationsというサービスのポリシーで実装
9. リソースコントロールポリシーの実例 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "kms:ScheduleKeyDeletion", "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceTag/deletable": "true" } } } ] }
10. Slack通知も実装し、本格導入
11. タグがないキーは削除が拒否される
12. タグの付いたキーは削除が待機される
13. うっかりミスを防ぐ視点
14. 不可逆で、とくに危険な操作はないか 例：クラウド側で、待機期間や復旧可能期間が用意されている操作 AWS Secrets Managerシークレットの削除（デフォルトで7日は待機） Azure Key Vaultの論理的な削除（デフォルトで90日は復旧可能） Google Cloudプロジェクトの削除（デフォルトで30日は待機） 「リーエン」という仕組みで削除を拒否することも可能
15. ルールによる拒否や、イベントの検知は不要か うっかりミスは原理的に防ぎたい 危険な操作が行われたら、念のためアラートしたい これらのニーズは十分に満たせているか
16. 対応のポイント
17. あえて「面倒」にするという発想 危険な操作が本当に必要な場合もある → 無条件に拒否はできない 手間をかければ操作できる状態を目指す タグでなくても「面倒」ならよい 承認フェーズを設ける リソースロックをかける（Azureなど）
18. まとめ
19. こんな話でした 暗号化データの復号に必要なキーを、うっかり削除できないようにした クラウド運用における、うっかりミスを防ぐ視点 不可逆で、とくに危険な操作はないか ルールによる拒否や、イベントの検知は不要か あえて「面倒」にすべき操作はないか、考えてみませんか？