Microsoft 365 企业安全架构系列（一）：身份攻击面、Kill Chain 与 Zero Trust 基础模型

〇、本系列文章的全景

这是一个由若干章组成的连载，本篇是第 1 篇（总入口）。后续章节将分别展开：

篇	主题	对应 Learning Path 4 模块
1（本篇）	身份攻击面、Kill Chain 与 Zero Trust 基础模型	总入口
2	Conditional Access 深度设计（含 Authentication Strength）	Secure User Access
3	Microsoft Defender XDR 检测与响应实战	Defender XDR Security Solutions
4	Secure Score 度量落地	Microsoft Secure Score
5	Privileged Identity Management 与管理员安全模型	Privileged Identity Management
6	Microsoft Entra ID Protection 风险闭环	Microsoft Entra ID Protection
7	系列复盘 + MS-102 考点映射	Identity and Access 学习路径复盘

之所以先讲"威胁、攻击路径、Zero Trust 模型"，再讲"具体控制"，是为了避免按清单操作却理解不到原因------这是 MS-102 想升级你认知的地方。

一、背景：为什么身份与访问安全是 M365 的第一战场

M365 是典型的身份驱动型（Identity-Centric）SaaS 套件：

几乎所有业务负载（Exchange Online、SharePoint、Teams、OneDrive、Power Platform）都用同一个身份面（Microsoft Entra ID）；
攻击者拿到一个普通账号后，不需要打穿企业内网------直接在 Exchange Online / SharePoint 内完成"横向 → 提权 → 拿数据"；
攻击路径从"控制一台机器"变成"控制一个账号 + 滥用一个 OAuth 应用"；
与传统企业边界模型（防火墙 + VPN）相比，M365 的攻击面是身份 + OAuth + 数据 + SaaS 四维叠加。

其中：

身份（Identity）是控制平面（Control Plane）------账号被攻陷即等于控制权旁落；

OAuth 是现代 SaaS 环境下的权限委托（Permission Delegation）通道 ------用户点一次"Allow"，第三方应用即可在用户语境下读写 Mail / Files / Calendar，无须账号密码外泄。

理解这两层的层级关系（Identity → OAuth → Data Access），是 M365 架构师区别于传统管理员的核心认知。

复制代码

flowchart TD
    A["<b>Identity</b><br/>Entra ID<br/><i>Control Plane</i>"]
    B["<b>OAuth</b><br/>Permission Delegation"]
    C["<b>Data Access</b><br/>Mail / Files / Teams"]
    A --> B --> C

    style A fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px
    style B fill:#2b88d8,stroke:#005a9e,color:#fff,stroke-width:2px
    style C fill:#71afe5,stroke:#005a9e,color:#fff,stroke-width:2px

结论：M365 的"安全突破口"不在防火墙后，而在登录那一刻。整个安全栈的最小单位，是一个 Entra ID 账号 + 一个会话 + 一个接入路径。

二、攻击者目标与三类核心威胁

攻击者盯上 M365 租户，最终目标不外乎三类：

Compromise user accounts through email ------钓鱼、欺骗、恶意软件，把一个普通员工账号拿下；
Gain control over resources ------拿到账号后再升级权限（Elevation of Privilege），变成有"写入/删除"权限的管理员；
Compromise data ------再往上一步就是偷数据、删数据、把数据泄露到租户外（Data Exfiltration / Data Spillage）。

后续所有的 Conditional Access、PIM、Defender XDR、ID Protection、Purview，本质都是围绕这三个目标做 "最大化阻断 + 最小化横移 + 最小化数据外泄"。

三、身份与访问方向的威胁向量（Threat Vector）清单

M365 当前状态下的威胁向量是多维度叠加的：

