所有隔離架構的最佳做法
以下是所有隔離設定的設計考量。 在此整個內容中，有許多連結。 我們會連結至內容，而不是在這裡複製該內容，因此您一律可以存取最新的資訊。
如需如何設定 Microsoft Entra 租用戶 (隔離或未隔離) 的一般指引，請參閱 Microsoft Entra 功能部署指南。
注意
針對所有隔離的租用戶，我們建議您使用清楚且區分的商標，以協助避免發生人為錯誤，在錯誤的租用戶中工作。
隔離安全性準則
設計隔離的環境時，請務必考慮下列準則：
僅使用新式驗證 - 部署在隔離環境中的應用程式必須使用宣告型新式驗證 (例如，SAML、* 驗證、OAuth2 和 OpenID Connect)，才能使用同盟、Microsoft Entra B2B 共同作業、委派和同意架構等功能。 如此一來，對舊版驗證方法具有相依性的舊版應用程式 (例如 NT LAN Manager (NTLM)) 將不會在隔離的環境中繼續執行。
強制執行增強式驗證 - 存取隔離的環境服務和基礎結構時，一律必須使用增強式驗證。 盡可能應該使用無密碼驗證，例如 Windows for Business Hello 或 FIDO2 安全性金鑰。
部署安全工作站 - 安全工作站提供的機制可確保平台和平台代表的身分識別得到適當的證明並受到保護，以防範惡意探索。 其他兩種要考慮的方法為：
搭配 Microsoft Graph API 使用 Windows 365 雲端電腦 (雲端電腦)。
使用條件式存取並篩選裝置作為條件。
消除舊版信任機制 - 隔離的目錄和服務不應該透過 Active Directory 信任之類的舊版機制與其他環境建立信任關係。 環境之間的所有信任都應該使用同盟和宣告型身分識別等新式建構來建立。
隔離服務 - 藉由保護基礎身分識別和服務基礎結構免於暴露，將表面攻擊區域降到最低。 僅透過服務的新式驗證啟用存取，以及保護基礎結構的遠端存取 (也受到新式驗證保護)。
目錄層級角色指派- 避免或減少目錄層級角色指派 (目錄範圍的使用者管理員，而不是 AU 範圍的使用者管理員) 的數目，或具有控制平面動作的服務特定目錄角色 (有權管理安全性群組成員資格的知識管理員) 數目。
除了 Microsoft Entra 一般作業指南中的指引之外，我們也建議針對隔離環境的下列考量。
人類身分識別佈建
具特殊權限的帳戶
針對操作環境的系統管理員和 IT 小組，在隔離的環境中佈建帳戶。 這讓您新增更強大的安全性原則，例如安全工作站的裝置型存取控制。 如前幾節所討論，非生產環境可能會利用 Microsoft Entra B2B 共同作業，將特殊權限帳戶上線到非生產租用戶，此租用戶會使用針對其生產環境中特殊權限存取所設計的相同態勢和安全性控制。
僅限雲端帳戶是在 Microsoft Entra 租用戶中佈建人類身分識別的最簡單方式，而且很適合用於綠地環境。 不過，若有對應至隔離環境的現有內部部署基礎結構 (例如，生產前或管理 Active Directory 樹系)，您可以考慮從該處同步身分識別。 如果此處內部部署基礎結構用於需要伺服器存取來管理解決方案資料平面的 IaaS 解決方案，則更是如此。 如需此案例的詳細資訊，請參閱保護 Microsoft 365 免遭內部部署攻擊。 如果有特定的法規合規性需求，例如僅限智慧卡驗證，也可能需要從隔離的內部部署環境進行同步。
注意
沒有技術控制可對 Microsoft Entra B2B 帳戶執行身分識別證明。 使用 Microsoft Entra B2B 佈建的外部身分識別會以單一因素啟動。 若要降低風險，就是讓組織有一個流程，在發出 B2B 邀請之前證明必要的身分識別，以及定期對外部身分識別進行存取權檢閱來管理生命週期。 請考慮啟用條件式存取原則來控制 MFA 註冊。
外包高風險角色
若要減輕內部威脅，您可以使用 Azure B2B 共同作業或透過 CSP 合作夥伴或 Lighthouse 委派存取權，將全域管理員的存取權和特殊權限角色管理員角色外包給受控服務提供者。 透過 Azure Privileged Identity Management (PIM) 中的核准流程，內部員工可以控制此存取權。 這種方法可以大幅減少內部威脅。 針對有疑慮的客戶，您可以使用此方法來符合其合規性需求。
非人類身分識別佈建
緊急存取帳戶
Microsoft 建議組織擁有兩個僅限雲端，且永久指派為全域系統管理員角色的緊急存取帳戶。 這些帳戶具有高度特殊權限，不會指派給特定個人。 這些帳戶僅限於無法使用一般帳戶或所有其他系統管理員均意外鎖在系統外的緊急狀況或「緊急安全窗口」案例。這些帳戶應遵循緊急存取帳戶建議來建立。
Azure 受控識別
針對需要服務識別的 Azure 資源使用 Azure 受控識別。 在設計 Azure 解決方案時，請檢查支援受控識別的服務清單。
如果不支援受控識別或其不可行，請考慮佈建服務主體物件。
混合式服務帳戶
某些混合式解決方案可能同時需要存取內部部署和雲端資源。 使用案例的範例是使用 AD DS 中的服務帳戶存取內部部署的已加入網域伺服器應用程式，而且在 Microsoft Entra 識別碼中也有帳戶，因為其需要 Microsoft Online Services 的存取權限。
內部部署服務帳戶通常無法以互動方式登入，這表示在雲端案例中，其無法滿足強式認證需求，例如多重要素驗證。 在此案例中，請不要使用已從內部部署同步的服務帳戶，而是改用受控識別\服務主體。 若為服務主體 (SP)，請使用憑證作為認證，或使用條件式存取來保護 SP。
如果由於技術限制而無法達成此目的，而且必須同時針對內部部署和雲端使用相同的帳戶，請實作補償控制 (例如條件式存取)，以鎖定來自特定網路位置的混合式帳戶。
資源指派
企業解決方案可能是由多個 Azure 資源所組成，且其存取權應以指派的邏輯單位 (資源群組) 形式管理和治理。 在該案例中，您可以建立 Microsoft Entra 安全性群組，並跨所有解決方案資源將這些安全性群組與適當的權限和角色指派建立關聯，以便從這些群組新增或移除使用者會導致允許或拒絕存取整個解決方案。
建議您在提供存取權限之前，先使用群組型授權和安全性群組，其作用於以擁有授權基座指派的使用者作為必要條件的 Microsoft 服務 (例如 Dynamics 365、Power BI)。
與 Microsoft Entra 存取權檢閱和 Microsoft Entra 權利管理結合時，可以從雲端原生治理 Microsoft Entra 雲端原生群組。
Microsoft Entra ID 也支援直接將使用者指派給協力廠商 SaaS 服務 (例如，Salesforce、Service Now) 和內部部署應用程式，以進行單一登入和身分識別佈建。 與 Microsoft Entra 存取權檢閱和 Microsoft Entra 權利管理結合時，可以從雲端原生治理資源的直接分配。 直接指派可能很適合終端使用者面向的指派。
某些案例可能需要透過內部部署 Active Directory 安全性群組授與內部部署資源的存取權。 針對這些案例，在設計流程 SLA 時，請考慮將週期同步至 Microsoft Entra ID。
驗證管理
本節描述如何根據貴組織的安全性態勢，針對認證管理和存取原則執行的檢查和採取的動作。
認證管理
強式認證
隔離環境中的所有人類身分識別 (透過 B2B 共同作業佈建的本機帳戶和外部身分識別) 都必須使用強式驗證認證 (例如多重要素驗證或 FIDO 金鑰) 進行佈建。 其基礎內部部署基礎結構搭配強式驗證 (例如智慧卡驗證) 的環境可以在雲端中繼續使用智慧卡驗證。
無密碼認證
無密碼解決方案是確保最方便且安全驗證方法的最佳解決方案。 對於具有特殊權限角色的人類身分識別，建議使用 FIDO 安全性金鑰和 Windows Hello 企業版等無密碼認證。
密碼保護
如果環境是從內部部署 Active Directory 樹系同步，您應該部署 Microsoft Entra ID 密碼保護，以消除貴組織中的弱式密碼。 Microsoft Entra 智慧鎖定也應該用於混合式或僅限雲端環境中，以鎖定嘗試猜測使用者密碼或使用暴力密碼破解方法來登入的不良執行者。
自助密碼管理
在技術支援中心的來電量和成本中，以需要變更或重設密碼的使用者佔最大宗。 除了成本之外，將變更密碼視為降低使用者風險的工具，是改善組織安全性態勢的基本步驟。 至少，針對具有密碼的人類和測試帳戶部署自助式密碼管理，以轉移技術支援中心通話。
外部身分識別密碼
藉由使用 Microsoft Entra B2B 共同作業，邀請和兌換流程可讓合作夥伴、開發人員和轉包商等外部使用者使用自己的認證來存取貴公司的資源。 這可減輕將更多密碼引入隔離租用戶中的需求。
注意
某些應用程式、基礎結構或工作流程可能需要本機認證。 根據個案評估此情況。
服務主體認證
針對需要服務主體的案例，請使用服務主體的憑證認證或工作負載身分識別的條件式存取。 如有必要，請使用用戶端密碼作為組織政策的例外狀況。
在這兩種情況下，Azure Key Vault 都可以與 Azure 受控識別搭配使用，讓執行階段環境 (例如 Azure 函式) 可以從金鑰保存庫取得認證。
請檢查此範例，以使用自我簽署憑證建立服務主體，透過憑證認證驗證服務主體。
存取原則
下列章節的內容是 Azure 解決方案的建議。 如需個別環境條件式存取原則的一般指引，請參閱 條件式存取最佳做法、Microsoft Entra 作業指南和零信任的條件式存取：
定義 Windows Azure 服務管理 API 雲端應用程式的條件式存取原則，以在存取 Azure Resource Manager 時強制執行身分識別安全性態勢。 這應該包括 MFA 上的控制項和裝置型控制項，以僅透過安全工作站啟用存取 (如需詳細資訊，請參閱身分識別治理下的特殊權限角色一節)。 此外，使用條件式存取來篩選裝置。
所有上線至隔離環境的應用程式都必須套用明確的條件式存取原則，作為上線流程的一部分。
定義安全性資訊註冊的條件式存取原則，此註冊會反映信任流程內部部署的安全根 (例如，對於實體位置中可由 IP 位址識別的工作站，員工必須親自造訪該工作站進行驗證)。
請考慮使用條件式存取來限制工作負載身分識別。 建立一個原則，根據位置或其他相關情況來限制或更妥善地控制存取。
驗證挑戰
使用 Microsoft Entra B2B 佈建的外部身分識別可能需要在資源租用戶中重新佈建多重要素驗證認證。 如果尚未使用資源租用戶設定跨租用戶存取原則，則這可能是必要的。 這表示，上線至系統是以單一因素啟動。 使用這種方法時，若要降低風險，讓組織具有一個流程，在發出 B2B 邀請之前，先證明使用者和認證風險設定檔。 此外，定義對註冊流程的條件式存取，如先前所述。
使用外部身分識別跨租用戶存取設定，來管理組織透過 B2B 共同作業和 B2B 直接連線與其他 Microsoft Entra 組織及其他 Microsoft Azure 雲端共同作業的方式。
針對特定裝置設定和控制，您可以在條件式存取原則中使用裝置篩選條件，來鎖定或排除特定裝置。 這可讓您限制從指定的安全系統管理工作站 (SAW) 存取 Azure 管理工具。 您可以採取的其他方法包括使用 Azure 虛擬桌面、Azure Bastion 或雲端電腦。
Azure EA 入口網站或 MCA 計費帳戶等計費管理應用程式不會以條件式存取目標的雲端應用程式表示。 作為補償控制，請使用「所有應用程式」條件定義個別的系統管理帳戶，並將條件式存取原則設為那些帳戶的目標。
身分識別治理
特殊權限角色
以下是在進行隔離時跨所有租用戶設定考慮的一些身分識別治理原則。
沒有常設存取權 - 沒有人類身分識別應該具有常設存取權，才能在隔離的環境中執行特殊權限作業。 Azure 角色型存取控制 (RBAC) 與 Microsoft Entra Privileged Identity Management (PIM) 整合。 PIM 提供由安全性閘道決定的 Just-In-Time 啟用，例如多重要素驗證、核准工作流程，以及有限的持續時間。
管理員數目 - 組織應該定義保留特殊權限角色以減輕商務持續性風險的人數下限和上限。 特殊權限角色若太少，可能沒有足夠的時區涵蓋範圍。 遵循最低權限原則，藉由具有盡可能少的管理員來減輕安全性風險。
限制特殊權限存取 - 針對高權限或敏感性權限建立僅限雲端和可角色指派群組。 這可為指派的使用者和群組物件提供保護。
最低殊許權限存取 - 身分識別應該只獲授與在組織中根據其角色執行特殊權限作業所需的權限。
來自安全工作站的特殊權限存取 - 所有特殊權限存取都應該從安全鎖定的裝置中進行。 將這些敏感性工作和帳戶與日常使用的工作站和裝置分隔，可保護特殊權限帳戶免於網路釣魚攻擊、應用程式和作業系統弱點、各種模擬攻擊以及認證盜用攻擊，例如按鍵輸入記錄、傳遞雜湊和傳遞票證等攻擊。
您可以用於使用安全裝置作為特殊權限存取案例一部分的某些方法，包括使用條件式存取原則來鎖定或排除特定裝置、使用 Azure 虛擬桌面、Azure Bastion 或雲端電腦，或建立 Azure 受控工作站或特殊權限存取工作站。
特殊權限角色流程護欄 - 組織必須定義流程和技術護欄，以確保在符合法規需求時，可以視需要執行特殊權限作業。 護欄準則的範例包括：
具有特殊權限角色的人員資格 (例如，全職員工/廠商、許可等級、公民)
明確的角色不相容性 (也稱為職責區分)。 範例包括具有 Microsoft Entra 目錄角色的小組不應負責管理 Azure Resource Manager 特殊權限角色等等。
哪些角色偏好直接使用者還是群組指派。
監視 Microsoft Entra PIM 外的 IAM 指派不會透過 Azure 原則自動進行。 為了降低風險，不要將訂用帳戶擁有者或使用者存取管理員角色授與工程小組。 請改為建立指派給最低特殊權限角色 (例如參與者) 的群組，並將這些群組的管理委派給工程小組。
資源存取
證明 - 應該定期檢閱保留特殊權限角色的身分識別，以保持最新且合格的成員資格。 Microsoft Entra 存取權檢閱與 Azure RBAC 角色、群組成員資格和 Microsoft Entra B2B 外部身分識別整合。
生命週期 - 特殊權限作業可能需要存取多個資源，例如企業營運應用程式、SaaS 應用程式，以及 Azure 資源群組和訂用帳戶。 Microsoft Entra 權利管理允許定義存取套件，代表一組以單位形式指派給使用者的資源、建立有效期間、核准工作流程等等。
租用戶與訂用帳戶生命週期管理
租用戶生命週期
建議您實作一個流程來要求新的公司 Microsoft Entra 租用戶。 此流程應考慮：
建立其的業務理由。 建立新的 Microsoft Entra 租用戶會大幅增加複雜度，因此確定是否需要新的租用戶是關鍵。
應在其中建立租用戶的 Azure 雲端 (例如商業、政府等等)。
這是生產環境還是非生產環境
目錄資料落地需求
誰將負責管理
常見安全性需求的訓練和了解。
一旦核准，就會建立 Microsoft Entra 租用戶、使用必要的基準控制項進行設定，以及在計費方案中上線、監視等等。
必須實作計費方案中 Microsoft Entra 租用戶的定期檢閱，以偵測並探索在受控流程外部的租用戶建立情況。 如需進一步詳細資料，請參閱本文件的「庫存和可見性」一節。
您可以使用 Azure 原則來控制 Azure AD B2C 租用戶建立。 當 Azure 訂用帳戶與 B2C 租用戶相關聯時，原則便會執行 (計費的必要條件)。 客戶可以將 Azure AD B2C 租用戶的建立限制為特定的管理群組。
沒有任何技術控制可使租用戶的建立從屬於組織。 不過，活動會記錄在稽核記錄中。 上線至計費方案是閘道的補償控制。 這必須改用監視和警示來補充。
訂用帳戶生命週期
以下是設計受控訂用帳戶生命週期流程的一些考量：
定義一種分類法，將需要 Azure 資源的應用程式和解決方案分類。 要求訂用帳戶時，所有要求訂用帳戶的小組都應該提供其「產品識別碼」。 此資訊分類法將決定：
佈建訂用帳戶的 Microsoft Entra 租用戶
用於建立訂用帳戶的 Azure EA 帳戶
命名慣例
管理群組指派
其他層面，例如標記、交叉付費、產品檢視使用方式等等。
不允許透過入口網站或其他方式建立特定訂用帳戶。 相反地，請考慮使用 Azure Resource Manager以程式設計方式管理訂用帳戶，並以程式設計方式提取使用量和計費報告。 這有助於限制將訂用帳戶佈建至授權的使用者，並強制執行您的原則和分類目標。 下列 AZOps 主體 指引可以用來協助建立實用的解決方案。
佈建訂用帳戶時，請建立 Microsoft Entra 雲端群組，以保留應用程式小組所需的標準 Azure Resource Manager 角色，例如參與者、讀者和核准的自訂角色。 這可讓您大規模管理具有受控特殊權限存取的 Azure RBAC 角色指派。
將群組設定為符合 Azure RBAC 角色資格，方法為使用 Microsoft Entra PIM 搭配對應的控制項，例如啟用原則、存取權檢閱、核准者等等。
然後將群組的管理委派 給解決方案擁有者。
作為護欄，請不要將產品擁有者指派給使用者存取管理員或擁有者角色，以避免在 Microsoft Entra PIM 外意外直接指派角色，或可能會將訂用帳戶完全變更為不同的租用戶。
針對選擇透過 Azure Lighthouse 在非生產租用戶中啟用跨租用戶訂用帳戶管理的客戶，請確定來自生產特殊權限帳戶的相同存取原則 (例如，僅來自安全工作站的特殊權限存取)，在驗證以管理訂用帳戶時才會強制執行。
鑑於租用戶與 Azure 訂用帳戶的親和性，訂用帳戶佈建應該注意相同人類執行者 (員工、合作夥伴、廠商等等) 跨多個租用戶的多個身分識別，並據以指派存取權。
EA 和 MCA 角色
Azure Enterprise (Azure EA) 合約入口網站不會與 Azure RBAC 或條件式存取整合。 若要降低此風險，請使用可透過原則和其他監視設為目標的專用系統管理帳戶。
Azure EA Enterprise 入口網站不提供稽核記錄。 若要降低此風險，請考慮根據上述考量來佈建訂用帳戶的自動化治理流程，以及使用專用 EA 帳戶並稽核驗證記錄。
Microsoft 客戶合約 (MCA) 角色不會以原生方式與 PIM 整合。 若要降低此風險，請使用專用 MCA 帳戶，並監視這些帳戶的使用方式。
Azure AD B2C 租用戶
在 Azure AD B2C 租用戶中，內建角色不支援 PIM。 為了提高安全性，我們建議使用 Microsoft Entra B2B 共同作業，從您的 Azure 租用戶將管理客戶身分識別存取管理 (CIAM) 的工程小組上線，將其指派給 Azure AD B2C 特殊權限角色，並套用條件式存取原則至這些專用系統管理帳戶。
Azure AD B2C 租用戶特殊權限角色不會與 Microsoft Entra 存取權檢閱整合。 若要降低風險，請在組織的 Microsoft Entra 租用戶中建立專用帳戶、將這些帳戶新增至群組，並在此群組上執行定期存取權檢閱。
遵循上述 Microsoft Entra ID 的緊急存取指導方針，除了上述外部管理員之外，請考慮建立對等的緊急存取帳戶。
我們建議 B2C 租用戶基礎 Microsoft Entra 訂用帳戶的邏輯擁有權與 CIAM 工程小組一致，其方式與其餘 Azure 訂用帳戶用於 B2C 解決方案的方式相同。
Operations
以下是 Microsoft Entra 的其他作業考量，專用於多個隔離的環境。 如需操作個別環境的詳細指引，請參閱 Microsoft Entra 雲端採用架構、Microsoft 雲端安全性基準測試和 Azure AD 作業指南。
跨環境角色和責任
全企業 SecOps 架構 - 組織中來自所有環境的作業和安全性小組成員應共同定義下列各項：
定義何時需要建立、合併或取代環境的準則。
在每個環境上定義管理群組階層的準則。
計費方案 (EA 入口網站/MCA) 安全性態勢、作業態勢和委派方法。
租用戶建立流程。
企業應用程式分類法。
Azure 訂用帳戶佈建流程。
跨小組和環境隔離和管理自主性界限和風險評估。
常見的基準設定和安全性控制 (技術和補償)，以及要用於所有環境的操作基準。
跨越多個環境的常見標準操作程序和工具 (例如監視、佈建)。
已同意跨多個環境委派角色。
跨環境的職責區分。
特殊權限工作站的常見供應鏈管理。
命名慣例。
跨環境相互關聯機制。
租用戶建立 - 特定小組應該遵循全企業 SecOps 架構所定義的標準化程序，自行建立租用戶。 這包括：
基礎授權佈建 (例如，Microsoft 365)。
上線至公司計費方案 (例如，Azure EA 或 MCA)。
建立 Azure 管理群組階層。
設定各種周邊的管理原則，包括身分識別、資料保護、Azure 等等。
根據同意的網路安全性架構部署安全性堆疊，包括診斷設定、SIEM 上線、CASB 上線、PIM 上線等等。
根據同意的委派來設定 Microsoft Entra 角色。
設定和散發初始特殊權限工作站。
佈建緊急存取帳戶。
設定身分識別佈建堆疊。
跨環境工具架構 - 某些工具 (例如身分識別佈建和原始檔控制管線) 可能需要跨多個環境運作。 這些工具應被視為基礎結構的重要工具，而且必須按此方式進行建構、設計、實作和管理。 因此，每當需要定義跨環境工具時，應該涉及來自所有環境的架構師。
清查和可見性
Azure 訂用帳戶探索 - 針對每個探索到的租用戶，Microsoft Entra 全域管理員可以提高存取權，以取得環境中所有訂用帳戶的可見度。 此提高權限會在根管理群組中為訂用帳戶指派使用者存取管理員內建角色。
注意
此動作具有高度特殊權限，而且如果該資料尚未適當地隔離，可能讓管理員可以存取保留極機密資訊的訂用帳戶。
啟用讀取存取以探索資源 - 管理群組可跨多個訂用帳戶大規模啟用 RBAC 指派。 客戶可以將讀者角色授與集中式 IT 小組，方法是在根管理群組中設定角色指派，這會傳播至環境中的所有訂用帳戶。
資源探索 - 在取得環境中的資源讀取存取之後，Azure Resource Graph 可以用來查詢環境中的資源。
記錄和監視
中央安全性記錄管理 - 以集中方式擷取每個環境中的記錄，跨環境遵循一致的最佳做法 (例如，診斷設定、記錄保留、SIEM 擷取等等)。 Azure 監視器可以用來擷取不同來源中的記錄，例如端點裝置、網路、作業系統的安全性記錄等等。
如需使用自動化或手動流程和工具來監視記錄，作為安全性作業一部分的詳細資訊，請參閱 Microsoft Entra 安全性作業指南。
某些環境可能會有法規需求，限制哪些資料 (如果有的話) 可以離開指定的環境。 如果無法跨環境集中監視，小組應該具有作業程序，基於稽核和鑑識目的將跨環境的身分識別活動相互關聯，例如跨環境橫向動作嘗試。 建議屬於相同人員的物件唯一識別碼人類身分識別是可探索的，可能是身分識別佈建系統的一部分。
記錄策略必須包含組織中所用每個租用戶的下列 Microsoft Entra 記錄：
登入活動
稽核記錄
風險事件
Microsoft Entra ID 會為登入活動記錄和稽核記錄提供 Azure 監視器整合。 您可以透過 Microsoft Graph API 來擷取風險事件。
下圖顯示需要納入作為監視策略一部分的不同資料來源：
Azure AD B2C 租用戶可以與 Azure 監視器整合。 建議您使用上述針對 Microsoft Entra ID 所討論的相同準則來監視 Azure AD B2C。
已使用 Azure Lighthouse 啟用跨租用戶管理的訂用帳戶，可以在 Azure 監視器收集記錄時啟用跨租用戶監視。 對應的 Log Analytics 工作區可以位於資源租用戶中，而且您可以使用 Azure 監視器活頁簿，在管理租用戶時集中分析。 若要深入了解，請參閱大規模監視委派的資源 - Azure Lighthouse。
混合式基礎結構 OS 安全性記錄
鑑於介面區暗示，應該將所有混合式身分識別基礎結構 OS 記錄當成第 0 層系統進行封存並謹慎地監視。 這包括：
AD FS 伺服器和 Web 應用程式 Proxy
Microsoft Entra Connect
應用程式 Proxy 代理程式
密碼回寫代理程式
密碼保護閘道機器
擁有 Microsoft Entra 多重要素驗證 RADIUS 延伸模組的 NPS
Microsoft Entra Connect Health 必須加以部署，才能監視所有環境的身分識別同步和同盟 (適用時)。
記錄儲存體保留 - 所有環境都應該有一致的記錄儲存體保留策略、設計和實作，以協助一致的工具組 (例如，Azure Sentinel 之類的 SIEM 系統)、常見查詢、調查和鑑識劇本。 Azure 原則可以用來設定診斷設定。
監視和記錄檢閱 - 圍繞身分識別監視的操作工作應該一致，而且在每個環境中都具有擁有者。 如上所述，致力於將這些責任跨環境合併到法規合規性和隔離需求所允許的範圍。
必須明確地監視並調查下列案例：
可疑活動 - 應該監視所有 Microsoft Entra 風險事件找出可疑活動。 所有租用戶應該定義網路具名位置，以避免在位置型訊號上偵測到雜訊。 Microsoft Entra ID Protection 以原生方式與 Azure 資訊安全中心整合。 建議任何風險偵測調查包括佈建身分識別的所有環境 (例如，如果人類身分識別在公司租用戶中具有作用中風險偵測，則操作客戶面向租用戶的小組也應該調查該環境中對應帳戶的活動)。
使用者實體行為分析 (UEBA) 警示 - UEBA 應該用來根據異常偵測取得深入解析資訊。 適用於雲端應用程式的 Microsoft 365 Defender 會在雲端中提供 UEBA。 客戶可以從適用於身分識別的 Microsoft 365 Defender 整合內部部署 UEBA。 MCAS 會從 Microsoft Entra ID Protection 讀取訊號。
緊急存取帳戶活動 - 應該監視任何使用緊急存取帳戶的存取，以及針對調查建立的警示。 此監視必須包括：
登入
認證管理
關於群組成員資格的任何更新
應用程式指派
計費管理帳戶 - 鑑於 Azure EA 或 MCA 中具有計費管理角色的帳戶敏感度，以及其重大權限，建議您監視和警示下列情況：
透過具有計費角色的帳戶進行登入嘗試。
嘗試向 EA 入口網站以外的應用程式進行驗證。
如果使用 MCA 計費工作的專用帳戶，則嘗試向 Azure 資源管理以外的應用程式進行驗證。
使用 MCA 計費工作的專用帳戶指派給 Azure 資源。
活動特殊權限角色活動 - 設定和檢閱 Microsoft Entra PIM 所產生的安全性警示。 如果鎖定直接 RBAC 指派無法透過技術控制完全強制執行 (例如，擁有者角色必須授與產品小組，才能執行其工作)，則每當直接指派使用者，以利用 Azure RBAC 存取訂用帳戶時便會產生警示，監視 PIM 外特殊權限角色的直接指派。
傳統角色指派 - 組織應該使用新式 Azure RBAC 角色基礎結構，而不是傳統角色。 因此，應該監視下列事件：
- 指派給訂用帳戶層級的傳統角色
全租用戶設定 - 任何全租用戶設定服務都應該在系統中產生警示。
更新自訂網域
更新商標
Microsoft Entra B2B 允許/封鎖清單
Microsoft Entra B2B 允許的識別提供者 (透過直接同盟或社交登入的 SAML IDP)
條件式存取原則變更
應用程式和服務主體物件
可能需要條件式存取原則的新應用程式/服務主體
應用程式同意活動
管理群組活動 - 應該監視管理群組的下列身分識別層面：
MG 中的 RBAC 角色指派
在 MG 套用的 Azure 原則
在 MG 之間移動的訂用帳戶
根 MG 安全性原則的任何變更
自訂角色
自訂角色定義的更新
已建立新的自訂角色
自訂職責區分規則 - 如果您的組織建立了任何職責區分規則，使用 Microsoft Entra 權利管理不相容的存取套件來強制執行職責區分，並建立警示或設定定期檢閱來偵測系統管理員違規。
其他監視考量 - 所含資源用於記錄管理的 Azure 訂用帳戶，應該視為重要基礎結構 (第 0 層)，並鎖定至對應環境的安全性作業小組。 請考慮使用 Azure 原則之類的工具，針對這些訂用帳戶強制執行其他控制。
操作工具
跨環境工具設計考量：
可能的話，將跨多個租用戶使用的作業工具應該設計成以 Microsoft Entra 多租用戶應用程式的形式執行，以避免在每個租用戶上重新部署多個執行個體，並避免作業效率不佳。 實作應該包含授權邏輯，以確定保留使用者與資料之間的隔離。
新增警示和偵測，以監視任何跨環境自動化 (例如，身分識別佈建) 和保全的閾值限制。 例如，如果取消佈建使用者帳戶達到特定層級，您可能會想要發出警示，因為其可能指出具有廣泛影響的 Bug 或作業錯誤。
協調跨環境工作的任何自動化都應該以高度特殊權限系統的形式操作。 如果需要來自其他環境的資料，此系統應該裝載到最高安全性環境，並從外部來源提取。 必須套用資料驗證和閾值，才能維護系統完整性。 常見的跨環境工作是身分識別生命週期管理，可從所有環境中移除解聘員工的身分識別。
IT 服務管理工具 - 使用 IT 服務管理 (ITSM) 系統的組織，例如 ServiceNow，應該設定 Microsoft Entra PIM 角色啟用設定，以要求票證號碼作為啟用目的一部分。
同樣地，Azure 監視器可以透過 IT 服務管理連接器與 ITSM 系統整合。
操作實務 - 將需要直接存取環境進行人類身分識別的作業活動降至最低。 相反地，將其模型化為執行常見作業 (例如，將容量新增至 PaaS 解決方案、執行診斷等等) 的 Azure Pipelines，並建立直接存取模型，以存取「緊急安全窗口」案例的 Azure Resource Manager 介面。
作業挑戰
某些案例的服務主體監視活動會受到限制
Microsoft Entra PIM 警示沒有 API。 若要降低風險，請定期檢閱這些 PIM 警示。
Azure EA 入口網站不會提供監視功能。 若要降低風險，請擁有專用的系統管理帳戶並監視帳戶活動。
MCA 不會提供計費工作的稽核記錄。 若要降低風險，請擁有專用的系統管理帳戶並監視帳戶活動。
Azure 中的某些服務需要操作環境，才能跨環境重新部署和重新設定，因為其不能是多租用戶或多雲端。
沒有跨 Microsoft Online Services 的完整 API 涵蓋範圍，以完全達成基礎結構即程式碼。 若要降低風險，請盡可能使用 API，並針對其餘部分使用入口網站。 此開放原始碼方案可協助您判斷可能適用於您環境的方法。
沒有程式設計功能可探索資源租用戶，這些租用戶對管理租用戶中的身分識別具有委派的訂用帳戶存取權。 例如，如果電子郵件地址已在 contoso.com 租用戶中啟用安全性群組來管理 fabrikam.com 租用戶中的訂用帳戶，則 contoso.com 中的管理員沒有 API 來探索是否發生了此委派。
特定帳戶活動監視 (例如，緊急安全窗口帳戶、計費管理帳戶) 不會以現成方式提供。 若要降低風險，請客戶建立自己的警示規則。
全租用戶的設定監視不會以現成方式提供。 若要降低風險，請客戶建立自己的警示規則。