決済関連のSaaSプロダクトを運営するその企業は、AWS上に本番環境を構築し、数万件の顧客トランザクションを日次で処理していました。開発チームは10名ほど、インフラ専任は1名。監視はCloudWatchの基本アラートのみという状態でした。
金曜日の夕方、経理担当者が月次のAWS請求を確認したとき、前月比で約3倍の利用料金が計上されていることに気付きました。身に覚えのないリージョンで、大量のEC2インスタンスが起動されている。最初は「開発チームの検証環境の消し忘れだろう」と考えましたが、確認を進めるうちに、誰にも心当たりがないことが分かりました。
この時点で分かっていなかったことは、いつから侵入されていたのか、どのIAMユーザーが悪用されたのか、顧客データへのアクセスがあったかどうか——そのすべてでした。
判断を難しくしていたのは、複数の制約が同時に存在していたことです。
まず、事業停止ができない。決済系のプロダクトであるため、サービスを止めれば加盟店・エンドユーザーに即座に影響が出ます。「調査のためにシステムを止める」という選択肢は、経営的に取れませんでした。
次に、ログの保全が不十分だったこと。CloudTrailは有効でしたが、S3のデータイベントログやVPCフローログは取得していない状態でした。攻撃者がログを改ざんしている可能性も排除できません。
さらに、社内に判断できる人材がいなかった。インフラ担当は1名で、フォレンジックの経験はありません。CTOは前年に退任しており、セキュリティの意思決定を担える人間が組織にいない状態でした。
急ぐべきは証拠の保全と被害範囲の把握。しかしサービスを止めずに進めなければならない——このバランスが、このケースの最も難しい点でした。
同社の顧問弁護士から「クラウドのフォレンジックができるチームを探している」という形で、金曜の夜にopen brainへ連絡がありました。弁護士経由での相談だったため、NDAは翌朝に締結。その日のうちにオンラインでの緊急ヒアリングを開始しました。
初回のヒアリングですぐに決めたことは3つ。CloudTrailログの即時バックアップ、不審なIAMユーザーの権限縮小（削除ではなく縮小）、そして経営陣への第一報のタイミングと内容です。
あえて決めなかったこともありました。「どこまで調査するか」のスコープは、初動で被害の輪郭が見えてから決める、としました。最初に調査範囲を狭く決めてしまうと、後から重大な見落としにつながるためです。
クラウド環境の侵害対応で最も重要なのは、「速さ」ではなく「順序」です。何を先に保全し、何を後回しにするか。どの情報を誰にいつ伝えるか。この優先順位を間違えると、技術的に正しい対応をしていても、組織としての判断が崩れます。
open brain が大切にしているのは、初動で「すべてを解決する」のではなく、「正しい順番で進められる状態をつくる」ことです。何が分かっていて、何がまだ分かっていないのか。それを正直に共有することが、結果として最短の解決につながると考えています。
また、今回のように「CTO不在」「セキュリティ専任者なし」という体制は、決して珍しいことではありません。その状態で侵害が起きたとき、外部の専門チームがどのように判断を支えるか——それがフォレンジックサービスの本質的な価値だと考えています。
「何かおかしい」と気づいた時点で、すでに正しい判断の第一歩を踏み出しています。クラウド環境の異常は、早く動くほど保全できる証拠が多く、選択肢が広がります。
正確な状況把握ができていなくても構いません。「分からないこと」を整理するところから一緒に始められます。
NDA（守秘義務契約）は初回相談前に締結可能です。緊急時は24時間体制で一次受付を行っています。