身份识别及超越 — 一位架构师的观点

在本文中，Microsoft 首席技术架构师 Alex Shteynberg 讨论了采用 Microsoft 365 和其他 Microsoft 云服务的企业组织的顶级设计策略。

作者简介

我是纽约 Microsoft 技术中心的首席技术架构师。 我主要与大型客户和复杂要求合作。 我的观点和观点是基于这些互动的，可能并不适用于每一种情况。 但是，就我的经验而言，如果我们能帮助客户应对最复杂的挑战，我们就能帮助所有客户。

我通常每年与 100 多个客户合作。 虽然每个组织都有独特的特征，但看到趋势和共同点很有趣。 例如，一个趋势是许多客户的跨行业兴趣。 毕竟，银行分行也可以是咖啡店和社区中心。

在我的角色中，我专注于帮助客户达成最佳技术解决方案，以实现他们独特的业务目标集。 我正式专注于标识、安全性、隐私和合规性。 我喜欢这些触摸我们所做的一切。 这给了我一个参与大多数项目的机会。 此活动使我忙碌，享受这个角色。

我住在纽约市 (最好的！) ，真的很享受其文化，食物和人的多样性 (而不是交通) 。 我喜欢旅行，当我可以，并希望看到世界上大部分在我有生之年。 我目前正在研究非洲之行，了解野生动物。

指导原则

• 简单通常更好：使用技术几乎可以执行 () 任何事情，但这并不意味着你应该这样做。 特别是在安全领域，许多客户都过度工程解决方案。 我喜欢谷歌条纹会议的 这段视频 来强调这一点。
• 人员、流程、技术：为人设计来增强流程，而不是技术第一。 没有“完美”的解决方案。 我们需要平衡每个业务可能不同的各种风险因素和决策。 太多的客户设计了一种用户以后会避免的方法。
• 首先关注“为什么”，然后是“如何”：成为一个有一百万个问题的讨厌的7岁大孩子。 如果我们不知道要问的正确问题，我们就不能得出正确的答案。 许多客户都对事情需要如何运作做出假设，而不是定义业务问题。 始终可以采用多个路径。
• 过去最佳做法的长尾：认识到最佳做法正在以轻快的速度变化。 如果你在三个多月前查看过Microsoft Entra，则可能已过期。 此处的所有内容在发布后都可能会更改。 现在的“最佳”选项可能与六个月后的“最佳”选项不同。

基线概念

请勿跳过此部分。 我经常发现，我必须回顾这些文章，即使是使用云服务多年的客户也是如此。 唉，语言不是一个精确的工具。 我们经常使用同一个词来表示不同的概念，或者使用不同的字词来表示相同的概念。 我经常使用下图来建立一些基线术语和“层次结构模型”。

当你学会游泳时，最好从游泳池开始，而不是在海洋中间开始。 我不想在技术上准确处理此图。 它是讨论一些基本概念的模型。

本图示内容：

• Tenant = Microsoft Entra ID 的实例。 它位于层次结构的“顶部”，或关系图中的级别 1。 我们可以将此级别视为“边界”， (Microsoft Entra B2B) 一边发生其他一切。 所有 Microsoft 企业云服务都是其中一个租户的一部分。 使用者服务是独立的。 在文档中，“租户”显示为 Microsoft 365 租户、Azure 租户、WVD 租户等。 我经常发现这些变体会导致客户感到困惑。
• 服务/订阅（关系图中的级别 2）仅属于一个租户。 大多数 SaaS 服务都是 1：1，如果不迁移，就无法移动。 Azure 不同，可以将计费和/或订阅移到另一个租户。 有许多客户需要移动 Azure 订阅。 此方案具有各种含义。 存在于订阅外部的对象不会移动。 例如，基于角色的访问控制 (Azure RBAC) 、Microsoft Entra对象 (组、应用、策略等 ) ，某些服务 (Azure 密钥保管库、Data Bricks 等 ) 。 如果没有良好的业务需求，请勿迁移服务。 GitHub 上共享一些有助于迁移的脚本。
• 给定服务通常具有某种“子级别”边界，或级别 3 (L3) 。 此边界有助于了解安全、策略、治理等的隔离。 不幸的是，我不知道没有统一的名字。 L3 的一些示例名称如下：Azure 订阅 = 资源;Dynamics 365 CE = 实例;Power BI = workspace;Power Apps = environment;等等。
• 级别 4 是实际数据所在的位置。 此“数据平面”是一篇复杂的文章。 某些服务使用 Microsoft Entra ID 进行 RBAC，而其他服务则不使用。 当我们访问委派文章时，我将对其进行一些讨论。

我发现许多客户 (和 Microsoft 员工) 感到困惑或有疑问的其他概念包括以下问题：

• 任何人都可以免费创建多个租户。 不需要在其中预配服务。 我有几十个 每个租户名称在 Microsoft 的全球云服务中都是唯一的， (换句话说，没有两个租户) 可以具有相同的名称。 它们都采用 TenantName.onmicrosoft.com 格式。 还有一些过程会自动 (非托管租户) 创建租户。 例如，当用户使用任何其他租户中不存在的电子邮件域注册企业服务时，可能会出现此结果。
• 在托管租户中，可以在其中注册许多 DNS 域 。 此结果不会更改原始租户名称。 除了迁移) ，目前没有简单的方法来重命名租户 (。 尽管租户名称目前在技术上并不重要，但有些人可能会觉得受此现实的限制。
• 即使尚未计划部署任何服务，也应为组织保留租户名称。 否则，有人可以从你那里拿回它，没有简单的过程来收回它 (与 DNS 名称) 相同的问题。 我经常听到客户这样的声音。 租户名称也应该是一篇辩论文章。
• 如果你拥有 DNS 命名空间，则应将所有这些命名空间添加到租户。 否则，可能会创建具有此名称 的非托管租户 ，这会导致中断， 使其托管。
• 例如，DNS 命名空间 (，contoso.com) 可以属于一个租户，并且只能属于一个租户。 此要求对各种方案具有影响， (例如，在合并或收购期间共享电子邮件域等) 。 有一种方法可以注册 DNS 子 (，例如在不同的租户中 div.contoso.com) ，但应避免这样做。 通过注册顶级域名，假定所有子域属于同一租户。 在多租户方案中， (如下) 中所述，我通常建议使用其他顶级域名 (，例如 contoso.ch 或 ch-contoso.com) 。
• 谁应该“拥有”租户？ 我经常看到不知道当前谁拥有其租户的客户。 这种缺乏知识是一个明显的危险信号。 尽快致电 Microsoft 支持人员。 同样，当服务所有者 (通常指定 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 同步， (合作伙伴可能需要) 。
• 我需要将相同的对象预配到多个租户。 此方案在技术上不受支持，但取决于“same”的定义。

是否应自定义默认同步规则 (筛选器对象、 更改属性、 备用登录 ID 等) ？ 避免它！ 标识平台的价值仅与使用它的服务一样重要。 虽然可以执行各种疯狂配置，但要回答这个问题，需要看看对应用程序的影响。 如果筛选已启用邮件的对象，则联机服务的 GAL 不完整;如果应用程序依赖于特定属性，则对这些属性进行筛选会产生不可预知的影响;依此类而行。 这不是标识团队的决定。

XYZ SaaS 支持实时 (JIT) 预配，为什么要求我同步？ 请参阅上一段。 许多应用程序需要“配置文件”信息才能实现功能。 如果所有启用邮件的对象都不可用，则不能有 GAL。 同样适用于与 Microsoft Entra ID 集成的应用程序中的用户预配。

身份验证

密码哈希同步 (PHS) 与 直通身份验证 (PTA) 与 联合身份验证。

通常围绕联邦进行激烈 的辩论 。 更简单通常更好，因此除非有充分的理由不使用，否则使用 PHS 更好。 还可以为同一租户中的不同 DNS 域配置不同的身份验证方法。

一些客户启用联合身份验证 + PHS 主要用于：

• 如果联合身份验证服务不可用，可以选择 回退 到 (进行灾难恢复) 。
• 其他功能 (例如，Microsoft Entra 域服务) 和安全服务 (凭据泄露)
• 对 Azure 中不了解联合身份验证的服务的支持 (例如，Azure 文件存储) 。

我经常引导客户完成客户端身份验证流程，以澄清一些误解。 结果如下图所示，这不如到达其中的交互过程好。

这种类型的白板绘图说明了在身份验证请求流中应用安全策略的位置。 在此示例中，通过 Active Directory 联合身份验证服务 (AD FS) 强制实施的策略将应用于第一个服务请求，但不会应用于后续服务请求。 此行为是尽可能多地将安全控件移动到云的原因之一。

只要我记得，我们一直在追逐 单一登录 (SSO) 的梦想。 一些客户认为，他们可以通过选择 STS) 提供商 (“正确”联合身份验证来实现单一登录。 Microsoft Entra ID可以大大有助于启用 SSO 功能，但没有任何 STS 是不可思议的。 仍有太多的“旧式”身份验证方法仍用于关键应用程序。 使用合作伙伴解决方案扩展Microsoft Entra ID可以解决其中许多方案。 SSO 是一种策略和旅程。 如果不转向应用程序标准，就不可能达到这 一点。 与本文相关的是 无密码 身份验证之旅，它也没有神奇的答案。

多重身份验证 (MFA) 今天 (对于更多) 至关重要。 向其添加 用户行为分析 ，你拥有一个可防止最常见的网络攻击的解决方案。 甚至消费者服务也开始需要 MFA。 然而，我仍然遇到许多不想采用 新式身份验证 方法的客户。 我听到的最大论点是，它会影响用户和旧应用程序。 有时，一个好的启动可能会帮助客户前进 - Exchange Online宣布的更改。 现在可以使用许多Microsoft Entra报表来帮助客户完成此转换。

Authorization

根据 维基百科，“授权”是定义访问策略。 许多人将其视为能够定义对象的访问控制， (文件、服务等) 。 在当前的网络威胁世界中，此概念正在迅速演变为动态策略，该策略可以应对各种威胁向量，并快速调整访问控制以响应它们。 例如，如果我从异常位置访问我的银行帐户，则会收到额外的确认步骤。 为了应对这一现实，我们不仅需要考虑策略本身，还需要考虑威胁检测和信号关联方法的生态系统。

Microsoft Entra ID的策略引擎是使用条件访问策略实现的。 此系统依赖于来自其他威胁检测系统的信息来做出动态决策。 简单视图类似于下图：

将所有这些信号组合在一起后，可以采用如下所示的动态策略：

• 如果在你的设备上检测到威胁，则你对数据的访问将减少到仅 Web，而无法下载。
• 如果要下载异常大量的数据，则下载的任何内容都将被加密和限制。
• 如果从非托管设备访问服务，则会阻止使用高度敏感数据，但允许访问非受限数据，而无法将其复制到其他位置。

如果同意此扩展的授权定义，则需要实现其他解决方案。 实施哪些解决方案取决于你希望策略的动态程度以及要确定哪些威胁的优先级。 此类系统的一些示例包括：

• Microsoft Entra ID 保护
• Microsoft Defender for Identity
• Microsoft Defender for Endpoint
• Microsoft Defender for Office 365
• Microsoft Defender for Cloud Apps (Defender for Cloud Apps)
• Microsoft Defender XDR
• Microsoft Intune
• Microsoft Purview 信息保护
• Microsoft Sentinel

除了Microsoft Entra ID之外，各种服务和应用程序还具有自己的特定授权模型。 委托部分稍后将讨论其中一些模型。

Audit

Microsoft Entra ID具有详细的审核和报告功能。 但是，这些报告通常不是做出安全决策所需的唯一信息来源。 有关此主题的更多讨论，请参阅委派部分。

没有 Exchange

不要惊慌！ Exchange 未 (或 SharePoint 等) 弃用。 它仍然是一项核心服务。 我的意思是，相当一段时间以来，技术提供商一直在转换用户体验 (UX) ，以包含多个服务的组件。 在 Microsoft 365 中，一个简单的示例是“新式附件”，其中电子邮件附件存储在 SharePoint Online 或 OneDrive 中。

查看 Outlook 客户端，可以看到许多服务都“已连接”作为此体验的一部分，而不仅仅是 Exchange。 示例包括Microsoft Entra ID、Microsoft 搜索、应用、配置文件、合规性和 Microsoft 365 组。

阅读有关即将推出的功能的预览Microsoft Fluid Framework。 现在在预览版中，我可以直接在 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 具有全面的 合规性方法，但更改人员和流程通常比技术要困难得多。

还有许多其他人员和流程影响。 在我看来，这一因素是一个关键和讨论不足的领域。 也许在另一篇文章中更多。

租户结构选项

单租户与多租户

通常，大多数客户应只有一个生产租户。 多个租户具有挑战性的原因有很多， (提供 必应搜索) 或阅读本 白皮书。 同时，我合作的许多企业客户都有另一个用于 IT 学习、测试和试验 (小型) 租户。 使用 Azure Lighthouse 可以更轻松地进行跨租户 Azure 访问。 Microsoft 365 和许多其他 SaaS 服务对跨租户方案有限制。 Microsoft Entra B2B 方案中需要考虑很多问题。

许多客户在 M&A) 合并和收购后最终获得多个生产租户 (并希望合并。 如今，这并不简单，需要 Microsoft 咨询服务 (MCS) 或合作伙伴加上第三方软件。 正在进行的工程工作将在未来解决多租户客户的各种方案。

某些客户选择使用多个租户。 这应该是一个谨慎的决定，几乎总是业务原因驱动的！ 一些示例包括以下原因：

• 控股型公司结构，其中不同实体之间不需要轻松协作，并且存在强大的管理和其他隔离需求。
• 收购后，将做出业务决策，将两个实体分开。
• 模拟不会更改客户生产环境的客户的环境。
• 为客户开发软件。

在这些多租户方案中，客户通常希望使某些配置跨租户保持相同，或者报告配置更改和偏差。 这通常意味着从手动更改转移到配置即代码。 Microsoft Premiere 支持基于以下公共 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角色，因此更改发生在同一位置。 提示：如果想要一个不带所有 Azure 杂乱的以标识管理为中心的管理 UI，请使用 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 ( (PAM) 解决方案的相应 miM) Privileged Access Management。 你可能还需要查看特权访问工作站 (PAW) 和Microsoft Entra ID 治理。 还有各种第三方工具，可以启用实时、恰时和动态角色提升。 此功能通常是有关保护环境的大型讨论的一部分。

有时，方案要求将外部用户添加到角色 (请参阅前面的多租户部分) 。 此结果正常。 Microsoft Entra B2B 是另一篇大而有趣的文章，可以引导客户完成，也许在另一篇文章中。

Microsoft Defender XDR和 Microsoft 365 Purview 合规性门户

Microsoft Defender门户中Email &协作角色和 Microsoft 365 Purview 合规性门户中Microsoft Purview 解决方案的角色组是“角色组”的集合，这些角色组与Microsoft Entra角色不同。 这可能会令人困惑，因为其中一些角色组与Microsoft Entra角色同名， (例如安全读取者) ，但它们可以具有不同的成员身份。 我更喜欢使用Microsoft Entra角色。 每个角色组由一个或多个“角色”组成， (了解我关于重用同一个单词的意思 ) ，并且具有来自Microsoft Entra ID（即已启用电子邮件的对象）的成员。 此外，还可以创建一个与角色同名的角色组，该角色组可能包含该角色，也可能不包含该角色， (避免) 这种混淆。

从某种意义上说，这些权限是 Exchange 角色组模型的演变。 但是，Exchange Online有自己的角色组管理界面。 Exchange Online中的某些角色组在Microsoft Entra ID或Microsoft Defender XDR和 Microsoft 365 Purview 合规性门户中被锁定和管理，但其他角色组的名称可能相同或相似，并且Exchange Online (管理，这增加了) 混乱。 建议避免使用 Exchange Online 用户界面，除非需要 Exchange 管理的范围。

无法创建自定义角色。 角色由 Microsoft 创建的服务定义，并随着新服务的引入而不断发展。 此行为在概念上类似于 Microsoft Entra ID 中应用程序定义的角色。 启用新服务后，通常需要创建新的角色组，以便授予或委派对这些 (例如 内部风险管理的访问权限。

这些角色组还需要直接成员身份，不能包含Microsoft Entra组。 遗憾的是，MICROSOFT ENTRA PIM 目前不支持这些角色组。 与Microsoft Entra角色一样，我倾向于建议通过 API 或合作伙伴治理产品（如 Saviynt 等）来管理这些角色组。

Microsoft Defender门户和 Microsoft 365 Purview 合规性门户角色跨越 Microsoft 365，你无法将这些角色组限定为一部分环境 (就像在 Microsoft Entra ID) 中使用管理单元一样。 许多客户询问他们如何细分。 例如，“仅为欧盟用户创建 DLP 策略”。目前，如果你有权访问 Microsoft Defender XDR 和 Microsoft 365 Purview 合规性门户中的特定函数，则你有权访问租户中此函数涵盖的所有内容。 但是，许多策略具有面向环境子集的功能， (例如，“使这些 标签 仅对这些用户可用”) 。 适当的治理和通信是避免冲突的关键组成部分。 某些客户选择实现“配置即代码”方法，以解决Microsoft Defender XDR和 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)
• 电子数据展示 - (./compliance/index.yml)
  • 权限筛选 - (./compliance/index.yml)
  • 合规性边界 - (./compliance/set-up-compliance-boundaries.md)
  • 电子数据展示 (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 for Endpoint - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

• Microsoft Defender XDR - (./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) 无关的Microsoft Entra ID (活动
• Exchange 邮件跟踪
• 前面讨论的威胁/UEBA 系统 (，例如，Microsoft Entra ID 保护、Microsoft Defender for Cloud Apps、Microsoft Defender for Endpoint等)
• Microsoft Purview 信息保护
• Microsoft Defender for Endpoint
• Microsoft Graph

请务必首先确定安全性和合规性计划所需的所有日志源。 另请注意，不同的日志具有不同的在线保留限制。

从管理员委派的角度来看，大多数 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 XDR 的服务中，有一个针对安全性、威胁、漏洞等的丰富内置分析系统。

许多大客户希望将此日志数据传输到第三方系统， (例如 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 蓝图、 管理组等) 。

总结

本文一开始是简短的总结，最终比我预想的要长。 我希望你现在已准备好深入了解如何为组织创建委派模型。 这种对话在客户中很常见。 没有一个模型适用于每个人。 在记录我们在客户中看到的常见模式之前，等待 Microsoft 工程的一些计划改进。 在此期间，你可以与 Microsoft 帐户团队协作，安排访问最近的 Microsoft 技术中心。 在那里见！