维度	典型目标	M365 中能看到什么
身份	口令、MFA 因子、Refresh Token	钓鱼、Token 重放、OAuth 同意滥用
终端	笔记本、台式机、移动设备	EDR 漏配、ASR 没开、磁盘未加密
邮件/协作	Exchange、Teams、SharePoint	钓鱼邮件、Teams 外部消息滥用
OAuth 应用	Mail、Files、Calendar API	多权限应用被滥用、Consent Grant 钓鱼
数据	SharePoint 站点、OneDrive 内容	标签缺失、DLP 未覆盖、Retention 短
网络/位置	跨境登录、Tor	不可能出差、异常 ISP

关键判断

攻击面宽度决定了 Zero Trust 必须是多维的------只看网络位置、看身份、看设备都不够，要叠加。

四、两个相互补充的攻击模型：Cyber Kill Chain 与 MITRE ATT&CK

1. 两者不是同一个模型

这是工程师里常被混用的两个概念，需要先校准：

Cyber Kill Chain（Lockheed Martin, 2011） ：描述攻击生命周期 （7 个阶段，从 Reconnaissance 到 Actions on Objectives）。回答："攻击走到了哪一步？"
MITRE ATT&CK（2013--至今） ：描述攻击者具体使用的技术和行为 （Tactics / Techniques / Procedures, TTP）。回答："攻击者到底用哪一招？"

M365 安全分析里，二者通常结合使用：

复制代码

flowchart TD
    A["<b>攻击生命周期</b><br/>Cyber Kill Chain"]
    B["<b>阶段定位</b><br/>What step?"]
    C["<b>战术 Tactics</b>"]
    D["<b>技术 Techniques</b>"]
    E["<b>MITRE ATT&CK</b><br/>TTP 映射"]
    F["<b>Defender XDR Detection</b><br/>Microsoft Sentinel Rule"]

    A --> B
    B --> C
    B --> D
    C --> E
    D --> E
    E --> F

    style A fill:#d13438,stroke:#a4262c,color:#fff,stroke-width:2px
    style B fill:#ff8c00,stroke:#e07b00,color:#fff,stroke-width:2px
    style C fill:#ffb900,stroke:#e0a800,color:#333,stroke-width:2px
    style D fill:#ffb900,stroke:#e0a800,color:#333,stroke-width:2px
    style E fill:#107c10,stroke:#0b6a0b,color:#fff,stroke-width:2px
    style F fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px

用 Kill Chain 定位"攻击走到了哪一步"------决定在哪一段布防御；
用 ATT&CK 对应"Txxxx / TAxxxx"技术 ID------决定如何检测和响应；
Defender XDR / Microsoft Sentinel 可以通过 ATT&CK 映射帮助安全团队理解攻击技术；部分检测规则、威胁分析和 Hunting 场景会关联 ATT&CK 技术 ID（例如 T1078 Valid Accounts、T1567 Exfiltration Over Web Service）。

如果你只懂其中一个，写出来的告警规则会偏颇；高级安全的工程师用两个模型同时理解攻击。

2. Cyber Kill Chain 在 M365 上的阶段映射

Kill Chain 阶段	典型动作	M365 中能看到什么
Reconnaissance	子域枚举、员工名单收集	LinkedIn / 企查查 / 暗网员工邮箱列表
Weaponization	构造钓鱼信或带宏的文档	假冒 M365 安全中心、假冒 IT 升级通知
Delivery	邮件投递、Teams 外部消息	带链接/附件的邮件、Teams 外部共享
Exploitation	用户点击/打开/输入凭证	MFA Token 截取、Outlook 规则创建
Installation	部署持久化	后台进程、键盘记录器、恶意 Outlook 规则
Command & Control	C2 上线、内网横向移动	异常出站连接、横向滥用 OAuth
Actions on Objectives	数据外泄/加密/破坏	OneDrive 批量下载、Exchange 规则异常、勒索加密 SharePoint

M365 的特殊性 ：传统企业里"横向 → 提权 → 拿数据"需要先打穿内网，在 M365 里直接在云端完成 。这就是为什么要在 应用层 + 身份层 同时设防。

五、常见攻击技术剖析（按出现频率排序）

1. Phishing（钓鱼）

