IT管理サービス大手 ConnectWise の Microsoft 365 連携アプリが悪用され、その先の顧客企業のクラウド環境が狙われました。Microsoft は2026年10月21日、攻撃者「Storm-0940」がAIを使う侵入テスト用フレームワーク「ARTEX」で攻撃を自動化していたと公表しています。この記事では、事実を整理したうえで、委託先に渡したアプリ権限をどう棚卸しするかというサプライチェーン攻撃対策を、受託開発会社の代表として顧客環境の権限を受け取る側の立場から論じます。
要点 (事実のみ)
- Microsoft によると、中国国家と協調するとみられる攻撃グループ Storm-0940 が、2026年9月ごろからオープンソースの侵入テスト用フレームワーク ARTEX を使い、世界の幅広い業種の組織を狙っていた。ARTEX は任意のAIモデルを使って、偵察から情報の持ち出しまでを自動で進める複数エージェント構成のツールとされる。
- 2026年10月15〜16日に ConnectWise 側で侵害が起き、同社は16日に公表した。悪用されたのは ConnectWise Cloud Backup、ConnectWise - MS Teams、ConnectWise - MS Graph、SkyKick Partner Portal の4つのアプリ連携 (OAuth アプリ) で、顧客がすでに権限を与えていたアプリとして、利用者の対話的なサインインを経ずに顧客環境へ入っていた。
- Microsoft は、2,250 を超える顧客テナントが標的になり、サインイン試行は最大で毎分2,900回に達したとしている。標的にされてから特権アクセスを得るまで3時間を切った例が複数あった。
- 侵入後は、アプリの認証情報を追加して居座る、全体管理者 (Global Administrator) の役割を自分に割り当てる、メールやファイルへのアクセスを試みる、といった操作が確認された。標的の大半では侵入は成功していない。
- ConnectWise の CEO、Manny Rivelo 氏はロイターに対し、影響を受けたアプリ連携を封じ込め、段階的にサービスを戻しているとしたうえで、「その措置は、すでに確立された可能性のある不正アクセスを取り除くものではない」と述べた。中国大使館はロイターの取材に応じていない。
徐 聖博の見解
侵入口は「人のパスワード」ではなく「契約で渡したアプリ権限」だった
今回の件で私が一番重く見ているのは、攻撃者がユーザーのパスワードを破ったのではなく、顧客企業が自分で許可したアプリの権限をそのまま使った点です。バックアップや Teams 連携のために「メールとファイルを読める」「ディレクトリを読める」権限を委託先アプリに渡す。これは多くの企業で日常的に起きている判断で、渡した時点では誰も問題だと思っていません。
その結果、多要素認証を入れていても、パスワードをどれだけ強くしても、このルートには効きません。アプリとして入ってくる以上、社員のサインインを経由しないからです。ConnectWise の CEO が「連携を止めても、すでに作られた不正アクセスは消えない」と言っているのも同じ理由で、侵入後に追加された認証情報や役割の割り当ては、元の連携を止めても顧客側のテナントに残ります。
受託開発の現場で、私たちはこの権限を「受け取る側」にいる
受託開発の仕事では、顧客の Microsoft 365 や AWS に、開発会社用のアカウント、アプリ連携、API キーを作ってもらうことがよくあります。立ち上げのときは「とりあえず管理者で」と広めの権限が渡されがちで、案件が終わったあとに誰がそれを消すのかは、契約書にも運用にも書かれていないことが多い。私は、ここが今回と同じ構造の穴だと考えています。
だから、開発会社の側から次の3つを出すべきだと思っています。
- 着手時に、受け取る権限の一覧を書面で出す。 どのアカウント・どのアプリに・どの範囲の権限が要るのかを開発会社が自分で書き、顧客が承認する形にする。「管理者で」を受け取らない。
- 終了時に、返却報告を出す。 削除・無効化したアカウントとアプリ連携を一覧で返す。顧客の情シスが自分で探さなくて済むようにする。
- 保守契約中は、四半期に一度の棚卸しを作業項目に入れる。 権限は追加されることはあっても、減らされることはまずありません。減らす作業を定期作業として見積もりに入れておかないと、誰もやらない。
これは「セキュリティに気をつけています」という姿勢の話ではなく、運用の設計の話です。私は、テスト、セキュリティ、認証・認可、本番環境の安定稼働は開発のスピードと引き換えにしないと決めていますが、権限の返却まで含めて初めて認証・認可を設計したと言えると考えています。
AIによる自動化で「気づいてから対処」の時間がなくなった
もう一つ、事業判断として見落とせないのは速度です。標的にしてから特権アクセスまで3時間を切った例が複数あり、サインイン試行は毎分2,900回です。ARTEX は誰でも入手できる侵入テスト用ツールで、防御側の検証にも使われるものです。攻撃の手順がAIで自動化されると、「月曜に情シスが気づいて対処する」という運用は前提から崩れます。
私はAIエージェント事業を進めている立場として、ここに逆向きの論点もあると考えています。社内に業務を代行するAIエージェントを入れるとき、そのエージェントもまた「アプリとして権限を持ち、人のサインインを経ずに動くもの」です。誰の権限で、何を見て、何を変えられるのかを決めずに入れたエージェントは、今回悪用されたアプリ連携と同じ形の入口になります。作る側としては、権限を最小にして監査ログを残すことを、機能より先に決めるべき要件だと考えています。
委託先のアプリ権限を確認する手順
Microsoft が今回の件で公開した推奨対応のうち、ConnectWise 製品を使っていない企業にも当てはまるものを、確認の順番に並べ直しました。
| 順番 | 確認すること | 見る場所の例 |
|---|---|---|
| 1 | 自社テナントで権限を持っている外部アプリ (エンタープライズアプリケーション) の一覧を出す | Microsoft Entra 管理センター |
| 2 | 各アプリが持つ権限の範囲と、契約上いまも必要かを照合する | 委託契約・保守契約の一覧 |
| 3 | アプリの認証情報の追加、新しいアプリの登録、役割の割り当ての変更履歴を確認する | Entra の監査ログ |
| 4 | 見覚えのない接続元からのアプリとしてのサインイン (成功・失敗の両方) を確認する | サインインログ |
| 5 | メール転送ルールの追加や、まとまったメール・ファイルの参照がないかを確認する | Microsoft 365 の監査ログ |
不審な点が見つかった場合、Microsoft はアプリを削除する前に証跡を保存し、まずは無効化することを勧めています。消してしまうと、何が行われたかを後から追えなくなるためです。
契約が終わった委託先の権限は消えているか
上の手順で一番見つかりやすいのは、取引が終わった委託先のアプリやアカウントが残っているケースです。保守を別の会社に切り替えた、PoC だけで終わった、担当者が異動した。こうした区切りのたびに権限の返却を確認する手順がないなら、それが今回のような攻撃で最初に使われる入口になります。
まとめ
今回の ConnectWise の件は、委託先の侵害が、その委託先にアプリ権限を渡していた顧客全員の問題になることを示しました。サプライチェーン攻撃への対策は、委託先の選定のときだけでなく、渡した権限を数え、使わなくなったら返してもらう運用があるかどうかで決まると私は考えています。
関連して読んでいただきたい記事:
