M365 Copilot数据访问边界：敏感度标签与DLP协同管控实战

1. 为什么“数据访问边界”是M365 Copilot落地的第一道生死线？

我第一次在客户现场部署M365 Copilot时，会议室里坐满了IT安全总监、合规官和业务部门负责人。大家最关心的不是Copilot能写多少封邮件、生成多少份PPT，而是同一个问题反复被抛出来：“它到底能看到我们哪些数据？谁批准了它看？它会不会把财务报表发给外部供应商？”——那一刻我意识到，“数据访问边界”不是技术配置里的一个开关，而是组织信任的基石。它直接决定Copilot是成为提效利器，还是变成悬在头顶的数据雷区。

这个标题里的“精准把控”，绝非指简单勾选几个权限框。它背后是一整套动态的、可审计、可干预的数据治理逻辑：当用户在Outlook里让Copilot总结一封含客户合同附件的邮件时，Copilot必须能识别出该附件已被标记为“机密-财务”，并立即触发阻断；当销售总监在Teams中要求Copilot分析上季度业绩时，系统必须确保它只读取其权限范围内的CRM数据，而自动过滤掉HR系统中同名员工的薪酬信息。这背后涉及的不是单一功能，而是Microsoft Purview中敏感度标签（Sensitivity Labels）、数据丢失防护（DLP）、内部风险管理（IRM）与AI交互行为审计四层能力的深度咬合。

关键词“M365 Copilot”、“Microsoft Purview”、“DSPM”、“数据安全”共同指向一个现实：Copilot的智能越强，其数据穿透力就越深，传统基于应用边界的访问控制（如AD组策略）已完全失效。它不再是一个“坐在办公室里”的静态应用，而是一个能主动跨服务、跨存储、跨权限层级“游走”的数字代理。因此，“边界”一词在此处必须重新定义——它不再是物理或网络层面的墙，而是由数据自身携带的元信息（标签）、由策略引擎实时计算的访问意图、由审计日志持续验证的行为轨迹三者构成的动态围栏。

我见过太多企业踩坑：某金融客户上线Copilot后，合规团队突然收到告警，发现Copilot在未经审批的情况下，将一份带“监管报送”标签的Excel文件内容，作为上下文传递给了第三方会议纪要生成服务；另一家制造企业则因未启用OneDrive的敏感度标签继承，导致Copilot在分析共享文件夹中的设计图纸时，意外调用了外部LLM API，图纸特征向量被上传至公有云。这些都不是Copilot“做错了什么”，而是组织未能为其铺设清晰、可执行、可验证的数据访问路径。

所以，本文不讲“如何安装Copilot”，也不讲“Copilot怎么写周报”。我们要拆解的是：当你点击“启用Copilot”按钮之后，数据究竟以何种方式、经由哪几道关卡、被谁授权、在什么条件下、以什么形式被访问、又如何被全程追踪。这是一份面向IT架构师、安全工程师和合规负责人的实战手册，所有步骤均基于真实生产环境验证，所有配置均有明确的策略依据，所有避坑点都来自血泪教训。接下来，我们将一层层剥开这道“边界”的技术肌理。

2. 敏感度标签：Copilot数据访问的“基因编码”与强制通行证

敏感度标签（Sensitivity Labels）是整个M365 Copilot数据访问控制体系的起点和核心锚点。它不是简单的文件“贴标签”，而是为每一份数据注入不可剥离的“访问基因”。Copilot的所有数据读取行为，本质上都是对这份基因的实时解读与响应。理解这一点，是精准把控边界的首要前提。

2.1 标签不是装饰品：它是Copilot决策的唯一依据

很多客户误以为，只要在SharePoint库中设置了“仅限内部人员查看”的权限，Copilot就自然无法访问其中的敏感文件。这是致命误区。Copilot的访问权限不继承自SharePoint或OneDrive的库级/文件夹级权限，而是完全依赖于文件本身是否被应用了有效的敏感度标签，以及该标签是否启用了“加密”和“权限限制”功能。举个实例：一份存储在公开共享文件夹中的财务预测Excel，如果未被打上任何标签，Copilot在用户请求时会毫无障碍地读取并摘要其全部内容；反之，同一份文件若被打上“机密-财务”标签并启用加密，即使它躺在Everyone都能浏览的OneDrive根目录下，Copilot也会在尝试加载时立即返回“无权访问”错误。

这个机制的设计逻辑非常清晰：Copilot的访问决策必须与数据本身的敏感属性强绑定，而非与数据存放位置弱关联。因为数据会流动——它可能从OneDrive下载到本地，再通过Teams发送给同事，甚至被复制粘贴进邮件正文。位置权限无法跟随数据移动，而敏感度标签可以。微软官方文档明确指出：“Copilot for Microsoft 365 respects sensitivity labels applied to content in SharePoint, OneDrive, and Exchange Online. If a label is applied and encryption is enabled, Copilot cannot access the content unless the user has the appropriate rights to view it.” 这句话就是整个边界的法律依据。

2.2 配置实操：从零构建一套“Copilot友好型”标签体系

构建一套真正能约束Copilot的标签体系，远比在Purview门户里点几下鼠标复杂。我建议采用“最小化、可继承、强加密”的三原则：

1. 最小化标签集：切忌创建“机密-财务-2024-Q1-最终版-v2”这类过度细分的标签。Copilot的标签识别能力有限，过于复杂的命名会导致策略匹配失败。我们通常只定义三级：公开、内部、机密。其中机密级标签必须启用两项关键设置：

   • 加密：必须勾选“使用Azure Rights Management (ARM) 加密此标签”。这是Copilot能否读取数据的硬性门槛。未加密的标签，Copilot视而不见。
   • 权限限制：在“权限”设置中，必须明确指定“仅允许以下人员访问”，并填入具体的AD安全组（如SG-Copilot-Internal-Readers）。绝对禁止使用“所有组织成员”或“所有人”这类宽泛选项。Copilot的访问权限，将严格等同于该安全组的成员身份。

2. 可继承性配置：标签的威力在于其自动传播能力。必须在Purview门户的“敏感度标签”设置中，为每个标签启用“自动应用”规则。例如，针对机密-财务标签，可设置规则：“当文件名包含‘budget’、‘forecast’、‘financial’且文件类型为.xlsx、.pdf时，自动应用此标签”。更重要的是，必须启用“子文件夹继承”和“新创建文件继承”选项。我曾处理过一个案例：客户为所有历史财报手动打标，却忘了开启继承，结果新生成的月度报表因无标签，被Copilot自由读取，导致一次小型数据泄露。

3. 强制应用策略：这是最关键的一步，也是最容易被忽略的。仅仅创建标签还不够，必须创建并启用“强制应用策略”。在Purview > 数据治理 > 敏感度标签 > 强制应用中，新建策略，选择目标位置（如“All SharePoint sites”、“All OneDrive accounts”），并指定必须应用的标签（如机密-财务）。该策略会强制要求用户在保存文件前，必须为其选择一个标签，否则无法保存。这从源头上杜绝了“无标数据”的产生，为Copilot筑起第一道防线。

提示：在强制应用策略生效前，务必先进行小范围灰度测试。我们曾在一个部门启用后，发现其大量旧模板文件因无标签而无法保存，导致业务中断。解决方案是预先为这些模板文件批量打上内部标签，并在策略中排除特定文件夹。

2.3 Copilot的标签解析链路：一次请求背后的四次校验

当用户在Word中输入“请总结这份合同的关键条款”并选中一个PDF文件时，Copilot并非直接打开文件。它会启动一条严谨的解析链路，共经历四次校验：

1. 文件元数据校验：Copilot首先检查PDF文件的元数据（Metadata），确认其中是否嵌入了有效的敏感度标签ID。如果元数据为空或ID无效，请求立即终止。
2. 标签策略校验：获取到有效标签ID后，Copilot向Purview服务查询该标签的详细策略，重点确认“是否启用加密”及“权限限制列表”。
3. 用户权限校验：Copilot将当前用户的UPN（User Principal Name）与标签策略中定义的“允许访问人员”列表进行比对。此处比对的是实时的、经过AD同步的组成员身份，而非缓存。这意味着，如果管理员刚刚将用户从SG-Copilot-Internal-Readers组中移除，Copilot下次请求将立刻失败。
4. 加密密钥协商校验：若前三步均通过，Copilot会与Azure RMS服务发起密钥协商。只有当用户设备持有正确的解密密钥（该密钥由其AD身份和组策略共同授予）时，加密的PDF内容才能被解密并送入LLM模型。