通用版：仿冒 M365、DocuSign、HR 系统、Teams 通知；
进阶：AiTM 钓鱼（Adversary-in-the-Middle）会直接偷取 Session Token / Refresh Token ------MFA 也可能绕过；
定向版（Spear Phishing）：针对高管、IT、财务、HR 定制内容，命中率显著高于群发。

应对

用户安全意识培训 + 模拟钓鱼演练（Microsoft Defender for Office 365 的 Attack Simulation Training）；
强制 Phishing-resistant MFA（FIDO2、Windows Hello for Business、Platform Credentials for macOS、Certificate-based Authentication）；
启用 Number Matching ，屏蔽单纯"Approve"------只点 Approve 容易被 MFA Fatigue 攻击；
启用 Conditional Access + Risk-based Signal ------一旦登录风险升高就重新验证。

关于"Phishing-resistant MFA"的关键澄清：

Microsoft 推荐（2025 视角）：FIDO2 Security Keys、Passkeys（云同步 FIDO2）、Windows Hello for Business、Certificate-based Authentication；

传统 OTP（SMS、Microsoft Authenticator Push）正在退出高风险场景 ------它们仍然容易受到 MFA Fatigue 和 AiTM 攻击；

一个常被误解的点：Number Matching ≠ Phishing Resistant。Number Matching 只是阻断"误点 Approve"，并不能阻止 AiTM 钓鱼中的 Token 截取。

生产建议 ：Global Admin / Exchange Admin / SharePoint Admin / Security Admin 全部要求 Phishing-resistant MFA Strength。

2. Spoofing（发件人欺骗）

SMTP 协议里有两类"发件人"，二者都可以被伪造：

5321.MailFrom （MAIL FROM）------实际投递用的；
5322.From（Header From）------邮件客户端里显示的"发件人"。

攻击者可以让一封信看起来是 security@woodgrovebank.com 发的，但实际是从 phish@badguy.com 投递。这是为什么 SPF / DKIM / DMARC 三件套必须配齐。

SPF / DKIM / DMARC 的精确分工

协议	验证对象	保护范围	验证方式
SPF	5321.MailFrom 的 IP 是否被授权	是不是"合法 IP" 在发	DNS TXT `v=spf1`
DKIM	邮件内容完整性 + 域签名	邮件是否被篡改	DKIM-Signature 头 + DNS 公钥
DMARC	5321.MailFrom 与 5322.From 的域对齐	是不是"合法域" 在冒名	DNS TXT `v=DMARC1` + Reporting

正确的关系表述：

SPF 提供"IP 真实性"基础；
DKIM 提供"内容完整性"基础；
DMARC 把两个东西对齐（5321 与 5322 域一致性），并定义策略（quarantine / reject）；
三者叠加形成"域保护"------任何一项缺失，攻击者都还有路径绕过。

一种不严谨的讲法是"SPF + DKIM + DMARC = 防止欺骗"，更精确的版本是：SPF + DKIM 提供身份真实性基础，DMARC 负责策略执行和域对齐，是阻止域冒充攻击的关键控制。

3. Malware（恶意软件）

两阶段：第一阶段诱导用户打开附件或访问恶意站点；第二阶段投放真正的 Payload（键盘记录器、RAT、勒索）；
2025 趋势 ：纯脚本化 + Living-off-the-Land（LOLBins）------ 用 PowerShell、WMI、mshta、rundll32 这些系统自带工具去打，静态查杀很难兜住。

M365 上的两个抓手

Exchange Online Protection（EOP）：所有入站邮件默认走它；
Microsoft Defender for Office 365（P2）：在 EOP 上再加一层------Safe Attachments（沙箱拆炸弹）、Safe Links（点击时实时 URL 改写 + 信誉判分）、Anti-phishing（含用户冒充检测、域冒充检测、Mailbox Intelligence）。

邮件安全栈的层次关系

EOP 与 Defender for Office 365 不是简单的"上下叠加"：

复制代码

