Microsoft 365、Copilot 与安全控制面

上一篇讨论了身份、资源与账单边界。本文进一步梳理 Microsoft 365 工作负载自身的授权体系、它与 Azure 的交界、Copilot 的数据访问范围，以及 Sentinel、Purview、Defender、Intune 等安全与管理服务。

一、M365 的认证体系：一个身份，多个授权层

M365 是一组工作负载——Exchange Online、SharePoint Online、OneDrive、Teams、Office 应用。它们的认证没有自己的一套：登录、MFA、条件访问、令牌签发，全部由上一篇讲过的 Entra 租户承担。M365 特有的是授权层，而且不止一层。

Microsoft 365 包含多套独立发展的基于角色的访问控制系统，各自面向不同工作负载。Exchange 角色组、SharePoint 站点权限和 Teams 策略并不共享一套授权模型；Entra 管理中心提供部分统一管理入口，但不能替代各服务自身的权限视图。

Entra 内置角色按作用范围分三类。第一类是 Entra ID 专属角色，只管目录里的东西，比如用户管理员、应用管理员；第二类是服务专属角色——为 M365 各服务在 Entra 里定义的角色，Exchange Administrator 管邮箱、Intune Administrator 管设备策略、SharePoint Administrator 管站点集、Teams Administrator 管服务；第三类是跨服务角色，Global Administrator 与 Global Reader 被多个 M365 服务承认，Security Administrator、Security Reader、Compliance Administrator 横跨多个安全与合规服务。Exchange Administrator 在 Entra 里的角色与 Exchange RBAC 系统中的 Organization Management 角色组有对应关系——同一份权限，两个入口；具体权限仍按当前角色定义核对。

在 Entra 角色之下，每个工作负载还有自己的内部体系：Exchange 的角色组与管理角色、SharePoint 按站点/库/条目层层继承的权限模型、Teams 的策略与外部访问配置。再往下是应用同意层——应用获授 Graph 应用权限后，可以不依赖某个具体用户而以应用身份访问对应 API；有效范围取决于权限类型、管理员同意与可用的资源范围控制。最底下是设备层：Intune 的合规状态写回设备对象，条件访问把它当访问决策的信号。

评估 M365 访问时，应分别检查 Entra 角色、工作负载自身的权限模型、应用同意（Graph 权限），以及由 Intune 提供并由条件访问评估的设备合规信号。合并这些视图后，才能判断账号及应用的实际有效权限。

Entra 管理中心提供 M365 权限的部分入口，但并不覆盖全部授权。Exchange 角色组、SharePoint 站点权限、Teams 策略和 Graph 应用同意都需分别审查；目录中未发现高权限角色，并不能证明工作负载中不存在高权限。

二、M365 与 Azure：同一目录，两套体系

M365 与 Azure 共享身份平面，但授权平面各自独立。两边可以使用同一个 Entra 租户及其用户、组、应用与设备；Azure 资源由 Azure RBAC 管理，M365 工作负载则由各服务的权限模型管理。订阅 Owner 不因此获得邮箱权限，Exchange Administrator 也不因此获得虚拟机权限。

在此之上有一批横跨两边的关联体系：

• 身份与策略：条件访问在 Entra 里定义，目标应用既可以选 M365 的 Exchange、SharePoint，也可以选 Azure 管理 API——同一份策略同时约束两个平面。设备合规这条信号链也是横跨的：Intune 上报合规，Entra 评估，两边同时生效。
• API：Microsoft Graph 是 M365 的统一 API（也是 Copilot 的取数通道），Azure 资源管理走 ARM API。Graph 也暴露部分 Azure 目录信息，但资源操作仍以 ARM 为准。
• 合规平面：Purview 覆盖 M365 内容（Exchange、SharePoint、OneDrive、Teams），并为部分 Azure 数据源提供分类、标签或治理能力；具体支持范围取决于数据源与功能。
• 安全平面：Defender XDR 防护 M365 的邮件、身份与端点，Defender for Cloud 防护 Azure 资源，Sentinel 把两边的数据都收进一个工作区。
• 设备平面：Intune 是 M365 的端点管理服务，但设备对象注册在 Entra，合规信号喂给条件访问，条件访问又同时管 M365 与 Azure。

还有一个容易被忽略的结构性事实：M365 的许可挂在用户与租户上，不依赖 Azure 订阅；但 Sentinel、Defender for Cloud 这类安全服务跑在 Azure 订阅里。一个纯 M365 的组织，它的安全栈也往往跨进了 Azure 订阅的边界——“M365 租户的安全运营”与“某几个 Azure 订阅”是绑在一起的。计费树（上篇）同样各自独立：M365 有自己的商业订阅，Azure 走自己的计费账户。

                 ┌─────────────────────────────┐
                 │   Entra 租户（身份平面）      │
                 │  用户 / 组 / 应用 / 设备 / CA  │
                 └───────┬─────────────┬───────┘
                         │             │
        ┌────────────────▼──┐      ┌──▼────────────────┐
        │  M365（数据平面）    │      │  Azure（资源平面）  │
        │  Exchange/SP/Teams │      │  订阅/管理组/资源    │
        │  Graph API         │      │  ARM + Azure RBAC  │
        └────────────────┬──┘      └──┬────────────────┘
                         │             │
         ┌───────────────┴─────────────┴──────────────┐
         │   安全与管理平面（横跨两边）                  │
         │   Defender XDR · Sentinel · Purview · Intune │
         └─────────────────────────────────────────────┘

三、M365 服务的访问通道

每一类通道都是官方功能；理解它们的存在比记住任何具体命令都重要。按“数据怎么出来”给每个工作负载归位，并标出各自的审计口径。

3.1 Exchange Online：三条读取通道

邮箱数据有几类彼此独立的官方访问通道。第一类是委托访问：用户把自己的邮箱或日历委托给别人，或被加入有邮箱权限的组。第二类是应用访问：应用可通过 Graph 应用权限以应用身份访问邮件；权限通常由租户管理员同意，默认授权范围可能覆盖租户内邮箱，但 Exchange Online 的 RBAC for Applications 等范围控制可以限制访问。第三类是合规管理员通道：Purview 的 eDiscovery Manager 可在组织范围内搜索其获授权的内容位置并导出结果，具体范围受案例成员身份、角色和搜索权限过滤等配置限制。Exchange Online 的 ApplicationImpersonation 管理角色已于 2025 年 2 月退役，不应再当作现行通道；存量遗留应用要单独核查迁移状态。

三条通道的审计口径完全不同。委托访问是配置问题，审计对象是逐邮箱的委托与权限记录。应用访问是凭据与同意问题：一把被管理员同意过的应用凭据可以在不触发任何用户侧登录异常的情况下访问邮件，作用范围只受同意与范围控制约束——盘点时问的不是“有没有登录”，而是“这个应用被同意到哪一步”。管理员通道最直接也最显眼：eDiscovery 的搜索与导出在审计里留痕很重，但它按设计就是成规模的筛选与导出能力，异常与否取决于基线，而不是动作本身。

另外，邮箱规则与转发设置是工作负载自己的配置面：收件箱规则可以在邮箱所有者不做任何操作的情况下把内容转发出去，或把特定发件人（安全告警、财务邮件）静默归档。它们不出现在目录角色里，是权限盘点时必须单独覆盖的配置面——清点口径是逐邮箱查规则与转发，而不是查目录日志。

3.2 SharePoint 与 OneDrive：继承与共享

SharePoint 的权限模型按站点、库、条目层层继承，任何一层都可以断开继承自定义权限。这个设计的代价是“权限债”：多年来按项目临时共享出去的链接、拉进来的 guest、断继承后没人回收的授权，全部沉淀在站点里。应用面对应的是文件类的 Graph 应用权限（Files、Sites 系列）。外部共享的形态——任何人链接、特定 guest、组织内链接——决定了每一份内容的实际可见面。

