4. 安全架构框架与标准

企业安全架构设计很少从零开始。现实中，团队往往同时面对多套框架与标准：董事会关心风险治理，IT部门谈TOGAF分层，安全运营团队用NIST CSF衡量能力成熟度，合规团队盯ISO 27001和等保2.0。若把它们当成彼此独立的“检查表”，就会出现重复建设、证据割裂、责任悬空。真正有效的做法，是理解每个框架的“视角”和“输出物”，再建立一张可追溯的映射关系，让同一项安全能力同时满足战略、架构、运营与合规诉求。

五个框架各自解决什么问题

SABSA（Sherwood Applied Business Security Architecture）是业务驱动的安全架构方法，核心是把“业务需求”逐层推导为“安全服务”，再落到机制与控制。它强调从业务属性（如可用性、完整性、不可否认）出发，而不是从技术产品出发。其六层模型——业务视图、架构视图、设计视图、构建视图、实现视图、服务管理视图——回答的是“为什么做、做什么、怎么做、用什么做、谁来做、如何持续运营”。

TOGAF（The Open Group Architecture Framework）是企业架构方法论，提供ADM（架构开发方法）循环：预备、架构愿景、业务架构、信息系统架构、技术架构、机会与解决方案、迁移规划、实施治理、变更管理。TOGAF本身不专讲安全，但它给出了安全架构在企业架构中的“挂载点”——安全应作为业务架构、数据架构、应用架构、技术架构的横切关注点，通过架构需求规格和架构契约固化。

NIST CSF（网络安全框架）以五功能为核心：识别（Identify）、保护（Protect）、检测（Detect）、响应（Respond）、恢复（Recover），2.0版本进一步强调治理（Govern）。它更像“能力体检表”，用于评估当前安全能力覆盖度、设定目标轮廓（Target Profile）并规划差距改进。

ISO/IEC 27001是信息安全管理体系（ISMS）要求标准，强调组织上下文、领导作用、风险评估与处置、支持过程、运行、绩效评价和持续改进。它关注“管理体系是否可审计、可运行、可改进”，附录A的控制措施是风险处置的参考库。

等保2.0（网络安全等级保护2.0）是中国强制性合规基线，按系统等级（一级至五级）规定安全通用要求和扩展要求，覆盖安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心，以及管理层面的制度、机构、人员、建设、运维。它回答的是“在中国境内，这套系统至少要做到什么”。

映射的本质：不是对齐名称，而是对齐“证据”

很多团队做映射时，把“NIST CSF的PR.AC-1”直接对应“ISO 27001 A.9.2.1”，再对应“等保2.0 8.1.4.1”，看似整齐，实际无法落地。原因是三者粒度不同：CSF是能力结果，ISO是管理过程，等保是合规条款。有效的映射应落到可验证的证据上，例如“统一身份认证与权限审批记录”这一证据，可以同时支撑CSF的PR.AC、ISO的访问控制条款、等保的身份鉴别与访问控制要求。

因此，建议采用“三层映射法”：

• 战略层：用SABSA业务属性与TOGAF架构愿景，确定安全投资的业务理由和架构原则。
• 能力层：用NIST CSF五功能建立能力目录，明确每项能力的当前成熟度与目标成熟度。
• 合规层：用ISO 27001控制项和等保2.0条款作为证据来源，反向验证能力是否可审计。

下面这张图展示了五个框架在“业务—架构—能力—合规—证据”链条上的映射关系。它不按章节标题排列，而是按实际设计时信息流动的方向组织：业务驱动架构，架构定义能力，能力产生证据，证据同时满足管理体系与合规基线。

落地时的关键操作：建立映射矩阵

映射不能停留在图上。实际项目中，建议维护一张“控制—能力—证据”矩阵，字段至少包括：控制编号、来源框架、控制描述、对应CSF功能、对应等保条款、证据名称、证据存放位置、责任部门、当前状态。下面给出一个可参考的示例片段，数据为教学假设，用于说明填写方式。

填写时有两个常见陷阱。第一，把“制度文件”当成唯一证据。等保测评和ISO审核都要求看到运行记录，仅有制度而无执行日志，通常判为不符合。第二，映射粒度过粗。例如把整个“访问控制”域映射到PR.AA，却无法回答具体条款是否覆盖。建议映射到条款级或控制项级，再向上聚合。

从映射到架构决策

映射的最终价值是指导架构决策。假设某企业要新建一套面向合作伙伴的API网关，业务要求高可用与可追溯。用SABSA推导，业务属性是“可用性”和“可审计性”，对应安全服务是“冗余接入”和“全量审计”。用TOGAF挂载，这属于技术架构中的应用安全组件，需在架构契约中明确SLA和日志接口。用NIST CSF衡量，目标轮廓要求PR.AA、PR.DS、DE.CM达到三级成熟度。用ISO 27001和等保2.0反查，需要准备身份鉴别、访问控制、安全审计、数据完整性等证据。最终架构方案中，API网关必须支持双向TLS、细粒度鉴权、请求全量落库、日志防篡改，并预留与SOC的对接接口。这样，一张映射矩阵直接变成了设计输入，而不是合规负担。

需要强调的是，五个框架并非必须全部启用。中小企业可以以等保2.0为基线、以NIST CSF为能力自评工具；大型集团或跨国企业则更适合以TOGAF为架构治理主干、以ISO 27001为管理体系、以SABSA做业务对齐、以CSF做运营度量。选择哪些框架、映射到什么深度，取决于组织规模、监管要求和安全成熟度。关键是：无论选哪几个，都要落到同一套证据和同一张责任表上，避免“多套体系、各自为政”。