身分識別和超越 — 一位架構師的觀點

  • 文章

在本文中，Microsoft 首席技術架構師 Alex Shteynberg 討論採用 Microsoft 365 和其他 Microsoft 雲端服務的企業組織最佳設計策略。

關於作者

Alex Shteynberg 相片。

我是紐約 Microsoft 技術中心的首席技術架構師。 我主要與大型客戶合作，且需求複雜。 我的觀點和意見是以這些互動為基礎，而且可能不適用於每種情況。 不過，在我的經驗中，如果我們能協助客戶解決最複雜的挑戰，我們就能協助所有客戶。

我通常每年與100位以上的客戶合作。 雖然每個組織都有獨特的特性，但查看趨勢和共通性很有趣。 例如，對許多客戶而言，其中一個趨勢是跨產業的興趣。 畢竟，銀行分公司也可以是咖啡廳和社群中心。

我的角色著重於協助客戶達成最佳的技術解決方案，以解決其獨特的一組商務目標。 正式而言，我著重於身分識別、安全性、隱私權和合規性。 我喜歡這些觸控我們所做的一切。 這可讓我有機會參與大部分專案。 此活動讓我忙碌並享受這個角色。

我身處紐約市 (最佳！) ，真正享受其文化、食物和人員的多樣性， (不是流量) 。 我想要在生命週期中看到全世界的大多數時，都能旅行。 我目前正在研究非洲的旅行，以瞭解野生動物。

指導原則

  • 簡單通常更好：您幾乎可以使用技術 () 任何專案，但這並不表示您應該這麼做。 特別是在安全性領域中，許多客戶會過度設計解決方案。 我喜歡來自Google Stripe會議的 這段影片 ，以強調這一點。
  • 人員、程式、技術：為人們設計以增強程式，而不是先設計技術。 沒有「完美」的解決方案。 我們需要平衡各種風險因素，以及每個業務可能不同的決策。 太多客戶會設計使用者稍後可避免的方法。
  • 著重於第一個和「如何」稍後的「原因」：成為有一百萬個問題的 7 歲小孩。 如果不知道要詢問的正確問題，我們就無法取得正確的答案。 許多客戶會假設需要如何運作，而不是定義商務問題。 一律有多個可採用的路徑。
  • 過去最佳做法的長尾：辨識最佳做法會以輕量的速度變更。 如果您在三個月前查看 Microsoft Entra，表示您可能已過期。 此處的所有項目在發行后都可能會變更。 現在的 [最佳] 選項可能與六個月後不同。

基準概念

請勿略過本節。 我通常會發現我必須回溯到這些文章，即使是使用雲端服務數年的客戶也是如此。 不過，語言不是精確的工具。 我們通常會使用相同的單字來表示不同的概念或不同的單字，以表示相同的概念。 我通常會使用下圖來建立一些基準術語和「階層模型」。

租使用者、訂用帳戶、服務和數據的圖例。

當您瞭解如何遊水時，最好是從集區開始，而不是在海邊。 我並未嘗試使用此圖表在技術上正確無誤。 這是討論一些基本概念的模型。

