限制對租用戶的存取

注重安全性的大型組織想要移到 Microsoft 365 之類的雲端服務,但需要確保其使用者只能存取核准的資源。 傳統上,當公司想要管理存取時,會限制網域名稱或 IP 位址。 這種方法在軟體即服務 (或 SaaS) 應用程式裝載於公用雲端的世界中失敗,這些應用程式會在共用功能變數名稱上執行,例如 outlook.office.comlogin.microsoftonline.com。 封鎖這些位址會使使用者完全無法存取網頁版 Outlook,而不只是將他們限制為只能存取已核准的身分和資源。

Microsoft Entra 對這項挑戰所提出的解決方案是一個稱為租用戶限制的功能。 透過租戶限制,組織可以根據應用程式所使用的 Microsoft Entra 租戶來控制 SaaS 雲端應用程式的存取權,以實現 單一登錄。 例如,您可能想要允許存取您組織的 Microsoft 365 應用程式,同時防止存取其他組織的相同應用程式執行個體。

藉由租用戶限制,組織可以指定允許其網路上使用者存取的租用戶清單。 Microsoft Entra ID 之後只會將存取權授予這些已允許的租用戶—其他所有租用戶都會遭到封鎖,即使是您的使用者可能以來賓身分所在的租用戶也是如此。

本文著重於 Microsoft 365 的租用戶限制,但此功能可保護所有將使用者導向 Microsoft Entra ID 以進行單一登入的應用程式。 如果您使用 SaaS 應用程式,且其 Microsoft Entra 租用戶與 Microsoft 365 所使用的租用戶不同,請務必確保所有必要的租用戶都已獲允許。 (例如,在 B2B 共同作業案例中)。 如需 SaaS 雲端應用程式的詳細資訊,請參閱 Active Directory Marketplace

租戶限制功能還支持封鎖所有 Microsoft 消費者應用程式(MSA 應用程式)的使用,例如 OneDrive、Hotmail 和 Xbox.com。 這項功能會對 login.live.com 端點使用個別標頭,並於本文末尾詳細說明。

運作方式

整體解決方案包含下列元件:

  1. Microsoft Entra 識別碼:如果 Restrict-Access-To-Tenants: <permitted tenant list> 標頭存在,Microsoft Entra 僅發行允許租用戶的安全性令牌。

  2. 內部部署 Proxy 伺服器基礎結構:此基礎結構是可進行傳輸層安全性 (TLS) 檢查的 Proxy 裝置。 您必須設定 Proxy 伺服器,使其在傳送至 Microsoft Entra ID 的流量中插入包含允許的租用戶清單的標頭。

  3. 客戶端軟體:若要支援租使用者限制,用戶端軟體必須直接從 Microsoft Entra ID 要求令牌,讓 Proxy 基礎結構可以攔截流量。 以瀏覽器為基礎的 Microsoft 365 應用程式目前支援租用戶限制,而使用新式驗證機制(例如 OAuth 2.0)的 Office 用戶端也支援。

  4. 新式驗證:雲端服務必須使用新式驗證來使用租使用者限制,並封鎖對所有未省略租使用者的存取。 根據預設,您必須將 Microsoft 365 雲端服務設定為使用新式驗證通訊協定。 如需新式驗證Microsoft 365 支援的最新資訊,請參閱 更新的 Office 365 新式驗證

下圖說明高層級的流量流向。 租用戶限制僅要求對傳送至 Microsoft Entra ID 的流量進行 TLS 檢查,而不要求對傳送至 Microsoft 365 雲端服務的流量進行檢查。 此區別很重要,因為傳送到 Microsoft Entra ID 以進行驗證的流量通常比傳送到 SaaS 應用程式 (例如 Exchange Online 和 SharePoint Online) 的流量少很多。

租戶限制流量圖。

設定租用戶限制

開始設定租用戶限制共有兩個步驟。 第一步,確定您的用戶端可以連線到正確的位址。 第二步,設定您的 Proxy 基礎結構。

URL 和 IP 位址

若要使用租用戶限制,您的用戶端必須能夠連線至下列 Microsoft Entra URL 以進行驗證:

  • login.microsoftonline.com
  • login.microsoft.com
  • login.windows.net

此外,若要存取 Office 365,您的用戶端也必須能夠連線到 Office 365 URL 和 IP 位址範圍中定義的完整功能變數名稱(FQDN)、URL 和 IP 位址。

代理伺服器設定與需求

以下是透過 Proxy 基礎結構啟用租用戶限制的必要設定。 本指導方針是通用的,因此如需了解特定的實作步驟,您應該參考您 Proxy 廠商的文件。

