長らくサイバー復旧とは、データを復元することを意味していた。サーバーを再稼働させ、ファイルを復旧し、いくつかのパスワードをリセットする。アイデンティティは、本当の作業が終わってから対処するものだった。
その考え方が、組織を苦境に追い込んでいる。
Palo Alto NetworksのUnit 42による「Global Incident Response Report」によれば、インシデント対応の調査の約90%がアイデンティティ侵害に行き着く。攻撃者がたいてい狙っているのは、目立たない技術的脆弱性ではない。認証情報を足がかりに侵入しているのだ。盗まれたパスワード、悪用されるサービスアカウント、ソーシャルエンジニアリング。攻撃の時点で彼らは正規ユーザーに見える。そして誰かが気づくころには、彼らは何週間も環境内を動き回り、権限をひそかに変更し、特権を昇格させ、足場を築いている。
筆者は以前から、この趣旨の主張を続けてきた。2018年か2019年ごろ、内部脅威に注力する企業と話した際、攻撃の瞬間には基本的にすべてが内部脅威になる、と指摘した。昔ながらの意味で「ハッキング」されることは、いまやめったにない。始まりはアイデンティティだ。その後変わったのは、アイデンティティがカバーする範囲が大きく広がった点である。
誰にも良い答えがなかった問題
仮想マシンを復元したり、データベースを復旧したりすることは、すでに解決済みの問題だ。信頼できるアイデンティティ環境を復元することは、そうではない。
アイデンティティは静的な対象ではない。ユーザー、グループ、ロール、サービスアカウント、そしてシステム間で連鎖・継承される権限からなる関係性の網である。現代の企業は1つのディレクトリで動いてはいない。オンプレミスのActive Directory、クラウドベースのEntra ID、Oktaのようなアイデンティティプロバイダー（IdP）、さらに自動化ツールやAIエージェントのスタックが拡大し、それぞれが固有のアイデンティティとアクセス権を持つ。そしてそのすべてが常に変化している。
長年、攻撃で何が起きたかを理解する主な手段はログだった。SIEM（セキュリティ情報・イベント管理）のデータ、イベントログ、監査証跡。そこから分かるのは、脅威がだいたいどこを移動し、だいたいいつ起きたか、といったことだ。筆者はJaspreet Singh氏（DruvaのCEO兼創業者）とこの点について話す機会があり、同氏は要点を的確に表現した。従来のフォレンジック（デジタル鑑識）モデルはログに支配され、ログ記録はラテラルムーブメント（横展開）を理解する唯一の仕組みだった。しかしログは全体像の一部しか示さない。攻撃者がどのように侵入したのか、つまりどのアクセスポイントや権限が「入口」を開いたのかを教えてはくれない。さらに、その結果として下流で何が変化したのかも分からない。どのデータが触られたのか。どの権限がひそかに改変されたのか。復元の際に何を実際に信頼できるのか。
Singh氏はまた、復旧がきれいで直線的な順序で進むという考えにも異を唱えた。実際は循環的なループに近い。復元し、調査し、分離し、再び調査し、さらに復元する。チェックボックスを埋めて次へ進む、というわけにはいかない。進めながら検証し続ける必要がある。
NHIの問題は悪化している
人間のアイデンティティ管理が厄介だとすれば、非人間アイデンティティ（NHI）のほうはさらに混沌としている。
サービスアカウント、APIトークン、マシン認証情報。これらは、多くの企業環境では人間のアイデンティティをはるかに上回る。Singh氏は具体的な数字も挙げた。従業員約1,200人の企業であれば、2,000以上のトークンを管理している可能性があるという。しかもこれは、AIエージェント、IoTデバイス、SaaS連携を考慮する前の話で、それぞれが固有のアイデンティティとアクセス権を持つ。
IT管理側で時間を過ごしたことがある人なら、この問題を即座に理解できるはずだ。誰かがアクセスを必要とする――緊急だ――付与する。だが、外すように頼まれることは誰もない。これが、ゾンビアカウントや休眠認証情報を生んできた昔からの経緯である。いま違うのは規模だ。エージェント型AI（agentic AI）と自動化ワークフローにより、同じ力学がユーザーアカウントではなくトークンで起き、しかも指数関数的な量で進行する。トークンは過剰な権限を与えられがちで、監視も不十分なまま放置されている。
Singh氏は、この領域で業界がまだ初期段階にあることを率直に認めた。より良く管理するための概念――ジャストインタイムアクセス、意図ベースの認可――は存在するものの、企業規模で確実に機能させるには、なお数年を要するという。
ベンダーが注力している領域
アイデンティティ・レジリエンスに関するより思慮深いアプローチは、それをバックアップの問題として扱う段階を超えている。方向性は、アイデンティティを継続的に進化するものとしてモデル化し、特定時点のディレクトリオブジェクトをスナップショットするだけでなく、時間の経過に伴う関係性と振る舞いを追跡することへと移っている。
Druvaは、同社の「Identity Resilience」プラットフォームがMicrosoft Entra IDに加え、OktaとMicrosoft Active Directoryもカバーするようになったと発表した。これにより、企業で最も一般的な3つのアイデンティティプロバイダーを、保護、サイバー復旧、脅威検知のために1つのプラットフォームに集約したことになる。同社は差別化要因として、「identity-aware recovery（アイデンティティを認識した復旧）」と呼ぶ機能を掲げる。これは「Dru MetaGraph」というグラフベースのインテリジェンス層の上に構築されており、環境全体にわたってアイデンティティ、権限、データ、アクティビティの関係性を継続的にマッピングするという。
Singh氏は、第三者の契約業者が攻撃者となりプロジェクトデータへアクセスした侵害事例について、実際の顧客例をもとに説明してくれた。調査の結果、侵入はシステム間の移動に使われる既知のバイナリツールに行き着いた。鍵となったのは、バックアップデータを検索して痕跡（アーティファクト）を探せたことだ――どのマシンにそのバイナリがインストールされていたのか、どのアクセス権限がネットワーク間の移動に使われたのか。バックアップ環境を検索可能で文脈を伴う形で見渡せることが、本来なら数週間かかり得た調査を、チームが実務として効率的に進められる水準に圧縮した。
「グラフの面白い点は、特にアイデンティティとともにMetaGraphをClaudeに公開したときにある。タスクを与えるのではなく、『これで何ができる？』と尋ねた。すると『権限の回帰分析（regression）を実行できる。システム間の変更の連鎖を見られる』と返してきた。だからグラフを構築すれば、通常のアナリストには理解しきれない問題を、最終的にAIが解けるようになる」
要点は、単にデータが存在することではない。熟練したアナリストが、何十ものシステムにまたがるつながりを手作業で追跡しなくても、AIが実際に推論できる形でデータが構造化されている、という点にある。
IDCのリサーチマネジャーであるJohnny Yu氏は、Druvaのプレスリリースの中で、インシデント後に何を信頼できるかを検証することはオブジェクトを復元することより難しい問題であり、侵害と正当な活動を区別するには、アイデンティティとデータの関係性を理解する必要があると述べた。
実務上、何を意味するのか
復旧の備えを考えるセキュリティチームとITチームにとって、この会話から浮かび上がる点はいくつかある。
多くの組織は、6カ月前に自社のアイデンティティ環境がどのような状態だったのか、という問いに対して実質的な答えを持っていない。いくつかのスナップショットはある。だが通常、欠けているのは関係性の文脈だ――誰が何にアクセスできたのか、そのアクセスが時間とともにどう変わったのか、どのシステムがどのアイデンティティに依存していたのか。それがなければ、復元ポイントの妥当性確認はほとんど当て推量になる。
アイデンティティの復元手順の順序は重要だが、一直線ではない。Singh氏は、作業の順番に普遍的な手順書は存在しないと明言した。実際のプロセスは反復的である。ただし一般原則は成り立つ。アイデンティティがまだ信頼できない環境に、下流のアプリケーションを復元することはできない。まずアイデンティティを整理し、そのうえで他のすべてを立ち上げていく過程で、検証を続けなければならない。
