掌握 MSP 的 SentinelOne 多租戶部署

MSP 必讀的 SentinelOne 多租戶部署指南：結合 Intune 與 RMM 的完整實務

將端點偵測與回應 (EDR) 代理程式推播到單一機器相對簡單。SentinelOne 提供了簡潔的安裝命令和完善的封裝文件。然而，託管服務提供商 (MSP) 面臨著更艱鉅的挑戰：如何在數十個獨立的客戶環境中一致地部署代理程式、維護版本一致性、確保正確的站點分配，並大規模管理後續的政策。

核心挑戰在於多租戶架構。這需要將每個客戶映射到特定的站點和權杖，透過 Microsoft Intune 或 RMM（如 NinjaOne、ConnectWise Automate 等）等工具交付代理程式，並在不手動檢查每個主控台的情況下確認覆蓋率。

本指南詳細說明如何使用 Intune 和 RMM 執行可重複的多租戶 SentinelOne 推廣，並解決大多數推廣過程中忽視的挑戰：隨著客戶數量的增長保持部署的一致性。

多租戶部署的不同之處：站點架構與權杖

在碰觸安裝程式或編寫部署指令碼之前，請先定義您的 SentinelOne 站點階層結構，因為它決定了後續的一切作業。

SentinelOne 將租戶組織為帳戶 (Accounts)、站點 (Sites) 和群組 (Groups) 的階層結構。對於 MSP 的使用場景，標準做法是每個客戶租戶設立一個站點，並在站點內設置群組以進行政策細分（例如區分伺服器與工作站）。每個站點都會發行自己的站點權杖 (Site Token)，這是一個唯一的字串，用於告知安裝中的代理程式應註冊到哪一個站點。

該權杖是多租戶推廣的核心轉折點。使用客戶 A 的權杖安裝的代理程式會落入客戶 A 的站點並繼承客戶 A 的政策。如果使用錯誤的權杖安裝，端點就會出現在錯誤的客戶環境中，這既是安全覆蓋問題，也是客戶資料隔離的問題。

這就是為什麼重複使用單一安裝套件無法乾淨地套用到所有客戶的原因。二進位檔雖然相同，但將每個代理程式綁定到正確租戶的權杖卻不相同。以下每種部署方法都在解決同一個問題：在不手動編輯每次安裝的情況下，重複且可靠地將正確的客戶專屬權杖交付到正確的機器集上。

部署前的準備清單

在開始部署之前，請確認以下先決條件已準備就緒：

先決條件 (Prerequisite)	說明 (Description)
權限與存取	確認您擁有提取站點權杖及管理目標客戶站點所需的管理員角色權限。
站點/群組架構	為每個客戶租戶建立一個獨立的站點，並配置內部群組以匹配您的政策細分策略。
提取權杖	檢索您要部署的每個站點的權杖，並將其安全地儲存在您的部署工具可以引用的位置。
標準化版本	決定全局推廣所要標準化的代理程式版本。在安裝時混合使用不同版本會在第一天就造成版本偏差。
作業系統對應	確認客戶裝置的作業系統分布（Windows、macOS、Linux），並確保擁有每個平台對應的安裝程式。
部署策略	根據現有管理機制，確定每個客戶最適合透過 Intune、RMM 還是混合方式進行存取。

透過 Microsoft Intune 進行部署

Intune 適用於裝置已註冊在您所管理的 Microsoft 365 租戶中的客戶。Windows 代理程式會作為 Win32 應用程式進行部署。

1. 封裝安裝程式

從主控台下載最新的 Windows 代理程式 MSI，然後使用 Microsoft Win32 內容準備工具 (IntuneWinAppUtil.exe) 將其打包為 .intunewin 檔案。盡可能使用 MSI 而不是 EXE，因為它能提供乾淨的無靜默安裝/解除安裝命令，以及傳遞站點權杖的可預測位置。

2. 配置命令與偵測規則

將安裝命令設定為將站點權杖作為 MSI 屬性傳遞：

msiexec /i SentinelInstaller.msi /qn SITE_TOKEN=<client-site-token>

設定對應的解除安裝命令，如果站點需要解除安裝通行碼，請考量防篡改 (Anti-Tamper) 保護。

關鍵步驟：偵測規則。這是多租戶 Intune 部署中最常出錯的地方。因為 MSI 產品代碼會隨代理程式版本而改變，所以依賴產品代碼的規則僅在固定的版本上準確。一旦代理程式從 SentinelOne 主控台自動更新，Intune 就會將受保護的端點誤讀為未安裝並再次推播套件。硬編碼的檔案路徑也有同樣的缺點，因為代理程式會安裝到帶有版本標籤的資料夾中。

請改用自訂偵測指令碼，驗證 SentinelOne 服務或特定登錄檔機碼的存在，並確保已安裝的版本符合您的最低要求。或者，使用基於版本比較而非固定路徑存在的檔案規則。請務必對照您固定代理程式版本的部署指南，確認確切的屬性名稱、安裝路徑和登錄機碼。

3. 租戶專屬群組分配

為每個客戶建立一個專用的 Entra ID 裝置群組，並將封裝好的應用程式分配給該群組。由於權杖已硬編碼在安裝命令中，每個客戶站點都需要有自己獨立的應用程式執行個體。雖然 Intune 能提供乾淨的封裝與動態群組，但營運上的折衷方案是必須為每個客戶租戶維護單獨的應用程式套件。

