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

〇、本系列文章的全景

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

之所以先讲"威胁、攻击路径、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 租户，最终目标不外乎三类：

1. Compromise user accounts through email——钓鱼、欺骗、恶意软件，把一个普通员工账号拿下；

2. Gain control over resources——拿到账号后再升级权限（Elevation of Privilege），变成有"写入/删除"权限的管理员；

3. Compromise data——再往上一步就是偷数据、删数据、把数据泄露到租户外（Data Exfiltration / Data Spillage）。

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

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

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

关键判断

攻击面宽度决定了 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 上的阶段映射

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提供"IP 真实性"基础；

• DKIM提供"内容完整性"基础；

• DMARC把两个东西对齐（5321 与 5322 域一致性），并定义策略（quarantine / reject）；

• 三者叠加形成"域保护"——任何一项缺失，攻击者都还有路径绕过。

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

推荐的 DMARC 部署路径

1. 先p=none+ 启用 RUA（rua=mailto:dmarc@yourdomain.com）→ 收集 2–4 周报告；

2. 调整 SPF/DKIM，让100% 合法流量通过 DMARC → 切到p=quarantine；

3. 试运行 4–8 周 → 切到p=reject；

4. 长期保留 RUA 邮箱，处理"spf/dkim 失效但 mail 还在" 的边缘场景。

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["<b>Domain Controller</b>"] T0B["<b>Entra ID / Cloud Tenant</b>"] T0C["<i>身份层 = 控制平面</i>"] 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. 三条原则

1. Verify explicitly（永远基于多源信号验证）—— 身份 / 设备 / 网络位置 / 应用 / 数据 / 行为 / 风险；

2. Use least privileged access（最小权限）—— JIT + Just-Enough-Access，对应 Microsoft EntraPIM；

3. 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

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

3. Microsoft Zero Trust 的四大支撑

1. Identity（身份）：Microsoft Entra ID + Conditional Access + PIM + ID Protection；

2. Security（安全）：Defender for Endpoint / Defender for Office 365 / Defender for Cloud Apps + Sentinel（SIEM/SOAR）；

3. Compliance（合规）：Microsoft Purview（Information Protection + Insider Risk + DLP）；

4. 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等不同框架条目数量不同，但核心动作重叠在以下五步）。把它当作一个“基线起步清单”使用即可：

1. Strengthen your credentials——开 MFA、强制 Authentication Strength、引导用户用 phishing-resistant MFA；这是绝大多数账号失陷攻击最直接的阻断点；

2. Reduce your attack surface——关 Legacy Auth（基本认证、SMTP AUTH、Active Sync 老协议）、限制 admin 接口入口（断外部访问 M365 Admin Center，只允许通过 PAW 访问）、禁用 user consent / 启用 Admin Consent Workflow；

3. Automate threat response——Defender XDR 的自动调查 + 响应、Sentinel 的 SOAR playbooks；越自动化，攻击者驻留时间越短；

4. Increase your awareness——开 Unified Audit Log、配 Sentinel / Log Analytics、配 Conditional Access 的 Failure 报告；

5. Enable user self-help——SSPR（Self-Service Password Reset），减少"找 IT 重置密码"这种场景下的钓鱼机会。

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

• 所有用户强制 MFA，且策略不依赖Security Defaults（要走 Conditional Access）；

• 日常 Global Administrator 极少数量（通常 2 个Emergency Access (Break Glass) Account+ 少量受控的临时激活管理员，日常管理通过PIM 临时激活完成）；

• Legacy Authentication 全租户阻断；

• 禁用 user consent，全部 OAuth 应用走 Admin Consent Workflow；

• Exchange Online / SharePoint / Teams 全部 Unified Audit Log = On；

• 邮件流：SPF + DKIM + DMARC（p=quarantine 或 p=reject）配齐 + RUA 报告收集；

• 启用Zero Trust Assessment工具和Microsoft Secure Score，每月巡检；

• 关键工作负载启用备份（异地离线）+ Microsoft 提供的备份能力（以官方公告为准）；

• 至少每季度跑一次Attack Simulation Training；

• 所有 Tier 0 管理员强制Phishing-resistant MFA+PAW 工作站。

八、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 考点映射

十、小结

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

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

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

3. 怎么防御—— 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 联动。