flowchart TD
    NET["<b>Internet</b>"]

    subgraph EOP ["Exchange Online Protection (EOP) --- 原生基础能力"]
        direction TB
        EOP1["Anti-spam"]
        EOP2["Anti-malware"]
        EOP3["Transport Rules"]
        EOP4["Connection Filtering"]
    end

    subgraph DFO ["Defender for Office 365 (Plan 1 / P2) --- 增强威胁防护"]
        direction TB
        D1["Safe Links"]
        D2["Safe Attachments<br/><i>沙箱 + 时间炸弹</i>"]
        D3["Anti-phishing<br/><i>用户冒充 / 域冒充</i>"]
        D4["Spoof Intelligence"]
        D5["Threat Explorer"]
        D6["Attack Simulation Training"]
        D7["Automated Investigation & Response"]
    end

    MBX["<b>Exchange Online Mailbox</b>"]

    NET --> EOP
    EOP -->|"流入"| DFO
    DFO --> MBX

    style NET fill:#666,stroke:#333,color:#fff,stroke-width:2px
    style EOP fill:#e8f4ff,stroke:#0078d4,color:#0078d4,stroke-width:2px
    style DFO fill:#fff4e6,stroke:#ff8c00,color:#d17000,stroke-width:2px
    style MBX fill:#107c10,stroke:#0b6a0b,color:#fff,stroke-width:2px

EOP 是 Exchange Online 原生邮件安全基础能力，Defender for Office 365 是增强型威胁检测与响应能力------前者是"邮件系统自带"，后者是"安全产品"。

4. OAuth Application Abuse（OAuth 同意滥用）------ M365 特有高发路径

这是 M365 区别于传统企业的典型风险路径：

复制代码

flowchart TD
    A["<b>Phishing / Lure</b><br/>钓鱼诱导"]
    B["<b>用户点击</b><br/>假冒 OAuth 应用"]
    C["<b>Consent Grant</b><br/>用户点了 Allow"]
    D["<b>恶意应用获得 OAuth Token</b><br/>Mail.Read / Mail.send / Files.ReadWrite.All ..."]
    E["<b>自动读写数据</b><br/>Mail / Files / Calendar / Contacts"]

    A --> B --> C --> D --> E

    style A fill:#d13438,stroke:#a4262c,color:#fff,stroke-width:2px
    style B fill:#ff8c00,stroke:#e07b00,color:#fff,stroke-width:2px
    style C fill:#ffb900,stroke:#e0a800,color:#333,stroke-width:2px
    style D fill:#d13438,stroke:#a4262c,color:#fff,stroke-width:2px
    style E fill:#a4262c,stroke:#6b1a1e,color:#fff,stroke-width:2px

为什么它比纯恶意软件更"安静"：

用户的账号密码没泄露（不需要 Touch MFA）；
攻击完全符合合法 OAuth 协议，短期内难以凭"异常登录"发现；
攻击面比传统邮件钓鱼宽------可以通过 Teams 消息、SharePoint 评论、PDF 文档里的链接、引荐邮件等方式投递。

防御要点

Disable user consent ------ 用户禁用"个人应用同意"，统一走 Admin Consent Workflow（Microsoft Entra ID → Enterprise applications → Consent and Permissions）；
Defender for Cloud Apps → OAuth monitoring------发现可疑权限组合（多权限应用、Mail.Send + Files.ReadWrite）；
Microsoft Entra App Governance（与 Defender for Cloud Apps 联动）------ 给 OAuth 应用分级、定期收回闲置权限；
Conditional Access App Control ------ 通过代理把通过的流量再做一层内容级策略；
Token revocation ------ 失陷 OAuth Token 后，使用 Microsoft Graph PowerShell 撤销该用户的全部 Refresh Token 与登录会话（推荐命令 Revoke-MgUserSignInSession）；旧版 Revoke-AzureADUserAllRefreshToken 属于 AzureAD PowerShell，已进入淘汰路线，新部署请改用 Microsoft Graph。

OAuth Application Abuse 在 M365 上 比传统邮件钓鱼更贴合当下风险------很多管理员不知道这条路径，会把整套邮件钓鱼防御做完就以为结束了。

5. Account Breach（账号失陷）