权限债就是“合法可见面”：不需要提权，只需要找到一个被过度授权的普通用户或应用，搜索与 AI 汇聚会替他把可见面里的东西全部翻出来。审计可见面必须用用户自己的权限视角（而不是管理员视角）去枚举可见的站点与文件——两者经常差出一个数量级。清点“任何人链接”与断继承站点，是 Copilot 上线前必须完成的功课。

3.3 Teams：跨组织的边缘

Teams 的策略面里，与边界相关的主要是三块：与外部组织的联邦、guest 邀请、共享频道。共享频道尤其值得注意——它依赖上一篇讲过的跨租户访问设置，等于在两个租户之间开了一条内容级的通道，边界的宽窄完全由两边的信任配置决定。应用面则是频道消息类的 Graph 应用权限。Teams 还补上了邮件审计里看不到的一块协作图：共享频道里的内容与成员关系，往往能还原出组织里谁和谁在做什么。

3.4 Graph 应用权限：通用钥匙

把上面几个服务放在一起看，同一个模式反复出现：应用注册、授予同意、凭据换 token、以应用身份访问工作负载。Graph 应用权限是 M365 上的重要访问面——获授 Mail.Read 或 Files.Read.All 并完成管理员同意的应用，通常能访问相应 API 的组织数据；实际范围还可能受 Exchange 应用 RBAC、应用访问策略或具体 API 能力约束。应用凭据本身不自动等于全租户数据权限，但“被同意的权限 + 一把凭据”的组合就是这个应用的真实作用面。

这把钥匙的发放门槛是同意体系：哪些应用允许用户自行同意、哪些必须管理员同意、同意时的审核流程——这些配置决定了“同意钓鱼”面对的是一扇门还是一堵墙。具体形态很固定：诱导用户对一个伪装成生产工具的应用授权，拿到的是用户级权限；诱导管理员同意，拿到的是应用级权限，且默认作用面更宽。权限的粒度、有效期的长短、凭据的轮换，共同决定这把钥匙被复制后的暴露窗口。

盘点 M365 的应用面固定查三样：租户里被同意的第三方应用列表（尤其是拿到 Mail.Read、Files.Read.All 这个级别权限的）、应用注册上有没有近期新增的凭据（证书比 secret 更不显眼）、以及同意策略是否允许用户自助同意。给别人的应用注册补一个凭据，是不新增对象的最安静持久化之一。

3.5 审计与取证

Purview Audit 记录多个 M365 工作负载及受支持功能的活动，是这一节所有通道的事后观测面，但不保证记录每一种操作或完整权限状态。审计本身也是一个管理面：日志保留策略、搜索权限、导出权限都是配置。eDiscovery 的搜索与导出既是取证通道，也是一条把内容批量带出组织的官方出口——能力与风险是同一件事的两面，控制它的手段是角色、案例成员资格、范围过滤与审计。不同工作负载的审计事件覆盖与保留时长并不一致，评估“有没有留下痕迹”要按工作负载分别核对。

评估 M365 的暴露面，四层授权（Entra 角色、工作负载 RBAC、应用同意、设备合规）加上审计配置，缺一层就是盲区。统一审计日志是横跨这四层最重要的观测点；做访问审查时先按工作负载把审计覆盖列一遍，再判断哪条通道的痕迹最薄。

四、Copilot：AI 体系的取数边界与风险面

4.1 Copilot 如何取数

Copilot 的架构拆成四件事。第一，Copilot 的价值来自把大语言模型连接到组织数据，而它访问内容与上下文的通道是 Microsoft Graph——用户文档、邮件、日历、聊天、会议、联系人都在 Graph 里。第二，语义索引为 Copilot 提供检索的 grounding 数据，它按用户意图扩展检索范围，并且遵守用户权限。第三，有一条用加粗写下的安全边界：Copilot 只呈现单个用户至少拥有查看权限的组织数据——支撑这个边界的是 M365 各服务自己的权限模型（包括共享频道这类跨租户协作给出的权限）。第四，扩展性：智能体（agents）与 Graph 连接器把组织外部与第三方数据接进 Copilot 的可及范围；启用智能体后，Copilot 会代表用户向智能体发起查询。

