SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场security-architecture

security-architecture

安全与审计

查看项目

更新于 10-15 13:53

技能介绍

用途

Security Architecture（零信任与 MCRA）用于定义身份、终结点、数据、应用、基础设施和网络控制如何组合以保护组织。其设计锚定零信任原则与 Microsoft Cybersecurity Reference Architectures（MCRA），交付脚手架来自 Cloud Adoption Framework Secure 方法，工作负载层面的严谨性来自 Well-Architected Framework 安全支柱。

适用场景包括：设计端到端安全目标状态、将多年路线图对齐到公认框架、或在重大项目启动前审查架构缺口。

不适用场景：战术性产品配置（应使用产品专属技能，如 defender-xdr、sentinel）；仅 SOC 工具架构（应使用 unified-secops-platform）；单一工作负载代码审查（应使用 threat-modelling）。

主要能力

框架选择

技能提供按问题选择框架的对照：

  • 三年安全目标状态：使用 MCRA + CAF Secure，输出能力地图 + 路线图。
  • 身份/终结点/数据/应用/基础设施/网络的能力覆盖：使用零信任六大支柱，输出支柱成熟度热力图。
  • 项目交付（战略 → 运营）：使用 CAF Secure 方法，输出工作流计划。
  • 单一工作负载是否安全设计：使用 Well-Architected 安全支柱，输出工作负载审查。
  • 特定设计面临哪些威胁：使用 STRIDE / SDL（即 threat-modelling），输出威胁模型。
  • 是否满足监管基线：使用 Microsoft Cloud Security Benchmark，输出合规证据。

经验法则：零信任是原则层，MCRA 是能力层，CAF Secure 是交付层，Well-Architected 是工作负载层。真实架构需同时使用四者，不可相互替代。

方法

  1. 先锚定零信任原则——显式验证、最小权限访问、假设失陷。后续每个决策都必须可追溯到其中一条。验证：设计中的每个控制都能标记到三条原则之一，否则追问其存在原因。
  2. 映射零信任六大支柱——身份、终结点、数据、应用、基础设施、网络，并在所有支柱上贯穿可见性/分析与自动化。按支柱评分当前成熟度（Traditional / Advanced / Optimal），使投资落在差距最大处。验证：支柱热力图显示清晰差异，能说出最需投资的两个支柱。
  3. 验证身份是首要控制平面——身份薄弱时其他支柱无法补偿。在重投网络、数据或终结点支柱前，确认 MFA 覆盖率、特权访问设计（PIM、PAW）和条件访问态势。验证：人类账户中抗钓鱼 MFA 的百分比、特权账户在 PIM 中的百分比已建立基线并纳入路线图。
  4. 将能力锚定到 MCRA——使用 Microsoft Cybersecurity Reference Architectures 将 Microsoft 产品（Defender、Sentinel、Entra、Purview、Intune、Defender for Cloud）映射到其覆盖的功能，并验证没有能力缺失或重复。验证：MCRA 海报叠加当前/计划产品后，范围内无未处理功能。
  5. 构建纵深防御——分层预防、检测和响应控制，使任何单一控制失效都不等于失陷。对每类资产至少指定一个预防控制和一个检测控制。验证：移除任一控制后仍有检测或补偿控制。
  6. 按风险与依赖排序路线图——按支柱从当前状态到目标状态，使前置条件先落地（如身份卫生先于数据分类、日志摄取先于 XDR、态势管理先于自动化）。验证：路线图显示有序里程碑、具名负责人和风险，而非扁平待办列表。
  7. 将监控与响应内建而非附加——SIEM/XDR 架构是设计的一部分，不是后续项目。确认日志源、保留期和响应交接。验证：每个支柱都向有文档的检测管道产生信号。

使用方式

技能以指导性方法呈现，通过示例提示驱动，例如：设计与 MCRA 对齐的零信任安全架构；将 Cloud Adoption Framework 安全方法应用于三年路线图；如何在身份、网络和数据间构建纵深防御；对照 Well-Architected 安全支柱审查工作负载设计；对当前状态在零信任六大支柱上评分。

适用场景

  • 设计端到端安全目标状态。
  • 将多年路线图对齐到公认框架。
  • 在重大项目前审查架构缺口。
  • 对零信任六大支柱进行成熟度评分。
  • 对照 Well-Architected 安全支柱审查单一工作负载。

限制与护栏

  • 架构必须由业务风险和数据敏感性驱动，而非产品清单、供应商压力或“我们已拥有什么”。从威胁和资产出发，再选控制。
  • 身份不可妥协。若 MFA、特权访问和条件访问薄弱，任何零信任架构都无法运作。先修复此支柱。
  • 可见性和自动化是横切关注点，不是第七支柱，而是所有六者的前置条件。需预先设计日志摄取和编排。
  • 纵深防御不等于防御开支。分层控制只有在每层检测/阻断不同类别的失效时才成立。两个 SIEM 不是纵深防御。
  • 没有负责人的路线图只是愿望清单。每个里程碑都需要具名负责人和可衡量的退出标准。
  • 每年重新建立基线。MCRA、CAF Secure 和零信任支柱都在演进，去年的参考架构不适用于今年。

常见反模式

  • “我们买了 Defender / Sentinel，所以我们是零信任。”产品不等于架构。没有原则、支柱和运营模式，只是搁置品。
  • 在身份仍薄弱时投资网络或数据支柱。对手会通过最弱支柱横向移动，而身份几乎总是最弱项。
  • 将 SIEM 视为事后考虑。在既有设计上追加检测会留下盲点，后期弥补代价高昂。
  • 60 页架构文档却没有路线图。没有排序的架构不可执行。每个目标状态都应搭配未来 90 天的工作。
  • 将 Well-Architected 用作组织级框架。WAF 是工作负载层面的；项目视图应使用 CAF Secure。

参考资源

  • 零信任概述：https://learn.microsoft.com/security/zero-trust/zero-trust-overview
  • MCRA：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 Security Benchmark：https://learn.microsoft.com/security/benchmark/azure/
  • 零信任部署指南：https://learn.microsoft.com/security/zero-trust/deploy/overview