ConnectWise Cloud Backupの不正アクセス調査が更新！Microsoft 365側で確認すべき接続と権限

ConnectWiseは2026年10月18日、Cloud Backup（旧SkyKick）に関連するアプリケーションの認証主体（アプリがアクセスに使うID）への不正アクセス調査を更新しました。利用企業にとって重要なのは、バックアップサービスの停止、保存済みアーカイブの状態、連携先のMicrosoft 365環境への影響を別々に確認することです。

本記事は同日の一次資料を確認したニュースと実務上の整理です。以下では発表元が確認した事実と、本サイトが提案する確認手順を区別します。原因が確定した製品脆弱性や、AIを使った攻撃としては扱いません。

発表で確認できる状況と未確定の点

ConnectWiseによると、関連する7つのアプリの認証主体を無効化し、接続用証明書も失効させています。Cloud Backupは停止中で、予定したバックアップと影響を受ける保存物へのアクセス・復元が利用できません。既存アーカイブは保全され、同社はそれらがアクセスされた証拠はないとしています。

これは個々のMicrosoft 365環境の無被害を保証する説明ではありません。製品脆弱性の関与や資格情報が露出した仕組みは調査中で、復旧時刻も未提示です。発表の範囲を超えて、全顧客の情報漏えいや安全性を断定しないでください。

出典：ConnectWise Trust Center：Cloud Backup Service Interruption（10月18日更新）。

公表・更新・対処の日時を分けて読む

発表元が使うUTCと日本時間を混同しないよう、主要な時点を次の表にまとめます。問題を認識した日と、外部へ公表した日は異なります。攻撃の開始時刻が判明したという意味ではありません。

出典：ConnectWise Trust Center：Cloud Backup Service Interruption（10月18日更新）。

区分	発表元の記載	日本時間での位置付け
問題の認識	2026年10月14日	時刻の記載はなく断定しない
最初の公表	10月16日17時47分 UTC	10月17日2時47分
7つの認証主体の無効化	10月17日7時 UTC	10月17日16時
今回確認した更新	10月18日1時 UTC	10月18日10時

最初に対象のテナントとアプリを特定する

ここからは本サイトの提案です。自社がCloud Backupを使っているかだけでなく、運用委託先が接続しているか、過去に利用したSkyKickの接続が残っていないかを確認します。サービスの請求が止まったことと、テナント内の接続が消えたことを同一視しないようにします。

対象はConnectWiseの技術案内にあるApplication client IDで照合します。表示名は変更でき、似た名前もあり得るため、名前だけで無関係な連携を止めないでください。テナントID、Application ID、ローカルのObject ID、担当者、用途を対応付けると、調査と後の復旧の対象をそろえやすくなります。

MSPが複数の顧客を管理する場合は、顧客ごとの確認表を作ります。一つのテナントでアプリが無効だったという結果を、他の顧客へ広げないことが重要です。業務管理者とセキュリティ担当者を決め、対象の確認と変更の承認を分担します。

出典：ConnectWise Trust Center：Cloud Backup Service Interruption（10月18日更新）。

接続の停止と既存のアクセスの除去を分ける

Microsoftの公式手順では、Enterprise applicationsの対象のプロパティからサインインを無効にできます。これはテナント内のサービスプリンシパルの状態を変える操作で、アプリ登録そのものの無効化とは区別されます。画面の状態と、どの範囲を止めたかを確認してください。

出典：Microsoft Learn：Disable user sign-in for an application。

本サイトの提案は、対象を特定したうえで発表元の停止指示を確認し、実施者、時刻、保存後の状態を記録することです。最初から削除して構成情報を失うより、調査に必要な情報を保ち、無効化後の状態を確認する進め方を検討します。緊急の封じ込めを、すべての記録の取得が終わるまで待たせる必要はありません。

新しい認証を止めることと、発行済みトークンや別のIDによるアクセスを除くことは別です。証明書を変えたので全アクセスが即時に消えた、と判断せず、利用中の認証方式と各リソースの失効条件を対応担当者が確認します。元の接続を止めても、別に作られた資格情報や権限まで自動で消える前提にはしません。

ログは種類と取得範囲を明示して保全する

Microsoft Entraのサインインログでは、人の対話型の利用、非対話型の利用、アプリなどを区別して取得する機能があります。通常の利用者のログイン画面だけを見て、アプリの認証がなかったと判断しないことが重要です。ダウンロードの形式やフィルター、取得可能な範囲は公式資料で確認します。

出典：Microsoft Learn：How to download logs in Microsoft Entra ID。

本サイトの提案として、対象期間、テナント、ログの種類、検索条件、UTCを含む時刻の扱いを取得記録へ残します。絞り込んだ結果だけを保存した場合は、除外した範囲も記録します。画面の一枚の画像だけでなく、許可された方法でイベントの詳細を保全すると、後から関連付けやすくなります。

閲覧・取得に必要な権限と、アプリやメール設定を変更する権限は別です。調査のために全員へ強い管理権限を与えるのではなく、必要な役割を持つ担当者へ依頼します。取得したログ自体にも識別情報が含まれるため、保存先と共有範囲を限定します。

