供應商來信說，受影響的應用程式身分已停用。值班工程師把通知轉進群組，準備將事件標成「已處理」。這時有人問：「那我們租戶裡，被改過的權限呢？」

這是虛構的值班場景，卻點出 ConnectWise Cloud Backup 事件值得工程團隊記住的判斷：供應商能證明自己做了什麼，客戶仍須回答自己的環境發生過什麼。兩份證據不能互相代簽。

截至 2026 年 10 月 19 日 01:15 UTC（臺北 09:15），ConnectWise 官方公告確認 Cloud Backup（原 SkyKick）相關應用程式身分遭未授權存取；七個身分於 10 月 17 日 07:00 UTC 停用。既有 access token 仍可能有效，租戶內的其他存取途徑需另查。Cloud Backup、SaaS Security 與 Cloud Management 仍暫停服務，尚無確定恢復時間；官方要求保持受影響的應用程式停用，等待正式恢復指示。官方稱備份封存仍加密隔離，未見被存取證據。這項說明無法證明個別 Microsoft 365 租戶安全，起始憑證曝露機制仍在調查。

本文不推定任何特定客戶已遭入侵，也不把事件寫成已確認的產品漏洞。以下是一套工程交接建議，沒有在真實租戶執行。

「已停用」必須帶著範圍一起交接

把事件狀態壓成一個布林值，很容易把不同問題混在一起。值班表若只剩 contained: true，下一班看不到那個 true 到底指供應商的認證入口、客戶租戶的 enterprise application，還是所有相關身分的存取權。

Microsoft 的停用應用程式登入文件區分單一租戶的 service principal 與跨租戶的 app registration。前者的停用狀態，不能直接拿來描述後者；反過來也不能省略本地設定的核對。

實務上的交接句應該縮小到能查證的對象。例如：「租戶 A 的應用程式 B，本地 Object ID 為 C，於某個 UTC 時間確認登入設定停用，證據存於事件紀錄 D。」這不是漂亮的摘要，卻讓另一個人知道自己應該到哪裡重查。

這裡的 A、B、C、D 是教學代號。紀錄可以放在組織既有的受控事件系統，不必為此新增平台，也不應把租戶明細貼到公開 issue。

停止規則：一項控制完成，只關閉它對應的工作項。「入口已關」後面還應保留待調查項目，而不是讓整張事件單一起變綠。

換一把合法鑰匙，不會自動移走多出來的鑰匙

接著看另一個虛構情境：團隊完成原憑證的替換，登入測試也成功。稍後查核人員才發現，同一個應用程式底下多了一組沒有變更單的 credential。

此時「新憑證可用」回答的是服務能不能重新認證；它沒有回答那組多出的 credential 是誰建立、是否仍可用、影響哪些資源。若交接表只驗證新路徑成功，舊風險可能完全不在測試範圍內。

Microsoft 的受侵應用程式調查指引將異常登入、credential 變更、應用程式設定、角色與 consent 分開調查，也要求檢查 application 與相關 service principal。這種拆法的用處，是讓「合法配置已恢復」和「未授權配置已清除」各自留下證據。

可以把工作交接拆成兩種責任：

  • 調查人員用已獲授權的讀取能力蒐集狀態、時間、物件識別值與對應紀錄，列出無法解釋的差異。
  • 有權限的處置人員判定差異是否未授權，再決定停用、移除、輪替或修正。每次變更都記下對象、影響、結果及覆核方式。

讀取也受組織授權約束；「唯讀」不代表任何人都能拿到全部租戶日誌。查到異常更不等於可以自行刪除整個應用程式。刪掉物件可能讓服務與調查一起受影響，處置順序應由事件負責人決定。

本文因此不提供一段跨租戶自動刪除或輪替的指令。安全的自動化起點，可以只是產出待覆核清單；要執行變更，還需要明確的目標範圍與客戶授權。

查無紀錄，是查詢結果，不是環境判決