必要條件

  • Proxy 必須要能夠執行 TLS 攔截、HTTP 標頭插入,以及使用 FQDN/URL 來篩選目的地。

  • 用戶端必須信任 Proxy 針對 TLS 通訊所出示的憑證鏈結。 例如,如果使用來自內部公開金鑰基礎結構 (PKI) 的憑證,就必須信任內部發行的根憑證授權單位憑證。

  • 需要 Microsoft Entra ID P1 或 P2 授權才能使用租用戶限制。

組態

針對 login.microsoftonline.comlogin.microsoft.comlogin.windows.net 的每個外發請求,插入兩個 HTTP 標頭:Restrict-Access-To-TenantsRestrict-Access-Context

注意事項

請勿在代理伺服器設定中包含 *.login.microsoftonline.com 之下的子網域。 此動作會包含 device.login.microsoftonline.com 並影響用於裝置註冊和裝置型條件式存取案例的用戶端憑證驗證。 將您的代理伺服器設為不對 device.login.microsoftonline.comenterpriseregistration.windows.net 進行 TLS 中斷並檢查以及標頭注入。

這些標頭應該包含下列元素︰

  • 針對 Restrict-Access-To-Tenants,請使用允許的租戶清單<值,這是您想要允許使用者存取的租戶逗號分隔清單。 與租用戶一起註冊的任何網域都可用來在此清單中識別該租用戶,以及目錄識別碼本身。 請勿在逗號分隔列表中包含空白。 以下示範以三種方式描述租用戶的範例,其中允許 Contoso、Fabrikam 和 Microsoft 的名稱/值配對如下:Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

  • 針對 Restrict-Access-Context,請使用單一目錄 ID 的值,宣告哪個租戶正在設置租戶限制。 例如,若要宣告 Contoso 是設定租用戶限制原則的租用戶,名稱/值組會顯示如下:Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff您必須在這裡使用自己的目錄識別碼來取得這些驗證的記錄。 如果您使用的不是您自己的目錄 ID,登入記錄就會出現在別人的租用戶中,且所有個人資訊都會被移除。 如需詳細資訊,請參閱 系統管理員體驗

若要尋找您的目錄識別碼:

  1. 以至少全域讀取者身分登入 Microsoft Entra 系統管理中心
  2. 流覽至 Entra ID>概觀>屬性
  3. 複製 [租用戶識別碼] 值。

若要驗證目錄識別碼或網域名稱是否指向同一個租用戶,請在此 URL 中以該識別碼或網域取代 <tenant>:https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration。 如果網域和 ID 的結果相同,則表示它們指的是同一個租用戶。

若要防止使用者在 HTTP 標頭中插入未核准租使用者的內容,如果傳入要求中已有 Restrict-Access-To-Tenants 標頭,代理就必須取代這個標頭。

必須強制用戶端對 login.microsoftonline.comlogin.microsoft.comlogin.windows.net 的所有要求使用 Proxy。 例如,如果使用 PAC 檔案來引導用戶端使用 Proxy 伺服器,終端使用者不應能夠編輯或停用 PAC 檔案。

使用者體驗

此節描述使用者和系統管理員的體驗。

終端使用者體驗

範例使用者位於 Contoso 網路上,但正在嘗試存取 Fabrikam 的共用 SaaS 應用程式執行個體 (例如 Outlook Online)。 如果 Fabrikam 是 Contoso 執行個體中未獲允許的租用戶,則使用者會看到存取遭拒訊息。 拒絕訊息指出您正嘗試存取屬於 IT 部門未核准之組織的資源。

2021年4月起租使用者限制錯誤訊息的螢幕快照。

管理員使用體驗

雖然租用戶限制的設定是在公司 Proxy 基礎結構上完成設定,但系統管理員可以直接在 Microsoft Entra 系統管理中心中存取租用戶限制報表。 若要檢視報表:

  1. 以至少全域讀取者身分登入 Microsoft Entra 系統管理中心
  2. 流覽至 Entra ID>概觀>租戶限制

如果將租用戶指定為 Restricted-Access-Context 租用戶,其管理員便可以使用此報表來查看因租用戶限制原則而遭封鎖的登入,包括所使用的身分識別及目標目錄識別碼。 如果設定限制的租用戶是該次登入的使用者租用戶或資源租用戶,則該登入會包含在內。