在此圖表中：

  • 租使用者 = Microsoft Entra ID 的實例。 其位於階層的「頂端」，或圖表中的層級 1。 我們可以將此層級視為「界限」，其中除了) 之外，其他所有專案 (Microsoft Entra B2B。 所有 Microsoft 企業雲端服務都是其中一個租使用者的一部分。 取用者服務是分開的。 「租使用者」在檔中會顯示為 Microsoft 365 租使用者、Azure 租使用者、WVD 租使用者等等。 我經常發現這些變化會造成客戶混淆。
  • 圖表中層級 2 的服務/訂用帳戶屬於一個租使用者，而且只有一個租使用者。 大部分的 SaaS 服務都是 1：1，不需要移轉就無法移動。 Azure 不同，您可以 將計費 和/或 訂 用帳戶移至另一個租使用者。 有許多客戶需要移動 Azure 訂用帳戶。 此案例具有各種影響。 存在於訂用帳戶外部的物件不會移動。 例如，角色型訪問控制 (Azure RBAC) 、Microsoft Entra 物件 (群組、應用程式、原則等 ) ，以及某些服務 (Azure 金鑰保存庫、數據磚等 ) 。 請勿在沒有良好商務需求的情況下移轉服務。 GitHub 上會共用一些有助於移轉的腳本。
  • 指定的服務通常會有某種「層級」界限，或層級 3 (L3) 。 此界限有助於瞭解安全性、原則、治理等的隔離。 可惜的是，我不知道任何統一的名稱。 L3 的一些範例名稱包括：Azure 訂用帳戶 = 資源;Dynamics 365 CE = 實例;Power BI = 工作區;Power Apps = environment;依此類推。
  • 層級 4 是實際數據所在的位置。 此「數據平面」是一篇複雜的文章。 有些服務使用 RBAC 的 Microsoft Entra ID，有些則不使用。 當我們開始委派文章時，我會稍微討論一下。

我發現許多客戶 (和 Microsoft 員工) 對某些其他概念感到混淆，或有下列問題：

  • 任何人都可以免費建立許多租使用者。 您不需要在其中布建服務。 我有幾十個 在 Microsoft 的全球雲端服務中，每個租用戶名稱都是唯一的 (換句話說，沒有兩個租使用者可以有相同的名稱) 。 它們全都使用 TenantName.onmicrosoft.com 格式。 另外還有一些程式會自動建立租使用者 (非受控租 使用者) 。 例如，當使用者使用任何其他租使用者中不存在的電子郵件網域註冊企業服務時，可能會發生此結果。
  • 在受控租使用者中，許多 DNS 網域 都可以在其中註冊。 此結果不會變更原始租用戶名稱。 除了移轉) 之外，目前沒有簡單的方法可將租使用者重新命名 (。 雖然目前租用戶名稱在技術上並不重要，但有些人可能會覺得受限於此實境。
  • 即使您尚未規劃部署任何服務，也應該為您的組織保留租用戶名稱。 否則，有人可以從您取得它，而且沒有簡單的程式可將它帶回 (與 DNS 名稱) 相同的問題。 我經常向客戶聽到這種訊息。 您的租用戶名稱應該是一篇爭議文章。
  • 如果您擁有 DNS 命名空間，您應該將所有這些命名空間新增至您的租使用者。 否則，使用者可以使用此名稱建立 Unmanaged 租使用者，進而造成管理中斷。
  • 例如，DNS 命名空間 (，contoso.com) 只能属于一个租用户。 這項需求會影響各種案例 (例如，在合併或收購期間共用電子郵件網域等) 。 有一種方法可以註冊 DNS 子 (，例如在不同的租用戶中 div.contoso.com) ，但應該避免這麼做。 藉由註冊最上層功能變數名稱，所有子域都會假設屬於相同的租使用者。 在多租使用者案例中， (如下) 我通常會建議使用另一個最上層域名 (，例如 contoso.ch 或 ch-contoso.com) 。
  • 誰應該「擁有」租使用者？ 我經常會看到不知道誰目前擁有其租用戶的客戶。 缺乏知識是一個重要的紅色旗標。 呼叫 Microsoft 支援 ASAP。 就像服務擁有者 (通常會指定 Exchange 系統管理員) 來管理租用戶一樣有問題。 租使用者包含您未來可能想要的所有服務。 租用戶擁有者應該是一個群組，可決定在組織中啟用所有雲端服務。 另一個問題是要求租用戶擁有者群組管理所有服務。 這個方法不會針對大型組織進行調整。
  • 沒有子/進階租使用者的概念。 基於某些原因，這個迷思會持續重複。 此概念也適用於 Azure Active Directory B2C 租使用者。 我聽到太多次「我的 B2C 環境在我的 XYZ 租使用者中」或「如何? 將我的 Azure 租使用者移至我的 Microsoft 365 租使用者？」
  • 本檔主要著重於全球商業雲端，因為這是大部分客戶所使用的功能。 了解 主權雲端有時會很有用。 主權雲端有其他影響，可討論哪些超出此討論範圍。

基準身分識別文章

有許多關於 Microsoft 身分識別平台的檔 – Microsoft Entra ID。 對於剛開始的人來說，這通常會讓人感到難以接受。 即使在您了解之後，保持持續創新和變更也極具挑戰性。 在我的客戶互動中，我經常發現自己是商務目標與「良好、更好、最佳」方法之間的「翻譯者」，以解決這些文章 (和人類「小記事」) 。 很少會有完美的答案，而「正確」決策是各種風險因素的平衡。 接下來是一些我常與客戶討論的常見問題和混淆領域。

佈建

Microsoft Entra ID 無法解決身分識別世界中缺乏治理的問題！ 身分識別治理 應該是與任何雲端決策無關的重要元素。 治理需求會隨著時間而改變，這就是為什麼它是程式而非工具。

Microsoft Entra Connect與 Microsoft Identity Manager (MIM) ，還是 (第三方或自定義) ？ 立即及未來儲存問題，並使用 Microsoft Entra Connect。 此工具中具有各種智慧型手機，可解決客戶設定和持續創新的問題。

某些邊緣案例可能會推動更複雜的架構：

  • 我有多個 AD 樹系，但它們之間沒有網路連線。 有一個新選項稱為 雲端布建。
  • 我沒有 Active Directory，也不想要安裝它。 Microsoft Entra Connect 可以設定為從 LDAP 同步 (可能需要合作夥伴) 。
  • 我需要將相同的物件布建到多個租使用者。 此案例在技術上不受支援，但取決於「相同」的定義。

我是否應該自定義預設同步處理規則 (篩選對象、 變更屬性、 替代登入標識碼等) ？ 請避免！ 身分識別平臺只和使用身分識別平臺的服務一樣有價值。 雖然您可以執行所有種類的簡便設定，但若要回答此問題，您必須查看對應用程式的影響。 如果您篩選啟用郵件的物件，則適用於 線上服務的 GAL 不完整;如果應用程式依賴特定屬性，則篩選這些屬性會產生無法預期的影響，依此類推。 這不是身分識別小組的決定。

XYZ SaaS 支援 Just-in-Time (JIT) 布建，為什麼您需要我進行同步處理？ 請參閱上一個段落。 許多應用程式都需要功能的「配置檔」資訊。 如果所有啟用郵件的物件都無法使用，您就不能有 GAL。 同樣適用於與 Microsoft Entra ID整合之應用程式中的使用者布建。

驗證

密碼哈希同步 (PHS) 與 PTA) 與同盟 (傳遞驗證。

通常會有關於同盟的熱衷 爭議 。 通常比較簡單，因此除非您有充分的理由不使用 PHS，否則請使用 PHS。 您也可以為相同租使用者中的不同 DNS 網域設定不同的驗證方法。

有些客戶主要針對下列項目啟用同盟 + PHS：

我經常引導客戶完成客戶端驗證流程，以釐清一些誤解。 結果如下圖所示，這不如到達該處的互動式程式。

白板對話範例。

這種類型的白板繪圖說明在驗證要求流程中套用安全策略的位置。 在此範例中，透過 Active Directory 同盟服務 (AD FS) 強制執行的原則會套用至第一個服務要求，但不會套用至後續的服務要求。 此行為至少是將安全性控件盡可能移至雲端的一個原因。

只要我記得，我們一直都在追求 單一登錄 (SSO) 。 有些客戶認為他們可以選擇「正確的」同盟 (STS) 提供者來達成單一登錄。 Microsoft Entra ID 可大幅協助啟用 SSO 功能，但沒有任何 STS 是神奇的。 仍有太多「舊版」驗證方法仍用於重要應用程式。 使用合作夥伴解決方案擴充 Microsoft Entra ID 可以解決許多這類案例。 SSO 是策略和旅程。 若未移至應用程式的標準，您就無法到達 該處。 與本文相關的是 無密碼 驗證的旅程，其中也沒有任何神奇的答案。

多重要素驗證 (MFA) 目前在這裡 (，以取得 更多) 。 將 使用者行為分析新 增至其中，您有可防止最常見的網路攻擊的解決方案。 甚至取用者服務也會移至 需要 MFA。 不過，我仍與許多不想移至 新式驗證 方法的客戶開會。 我聽到的最大自變數是它會影響使用者和舊版應用程式。 有時候，不錯的動作可能會協助客戶繼續進行， Exchange Online 宣布的變更。 現在有許多 Microsoft Entra 報告可協助客戶進行這項轉換。

授權

根據 維琪百科，「授權」是定義存取原則。 許多人將它視為能夠定義物件 (檔案、服務等) 訪問控制。 在網路威脅的目前世界中，此概念正快速演進為動態原則，可回應各種威脅向量，並快速調整訪問控制以回應它們。 例如，如果我從不尋常的位置存取我的銀行帳戶，我會取得額外的確認步驟。 若要實現此實境，我們不僅需要考慮原則本身，還需要考慮威脅偵測和訊號相互關聯方法的生態系統。

Microsoft Entra ID 的原則引擎是使用條件式存取原則來實作。 此系統依賴來自其他威脅偵測系統的資訊來進行動態決策。 簡單檢視如下圖所示：

Microsoft Entra ID 中的原則引擎。

將所有這些訊號結合在一起，可讓您使用如下的動態原則：

  • 如果在您的裝置上偵測到威脅，您對數據的存取只會降低為 Web，而無法下載。
  • 如果您正在下載非常大量的數據，則您下載的任何專案都會加密並受到限制。
  • 如果您從非受控裝置存取服務，系統會封鎖您存取高度敏感數據，但允許您存取非重設大小的數據，而無法將它複製到另一個位置。

如果您同意此擴充的授權定義，則必須實作其他解決方案。 您實作的解決方案取決於您希望原則的動態程度，以及您想要優先處理哪些威脅。 這類系統的一些範例包括：

除了 Microsoft Entra ID，各種服務和應用程式都有自己的特定授權模型。 委派一節稍後會討論其中一些模型。

稽核

Microsoft Entra ID 具有詳細的稽核和報告功能。 不過，這些報告通常不是做出安全性決策所需的唯一資訊來源。 如需此主題的詳細討論，請參閱委派一節。

沒有 Exchange

別擔心！ (或 SharePoint 等) 不會取代 Exchange。 它仍然是核心服務。 我的意思是，一段時間以來，技術提供者已將用戶體驗 (UX) 轉換為包含多個服務的元件。 在 Microsoft 365 中，簡單範例是「新式附件」，其中電子郵件的附件會儲存在 SharePoint Online 或 OneDrive 中。

將檔案附加至電子郵件。

查看 Outlook 用戶端，您可以看到許多「已連線」的服務作為此體驗的一部分，而不只是 Exchange。 範例包括 Microsoft Entra ID、Microsoft Search、Apps、Profile、compliance 和 Microsoft 365 群組。

具有圖說文字的 Outlook 介面。

閱讀 Microsoft 流體架構 以預覽即將推出的功能。 在預覽版中，我可以直接在 Outlook 中讀取和回復 Teams 交談。 事實上， Teams 客戶 端是此策略最顯著的範例之一。

整體而言，在 Microsoft 365 與 Microsoft 雲端中的其他服務之間繪製清楚的線條變得越來越困難。 我將其視為對客戶的絕佳好處，因為即使客戶使用一個元件，他們也能從我們所做的所有專案中獲得全面創新的好處。 相當酷，對許多客戶具有深遠的影響。

今天，我發現許多客戶IT群組都是以「產品」為建構。這是內部部署世界的邏輯，因為您需要每項特定產品的專家。 不過，很高興因為這些服務已移至雲端，所以不必再對 Active Directory 或 Exchange 資料庫進行偵錯。 自動化 (基本上是雲端) 移除某些重複的手動作業， (查看處理站) 發生的情況。 不過，這些工作會取代為更複雜的需求，以瞭解跨服務互動、效果、商務需求等等。 如果您願意 學習，雲端轉換會提供絕佳的機會。 進入技術之前，我經常與客戶討論如何管理IT技能和小組結構的變更。

對所有 SharePoint 風扇人員和開發人員，請停止詢問「如何在 SharePoint Online 中執行 XYZ？」針對工作流程使用 Power Automate (或 Flow) ，這是一個功能更強大的平臺。 使用 Azure Bot Framework 為您的 500 K 專案清單建立更好的 UX。 開始使用 Microsoft Graph ，而不是 CSOM。 Microsoft Teams 包含 SharePoint，但也包含更多世界。 我可以列出許多其他範例。 有一個龐大而絕佳的宇宙。 開啟門並 開始探索。

另一個常見的效果是在合規性區域中。 這種跨服務方法似乎完全混淆了許多合規性政策。 我持續看到組織指出「我需要將所有電子郵件通訊記錄到電子檔探索系統」。當電子郵件不再只是電子郵件，而是進入其他服務的視窗時，此語句真正代表什麼意思？ Microsoft 365 具有完整的 合規性方法，但變更人員和程式通常比技術困難得多。

還有許多其他人員和程式含意。 我的意見是，此因素是重要且討論不足的領域。 或許在另一篇文章中還有更多內容。

租用戶結構選項

單一租使用者與多租使用者

一般而言，大部分的客戶應該只有一個生產租使用者。 有許多原因會導致多個租用戶難以 (提供 Bing 搜尋) 或閱讀此 白皮書。 同時，與我合作的許多企業客戶都有另一個 (小型) 租使用者，用於IT學習、測試和實驗。 使用 Azure Lighthouse 可更輕鬆地存取跨租使用者 Azure。 Microsoft 365 和許多其他 SaaS 服務對於跨租使用者案例有限制。 Microsoft Entra B2B 案例中需要考慮許多事項。

在 M&A) 進行合併和收購之後 (，許多客戶最終會擁有多個生產租使用者，並想要合併。 現在這並不簡單，而且需要 Microsoft 諮詢服務 (MCS) 或合作夥伴加上第三方軟體。 未來將持續進行工程工作，以處理多租用戶客戶的各種案例。

有些客戶選擇使用多個租使用者。 這應該是謹慎的決策，而且幾乎永遠都是商業原因驅動！ 部分範例包括下列原因：

  • 保留型別公司結構，不需要在不同實體之間輕鬆共同作業，而且有強大的系統管理和其他隔離需求。
  • 取得之後，會做出商務決策，將兩個實體分開。
  • 模擬不會變更客戶生產環境的客戶環境。
  • 為客戶開發軟體。

在這些多租使用者案例中，客戶通常會想要在租用戶之間維持相同的組態，或報告組態變更和漂移。 這通常表示從手動變更移至設定即程序代碼。 Microsoft Marketplace 支援會根據此公用 IP 提供這些需求類型的研討會： https://Microsoft365dsc.com。

多地理位置

若要 多地理位置 ，或不移至多地理位置。 這就是問題所在。 使用 Microsoft 365 多地理位置，您可以在您選擇的地理位置中布建和儲存待用數據，以符合 數據落地 需求。 這項功能有許多誤解。 請牢記下列要點：

  • 它無法提供效能優勢。 如果 網路設計 不正確，可能會使效能變差。 讓裝置「靠近」Microsoft 網路，不一定對您的數據。
  • 這不是 GDPR合規性的解決方案。 GDPR 不會將焦點放在數據主權或儲存位置。 數據主權或儲存位置還有其他合規性架構。
  • 它無法解決委派系統管理 (請參閱下列) 或 資訊屏障。
  • 它與多租使用者不同，而且需要更多 使用者布建 工作流程。
  • 它不會將您的租使用者 ( 您的 Microsoft Entra ID) 移至另一個地理位置。

委派系統管理

在大部分的大型組織中，職責區分和角色型訪問控制 (RBAC) 是必要的實境。 我即將事先抱歉。 此活動不像某些客戶想要那麼簡單。 客戶、法律、合規性和其他需求都不同，有時會在世界各地發生衝突。 簡單和彈性通常彼此相反。 別誤會我，我們可以在此目標上執行更好的工作。 已 (，且會隨著時間) 大幅改善。 請造訪您的本機 Microsoft 技術中心 ，在不閱讀 379,230 份文件的情況下，找出符合您商務需求的模型！ 在這裡，我著重於您應該思考的，而不是為什麼會這樣。 接下來有五個不同的領域可供規劃，以及我遇到的一些常見問題。

Microsoft Entra ID和 Microsoft 365 系統管理中心

內 建角色的清單很長且不斷成長。 每個角色都包含群組在一起的角色許可權清單，以允許執行特定動作。 您可以在每個角色內的 [描述] 索引標籤中看到這些許可權。 或者，您可以在 Microsoft 365 系統管理 中心看到更人性化的這些許可權版本。 無法修改內建角色的定義。 我通常會將這些角色分成三個類別：

  • 全域管理員：此「所有功能強大的」角色應該受到高度保護，就像您在其他系統中一樣。 一般建議包括：不使用永久指派，並使用 Microsoft Entra Privileged Identity Management (PIM) ;強身份驗證等等。 有趣的是，此角色預設不會讓您存取所有專案。 我通常會看到合規性存取和 Azure 存取的混淆，稍後會加以討論。 不過，此角色一律可以將存取權指派給租使用者中的其他服務。
  • 特定服務管理員：某些服務 (Exchange、SharePoint、Power BI 等) 取用來自 Microsoft Entra ID 的高階系統管理角色。 此行為在所有服務之間並不一致，稍後會討論更多服務特定角色。
  • 功能：有很長 (且成長) 的角色清單著重於特定作業 (來賓邀請者等等) 。 這些角色會定期根據客戶需求新增。

雖然間距) 減少，但無法將所有專案委派 (，這表示有時需要使用全域系統管理員角色。 應考慮設定即程式代碼和自動化，而不是此角色的人員成員資格。

注意：相較於 Microsoft Entra 系統管理員體驗，Microsoft 365 系統管理中心 具有更方便使用的介面，但具有一部分功能。 這兩個入口網站都使用相同的 Microsoft Entra 角色，因此變更會在同一處發生。 秘訣：如果您想要以身分識別管理為主的系統管理 UI，而不需要所有 Azure 雜亂，請使用 https://aad.portal.azure.com。

名稱中有哪些？ 請勿從角色名稱進行假設。 語言不是精確的工具。 目標應該是定義需要委派的作業，再查看需要哪些角色。 將某人新增至「安全性讀取者」角色並不會讓他們看到所有專案的安全性設定。

建立 自定義角色 的能力是常見的問題。 如稍後) 所述，目前 Microsoft Entra (此功能受到限制，但功能會隨著時間成長。 我認為這些自定義角色適用於 Microsoft Entra ID 中的函式，而且可能不會如先前) 所述，跨越階層模型 (。 每當我處理「自定義」時，我通常會回到「簡單更好」的主體。

另一個常見的問題是能夠將角色範圍設定為目錄的子集。 其中一個範例類似「僅適用於歐盟用戶的技術服務人員系統管理員」。 管理單位 旨在解決此案例。 如先前所述，我認為這些範圍適用於 Microsoft Entra ID 中的函式，而且可能不會跨越「向下」。某些角色不適用於 (全域系統管理員、服務管理員等) 。

現在，如果您使用 Microsoft Entra PIM) ，則所有這些角色都需要直接成員資格 (或動態指派。 這表示客戶必須直接在 Microsoft Entra ID 中管理這些角色，而且這些角色不能以安全組成員資格為基礎。 我並不是建立腳本來管理這些角色的風扇，因為它需要以更高的許可權來執行。 我通常建議 API 與 ServiceNow 等程式系統整合，或使用 Saviynt 等合作夥伴治理工具。 經過一段時間后，有工程工作可以解決此問題。

我 Microsoft Entra PIM 提及過幾次。 內部部署控制有對應的 Microsoft Identity Manager (MIM) Privileged Access Management (PAM) 解決方案。 您可能也想要查看特殊權限存取工作站 (PAW) 和 Microsoft Entra ID 控管。 也有各種第三方工具，可以啟用 Just-In-Time、Just-enough 和動態角色提升。 這項功能通常是保護環境的較大型討論的一部分。

有時候，案例會要求將外部使用者新增至角色 (請參閱先前的多租用戶一節) 。 此結果可正常運作。 Microsoft Entra B2B 是另一篇大型且有趣的文章，可引導客戶完成，或許在另一篇文章中。

Microsoft Defender 全面偵測回應 和 Microsoft 365 Purview 合規性入口網站

Email &Microsoft Defender 入口網站中的共同作業角色和 Microsoft 365 Purview 合規性入口網站中 Microsoft Purview 解決方案的 *角色群組是「角色群組」的集合，與 Microsoft Entra 角色不同。 這可能會造成混淆，因為其中有些角色群組的名稱與 Microsoft Entra 角色的名稱相同 (例如安全性讀取者) ，但其成員資格可能不同。 我偏好使用 Microsoft Entra 角色。 每個角色群組都包含一或多個「角色」， (查看重複使用同一個字組的意義？) ，並擁有來自 Microsoft Entra ID 的成員，也就是啟用電子郵件的物件。 此外，您可以使用與角色相同的名稱來建立角色群組，這可能會包含該角色， (避免此混淆) 。

就意義而言，這些許可權是 Exchange 角色群組模型的演進。 不過，Exchange Online 有自己的角色群組管理介面。 Exchange Online 中的某些角色群組會從 Microsoft Entra ID 或 Microsoft Defender 全面偵測回應 和 Microsoft 365 Purview 合規性入口網站進行鎖定和管理，但其他角色群組可能具有相同或類似的名稱，而且會在 Exchange Online (造成混淆) 。 除非您需要 Exchange 管理的範圍，否則建議您避免使用 Exchange Online 使用者介面。

您無法建立自定義角色。 角色是由 Microsoft 所建立的服務所定義，並隨著新服務的引進而持續成長。 此行為在概念上類似於應用程式在 Microsoft Entra ID 中定義的角色。 啟用新的服務時，通常需要建立新的角色群組，才能授與或委派這些 (的存取權，例如 內部風險管理。

這些角色群組也需要直接成員資格，而且不能包含 Microsoft Entra 群組。 可惜的是，目前 #DEF2E873BD4444D209FC3365D12DE4525 PIM 不支持這些角色群組。 就像 Microsoft Entra 角色一樣，我通常建議透過 API 或像是 Saviynt 等合作夥伴治理產品來管理這些角色群組。

Microsoft Defender 入口網站和 Microsoft 365 Purview 合規性入口網站角色橫跨 Microsoft 365，而且您無法將這些角色群組限定在環境的子集 (如同您在 Microsoft Entra ID) 中的管理單位一樣。 許多客戶會詢問他們如何轉包。 例如，「僅為歐盟使用者建立 DLP 原則」。現在，如果您擁有 Microsoft Defender 全面偵測回應 和 Microsoft 365 Purview 合規性入口網站中特定函式的許可權，您就有許可權擁有租使用者中此函式涵蓋的所有專案。 不過，許多原則都有將環境子集設為目標的功能 (例如，「讓這些 卷標 僅供這些使用者使用」) 。 適當的治理和通訊是避免衝突的關鍵元件。 有些客戶選擇實作「設定即程式代碼」方法，以在 Microsoft Defender 全面偵測回應 和 Microsoft 365 Purview 合規性入口網站中處理子委派。 某些特定服務支援子委派 (請參閱下一節) 。

服務特定

如先前所述，許多客戶都想要達成更細微的委派模型。 常見範例：「僅針對部門 X 使用者和位置管理 XYZ 服務」 (或其他維度) 。 執行此動作的能力取決於每個服務，而且在服務和功能之間並不一致。 此外，每個服務可能會有個別且唯一的 RBAC 模型。 除了討論所有這些模型 (需要永久) ，而是為每個服務新增相關連結。 此清單尚未完成，但可讓您開始使用。

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (../compliance/index.yml)
    • 權限篩選 - (../compliance/index.yml)
    • 合規性界限 - (../compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) - (../compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • 多地理位置 - (../enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

注意事項

此連結會連結至檔的根目錄。 系統管理員/委派模型中有多種不同的服務類型。

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      注意事項

      系統管理員/委派模型中有多個具有變化的類型。

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      注意：數據平臺安全性和委派 (哪個Power BI是元件) 是一個複雜的領域。

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • 適用於端點的 Microsoft Defender - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender 全面偵測回應 - (../security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • 資訊屏障 - (../compliance/information-barriers.md)

活動記錄

Microsoft 365 具有統一的 稽核記錄。 這是非常 詳細的記錄檔，但不會讀取太多名稱。 它可能不會包含您需要或需要的安全性與合規性需求的所有專案。 此外，有些客戶對 稽核 (Premium) 非常感興趣。

透過其他 API 存取的 Microsoft 365 記錄範例包括下列功能：

請務必先識別安全性與合規性計劃所需的所有記錄來源。 另請注意，不同的記錄有不同的在線保留限制。

從系統管理員委派的觀點來看，大部分的 Microsoft 365 活動記錄沒有內建的 RBAC 模型。 如果您有查看記錄的許可權，則可以看到其中的所有內容。 客戶需求的常見範例是：「我只想要查詢歐盟用戶的活動」 (或其他維度) 。 若要達到此需求，我們需要將記錄傳送至另一個服務。 在 Microsoft 雲端中，建議您將它傳輸至 Microsoft Sentinel 或 Log Analytics。

高階圖表：

安全性與合規性計劃的記錄來源圖表。

此圖表代表將記錄傳送至事件中樞和/或 Azure 記憶體和/或 Azure Log Analytics 的內建功能。 並非所有系統都包含此現成可用的功能。 但還有其他方法可將這些記錄傳送至相同的存放庫。 例如，請參閱 使用 Microsoft Sentinel 保護您的 Teams。

將所有記錄合併到一個儲存位置包含額外的優點，例如交叉相互關聯、自定義保留時間、擴充支援 RBAC 模型所需的數據等等。 一旦數據在此記憶體系統中，您可以使用適當的 RBAC 模型建立 Power BI 儀錶板 (或其他類型的視覺效果) 。

記錄不一定只能導向至一個位置。 在 Power BI 中整合 Microsoft 365 記錄與 Microsoft Defender for Cloud Apps 或自定義 RBAC 模型也可能有説明。 不同的存放庫有不同的優點和物件。

值得一提的是，在稱為 Microsoft Defender 全面偵測回應 的服務中，有豐富的內建分析系統可提供安全性、威脅、弱點等等。

許多大型客戶想要將此記錄數據傳輸到第三方系統 (例如SIEM) 。 此結果有不同的方法，但一般而言，Azure 事件中樞 和 Graph 是不錯的起點。

Azure

我經常會問，是否有方法可以分隔 Microsoft Entra ID、Azure 和 SaaS (高許可權角色，例如：Microsoft 365 的全域管理員，而不是 Azure) 。 沒有。 如果需要完整的系統管理區隔，則需要多租用戶架構，但這會 (增加相當複雜的) 。 所有這些服務都是相同安全性/身分識別界限 (的一部分，如階層模型) 所示。

請務必瞭解相同租用戶中各種服務之間的關聯性。 我與許多客戶合作，這些客戶正在建置跨 Azure、Microsoft 365 和 Power Platform (的商務解決方案，而且通常也會在內部部署和第三方雲端服務) 。 一個常見的範例：

  1. 我想要在 Microsoft 365 (一組檔/影像/等等上共同作業)
  2. 透過Power Platform) (核准程式傳送其中每一個
  3. 核准所有元件之後，請將這些項目組合成統一的交付專案 () (Azure) Microsoft 圖形 API 是您在這裡的最佳朋友。 並非不可能，但設計跨 多個租用戶的解決方案會更加複雜。

Azure Role-Based 存取控制 (RBAC) 可為 Azure 啟用更細緻的存取管理。 使用 RBAC，您可以將執行其作業所需的最少許可權授與使用者，以管理資源的存取權。 詳細數據不在本檔的範圍內，但如需 RBAC 的詳細資訊，請參閱 什麼是 Azure 中的角色型存取控制 (RBAC) ？ RBAC 很重要，但只是 Azure 治理考慮的一部分。 雲端採用架構 是深入瞭解的絕佳起點。 我喜歡朋友 Andres Ravinet 如何逐步引導客戶完成各種元件，以決定方法。 各種元素的高階檢視 (不如取得實際客戶模型的程式) 如下所示：

委派管理的 Azure 元件高階檢視。

如上圖所示，許多其他服務應該視為設計 (一部分，例如： Azure 原則、 Azure 藍圖、 管理群組等) 。

總結

本文一開始是簡短摘要，最後比我預期的時間還長。 我希望您現在已準備好深入瞭解如何為組織建立委派模型。 此交談與客戶非常常見。 沒有一個模型適用於所有人。 在記錄我們在客戶之間看到的常見模式之前，請先等候 Microsoft 工程的一些計劃性改善。 在此同時，您可以與 Microsoft 帳戶小組合作，安排造訪最接近的 Microsoft 技術中心。 請在該處看到您！