隐私侧：提示、响应与经 Graph 访问的数据不会被用来训练基础大模型；Copilot 的交互数据与组织在 M365 的其他内容按同样的契约边界处理。防护侧，内置措施包括对提示注入（越狱）类攻击的拦截与有害内容的拦截。

4.2 风险面：五条

Copilot 的风险面几乎全部由“既有权限体系 + 新的数据汇聚与执行层”组合而成，拆成五条。

第一条是权限放大。Copilot 不改变权限，它改变的是汇聚速度：一个高可见度的身份（高管助理、IT 与合规类角色、被过度授权的普通用户），过去要靠人工翻 SharePoint 和邮箱才能拼出的情报，现在一句提示就能完成聚合。目标价值因此从“找数据”转移到“找身份”——谁的可见面大，谁就是 Copilot 场景里的高价值对象。防范重心跟着转移：高可见度身份的权限收敛，优先级高于普通用户。

第二条是权限债的兑现。既然 Copilot 只呈现用户有权查看的内容，那么它暴露的其实就是组织多年沉淀的过度共享：开了“任何人”链接的站点、断继承后没人管的库、随手拉进来的 guest。用 M365 服务的权限模型确保正确的人访问正确的内容——这句防御原则反过来读，就是 Copilot 数据面的全部内容。审计 Copilot 的暴露面，等价于审计整个权限模型。

第三条是间接提示注入。Copilot 的 grounding 会把用户有权访问的内容带进提示上下文，于是文档、邮件或 Teams 消息中的恶意指令可能影响模型输出或后续处理。注入的候选载体不需要什么高深技术——隐藏文本、批注、文档元数据、图片替代文字，凡是 Copilot 能读到、而用户肉眼不会注意的角落都算。提示注入防护是纵深防御的一层，不代表对所有攻击免疫。可能的影响取决于产品、连接身份和可用能力：从误导回答、呈现用户有权访问但不应被汇总的信息，到在具备动作能力且授权允许的智能体中触发非预期操作。

第四条是智能体与连接器——新的数据访问与执行面。智能体不一定拥有独立服务身份：它可根据产品类型和配置，以用户委托身份、连接所有者身份或应用身份访问数据或调用操作。Graph 连接器把外部数据接入 Graph，并需正确配置访问控制与安全裁剪。于是评估一个组织的 AI 面，就变成清点这些新身份与连接：谁创建了哪些智能体、它们以什么身份运行、连了哪些数据源、凭据怎么管、权限谁审。AI 体系没有发明新的权限模型，但它把“清点服务账号与连接”这件老工作放大出一个增长极快的新入口——不能把所有智能体都概括成新的服务账号，但每一个都值得按服务账号的标准盘一遍。

第五条是从 Copilot 到 Azure 与本地。Microsoft 365 Copilot 的原生 M365 grounding 不会因为用户使用 Copilot 就自动获得 Azure RBAC；但智能体、插件或连接器可以按其配置连接外部服务或 API。跨到 Azure 或本地的能力取决于连接所用身份、授权和配置，而不是简单由 Graph 一条边界决定。结合上篇的结论：Copilot 是汇聚加速器，不是边界突破器——它加速汇总已有权限可访问的数据，而通向 Azure 与本地的路仍然是身份与凭据（Entra 角色、Graph 权限、Azure RBAC、混合链）。

Microsoft 365 Copilot 对组织数据的访问通常遵循用户现有权限；扩展智能体和连接器的行为还取决于其身份与连接配置。它会更快汇总用户可访问的数据，因此权限审计与扩展配置都是必需项——权限审计从可拖延的工程，变成了随时会被一句提示兑现的债。

4.3 观测面