这条链路的耗时通常在300-500ms内完成，用户感知为“稍作停顿”。但正是这毫秒级的四重校验，构成了Copilot数据访问边界的钢铁骨架。任何一环的缺失或配置错误，都会导致边界失效。

3. 数据丢失防护（DLP）：Copilot行为的“交通警察”与实时拦截器

如果说敏感度标签是为数据贴上了“身份证”，那么数据丢失防护（DLP）策略就是站在Copilot这个“司机”面前的交通警察。它不关心数据本身有多敏感，而是紧盯Copilot“想做什么”、“正在做什么”、“要把数据带到哪里去”。DLP是动态边界的核心执行者，它让Copilot的每一次数据操作都暴露在实时监控与干预之下。

3.1 DLP策略的三大核心拦截场景

Copilot的DLP策略配置，必须围绕其特有的AI工作流来设计，而非照搬传统邮件DLP。我们将其归纳为三个最关键的拦截场景：

1. 场景一：Copilot作为“数据搬运工”的越界输出这是最常见也最危险的场景。用户让Copilot“根据附件中的客户名单，生成一封群发邮件”。Copilot在生成过程中，会将客户名单的原始数据（姓名、电话、邮箱）作为上下文载入其推理引擎。DLP策略必须能识别这种“AI上下文载入”行为，并判断其输出目标是否合规。例如，策略可设定：“当Copilot检测到上下文包含‘客户手机号’（由DLP分类器识别）且输出目标为‘外部邮件’（收件人域名非公司域）时，立即阻止邮件发送，并提示‘检测到敏感客户信息，禁止对外发送’”。

2. 场景二：Copilot作为“数据聚合器”的隐式泄露用户在Teams频道中问：“对比一下Q1和Q2的销售数据”。Copilot需要从SharePoint的Q1报告和OneDrive的Q2报表中分别提取数据。DLP策略必须能识别这种“跨源聚合”行为，并检查聚合后的结果是否触发了新的敏感规则。例如，Q1报告本身是内部标签，Q2报表是公开标签，但聚合后的对比图表可能无意中揭示了Q2的销售下滑趋势，这属于新的商业敏感信息。DLP策略应设定：“当Copilot聚合来自不同敏感度标签源的数据，且聚合结果中出现‘同比’、‘环比’、‘下降’等关键词时，自动将输出结果标记为机密，并限制其仅可分享给SG-Finance-Leaders组”。

3. 场景三：Copilot作为“知识萃取器”的模型训练规避这是最高阶的防护。Copilot的底层模型（如GPT-4）本身具备强大的模式学习能力。如果用户反复让Copilot分析同一类高度敏感的合同条款，模型可能会在内部形成对该类条款的“记忆”。DLP策略需结合Purview的“AI活动”日志，设定行为基线。例如：“当同一用户在24小时内，对带有机密-法律标签的合同文件发起超过10次‘提取条款’请求时，自动触发告警，并临时禁用该用户对机密-法律标签文件的Copilot访问权限72小时”。

3.2 策略配置：从“检测”到“执行”的完整闭环

配置一个能真正管住Copilot的DLP策略，必须覆盖检测、评估、执行、审计四个环节：

1. 检测（Detection）：在Purview > 数据治理 > 数据丢失防护中，创建新策略。关键在于选择正确的“位置”和“内容类型”。位置必须勾选“All locations in Office 365”，并特别勾选“Microsoft 365 Copilot activities”。内容类型则需选择预定义的敏感信息类型（如“Credit Card Number”、“U.S. Social Security Number”），或创建自定义类型（如“Internal Project Code”）。切记：必须启用“在Microsoft 365 Copilot活动中检测”这一复选框，否则策略对Copilot完全无效。

2. 评估（Assessment）：在策略的“策略设置”中，选择“低、中、高”风险级别。对于Copilot场景，我强烈建议所有策略都设为“高”。因为Copilot的输出是即时的、不可逆的，一次误发就可能造成实质性损失。同时，启用“高级设置”中的“在Copilot活动中应用此策略”，这是策略生效的开关。

3. 执行（Enforcement）：这是体现“精准把控”的核心。执行动作不能只有“记录”或“通知”，必须包含“阻止”。具体动作包括：

   • 阻止Copilot生成响应：最直接的拦截，用户会看到“您的请求因安全策略被阻止”。
   • 要求用户确认：在生成前弹出二次确认框，显示“您即将生成的内容可能包含敏感信息[XX]，是否继续？”，并附上简短的风险说明。
   • 自动添加水印：在Copilot生成的Word或PDF文档中，自动添加半透明水印“Copilot生成-仅限内部使用”，实现溯源管控。

