多租用戶防禦組織的零信任設定
本文說明多租用戶組織如何在 Microsoft Entra ID 中套用設定，並符合常見的防禦零信任需求。 請遵循這些建議來建立正確的多租使用者身分識別架構，並在您的環境中實作零信任。
圖 1：具有零信任設定的多租使用者防禦架構範例。
判斷身分識別架構
Microsoft Entra 租使用者是您身分識別架構的基礎。 租使用者是Microsoft Entra ID 中的身分識別界限。 具有一個Microsoft Entra 租用戶的組織具有單一租用戶架構。 使用多個Microsoft Entra 租用戶的組織具有多租用戶架構。
單一租用戶的優點。 透過營運效率，單一租使用者更容易管理和降低成本。 它可讓您更輕鬆地設定零信任環境。 單一租使用者可避免使用多個登入認證來分散用戶體驗。 它也有助於防止稍後需要整合的孤島解決方案。 您應該努力讓單一租用戶中的數據、Microsoft 365 和 Azure 雲端服務。 如果您已經有多個Microsoft Entra 租使用者，您應該考慮將環境合併成使用單一租使用者。 您可以將 Azure 訂用帳戶從次要租用戶轉移至主要租使用者，以合併租使用者。 如需詳細資訊，請參閱 將 Azure 訂用帳戶轉移至不同的Microsoft Entra 目錄。
多租使用者使用案例。 防禦組織使用多租用戶架構有理由。 大型且複雜的防禦組織可能需要多個Microsoft Entra 租使用者，才能獲得安全性、合規性和共同作業（請參閱表 1）。
資料表 1。 擁有或建立多個租使用者的原因。
| 原因 | 範例 |
|---|---|
| 隱私權或安全性需要更深入的數據區隔 | 監察長辦公室必須獨立。 |
| 管理委派和分割 | 一個組織無法管理另一個組織。 |
| 數據主權和/或擁有權 | 一個組織沒有管理另一個組織數據的法律授權單位。 |
| 網路和IT組織 | 不可能也無法將多個大型企業IT架構折疊成單一企業架構。 |
| SOC 監視和事件回應 | SOC 需要個別租用戶來管理其角色和責任。 |
如果您需要多個Microsoft Entra 租使用者，您應該使用 Microsoft Entra 外部 ID （B2B） 和 Azure Lighthouse。 這些功能可協助支援多租使用者防禦環境。 如需詳細資訊，請參閱 多租用戶解決方案的租用模型。
識別租用戶類型
多租使用者防禦組織可以將Microsoft Entra 實例分類為主要或次要實例。 每個組織都應該識別並指定一個租用戶作為主要租使用者。 所有其他租使用者都是次要租使用者。 圖 1 顯示具有主要租使用者和 n 個次要租用戶的防禦組織（顯示的兩個次要租使用者）。
識別主要租使用者。 大部分的防禦組織會在註冊 Microsoft 365 時建立主要租使用者。 主要租使用者包含 （1） 所有使用者身分識別和Microsoft 365 個授權、（2） 個裝置和 （3） 個應用程式（請參閱圖 1）。 防禦組織通常會使用 Microsoft Entra Connect ，將身分識別從內部部署 Active Directory 同步處理到主要Microsoft Entra 租使用者。
某些防禦組織會取用Microsoft 365 個共用租使用者，由外部機構擁有及運作。 此機構作為Microsoft 365 的共用服務提供者。 您的組織可能不會管理或控制共用租使用者，但它包含您使用者可能用於 Office 365 和其他應用程式的授權Microsoft Entra 身分識別。 在此案例中，共用服務提供者租使用者是您的主要租使用者。
識別所有次要租使用者（如果多租使用者）。 組織管理的其他所有租使用者都是次要租使用者。 如果您已將應用程式遷移至雲端，再建立 企業級 Azure 登陸區域，您可能會有次要租使用者。 您通常會使用次要租使用者來管理外部使用者 （B2B 來賓） 或 （5） 僅限雲端帳戶的 Azure 工作負載（請參閱圖 1）。
使用判定樹。 尋找主要租用戶最簡單的方式是考慮您在 entra 識別碼Microsoft所擁有的身分識別授權。
具有您Microsoft 365 授權的租使用者是您的主要租使用者（請參閱圖 2）。 主要租使用者可能不是組織所建立的第一個租使用者，但應該是具有所有使用者的主要租使用者，且Microsoft 365 個授權。
如果您的組織未使用 Microsoft 365，則任何 Microsoft具有 Enterprise Mobility and Security （EMS） 授權的 Entra 租使用者都是您的主要租使用者。 此租使用者是您新增並驗證組織 功能變數名稱的位置。 租使用者通常會使用混合式身分識別或與人力資源 （HR） 系統整合（請參閱圖 2）。
圖 2. 判斷Microsoft Entra 主要租使用者和次要租使用者的判定樹。
若要將Microsoft Entra標識元建立為零信任平臺，您需要以使用者身分識別填入租使用者身分識別，並取得使用者和裝置型存取原則的授權。 Microsoft 365 授權組合這些零信任功能與 Office 365。 如果您未使用 Microsoft 365，請考慮 使用 Enterprise Mobility + Security E5 來建立雲端式身分識別提供者以進行零信任。 如需詳細資訊，請參閱 選擇您的身分識別授權單位。
設定零信任
在 Microsoft Entra 識別碼中管理身分識別時，您應該針對每個租使用者類型考慮下列建議。 您應該先採用的所有租用戶類型有一般建議。 實作這些一般建議之後，請尋找特定租使用者類型的建議（主要或次要），然後套用這些建議。
若要深入瞭解如何保護零信任Microsoft Entra 租使用者，請參閱 零信任 快速現代化計劃和安全性快速現代化計劃。
所有租用戶
您應該在所有Microsoft Entra 租用戶中實作下列建議。
建立緊急存取帳戶和程式。 建立兩個以上的緊急存取帳戶，以避免鎖定您的 Microsoft Entra 租使用者。 您必須將全域管理員角色指派給這些帳戶。 帳戶應該是僅限雲端的帳戶。 僅限雲端的帳戶會使用 *.onmicrosoft.com 網域。 如需詳細資訊，請參閱 管理緊急存取系統管理員帳戶。
重要
Microsoft建議您使用具有最少許可權的角色。 這有助於改善組織的安全性。 全域管理員是高度特殊許可權的角色，當您無法使用現有角色時，應該受限於緊急案例。
保護 Microsoft Entra 識別子免受內部部署攻擊。 遵循保護特殊許可權存取中所述的最佳做法。 僅將 Microsoft Entra 許可權指派給具有網路釣魚防護認證的僅限雲端用戶帳戶，例如硬體複雜密鑰或憑證式驗證。 請勿將同盟身分識別用於系統管理用途。 如需詳細資訊，請參閱 保護 Microsoft 365 免受內部部署攻擊。
使用 Privileged Identity Management。 使用 Microsoft Entra Privileged Identity Management （PIM） 來管理Microsoft Entra ID 和 Azure 角色的角色指派。 您也應該使用 PIM 來管理特殊許可權安全組的合格群組成員資格。 為合格的系統管理員和外部使用者（B2B 來賓）建立定期 存取權檢閱 。
為所有使用者啟用雲端式驗證。 雲端式驗證方法比同盟驗證更安全。 當與已加入Microsoft的裝置結合時，它們可提供更佳的單一登錄體驗。 同盟驗證會公開Microsoft Entra標識符，以 內部部署的 Active Directory 入侵。
Microsoft Entra 憑證型驗證 （CBA） 使得不需要同盟Microsoft Entra 網域。 Microsoft Entra 驗證支援下列 無密碼驗證方法：
- 複雜金鑰 （FIDO2 安全性金鑰 ）
- 憑證式驗證
- Microsoft驗證器
- Windows Hello 企業版
建立基準條件式存取原則。 條件式存取基準會因組織和需求而異。 為所有Microsoft Entra 租使用者建立一組核心條件式存取原則。 在您的原則集合中使用身分識別、裝置、應用程式和風險條件。 從條件式存取原則中排除 緊急存取帳戶 。
Microsoft Entra ID Protection 可協助組織偵測、調查及補救 身分識別型風險。 若要保護有風險的登入和使用者，請建立具有風險條件的條件式存取原則。 針對有風險的使用者和有風險的登入使用不同的原則。針對每個風險類型增加具有風險層級的套用控件。 若要 平衡用戶生產力與安全性，請避免在風險型原則中使用 封鎖 控制。
注意
使用者可以使用 MFA 自行補救 登入 風險。 若要允許使用者自行補救登入風險，請在登入風險型條件式存取原則中設定 MFA 或驗證強度授與控制權。
用戶可以藉由變更其密碼來自我補救 用戶 風險。 若要允許使用者自我補救用戶風險，請使用 [需要密碼變更授與控制] 設定用戶風險型條件式存取原則。
警告
只有使用 Entra 憑證型驗證、複雜金鑰或 Windows Hello 企業版 等無密碼方法登入的無密碼使用者，如果無法在 entra ID Microsoft 中重設其密碼，則可以透過 [要求密碼變更授與] 控制來封鎖。
使用範例條件式存取原則檢查清單設計貴組織的條件式存取原則（請參閱表 2）。 在部署到生產環境之前，使用 僅限報表模式 來測試條件式存取原則。
表 2：條件式存取原則檢查清單範例。
| 原則名稱 | 使用者 | 應用程式 | 條件 | 授與控件 |
|---|---|---|---|---|
| 所有使用者的 MFA | 所有使用者 | 所有應用程式 | 無 | - 防網路釣魚 MFA |
| 需要受管理的裝置 | 所有使用者 | 所有應用程式 | 無 | - 需要Microsoft Entra 混合式加入或相容裝置 |
| 保護中度風險登入 | 所有使用者 | 所有應用程式 | 中度登入風險 | - 防網路釣魚 MFA - 需要符合規範的裝置 - 登入頻率：1 小時（根據貴組織 的風險承受能力進行調整） |
| 保護高風險登入 | 所有使用者 | 所有應用程式 | 高登入風險 | - 防網路釣魚 MFA - 需要符合規範的裝置 - 登入頻率：每次 |
| 保護高風險使用者 | 所有使用者 | 所有應用程式 | 高用戶風險 | - 防網路釣魚 MFA - 需要符合規範的裝置 - 登入頻率：每次 |
| 安全Microsoft Entra 管理 | Microsoft Entra 角色 | 所有應用程式 | 無 | - 防網路釣魚 MFA - 使用裝置篩選器要求符合規範的特殊許可權存取工作站 （PAW） |
| 保護雲端管理 | 所有使用者 | Azure 管理 Google Cloud Platform Amazon Web Services |
無 | - 防網路釣魚 MFA - 使用裝置篩選器要求符合規範的特殊許可權存取工作站 （PAW） |
表 2 中設定的範例原則適用於無密碼組織，所有使用者只使用受管理裝置的網路釣魚防護 MFA。 特殊許可權使用者使用受 Intune 管理的 Privileged Access Workstations （PAW）。 風險用戶原則會強制執行驗證強度和登入頻率控制，而不是要求對高風險使用者進行密碼變更。 這些控件提供一些保護，但不會在 Microsoft Entra ID Protection 中補救用戶的風險層級。 您的安全性作業小組應該 調查 並 補救 高風險的使用者。
若要深入了解條件式存取部署，請參閱 規劃條件式存取部署。
使用主要租使用者身分識別來存取所有應用程式。 用戶應該能夠在主要租使用者中使用其身分識別來存取應用程式。 您必須在主要租用戶中註冊應用程式。 建立原則以 向主要租用戶註冊應用程式 ，不論應用程式基礎結構裝載位置為何。
對於不支援新式驗證通訊協定的舊版應用程式，請在主要租使用者中使用 Microsoft Entra 應用程式 Proxy 服務。 Microsoft Entra 應用程式 Proxy Microsoft 會將 entra 零信任功能帶到現有的舊版應用程式，而不需要變更程序代碼。
當共用服務提供者或外部代理程式控制您的主要租使用者時，他們應該 委派應用程式註冊許可權。 如果服務提供者未提供此委派，您必須向組織所控制的次要租用戶註冊應用程式。 不過，使用者仍應存取這些應用程式，而不需在次要租使用者中建立新的身分識別。 針對此設定，請為主要租使用者中的使用者，使用 外部身分 識別（B2B 來賓）指派使用者存取權。 如需詳細資訊，請參閱 保護零信任的應用程式。
使用Microsoft Entra標識符來管理其他雲端環境。 Microsoft Entra ID 不只是 Azure 的身分識別平臺，Microsoft 365。 使用Microsoft Entra標識符來取得其他雲端環境的存取權。 這些環境包括熱門的軟體即服務 （SaaS） 產品和雲端平臺，例如 Amazon Web Services （AWS） 和 Google Cloud Platform （GCP）。 如需詳細資訊，請參閱 Microsoft Entra 應用連結庫。
使用安全的雲端運算架構 （SCCA）。 每個防禦組織都應該部署 符合 SCCA 規範 的登陸區域架構。 登陸區域應該位於連結至主要租使用者的 Azure 訂用帳戶中。
在單一租用戶中分割 Azure 資源管理。 您應該針對企業級 Azure 登陸區域中的訂用帳戶使用 Azure 角色的資源和管理隔離。 請考慮 將訂 用帳戶從次要租用戶轉移至主要租使用者。
使用 Microsoft Entra 權限管理。 Microsoft Entra 權限管理 是Microsoft雲端基礎結構權利管理 （CIEM） 解決方案。 您應該使用 Microsoft Entra 權限管理 來查看指派給所有身分識別的許可權。 您也應該使用它來追蹤 組織多雲端環境的許可權爬行 。
使用 Microsoft Entra ID 控管。 使用 Microsoft Entra ID 控管 自動執行用戶和來賓的存取指派生命週期。 針對不再需要雲端環境的用戶，進行存取權檢閱以移除對雲端環境的存取權。
保護工作負載身分識別。 使用 Microsoft Entra 工作負載 ID 功能來管理並套用 Microsoft Entra 識別碼中應用程式身分識別 （服務主體） 的調適型零信任原則。
為您的企業啟用 適用於雲端的 Defender。 針對多重雲端環境使用 適用於雲端的 Defender。 請務必 開啟增強的安全性功能 ，以監視 Azure 資源並補救設定風險。 適用於雲端的 Defender 保護延伸至 Azure 以外，以協助您保護混合式和多重雲端環境。
部署 Sentinel 並連線所有可用的數據源。 匯總 SIEM 中的安全性訊號，例如 Microsoft Sentinel。 藉由設定 數據連接器，部署 Sentinel 並連線所有安全性訊號數據源。
主要租使用者
您應該只在主要租用戶中實作下列建議。
終端使用者在 Entra ID 中只有一個身分識別。將 內部部署的 Active Directory Domain Services 與主要Microsoft Entra 租使用者同步。 同步處理會將組織的使用者、群組和裝置填入Microsoft Entra識別符。 外部 B2B 來賓可能存在於次要租使用者中，但使用者只需要記住所有應用程式和服務的一個用戶名稱。 當您在主要租使用者中使用身分識別進行 Windows 登入和應用程式存取時，用戶體驗和零信任結果最好。
使用主要租使用者加入和管理裝置。 主要Microsoft Entra 租使用者包含組織內的所有用戶和裝置。 Microsoft Entra join （或 Microsoft Entra hybrid join） Windows 裝置到主要租使用者，並使用 Microsoft Intune 進行管理。 使用 Intune 原則部署 適用於端點的 Microsoft Defender 啟用擴充偵測和回應 （XDR） 功能。
委派應用程式註冊許可權。 企業應用程式，包括在任何 Azure 訂用帳戶中執行的應用程式程式碼，請使用主要Microsoft Entra ID 租使用者來取得使用者身分識別。 讓開發人員有資格使用 Privileged Identity Management Microsoft Entra 角色 或 自定義應用程式註冊角色 。 此設定可讓開發人員在次要租使用者中建置應用程式，以向主要租用戶註冊以進行身分識別。
附加需要使用者身分識別的平臺即服務 （PaaS） 服務。 某些 PaaS 服務，例如 Azure 檔案儲存體 和 Azure 虛擬桌面，取決於混合式身分識別設定或授權權利。 您必須將這些服務部署到主要租使用者中的 Azure 訂用帳戶。
次要租使用者
您應該在次要租用戶中實作下列建議。
採購Microsoft Entra 管理所需的授權。 您需要授權才能在次要租用戶中開啟進階安全性功能。 請考慮使用者、工作負載和裝置所需的授權。
使用者身分識別。 您必須Microsoft 租用戶系統管理員和緊急存取帳戶的 Entra ID Premium P2 授權。 如果您使用外部身分識別 （B2B 來賓） 管理模型，您必須將至少一個Microsoft Entra ID Premium P2 授權指派給租使用者中的本機使用者。 此設定可讓您啟用進階功能，例如 條件式存取 和 Identity Protection。 如需詳細資訊，請參閱 多租用戶使用者管理的常見考慮。
工作負載身分識別。 您應該使用 工作負載身分識別進階 來保護工作負載身分識別，並存取主要租使用者中的資源，例如 MS Graph API。
裝置管理。 您可能需要在次要租使用者中使用 Microsoft Intune 來管理裝置。 如果是，您必須購買 Enterprise Mobility and Security （EMS） 授權。
設定跨租使用者存取原則 （XTAP）。 Microsoft Entra 外部 ID （Microsoft Entra B2B 共同作業） 跨租使用者存取設定可讓次要租使用者信任來自主主要租使用者的特定宣告。 將主要Microsoft Entra 租使用者新增為組織，並更新 輸入信任設定 以包含：
- 信任來自 Microsoft Entra 租使用者的多重要素驗證 （MFA）
- 信任相容的裝置
- 信任Microsoft已加入混合式裝置
- 選擇性：使用租用戶自動兌換邀請
使用來自主要租使用者的身分識別來管理次要租使用者。 使用來自主要租使用者的外部使用者（B2B 來賓）來管理次要租使用者和 Azure 資源，以減少系統管理額外負荷和成本。 使用Microsoft Entra Privileged Identity Management 的工作，依工作指派Microsoft Entra 角色Microsoft Entra 角色。 使用 使用者起始的存取 權或 跨租使用者同步處理 ，以減少在次要租使用者中上架外部身分識別的管理額外負荷。
使用 Azure Lighthouse 協助從主要租使用者存取 Sentinel。Azure Lighthouse 可讓您以另一種方式跨租使用者管理 Azure。 Azure Lighthouse 會使用 Azure Resource Manager （ARM） 範本 ，將 Azure 角色指派給外部租使用者中的身分識別。 此方法不會使用 B2B 來賓用戶物件。 當系統管理員登入入口網站來管理 Azure 時，他們會看到所有租使用者的所有資源。 此合併檢視包含具有 Azure Lighthouse 指派許可權的訂用帳戶。 由於沒有 B2B 客體對象，系統管理員不需要切換目錄。 使用 Azure Lighthouse 來協助 管理跨租使用者Microsoft Sentinel。