Microsoft Purview Audit 会记录受支持 Copilot 与 AI 应用的交互事件，包括用户、时间、交互位置及访问资源等信息；Copilot 交互审计记录还可包含提示与响应消息信息。实际可检索内容、保留期限及 eDiscovery 可用性取决于具体 Copilot 产品、许可、审计配置和适用的保留策略——不能假设所有 AI 交互都以相同方式或期限保存。微软也提供面向 AI 场景的数据安全治理能力（DSPM for AI）。AI 交互有日志可查，但“有日志”不等于“查得到”——做合规审查时要按产品的审计覆盖与保留期分别核对。

五、安全栈拆解：Sentinel、Purview、Defender、Intune

5.1 Microsoft Sentinel

Sentinel 是云原生 SIEM，在多云多平台环境里提供可扩展、高性价比的安全能力，结合 AI、自动化与威胁情报支撑威胁检测、调查、响应与主动狩猎。

它与 Azure 的关系是：Sentinel 是 Azure 服务，数据存储在 Log Analytics 工作区；启用和管理权限取决于工作区、订阅与 Sentinel 的角色配置。它与 M365 的关系靠数据连接器：Entra ID、Azure Activity、M365 审计、Defender 告警等可以通过连接器送入工作区。Sentinel 已在 Defender 门户正式可用；截至本文更新时，Azure 门户体验计划于 2027 年 3 月 31 日后停止支持。自 2025 年 7 月起，符合条件的新客户工作区会在启用 Sentinel 时自动接入 Defender 门户；相关条件包括订阅 Owner 或 User Access Administrator 权限，且不是 Azure Lighthouse 委托用户。Defender 门户中的安全访问可由统一 RBAC（URBAC）管理，Azure 资源本身仍受 Azure RBAC 控制。

两个必须记住的细节。其一，角色分配是累积的——一个同时持有 Sentinel Reader 与（Azure）Contributor 的用户，实际权限可能超出预期；清点 Sentinel 的权限不能只看 Sentinel 专属角色，要并上 Azure 侧的通用角色与 Log Analytics 角色。其二，数据完整性：Sentinel 继承 Azure Monitor 的防篡改与不可变实践，Azure Monitor 是仅追加的数据平台，但为合规目的保留了删除条款——日志不是绝对动不了，删除的通道存在，只是被设计得很窄。此外 Sentinel 支持 Lighthouse 跨租户管理，托管安全服务这个形态本身也是一条需要识别的跨租户通道。

Sentinel 的权限价值分两条线。一条是取证：持有相应读取权限时，工作区查询是最快的“历史复盘”入口——登录日志、告警、实体关系一次查完。另一条是规则面：持有 Sentinel Contributor 及以上角色的人可以改分析规则、关规则、删事件、改自动化规则与 playbook。被改了阈值的分析规则比没有告警更危险，因为它看起来还在工作；而“改规则”这个动作本身，只有被另一层监控（对 Sentinel 自身的变更审计）覆盖时才会暴露——这正是“检测的检测”该覆盖的位置。

5.2 Microsoft Purview

Purview 是合规平面，解决方案覆盖统一审计、eDiscovery（标准与高级）、DLP、内部风险管理、通信合规、数据生命周期与记录管理，以及面向 AI 的数据安全治理。内部风险管理的定位：关联多种信号以识别潜在恶意或无意内部风险（知识产权窃取、数据泄露、违规行为），默认对用户做假名化，配合 RBAC 与审计日志实现隐私设计。

权限侧的事实：Purview eDiscovery Manager 角色组可让成员在组织范围内搜索其获授权的内容位置并导出结果，具体权限受案例成员资格和搜索范围过滤等设置约束。应用专用认证运行 Security & Compliance PowerShell 的 eDiscovery cmdlet 属于不支持的场景；Microsoft 建议在可用时迁移到 Microsoft Graph API，现存自动化说明只能作为尽力而为的兼容指导。Entra 内置角色 Purview Workload Content Administrator 可从 Purview 门户管理或清除 M365 数据；这一高权限角色也应纳入最小权限和审计范围。

