本节目标：建立企业架构体系框架的战略认知，阐述安全架构在企业架构中的定位与价值，为全书提供顶层逻辑与架构基础。
企业架构（enterprise architecture）的核心作用是在业务需求、技术实施和安全控制之间建立统一的决策语言。缺乏这一统一框架时，组织通常呈现以下症状：业务部门的需求描述与技术团队的理解存在偏差；安全评审在项目后期才介入，导致设计返工；跨部门协作依赖临时沟通而非结构化流程。
架构决策具有长尾效应。早期的技术选型和数据模型设计一旦固化，后续调整成本显著上升。这一特性使架构工作从纯技术议题上升为需要业务和技术负责人共同参与的战略决策。
将安全作为架构设计的后置环节存在结构性缺陷。典型问题包括：
业务连续性风险：核心业务系统的安全缺陷可能导致服务中断。对于交易类系统，中断时长与业务损失存在直接关联，但具体影响程度取决于业务峰值时段、客户类型和合同条款。
供应链攻击面扩大：企业使用的云服务、开源组件和第三方 API 形成了复杂的依赖关系，攻击者可通过供应链中的薄弱环节实现横向移动。典型攻击路径包括：第三方服务的配置缺陷、开源组件的已知漏洞、API 权限的过度授予。
合规成本累积：主要司法管辖区的数据保护法规（包括中国的网络安全法、数据安全法、个人信息保护法，欧盟 GDPR，美国各州隐私法）均对数据处理活动提出系统性要求。在架构设计阶段忽略合规需求，后期的改造成本通常高于前置设计。
预算论证困难：安全投资与业务成果之间缺乏可追溯的关联机制时，预算申请难以获得支持。
工具孤岛：缺乏整体架构规划时，安全工具的采购往往基于单点需求，导致数据互不相通、告警无法关联、实际使用率低于预期。
响应延迟：没有完整的架构视图（包括系统依赖、数据流向、第三方接口），安全评估需要逐系统梳理，显著延长项目周期。
运营负载失衡：告警量与可处理量的失衡是常见问题，其根源通常在于检测规则缺乏业务上下文、各工具之间缺少关联分析能力。
企业架构的三层结构提供了从战略意图到技术实施的逻辑链条。
三层结构及其安全嵌入点：
| 层级 | 核心问题 | 关键产出 | 安全角色 |
|---|---|---|---|
| 战略层 | 为什么做 | 业务战略、IT 战略、安全战略 | 识别战略性安全需求，参与业务战略讨论 |
| 规划层 | 做什么 | 业务架构、IT 架构、安全架构 | 安全架构设计、威胁建模、架构评审 |
| 落地层 | 怎么做 | 项目实施、运营优化 | SDL 集成、安全工具部署、运营指标监控 |
三个层级的划分依据是组织中不同的决策权限和时间跨度：战略层决策通常涉及董事会或高管团队，影响周期以年计；规划层由架构委员会主导，影响周期以季度计；落地层由项目团队执行，影响周期以迭代或发布周期计。
适用边界：该框架适用于具备独立 IT 治理职能的组织。对于完全依赖外包或纯 SaaS 化的小型组织，三层结构可能需要简化。
关键约束：三层之间的协调需要稳定的治理机制支撑，包括定期的架构评审会议、跨层级的信息同步流程。组织变动频繁时，层级间的对齐容易断裂。
常见误区：
- 战略层与规划层脱节：安全战略停留在文档层面，未转化为架构设计约束
- 规划层与落地层脱节：架构蓝图设计完成后缺乏执行监控，实际实施偏离设计
验证方法：
- 抽查最近三个重大项目，检查其是否经过架构评审流程
- 对比安全战略文档与实际架构设计，识别未落地的战略意图
安全工作需要用业务语言进行价值表述。以下框架提供了五个常用的价值维度：
| 维度 | 价值主张 | 指标类型 | 典型受众 |
|---|---|---|---|
| 资本维度 | 风险管理、保险成本优化 | 风险敞口变化、保险条款改善 | CFO、董事会 |
| 市场维度 | 合规准入、客户信任 | 认证获取、客户安全审计通过率 | CMO、销售负责人 |
| 用户维度 | 账户安全、隐私保护 | 账户安全事件率、隐私投诉率 | 产品负责人 |
| 技术维度 | 架构稳定、技术债务控制 | 漏洞修复周期、安全阻断率 | CTO、工程负责人 |
| 合规维度 | 监管合规、持续运营 | 审计缺陷数、合规覆盖率 | GRC、法务 |
五个维度覆盖了企业决策者关注的主要利益相关方视角。实际使用时，应根据组织的业务模式选择重点维度——ToB 企业的市场维度权重通常高于 ToC 企业，而金融类企业的合规维度权重普遍较高。
价值量化的实际困难：安全投资的 ROI 量化面临数据缺失和时间错位两个主要障碍。
数据缺失体现在：安全事件的发生概率难以精确估计，单次事件的损失范围（直接损失、声誉损失、机会成本）难以完整计算。ALE（年度预期损失）模型提供了一种结构化的估算方法，但其有效性依赖于历史数据积累和行业基准参考。
时间错位体现在：安全投资的收益通常滞后于投入。SDL 流程的漏洞预防效果需要经过完整的开发周期才能体现，这与业务部门按季度评估的节奏存在不匹配。
缓解策略：在长周期项目中设置短期里程碑，每个里程碑产出可观测的中间成果。零信任转型的第一阶段可聚焦于远程访问 MFA 覆盖率，该指标可在短期内改善并获得可见性。
TOGAF 的 BDAT 模型将企业 IT 活动分为四个架构层次，每层有对应的安全关注点和控制措施。需要说明的是，BDAT 是 TOGAF 标准定义的四个「架构域」（Architecture Domains），并非 ADM 的阶段划分——ADM 阶段 C 把数据与应用合并为「信息系统架构」，四域与八阶段不是一一对应关系[1]：
| 架构层 | 覆盖范围 | 安全关注点 | 典型控制措施 |
|---|---|---|---|
| Business | 业务流程、组织架构 | 业务连续性、欺诈检测 | BCP/DR、业务规则引擎 |
| Data | 数据资产、数据流、生命周期 | 数据分类、访问控制 | 加密、脱敏、审计 |
| Application | 应用组件、服务接口 | 安全开发、API 安全 | SAST/DAST、认证授权 |
| Technology | 基础设施、网络、平台 | 网络隔离、主机加固 | 网络分段、基线配置 |
云环境映射：BDAT 模型可映射到云服务的责任分担模型（shared responsibility model）——云厂商负责「云本身的安全」，客户负责「云中的安全」，分界线随服务模型（IaaS/PaaS/SaaS）上移[2]。
- Technology 层对应 IaaS（如 EC2、VPC），云厂商负责物理与虚拟化安全
- Application 层对应容器和 serverless 服务，客户负责代码与配置安全
- Data 层对应 PaaS 数据服务（如 RDS、对象存储），责任共担
- Business 层对应 SaaS 服务，客户主要负责业务流程配置和访问管理
适用边界：BDAT 模型适用于需要系统化梳理安全控制覆盖面的场景。对于单一产品线或技术栈简单的组织，可简化为更少的层次。
关键约束：四层之间的边界在微服务和 serverless 架构下变得模糊。Lambda 函数同时涉及 Application 层（代码逻辑）和 Technology 层（运行时环境）。实际使用时需明确边界划分规则。
三域划分：安全治理可按技术栈特性划分为三个域。
| 安全域 | 覆盖范围 | 技术特征 |
|---|---|---|
| 基础安全 | 网络、主机、身份、密钥 | 基础设施层面，变更频率相对低 |
| 应用安全 | SDL、API、微服务 | 与开发流程紧密耦合，变更频率高 |
| 数据安全 | 分类、加密、DLP、隐私 | 贯穿全生命周期，涉及多个技术层 |
三位一体治理模式：
| 治理维度 | 核心活动 | 关键产出 |
|---|---|---|
| 管理 | 策略制定、风险评估、合规审计 | 安全政策、风险报告、合规证明 |
| 技术 | 架构设计、技术选型、安全研发 | 架构蓝图、安全基线、安全组件 |
| 运营 | 威胁检测、事件响应、漏洞管理 | 运营手册、应急预案、漏洞处置 SLA |
三个维度相互依存：管理层面的策略需要技术层面的控制措施来落地，技术层面的产出需要运营层面的持续维护，运营层面发现的问题需要反馈到管理和技术层面进行改进。
零信任架构的核心假设是：不存在可信的网络边界，所有访问请求都需要验证。
五个设计原则：
身份为中心：访问控制从基于网络位置转向基于身份属性。实施要点包括：统一身份源、跨系统的身份联邦、基于属性的访问控制（ABAC）。
最小权限：默认拒绝，按需授权，定期复核。权限粒度应细化到具体资源和操作，而非角色包。
微隔离：网络策略粒度从 VLAN 级细化到工作负载级。实施复杂度与工作负载数量正相关。
持续验证：信任级别基于实时风险评估动态调整。评估因素包括：设备状态、访问位置、行为模式、时间特征。
假定攻陷：架构设计以"攻击者已在内部"为前提，要求在每一层部署检测能力，限制横向移动路径。
适用边界：零信任原则适用于有远程访问需求、多云部署或第三方协作场景的组织。对于物理隔离的封闭网络，实施优先级可降低。
关键约束：
- 用户体验影响：持续验证会增加认证频次，需平衡安全性与可用性
- 实施成本：微隔离需要梳理全部工作负载的访问关系，策略数量与系统复杂度正相关
- 遗留系统兼容：不支持现代认证协议（如 OAuth2、OIDC）的系统需要额外适配层
常见误区：
- 身份源被攻陷：集中化身份管理成为单点故障，需要额外保护（如特权访问管理）
- 策略配置错误：微隔离策略过于宽松或存在遗漏，失去隔离效果
- 检测盲区：持续验证依赖的遥测数据不完整，无法识别异常行为
验证方法：
- 红队测试：模拟内部横向移动，验证微隔离有效性
- 策略审计：定期审查权限配置，识别过度授权
- 遥测覆盖检查：验证各工作负载的日志和指标采集完整性
运行指标：
- 认证成功率与失败率：异常失败率上升可能指示攻击尝试或配置问题
- 策略命中分布：识别过于宽松或从未命中的策略
- 横向移动检测率：红队演练中横向移动尝试的检出比例
将安全活动嵌入企业架构的全生命周期：
| 阶段 | 安全活动 | 产出物 | 评审机制 |
|---|---|---|---|
| 战略规划 | 安全战略对齐、风险评估 | 安全战略规划、预算方案 | 安全委员会/董事会 |
| 架构设计 | 威胁建模、架构评审 | 安全架构蓝图、ADR | 架构评审委员会 |
| 开发实施 | SDL 流程、安全测试 | 安全需求、测试报告 | Gate Review |
| 部署上线 | 基线验证、渗透测试 | 上线检查清单、渗透报告 | 上线评审 |
| 运营维护 | 威胁检测、事件响应 | 运营报告、应急预案 | 定期运营评审 |
本章建立的框架与后续章节的映射关系：
| 章节 | 架构层对应 | 关系说明 |
|---|---|---|
| 第2章GRC 治理 | 战略层 | 风险管理框架、合规体系的详细设计 |
| 第3章业务安全伙伴 | 战略层 | BISO 模式、业务价值沟通方法 |
| 第4章安全架构工程 | 规划层 | 威胁建模方法论、架构评审流程 |
| 第5章云安全架构 | Technology 层 | 云安全治理、CSPM 实施 |
| 第6章应用安全架构 | Application 层 | SDL 流程、API 安全设计 |
| 第7章供应链安全 | Application 层 | SBOM 管理、CI/CD 安全 |
| 第8章-10：数据安全与隐私 | Data 层 | 数据分类、加密、DLP、隐私合规 |
| 第11章-12：安全运营与红队 | 落地层 | SOC 架构、攻防验证 |
| 第13章 业务风控与反欺诈 | Business 层 | 反欺诈、风控系统 |
| 第17章-15：AI 安全 | 横向能力 | AI 辅助检测、AI 系统安全 |
| 第19章安全领导力 | 战略层 | 组织建设、战略沟通 |
架构工作的落地依赖组织治理机制的支撑。
治理机制建设：安全架构决策应纳入企业架构评审委员会（ARB）的议程。CISO 或安全架构负责人应作为 ARB 的常设成员参与重大技术决策的评审。
业务语言转换：向非技术决策者汇报时，需将技术指标转换为业务影响。"部署 WAF 拦截攻击"转换为"保护交易系统可用性，支撑业务连续性目标"，是这种转换的典型示例。
KPI 设计：建议采用双层 KPI 体系。底层为技术指标（漏洞修复时长、检测覆盖率等），供安全团队内部管理；顶层为业务指标（安全相关业务中断时长、客户安全审计通过率等），供向高层汇报。
方法论培训：TOGAF、SABSA 等企业架构框架的培训可帮助安全团队建立结构化的思考方式。培训的价值不在于认证本身，而在于掌握架构设计和评审的方法论。
跨职能协作：安全架构师需要与企业架构师、业务架构师、应用架构师建立定期沟通机制。架构联席会的目的是同步信息、对齐术语、识别协作需求。
文档规范：ADR（architecture decision record）机制可解决架构决策的可追溯性问题。每个重大架构决策应记录：背景、备选方案、决策结果、决策理由。架构视图和依赖关系矩阵应随系统变更持续更新。
架构建模：ArchiMate 是 The Open Group 发布的企业架构建模语言（当前版本 3.2），与 TOGAF 同属 The Open Group 标准体系，适合与 TOGAF 框架配合使用[3]。对于起步阶段的团队，通用绘图工具配合统一的绘图规范也可满足基本需求。
合规自动化：policy as code 方法（如 OPA）可将架构规范编码为可自动执行的策略。CSPM 工具可持续扫描云环境配置，发现偏离基线的配置项。
架构可视化：手工维护的架构图容易与实际系统脱节。从 IaC 配置、服务发现或网络流量日志自动生成架构视图可提高准确性。
定期评审：建议每季度进行架构健康检查，重点关注技术债务积累情况、实际实施与架构蓝图的偏离程度。评审产出应包括架构债务清单和优先级排序。
成熟度评估：OWASP SAMM[4] 与 BSIMM[5] 等成熟度模型提供了结构化的评估框架。两者的定位不同：SAMM 是规范性模型（告诉你「应该做什么」，按 5 个业务功能 × 15 个安全实践 × 3 个成熟度级别自评），BSIMM 是描述性模型（统计真实企业「实际在做什么」，形成可对标的行业基线）——选型时先想清楚需要的是路线图还是对标数据。年度评估可追踪能力演进趋势，识别与行业实践的差距。
企业安全架构实践中的典型误区可归纳为三类：
组织协作类：
- 孤岛架构：安全架构与 IT/业务架构脱节，安全需求未进入架构评审流程
- 沟通失效：用技术术语向业务决策者汇报，无法获得理解和支持
执行管控类：
- 架构文档化：架构图和文档存在，但不指导实际决策
- 架构漂移：实际实施与架构蓝图偏离，缺乏持续的合规检查机制
战略认知类：
- 过度设计：追求理论完美，忽视实施可行性和业务节奏
- 量化缺失：安全投资无法与业务成果关联，难以证明价值
症状识别：架构评审会上业务部门缺席、架构文档长期未更新、项目绕过架构审批流程、安全议题在高管会议中被边缘化——这些现象通常是上述误区的外在表现。
缓解原则：将架构嵌入业务决策流程，而非游离于外。具体措施包括：架构评审作为项目审批的前置条件、建立业务价值翻译机制、安全架构师参与重大 IT 决策会议。
- 架构覆盖率：关键业务流程有完整架构文档的比例
- 架构评审率：重大项目经过架构评审的比例
- 架构偏离率：实际实施与架构蓝图的一致性（可通过 CSPM、配置审计工具度量）
- ADR 完整性：重大架构决策有 ADR 记录的比例
- 安全评审周期：新业务/产品的安全评审耗时
- 安全阻断率：因安全问题导致的项目延期或阻断比例
- 合规审计结果：客户安全审计、监管审计的缺陷数量和严重程度
- 跨职能协作频次：与业务/IT 架构团队的联合评审次数
- 架构培训覆盖：核心团队完成架构方法论培训的比例
绘制当前架构现状（as-is architecture），明确核心系统清单、系统间依赖关系、数据流向、现有安全控制点。同步识别架构债务和风险热点，包括过时技术栈、单点故障、缺少保护的数据流，产出架构债务清单。建立架构文档模板和评审流程，为后续工作提供规范依据。
适用边界：该阶段适用于具备独立 IT 治理职能的组织。对于完全依赖外包或纯 SaaS 化的小型组织，基线梳理范围可聚焦于供应商清单与数据流，而非内部系统架构。
关键约束：基线梳理需要跨部门协作，依赖 IT、业务、安全团队的信息输入。若组织缺乏资产管理基础数据，梳理周期会显著延长。
设计目标架构蓝图（to-be architecture），对齐业务战略和技术战略。制定架构演进路线图，明确阶段划分和优先级。路线图的时间跨度建议控制在可预见的范围内。
按优先级推进改进项目，优先选择影响大、实施难度相对低的项目，快速产出可见成果。建立持续的架构评审和合规检查机制，确保实施不偏离蓝图。量化架构改进的业务价值，建立安全工作与业务成果的关联。
定期进行架构成熟度评估，追踪能力演进趋势。关注技术发展和威胁态势变化，评估其对现有架构的影响。提炼和分享实践经验，包括成功案例和失败教训。
常见误区：
- 架构评估流于形式：评估报告产出后无人跟进整改，成熟度分数停滞不前。验证方法是对比连续两次评估的整改项关闭率。
- 过度追求完备性：试图一次性设计完美架构，导致项目周期过长、无法适应业务变化。应采用 MVP 策略，分阶段交付可验证成果。
验证方法：每阶段设定明确的里程碑与验收标准；通过 CSPM、配置审计等工具度量实际实施与架构蓝图的一致性。
运行指标：架构偏离率（实际配置与蓝图的差异比例）、架构债务关闭率（识别的债务项在目标周期内关闭的比例）。
企业安全架构实施需要平衡以下决策维度：
战略一致性：安全架构需嵌入企业架构治理流程。挑战在于跨部门语言体系差异，需要通过定期协调机制和统一文档规范来对齐。
价值可见性：安全投资需要转换为业务语言。在数据不充分的情况下，可通过分阶段展示中间成果来建立价值认知。
架构完整性：BDAT 四层模型和三域划分提供了覆盖检查的框架。云环境下的责任分担需要明确边界。
持续性：架构是动态演进的系统，需要通过定期评审和债务管理机制防止漂移。
权衡取舍：架构设计存在"完备性"与"可实施性"的张力。MVP 策略（最小可行架构加渐进式扩展）在实践中的适应性通常优于一次性完整设计。
残余风险与后续控制：本章建立的框架为后续章节提供了定位坐标。具体的控制设计、技术选型和运营实践将在各专题章节中展开——GRC 治理（2）、BISO 模式（3）、安全架构工程（4）等章节将分别深入各自领域的控制细节。
| # | 来源 | 标题 | 日期 | 链接 |
|---|---|---|---|---|
| [1] | The Open Group | The TOGAF® Standard, 10th Edition：定义业务/数据/应用/技术四个架构域（BDAT），ADM 阶段 C 将数据与应用合并为「信息系统架构」 | 2022-04-25 发布 | https://www.opengroup.org/togaf |
| [2] | Amazon Web Services | Shared Responsibility Model：云厂商负责「云本身的安全」，客户负责「云中的安全」 | 现行版本 | https://aws.amazon.com/compliance/shared-responsibility-model/ |
| [3] | The Open Group | ArchiMate® 3.2 Specification：企业架构建模语言，与 TOGAF 同属 The Open Group 标准体系 | 2022 | https://pubs.opengroup.org/architecture/archimate32-doc/ |
| [4] | OWASP Foundation | OWASP SAMM v2（Software Assurance Maturity Model）：5 个业务功能、15 项安全实践、3 个成熟度级别的规范性自评模型 | v2 现行 | https://owaspsamm.org/model/ |
| [5] | Black Duck（原 Synopsys SIG） | BSIMM（Building Security In Maturity Model）：基于真实企业观测数据的描述性对标模型，年度更新 | 年度更新 | https://www.blackduck.com/resources/analyst-reports/bsimm.html |
© 2025-2026 AISecOps Project. Licensed under CC BY-NC-SA 4.0