當屬於 Restricted-Access-Context 租用戶以外其他租用戶的使用者登入時,此報告可能僅包含有限資訊,例如目標目錄識別碼。 在此案例中,會遮罩使用者可識別的資訊,例如名稱和使用者主體名稱,以保護其他租用戶中的使用者資料 (例如,"{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 適當地取代使用者名稱和物件識別碼)。

與 Microsoft Entra 系統管理中心中的其他報告相同,您可以使用篩選來指定報告的範圍。 您可以根據特定時間間隔、使用者、應用程式、用戶端或狀態進行篩選。 如果您選取 [資料行] 按鈕,則可以選擇使用下列欄位的任何組合來顯示資料:

  • 使用者 - 此欄位可以移除個人資料,其中其值設定為 00000000-0000-0000-0000-000000000000
  • 應用
  • 地位
  • 日期
  • 日期 (UTC) - 其中 UTC 為國際標準時間
  • IP位址
  • 客戶
  • 用戶名稱 - 此欄位可以移除個人資料,其中其值設定為 {PII Removed}@domain.com
  • 位置
  • 目標租用戶標識碼

Microsoft 365 支援

Microsoft 365 應用程式必須符合兩個準則,才能完全支援租用戶限制:

  1. 所使用的用戶端支援新式驗證。
  2. 啟用新式驗證作為雲端服務的預設驗證通訊協定。

如需 Office 用戶端目前支援新式驗證的最新資訊,請參閱 更新的 Office 365 新式驗證。 該頁面也包含在特定 Exchange Online 和「商務用 Skype Online」租用戶上啟用新式驗證的指示連結。 根據預設,SharePoint Online 已啟用新式驗證。 Teams 僅支援現代驗證,且不支援舊版驗證,因此這項略過疑慮不適用於 Teams。

Microsoft 365 瀏覽器型應用程式 (例如,Office 入口網站、Yammer、SharePoint 網站及 Outlook 網頁版) 目前支援租用戶限制。 豐富型用戶端 (Outlook、商務用 Skype、Word、Excel、PowerPoint 等等) 只有在使用新式驗證時才可以強制執行租用戶限制。

支援新式驗證的 Outlook 和商務用 Skype 用戶端仍能針對未啟用新式驗證的租用戶使用傳統通訊協定,有效略過租用戶限制。 如果租用戶在驗證期間連絡 login.microsoftonline.comlogin.microsoft.comlogin.windows.net,則租用戶限制可能會封鎖使用舊版通訊協定的應用程式。

針對 Windows 上的 Outlook,客戶可以選擇實作可防止使用者將非已核准郵件帳戶新增至其設定檔的限制。 例如,請參閱 防止新增非預設 Exchange 帳戶 組策略設定。

Azure RMS 和 Office 郵件加密不相容

Azure Rights Management Service (Azure RMS)Office 郵件加密功能與租使用者限制不相容。 這些功能仰賴讓您的使用者登入其他租用戶,以取得加密文件的解密金鑰。 由於租用戶限制封鎖對其他租用戶的存取,因此無法存取自未經授權租用戶傳送至使用者的加密電子郵件和文件。

測試

如果您想要先試用租用戶限制,然後才為整個組織實作此功能,則您有兩個選項:運用使用 Fiddler 這類工具的主機型方法,或是分段推出 Proxy 設定。

適用於主機型方法的 Fiddler

Fiddler 是一個免費的 Web 偵錯 Proxy,可用來擷取和修改 HTTP/HTTPS 流量,包括插入 HTTP 標頭。 若要設定 Fiddler 以測試租用戶限制,請執行下列步驟:

  1. 下載並安裝 Fiddler

  2. 根據 Fiddler 的說明檔,將 Fiddler 設定為解密 HTTPS 流量。

  3. 設定 Fiddler 以使用自定義規則插入 Restrict-Access-To-TenantsRestrict-Access-Context 標頭:

    1. 在 Fiddler Web 調試程式工具中,選取 [ 規則 ] 功能表,然後選取 [ 自定義規則... ] 以開啟 CustomRules 檔案。

    2. OnBeforeRequest 函式中新增下列幾行。 以已向您的租用戶註冊的網域 (例如 contoso.onmicrosoft.com) 取代 <租用戶識別碼清單>。 使用您租用戶的 Microsoft Entra GUID 識別碼來取代 <directory ID>。 您必須包含正確的 GUID 識別碼,才能讓記錄出現在您的租戶中。

     // Allows access to the listed tenants.
       if (
           oSession.HostnameIs("login.microsoftonline.com") ||
           oSession.HostnameIs("login.microsoft.com") ||
           oSession.HostnameIs("login.windows.net")
       )
       {
           oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
           oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
       }
    
     // Blocks access to consumer apps
       if (
           oSession.HostnameIs("login.live.com")
       )
       {
           oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
       }
    

    如果您需要允許多個租用戶,請使用逗號來分隔租用戶名稱。 例如:

    oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

  4. 儲存並關閉 CustomRules 檔案。

設定 Fiddler 之後,您可以移至 [File] \(檔案) 功能表並選取 [Capture Traffic] \(擷取流量),來擷取流量。

分階段推出代理伺服器設定

視您 Proxy 基礎結構的功能而定,您可能可以向使用者分段推出設定。 請參閱以下高層級選項以供考量:

  1. 使用 PAC 檔案將測試使用者指向測試 Proxy 基礎結構,同時又讓一般使用者繼續使用生產環境 Proxy 基礎結構。
  2. 有些 Proxy 伺服器可以使用群組來支援不同的組態。

如需具體的詳細資料,請參閱您的 Proxy 伺服器文件。

封鎖消費者應用程式

Microsoft 的應用程式若同時支援個人帳戶和組織帳戶(例如 OneDrive),有時可能會裝載於同一個 URL。 這表示必須針對工作目的存取該 URL 的使用者也可以存取該 URL 以供個人使用。 根據您的作業指導方針,可能無法使用此選項。

某些組織會藉由封鎖 login.live.com 來封鎖個人帳戶進行驗證,以嘗試修正此問題。 此修正程式有數個缺點:

  1. 封鎖 login.live.com 會禁止在 B2B 來賓情境中使用個人帳戶,這可能會妨礙來賓存取和共同作業。
  2. Autopilot 需要使用 login.live.com 才能部署。 當封鎖 login.live.com 時,Intune 和 Autopilot 案例可能會失敗。
  3. 依賴 login.live.com 服務的裝置標識碼的組織遙測和 Windows 更新停止運作

消費者應用程式的設定

Restrict-Access-To-Tenants 標頭作為允許清單時,Microsoft 帳戶 (MSA) 區塊會以拒絕訊號的形式運作,藉以告知 Microsoft 帳戶平台不允許使用者登入取用者應用程式。 若要傳送此訊號,會將sec-Restrict-Tenant-Access-Policy 標頭插入經由訪問 login.live.com 的流量中,此處所使用的是本文 代理設定和要求一節中所述的相同公司代理伺服器或防火牆。 標頭的值必須是 restrict-msa。 當標頭存在且取用者應用程式嘗試直接登入使用者時,該登入會遭到封鎖。

目前,消費者應用程式的身份驗證不會出現在 系統管理日志中,因為 login.live.com 是獨立於 Microsoft Entra ID 的伺服器。

標頭會封鎖與不會封鎖的內容

restrict-msa 原則會封鎖使用消費者應用程式,但會放行其他幾種類型的流量和驗證:

  1. 裝置的無使用者 (User-less) 流量。 此選項包含 Autopilot、Windows Update 和組織遙測的流量。
  2. 消費者帳戶的 B2B 驗證。 受邀與租戶共同作業的Microsoft帳戶使用者需要通過 login.live.com 驗證以便存取資源租戶。
    1. 這項存取是使用 Restrict-Access-To-Tenants 標頭來控制,以允許或拒絕對該資源租用戶的存取。
  3. 「傳遞驗證」,許多 Azure 應用程式和 Office.com 都會使用這種驗證方式;在消費者情境中,應用程式會使用 Microsoft Entra ID 讓消費者使用者登入。
    1. 此存取權限也會透過 Restrict-Access-To-Tenants 標頭控制,以允許或拒絕對特殊「直通」租戶 (f8cdef31-a31e-4b4a-93e4-5f571e91255a) 的存取。 如果此租用戶未出現在您允許網域的 Restrict-Access-To-Tenants 清單中,Microsoft Entra ID 會封鎖取用者帳戶登入這些應用程式。

不支援 TLS 中斷和檢查的平台

租用戶限制取決於 HTTPS 標頭中允許租用戶清單的插入。 此相依性需要傳輸層安全性檢查 (TLSI) 來中斷和檢查流量。 對於客戶端無法中斷和檢查流量以新增標頭的環境,租用戶限制無法運作。

以 Android 7.0 和更新版本為例。 Android 變更其處理受信任憑證授權單位 (CA) 的方式,為安全的應用程式流量提供更安全的預設值。 如需詳細資訊,請參閱 Android Nougat 中受信任證書頒發機構單位的變更

遵循 Google 的建議,Microsoft 用戶端應用程式預設會忽略使用者憑證。 此原則可讓這類應用程式無法使用租用戶限制,因為網路 Proxy 所使用的憑證會安裝在使用者憑證存放區中,用戶端應用程式不信任這些憑證。

對於無法中斷和檢查流量以將租用戶限制參數新增至標頭的環境,Microsoft Entra ID 的其他功能可以提供保護。 下列清單提供有關這類 Microsoft Entra 功能的詳細資訊。

不過,某些特定案例只能使用租用戶限制來涵蓋。

下一步