Purview 的关键词是“批量”与“合规出口”。eDiscovery 的搜索与导出按设计就是要把内容成规模地筛出来交给人——一个拿到 eDiscovery Manager 的身份，可以不碰任何邮箱或站点权限就完成成规模的内容导出；导出本身是审计事件，但“导出”这个动作在大型组织里并不罕见，异常与否取决于基线。反方向的清单同样具体：DLP 与保留策略覆盖哪些通道、豁免了哪些账号，决定了 M365 侧数据面的剩余宽度——这些策略配置本身也是需要纳入治理的资产。

5.3 Microsoft Defender XDR

Defender XDR 是统一的击前击后企业防御套件，原生集成端点、身份、邮件与应用。拆开是几个组件：Defender for Endpoint（端点检测与响应，Live Response 提供远程会话——基础命令包括列目录、列进程、下载文件，高级命令包括网络隔离、运行脚本库中的 PowerShell、采集取证包、清除实体，高级命令受角色控制）；Defender for Office 365（邮件安全）；Defender for Identity（在本地 AD 部署传感器，把上一篇那些 Kerberos 与身份攻击的检测接进云端门户——本地与云在这里交汇）；Defender for Cloud Apps（SaaS 与影子 IT）；Azure 侧另有 Defender for Cloud。

它与其他服务的集成关系构成一张网：与 Sentinel 用连接器互通告警；与 Intune 互通设备管理与策略下发（安全设置管理允许在 Defender 门户管理安全策略而无需完整 Intune 注册）；与条件访问互通——Defender for Endpoint 的设备风险信号进入条件访问评估，把“端点安全状态”变成访问控制信号。

Defender XDR 最值得先记住的是 Live Response 的双面性：它的高级命令就是一套受控的远程执行能力——在授权角色手里是调查工具，在失陷的同等权限手里就是“通过官方通道在端点执行脚本、取文件、采集取证包”的通道，甚至包括把设备从网络隔离。检测侧对应的是 Defender 角色分配与 Live Response 会话记录，是很有分量的事件。另一个单独值得注意的组件是 Defender for Identity——它的传感器在本地 AD，意味着上篇里 Kerberos 票据与委派那几节的手法在这里有对应的告警名；它的安全评估项（包括对 AZUREADSSOACC 委派配置的检查）恰好就是上篇“委派盘点”那四处的官方巡检清单。做混合链评估时，把 MDI 的检测矩阵放在手边，逐条对一下要审计的手法会落在哪个阶段。

安全栈的控制面本身就是高价值目标：能改 Sentinel 分析规则的人能制造盲区，能操作 Defender 与 Intune 的人握着隔离与设备动作，能管 Purview 的人掌握审计与证据。清点这些角色（URBAC、Sentinel Contributor、Defender 门户角色、Intune RBAC、Purview 角色组）与清点业务权限同等重要。

5.4 Intune 与 MDM

先把概念分开：MDM（移动设备管理）是一种能力——设备注册、策略下发、合规上报；Intune 是微软的 MDM 实现，同时也是 M365 的端点管理服务。像 Intune 这样的 MDM 方案可以设定设备必须满足的规则并上报合规状态，这就是合规策略；把合规策略与条件访问结合后，就能要求设备满足安全要求才能访问组织数据。

条件访问那一侧的信号清单是：用户或组成员身份、IP 位置信息、设备细节（合规或配置状态）、应用细节（是否要求受管应用）、以及配合移动威胁防御伙伴的实时与计算风险检测。Intune 对这套体系的贡献，是给这个能力加上移动设备合规与移动应用管理数据。

Intune 的管理动作叫设备动作：擦除、停用、删除、远程锁定、重启、重置密码、远程协助——具体动作因设备平台和管理状态而异，每一种都受 Intune RBAC 角色、权限与范围约束。与 Entra 的关系：设备对象在目录里，注册发生在 Entra，合规状态写回设备对象，条件访问在 Entra 里启用。与 Defender 的关系上一节说过：设备风险接条件访问，Intune 负责部署与策略。