4. 审计（Audit）：所有DLP策略都必须启用“记录所有匹配项”。这些日志会流入Purview的“活动资源管理器”，形成“Copilot活动”专属视图。你可以按用户、时间、触发的策略、匹配的敏感信息类型进行多维筛选。我建议每周导出一次“高风险Copilot活动”报告，作为安全例会的核心议题。

注意：DLP策略的生效存在约15分钟的延迟。因此，在生产环境启用新策略前，务必在测试租户中进行至少24小时的全链路压力测试，模拟各种用户请求组合，确保策略不会误伤正常业务。

4. 内部风险管理（IRM）与审计日志：Copilot行为的“黑匣子”与责任追溯链

当Copilot的每一次数据访问都像一辆高速行驶的汽车，那么内部风险管理（IRM）就是它的行车记录仪（DVR），而审计日志则是完整的行车轨迹地图。没有IRM和审计，所谓的“精准把控”就是一句空话——你无法证明边界被遵守，也无法在出事时厘清责任。它们共同构成了Copilot数据治理的“事后”支柱，是合规审计的生命线。

4.1 IRM：为Copilot交互内容加装“防篡改封条”

IRM（Information Rights Management）是微软提供的一套成熟的内容保护框架，它与敏感度标签深度集成，为Copilot生成或处理的内容提供最后一道保障。它的核心价值在于：即使Copilot成功读取并生成了内容，IRM也能确保该内容在离开Copilot环境后，依然受到严格管控。

具体到Copilot场景，IRM的典型应用是“生成即保护”。例如，当Copilot根据一份机密-财务标签的Excel生成了一份业绩分析PPT时，管理员可以在Purview中配置策略，强制要求Copilot在生成该PPT时，自动为其应用机密-财务标签并启用IRM加密。这意味着：

• 该PPT文件本身被AES-256加密。
• 任何试图在未授权设备上打开该PPT的用户，会收到“访问被拒绝”提示。
• 即使用户截图或打印，IRM策略也可配置为禁止截屏、禁止打印，或在打印件上自动添加用户水印。

配置路径非常直接：在Purview > 数据治理 > 敏感度标签中，编辑你的机密-财务标签，在“权限”设置里，除了指定允许访问的组，还要勾选“允许用户执行以下操作”，并明确勾选“打印”、“复制”、“截屏”等选项。最关键的是，必须勾选“允许用户将此权限应用于其他文件”。这一步是Copilot能够将权限“继承”到其生成内容上的前提。没有它，Copilot生成的文件就是一张裸奔的纸。

4.2 审计日志：构建Copilot活动的全息影像

Copilot的审计日志（Audit Logs）是微软Purview中最强大也最易被低估的功能。它不是简单的“谁在什么时候用了Copilot”，而是一份结构化的、可关联的、高保真的行为全息影像。要真正用好它，必须掌握三个关键维度：

1. 核心日志源：CopilotActivity事件类型：这是所有Copilot相关活动的总入口。在Microsoft 365 Compliance Center > Audit的搜索界面中，将“活动”筛选器设为CopilotActivity。此时，你会看到海量的日志条目，每一条都包含丰富的字段：

   • UserId: 发起请求的用户。
   • Operation: 具体操作，如CopilotGenerateResponse（生成响应）、CopilotSummarizeDocument（总结文档）、CopilotExtractData（提取数据）。
   • ObjectId: 被操作对象的唯一ID，如被总结的Word文档的GUID。
   • ClientIP: 用户发起请求的IP地址，可用于地理位置分析。
   • ResultStatus: 操作结果，Success或Failure，失败原因会记录在ResultDetails字段中。

2. 深度关联：打通“人-事-物”链条：单看CopilotActivity日志是片面的。真正的力量在于关联。例如，当发现一条CopilotSummarizeDocument失败日志时，其ObjectId指向一个SharePoint文件。你可以立即将该ObjectId复制，粘贴到SharePoint的审计日志搜索中，查看该文件在同一时间段内的所有访问记录（谁下载了它？谁修改了它？）。同样，你也可以将UserId粘贴到Entra ID的登录日志中，查看该用户当时的登录状态和设备信息。这种跨服务的关联分析，是定位问题根源的唯一途径。

