シュレーディンガーの設定ミス

木曜日の午後、少し早めに退勤しようとしています。なぜなら……そうできるからです。ところが、あの厄介な「通知の配達人」（別名 Slack）が、セキュリティアラートのチャンネルに新しいメッセージを投げ込んできます。

困りました。誰かがストレージボリュームのスナップショットを公開にしたのです。これは攻撃でしょうか。それとも操作ミスでしょうか。あるいは、ポリシーを知らなかっただけでしょうか。

設定ミスには3つの状態がある

私はこれを シュレーディンガーの設定ミス と呼び始めました。量子力学の原理を使って情報セキュリティを説明するという悪癖があるためです。シュレーディンガーの猫をご存じないとすれば驚きですが、これはエルヴィン・シュレーディンガーが量子の重ね合わせという逆説をアルベルト・アインシュタインに示すために用いた有名な思考実験です。ごく短く言えば、放射性崩壊によって作動する毒物とともに猫を箱に入れると、その猫は生きてもいなければ死んでもおらず、したがって箱を開けて確認するまでは生きていると同時に死んでいる状態にある、というものです。

はい、不条理です。そこがまさに要点でした。とりわけ、箱に閉じ込められるのを断固として好まない猫を飼っている人間にとっては。もっとも、猫が自分から箱に入るのに人に入れられると激怒することについてはブログシリーズが1本書けてしまうので……話がそれました。

クラウドセキュリティの話に戻ります。この思考実験の根底にある概念は、あるものが観測されるまでは複数の状態を同時に取り、観測という行為が答えを確定させるというものです。当然ながら、私は自分の目的に合わせて解釈を曲げ、単純化していますので、物理学の素養をお持ちの方は怒りのメールを送らないでください。

この概念をクラウドに当てはめると、あらゆる設定ミスは、調査して原因を特定するまで、攻撃・操作ミス・ポリシー違反のいずれでもある状態に置かれています。

この概念を裏づけるクラウドの特性は5つあります。

• クラウド／開発チームは、自らのクラウドインフラを直接管理する裁量をより多く持つ傾向があります。
• クラウドの管理プレーンはインターネット経由でアクセスできます。
• （現時点で）クラウド攻撃の最も一般的な起点は認証情報の窃取です。
• 多くの設定ミスは、攻撃者の行為と見分けのつかない状態を生み出します（例：スナップショットの公開）。
• 設定ミスは偶発的に発生しやすく、また必要に迫られて意図的に行われた結果、実行者がそれをセキュリティ上の問題だと認識していない場合もあります。

この概念は従来型インフラにも当てはまりますが、チームの裁量が小さいぶん程度ははるかに低くなります。アプリの開発者が、ファイアウォールのルールやルートテーブルを直接変更できることは通常ありません。クラウドでは、少なくとも一部の環境において、それがごく一般的です。

反証されるまでは攻撃と想定する

クラウドにおけるインシデント対応で特に重要な原則の1つは、設定ミスを必ずセキュリティイベントとして扱い、反証されるまでは攻撃であると想定しなければならない、という点です。

これは発想の転換です。セキュリティ部門は脆弱性やアタックサーフェスという観点で考えることに慣れていますが、それらは定期的にスキャンする対象であり、おおむね修正すべき課題として扱われてきました。私が提案しているのは、クラウドコンピューティングにおいて、検出された設定ミスをIDSやEDRのアラートと同じレベルに引き上げることです。それらは単なるコンプライアンス上の問題ではなく、侵害の潜在的な兆候です。

もちろん、これはあらゆる環境のあらゆる設定ミスに当てはまるわけではありません。フィルタリングと優先順位付けが必要です。さらに言えば、コミュニケーションが欠かせません。設定ミスが悪意ある攻撃かどうかを見極める最も簡単な方法は、たいていの場合、変更を行った本人に意図的なものだったかを尋ねることだからです。

トレーニングクラス向けに要点を絞り込む必要があったため、セキュリティテレメトリの主要なフィードを3つにまとめました。

• ログ
• クラウドプロバイダーのイベント（例：Security Hub のイベント）
• クラウドの設定ミス（CSPMツール、OSSスキャナーなどから得られるもの）

クラウドセキュリティに携わる多くの方は、この概念をすでに体得していますが、それを言語化して説明することは多くありません。Cloud Detection and Response（CDR）ツールの中には、一部の設定ミスに対してアラートを生成するものがあります。これは、レポートやダッシュボード上に検出結果を作成するという従来のCSPMツールの動作とは異なります。そうした検出結果はコンプライアンスや一般的なセキュリティ衛生の観点で重要ですが、攻撃者はディスクイメージを他のアカウントと共有したり、IAMロールにバックドアアクセスを仕込んだりといった悪質な行為を行うため、一部の設定ミスは、反証されるまで侵害の兆候として扱う必要が本当にあります。

社内（および DisruptOps プラットフォーム）では、特定されたAPIコールに基づいて評価を実行するリアルタイムの脅威検出機能群でこれに対応しています。設定ミスを特定し、上でご覧いただいたように Slack（または Teams）経由でセキュリティ担当者とプロジェクトオーナーに通知するまで、約15～30秒です。これらのアラートは GuardDuty の検出結果やその他の侵害の兆候と同じように扱われますが、ChatOps を用いて挙動を確認することで、毎回詳細な分析を行うことなく、きわめて迅速にトリアージできます。

要点は次のとおりです。重要なクラウド設定ミスはほぼリアルタイムで扱い、反証されるまでは侵害の兆候として扱ってください。

本記事の執筆にあたって、猫は一匹も傷つけていません。