Intune 有两条值得单列的治理面。其一是“下发能力”：Intune 的脚本与配置下发机制本身就是一条官方的代码投递通道——控制它的人可以在受管设备上执行代码，而这类动作在端点日志里未必显眼。其二是“合规姿态”：能改合规策略或设备记录的人，可以改变设备进入组织数据的门槛——让不合规的设备看起来合规。前者是横向移动与驻留的候选通道，后者是绕过设备条件访问的候选通道，两条都应写进影响评估，而不是只写“拿到了控制台权限”。

5.5 拆解之后

四个服务放进同一张图，就是第二、三节的平面图加上执行层：Sentinel 站在 Azure 订阅里观测两个平面；Purview 站在合规平面横跨两边的内容；Defender XDR 站在防护平面横跨端点、邮件、身份与本地 AD；Intune 站在设备平面把终端状态翻译成条件访问的信号。它们互不隶属，靠连接器与共享的 Entra 身份平面咬合。这层拆解的价值在于：每进入一层，掌握的不止是“更多数据”，而是“别人看数据的眼睛”——观测面本身也是需要治理的领地。

六、核验清单：M365 与安全栈

按层把值得核验的配置与通道排一遍，全部是前面各节展开过的机制的名字化版本，逐项在环境中验证“存在或不存在”：

• 身份层：密码喷洒与令牌重放的暴露面、设备代码钓鱼的同意面、PRT 保护（上篇）、同意钓鱼的门与墙（用户级与管理员级）、应用注册凭据的新增与轮换记录、PIM 激活策略。
• 邮箱层：Graph 应用权限的实际授权范围（受范围控制约束）、收件箱规则与转发配置、eDiscovery 的案例范围与导出基线、委托与邮箱权限的分布。
• 文件层：Graph 文件权限的授权范围、站点集管理员清单、“任何人链接”与 guest 清单、断继承站点清单、以用户视角重测的可见面。
• 协作层：共享频道的跨租户访问设置、Teams 联邦与 guest 策略、频道消息类应用权限。
• AI 层：隐藏文本/批注/元数据/替代文字这类注入载体的处理策略、智能体身份与连接清单、连接器数据源清单、Copilot 审计记录的覆盖与保留。
• 安全栈层：Sentinel 分析规则的变更审计、playbook 的权限边界、工作区查询的读取权限分布、Purview eDiscovery 的导出基线、Defender Live Response 的角色分配与会话记录、Intune 脚本下发与合规策略的变更管理。

这张清单不是操作手册，是做环境盘点时的对照表：每一项在目标环境里要么存在、要么不存在，不存在本身就是一条结论。

七、收束：从 M365 到 Azure 到本地

两篇合起来，完整的访问与审查链收在一处：

（身份入手）
   用户 / 应用凭据 / 设备（PRT）
        │
        ├─ Entra 角色 ──► 目录与安全栈控制面（GA→elevateAccess→Azure）
        ├─ Graph 应用权限 ──► 经同意的 M365 API 数据（范围取决于权限与资源范围控制）
        ├─ 工作负载 RBAC ──► eDiscovery 导出 / 委托 / 站点管理
        │        └─► Copilot：可见面的一次性兑现（放大器，不是新边界）
        ├─ Azure RBAC ──► 资源平面（托管标识 / IMDS / 订阅）
        └─ 混合链 ──► PHS / PTA / ADFS / SSO / 委派 ⇄ 本地域控（见上篇）
（观测与审查）
   Sentinel（Azure 订阅里的工作区）· Purview（审计/eDiscovery）· Defender（URBAC/Live Response）· Intune（设备动作）

本篇的要点收成下面十几句：

