导读：本节回答一个根本性问题——为什么安全团队总是"来晚了"？三层体系框架的价值，不在于提供整洁的分层图示，而在于把安全嵌入点前置到战略制定与架构设计阶段，从源头断开"事后补救"的恶性循环。本节分析三层体系各自的核心职责与安全嵌入点，以及层间协同与反馈机制。
一个典型的失效场景是：CEO 在年度战略会上提出业务扩张目标，产品团队开始设计新功能，技术团队开始选型云平台，而安全团队在产品发布前一周才被通知"做个安全评估"。其结果往往是：发现不符合目标市场的合规要求而紧急叫停；业务团队抱怨安全是"业务阻碍者"，安全团队则认为早期介入本可避免返工。三层体系的价值在于：将战略意图逐层分解为可执行的架构方案与工程任务，并在每个层级设置安全嵌入点，使安全团队从决策初期就参与，而非事后补救。
企业架构三层体系将组织的战略意图转化为可执行的技术方案。战略层由 CEO 与董事会主导，确定业务方向与资源优先级；规划层由架构师团队主导，将战略目标翻译为业务架构、IT 架构与安全架构蓝图；落地层由研发与运维团队执行，将架构方案转化为可运行的系统。
下表对比了三层体系的核心定位与关键产出，三个维度分别对应"这一层做什么""解决什么问题""产出什么成果"。
| 架构层级 | 核心定位 | 关键问题 | 关键活动与产出 |
|---|---|---|---|
| 战略层 | 明确业务目标与方向 | WHY——为什么做 | 制定企业战略、业务愿景、核心目标；定义风险偏好与投资优先级；产出战略规划、年度目标 |
| 规划层 | 将战略转化为架构方案 | WHAT——做什么 | 设计业务架构、IT 架构、安全架构；明确架构标准；产出架构蓝图、技术选型、实施路线图 |
| 落地层 | 推动架构方案落地执行 | HOW——怎么做 | IT 系统项目开发、产品交付、运维运营；产出可运行的系统、运营数据、改进建议 |
三层之间存在明确的输入输出关系：战略层的目标是规划层的输入，规划层的蓝图是落地层的输入，落地层的运营数据和改进建议反馈到上两层，形成闭环。
适用边界：该框架适用于具备独立 IT 能力的中大型企业。对于完全依赖外包或 SaaS 的小型组织，规划层的职能可能由供应商或集成商承担，但战略层的风险决策与落地层的验收仍需内部主导。
关键约束：三层体系的有效运作依赖组织具备跨层级沟通机制。若战略层与落地层缺乏信息同步渠道，规划层的架构设计容易与实际执行脱节。
战略层是企业架构的起点，其核心任务是在有限资源下做优先级判断。典型的战略会议场景：产品负责人提出"进军新市场"，技术负责人提出"偿还技术债"，CFO 关心利润率，CISO 强调合规前置。这些诉求各有其合理性，但资源有限，战略层的价值在于做取舍——决定"做什么、不做什么"以及"先做什么、后做什么"。
战略制定的核心是明确企业使命、愿景、核心价值观，制定中长期战略规划，识别关键业务目标与成功指标。主要产出物包括企业战略文档（包含明确的目标、路径、资源分配，而非仅停留于愿景描述）、战略地图（可视化展示战略目标与因果关系）、平衡计分卡（从财务、客户、流程、学习四个维度分解战略目标）。责任角色通常为 CEO、董事会、战略规划部。
常见误区：战略文档写得完美但执行层无法落地——通常因为战略制定时未考虑资源约束和执行能力，导致战略沦为"墙上的标语"。改进方式是在战略制定时拉上财务、技术、安全的负责人参与可行性评估。
业务目标设定需将战略分解为可衡量的业务目标，设定年度或季度 OKR/KPI，明确各业务单元的目标与职责。主要产出物包括年度业务目标（每个目标有明确的负责人、时间节点、验收标准）、OKR 体系（Objective 具有挑战性但可达成，Key Results 必须可量化）、业务单元目标责任书（明确权责，避免执行时扯皮）。
验证方法：OKR 的有效性检验——能否用"是/否"或具体数字回答"目标是否达成"。若答案是"差不多"或"有进步"，则目标设定不够具体。
风险偏好界定是战略层最容易被忽视但对安全架构影响最大的决策之一。不同企业、不同发展阶段对风险的承受能力不同：初创公司可能将现金流置于安全之上，金融机构则可能对数据泄露零容忍。活动内容包括明确企业可接受的风险水平、定义风险承受能力、制定风险管理原则。主要产出物包括风险偏好声明（明确说明哪些风险零容忍、哪些可接受、接受的条件）、风险承受阈值（用业务语言定义）、风险管理政策（指导日常决策的原则）。
这一活动在两套主流标准里都有对应位置，可直接借用其术语与产出定义，不必自造：ISO 31000:2018 把「风险准则」（risk criteria）的确立列为风险管理框架的规定动作，要求组织显式说明衡量风险重要性所依据的标准[1]；NIST CSF 2.0 在 2024 年新增的 GOVERN 职能中，进一步把「风险偏好与风险容忍度声明须被建立、传达并维护」（GV.RM-02）写成了独立子类别[2]。用标准既有的措辞起草风险偏好声明，能省掉与审计、内控团队反复对齐定义的成本。
关键约束：风险偏好不是技术问题，是业务决策。CISO 的职责是将技术风险翻译成业务语言（损失金额、概率、影响范围），让 CEO 和董事会做出明智的决策，而非替业务做决定。
安全投资的难点在于难以直接证明 ROI——损失本来就没发生，难以证明是安全投资的功劳。应对策略包括：锚定行业基准（与同行安全投资占比对标）、量化业务价值（认证带来的客户签约）、展示合规风险（监管处罚的潜在敞口）。活动内容包括确定 IT 与安全投资优先级、平衡业务增长与风险控制的投入、制定年度预算与资源分配。主要产出物包括年度预算（分解到具体项目、时间节点、验收标准）、投资组合（按优先级排序，明确哪些必须做、哪些可选、哪些可以推迟）、资源分配计划。
验证方法：投资决策的有效性可通过年度复盘检验——预算执行率、项目交付率、预期收益达成率。
战略层的安全嵌入包括四项核心活动。
参与战略制定：确保安全战略与业务战略对齐；将安全能力作为业务竞争力的组成部分；识别安全对业务的支持机会。
明确安全目标：将安全目标转化为业务语言；设定可衡量的安全 KPI/KRI；与业务目标建立关联关系。
定义风险偏好：协助制定风险承受能力基线；明确"零容忍"风险项；建立风险量化模型。
争取预算支持：用业务价值证明安全投资必要性；量化安全投资回报；建立安全经济性模型。
战略层的安全嵌入需要明确"服务范围与优先级"。推荐分两步进行：首先按业务单元（BU）、市场区域或产品类型进行业务细分，每个细分匹配对应的安全业务伙伴（BISO/GSBP）；其次建立利益相关方地图，列出 CXO、产品负责人、研发负责人、运营、法务、合规、隐私、数据等角色，明确其期望、安全痛点与沟通渠道。
下表展示典型利益相关方的关注点与安全诉求，五类角色分别代表业务决策、产品交付、日常运营、合规约束、技术实现维度。
| 利益相关方 | 关注点 | 安全诉求 | 推荐互动节奏 |
|---|---|---|---|
| BU 总经理 | 业务增长、利润率、客户体验 | 安全不阻碍创新，重大风险有方案 | 月度经营会、季度 QBR |
| 产品负责人 | 产品路线图、上线节奏 | 上线审批效率、风险提前识别 | 产品例会、迭代评审 |
| 运营负责人 | 活动执行、成本控制 | 反作弊、账号安全、投诉率 | 周例会、活动前复盘 |
| 法务/合规 | 合同、政策、监管沟通 | 合规评估、证据留存 | 月度法规同步、合规评审会 |
| 技术负责人 | 技术债、稳定性、效率 | 安全需求可落地、开发成本可控 | 架构评审、技术双周会 |
利益相关方地图需定期更新，纳入团队知识库，确保新成员快速熟悉关系网络。
某企业计划进入欧洲市场开展业务。战略目标包括财务目标（达成目标市场的营收指标并保持利润率）、用户目标（获得目标市场用户信任）、合规目标（满足 GDPR 等欧洲法规要求）。
下表展示安全战略如何与业务目标对齐，四个维度分别对应合规约束、风险容忍度、资源分配、价值衡量四个战略决策要素。
| 安全战略 | 与业务目标的对齐 | 验收口径 |
|---|---|---|
| 合规先行 | GDPR 合规作为进入欧洲市场的前置条件；获得 ISO 27001、SOC 2 认证提升客户信任 | GDPR 合规评估通过；认证在业务上线前完成 |
| 风险偏好 | 明确"数据泄露零容忍"原则；建立数据保护影响评估（DPIA）流程 | 数据泄露事件数为零；DPIA 覆盖所有涉及个人数据处理的业务流程 |
| 投资决策 | 安全预算向数据保护、隐私工程、合规自动化倾斜 | 安全预算占 IT 预算比例提升；避免合规罚款敞口 |
| 价值量化 | 加速客户安全评估，缩短销售周期；Trust Center 提升转化率 | 客户安全评估周期缩短；网站转化率提升 |
安全战略的每个维度都直接映射到可验收的业务成果，而非停留在技术指标层面。
常见误区：若安全团队未参与战略制定，可能出现业务上线后才发现不符合 GDPR 要求的情况，导致紧急整改或延迟上线。
规划层是企业架构中连接"战略想做什么"与"工程师能做什么"的关键层级。规划层的任务是将战略目标翻译成具体的架构方案：需要建设哪些系统、数据如何流转、技术选型是用 SaaS 还是自建。这些决策不是研发团队能定的，也不是 CEO 关心的细节——这正是规划层的价值所在。
对于安全架构师，规划层是核心战场。在这里，需要将"数据泄露零容忍"这类抽象的安全战略转化为具体的控制措施：哪些数据需要加密、哪些系统要做脱敏处理、跨系统数据传输如何审计。这些决策如果在规划层没做好，到了落地层的修正成本会显著增加。
业务架构设计的价值在于，在技术方案之前先搞清楚"谁是利益相关方、他们要什么、业务流程怎么跑、核心能力是什么"。活动内容包括定义业务能力地图（识别企业核心能力）、梳理业务流程与价值流（端到端画出业务运转方式，识别价值创造点与摩擦点）、设计组织架构与角色职责。主要产出物包括业务架构蓝图（展示业务全景——能力、流程、组织、系统的关系）、业务能力地图（树状结构，按 TOGAF 惯例从能力层级 0 到层级 3 逐层细化）、业务流程图（标注角色、活动、决策点、异常处理）。
安全嵌入点：业务架构设计阶段，安全架构师需识别"敏感流程、关键数据、合规要求"。支付流程需做威胁建模，会员数据需分级保护，跨境传输需符合 GDPR/PIPL。此阶段的决策一旦固化，后续修改成本较高。
IT 架构设计的核心任务是：拿到业务架构的需求（如"支持特定并发量、特定可用性、特定服务时间"），设计出合适的应用架构、数据架构和技术架构。关键词是"合适"——不是最新的技术，而是最匹配业务复杂度与团队能力的架构。
活动内容包括设计应用架构（选择单体/微服务/Serverless，定义服务边界、通信方式、状态管理策略）、设计数据架构（确定数据存储方案，设计数据模型、分库分表策略、数据同步机制）、设计技术架构/基础设施架构（选择云平台、容器编排、中间件、DevOps 工具链）。主要产出物包括 IT 架构蓝图（展示业务-数据-应用-技术的映射关系）、技术栈选型决策文档（ADR，每个决策的理由和权衡分析）、集成架构设计。
常见误区：IT 架构设计脱离业务实际——选择了与业务复杂度不匹配的技术栈。日均订单量较低的业务系统盲目采用微服务架构，导致运维复杂度与成本激增。
安全嵌入点：IT 架构设计阶段，安全架构师需评估"技术选型带来的安全风险"。采用 Kubernetes 需考虑容器逃逸、镜像安全；采用微服务需考虑服务间认证、API 网关防护；采用云平台需考虑云安全基线、权限管理。架构选型阶段埋下的安全隐患，后续修复成本较高。
安全架构设计回答的核心问题是：在业务架构和 IT 架构确定后，如何设计一套安全控制体系，既能保护业务资产、满足合规要求，又不过度影响用户体验和开发效率？
活动内容包括设计安全控制框架（基于业务风险和合规要求，选择合适的安全框架，定义安全控制目标）、设计安全防护体系（从网络、主机、应用、数据、身份五个维度设计纵深防御体系）、威胁建模与风险评估（使用 STRIDE、PASTA 等方法，识别业务流程和系统架构中的威胁，评估风险优先级，制定缓解措施）、制定安全标准与基线。主要产出物包括安全架构蓝图、威胁模型文档（列出关键资产、威胁场景、攻击路径、现有控制措施、剩余风险）、安全控制矩阵、安全设计标准。
关键约束：安全架构设计必须与业务架构、IT 架构同步进行，而非等到落地层才介入。在规划层明确安全控制要求，后续的开发、测试、上线才能有章可循。
常见误区：安全架构"来晚了"——系统开发接近完成才介入安全评估，发现数据流转未控制、合规要求未考虑，导致大规模返工或带病上线。安全架构"过度设计"——脱离业务实际需求，设计过于复杂的控制体系，导致研发团队绕过或放弃执行。
架构评审的价值在于及早发现设计缺陷，降低后期修复成本。有效的架构评审应分阶段进行：概念阶段评审（评审整体思路、技术选型、关键假设是否合理，此时调整成本最低）、详细设计评审（评审详细的架构设计、接口定义、安全控制，确保方案可行）、实施过程评审（检查实际实现是否偏离架构设计，及时纠偏）、上线前评审（验证系统是否满足架构标准、安全基线、性能要求，作为上线的门禁）。主要产出物包括架构评审报告（详细的评审意见——哪些必须改、哪些建议改、哪些可接受）、架构决策记录（ADR）、风险与缓解措施清单。
常见误区：架构评审来得太晚——代码已写完、合同已签订、上线日期已定，此时发现问题只能"睁一只眼闭一只眼"放行，架构债务持续积累。
验证方法：检验架构评审有效性的指标包括评审发现的阻塞项在上线前的修复率、上线后因架构缺陷导致的事故数量。
路线图规划的核心原则是渐进式演进，每个阶段都在当前能力范围内，同时为下一阶段做能力储备。活动内容包括制定分阶段实施计划（基于组织现状能力，设计渐进式演进路径）、定义里程碑与验收标准（每个阶段有清晰的交付物、可量化的验收指标、明确的决策点）、规划资源与预算。主要产出物包括架构演进路线图（时间轴展示从当前状态到目标状态的演进路径）、实施计划、资源需求与预算。
常见误区：路线图脱离实际，未考虑组织能力的成熟度。IT 团队还在"手工运维虚拟机"水平时，路线图要求一步跳到"云原生微服务"，结果第一阶段就因预算超支、能力不足而卡住。
安全嵌入点：路线图规划时，安全团队需明确每个阶段的安全里程碑——第一阶段必须完成安全基线配置，第二阶段必须通过云安全评估，第三阶段必须实现自动化安全检测。
规划层是安全架构设计的核心层次，关键活动包括威胁建模、安全控制设计、安全架构审查、安全标准制定、安全工具与平台规划。
威胁建模的目的是识别业务流程与系统架构中的安全威胁。常用方法包括 STRIDE（微软 1999 年内部文档《The Threats To Our Products》提出，针对技术威胁）[3]、PASTA（UcedaVélez 与 Morana 于 2015 年出版的《Risk Centric Threat Modeling》系统化，以攻击者为中心、风险驱动的七阶段流程）[4] 和 LINDDUN（鲁汶大学 DistriNet 研究组提出，针对隐私威胁）[5]。产出物包括威胁模型文档、数据流图、攻击树、威胁清单与风险评级。
方法名清单不等于威胁建模能力——真正的建模是"画出数据流、标出信任边界、逐元素推导威胁、映射控制、记录残余风险"这一完整链条。下面以支付流程为例，做一次浓缩的 STRIDE 端到端示范，让读者看到方法如何落地。
第一步，画数据流图（DFD）并标注信任边界。支付流程的核心元素是：外部实体（用户浏览器/App）→ 进程（订单服务、支付网关适配器）→ 数据存储（订单库、密钥存储）→ 外部实体（第三方支付渠道）。信任边界至少有三条：公网与内网之间、订单服务与支付网关之间、企业系统与第三方渠道之间。信任边界正是威胁最集中的地方，因为跨边界的数据流意味着一次身份、完整性与授权的重新验证。
第二步，逐元素套用 STRIDE 六类威胁并映射控制与残余风险：
| STRIDE 类别 | 支付流程中的威胁示例 | 对应控制 | 残余风险 |
|---|---|---|---|
| S 仿冒（Spoofing） | 攻击者伪造用户身份发起支付 | 强身份认证（MFA）、mTLS 服务间认证 | 会话令牌被窃取后重放 |
| T 篡改（Tampering） | 篡改金额、收款方等支付参数 | 请求签名、服务端金额二次校验 | 服务端逻辑漏洞导致校验被绕过 |
| R 抵赖（Repudiation） | 用户否认发起过某笔交易 | 不可篡改审计日志、操作签名 | 日志被特权账号删改 |
| I 信息泄露（Information Disclosure） | 卡号/凭证在传输或日志中泄露 | TLS 1.3、日志脱敏、代币化 | 内存/缓存/备份中的明文残留 |
| D 拒绝服务（Denial of Service） | 刷单/洪泛耗尽支付通道 | 多维限流、渠道熔断 | 单维限流被代理池绕过（见 1.3） |
| E 权限提升（Elevation of Privilege） | 普通用户越权触发退款/结算 | 最小权限、关键操作二次授权 | 越权漏洞（IDOR）导致横向越权 |
第三步，把攻击链映射到 MITRE ATT&CK 战技术，让防御方与检测方使用同一套语言。例如"仿冒→凭证窃取"对应 Credential Access（TA0006），"篡改绕过校验后横向调用内部服务"对应 Lateral Movement（TA0008），"批量导出交易数据"对应 Exfiltration（TA0010）。ATT&CK 映射的价值在于：威胁模型不再停留在设计文档，而能直接转化为 SOC 的检测用例与红队的验证脚本。
适用边界：STRIDE 适用于技术系统的威胁分析；LINDDUN 适用于处理个人数据的系统；PASTA 适用于需要将业务影响与攻击可行性结合的风险决策。三者可组合使用。需要注意的是，STRIDE 诞生于单体架构时代，在微服务/云原生/AI 系统下存在适用局限：微服务的东西向调用、服务网格、Serverless 的短生命周期使"进程"与"信任边界"的边界模糊，每次拆分服务都会新增跨边界数据流；AI 系统还引入了提示注入、训练数据投毒等 STRIDE 六类难以直接覆盖的威胁（详见 15）。因此在这些场景下，STRIDE 需要与服务级威胁建模、ATT&CK 映射叠加使用，而非单独套用。
安全控制设计的目的是为识别的威胁设计对应的安全控制措施。控制框架通常包括预防性控制（阻止威胁发生）、检测性控制（发现安全事件）、响应性控制（处置安全事件）、补偿性控制（替代主要控制的备选方案）。
验证方法：控制设计的有效性通过红队测试、渗透测试验证——控制是否能阻断预期的攻击路径。
安全架构审查的目的是评审业务架构与 IT 架构的安全性，确保安全融入设计。审查要点包括身份与访问管理设计、网络隔离与分段、数据分类与保护、日志与可观测性、密钥与凭证管理、合规要求映射。
安全标准制定的目的是输出安全设计标准与实践指南，指导落地层实施。标准类型包括认证与授权标准、数据保护标准、API 安全标准、日志与审计标准、云安全基线。
安全工具与平台规划的目的是规划安全工具链与平台能力，支撑落地层实施。工具规划覆盖开发阶段（SAST、SCA、Secret Scanning）、测试阶段（DAST、IAST、API Testing）、部署阶段（IaC 扫描、镜像扫描、签名验证）、运行阶段（RASP、WAF、SIEM/XDR）。
规划层的安全架构师需要与"总部安全能力团队""业务经营团队""横向职能伙伴"形成稳定的三方协作机制，确保信息传导与资源保障。
下表展示三方协作的核心接口与机制，三类合作对象分别代表安全能力供给方、安全需求方、合规与资源保障方。
| 合作对象 | 核心接口人 | 协作目标 | 机制与节奏 |
|---|---|---|---|
| 安全中心各域团队（SecOps、威胁情报、平台、数据安全等） | 能力域负责人、产品经理 | 将总部安全策略/产品与业务场景对齐，快速落地控制措施 | 周度需求同步会、专项共创工作坊、季度能力路线图评审 |
| 业务经营团队（BU CEO、产品、研发、运营、市场、客服） | BU 总经理、产品/研发负责人 | 将安全嵌入业务全流程，实现"需求→设计→交付→运营"闭环 | 嵌入业务例会、OKR 共创、版本评审、QBR 汇报 |
| 横向职能团队（法务、合规、隐私、数据、HR、财务、内控） | CLO/CCO/CHRO、数据治理负责人 | 协调合规审查、证据治理、人才机制与预算资源，确保安全举措可执行 | 月度法规同步、合规评审会、年度预算/人力规划会 |
协作要点：在安全中心内部建立"安全业务伙伴双向窗口"，明确需求分类、响应流程与二线升级机制；与业务团队共建"安全+业务"联合行动计划（Joint Security Plan），纳入业务例会与绩效考核；与职能团队共享风险登记册、证据库与人才计划，实现法规变化、预算、绩效的一致性。
落地层是企业架构的执行层，其核心任务是将规划层的蓝图转化为可运行的系统。落地层的挑战在于"理想与现实的碰撞"：再完美的架构设计，如果落地时体验很差——安全扫描耗时过长、误报率过高——开发团队就会设法绕过。
落地层需要平衡安全与效率：自动化尽可能多的检查，降低误报，优化流程体验，使安全控制成为研发流程的自然组成部分，而非额外负担。
落地层的安全嵌入可遵循业务伙伴关系生命周期模型，将安全团队与业务的合作划分为五个阶段：
Discover（洞察）：参与业务战略、OKR、路线图讨论，识别潜在风险与合规需求，输出"机会/风险雷达"。
Define（定义）：共拟安全目标、优先级、成功指标，生成联合行动计划（Joint Security Plan）。
Develop（共创）：组织工作坊，将安全需求拆解为可执行任务，与安全平台、SecOps、隐私等团队协作交付。
Deliver（交付）：在产品迭代、产品上线、营销活动等场景执行 Playbook，确保控制措施落地并形成证据。
Review（复盘）：通过 QBR 或专项复盘评估成效，记录经验、沉淀知识、更新指标与行动计划。
建议为每个阶段配套标准工件（模板/表单/SOP）并在知识库中维护版本。
活动内容包括开发应用系统与服务（基于规划层的架构设计，实现业务逻辑、接口、数据模型）、实施微服务/API（遵循架构标准，确保服务间通信安全）、数据库与数据管道开发（落实数据分级加密要求）。主要产出物包括可部署的代码（经过代码审查、符合编码规范、通过静态扫描的生产级代码）、API 接口文档、数据库 Schema。
常见误区：规划层的安全标准未转化为开发团队能看懂的技术规范和代码示例，研发团队按自己的理解实现，到安全检查时发现不符合要求而返工。
安全嵌入点：开发阶段需有明确的安全编码标准，配合 IDE 插件实时提示——检测到不安全的哈希算法时提示替换，检测到 SQL 拼接时提示使用参数化查询。
验证方法：SAST 扫描通过率、代码审查中安全问题的发现率与修复率。
安全不是可以"事后加装"的模块，而是要在开发早期就嵌入架构。若规划层设计了统一的审计框架，开发层只需调用框架 API；若事后补，则面临日志格式不统一、关键操作遗漏、性能影响严重、存储成本失控等问题。
活动内容包括将安全控制集成到系统中（从架构层提供统一的安全组件）、实施认证授权模块（集成企业统一身份认证，实现细粒度权限控制）、实施数据加密与脱敏（落实规划层的数据分级要求）、集成日志与审计。主要产出物包括安全功能模块（经过安全测试验证的可复用安全组件）、安全配置文件、日志与审计记录。
关键约束：安全能力应平台化——由安全团队提供统一的安全中间件/SDK，各业务系统直接复用，既降低开发成本，又保证安全一致性。避免"项目制"的安全集成（每个项目各自实现一套认证、审计逻辑），导致安全能力碎片化。
安全测试应分层递进：开发阶段采用 SAST（代码提交时自动扫描，发现 SQL 注入、硬编码密钥等问题，修复成本最低）、集成测试阶段采用 DAST（系统运行后扫描，发现配置错误、未授权访问等问题）、预上线阶段采用 IAST（结合 SAST 和 DAST，在运行时检测漏洞）、上线前进行渗透测试（人工模拟攻击，验证自动化测试可能遗漏的复杂场景）。
活动内容包括功能测试（验证业务逻辑正确性）、性能测试（压力测试、负载测试）、安全测试（SAST/DAST/IAST/渗透测试）、合规性测试（对照合规 checklist 逐项验证）。主要产出物包括测试报告（详细的测试结果，包括测试用例、发现的问题、严重等级、修复建议）、缺陷清单与修复计划、测试覆盖率报告。
常见误区：安全测试误报率高导致团队不信任——若 SAST 扫描每次报告的问题中大多数是误报，开发团队会选择忽略。改进方式是持续调优扫描规则，降低误报，并建立快速反馈机制。
运行指标：SAST 扫描误报率、漏洞修复周期（从发现到修复的平均时间）、渗透测试发现的高危漏洞数量趋势。
现代化的部署上线应包含：基础设施即代码（用 Terraform/CloudFormation 定义基础设施，配置版本化管理）、自动化部署（CI/CD 流水线自动打包、部署、验证）、上线前检查（自动化检查清单）、灰度发布（先上线小比例流量，观察监控指标无异常后逐步放大）、应急预案（准备好回滚脚本、数据备份、应急联系人）。主要产出物包括生产环境系统（经过充分验证、配置正确、监控就绪的可用系统）、部署文档、上线检查清单。
常见误区：上线流程缺乏自动化和验证机制——手工部署容易出错，配置文件可能过期，上线前检查不充分，导致生产环境故障。
安全嵌入点：上线前必须完成安全基线检查——是否启用 HTTPS、是否修改默认密码、是否关闭调试端口、是否启用日志审计、是否配置 DDoS 防护等。这些检查应自动化，作为部署流水线的强制门禁。
运营维护应是"主动式运维"——靠监控、巡检、演练提前发现和预防问题，而不是等出了问题再修。
关键实践包括持续监控（实时监控系统健康，异常自动告警）、主动巡检（定期检查系统配置、日志清理、证书有效期、补丁更新）、补丁管理（建立漏洞管理流程）、应急演练（定期做故障演练，验证应急预案有效性）、持续优化（基于监控数据分析性能瓶颈、用户体验痛点、架构债务）。主要产出物包括运营报告、事件响应记录、性能优化建议、架构演进建议（反馈到规划层）。
关键约束：运营维护的挑战是人力有限而需求无限。解决方式是自动化一切可自动化的工作——自动化监控、巡检、补丁、扩缩容，让团队聚焦在真正需要人类判断的复杂问题上。
运行指标：系统可用性（SLA 达成率）、平均故障恢复时间（MTTR）、漏洞修复周期、安全事件响应时间。
围绕高频业务场景构建标准 Playbook，可显著提升交付质量与复用率。下表展示典型场景的 Playbook 要素，覆盖产品发布、营销活动、供应商管理、合规审查、海外扩张五类高频安全介入点。
| 场景 | 核心步骤 | 关键产出 | 安全团队角色 |
|---|---|---|---|
| 新产品/功能上线 | 需求梳理 → 风险评估 → 控制建议 → 放行决策 → 上线复盘 | 风险评估报告、控制清单、上线许可、复盘记录 | 牵头评估、协调安全专家、输出业务建议 |
| 市场/营销活动 | 活动清单 → 反作弊策略 → 系统压测 → 实时监控 → 复盘 | 活动安全清单、风控策略、监控计划、复盘报告 | 聚合数据、协调风控/反作弊、汇报高管 |
| 供应商/第三方接入 | 背景调研 → 安全评估 → 合同条款 → 持续监控 | 第三方风险评估、合同安全条款、整改计划 | 组织评估、审核条款、跟踪整改 |
| 合规/监管审查 | 需求解析 → 证据搜集 → 差距分析 → 策略执行 → 听证沟通 | 合规差距报告、证据包、整改计划、监管沟通纪要 | 协调资源、统一对外口径、保障整改进度 |
| 海外拓展或并购 | 法规调研 → 安全差距评估 → 文化与流程融合 → 过渡期守护 | 国别合规速查、整合计划、风险缓解方案 | 牵头法规评估、整合安全流程、汇报风险 |
Playbook 应包含"触发条件、所需输入、关键任务、责任人、产出模板、成功指标、常见风险"，并设置负责人定期更新。
在落地层，核心理念是安全左移——将安全活动前移到开发早期阶段，通过 SDL（安全开发生命周期）和 DevSecOps 实践，将安全融入研发流程。
SDL 将安全活动嵌入到软件开发的每个阶段。下表展示各阶段的安全活动与工具方法。
| 阶段 | 安全活动 | 工具/方法 | 产出物 |
|---|---|---|---|
| 需求分析 | 识别安全需求、数据分类分级、合规要求梳理 | 安全需求清单、STRIDE 威胁建模 | 安全需求规格、数据分类结果 |
| 设计阶段 | 威胁建模、安全架构设计、安全设计评审 | 威胁建模工具、STRIDE/PASTA | 威胁模型、安全设计方案 |
| 开发阶段 | 安全编码、代码审查、SAST 扫描、SCA 扫描、Secret 扫描 | SAST 工具、SCA 工具、Secret 扫描工具 | 代码扫描报告、依赖漏洞清单 |
| 测试阶段 | DAST 扫描、IAST 测试、API 安全测试、渗透测试 | DAST 工具、渗透测试工具 | 动态扫描报告、渗透测试报告 |
| 部署阶段 | 镜像扫描、IaC 安全扫描、配置基线检查、签名验证 | 镜像扫描工具、IaC 扫描工具 | 镜像扫描报告、配置合规报告 |
| 运营阶段 | 运行时监控、漏洞管理、事件响应、补丁管理 | RASP/WAF、SIEM/XDR、SOAR | 监控告警、事件响应报告 |
安全活动覆盖从需求到运营的完整周期，每个阶段都有明确的产出物作为下一阶段的输入或验收依据。
在 CI/CD 流水线中设置安全检查点，不合格的代码无法进入下一阶段。下表展示各阶段的门禁检查项与阻断条件。五个阶段是代码流转的关键节点，在这些节点设置检查可以最大化拦截效果同时最小化对开发效率的影响。
| 阶段 | 门禁检查项 | 阻断条件 | 责任人 | 豁免流程 |
|---|---|---|---|---|
| 代码提交 | Secret 扫描、依赖项安全检查 | 发现高危密钥、严重依赖漏洞 | 开发者 | 无法豁免，必须修复 |
| 代码合并 | SAST、代码审查 | 高危漏洞未修复、未通过安全审查 | Tech Lead | 需 CISO 批准，设定修复期限 |
| 构建阶段 | SCA、镜像扫描 | 严重漏洞或许可证违规 | CI/CD 系统 | 需安全团队评估 |
| 部署前 | DAST、配置审查、发布审批 | 关键安全控制缺失 | 安全团队 | 需架构委员会批准 |
| 生产环境 | 基线检查、合规扫描 | 严重偏离安全基线 | SRE 团队 | 需制定整改计划 |
门禁的严格程度随着代码接近生产环境而逐步提升，豁免流程也相应变得更加审慎。
验证方法：门禁有效性通过以下指标检验——门禁阻断率、门禁误报率、门禁绕过率。
核心理念包括 Shift Left（安全前移到开发早期）、Automation（安全检查自动化）、Collaboration（开发、安全、运维协同）、Continuous（持续的安全测试与改进）。关键实践包括安全即代码、策略即代码、自动化漏洞修复、安全反馈循环。
监控覆盖应包括应用层（WAF、RASP、API 网关日志）、网络层（流量分析、DDoS 检测）、主机层（EDR、HIDS）、云层（CSPM、CIEM）、数据层（DLP、数据访问审计）。
事件响应流程包括六个阶段：检测（通过 SIEM/XDR 发现安全事件）、分析（确定事件性质、范围、影响）、遏制（隔离受影响系统，防止扩散）、根除（清除威胁，修复漏洞）、恢复（恢复正常业务运行）、总结（复盘事件，改进流程）。
反馈到规划层：从事件中识别架构缺陷；更新威胁模型与安全控制；优化安全架构设计。
企业架构三层体系不是单向流动，而是通过反馈机制形成闭环：落地层的安全事件与运营数据反馈到规划层，驱动架构优化与威胁模型更新；规划层识别的系统性风险反馈到战略层，触发风险偏好调整与预算重新分配。缺乏反馈机制的架构体系会陷入"设计与现实脱节"的困境。
有效的协同依赖分层治理会议机制。下表展示"三层治理金字塔"的会议结构，战略层、战术层、执行层分别对应决策、协调、执行三类会议诉求，覆盖从高管对齐到日常推进的完整节奏。
| 层级 | 例会名称 | 频率 | 参与者 | 议题示例 | 安全团队输出 |
|---|---|---|---|---|---|
| 战略层 | 安全与业务联合委员会、季度 QBR | 季度 | CISO、BISO、BU 领导、法务、合规 | 战略目标对齐、重大风险、预算与资源 | 业务安全 KPI、重大风险缓解进度、资源需求 |
| 战术层 | 业务线安全例会、项目群例会 | 月度/双周 | 安全业务伙伴、业务负责人、安全专家 | 项目进度、需求优先级、例外决策 | 需求看板、Playbook 执行情况、例外建议 |
| 执行层 | 日/周 Standup、专项工作坊 | 每周/按需 | 安全业务伙伴、产品/研发、SecOps、隐私 | 具体需求推进、问题处理、培训宣导 | 行动列表、责任 RACI、阻塞点升级 |
结合会议体系输出一套"治理例程日历"，并在开始前提前发布议题与材料，确保决策效率。
从落地层到规划层的反馈：触发条件包括生产环境发生重大安全事件、安全测试发现架构设计缺陷、新威胁或新攻击手法出现、技术选型需要调整。反馈内容包括架构设计缺陷与改进建议、安全控制有效性评估、技术债务清单、威胁模型更新需求。
从落地层到战略层的反馈：触发条件包括安全投资 ROI 不达预期、业务目标与安全目标冲突、合规要求发生重大变化、组织能力与战略目标不匹配。反馈内容包括安全投资效果评估、业务影响分析、风险偏好调整建议、组织能力差距分析。
建立"三类指标"组合，确保安全价值可量化、可追溯。下表展示指标分类与汇报对象，结果类、过程类、体验类分别衡量最终成效、执行过程、服务体验，构成完整的度量视角。
| 类别 | 示例指标 | 度量方式 | 汇报对象 |
|---|---|---|---|
| 结果类（Outcome） | 重大风险敞口下降率、重大事件数量、监管罚款为零 | 风险登记册、事件库 | BU 经营会、董事会风险分委会 |
| 过程类（Process） | 需求 SLA 达成率、Playbook 执行率、例外关闭周期 | 服务管理系统 | 安全治理例会、IT 变更会 |
| 体验类（Experience） | 业务满意度、NPS、业务团队自助率 | 季度调查、服务台数据 | QBR、服务改进会 |
报告节奏：月报针对战术层，聚焦需求、项目进展、阻塞点；季度 QBR 重点呈现业务成果、风险趋势、投资回报、经验案例；年度报告总结战略成果、预算使用、人才成长、次年重点。对重大事件或监管关注项，在发生后尽快提供高管摘要（事件概况/影响/响应/诉求）。
下表总结了三层体系协同的关键成功因素，五个因素分别对应组织支持、流程融合、技术赋能、数据驱动、人才储备五个维度。
| 因素 | 说明 | 实践建议 |
|---|---|---|
| 高管支持 | 获得 CEO/董事会的明确支持 | 定期向董事会汇报安全状况；用业务语言说明安全价值；将安全纳入高管 KPI |
| 流程集成 | 安全流程与业务流程融合 | 避免平行流程；安全检查嵌入业务审批；建立"安全 BP"机制 |
| 工具自动化 | 减少人工干预，提升效率 | 优先投资安全自动化工具；建立 DevSecOps 文化；安全即代码 |
| 度量反馈 | 建立闭环的度量与改进机制 | 定期复盘安全指标；事件驱动的架构优化；从运营数据反馈到战略层 |
| 人才培养 | 提升团队的安全意识与能力 | 全员安全培训；Security Champions 计划；建立安全职业发展路径 |
表现：安全团队设计"技术完美"的方案，但无法回答 CEO 的问题——"能带来什么业务价值？""具体降低多少风险？""能帮我们拿下大客户吗？"
后果：安全预算被削减，安全团队被边缘化，业务部门把安全视为"阻碍者"，真正重要的合规认证反而无人推进。
改进建议：始终从业务价值出发；用业务语言说话；建立业务伙伴机制；量化投资回报。
表现：精美的架构图无法落地；安全标准停留在文档，无人执行；研发团队不理解安全架构的意图；架构设计与实际系统差距巨大。
后果：架构沦为"纸上谈兵"；安全控制未真正实施；架构文档失去价值。
改进建议：确保架构可执行、可验证、可度量；提供参考实现；建立架构合规检查机制；安全架构师深入研发团队提供技术支持。
表现：落地层的问题无法反馈到规划层；重复犯同样的安全错误；架构设计与实际威胁不匹配；安全工具与流程无法持续优化。
后果：安全体系无法改进；新威胁无法及时应对；安全投资效率低下。
改进建议：建立事件复盘与架构优化机制；定期回顾安全架构；从红队演练、渗透测试中识别架构缺陷；建立威胁情报反馈到威胁模型的流程。
表现：试图一次性构建完美架构；项目周期过长；技术选型陷入分析瘫痪；无法适应业务快速变化。
后果：项目延期或失败；业务机会错失；技术方案过时。
改进建议：采用敏捷方法，快速迭代优化；MVP 优先，逐步完善；优先解决主要问题；建立架构演进路线图，分阶段实施。
表现：安全业务伙伴（BISO/GSBP）沦为"流程挡板"或"背锅职能"；业务指标缺失，安全价值无法量化；合规与安全职责混淆，导致重复沟通。
后果：安全团队被动响应，无法主动规划；业务方对安全服务满意度低；人才流失严重。
改进建议：通过使命宣言与 RACI 明确职责边界；引入财务/业务 KPI 与满意度调查；明确与法务/隐私的接口与责任界面。
企业架构三层体系：战略层明确 WHY（业务目标与安全战略对齐）、规划层明确 WHAT（设计安全架构蓝图与控制框架）、落地层明确 HOW（将安全控制嵌入系统开发与运营）。
安全架构嵌入点：战略层参与战略制定、明确安全目标、定义风险偏好、争取预算支持、建立利益相关方地图；规划层进行威胁建模、安全控制设计、架构审查、标准制定、工具规划、三方协作机制；落地层实施业务伙伴关系生命周期、SDL 嵌入、安全门禁、Playbook 驱动、DevSecOps、持续监控与响应。
协同机制：战略层指导规划层，规划层指导落地层，落地层反馈到规划层和战略层，形成完整的持续改进闭环；通过分层治理会议机制（战略层/战术层/执行层）和三类指标体系（结果/过程/体验）确保协同透明可追溯。
关键成功因素：高管支持、流程集成、工具自动化、度量反馈、人才培养。
本节建立了企业架构三层体系框架，1.2 将深入业务架构阐述安全如何为业务创造价值，1.3 将详细介绍 IT 架构（TOGAF BDAT）与云时代的映射，1.4 将展示完整的安全架构全景。
后续章节（2–16）将基于本节的三层体系框架，分别深化各层的实践：第1部分（2–3）聚焦战略层的 GRC 治理与业务对齐；第2部分（4–7）聚焦规划层的技术架构设计；第3部分（8–10）聚焦规划层的数据架构设计；第4部分（11–13）聚焦落地层的运营与防御；第6部分（14–15）阐述 AI 支持各层能力提升；第7部分（16）聚焦组织与人才支撑。
| # | 来源 | 标题 | 日期 | 链接 |
|---|---|---|---|---|
| [1] | ISO | ISO 31000:2018 Risk management — Guidelines：将「确立风险准则」列为风险管理框架的规定动作 | 2018-02 | https://www.iso.org/standard/65694.html |
| [2] | NIST | NIST CSWP 29《The NIST Cybersecurity Framework (CSF) 2.0》：新增 GOVERN 职能，GV.RM-02「Risk appetite and risk tolerance statements are established, communicated, and maintained」 | 2024-02-26 | https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf |
| [3] | Loren Kohnfelder, Praerit Garg（Microsoft） | The Threats To Our Products：STRIDE 六类威胁分类的原始文档（微软官网已下线，由 Adam Shostack 存档） | 1999-04 | https://shostack.org/resources/early-threat-modeling |
| [4] | Tony UcedaVélez, Marco M. Morana | Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis (PASTA)，Wiley | 2015 | https://www.wiley.com/en-us/Risk+Centric+Threat+Modeling:+Process+for+Attack+Simulation+and+Threat+Analysis-p-9780470500965 |
| [5] | M. Deng, K. Wuyts, R. Scandariato, B. Preneel, W. Joosen（KU Leuven DistriNet） | A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements，Requirements Engineering 16(1): 3-32（LINDDUN 原始论文） | 2011 | https://link.springer.com/article/10.1007/s00766-010-0115-7 |
© 2025-2026 AISecOps Project. Licensed under CC BY-NC-SA 4.0