适用于所有隔离体系结构的最佳做法
下面是适用于所有隔离配置的设计注意事项。 在整个内容中有许多链接。 我们链接到内容，而不是在此处进行复制，以便你始终可访问最新信息。
有关如何配置 Microsoft Entra 租户（隔离或非隔离）的一般指南，请参阅 Microsoft Entra 功能部署指南。
注意
对于所有独立租户，建议使用清晰和差异化的品牌打造，以帮助避免在错误租户中工作这一人为错误。
隔离安全性原则
设计独立环境时，请务必考虑以下原则：
仅使用新式身份验证 - 在独立环境中部署的应用程序必须使用基于声明的新式身份验证（例如 SAML、* Auth、OAuth2 和 OpenID Connect），才能使用联合、Microsoft Entra B2B 协作、委派和同意框架等功能。 这样，依赖于旧身份验证方法（例如 NT LAN Manager (NTLM)）的旧应用程序无法在独立环境中继续运行。
强制实施强身份验证 - 访问独立环境服务和基础结构时，必须始终使用强身份验证。 应尽可能使用无密码身份验证（例如 Windows Hello 企业版或 FIDO2 安全密钥）。
部署安全工作站 - 安全工作站提供了一种机制，可确保平台以及平台表示的标识进行正确证明并防范攻击。 要考虑的另外两种方法是：
将 Windows 365 云电脑（云电脑）与 Microsoft Graph API 配合使用。
使用条件访问并筛选设备作为条件。
消除旧信任机制 - 独立目录和服务不应通过旧机制（如 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 ID 中也有一个帐户，因为它需要访问 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 的同步周期。
身份验证管理
本部分介绍根据组织的安全状况，要针对凭据管理和访问策略执行的检查和执行的操作。
凭据管理
强凭据
必须使用强身份验证凭据（例如多重身份验证或 FIDO 密钥）预配独立环境中的所有人员标识（通过 B2B 协作预配的本地帐户和外部标识）。 具有采用强身份验证（例如智能卡身份验证）的基础本地基础结构的环境可以在云中继续使用智能卡身份验证。
无密码凭据
无密码解决方案是可确保最方便且最安全的身份验证方法的最佳解决方案。 对于具有特权角色的人员标识，建议使用无密码凭据（例如 FIDO 安全密钥和 Windows Hello 企业版）。
密码保护
如果环境从本地 Active Directory 林进行同步，则应部署 Microsoft Entra 密码保护以消除组织中的弱密码。 还应在混合或仅限云的环境中使用 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 提供由安全入口（例如多重身份验证、审批工作流和有限持续时间）确定的实时激活。
管理员数 - 组织应定义拥有特权角色的最小和最大人员数，以缓解业务连续性风险。 特权角色太少时，可能没有足够的时区覆盖范围。 遵循最低特权原则，通过让管理员尽可能少来缓解安全风险。
限制特权访问 - 为高特权或敏感特权创建仅限云和可分配角色的组。 这可为分配的用户和组对象提供保护。
最低特权访问 - 仅应向标识授予根据其角色在组织中执行特权操作所需的权限。
Azure RBAC 自定义角色允许基于组织需求设计最低特权角色。 建议由专业安全团队创作或评审自定义角色定义，缓解意外过多特权的风险。 可以通过 Azure Policy 审核自定义角色的创作。
若要减少对不打算在组织中广泛使用的角色的意外使用，请使用 Azure Policy 显式定义哪些角色定义可用于分配访问权限。 通过此 GitHub 示例了解详细信息。
从安全工作站进行的特权访问 - 所有特权访问都应从安全的锁定设备进行。 从日常使用的工作站和设备中分离这些敏感任务和帐户可保护特权帐户，使其免受网络钓鱼攻击、应用程序和 OS 漏洞攻击、各种模拟攻击和凭据盗窃攻击（例如按键日志记录、哈希传递和票证传递）。
可用于将安全设备用作特权访问情景的一部分的方法包括使用条件访问策略针对或排除特定设备、使用 Azure 虚拟桌面、Azure Bastion 或云电脑，或者创建 Azure 托管工作站或特权访问工作站。
特权角色过程防护措施 - 组织必须定义过程和技术防护措施，以确保在符合法规要求的同时，可以根据需要随时执行特权操作。 防护措施条件的示例包括：
具有特权角色的人员资格（例如全职员工/供应商、通行证级别、公民身份）
角色的明确不兼容性（也称为职责分离）。 示例包括具有 Microsoft Entra 目录角色的团队不应负责管理 Azure 资源管理器特权角色等。
对于哪些角色，首选直接用户或组分配。
监视 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 Policy 控制 Azure AD B2C 租户创建。 当 Azure 订阅关联到 B2C 租户时（计费的先决条件），策略会执行。 客户可以将 Azure AD B2C 租户的创建限制到特定管理组。
没有技术控制可使租户的创建从属于组织。 但是，活动会记录在审核日志中。 加入计费平面是入口处的补偿控制。 这需要改为通过监视和警报进行补充。
订阅生命周期
下面是设计受治理订阅生命周期过程时的一些注意事项：
定义需要 Azure 资源的应用程序和解决方案的分类。 请求订阅的所有团队都应在请求订阅时提供其“产品标识符”。 此信息分类会确定：
预配订阅的 Microsoft Entra 租户
用于订阅创建的 Azure EA 帐户
命名约定
管理组分配
其他方面，例如标记、交叉记帐、产品视图使用情况等。
请勿允许通过门户或其他方式创建临时订阅。 相反，请考虑使用 Azure 资源管理器以编程方式管理订阅，并以编程方式拉取消耗和计费报表。 这可帮助将订阅预配限制到授权用户并强制实施策略和分类目标。 有关以下 AZOps 主体的指导可用于帮助创建实用解决方案。
预配订阅后，创建 Microsoft Entra 云组以拥有应用程序团队所需的标准 Azure 资源管理器角色，例如参与者、读者和已批准的自定义角色。 这使你可以大规模管理具有受治理特权访问权限的 Azure RBAC 角色分配。
鉴于租户与 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 的紧急访问准则，除了上述外部管理员之外，还应考虑创建等效的紧急访问帐户。
建议采用将其余 Azure 订阅用于 B2C 解决方案的相同方式，使 B2C 租户的基础 Microsoft Entra 订阅的逻辑所有权与 CIAM 工程团队保持一致。
操作
下面是特定于多个独立环境的适用于 Microsoft Entra ID 的其他操作注意事项。 有关操作各个环境的详细指导，请查看 Azure 云采用框架、Microsoft 云安全基准和 Microsoft Entra 操作指南。
跨环境角色和职责
企业范围的 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 Monitor 可用于从不同源（例如终结点设备、网络、操作系统的安全日志等）引入日志。
Microsoft Entra 安全操作指南提供了有关在安全操作过程中使用自动化或手动过程和工具监视日志的详细信息。
某些环境可能具有限制哪些数据（如果有）可以离开给定环境的法规要求。 如果无法进行跨环境集中监视，则团队应具有操作过程来跨环境关联标识的活动，以用于审核和取证，例如跨环境横向移动尝试。 建议在标识预配系统中，可以发现属于同一人的对象唯一标识符人员标识。
日志策略必须为组织中使用的每个租户包含以下 Microsoft Entra 日志：
登录活动
审核日志
风险事件
Microsoft Entra ID 提供登录活动日志和审核日志的 Azure Monitor 集成。 可以通过 Microsoft Graph API 引入风险事件。
下图显示了需要纳入监视策略中的不同数据源：
Azure AD B2C 租户可以与 Azure Monitor 集成。 建议使用上述适用于 Microsoft Entra ID 的相同条件来监视 Azure AD B2C。
如果由 Azure Monitor 收集日志，则通过 Azure Lighthouse 启用了跨租户管理的订阅可以启用跨租户监视。 对应 Log Analytics 工作区可以驻留在资源租户中，并且可以使用 Azure Monitor 工作簿在管理租户中集中分析。 若要了解详细信息，请查看 大规模监视委托资源 - Azure Lighthouse。
混合基础结构 OS 安全日志
由于对外围应用造成的影响，应该存档所有混合标识基础结构 OS 日志，并将其作为第 0 层系统认真监视。 这包括：
AD FS 服务器和 Web 应用程序代理
Microsoft Entra Connect
应用程序代理
密码写回代理
密码保护网关计算机
具有 Microsoft Entra 多重身份验证 RADIUS 扩展的 NPS
必须部署 Microsoft Entra Connect Health 以监视所有环境的标识同步和联合（如果适用）。
日志存储保留 - 所有环境都应具有统一的日志存储保留策略、设计和实现，以促使形成一致的工具集（例如 SIEM 系统，如 Azure Sentinel）、通用查询、调查和取证 playbook。 Azure Policy 可用于设置诊断设置。
监视和日志评审 - 有关标识监视的操作任务应在每个环境中保持一致，并且具有所有者。 如上所述，应努力在法规合规性和隔离要求允许的范围内跨环境整合这些责任。
必须显式监视和调查以下场景：
可疑活动 - 应监视所有 Microsoft Entra 风险事件，以发现可疑活动。 所有租户都应定义网络命名位置，以免基于位置的信号产生干扰性的检测结果。 Microsoft Entra ID 保护与 Azure 安全中心原生集成。 建议任何风险检测调查都包含预配标识的所有环境（例如，如果某个人员标识在公司租户中具有活动风险检测，则操作面向客户的租户的团队也应在该环境中调查对应帐户的活动）。
用户实体行为分析 (UEBA) 警报 - 应使用 UEBA 以基于异常情况检测获取富有见解的信息。 Microsoft Microsoft 365 Defender for Cloud Apps在云中提供 UEBA。 客户可以从 Microsoft Microsoft 365 Defender for Identity 集成本地 UEBA。 MCAS 从 Microsoft Entra ID 保护读取信号。
紧急访问帐户活动 - 应监视任何使用紧急访问帐户的访问，并创建警报以进行调查。 此项监视必须包括：
登录
凭据管理
对组成员身份进行的任何更新
应用程序分配
计费管理帐户 - 鉴于在 Azure EA 或 MCA 中具有计费管理角色的帐户的敏感性及其重要特权，建议对以下情况进行监视并发出警报：
由具有计费角色的帐户进行的登录尝试。
对 EA 门户以外的其他应用程序进行身份验证的任何尝试。
对 Azure 资源管理以外的其他应用程序进行身份验证的任何尝试（如果对 MCA 计费任务使用专用帐户）。
使用专用帐户为 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 Policy 等工具对这些订阅强制实施其他控制。
操作工具
跨环境工具设计注意事项：
应尽可能将会跨多个租户使用的操作工具设计为作为 Microsoft Entra 多租户应用程序来运行，以避免在每个租户上重新部署多个实例，并避免操作效率低下。 实现应包含授权逻辑，以确保维持用户与数据之间的隔离。
添加警报和检测来监视任何跨环境自动化（例如标识预配）和阈值限制，以实现防故障。 例如，你可能希望在用户帐户的取消设置达到特定级别时发出警报，因为它可能指示可能会产生广泛影响的 bug 或操作错误。
协调跨环境任务的任何自动化都应作为高特权系统来运行。 如果需要来自其他环境的数据，此系统应位于最高安全性环境中并从外部源进行拉取。 需要应用数据验证和阈值以维护系统完整性。 常见跨环境任务是标识生命周期管理，用于为离职员工从所有环境中移除标识。
IT 服务管理工具 - 使用 IT 服务管理 (ITSM) 系统（如 ServiceNow）的组织应配置 Microsoft Entra PIM 角色激活设置，以请求票证编号用于激活。
同样，Azure Monitor 可以通过 IT 服务管理连接器与 ITSM 系统集成。
操作做法 - 最大程度地减少需要针对人员标识直接访问环境的操作活动。 而是将它们建模为执行常见操作（例如将容量添加到 PaaS 解决方案、运行诊断等）的 Azure Pipelines，并将对 Azure 资源管理器接口的直接访问建模到“打破玻璃”方案。
操作挑战
对于某些场景，服务主体监视的活动会受到限制
Microsoft Entra PIM 警报没有 API。 缓解措施是定期评审这些 PIM 警报。
Azure EA 门户不提供监视功能。 缓解措施是使用专用管理帐户并监视帐户活动。
MCA 不提供用于计费任务的审核日志。 缓解措施是使用专用管理帐户并监视帐户活动。
Azure 中运行环境所需的某些服务需要跨环境重新部署和重新配置，因为它们不能是多租户或多云。
Microsoft Online Services 中没有完整的 API 覆盖，无法完全实现基础结构即代码。 缓解措施是尽可能多地使用 API，并将门户用于其余部分。 此开放源代码计划可帮助你确定可能适用于环境的方法。
没有编程功能可发现对管理租户中的标识具有委托订阅访问权限的资源租户。 例如，如果某个电子邮件地址在 contoso.com 租户中启用了安全组来管理 fabrikam.com 租户中的订阅，则 contoso.com 中的管理员没有 API 可发现发生了此委派。
不提供现成的特定帐户活动监视（例如，打破玻璃帐户、计费管理帐户）。 缓解措施是让客户创建自己的警报规则。
不提供现成的租户范围配置监视。 缓解措施是让客户创建自己的警报规则。