失陷途径很多：

密码喷洒（password spray）；
撞库（credential stuffing）；
键盘记录；
社会工程；
OAuth 同意滥用（见上一节）；
移动设备 / 终端上的恶意 Outlook APP。
现代会话型攻击（2025 起显著上升）------与前面的 Phishing 章节形成闭环：
- AiTM（Adversary-in-the-Middle）Token Replay------攻击者通过反向代理窃取已认证用户的 Session Token，直接重放到 Entra ID；
- Refresh Token Theft ------ Refresh Token 在浏览器 / 移动端被恶意应用 / 终端恶意软件外泄，攻击者不需要账号密码就能以用户身份持续刷新访问令牌；
- Browser Session Cookie Theft------通过恶意浏览器扩展 / 本地脚本把会话 Cookie 外泄；
- 结果：M365 上 2025 起"账号失陷"逐渐从 "密码失陷" 变成 "会话 / Token / OAuth Grant 失陷"------防御控制也要相应从前置 MFA 后移到 Continuous Access Evaluation（CAE）+ Token Revocation + Conditional Access 实时风险评估。

最常见的失陷信号：

在 Microsoft Entra ID → Sign-in Logs 里会发现大量来自异常地区、异常设备、异常 ISP 的登录；
Microsoft Entra ID Protection 会把这些自动算成 Risk Event；
会话型攻击较难从单一登录发现，需要靠 UEBA（用户与实体行为分析）+ Defender XDR 的 Identity 侧告警关联。

后续文章会展开。

6. Elevation of Privilege（提权）

攻击者用一个普通账号进来后，会去搜 GitHub/SharePoint 上的运维脚本找硬编码口令，找浏览器里保存的 Session，找没用 PIM 的 Global Admin 账号；
管理员账号必须强制 Phishing-resistant MFA；
管理员账号对应的设备必须隔离 ------这就是 Privileged Access Workstation (PAW) 的核心；

Microsoft 同时提供了 Enterprise Access Model，对应传统 Tier 0 / Tier 1 / Tier 2：

flowchart TD
subgraph T0 ["Tier 0 --- 控制平面"]
T0A["Domain Controller"]
T0B["Entra ID / Cloud Tenant"]
T0C["身份层 = 控制平面"]
end

复制代码

  subgraph T1 ["Tier 1 --- 被管理平面"]
      T1A["<b>Server</b>"]
      T1B["<b>Application</b>"]
      T1C["<b>Resource</b>"]
  end

  subgraph T2 ["Tier 2 --- 用户办公平面"]
      T2A["<b>User Workstation</b>"]
      T2B["<b>Productivity Application</b>"]
  end

  T0 -->|"管理"| T1
  T1 -->|"管理"| T2

  style T0 fill:#d13438,stroke:#a4262c,color:#fff,stroke-width:2px
  style T1 fill:#ff8c00,stroke:#e07b00,color:#fff,stroke-width:2px
  style T2 fill:#107c10,stroke:#0b6a0b,color:#fff,stroke-width:2px

传统 Tier 0/1/2 模型正在演进为 Microsoft Enterprise Access Model ，但核心思想一致：高权限身份必须隔离、受控、可审计 。PAW（Privileged Access Workstations） 是 Tier 0 管理员工作的专用工作站------硬件层、OS 层、网络层、应用层多重隔离。

7. Data Exfiltration / Data Spillage

Data Exfiltration：攻击者主动把企业数据拷出去（OneDrive 同步到外部设备、Exchange 转发到外部邮箱、SharePoint 外部共享）；
Data Spillage ：员工不小心把机密文档群发到了不该发的人。事后用 eDiscovery（Hold → Search → Purge） 删除。

8. Data Deletion

攻击者拿到管理员后，最直接的破坏动作是清空 OneDrive / SharePoint / 邮箱。对应的工程方案：

