第１ MFAを設定していても確認すべき経路
Microsoft 365の不正アクセス対策では，利用者のパスワードや多要素認証（MFA）に注目しがちである。
しかし，バックアップなどの外部サービスが，利用者の操作を介さずに組織のデータへアクセスする構成もある。
利用者のログイン経路と，アプリが自身の資格情報でアクセスする経路を，分けて点検する必要がある。
Microsoftは，令和８年１０月２１日の調査報告で，ConnectWiseに関係するアプリケーション資格情報を悪用し，既にアクセスを許可していた顧客環境へアクセスする活動を報告した。
本稿は，同月２４日までに確認した報告と公式仕様を基に，外部アプリの権限，証拠保全及び委託管理上の点検事項を整理する。
個々の企業の被害や責任を認定するものではない。
第２ 利用者の権限とアプリの権限はどう違うか
１ 利用者に代わるアクセスとアプリ自身のアクセス
Microsoftの公式説明は，利用者に代わって行う委任アクセスと，利用者の対話的な操作を介さず，アプリ自身のIDで行うapp-onlyアクセスを区別している。
後者は，自動処理や複数の利用者の情報を扱うバックアップなどに使われる。
アプリにどの操作を許すかは，付与されたアプリケーション権限などによって決まる。
外部サービスと契約していることだけでなく，自社環境で何を許可したかを確認しなければならない。
２ アプリの資格情報には証明書やシークレットがある
サービスプリンシパルとは，組織の環境内でアプリなどの主体を表すものである。
そのサインインでは，アプリが証明書やクライアントシークレットなどの資格情報を用いる場合がある。
利用者がその都度パスワードを入力する処理とは異なる。
したがって，利用者のパスワード変更やMFAの設定確認だけで，アプリ側の資格情報や既存の権限まで点検したことにはならない。
MFAを継続しながら，アプリのID，所有者，資格情報，付与権限及び利用状況も調べることが必要である。
第３ ConnectWiseに関する報告で確認できること
１ 既存の信頼関係が悪用されたとの報告
Microsoftは，Storm-0940と呼ぶ攻撃者がARTEXを用い，侵害したアプリケーションの資格情報を通じて顧客環境へアクセスしたと評価している。
報告が説明するのは，利用者の対話型ログインを必要としない経路である。
「AIがあらゆるMFAを破った」と言い換えることは適切でない。
ConnectWiseもCloud Backup（旧SkyKick）に関連するアプリケーション資格情報への不正アクセスを公表し，調査及び復旧に関する情報を更新している。
別の製品やポータルについての復旧告知を，Cloud Backupの復旧完了と読み替えないよう注意が必要である。
２ 認証成功とデータ取得は別の事実である
Microsoftは，影響するアプリの存在や攻撃者による認証成功だけで，顧客データへのアクセス又は外部への持ち出しがあったとは限らないと説明している。
これは，被害がないと確認したという意味でもない。
対象アプリ，認証，操作，データの範囲を分け，個々の環境について調査する必要がある。
攻撃の試行件数や認証に成功した件数を，そのまま漏えいした企業数又は顧客数に換算してはならない。
第４ 管理担当者に確認したいこと
１ 外部アプリの台帳
外部アプリごとに，サービス名だけでなく，アプリID，サービスプリンシパルID，社内の管理責任者，利用目的，付与権限，管理者同意，資格情報の管理主体及び更新・廃止の手順を整理しておくことを提案する。
契約を終了しても権限が残っていないか，利用目的に比べて権限が広すぎないか，誰が例外を承認するかも点検する。
営業担当者への契約確認と，実際の設定確認を対応させることが大切である。
２ 利用者ログだけで調査を終えない
Microsoftの公式説明によれば，サービスプリンシパルのサインインは利用者のサインインとは異なる記録である。
証明書やアプリのシークレットによる認証も対象となる。
調査では，サービスプリンシパルのサインインに加え，アプリの資格情報・権限の変更，対象サービス側の操作記録などを確認する。
記録の保存期間，取得開始時点及び取得できない操作も明らかにする。
あるログに痕跡がないというだけでは，すべてのデータへのアクセスを否定できない。
３ 条件付きアクセスの適用範囲
ワークロードID向けの条件付きアクセスにも，対象やライセンスなどの条件がある。
利用者向けに設定したポリシーが，すべての外部アプリへ同じように適用されるとは限らない。
Microsoftの説明では，Microsoft及び第三者のSaaSアプリ（マルチテナントアプリを含む。）は，このポリシーの対象外とされている。
自社のアプリがどの構成に該当するかを確認し，特定の設定を有効にすればすべて防げると判断しないことが重要である。
第５ 疑わしいアクセスが見つかったとき
１ 封じ込めと証拠保全を並行する
Microsoftの事案別の案内は，関連証拠を保全しつつ，ConnectWiseの封じ込めの案内に従うことを求めている。
エンタープライズアプリを先に削除すると，調査に必要な設定等を失うおそれがあるため，削除を急ぐ前に保存すべき情報を確認する。
これは，侵害が疑われる接続を継続してよいという意味ではない。
記録のエクスポートを待って，緊急の封じ込めを遅らせないようにする。
停止，資格情報の失効・更新，設定の保存及び復旧の順序を，担当者とベンダーの最新案内に照らして決める。
個別サービスの再接続の可否は，その時点の正式な復旧案内で確認する。
２ 事業者への質問を具体化する
問い合わせでは，何が漏えいしたのかだけでなく，対象アプリと資格情報の識別，影響期間，付与されていた権限，顧客環境で確認した操作，未確認の範囲，提供できるログ及び再接続の条件を尋ねることが有用である。
「バックアップの保存領域について被害の兆候がない」という説明があっても，それだけで，連携先のMicrosoft 365環境に対するすべての操作が否定されるわけではない。
説明がどの領域と調査範囲を対象にしているかを確認する。
３ 法務は事実の整理を技術担当と共有する
報告・通知や契約上の対応を検討する際は，確認済みの事実，調査中の事項及び否定できない事項を分けた資料を，技術担当者と共有する。
サービス名やAI利用の有無だけで結論を決めないことが重要である。
具体的な報告・通知の判断は，情報漏洩が相次ぐ今，企業の信頼を守る法務の備えを参照されたい。
調査報告の限界は，情報漏えいのフォレンジック報告書をどう読むかで扱っている。
第６ 出典・関連記事
①Microsoftの令和８年１０月２１日付け調査報告。
事案の仕組み，認証成功とデータ取得の区別，証拠保全を参照。
https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
②ConnectWiseの公式案内。
Cloud Backupの調査・復旧については，同じページ内でも対象サービスと更新日時を確認する必要がある。
https://www.connectwise.com/company/trust/advisories
③Microsoft公式仕様のapp-onlyアクセスの説明。
https://learn.microsoft.com/en-us/entra/identity-platform/app-only-access-primer
④サービスプリンシパルのサインインログの説明。
https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-service-principal-sign-ins
⑤ワークロードID向け条件付きアクセスの説明。
対象外のアプリ及び適用条件を参照。
https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identity
⑥サービスプリンシパルの定義は，Microsoft公式仕様のService principal object及びRelationship between application objects and service principalsを参照。
https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals
⑦ARTEX自体の説明は，ARTEXとは―AIサイバー攻撃の仕組みと企業が確認すべき対策を参照されたい。