10 月 18 日 18:45 UTC，官方新增兩個供調查的 IP：144.172.64[.]99 與 144.172.64[.]60；先前已列出的 144.172.64[.]128 仍在清單內。新增地址來自合作夥伴及客戶環境的下游安全監測，應納入 Microsoft 365 認證與稽核紀錄查詢。這項更新擴充了查詢條件，沒有證明又出現多少受害者。

10 月 18 日版官方調查指南第 3–4 頁要求調查涵蓋 10 月 13 日至今；若紀錄可取得，擴大到 10 月 1 日。也要依各應用程式 ID 查核 service-principal 活動，分開檢視成功、失敗及後續行為，不能只查已公布的 IP。指南明確提醒：IP 命中需要調查，單靠命中不能判定入侵或資料外洩。

假設工程師查了最近一天的登入紀錄，沒有找到列出的可疑來源，便在報告寫下「未受影響」。這個結論至少跳過了兩個問題：事件可能發生在查詢期間以前；要回答的活動，也可能不在這類日誌裡。

更可用的寫法是：「已查某類紀錄，涵蓋某段 UTC 時間，使用某組條件，未發現命中。更早期間無資料，其他類型尚未查核。」讀起來沒有那麼安心，但下一班能接著做事，主管也知道判斷還有多大缺口。

建議在每份查核結果旁保留以下欄位：

  • 查了哪個租戶、身分與資源，資料由哪個已授權角色取得。
  • 實際涵蓋的起訖時間與時區，而不是只有「最近七天」。
  • 查詢條件、事件識別值，以及可以重現查詢的紀錄位置。
  • 哪些資料缺失、哪些差異待確認，以及下一位負責人。

這些欄位是本文提出的交接格式，並非供應商工具已內建的保證。它們要解決的是證據強度被摘要吃掉的問題：成功認證、資源存取、資料遭複製，是不同層次的主張。報告應寫到現有證據能支持的位置。

備份空窗需要另一位負責人

身分調查可能花上數日，業務資料卻仍在變動。如果事件群組只追蹤「是否還有未授權存取」，就可能忽略另一個持續擴大的問題：現在新增的資料，要靠哪個復原點救回來？

這裡適合分出一條營運工作線。它不判定攻擊者做過什麼，而是回答最後一次可確認的成功備份時間、可用的獨立副本、實際可啟動的還原途徑，以及資料負責人能接受的缺口。

例如，假設最後確認的復原點在週六 02:00，週日 10:00 仍未恢復備份，距離是 32 小時。這是教學假設的時間差，不能直接宣稱「已遺失 32 小時資料」；原始資料可能仍在，另有副本也可能存在。它提醒的是：若此刻再發生資料毀損，手上的復原選項可能不涵蓋這段期間。

暫時多匯出一份資料也有成本：敏感資料去了哪裡、誰能讀、何時刪除、是否能還原，都要有人負責。不能為了補空窗，臨時把客戶資料搬到未核准的位置。

與此同時，安全工作線持續釐清身分、存取與未解問題。兩條線可以並行；備份工作恢復成功，不會代替安全調查的結論。

一張能讓下一班繼續工作的事件單

回到開頭的群組。這次值班工程師不再只回「供應商已處理」，而是交接兩個具體結果：哪些連線已確認停用、哪些租戶問題還沒釐清；以及目前有哪些經確認的復原選項、哪段資料仍有保護缺口。

對整合外部 SaaS 的團隊，這也提供了一個平時就能做的設計檢查：每個高權限整合，能否找到負責人、明確識別的本地物件、可取得的稽核資料，以及停用後的業務替代路徑？如果答案散落在不同人的記憶裡，事件發生時就很難平行處理。

下一次檢視整合清單時，挑一個備份或管理型應用程式，試著寫出這份交接。不需要真的停用它，也不用碰客戶資料。若連「誰有權確認狀態」都寫不出來，這就是目前最值得補上的工作。