多层 MFA + 限制后台令牌存活时间；
Conditional Access + Sign-in Risk Policy；
异地离线备份（一份在 immutable storage + 离线）；
Microsoft 365 Backup（Microsoft 提供的备份能力，用于提高 Exchange Online、SharePoint Online、OneDrive 数据恢复能力；具体 GA / 区域可用性以 Microsoft 官方公告为准）；
关键数据开启 SharePoint/OneDrive 的版本历史 + Recycle Bin + Retention Policy；
Unified Audit Log + Sentinel/Defender XDR 检测删除行为。

六、Zero Trust 模型："Never trust, always verify"

1. 三条原则

Verify explicitly（永远基于多源信号验证）------ 身份 / 设备 / 网络位置 / 应用 / 数据 / 行为 / 风险；
Use least privileged access （最小权限）------ JIT + Just-Enough-Access，对应 Microsoft Entra PIM；
Assume breach （默认已失陷）------ 日志全开 + 自动化响应 + 默认不允许 长期持有高权限账号，对应 Microsoft Defender XDR + Sentinel。

2. Zero Trust 的六大核心组件（Microsoft 官方口径）

复制代码

flowchart TB
    subgraph ZTA ["Microsoft Zero Trust Architecture"]
        direction TB

        subgraph ROW1 [" "]
            direction LR
            ID["<b>Identities</b><br/>━━━━━━━━━<br/>Entra ID<br/>Conditional Access<br/>PIM<br/>ID Protection"]
            DEV["<b>Devices</b><br/>━━━━━━━━━<br/>Intune<br/>Defender for Endpoint"]
            APP["<b>Applications</b><br/>━━━━━━━━━<br/>Defender for Cloud Apps<br/>Entra App Management<br/>OAuth Governance<br/>CA App Control"]
        end

        subgraph ROW2 [" "]
            direction LR
            DATA["<b>Data</b><br/>━━━━━━━━━<br/>Microsoft Purview<br/><i>Labels / DLP /<br/>Information Protection</i>"]
            INFRA["<b>Infrastructure</b><br/>━━━━━━━━━<br/>Defender for Cloud<br/><i>Cloud posture &<br/>workload protection</i>"]
            NET["<b>Network</b><br/>━━━━━━━━━<br/>Global Secure Access<br/><i>Private Access /<br/>Internet Access</i>"]
        end
    end

    DR["<b>Detection / Response</b><br/>━━━━━━━━━━━━━━━━━━<br/>Microsoft Defender XDR<br/>Microsoft Sentinel"]

    ROW1 --> ROW2
    ZTA --> DR

    style ID fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px
    style DEV fill:#2b88d8,stroke:#005a9e,color:#fff,stroke-width:2px
    style APP fill:#71afe5,stroke:#005a9e,color:#fff,stroke-width:2px
    style DATA fill:#107c10,stroke:#0b6a0b,color:#fff,stroke-width:2px
    style INFRA fill:#2b88d8,stroke:#005a9e,color:#fff,stroke-width:2px
    style NET fill:#71afe5,stroke:#005a9e,color:#fff,stroke-width:2px
    style DR fill:#d13438,stroke:#a4262c,color:#fff,stroke-width:2px
    style ZTA fill:#f8f9fa,stroke:#0078d4,stroke-width:3px
    style ROW1 fill:transparent,stroke:transparent
    style ROW2 fill:transparent,stroke:transparent

组件	Microsoft 对应	关键能力
Identities	Microsoft Entra ID	MFA、PIM、Conditional Access、ID Protection
Devices	Intune / Defender for Endpoint	Compliance Policy、设备健康、风险评分
Applications	Defender for Cloud Apps、Entra App Management、OAuth App Governance、Conditional Access App Control	SaaS 发现、影子 IT、OAuth 治理
Data	Microsoft Purview	分类、标签、DLP、加密
Infrastructure	Defender for Cloud	服务器 / 容器 / 数据库的安全态势
Network	Global Secure Access、Entra Private Access、Entra Internet Access	Zero Trust Network Access

传统 VPN 仍会在大型企业短期共存------Entra Private Access 是 Microsoft Zero Trust Network Access（ZTNA）方向的核心能力，用于减少对传统 VPN 的依赖，而不是"立刻全部替换"。

