どうも おかしん です。
Microsoftが2026年10月1日に公開したMicrosoft Digital Defense Report 2026を読みました。AIを使った攻撃、国家による活動、サイバー犯罪、組織のレジリエンスまでを扱った年次レポートです。
レポートの主なポイントを要約すると、次のようになります。
- AIは攻撃の準備や実行を速め、高度な攻撃に必要なコストを下げ、攻撃の規模や自律性を高めている。
- 侵入の入口として、人の実行行為、フィッシング、IDの悪用など、従来の経路が引き続き使われている。
- IDは防御の中心にあり、フィッシング耐性のあるMFA、権限の削減、人間・非人間IDの管理が重要になる。
- AI自体も攻撃対象になり、エージェントの権限やアクセス先、扱うデータを管理する必要がある。
- 端末、ID、クラウド、メールなどの情報を突き合わせることで、個別のログでは見えない攻撃を捉えられる。
- 脆弱性対応は定期的な作業だけで完結させず、資産と露出を継続的に把握し、リスクに応じて対応する。
- 対策の成果は、パッチ適用数だけでなく、露出の削減、検知範囲、緩和までの時間、重要業務の継続や復旧で見る。
このレポートからも分かるように、AIによって攻撃の速度と規模は拡大しています。ただ、それを受けて「AIを使った攻撃に対応するには、守りにもAIを使っていこう」という、一見正しそうなスローガンを全面的に支持できるかというと、私はそうは思いません。レポート自体も防御へのAI活用を提言していますが、それだけで対策の方向を決めてよいわけではないからです。
私がこのレポートから読み取ったのは、結局のところ、「ID・端末、特にIDの管理をちゃんとやりましょう」ということと、セキュリティ対策では「事業への影響をどれだけ抑えられるか」が重要だということです。
AI以前から当たり前だったことが、引き続き重要である。AIを使うことも、この基本を押さえたうえで考えるべきだと思います。
ID管理は、やはり防御の中心にある
レポート本文の主要な提言には、IDを防御の主要な制御面として扱うことが挙げられています。パスキーやフィッシング耐性のあるMFA、権限の削減、人間と非人間のIDの管理、トークンやセッション資格情報の速やかな失効・更新などです。
IDの話が中心にあるのは、侵入した攻撃者が正規の権限を使って活動できるからです。
Microsoft Defender Expertsの顧客向け通知を分析した初期アクセスの内訳では、ユーザーによる実行が30%、有効アカウントの悪用が20%と報告されています。有効アカウントを使った侵入の52.2%では、その後に追加の資格情報窃取が発生していました。これはMicrosoftの当該観測に基づく数字で、全企業の侵害にそのまま当てはまる割合ではありません。
盗まれたIDが一つあれば、そのIDでアクセスできる先に入れる。そこから別の資格情報を盗み、さらにアクセスを広げる。
最初に乗っ取られたアカウントを止めただけで、調査を終えてよいとは限らないわけです。どの権限を持っていたのか、どこにアクセスしたのか、その先で何が起きたのかを追える必要があります。
アカウントが存在することと、管理できていることは違う
ここでいうID管理は、アカウントの一覧を作ることだけではありません。
誰のためのIDなのか。何に使うのか。どの権限を持たせるのか。異動したら何を変え、退職したら何を止めるのか。例外として残すなら、誰が承認し、いつ見直すのか。
こうしたことが、実際の状態と一致している必要があります。
たとえば、退職者のIDをIdPで無効にした。でも、個別のSaaSにはアカウントが残っている。既に発行されたセッションやAPIキーも使える。これでは、止めたつもりのアクセスが残る可能性があります。無効化がどこまで効くかは、連携方式や各サービスの仕様も含めて確かめなければいけません。
SSOの導入だけでアカウントのライフサイクルまで自動的に管理されるわけではない、という話は、以前の「2026年の今、なぜSSOが重要なのか」でも書きました。
管理者IDなら、日常業務のIDと分ける。不要な権限は外す。強い権限を常設する必要があるかを見直す。侵害されたときに、資格情報やセッションを失効できるようにしておく。
基本的なことですが、ここを飛ばすことはできません。
端末の状態と、人間以外のIDも見る
IDだけを見ても、そこから使われる端末の状態が分からなければ、アクセスの判断に必要な材料が欠けます。
会社が把握している端末か。誰が使っているのか。OSやソフトウェアは期待した状態か。端末の防御機能が動いているか。異常があったとき、アクセス制限や隔離を実行できるか。
MDMやEDRが入っている台数だけで、これらを全部説明できるわけではありません。登録されていることに加えて、現在の状態と、問題があったときに取れる操作まで見たいところです。
シンジの「情報漏えいの起こし方」では、異動前の権限が残る、退職者が発行したAPIキーを放置する、MFAを入れても端末からセッション情報を盗まれる、といった管理の抜けが、架空の会社の短いケースとして描かれています。IDと端末の管理を別々に完了扱いすると、こうした抜けを見落としてしまいます。
この対象には、アプリケーションやサービス、AIエージェントのIDも含まれます。レポートも、人間と非人間の両方のIDを管理することを求めています。
業務を実行するAIエージェントに、誰も所有者を把握していない強い権限や、期限のない資格情報を渡してしまう。人間のIDで避けてきた状態を、AIだからといって許す理由はありません。
誰が使うか、どの端末や実行環境から、何に、どの権限でアクセスするかを確かめる。このようなゼロトラストの設計原則を、日々の管理に落とし込むことが必要です。
ゼロトラストの設計原則については、弊社の書籍『ゼロトラスト概論』もご参考ください。
セキュリティ対策の成果は、事業への影響で見る
もう一つ、私が重視したいのは、セキュリティ対策の評価です。
レポートの組織向け優先事項では、継続的な攻撃にさらされる中で、重要な業務を維持できるか、被害を封じ込められるか、速やかに復旧し、信頼を保てるかが問われています。主要な提言でも、レジリエンスをセキュリティ計画の成果として扱っています。
ここから私が言いたいのは、セキュリティ対策は、事業影響を抑えることができているかに尽きる、ということです。
これはID管理だけの評価ではありません。認証、端末防御、脆弱性対応、監視、バックアップ、インシデント対応など、対策全体に対する評価基準です。
パッチを何件当てたか。アラートを何件処理したか。何台に防御製品を入れたか。これらは運用を回すうえで必要な数字です。ただ、その数字だけでは、顧客情報の流出をどこまで抑えられるのか、請求や出荷をどれだけ早く再開できるのかまでは分かりません。
レポートも、報告指標をパッチ適用数から、露出の削減、検知できる範囲の拡大、緩和までの時間の短縮へ移すことを提言しています。事業影響を見ようとするなら、その先の業務への影響まで、自社の状況に合わせて確かめたいです。
何を止められたかと、何を続けられたか
仮想の例で考えてみます。請求業務の担当者の端末が侵害され、その担当者のアカウントも不正に使われたとします。
そのIDが請求に必要な範囲を超えて、他部門のデータや管理機能にもアクセスできるなら、侵害が広がる可能性があります。共有アカウントを使っていれば、一人のアクセスを止めるつもりでも、ほかの担当者まで止まるかもしれません。
必要な範囲に権限を絞り、利用者ごとにIDを分けておけば、特定のIDや端末を制御する選択肢を持てます。ただし、セッションの失効や端末隔離がどこまで効くかは、その環境で確認する必要があります。
さらに、別の担当者が請求を引き継げるか。請求データは改ざんされていないか。復旧したデータが正しいと確認できるか。期限までに業務を再開できるか。
ここまで見て初めて、事業への影響を考えられます。
侵害された端末を隔離できたのは、防御上の成果です。でも、その端末でしか請求できず、代替手段もなければ、業務は止まったままです。隔離が不要という話ではなく、隔離した後に事業をどう続けるかも対策に含めるという話です。
以前の「情報システムの価値を壊すセキュリティは悪である」でも書いたように、セキュリティ対策自体が業務の価値を壊していないかも、評価から外せません。
被害がなかっただけで、有効だったとは言い切れない
とはいえ、事業影響を評価するために、実際の事故を待つわけにもいきません。
重要な業務について、想定した侵害の範囲を限定できるか、代替運用へ移れるか、許容できる時間内に必要な状態まで復旧できるかを、訓練で確かめることができます。
「バックアップがあります」だけで終えず、復元できるか、データの整合性を確認できるか、業務を再開するまでにどれだけかかるかを見る。停止時間を測るなら、いつを停止の起点とし、どの状態を再開とするかも、業務側とそろえておく必要があります。
実際のインシデントと訓練では条件が違いますし、被害がなかった期間だけを見ても、対策によってどれだけの損失を避けたかは証明できません。実績と訓練結果、まだ確認できていない点を分けて、判断材料にするのがよいと思います。
後書き：結局、地道にやるしかない
ここまで書いておいて何ですが、ID管理なんて基本中の基本です。
事業影響を評価基準にするのであれば、「何が重要業務なのか」を先に特定しなければいけません。その業務にどんな情報資産が必要なのか。情報はどこにあり、どこを流れ、誰が使うのか。どんな脅威があり、どの脆弱性や管理上の不足を通じて、業務に影響が出るのか。
つまり、情報資産を特定して、リスクアセスメントをちゃんとしましょうね、という話です。
この進め方は、以前の「NIST IR 8286 Rev.1を読む」でも書きました。重要な業務と資産を事業目的から見て、リスクをシナリオにし、影響と対応後に残るリスクを整理する。今回のレポートを読んでも、その土台を省略できるとは思いません。
AIによって、攻撃者が調査や攻撃の準備にかける時間・コストを下げ、攻撃を大規模に実行しやすくなる。そこは変わっています。Microsoftの公式解説も、AIが攻撃の速度や規模を変える一方、人、ID、外部公開システム、信頼されたアクセスが引き続き悪用されていると説明しています。
全く未知の超高度な攻撃だけが問題になっているわけではありません。資格情報を盗む。権限のあるIDを使う。修正されていないシステムに入る。そうした従来からの入口が、今も使われています。
もちろん、AIを狙うプロンプトインジェクションやエージェントの権限悪用など、追加で考えるべき攻撃面もあります。「何も変わっていない」という意味ではありません。
AIを使って守ろう、という方向も間違いではないです。調査や検知、対応を速くするために使えるなら、使えばよいと思います。
ただ、何を守るのかが分からず、IDや端末の管理も曖昧なままでは、AIに何を見せ、何を判断させ、どこまで操作させるかも決まりません。
新しい技術を使うことと、基本をやることは両立します。結局、地道にやるしかない。 AIだからどうこうという前に、基本からちゃんとやっていきましょう。
