Entra ID 服務主體是什麼？從 MSP 遭入侵事件看委外 IT 的自查清單

Table of Contents

很多中小企業沒有自己的 IT 部門，Microsoft 365 的帳號、備份、資安監控都交給委外的 IT 服務商（MSP）代管。這種模式方便，但也有一個風險：攻擊者不必一家一家打，只要拿到 MSP 手上的一把鑰匙，就可能一路入侵它管理的客戶。

這個月就出現一起這樣的案例。我們來看看事情經過、被冒用的服務主體是什麼，以及有委外 IT 的企業可以怎麼自查。

事件經過

資安業者 Todyl 在 11 月 3 日公布調查（11 月 6 日更新），重點如下：

項目	內容
入侵方式	拿外洩的用戶端密碼（client secret），以應用程式的服務主體（service principal）身分登入，不需要任何員工的密碼
影響範圍	27 個組織，包含 MSP 本身和它服務的客戶
資料存取	下載 81 個檔案，讀取信箱內容約 2,279 筆
時間	Todyl 首次發現是 11 月 1 日（UTC）；Microsoft 的紀錄顯示，同一個 IP 最早在 10 月 28 日就已成功登入

這次沒有用到任何 Microsoft 的漏洞，用戶端密碼的外洩來源與攻擊細節，有興趣的讀者可以看 Todyl 的調查報告與 Microsoft 的研究說明。

Microsoft Entra ID 是 Microsoft 的雲端身分識別與存取管理服務，前身是大家熟悉的 Azure AD（Azure Active Directory）。可以想成公司的門禁系統：誰能進來、能進哪幾道門，都由它發卡、驗證與管控。

公司使用 Microsoft 365 時，員工的帳號就是由 Entra ID 管理；但能拿到門禁卡的不只有人，軟體工具也需要。

服務主體（service principal）是 Entra ID 發給軟體工具的身分，也就是發給工具的那張門禁卡。

人登入 Microsoft 365 用的是員工帳號；軟體工具、服務或腳本要存取公司資料時，用的則是服務主體。Microsoft 把這類給軟體使用的身分統稱為「工作負載身分識別」（workload identity）。

這張門禁卡不是靠帳號密碼開門，而是靠用戶端密碼（client secret）或憑證。

面向	優點	缺點
帳號管理	工具不必借用員工帳號，員工離職或改密碼都不受影響	建立後容易被遺忘，什麼時候該收回不好追蹤
權限	可以只開工具需要的範圍	權限給太大、用不到也沒收回，就成了多餘的入口
登入方式	全天自動執行，不需要有人在場登入	靠用戶端密碼或憑證登入，外洩後別人也能直接拿來用，平常也很少有人盯著它的登入狀況
管理規模	MSP 用同一套工具就能服務多家客戶	同一套工具的權限可能橫跨好幾家企業

Microsoft 也提供「受控識別」（managed identity）等做法，讓部分在 Azure 上執行的工具不必自己管理認證，從源頭減少外洩的機會。

場景	例子
雲端備份	備份服務定期讀取郵件、OneDrive 與 SharePoint 檔案
資安與監控	監控工具讀取登入紀錄與告警，集中到資安平台
自動化管理	IT 人員用腳本批次建立帳號、調整設定
系統整合	公司自己的網站或系統透過 Microsoft Graph 讀取行事曆、郵件等資料
程式部署	開發流程自動把網站從 GitHub 部署到 Azure

依 Microsoft Learn 的官方說明，服務主體分成三種：

類型	怎麼來的	要注意的地方
Application	註冊應用程式，或同意某個工具存取公司資料時自動建立，MSP 接上的第三方工具多半屬於這種	可以設定用戶端密碼或憑證，這次事件被冒用的就是這一類
受控識別（Managed identity）	在 Azure 上啟用受控識別時自動建立	不必自己管理認證，也不能直接修改，只能指派權限
Legacy	應用程式註冊功能推出前建立的舊應用程式	沒有對應的應用程式註冊，但仍可能設有認證，只能在建立它的公司環境裡使用

在 Microsoft Entra 系統管理中心的「企業應用程式」頁面，可以查看與管理這些身分。

有委外 IT 的公司，環境裡通常就有好幾張這樣的門禁卡，而且多半是 MSP 幫忙發的。這次事件的入口，就是這種平常沒人注意的身分。

企業不需要自己懂設定，但可以請 MSP 用書面回答下面這些問題：

要問 MSP 的問題	為什麼要問
我們的 Microsoft 365 裡接了哪些工具？各自能讀寫哪些資料？	用不到的工具、給太大的權限，都是多出來的入口
這些工具用什麼方式登入？用戶端密碼多久更換一次？	Microsoft 官方文件指出，用戶端密碼的安全性不如憑證，不建議用在正式環境
你們有哪些可以管理我們環境的權限？期限到什麼時候？	MSP 的管理權限一旦被冒用，攻擊者就能進一步入侵客戶的環境
我們的用戶端密碼或設定，有沒有寫在文件、工單或程式碼裡？	Microsoft 這次追查到的外洩來源之一，就是公開的程式碼儲存庫
有沒有定期檢查「服務主體登入」的紀錄？最近一次是什麼時候、結果如何？	Microsoft Entra 的登入紀錄會把員工登入和服務主體登入分開記錄，只看員工登入會漏掉；這次被冒用的正是服務主體
如果你們自己被入侵，多久內會通知我們？	先講好通知時間，出事時才不會最後一個知道

遇到像這次這樣有明確時間點的事件，就可以把事件資訊加進去一起問。以這次為例，依 Microsoft 的紀錄，攻擊最早可追溯到 10 月 28 日，可以請 MSP 針對下面幾點回覆：

檢查項目	這次事件的資訊
檢查期間	從 2026 年 10 月 28 日起到現在
攻擊來源 IP	199.19.77.84、199.19.77.18（Microsoft 註明後者是 Tor 出口節點，紀錄裡可能混有不相關的活動）
要看的紀錄	服務主體登入，包含登入失敗的紀錄

如果公司有 Microsoft 365 的管理員帳號，可以到 Microsoft Entra 系統管理中心的「企業應用程式」清單看看。看到不認得的名稱，就列出來請 MSP 說明用途。

另外，也可以把和 MSP 簽的合約拿出來確認，裡面有沒有寫明資安事件的通知時限與處理責任。

如果 MSP 確認有異常登入，很多人第一個反應是把密碼換掉。這裡我們直接引用 Todyl 調查報告中的原文：

Don't rely on rotation alone.

原因是攻擊者先前已經拿到的存取權杖（access token），不會因為換了密碼就跟著失效，要等權杖本身過期才會失效。

完整的排查與清除步驟，可以直接看 Todyl 的處理建議與 Microsoft 的緩解說明，請交由 MSP 或具備權限的管理員照著處理。

這類事件最容易被忽略的，是服務主體不像員工帳號會被定期盤點。趁這次新聞，請 MSP 把授權清單交出來對一遍，成本不高，比等到出事再查合算。