四つの事故経路と、それぞれの遮断線
一言でいうと
クラウドのセキュリティ事故は、たいてい巧妙な攻撃ではなく、自分たちが開けておいたドアから入ってきます。経路はいくつかに決まっていて、それぞれに対応する遮断線も決まっています。
防御のための内容です。各経路ごとに、「何が間違っていて、何で防ぐか」をペアにして扱います。
なぜ必要なのか
クラウドの事故は、製品ごとに違って見えても、公開設定、漏れた資格情報、過剰な権限、メタデータの悪用という、いくつかの経路に収束します。経路ごとの最初の遮断線と、事故後の証拠保全の順序を知っていれば、同じ設定ミスが組織全体の侵害に広がるのを防げます。
どう動くのか
経路1: 公開されたストレージ
最もよくあります。バケットを公開にして、忘れてしまうことです。
どう起きるか: 一時的にファイルを共有しようと開けて、元に戻さない。または、静的Webサイトホスティングの設定をしていて、全体を公開に変えてしまう。
遮断線
- アカウントレベルで、パブリックアクセスのブロックを有効にしておく(個別のバケット設定を無効化します)
- 組織のガードレールで、公開設定そのものをDeny
- 設定の監視で、公開されたバケットを自動検出して通知
経路2: 漏れた資格情報
どう起きるか: リポジトリへのコミット、CIログへの出力、スクリーンショット、チャット。公開リポジトリに上がったキーは、分単位で発見されます。
遮断線
- そもそも長期のキーを作らない(ロール・OIDC)
- コミット前のシークレットスキャンをフックでかける
- 異常な使用の検出: 普段と違うリージョン・時刻・API呼び出し量
- 予算アラート: マイニング用のインスタンスは、料金の急増で先に表に出ます
最後の項目が、意外と実効性が大きいです。事故を防ぐことはできませんが、数時間以内に気づけます。
経路3: 過剰な権限の悪用
どう起きるか: 内部者のミス、または侵害されたアカウントが、広い権限をそのまま使う。s3:*を持つプリンシパルが侵害されると、削除までできます。
遮断線
- 最小権限 + 権限境界
- 削除・権限変更のような高リスクの操作に、条件を強化(MFAの要求など)
- 重要なデータに、バージョン管理と削除防止を有効にする
- バックアップを別のアカウントに置く。これが決定的です
侵害されたアカウントからバックアップまで消せるなら、それはバックアップではありません。アカウントの境界を越えて置いておいてこそ、ランサムの状況で生き残れます。
経路4: メタデータサービスの悪用(SSRF)
どう起きるか: アプリケーションにURLを入れると、サーバーがそのアドレスにリクエストを送る機能(画像の取得など)があり、攻撃者がインスタンスのメタデータのアドレスを入れます。すると、そのインスタンスの一時的な資格情報がレスポンスとして出てきます。
遮断線
- メタデータサービスの最新バージョンだけを許可する(トークンが必要な方式)
- アプリケーションで、ユーザーが提供したURLを検証する。プライベートアドレス範囲を遮断
- インスタンスロールの権限を最小に。漏れても、できることが少なくなります
事故が起きたときの順序
- 範囲を決める: どの資格情報・リソースが関係したか
- 遮断する: キーの取り消し、ロールの信頼ポリシーの修正、セッションの無効化
- 保全する: ログとスナップショットを先に確保する。消すと調査が終わります
- 調査する: 監査ログで、何をしたかのタイムラインを復元する
- 防ぐ: 同じ経路が再び開かないよう、ガードレールを追加する
2つ目でよく見落とされるのが、すでに発行された一時的な資格情報です。ロールのポリシーを変えても、すでに出たセッションは期限切れまで有効なことがあるので、セッションの無効化を別に行う必要があります。
平時にしておく5つのこと
- 監査ログを有効にして、別のアカウントに保管します
- ルートアカウントにMFAをかけ、日常的には使いません
- 予算アラートをかけます。マイニング用の使用量の急増を、あとから発見する補助的な検出線です
- パブリックアクセスのブロックを、アカウントレベルで有効にします
- バックアップを別のアカウントに置きます
権限を絞る作業を実際に回す
最小権限は誰もが同意しますが、実行されません。絞っていて何かが止まると、その人が責められるからです。そのため、順序を逆にします。まず測り、そのあとで絞ります。
実際に使った権限を基準にします。クラウドごとに、アクセス記録を分析して「過去90日間に、このロールが実際に呼び出したAPI」を抽出してくれるツールがあります。人が想像してポリシーを書くより正確で、何より、何が壊れるかを事前に知れます。
一度に塞がず、まず警告を残します。ポリシーを2つに分けて、実際に塞ぐものはそのままにしておき、絞ったポリシーには「このリクエストは新しいポリシーでは拒否されます」を記録だけさせます。数日間見守って、記録が静かになったら、そのときに切り替えます。
長寿命のキーをなくすほうが、ポリシーを整えるより効果が大きいです。流出事故の大半は、ポリシーが広いからではなく、どこかに書かれていたアクセスキーが原因です。人はSSOに、ワークロードはロールの委任やOIDC連携に替えれば、盗まれるキーそのものがなくなります。CIからクラウドにつなぐ場面が特にそうです。
残ったキーには、期限切れを強制します。動いているものと動いていないものをリストで管理せず、90日が過ぎたら自動的に無効になるようにします。人の誠実さに頼る統制は、忙しい四半期に必ず崩れます。
権限境界を1つ置くと、ミスの幅が減ります。開発者にロールを作る権限を与えつつ、そのロールが持てる権限の上限を決めておきます。そうすれば、自分で権限を広げる経路が塞がれながらも、日常の作業を他人に頼まなくて済みます。リクエストと承認が減る分、実際に守られます。
最後は記録です。監査ログを書き込み専用のストレージに別に送り、そのストレージを削除できる人を、別のアカウントに分離します。侵害後に最初にすることが、ログを消すことなので、ログが残っているかどうかが、調査できるかどうかを分けます。
現場での姿
- 普段と違うリージョンで、権限の探索が続く → 監査ログベースの異常行動アラートが先に鳴りました。
- 遅れて料金も急増した → コストアラートは有用でしたが、侵害の最初の検出線ではありませんでした。
- キーを取り消したのに攻撃が続く → すでに発行されたセッションが生きていました。
- ランサムの後、バックアップも消された → 同じアカウントにありました。
次のコース
ネットワーク。権限が「誰が」を決めるなら、ネットワークは「どこから」を決めます。