4. macOS 部署注意事項

macOS 的部署需要單獨的套件，且包含額外的核准步驟。代理程式通常需要完全磁碟存取權 (Full Disk Access)、網路擴充套件核准，以及內容篩選核准，所有這些都可以透過 Intune 或其他 MDM 作為設定檔 (Configuration Profiles) 推播，使代理程式在沒有終端使用者提示的情況下進行安裝。請透過安裝指令碼、權杖檔案或設定檔交付註冊權杖，按客戶界定範圍。

透過 RMM 進行部署：多租戶的主力工具

對於大多數 MSP 來說，RMM 是多租戶部署中更自然的選擇，因為它本身就將客戶建模為獨立的實體，且能直接運行指令碼。

為何 RMM 更適合多租戶

RMM 允許您將每個客戶的站點權杖儲存為組織層級的變數，並在所有地方運行單一部署指令碼。指令碼會讀取其運行的客戶變數，因此您只需維護一套部署邏輯，而非每個租戶維護一個封裝應用程式。NinjaOne、ConnectWise Automate、Atera 和 Syncro 等 RMM 都支援這種架構。

執行安裝

透過 RMM 的指令碼引擎部署 MSI，傳遞客戶的權杖變數：

msiexec /i SentinelInstaller.msi /qn SITE_TOKEN=%SiteToken%

（請將 %SiteToken% 替換為您 RMM 的特定變數語法。） 這單一指令碼即可即時擴展到所有客戶。對於 macOS 設備，運行相應的安裝指令碼，並從相同的變數中提取客戶的註冊權杖。

管理升級與防篡改通行碼

一旦代理程式成功註冊到正確的站點，它就會繼承該處分配的政策。版本升級通常透過 SentinelOne 主控台的代理程式更新政策進行集中管理，從而將升級邏輯排除在 RMM 之外。

重新安裝和轉移需要額外的規劃，因為防篡改控制可能會阻止代理程式被移除或替換。預設情況下，SentinelOne 會為每個單獨的端點產生唯一的解除安裝通行碼，而不是每個客戶一個。請確保您的自動化工具可以透過程式存取檢索這些唯一的通行碼，否則技術人員將不得不手動在主控台中查詢每台機器的通行碼。

驗證跨租戶部署

當指令碼報告「成功」時，部署並未結束。您必須手動驗證每個租戶的結果：

• 驗證站點分配：抽查每個客戶的代理程式是否出現在該客戶的站點中，而不是其他站點。變數錯誤導致的路由錯誤非常常見且容易被忽略。
• 對比資產清單：將 SentinelOne 主控台中每個站點的代理程式數量與 RMM 報告的裝置清單進行比較。兩者之間的任何差異都是需要處理的端點清單。
• 追蹤未連線裝置：識別從未報到、安裝後不久即離線或在推廣期間關機的端點，並重新進行針對性部署。
• 密鑰安全性審查：確認權杖未暴露在客戶可讀取的記錄檔或指令碼中，且您能夠檢索任何指定端點的解除安裝通行碼。

請按客戶獨立執行此驗證。整體較高的覆蓋率可能會掩蓋單一客戶環境中的嚴重覆蓋盲點。

持續的挑戰：偏離與一致性

部署只是起點。更艱鉅的工作是隨著客戶數量的增加，保持版本、政策、覆蓋率和密鑰的一致性。您將不可避免地需要應對四種類型的偏離 (Drift)：

• 版本偏離 (Version Drift)：由於分階段入職和不一致的更新政策，客戶最終使用不同的代理程式版本。
• 政策偏離 (Policy Drift)：基準安全政策在特定事件期間被修改，且從未還原，導致安全姿態碎片化。
• 入職漏洞 (Onboarding Gaps)：新裝置加入客戶環境但未繼承代理程式，導致端點失去保護。
• 權杖蔓延 (Token Sprawl)：需要安全追蹤的密鑰數量呈指數級增長（每個新增的租戶有一個站點權杖，加上每個端點唯一的解除安裝通行碼）。

雖然指令碼可以處理初始部署，但它們無法處理大規模保持一致性所需的持續多租戶協調工作。

透過整合平台降低營運負擔

如果持續的站點權杖、通行碼和政策偏離管理正使您的團隊不堪重負，值得評估為您管理這些複雜性的平台。像 Guardz 這樣的解決方案透過以 MSP 為中心的營運模式提供 SentinelOne Singularity。

核心 EDR 技術保持不變——您依然使用業界領先的 SentinelOne 代理程式和偵測引擎，並保留原生主控台的存取權。改變的是圍繞它的商業與營運包裝：

• 無席位最低限制：隨客戶成長按需新增端點，無需承諾最低席位門檻。
• 統一合約：無需管理單獨的 SentinelOne MSSP 合約，全數整合至現有的平台方案中。
• 包含 24/7 MDR 分流：Guardz MDR 團隊全天候分流 EDR 警報，防止技術人員產生警報疲勞。
• 集中化協調：站點建立、權杖注入、政策強制執行和生命週期管理皆在平台內原生運行，同時保留原生主控台以供深入調查。

透過轉向整合平台，繁重的多租戶底層工作（管理無窮無盡的權杖、通行碼和更新政策）將從日常營運頭痛問題轉變為簡化的自動化設定。