3. Microsoft Zero Trust 的四大支撑

Identity（身份）：Microsoft Entra ID + Conditional Access + PIM + ID Protection；
Security（安全）：Defender for Endpoint / Defender for Office 365 / Defender for Cloud Apps + Sentinel（SIEM/SOAR）；
Compliance（合规）：Microsoft Purview（Information Protection + Insider Risk + DLP）；
Skilling（技能）：Security, Compliance, and Identity Fundamentals / Information Protection Administrator Associate / Security Operations Analyst Associate / Identity and Access Administrator Associate------这四个认证对管理员来说基本要全考。

七、规划你的 Zero Trust 路线（落地五步）

下面这条路径来自 Microsoft Entra 团队推荐的 Identity Zero Trust 落地路线 （与 Microsoft 官方发布的多份 Zero Trust Adoption Framework 一致------典型如 Microsoft Zero Trust Deployment Plan 、Identity Zero Trust Guidance 、Entra Secure Access Guidance 等不同框架条目数量不同，但核心动作重叠在以下五步）。把它当作一个"基线起步清单"使用即可：

Strengthen your credentials------开 MFA、强制 Authentication Strength、引导用户用 phishing-resistant MFA；这是绝大多数账号失陷攻击最直接的阻断点；
Reduce your attack surface ------关 Legacy Auth（基本认证、SMTP AUTH、Active Sync 老协议）、限制 admin 接口入口（断外部访问 M365 Admin Center，只允许通过 PAW 访问）、禁用 user consent / 启用 Admin Consent Workflow；
Automate threat response------Defender XDR 的自动调查 + 响应、Sentinel 的 SOAR playbooks；越自动化，攻击者驻留时间越短；
Increase your awareness------开 Unified Audit Log、配 Sentinel / Log Analytics、配 Conditional Access 的 Failure 报告；
Enable user self-help------SSPR（Self-Service Password Reset），减少"找 IT 重置密码"这种场景下的钓鱼机会。

八、Advanced：把 Threat Vector → Zero Trust 串成一张总架构图

复制代码

flowchart TD
    ATTACKER["<b>Attacker</b> 攻击者"]

    subgraph TVS ["Threat Vector Surface 威胁向量面"]
        direction LR
        TV1["<b>Identity</b><br/>Credentials / MFA / Token"]
        TV2["<b>Email</b><br/>Phishing / Spoof / Malware"]
        TV3["<b>OAuth App Abuse</b>"]
        TV4["<b>Endpoint</b><br/>LOLBins / ASR"]
        TV5["<b>Insider / Data Spillage</b>"]
    end

    KILL["<b>Cyber Kill Chain</b><br/>7 阶段攻击生命周期"]
    ATTACK["<b>MITRE ATT&CK</b><br/>TTP 映射"]

    subgraph DET_RESP ["Detection & Response 检测与响应"]
        direction LR
        DET["<b>Detection</b><br/>EDR / NDR"]
        RESP["<b>Response</b><br/>SOAR"]
    end

    subgraph ZT ["Microsoft Zero Trust Architecture"]
        direction TB
        ZT1["<b>Identities</b> --- Entra ID / CA / PIM / ID Protection"]
        ZT2["<b>Devices</b> --- Intune / Defender for Endpoint"]
        ZT3["<b>Applications</b> --- Defender for Cloud Apps / Entra App Mgmt / OAuth Governance"]
        ZT4["<b>Data</b> --- Purview (Labels / DLP / IP)"]
        ZT5["<b>Infrastructure</b> --- Defender for Cloud"]
        ZT6["<b>Network</b> --- Global Secure Access"]
    end

    XDR["<b>Detection & Response 层</b><br/>━━━━━━━━━━━━━━━━━━<br/>Microsoft Defender XDR<br/>Microsoft Sentinel (SIEM/SOAR)"]

    ATTACKER --> TVS
    TVS --> KILL
    KILL --> ATTACK
    ATTACK --> DET
    ATTACK --> RESP
    DET --> ZT
    RESP --> ZT
    ZT --> XDR

    style ATTACKER fill:#a4262c,stroke:#6b1a1e,color:#fff,stroke-width:3px
    style TVS fill:#fef2f2,stroke:#d13438,stroke-width:2px,color:#a4262c
    style KILL fill:#fff4e6,stroke:#ff8c00,color:#d17000,stroke-width:2px
    style ATTACK fill:#fffbe6,stroke:#ffb900,color:#8a6d00,stroke-width:2px
    style DET_RESP fill:#f0f6ff,stroke:#0078d4,stroke-width:2px,color:#0078d4
    style ZT fill:#f0fff4,stroke:#107c10,stroke-width:2px,color:#0b6a0b
    style XDR fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px