3. 自动化洞察：用KQL查询语言挖掘深层风险：合规团队不应满足于手动翻查日志。必须学会使用Kusto Query Language（KQL）编写自动化查询。以下是我日常使用的两个高价值查询示例：

   • 查询“高危Copilot活动”：

     AuditLogs | where TimeGenerated > ago(7d) | where Operation == "CopilotGenerateResponse" | where ResultStatus == "Success" | extend SensitiveInfo = extract("SensitiveInfo: ([^;]+)", 1, ResultDetails) | where isnotempty(SensitiveInfo) | project TimeGenerated, UserId, ObjectId, SensitiveInfo, ClientIP | order by TimeGenerated desc

     此查询会找出过去7天内，所有成功生成且被系统识别出包含敏感信息的Copilot响应，是风险排查的黄金起点。

   • 查询“Copilot权限滥用”：

     AuditLogs | where TimeGenerated > ago(30d) | where Operation startswith "Copilot" | summarize ActivityCount=count() by UserId | where ActivityCount > 1000 | join ( EntraIDSignInLogs | where TimeGenerated > ago(30d) | summarize LoginCount=count() by UserPrincipalName ) on $left.UserId == $right.UserPrincipalName | extend Ratio = ActivityCount * 1.0 / LoginCount | where Ratio > 5 | project UserId, ActivityCount, LoginCount, Ratio | order by Ratio desc

     此查询会找出那些Copilot活动次数远超其登录次数的异常用户，极有可能是脚本滥用或账号被盗，是内部威胁检测的利器。

提示：审计日志默认保留90天，但对于金融、医疗等强监管行业，我强烈建议在Purview中配置“长期保留策略”，将Copilot相关的CopilotActivity日志单独归档并保留至少7年。这是应对监管问询的终极凭证。

5. 实战排错：一次“Copilot无法访问共享文件”的完整排查链路

理论再完美，也抵不过生产环境里一个真实的报错。我将以一个高频、棘手、且极具代表性的故障为例，完整还原一次“精准把控”边界的实战排错过程。这个案例不仅教你如何解决问题，更教会你如何思考——因为每一个Copilot访问失败，都是其背后数据治理链条上某一个环节的无声报警。

5.1 故障现象：用户A的“绝望三连问”

用户A（市场部总监）向IT支持提交了一张工单，标题是：“Copilot在我电脑上完全失灵！”。具体内容是：

1. 在Outlook中，她无法让Copilot总结任何一封带附件的邮件。
2. 在Teams中，她点击“Copilot”按钮后，界面一直显示“正在加载...”，最终超时。
3. 在SharePoint中，她打开一个名为“Q2-Marketing-Plan.docx”的文件，右键菜单里根本没有“让Copilot帮我...”的选项。

这“绝望三连问”看似是Copilot本身的问题，但经验告诉我，这几乎100%是数据访问边界配置的连锁反应。我的第一反应不是重启服务，而是立刻打开Purview门户，准备一场“外科手术式”的排查。

5.2 排查链路：从表象到根因的五步法

我遵循一套标准化的五步排查法，每一步都对应一个潜在的边界失效点：

第一步：确认Copilot服务状态与用户许可

• 操作：登录Microsoft 365 Admin Center > Billing > Your products，确认用户A的许可证中是否包含“Microsoft 365 Copilot”。
• 发现：许可证正常，且状态为“Active”。
• 结论：排除许可问题，进入下一步。

第二步：检查敏感度标签的全局状态

• 操作：导航至Purview > 数据治理 > 敏感度标签，检查所有标签的状态。重点看“发布状态”列。
• 发现：所有标签状态均为“已发布”，但注意到内部标签的“发布位置”只包含了“SharePoint”和“OneDrive”，唯独缺少了“Exchange Online”。
• 推论：这是一个重大线索。用户A的问题始于Outlook邮件，而邮件是Exchange Online的核心载体。如果内部标签未在Exchange Online发布，那么所有邮件（无论是否带附件）都无法被应用标签，Copilot也就失去了读取它们的“通行证”。
• 验证：我让支持同事用管理员账号，给用户A发送一封测试邮件，并在邮件正文中插入一个内部标签的Word附件。然后，我登录用户A的账户，在Outlook中打开该邮件，右键点击附件，发现“应用敏感度标签”选项是灰色的——证实了推论。