ログの保持期間や機能はライセンスと既存の収集設定に左右されます。後から監視を有効にしても、記録されていなかった過去の操作を復元したことにはなりません。調べられた期間と、証拠のない期間を区別して報告します。

認証の成功・設定変更・データ取得を別々に判断する

Microsoftの侵害アプリ調査資料は、不審なサインインに加え、資格情報、設定、権限、同意などの変化を調べる観点を示しています。アプリのオブジェクトとサービスプリンシパルの両方を対象に考える必要があります。

出典：Microsoft Learn：Compromised and malicious applications investigation。

本サイトの提案は、個々のイベントを「認証の試行」「認証の成功」「構成の変更」「対象データへの操作」に分けることです。成功したサインインだけで情報のコピーを断定せず、その後の操作と結び付く記録を探します。一方、取得操作のログが見つからないことも、記録が十分でなければ無被害の証明にはなりません。

公開された指標は入口として使い、既知のIPに一致しないことだけで調査を終えないようにします。通常のバックアップ処理と、管理者の承認済み作業を照合し、見慣れないイベントをすべて攻撃と分類しない手順にします。利用者名やアプリ名の印象ではなく、識別子、対象、時刻と結果で追います。

追加された資格情報や権限が残っていないか

本サイトの提案として、アプリの所有者、証明書やシークレット、フェデレーションの設定、APIの同意、強いディレクトリ権限の変更を、通常の変更記録と照合します。正規の資格情報を新しくしたことと、意図しない資格情報が除かれたことは別の確認です。

権限を追加した主体、変更先、結果、変更された値を対応付けます。別のアプリや利用者へ変更がつながるなら、そのIDも調査対象へ広げます。見つけた値が有効期間内というだけで、いつ追加され、誰が承認したかを推定しないようにします。

不正と確認できた設定を除く場合も、所有者と対応担当者が必要な証拠を保全し、影響を見て実施します。正規の設定までまとめて消すと、復旧に必要な接続や監視を失う場合があります。変更後には状態を読み直し、別の経路が残っていないかを確認します。

MFAと条件付きアクセスを一律の解決策にしない

Microsoftは、ワークロードIDが人のアカウントと異なりMFAを実行できないこと、ワークロード向け条件付きアクセスが対象とする範囲には制約があることを説明しています。確認した資料では、第三者SaaSやマルチテナントアプリは、そのポリシーの対象に含まれません。

出典：Microsoft Learn：Conditional Access for workload identities。

本サイトの提案は、人の管理者アカウントに対するMFAと、アプリの資格情報・同意・実行権限を別の台帳で確認することです。「全員にMFAを設定済み」という回答だけでは、今回調べるアプリの経路を評価できません。

新しいポリシーの追加を急ぐ前に、対象のアプリに適用できる仕様と、必要なライセンス、通常の処理への影響を確認します。適用対象外の設定を有効にして、封じ込めが完了したと報告しないようにしてください。

メールのルールと権限を業務の記録と照合する

Microsoft 365に関わる運用では、メールの転送、受信トレイのルール、代理アクセスなども確認候補です。MicrosoftのGet-InboxRule資料には、非表示のルールを含めるIncludeHiddenの指定があり、操作には適切な権限が必要とされています。

出典：Microsoft Learn：Get-InboxRule。

本サイトの提案として、外部転送が業務上認められた宛先か、最近追加したルールに変更申請があるかを確認します。受信トレイのルールと、組織のメール配送のルールは別の対象として担当者へ依頼します。通常の管理画面で見えた項目だけが全設定だとは判断しないでください。

Web運営者にとっては、問い合わせ、決済通知、パスワード再設定のメールに関係する業務の影響も確認します。これは本件でそれらが盗まれたという報告ではなく、自社の連携と情報の重要度から調査の優先順位を付けるための提案です。

復旧は再接続の成功だけで終わらせない

本サイトの提案は、調査と並行して、最後に成功したバックアップの復旧点を確認することです。停止中に新しく作られたデータと、最後の保存時点との差を、業務ごとに記録します。保存物が保全されていることと、必要な時に復元できることを別の確認にします。

提供元が正式な復旧・再認可の案内を出すまでは、動かすためだけに古い接続を再有効化しないようにします。案内に従って復旧する場合も、接続先、付与する権限、初回のバックアップ結果、通常と異なる認証の有無を確認します。再認可を求めるメールは、独立して確認した公式案内と照合してください。

復元を試す際は、許可された隔離環境と架空または保護したデータを使い、通知や外部への更新を止めます。実際の復旧時に誰が作業し、業務としてどの時点まで戻すかを決めておくことも、停止中の重要な準備です。

確認結果には限界と次の担当を残す

完了の報告には、対象テナントとアプリ、保全したログの範囲、停止の時刻、見つかった変更、対処した項目、未確認の点をまとめます。本サイトの提案は、「異常が見つからなかった」と「十分な記録により影響範囲を判断できた」を別の結果として扱うことです。

本記事は10月18日に確認した発表を整理したもので、継続的な監視結果ではありません。復旧状況と調査結果はConnectWiseのTrust Centerで再確認してください。外部サービス側の措置だけで対応を完了とせず、自社と委託先がどの範囲まで確認したかを記録することが、次の判断につながります。