• M365 的认证主要由 Entra 承担；访问评估要分别看 Entra 角色、工作负载权限、应用同意，以及条件访问使用的设备合规信号。
• M365 与 Azure 共享身份平面，各自拥有授权平面；安全栈横跨两边，且往往住在 Azure 订阅里。
• Graph 应用权限是 M365 的重要应用访问面；授权范围取决于具体权限和已配置的资源范围控制，评估时看“同意到了哪一步”而不是“有没有登录”。
• ApplicationImpersonation 已退役；应用访问邮箱走 Graph 应用权限加范围控制——旧角色残留是单独的清点项。
• Copilot 对组织数据的访问通常遵循用户现有权限；它不改变权限，只加速汇聚——暴露的是权限债。
• 间接注入的载体是“用户会读到的内容”：隐藏文本、批注、元数据、图片替代文字都算候选。
• 智能体与连接器增加了数据访问和操作面；它们使用的身份与权限取决于产品类型和配置，每一个都值得按服务账号的标准盘一遍。
• Copilot 不会自动授予 Azure RBAC；扩展组件能否访问 Azure 或本地资源取决于其连接身份与授权——Copilot 是放大器，不是边界突破器。
• Sentinel 工作区与数据访问涉及 Azure RBAC 与 Defender 门户的统一 RBAC，且角色分配是累积的；改规则比删日志更隐蔽。
• eDiscovery 是成规模的官方导出出口，范围受案例成员资格与搜索过滤约束；“导出”是否异常取决于基线。
• Defender for Identity 的传感器在本地 AD——本地票据与委派攻击在这里有对应的告警名，混合链评估要对表。
• Intune 的脚本下发与合规姿态是设备面通往数据面的两条正式通道。
• 访问链上每一环的观测点都在安全栈里；而安全栈自身的角色分配，就是这条链上最后一块需要治理的领地。

八、参考

本篇梳理所依据的原始文档，观点均以原文为准：

• Microsoft Learn：Understand roles in Microsoft Entra ID — https://learn.microsoft.com/entra/identity/role-based-access-control/concept-understand-roles
• Microsoft Learn：Microsoft Entra built-in roles — https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference
• Microsoft Learn：Feature permissions in Exchange Online — https://learn.microsoft.com/exchange/permissions-exo/feature-permissions
• Microsoft Learn：Role Based Access Control for Applications in Exchange Online — https://learn.microsoft.com/exchange/permissions-exo/application-rbac
• Microsoft Learn：Assign permissions in eDiscovery — https://learn.microsoft.com/purview/edisc-permissions
• Microsoft Learn：Microsoft Graph permissions reference — https://learn.microsoft.com/graph/permissions-reference
• Microsoft Learn：Data, Privacy, and Security for Microsoft Copilot — https://learn.microsoft.com/microsoft-365/copilot/microsoft-365-copilot-privacy
• Microsoft Learn：Audit logs for Copilot and AI applications — https://learn.microsoft.com/purview/audit-copilot
• Microsoft Learn：Semantic indexing for Microsoft Copilot — https://learn.microsoft.com/microsoftsearch/semantic-index-for-copilot
• Microsoft Learn：What is Microsoft Sentinel? — https://learn.microsoft.com/azure/sentinel/overview
• Microsoft Learn：Roles and permissions in the Microsoft Sentinel platform — https://learn.microsoft.com/azure/sentinel/roles
• Microsoft Learn：Learn about Insider Risk Management — https://learn.microsoft.com/purview/insider-risk-management
• Microsoft Learn：What is Microsoft Defender XDR? — https://learn.microsoft.com/defender-xdr/microsoft-365-defender
• Microsoft Learn：Microsoft Defender for Endpoint and other Microsoft solutions — https://learn.microsoft.com/defender-endpoint/threat-protection-integration
• Microsoft Learn：Investigate entities on devices using live response — https://learn.microsoft.com/defender-endpoint/live-response
• Microsoft Learn：Microsoft Defender for Identity overview — https://learn.microsoft.com/defender-for-identity/what-is
• Microsoft Learn：Get started with your Microsoft Intune deployment — https://learn.microsoft.com/intune/fundamentals/get-started
• Microsoft Learn：Conditional Access and Intune overview — https://learn.microsoft.com/intune/device-security/conditional-access-integration/overview
• Microsoft Learn：Troubleshooting device actions in Intune — https://learn.microsoft.com/troubleshoot/mem/intune/device-management/troubleshoot-device-actions
• Microsoft Learn：Retire devices action — https://learn.microsoft.com/intune/device-management/actions/retire