security-architecture

安全架构（Zero Trust 与 MCRA）

安全架构定义了身份、终端、数据、应用、基础设施和网络控制如何协同保护组织——以 Zero Trust 和 Microsoft Cybersecurity Reference Architectures（MCRA） 为核心，借助 Cloud Adoption Framework Secure methodology 提供交付框架，并通过 Well-Architected Framework Security pillar 强化工作负载级别的严谨性。

适用场景

设计端到端的安全目标状态、将多年路线图与公认框架对齐，或在大型项目启动前检查架构是否存在差距。

请勿将此技能用于：

• 战术层面的产品配置（请使用特定产品技能，例如 defender-xdr、sentinel）
• 仅限 SOC 工具的架构（请使用 unified-secops-platform）
• 单个工作负载的代码审查（请使用 threat-modelling）

为当前讨论选择合适的框架

要回答的问题	使用此框架	输出
我们的 3 年安全目标状态是什么？	MCRA + CAF Secure	能力图谱 + 路线图
哪些能力涵盖身份 / 终端 / 数据 / 应用 / 基础设施 / 网络？	Zero Trust 六大支柱	支柱成熟度热力图
如何交付项目（策略 → 运营）？	CAF Secure methodology	工作流计划
这个单个工作负载是否经过安全设计？	Well-Architected Security pillar	工作负载评审
特定设计面临哪些威胁？	STRIDE / SDL（请使用 threat-modelling）	威胁模型
我们是否符合监管基线？	Microsoft Cloud Security Benchmark	合规性证据

经验法则： Zero Trust 是原则层。MCRA 是能力层。 CAF Secure 是交付层。Well-Architected 是工作负载层。实际架构会用到这四层——不要试图用其中一层替代另一层。

方法

1. 首先以零信任原则为锚点——显式验证、采用最小权限访问、假定已遭入侵。后续每项决策都必须能追溯到其中一项原则。 验证：设计中的每项控制都能对应到这三项原则之一。如果不能，请弄清它为何存在。
2. 绘制零信任的六大支柱——身份、终端、数据、应用、基础设施、网络，并在所有支柱中融入可见性/分析和自动化。按支柱评估当前成熟度（传统 / 高级 / 最佳），确保投资投向差距最大的领域。 验证：支柱热力图清楚显示差距；你能说出最值得投资的两个支柱。
3. 确认身份是主要控制平面——如果身份薄弱，其他支柱都无法弥补。大量投资网络、数据或终端支柱之前，先确认 MFA 覆盖率、特权访问设计（PIM、PAW）和条件访问态势。 验证：已确定启用抗钓鱼 MFA 的人类账户比例和纳入 PIM 的特权账户比例基线，并将其纳入路线图。
4. 将能力锚定到 MCRA——使用 Microsoft 网络安全参考架构，将 Microsoft 产品（Defender、Sentinel、Entra、Purview、Intune、Defender for Cloud）映射到其覆盖的功能，并确认没有遗漏或重复的能力。 验证：将 MCRA 海报与当前/计划使用的产品叠加后，你的范围内没有未覆盖的功能。
5. 构建纵深防御——叠加预防、检测和响应控制，确保单项控制失效不会导致入侵。针对每类资产，至少指定一项预防控制和一项检测控制。 验证：移除任何一项控制后，仍有检测控制或补偿控制发挥作用。
6. 按风险和依赖关系排列路线图顺序——为每个支柱规划从当前状态到目标状态的路径，并按顺序安排，确保先落实前置条件（例如，先做好身份卫生，再进行数据分类；先接入日志，再部署 XDR；先进行态势管理，再实现自动化）。 验证：路线图列出了有序的里程碑、明确的负责人和风险，而不是一份平铺的待办清单。
7. 将监控和响应融入设计，而非事后补充——SIEM/XDR 架构是设计的一部分，不是后续项目。确认日志源、保留期限和响应交接流程。 验证：每个支柱都会向有文档记录的检测流水线提供信号。

防护原则

• 架构必须由业务风险和数据敏感度驱动——不能由产品清单、供应商施压或“我们已经拥有的东西”驱动。从威胁和资产出发，再选择控制措施。
• 身份不可妥协。 如果 MFA、特权访问和条件访问薄弱，任何零信任架构都无法奏效。先修复这一支柱。
• 可见性和自动化是贯穿各领域的能力——它们不是第七个支柱，而是六大支柱的前提。应提前设计日志接入和编排。
• 纵深防御，而非堆砌开支——只有各层能检测/阻止不同类型的故障，分层控制才有意义。部署两个 SIEM 不等于纵深防御。
• 没有负责人的路线图只是愿望清单。 每个里程碑都需要指定负责人和可衡量的退出标准。
• 每年重新评估基线。 MCRA、CAF Secure 和零信任支柱都在演进——去年的参考架构不代表今年的情况。

常见反模式

• “我们购买了 Defender / Sentinel，所以我们就是零信任。” 产品不等于架构。 如果没有相应的原则、支柱和运营模式，买来的产品只会束之高阁。
• 在身份仍然薄弱时投资网络或数据支柱。 对手会从最薄弱的支柱突破；几乎总是身份。
• 把 SIEM 当作事后才考虑的事项。 在现有设计上补充检测会留下盲点，之后弥补的代价很高。
• 只有 60 页架构文档，却没有路线图。 没有明确实施顺序的架构无法付诸行动。每个目标状态都应配上接下来 90 天的工作计划。
• 将 Well-Architected 用作全组织范围的框架。 WAF 面向工作负载；对于计划层面的视角，应使用 CAF Secure。

示例提示词

• Design a Zero Trust security architecture aligned to MCRA.
• Apply the Cloud Adoption Framework secure methodology to our 3-year roadmap.
• How do I build defence in depth across identity, network, and data?
• Review my workload design against the Well-Architected security pillar.
• Score our current state across the six Zero Trust pillars.

Microsoft Learn

• 零信任概述：https://learn.microsoft.com/security/zero-trust/zero-trust-overview
• MCRA（Microsoft 网络安全参考架构）：https://learn.microsoft.com/security/adoption/mcra
• CAF Secure 方法：https://learn.microsoft.com/azure/cloud-adoption-framework/secure/
• Well-Architected 安全支柱：https://learn.microsoft.com/azure/well-architected/security/
• Microsoft Cloud 安全基准：https://learn.microsoft.com/security/benchmark/azure/
• 零信任部署指南：https://learn.microsoft.com/security/zero-trust/deploy/overview