这张图把"攻击面 → 攻击模型 → 防御模型 → 产品映射 → 检测响应"在同一张图里画清楚------架构师想要的总览。

九、MS-102 考点映射

MS-102 知识点	对应模块	本系列对应
Threat Vector（描述 Microsoft 安全方案）	Domain 3：Microsoft Security Solutions	本篇 + 第 3 篇
Zero Trust（落地安全控制）	Domain 3 + Domain 4	本篇
Conditional Access（身份访问管理）	Domain 4	第 2 篇
Defender XDR（安全事故处理）	Domain 4	第 3 篇
Purview（合规管理）	Domain 5	系列补充
PIM（身份治理）	Domain 4	第 5 篇
ID Protection（身份风险）	Domain 4	第 6 篇

十、小结

本篇是总入口，回答三个问题：

攻击面是什么 ------ 身份、邮件、OAuth、终端、数据五条线；

怎么建模 ------ Cyber Kill Chain（生命周期）+ MITRE ATT&CK（TTP）双模型叠加；

怎么防御 ------ Microsoft Zero Trust 六组件：Identities / Devices / Applications / Data / Infrastructure / Network。

后续 5 篇会按 Conditional Access → Defender XDR → Secure Score → PIM → ID Protection 顺序展开，把"防御控制"逐一落地。

下一章预告：Conditional Access 深度设计

下一篇（系列第 2 篇）会展开：

Conditional Access 的信号 / 决策 / 会话三大类；
Authentication Strength 三档强制策略；
10 条 Baseline Policy 模板；
与 Microsoft Defender for Endpoint / Intune 的联动；
与 Microsoft Entra ID Protection 的 Risk Signal 联动。

Microsoft 365 企业安全架构系列（一）：身份攻击面、Kill Chain 与 Zero Trust 基础模型

〇、本系列文章的全景

一、背景：为什么身份与访问安全是 M365 的第一战场

二、攻击者目标与三类核心威胁

三、身份与访问方向的威胁向量（Threat Vector）清单

关键判断

四、两个相互补充的攻击模型：Cyber Kill Chain 与 MITRE ATT&CK

1. 两者不是同一个模型

2. Cyber Kill Chain 在 M365 上的阶段映射

五、常见攻击技术剖析（按出现频率排序）

1. Phishing（钓鱼）

应对

2. Spoofing（发件人欺骗）

SPF / DKIM / DMARC 的精确分工

推荐的 DMARC 部署路径

3. Malware（恶意软件）

M365 上的两个抓手

邮件安全栈的层次关系

4. OAuth Application Abuse（OAuth 同意滥用）------ M365 特有高发路径

防御要点

5. Account Breach（账号失陷）

6. Elevation of Privilege（提权）

7. Data Exfiltration / Data Spillage

8. Data Deletion

六、Zero Trust 模型："Never trust, always verify"

1. 三条原则

2. Zero Trust 的六大核心组件（Microsoft 官方口径）

3. Microsoft Zero Trust 的四大支撑

七、规划你的 Zero Trust 路线（落地五步）

推荐检查清单（架构级别）

八、Advanced：把 Threat Vector → Zero Trust 串成一张总架构图

九、MS-102 考点映射

十、小结

下一章预告：Conditional Access 深度设计