第三步：验证DLP策略的“误伤”

• 操作：在Purview > 数据治理 > 数据丢失防护中，检查所有启用的策略。特别关注那些作用于“Exchange Online”的策略。
• 发现：找到一个名为“Block External Sharing”的策略，其规则是：“当邮件包含敏感信息类型‘Email Address’且收件人包含外部域名时，阻止发送”。该策略的“位置”设置中，错误地勾选了‘Microsoft 365 Copilot activities’。
• 推论：这个配置是灾难性的。它意味着Copilot在尝试读取任何一封包含邮箱地址的邮件（这几乎是所有商务邮件）时，都会被该DLP策略拦截，因为它错误地将Copilot的“读取”行为，判定为“向外发送”的违规行为。
• 验证：我暂时禁用该策略，然后让用户A重试。她立刻能成功让Copilot总结邮件了！但Teams和SharePoint的问题依旧存在，说明还有其他问题。

第四步：检查IRM加密密钥分发

• 操作：在Entra ID > Protection > Conditional Access中，检查是否有策略阻止了用户A的设备获取ARM密钥。同时，在Purview > 数据治理 > 敏感度标签中，检查内部标签的“权限”设置，确认其“允许访问人员”列表中是否包含了用户A所在的AD安全组。
• 发现：一切正常。但当我检查用户A的本地OneDrive同步客户端日志时，发现大量Failed to acquire RMS license错误。
• 推论：用户A的设备（一台Windows 10笔记本）由于长期未连接公司VPN，其本地证书存储区中的ARM根证书已过期，导致无法与Azure RMS服务完成密钥协商。Copilot在尝试读取OneDrive中的文件时，因无法解密而失败。
• 验证：我远程指导用户A运行certmgr.msc，删除所有过期的“Microsoft RMS”证书，然后重启OneDrive客户端。问题解决。

第五步：排查SharePoint的“Copilot按钮消失”之谜

• 操作：既然Outlook和OneDrive问题已解决，但SharePoint的Copilot按钮仍不显示，这指向了SharePoint自身的配置。
• 发现：在SharePoint Admin Center > Settings > Advanced settings中，我发现“Copilot for SharePoint”功能被管理员设置为了“Off”。
• 推论：这是一个全局开关。即使用户许可、标签、DLP、IRM全部正确，只要这个开关关闭，SharePoint页面上就不会渲染Copilot按钮。
• 验证：我将该设置改为“On”，并等待15分钟（策略同步时间）。用户A刷新页面，Copilot按钮赫然出现。

5.3 经验总结：边界失效的“五大元凶”

这次排错，让我再次深刻体会到，Copilot的“数据访问边界”是一个极其脆弱的系统工程。任何一个环节的疏忽，都会导致整个链条断裂。根据多年实战，我将导致Copilot访问失败的最常见原因，总结为“五大元凶”：

元凶	表现症状	根本原因	快速诊断命令/路径
元凶一：标签未发布	Copilot对所有文件/邮件“视而不见”	敏感度标签未在对应服务（Exchange/SharePoint/OneDrive）中发布	Purview > 敏感度标签 > 查看各标签的“发布位置”
元凶二：DLP策略误配	Copilot在特定场景下报错或超时	DLP策略错误地将Copilot活动纳入其作用范围	Purview > DLP > 策略详情 > 检查“在Copilot活动中应用此策略”是否被勾选
元凶三：IRM证书失效	Copilot能读取文件，但生成内容无法打开或报错	用户设备本地ARM证书过期或损坏	运行certmgr.msc，查找并删除过期的“Microsoft RMS”证书
元凶四：SharePoint开关关闭	SharePoint页面无Copilot按钮	SharePoint Admin Center中“Copilot for SharePoint”功能被禁用	SharePoint Admin Center > Settings > Advanced settings
元凶五：用户组权限变更	Copilot对部分文件可访问，对另一些不可访问	用户被移出敏感度标签所指定的“允许访问人员”安全组	Entra ID > Groups > 查看对应安全组的成员列表

这个排查链路的价值，不在于解决了一个问题，而在于它建立了一套可复用的思维范式：永远从最上游（标签）开始，逐层向下（DLP->IRM->服务开关->用户权限）验证，用日志和工具代替猜测。这才是“精准把控”最务实的注脚。