重新理解安全架构—从建设对象、成熟度到分层落地体系

前言

很多同行聊安全，很容易一步跳到 WAF、EDR、漏洞扫描、渗透测试这些工具；聊到”安全架构”，则众说纷纭——有人觉得是一张网络拓扑图，有人觉得是一摞等保文档，也有人把它等同于一套态势感知平台。

概念一旦模糊，落地一定走形。我见过太多次这样的场景：

• 一家不到 200 人的公司，被厂商一讲”可视化大屏”，买了态势感知 + SOC，装完之后没人看告警，一年后续费停掉，日志源只剩防火墙；
• 一家央国企，等保材料能堆满一整个文件柜，测评年年过，但生产环境的高危漏洞从发现到修复平均要 90 天，因为没有一条贯穿”发现—派单—修复—复测”的流程；
• 一家 3000 人的公司，安全负责人非常能干，架构图画得极漂亮，从零信任画到数据安全治理。但他下面只有 2 个人，图上 80% 的能力没有 owner，落地进度停在 PPT 第 12 页。

这三个案例的共同点，不是技术选型错了，而是跳过了两个前置问题：

1. 我们到底是给谁做安全架构？（建设对象）
2. 这个对象现在处在什么水平？（成熟度）

不回答这两个问题，任何架构都是”别人的架构”。所以这篇文章的顺序是：

章节	回答的问题	你可以得到什么
第一章	给谁做	按规模、按行业识别建设对象与约束条件
第二章	现在什么水平	一套可自评的四层成熟度模型
第三、四章	架构到底是什么	把抽象概念拆成看得见的分层与切面
第五章	怎么落地	从成熟度推导选型、路线图与预算分配
第六、七章	怎么表达、怎么避坑	架构图的画法与六类典型错配

阅读建议：如果你在中小厂，重点看 1.1、2.1、2.2、5.1；如果你在金融、央国企、政务，重点看 1.2、4.1、4.4；如果你已经在带团队做体系建设，第三、四、六章是重点。

---

一、安全建设的对象：规模 × 行业，两个维度交叉才是真实基线

安全架构没有万能模板。约束条件首先来自组织规模（决定你有多少人、多少钱、多少时间），其次来自行业属性（决定你必须满足什么、优先级如何排序）。两者交叉，才是真实的建设基线。

1.1 按组织体量划分

（1）小微企业：没有安全岗，安全是 IT 的副业

典型画像

• 人数 50300，IT 13 人，通常由运维兼安全，或者由研发负责人兼；
• 没有独立安全预算科目，安全费用挂在”IT 采购”或”项目成本”里；
• 一年的安全支出常见在几万元到几十万元区间，且多为一次性支出，不做年度续费规划。

安全诉求的真实来源

不是”我想做安全”，而是这四件事推着走：

1. 客户/甲方在合同里加了安全条款，要求提供等保备案证明或渗透测试报告；
2. 业务系统被监管扫描通报、被白帽子提交漏洞、被勒索病毒加密过一次；
3. 平台入驻审核（应用市场、云市场、招投标）要求安全资质；
4. 老板在新闻里看到同行的数据泄露事件，短暂地焦虑了一周。

一年真实的安全日历

时间	事件	谁在做
3 月	客户要求提供等保二级测评报告	找测评机构，临时补材料
6 月	新系统上线前做一次渗透测试	外包，出报告，改了几个高危
9 月	收到云厂商的漏洞告警/监管通报	运维连夜打补丁
11 月	大促前加固，临时买 WAF 高防	云上开箱即用
随时	员工点了钓鱼邮件、电脑中招	重装系统，没人复盘

能买什么、不能买什么

• 能买：云原生安全能力（云防火墙、WAF、主机安全、日志审计、堡垒机按量开通）、等保测评、单次渗透测试、按次应急响应、SaaS 化的漏扫与资产测绘。
• 不能买：SOC/SIEM、自建安全运营中心、7×24 自建值班、需要长期调参的复杂平台。不是买不起，是养不起——这类系统的价值 80% 来自持续运营，而你没有人运营。

架构约束

小微企业的架构目标不是”体系完整”，而是三句话：底线合规能过、常见攻击能挡、出了事有人兜。所以它的架构形态是”云上开箱能力 + 外部专家服务 + 一份自己的资产台账“。

这里有一个容易被忽略但极重要的原则：

能力可以外包，责任和台账不能外包。

外包团队能替你测、替你值守、替你应急，但不能替你回答”我有哪些资产、哪个最重要、谁负责”。而这三件事恰恰是安全架构的地基。我见过不少小公司，五年换了三家安全服务商，每次都要从零讲一遍自己的系统，这就是台账没留在自己手里的代价。

最常见的失败模式

买了一套”看起来很专业”的东西，但没有对应的运营动作。比如买了日志审计，从不看；买了堡垒机，运维嫌麻烦绕过去直连；做了渗透测试，报告锁在抽屉里，复测率 0。

（2）中型企业：1~3 人安全小组，一个人扛一条线

典型画像

• 公司 3003000 人，有明确的安全负责人（可能是”安全经理””信息安全负责人”），下面 02 名工程师；
• 安全团队通常挂在 IT 部、研发中心或技术中台下，不是独立一级部门，这意味着预算和话语权都受限；
• 安全预算开始按年度规划，常见量级在几十万到几百万。

这一层最真实的工作状态

不是”做体系”，而是同时打五份工。一个典型的安全负责人，一周可能是这样：

• 周一：投标支持，填甲方的 80 项安全问卷，写安全方案；
• 周二：给新版本做渗透测试，顺手审一下第三方组件的 CVE；
• 周三：跟进 37 个漏洞的整改进度，其中 12 个已经超期，要去催研发；
• 周四：等保整改，机房要加一台日志审计，走采购流程；
• 周五：业务被 DDoS 打了一下，拉会、处置、写复盘，晚上补周报。

这个阶段的核心矛盾

职责高度交叉 × 人手严重不足 × 流程全靠人肉推动。

具体表现为四个”断层”：

1. 资产断层：CMDB 一份、扫描器一份、云控制台一份，三份对不上，谁也不知道生产到底有多少台机器；
2. 流程断层：漏洞从发现到关闭靠微信群喊人，没有工单、没有 SLA、没有复测记录；
3. 数据断层：扫描器、WAF、EDR 各自有后台，出事了要人工登录四个系统拼时间线；
4. 人力断层：所有流程都长在负责人脑子里。他一休假，漏洞没人催、告警没人看、应急没人拍板；他一离职，体系直接归零。

最后这条，是中型企业做架构时最该优先解决的问题，却最常被忽略。所以对这一层，我给一个很具体的判断标准：

如果你的安全能力无法在负责人休假两周的情况下继续运转，那它就不是架构，只是个人能力。

架构约束与建设顺序

中型企业的架构必须轻量化、自动化、低运维成本。不是”少做”，而是”用人最少的方式做”。

推荐顺序（后面第五章会给完整清单）：

1. 资产自动发现 + 统一台账（先解决”我有什么”）；
2. 漏洞管理工单化 + SLA（解决”谁来改、多久改”）；
3. 上线卡点（CI/CD 里插安全门禁，把问题挡在发布前，而不是上线后救火）；
4. 基础监控与告警（WAF/EDR/云审计告警收敛到一个入口）；
5. 应急响应预案 + 联系人清单 + 一次真实演练。

不要做的：自建 SOC、自研扫描器、上 SOAR 编排、铺零信任全量改造。这四件事在这个阶段投入产出比极低。

（3）大型企业：独立安全部门，岗位开始细分

典型画像

• 安全团队 20~100 人以上，成立独立的安全部/安全中心，向 CTO、CIO 或 CSO 汇报；
• 岗位细分：资产与合规、应用安全（SDL/代码审计）、攻防（红队/渗透）、安全运营（SOC）、数据安全、基础安全（网络/主机）、供应链安全、安全研发；
• 年度预算千万级，工具链完整，通常会自研部分平台。

这一层真正的痛点，不是”缺能力”，而是”能力之间不通”

• 组织上的交叉：应用安全团队在做漏洞扫描，基础安全团队也在扫，结果两套数据、两个口径、两份报告，研发收到两份工单；
• 数据上的孤岛：资产在 CMDB、暴露面在扫描器、告警在 SIEM、漏洞在 Jira，没有一个统一的资产 ID 把它们串起来，导致”这个告警对应哪台机器、这台机器上有什么漏洞、这个漏洞的工单是谁在处理”要人工拼；
• 工具上的堆叠：WAF、IPS、EDR、XDR、HIDS、CWPP、CSPM、DLP……每引进一个工具就多一个后台、一套账号、一份报表；
• 度量上的失真：月报里全是”扫描了多少次、发现多少漏洞”这类过程数据，没有”风险收敛了多少、响应快了多少”这类结果数据，导致安全投入无法向管理层证明价值。

架构约束

大型企业的架构重点从”建能力”转为”打通数据、统一口径、标准化流程、可度量“：

• 统一资产唯一标识（这是所有集成的锚点）；
• 统一漏洞/事件/工单的数据模型与状态机；
• 统一权限与多租户隔离（安全平台自己也是被攻击对象）；
• 统一指标体系，让每个平台都能回答”我的产出对哪个业务指标有贡献”。

这里有个组织层面的规律值得写进架构文档——康威定律：系统的架构会镜像组织的沟通结构。如果资产团队和运营团队不坐在一个会上，你的资产平台和 SOC 平台就永远对不上账。所以大型企业做架构，一半是技术设计，一半是组织与流程设计。

规模维度对照表

维度	小微企业	中型企业	大型企业
安全专职人数	0	1~3	20~100+
组织形态	IT 兼管	挂在 IT/研发下的安全组	独立安全部门/安全中心
年安全预算量级	几万~几十万	几十万~几百万	千万级
主要驱动力	客户要求、被动救火	产品防护 + 客户准入 + 基础合规	攻击面治理 + 监管叠加 + 内控
典型能力	云上开箱 + 外包服务	轻量平台 + 自动化流程	集成平台 + 常态化运营
架构关键词	兜底	闭环	打通
首要矛盾	没人、没预算	人少事多、流程靠人	数据孤岛、工具堆叠
最大风险	出了事没人管	负责人一走体系断层	告警爆炸、风险不闭环

1.2 按行业属性划分

同样的规模，换一个行业，建设重心会直接反转。规模决定”能做多少”，行业决定”必须先做什么”。

（1）金融：合规是高压线，审计追溯优先于检测先进性

以银行、证券、保险、支付机构为例。

监管环境：等保（核心系统普遍三级，部分四级）、商用密码应用安全性评估（密评）、人民银行与金融监管总局的各类科技风险管理要求、证监会对证券期货业网络安全的专门规定、数据分类分级与个人金融信息保护规范。特点是规范密集、检查频繁、处罚明确。

技术与架构特征（这是最能体现”细节”的部分）：

• 网络分区极其严格：互联网接入区、DMZ、生产区、办公区、开发测试区、运维管理区，区间用防火墙隔离，策略变更要审批、要留痕；
• 生产区默认不能主动访问互联网，运维操作必须经过堡垒机，重要操作双人复核；
• 变更管理是龙头：变更窗口多在夜间，要求有回滚预案、有双人复核、有变更评审记录。做金融的安全架构，第一课不是攻防，是变更管理；
• 审计追溯要求高：数据库审计、业务操作审计、日志集中留存（网络日志按规定不少于六个月，金融行业往往更长），出问题要能还原”谁、什么时候、从哪、做了什么”；
• 上线前强制安全关卡：渗透测试、代码审计、安全评审，重要系统上线前必须通过；
• 年度固定动作：攻防演练、监管检查、应急演练、灾备切换演练；
• 灾备：同城双活、两地三中心是常见形态，RTO/RPO 有明确指标。

架构落地难点

1. 安全与业务连续性的冲突最尖锐——WAF 拦错一次交易，损失可能比漏洞本身大得多。所以金融的架构必须回答”误杀的兜底方案是什么“（旁路观察、灰度拦截、一键放行、回滚窗口）；
2. 老系统多、厂商多、耦合深，很多控制点只能”外挂”，不能”内嵌”；
3. 合规驱动强于风险驱动，容易形成”材料很完整、风险没收敛”的假象。

给同行的建议：在金融做安全架构，先把”证据链”和”变更流程”做扎实，再谈新技术。这里的架构价值，很大一部分体现在”可审计、可解释、可回滚“。

（2）央国企：多级法人、项目制建设、重保优先

典型结构：集团总部—二级单位—三级单位，多级法人，安全责任逐级落实。总部通常负责”定标准、建平台、做考核”，二级单位负责”落地、运维、上报”。

监管与要求：网信部门要求、国资监管考核、行业主管规范、等保、关键信息基础设施保护、保密管理（涉密网与非涉密网物理隔离）、信创与国产化替代、供应链安全。

这一层最典型的三个特征

1. “统建 + 分建”的架构形态：总部建统一平台（资产、SOC、态势感知），分支部署探针或日志回传，通过专线组网。架构图上必须标清楚”哪些能力在总部、哪些在分支、数据往哪流”；
2. 项目制带来的”重建设、轻运营”：立项—招标—实施—验收，验收之后运维预算和人员编制往往跟不上，平台变成”验收即巅峰”。这是央国企安全架构最大的结构性短板，做架构时必须在项目里就把运营预算、人员编制、SLA 写进去；
3. 资产庞大且分散：集团几十上百家单位，域名、IP、系统数量巨大，”三无资产”（无人认领、无人维护、无人知晓）是常态，资产梳理是长期工程而不是一次性项目。

架构落地难点：流程长、采购周期长、跨单位协同难；信创替代带来大量兼容性与重新测评工作；重保期间临时加压、平时资源不足，能力”潮汐化”。

（3）政府：预算差异极大，本质是两类完全不同的单位

政府单位不能用一句话概括，省直/地市/区县是三个世界。

高预算单位（省直、部分地市）

• 可自建安全运营中心，采购全套防护设备，组建或购买驻场运营团队；
• 重保任务多、规格高，全年有多个重点保障期；
• 架构形态接近大型企业：独立机房/专区、分区隔离、SOC 集中运营、常态化值守。

基层单位（多数区县）

• 预算紧张、IT 人手 1~2 人，普遍依赖政务云服务商 + 第三方驻场托管；
• 安全能力主要来自云上”开箱即用”的安全池（云防火墙、WAF、日志审计、堡垒机、主机安全、网页防篡改）；
• 目标非常朴素：系统别被篡改、别中断、别泄密、别被通报。

政务场景的架构共性

• 网络形态：政务外网、互联网区、专网隔离，跨网数据交换有专门通道和要求；
• 合规动作：等保测评 + 密评，这两年密评带来的改造工作量不小；
• 责任共担：用政务云时，”云平台安全”由云服务商负责，”云上系统安全”由使用单位负责，架构文档里必须写清这条边界，否则出事互相推；
• 考核压力：”零事故”导向，容易催生”一断了之”的防守习惯。好的架构应该给出可用的防守手段——限流、灰度、降级、备份快速恢复，而不是只有关机下线。

（4）互联网企业：业务驱动、快速迭代、资产高度动态

• 诉求几乎全部来自业务：防薅羊毛、防爬、防撞库、防数据泄露、保可用性、过应用市场与大客户审核；
• 资产高度动态（容器、弹性伸缩、Serverless、多活多 Region），资产自动发现是刚需，人工台账必然失效；
• 攻击面重心在应用层与 API：小程序、开放平台、第三方 SDK、供应链组件；
• 能力形态偏”左移 + 自动化”：SDL、SAST/DAST/IAST/SCA 进 CI/CD，安全能力 API 化，漏洞直接进研发的缺陷系统；
• 度量偏工程指标：MTTD、MTTR、漏洞逃逸率、拦截率、误报率。

（5）制造业：生产连续性第一，勒索是头号敌人

• IT 与 OT 融合，工控协议（Modbus、OPC 等）和老旧系统大量存在，很多设备根本打不了补丁；
• 一次勒索导致停产，损失按小时计算，所以安全目标排序是：不停产 > 不泄密 > 合规；
• 架构重点：办公网 / 生产网 / 工控网分层隔离，必要时单向隔离；对不能打补丁的设备用补偿性控制（微隔离、应用白名单、只读策略、离线备份）；
• 供应商远程运维通道是高频入口，必须收口到堡垒机 + 审批 + 录屏；
• 备份要能”恢复得回来”——很多企业有备份，但没做过恢复演练。

（6）医疗、教育：预算有限、勒索高发、数据敏感

• 等保二级/三级为主，经费有限，信息化外包程度高；
• 数据敏感（病历、学生信息），一旦泄露舆情压力大；
• 勒索病毒高发，且系统老旧、补丁困难；
• 架构重点不是”建大平台”，而是：账号与远程接入治理（外包运维是最大风险面）+ 备份恢复 + 终端防护 + 网页防篡改。

行业 × 规模：建设重心矩阵

	小微	中型	大型
金融	少见（多为分支机构，服从总行标准）	合规达标 + 上线测试 + 边界隔离	强隔离 + 全链路审计 + 灾备 + 常态化对抗
央国企	三级单位：跟总部标准 + 外包兜底	二级单位：标准落地 + 平台接入	总部：统建平台 + 考核 + 重保
政府	区县：政务云安全池 + 托管	地市：等保密评 + 监测处置	省直：自建运营中心 + 驻场 + 重保
互联网	云上开箱 + 外包渗透	自动化 + 左移 + 资产动态发现	自研平台 + 攻防体系 + 数据安全
制造	边界隔离 + 备份 + 终端	工控分区 + 勒索防护 + 供应链	IT/OT 统一治理 + 集团级监测

✅ 小结：
小微企业——外包兜底，守住底线；
中型企业——少量人 + 轻量化平台，支撑闭环；
大型/金融/省直政务——独立团队 + 集成平台 + 常态化运营；
央国企——强流程、强文档、重保优先，补齐持续运营短板；
制造业——连续性优先，隔离与备份先行。

把建设对象识别清楚之后，才有资格去谈”它现在处在哪个阶段”。这就引出了下一章的成熟度模型。

---

二、安全体系成熟度模型：四层，以及如何自评

这里不照搬 CMMI、CMMC，做一个适配国内甲方现状的简化四层模型：初始级 → 规范级 → 量化级 → 自适应级。

需要先说明三件事，否则这套模型很容易被误用：

1. 成熟度不等于规模。1000 人的公司可能停在 L1，200 人的公司也可能做到 L3——差别在于”能力是否被固化成流程和平台”，而不是人数；
2. 成熟度不等于投入。买了一堆设备但没人运营，依然是 L1；只用一个表格但每个漏洞都闭环，已经摸到 L2 的门槛；
3. 允许局部跳级。资产梳理可以一步做到 L3 水平，但运营体系往往必须从 L2 补起。不要为了”整体一致”而刻意压慢某一块。

2.1 L1 初始级：救火式安全，被动响应

核心特征：安全是”事件驱动”的——出漏洞、被通报、客户来审、中病毒，才动一下。

可观察到的具体症状（用这些判断，比看制度文件准得多）：

• 问”生产有多少台服务器、多少个域名”，三个人的答案不一样，且都说不全；
• 有资产台账，但最后一次更新是半年前，新上线的系统不在里面；
• 没有漏洞管理制度，漏洞来了拉个群、@ 一下开发，改不改、什么时候改，没人跟；
• 安全工具是零散的：WAF 有后台、云主机安全有后台、日志审计有后台，互相不通；
• 责任边界模糊：”这个系统归谁””安全归谁”说不清，出事第一反应是找厂商；
• 合规靠临时补材料，测评前一个月突击整改，测完恢复原样；
• 没有应急联系人清单，真出事靠”找人问”。

安全目标：不出重大事故、应付外部检查。
典型主体：绝大多数小微企业、部分基层区县单位、小体量 SaaS 厂商。
预算形态：按需、按次、项目制。

这个阶段最该做的三件事（顺序不能乱）：

1. 盘资产：云控制台 + DNS + 证书 + 扫描器 + 问业务，先把互联网暴露面拉出来，形成一份”能看、能更新”的表；
2. 补底线：备份可恢复、边界有防护、账号不共用、终端有杀毒；
3. 找一个能在 30 分钟内响应的外部支援：应急响应服务商 + 保险/保底方案。

2.2 L2 规范级：有制度、有流程、有专人，工作可重复

核心特征：从”人治”走到”有章可循”，同一件事两个人做，结果基本一致。

具体标志：

• 资产台账存在且有人负责，能区分核心/重要/一般资产，新系统上线有登记动作；
• 制度成文：安全管理、漏洞管理、变更管理、权限管理、应急响应；
• 有基础检测能力：定期漏扫、年度渗透、基线核查；
• 漏洞有闭环：有责任人、有 SLA、有复测记录（哪怕用表格 + 工单系统实现）；
• 合规常态化：不是测评前突击，而是把要求拆到日常动作里；
• 有应急预案，且至少演练过一次。

典型短板（也是 L2 向 L3 跃迁要解决的问题）：

• 一切靠人驱动：人一忙、一休假，流程就停；
• 没有统一平台，数据靠人汇总；
• 没有量化指标，”这个月安全情况怎么样”只能定性描述；
• 业务变更（上线、扩容、换域名）不会自动同步到安全侧，资产台账天然滞后；
• 告警靠人工看，看不过来就关掉一部分。

典型主体：多数中型企业、预算一般的央国企二级单位、部分地市政务单位。

2.3 L3 量化级：平台化承接，数据驱动，风险可度量

核心特征：能力被平台固化，管理靠数据说话。

具体标志：

• 资产自动发现 + 标签分级：云 API、扫描、流量、DNS 多源发现，资产变更有感知；
• 工具数据打通：扫描器、WAF、EDR、日志、代码审计、红队结果汇入同一平台，用统一资产 ID 关联；
• 风险可评分：漏洞严重性 × 资产价值 × 暴露程度 × 现有控制，输出可排序的风险清单，而不是一堆高危漏洞列表；
• 工单标准化：状态机清晰（待确认/已派单/修复中/待复测/已关闭/风险接受），SLA 明确；
• 指标持续统计：漏洞闭环率、平均修复时长、超期率、告警误报率、覆盖率、演练达成率；
• 安全左移：SDL 与安全评审嵌入研发流程，安全需求进需求池，而不是上线后补测。

典型短板：

• 规则偏静态：攻击手法一变种、业务一迭代，就要大量人工调参；
• 策略跟随”事件”调整，而不是跟随”业务变化”自动调整；
• 度量指标容易”指标化”——为了报表好看而优化数字，而不是优化风险。

典型主体：大型互联网企业、省级政务、头部城商行/券商。

2.4 L4 自适应级：风险自感知，策略自调整

核心特征：攻防形成闭环，架构与业务共生。

具体标志：

• 资产、业务、流量、威胁情报联动，业务上线/扩容时安全能力自动跟随（策略自动生成、探针自动部署）；
• 红蓝对抗常态化，红队结果直接转化为检测规则与防护策略（紫队机制）；
• 高风险事件可自动处置：隔离、限流、熔断、下线，且有回滚与人工兜底；
• 风险模型持续迭代，误报率与漏报率有基线并持续优化；
• 安全指标与业务指标打通，安全投入产出可评估（例如”每万元投入减少多少高风险暴露”）；
• 架构评审成为业务架构评审的固定环节，安全不是”后加的一层”，而是设计约束。

典型主体：头部大厂、国家级关键信息基础设施单位、头部总行、少数安全能力外溢的安全厂商。

2.5 怎么自评：12 个问题，0/1/2 打分

不要凭感觉定级，用下面这张表。每条按 0=没有 / 1=有但不稳定 / 2=稳定且可验证 打分，总分 0~24。

#	问题	0 分的样子	2 分的样子
1	能否在 10 分钟内说清互联网暴露面？	说不清	平台可查，且每日更新
2	资产是否有唯一 ID 和明确 owner？	台账三份对不上	全公司统一 ID，变更自动同步
3	新系统上线是否必经安全评审？	没有卡点	流程强制，未过不能发
4	漏洞是否有 SLA 和复测？	群里催	工单 + 超期升级 + 复测留痕
5	是否有统一告警入口？	多个后台	一处收敛，分级分派
6	告警是否有研判结论和处置记录？	看了就关	每条有结论，误报可回溯
7	是否有应急预案并演练过？	只有文档	年度演练 + 复盘改进
8	关键操作是否可审计追溯？	查不到	堡垒机 + 审计日志可还原
9	是否能给出风险排序而非漏洞清单？	只有高危列表	结合资产价值评分
10	是否有月度/季度安全指标？	没有	指标看板 + 趋势
11	安全能力是否在负责人休假时仍运转？	停摆	SOP + 值班可接续
12	红队/攻防结果是否转化为规则？	报告归档	规则上线并验证

判级参考：06 → L1；713 → L2；1419 → L3；2024 → L4。

这个表更大的价值不是算出分数，而是暴露出短板集中在哪一层。多数企业会呈现”资产 1 分、平台 2 分、运营 0 分”这种畸形分布——这正是下一章分层架构要解决的问题。

成熟度的核心价值：不攀比高阶能力，只选择匹配当前组织的安全架构方案。一个 L1 阶段的小微企业，强行落地 L3 的 SOC 集成架构，就是典型的架构错配。

---

三、核心讨论：安全架构到底是什么？如何具象化？

前面两章解决的是”给谁做、什么水平”。这一章解决最容易被讲糊的那个问题：安全架构到底指什么？它的边界在哪？

3.1 先把词拆开：架构 = 结构 + 关系 + 演进规则

“架构”这个词被用坏了。它至少包含三层含义，缺一层就不成立：

1. 结构：有哪些组成部分（资产、控制点、平台、角色）；
2. 关系：它们之间怎么连、谁依赖谁、数据往哪流、权限怎么划；
3. 演进规则：新增一个系统/一条业务线时，按什么规则接入；什么东西不允许出现；变更走什么路径。

很多人画的”安全架构图”只有第一层（一堆框），没有第二层（框之间没有数据流和信任边界），更没有第三层（没有约束规则）。所以图看着热闹，落地时无从下手。

3.2 给一个能落地的定义

安全架构，是一套围绕资产展开的约束、管控、检测、响应与持续优化的分层体系。它明确回答五个问题：保护什么、为什么保护、用什么能力保护、谁来运转、如何越做越好。

它由五部分咬合而成：

资产（对象） + 驱动（为什么） + 能力平台（用什么） + 运营体系（谁怎么干） + 反馈闭环（怎么变好）

它不是网络拓扑图（那只是其中一张图），不是设备清单（那只是能力层的一部分），也不等于等保文档（那只是合规驱动的产物）。

3.3 具象化方法一：四个视角看同一件事

抽象概念之所以抽象，是因为你只从一个角度看它。安全架构可以用四个视角分别”拍一张照片”，四张照片叠起来，概念就具体了。

视角一：资产视角——我有什么，哪个最值钱

把资产按”业务重要性 × 数据敏感度”排个序。这一步的产出是分级清单，不是清单本身。因为后面所有资源投入都要按这个排序来分配：核心资产配最强的控制，边缘资产用最低成本兜底。

视角二：攻击面视角——谁能打到我，从哪进来

把资产按”是否互联网可达”重新排一遍：直接暴露的（域名、IP、API、VPN、远程桌面）、间接暴露的（供应链、第三方、外包运维、员工终端）、内部横向的（弱口令、共享账号、过度授权）。

这两个视角的差集，往往就是事故的来源：你以为不重要所以没管，攻击者觉得很容易所以打了。

视角三：控制点视角——在哪些位置放了什么控制

在每一条数据流经的路径上标注控制点，并标注它的作用类型：

类型	作用	例子
预防	不让它发生	网络隔离、WAF、权限最小化、镜像加固
检测	发生了能知道	IDS、EDR、审计日志、异常行为分析
响应	知道后能处置	封禁、隔离、下线、取证
恢复	处置后能回来	备份、快照、灾备切换、回滚

一个成熟的控制点布局，不是”每个位置都堆满设备”，而是每类风险都有对应的预防+检测+恢复三件套。只有预防没有检测，等于闭着眼睛防守；只有检测没有恢复，等于知道要死但救不回来。

视角四：流程视角——一个风险从发现到关闭，经过哪些人、哪些系统

这条线走通了，架构才真正”活”起来。典型链路：

发现（扫描/告警/情报/人工）→ 确认（研判/复现）→ 定级（资产价值 × 可利用性）→ 派单（工单系统）→ 修复（研发/运维）→ 复测（安全）→ 关闭/风险接受（owner 签字）→ 复盘（是否要改规则、改架构）

这条链路上每换一次系统、每跨一个部门，就是一次”断点”。架构设计的一大半工作，就是消除这些断点。

3.4 具象化方法二：拿一条真实请求链路走一遍

抽象讲完，用一个具体例子把它落地。假设是一个电商下单请求：

用户 App/浏览器
  → CDN
  → WAF / DDoS 清洗
  → 负载均衡 SLB
  → API 网关
  → 订单服务（容器，K8s）
  → Redis（缓存）
  → MySQL（订单库）
  → 对象存储 / 消息队列
  → 第三方支付网关

现在在这条链路上逐个问四个问题：这里有什么资产？跨了几次信任边界？有什么控制？出问题怎么查？

位置	资产	控制点（预防/检测/恢复）	常见缺口
域名/DNS	域名、证书	证书到期监控、DNSSEC、解析变更审计	证书过期导致全站不可用
CDN	缓存、回源配置	回源鉴权、缓存投毒防护	源站 IP 泄露，CDN 形同虚设
WAF	策略、规则	规则防护、Bot 管理、日志留存	只开默认规则，不调优，误杀就整条关掉
API 网关	路由、AK/SK	认证鉴权、限流、参数校验、审计	内部接口未鉴权，越权访问
订单服务	容器、镜像、配置	镜像扫描、运行时防护、密钥管理	密钥写死在镜像/配置文件里
Redis	缓存数据	禁止公网、密码/ACL、持久化	未授权访问，被写入 SSH key
MySQL	订单与用户数据	最小权限、审计、加密、备份	共用高权限账号，审计缺失
对象存储	合同、发票、附件	Bucket 策略、防盗链、加密	Bucket 公开可读，数据裸奔
第三方支付	商户密钥、回调	签名校验、回调白名单、对账	回调未验签，可伪造支付成功

走完这一遍你会发现：

所谓安全架构，就是把这条链路上每个位置的控制点，按”谁负责、在哪一层、是阻断还是检测、出问题怎么查”固定下来，并保证新增链路时按同样的规则接入。

这就是”具象化”。它比任何定义都好用，因为你可以立刻拿自己公司的核心业务画一遍，缺口会自己冒出来。

3.5 边界：安全架构管什么，不管什么

概念不清，往往是因为边界不清。这一节直接把边界画出来。

必须管（架构的输出物）

1. 安全域与信任边界：哪些区域、区间怎么隔离、跨区怎么访问；
2. 控制点布局：关键路径上放什么控制、由谁运维、失效了怎么办；
3. 身份与权限模型：人、服务、第三方分别怎么认证授权，特权怎么管；
4. 数据流转与保护：数据从哪来到哪去、在哪加密、谁能看到、留存多久；
5. 检测与响应能力：日志从哪采、告警怎么收敛、事件怎么分级处置；
6. 运营流程与职责：谁负责什么、SLA 是什么、升级路径是什么；
7. 度量与演进规则：怎么衡量有效、新增系统怎么接入、什么不允许出现。

不该管（或只给约束、不管实现）

• 具体业务功能怎么实现（那是业务架构）；
• 服务器怎么装、网络怎么布线（那是 IT 基础设施运维）；
• 代码具体怎么写（架构只给”安全编码规范 + 卡点”，实现归研发）；
• 安全产品的内部实现原理（选型归架构，实现归厂商）。

一个判断边界是否清晰的测试：拿一个具体问题去问——“这个事归安全架构管吗？”

• “要不要给这个系统上 WAF” → 管（控制点布局）；
• “WAF 用哪个厂商” → 参与选型，但属于采购决策；
• “WAF 规则谁来调” → 管（职责与流程）；
• “WAF 的引擎怎么写的” → 不管。

边界清楚之后，架构文档才不会变成”什么都有、什么都不深”的百科。

3.6 和几个相邻概念的区别

这是读者最容易混淆的地方，单独列一张表：

概念	回答的问题	主要产出	与安全架构的关系
安全治理	谁决策、谁负责、政策是什么	组织、制度、责任矩阵、预算	给架构提供”授权与约束”
安全架构	结构怎么搭、控制点在哪、怎么演进	分层模型、域划分、控制矩阵、路线图	本体
安全技术体系	用什么组件、怎么部署	产品清单、部署方案、配置基线	架构在技术侧的实现
安全运营	每天怎么转、告警怎么处理	SOP、值班表、工单、指标	架构的执行层
安全体系	以上全部 + 制度 + 考核	完整体系文件与运转机制	最大集合，架构是其骨架
企业架构/IT 架构	业务与 IT 怎么组织	业务流程、应用、数据、技术架构	安全架构是其中的横向约束层

一句话记：治理定规则，架构定结构，技术定组件，运营定运转，体系是全集。

3.7 好架构的五条判断标准

给你一把尺子，用来评估自己和别人的架构方案：

1. 可描述：能用一页纸讲清楚，新来的同事 30 分钟能看懂；
2. 可裁剪：能按规模和成熟度删减，L1 用它的 20% 也能成立，而不是”全有或全无”；
3. 可落地：每个模块都有 owner、有交付物、有验收标准，不是只有名词；
4. 可度量：每个能力都能对应至少一个指标，能证明它有效；
5. 可演进：写清楚了”下一步加什么、什么条件下加”，而不是一次性设计到位。

反过来说，如果一份架构方案里出现大量没有 owner 的名词、没有指标的模块、没有先后顺序的清单，那它大概率是”抄来的”。

---

四、分层落地体系：五层结构 + 五个横向切面

这一章是全文的主体。前面讲”对象”和”水平”，这里讲”结构”。

先给总图，再逐层拆。

4.1 L0 基座层：网络、基础设施、资产——我们到底在保护什么

这一层是被保护对象，是所有安全工作的原点。它不”做安全”，它是”安全的宾语”。

资产清单要细到什么程度

很多人的资产清单只有”服务器”。这远远不够。实际需要覆盖的类别：

类别	具体对象	常见盲区
网络	出口链路、专线、VPN、SD-WAN、公网 IP、NAT 映射	临时开的映射、离职人员留的 VPN 账号
云	VPC、安全组、对象存储、负载均衡、API 网关、云函数	安全组 0.0.0.0/0、公开的 Bucket
计算	物理机、虚机、容器、镜像仓库、Serverless	测试环境、影子集群
数据	数据库、缓存、大数据平台、备份、日志平台	备份介质无人管、脱敏库未脱敏
应用	域名、证书、站点、API、App、小程序、公众号	测试域名、旧版接口、历史遗留站点
身份	员工账号、服务账号、AK/SK、第三方账号、特权账号	服务账号长期不过期、共用账号
终端	PC、移动设备、办公外设、BYOD	外包人员设备
OT/IoT	工控设备、摄像头、打印机、门禁	摄像头默认口令
供应链	开源组件、外包厂商、云服务商、SaaS	第三方 SDK 回传数据

台账的最小字段集

别追求大而全，先保证这 12 个字段，缺一个都会在后面某个环节卡住：

资产ID | 名称 | 类型 | 地址(IP/域名/URL) | 归属系统 | 业务负责人 | 安全负责人 | 业务等级 | 数据等级 | 是否互联网暴露 | 部署位置(云/IDC/办公) | 生命周期状态

后加两个”运营字段”，台账才活：数据来源(自动发现/人工登记) | 最后确认时间。

• 资产ID 必须唯一且稳定，它是后面所有平台关联的锚点；
• “最后确认时间”是防腐剂——超过 90 天未确认的资产自动标灰，逼着人去核。

资产工作的三步，别跳

1. 发现（测绘）：云 API、CMDB、扫描器、DNS、证书透明日志、流量、问业务。目标是把”影子资产”捞出来；
2. 登记（台账）：去重、合并、补 owner。这一步最枯燥，也最有价值；
3. 分级（定价值）：按业务重要性、数据敏感度、暴露程度打标签。分级不是为了好看，是为了决定资源投给谁。

网络与信任边界

资产之上是网络。这一层要回答的不是”网络怎么建”，而是”边界在哪、跨边界怎么控“：

• 分区：互联网接入区 / DMZ / 生产区 / 办公区 / 开发测试区 / 运维管理区 / 第三方接入区；
• 南北向：出入口收敛，默认拒绝，白名单放行；
• 东西向：生产区内部横向移动的防护（微隔离、主机防火墙、服务间认证）；
• 特殊通道：VPN、远程桌面、数据库直连、第三方运维通道——这四个是事故高发口，必须单独治理。

这一层的度量

指标	含义	参考目标
资产发现覆盖率	已纳管资产 / 实际资产	>95%
台账准确率	抽查一致的资产占比	>90%
互联网暴露面数量	公网可达的 IP/域名/端口/API	持续下降并基线化
高危暴露收敛时长	从发现暴露到关闭	严重 24h 内
影子资产数量	未登记但被发现	趋零

常见坑

• 只统计服务器，不管域名、API、证书、对象存储；
• 台账是”年度项目”，做完就冻结；
• 扫描器扫不到的东西就当作不存在（影子资产、内网遗留系统）；
• 分级只按”等保几级”，不看数据敏感度。

一个非常常见的误区：跳过资产梳理直接上防护设备。你都不知道要保护什么，WAF、EDR 不知道该管控哪些对象，安全架构就是空中楼阁。

4.2 L1 驱动层：合规驱动 vs 业务驱动——我们为什么做安全

安全建设只有两种原始动力：怕被罚（合规）和怕出事（业务）。绝大多数组织是两者混合，只是权重不同。权重不同，上层能力的取舍就完全不同。

合规驱动：把条款翻译成控制项

常见的合规来源（按适用性判断，不是全都适用）：

来源	主要关注	典型产出
网络安全法	等级保护、日志留存、事件报告	等保备案/测评、日志留存 6 个月以上
数据安全法、个人信息保护法	数据分类分级、告知同意、跨境、最小必要	数据资产清单、隐私政策、出境评估
等保 2.0（GB/T 22239-2019）	技术+管理双维度、十个安全类	定级备案、建设整改、测评报告
关键信息基础设施保护条例	关基识别、专门保护、年度检测评估	关基认定材料、保护计划
密码法 / 密评	商用密码应用合规	密评报告、密码改造
行业规范	金融、卫健、教育、证券期货等专项要求	行业检查、专项报送

关键动作：做一张”合规—控制—证据”映射表。这是合规驱动能否落地的分水岭。

合规条款（示例）	对应控制项	落地系统/动作	证据	Owner
身份鉴别要求	双因素认证、口令策略	IAM/堡垒机	配置截图、审计日志	基础安全
访问控制要求	最小权限、权限审批	权限平台	审批单、权限矩阵	基础安全
安全审计要求	日志集中、留存 6 个月	日志平台	留存策略、抽样日志	安全运营
入侵防范要求	边界防护、主机加固	WAF/IPS/HIDS	策略、基线报告	安全运营
数据完整性/保密性	传输加密、存储加密	TLS/密钥管理	证书清单、加密配置	应用安全

有了这张表，合规就从”测评前突击”变成”日常有据可查”。而且它天然是证据驱动的——检查时不用现编，平时就在产生。

业务驱动：把安全讲成钱

业务驱动的核心是损失模型。老板不关心 CVE 编号，关心的是”这事会让我损失多少”。所以要用业务语言表达：

风险场景	影响	量化口径（示例）	对应能力
勒索加密	停产/停业	每小时营收 × 停产小时数 + 恢复成本	备份恢复、终端防护、隔离
数据泄露	罚款 + 索赔 + 客户流失	监管罚款上限 + 客户流失率 × LTV	数据分级、权限、DLP、审计
业务中断	交易损失 + SLA 赔付	每分钟订单损失 + 赔付条款	高可用、DDoS 防护、限流降级
客户准入失败	丢单	单个大客户年合同额	等保、渗透报告、安全问卷
声誉事件	品牌与股价	难量化，用同级案例类比	监测、应急、公关联动

给老板汇报的正确句式：不是”我们发现 137 个高危漏洞”，而是”核心交易系统存在 3 个可被直接利用的高危问题，攻击者无需登录即可获取用户订单数据，按监管口径可能触发通报与处罚；修复需要 5 人日，本周可完成“。

驱动权重决定建设偏好

驱动权重	建设偏好	容易出现的偏差
合规为主（金融、央国企、政务）	制度、审计、隔离、证据链、测评整改	材料齐全但风险未收敛；重”可检查”轻”可对抗”
业务为主（互联网、制造、商贸）	漏洞闭环、入侵检测、应急、反欺诈、可用性	合规欠账；审计追溯能力弱，出事说不清
双轮（大型集团）	两套都要，靠平台统一承载	两套流程两张皮，重复投入

从驱动推导年度规划

一个可复用的推导链：

业务目标/监管要求 → 风险清单（Top 10）→ 控制目标 → 项目（能力建设）→ 预算与人力 → 指标（验收标准）

如果某个项目在这条链上找不到上游依据，那它大概率是”厂商推的”，不是”你需要的”。这是评审安全预算时最有效的一把刀。

4.3 L2 能力平台层：功能平台、技术平台、集成平台

这是大家最熟悉、也最容易混淆的一层。把能力拆成三类，概念立刻清楚。

（1）功能平台：单点能力，解决一个具体问题

按”预防/检测/响应/恢复”分类，列清单并标注局限：

能力	解决的问题	主要局限
防火墙/安全组	边界隔离、访问控制	管不了应用层，策略易腐化
WAF	Web 攻击拦截	绕过后无感知，需配合日志分析
IPS/IDS	网络层攻击检测	加密流量盲区，误报需调优
DDoS 防护	可用性	应用层 CC 需专门策略
漏扫	已知漏洞发现	覆盖不到逻辑漏洞，误报需人工确认
渗透测试	真实攻击路径验证	采样、有窗口期、不可持续
代码审计（SAST）	源码缺陷	误报高，需研发配合
交互式扫描（IAST）	运行时漏洞	需接入测试环境
组件分析（SCA）	开源组件风险	许可证与可达性判断难
EDR/HIDS	主机层威胁检测与响应	覆盖不全则形同虚设
堡垒机	运维操作管控与审计	绕过风险（直连）
数据库审计	敏感数据访问追溯	只审不防
DLP	数据外发管控	规则维护成本高，误拦影响业务
邮件安全	钓鱼、恶意附件	员工意识仍是短板
威胁情报	已知恶意 IOC 与上下文	情报质量与本地化适配
蜜罐	诱导与早期发现	部署位置决定价值
备份/容灾	恢复能力	没演练过的备份不算备份

判断一个”功能平台”该不该买，只问三句话：它解决我哪个 Top 风险？谁来运维它？失效了怎么发现？

（2）技术平台：承载流程，让管理动作有地方落

功能平台是”点”，技术平台是”线”：

• 资产管理平台：资产台账、分级、变更感知（一切的基础）；
• 漏洞管理平台：漏洞录入、定级、派单、SLA、复测、统计；
• SDL 平台：安全需求库、威胁建模模板、评审记录、卡点；
• 权限/身份平台（IAM）：账号生命周期、审批、最小权限、特权管理；
• 工单/流程平台：把事件、变更、评审、整改统一到一个状态机；
• 应急响应平台：预案、联系人、处置记录、取证留痕；
• 知识库：SOP、Runbook、历史事件、规则说明。

这类平台的价值不在技术含量，而在**把”靠人记”变成”系统推”**。中型企业优先建这一类，性价比远高于建 SOC。

（3）集成平台：数据收口与关联分析（高阶）

包括 SIEM/SOC、XDR、态势感知、SOAR。它的本质是一条数据流水线：

采集（日志/流量/终端/云审计/情报）
  → 解析与归一化（统一字段、统一时间、统一资产ID）
  → 富化（补资产信息、补情报、补漏洞上下文）
  → 关联与检测（规则、模型、行为基线）
  → 告警（分级、去重、抑制）
  → 编排与处置（剧本、自动封禁、工单）
  → 度量（MTTD/MTTR/误报率/覆盖率）

任何一个环节缺失，平台都会退化成”告警垃圾生成器”：

• 没有资产 ID → 告警说不清打的是谁；
• 没有归一化 → 同一个事件在三个系统里有三种写法；
• 没有富化 → 分析师要手工查五张表；
• 没有处置闭环 → 告警点完”已读”就消失了。

三类平台的关系与建设顺序

关系：功能平台产生数据，技术平台承载流程，集成平台做关联与调度。三者不是替代关系。

顺序建议：

1. 先有资产与漏洞管理（技术平台），哪怕是用开源 + 表格起步；
2. 再有 3~5 个稳定的功能平台，产生可靠数据源；
3. 当出现下面这些信号时，才考虑集成平台：
   • 日均有效告警超过几百条，人工看不过来；
   • 日志源超过 10 个、工具超过 10 套；
   • 有 2 人以上专职做告警研判；
   • 已经能说清”哪些告警必须处理”，只是效率低。

重点提醒：平台不是越高大上越好。L1、L2 阶段的组织，单点工具 + 简单工单，就足够支撑；L3 才需要投入集成平台做统一收口。

常见坑

• 日志源没接全就上 SIEM，最后只有防火墙日志；
• 买了 SOAR 没有剧本，自动化变成”自动发通知”；
• 平台上线了但没有数据治理，半年后没人敢用；
• 平台自己不做权限隔离，安全平台成了最大的越权入口。

4.4 L3 安全运营体系层：人、流程、职责、SOP

平台是工具，运营体系才是让安全持续运转的骨架。没有这一层，前面所有投入都是”资产”而不是”能力”。

组织与职责：先做 RACI，再谈编制

以漏洞管理为例：

环节	安全团队	研发/业务	运维	资产 Owner	管理层
发现	R/A	I	I	I	I
定级	R	C	C	C	I
派单	R	I	I	A	I
修复	C	R	R	A	I
复测	R/A	C	C	I	I
关闭/风险接受	R	C	C	A	C
复盘	R	C	C	I	A

R=执行，A=最终负责，C=被咨询，I=被通知。注意”最终负责”必须落在业务侧，而不是安全团队——安全团队负责发现和推动，业务负责修。这条不写清，漏洞永远修不完。

岗位设置：三种现实配置

配置	适用	分工
1 人	中型早期	一人全包：合规 + 渗透 + 运营 + 应急
3 人	中型成熟	A：合规与资产；B：应用安全与渗透；C：运营与应急
6~10 人	大型	应用安全、基础安全、安全运营（含值班）、数据安全、合规、安全研发

核心流程（必须有 SOP，不能只在脑子里）

漏洞管理流程（含 SLA 示例）：

等级	判定参考	临时缓解	修复时限
严重	可直接利用 + 互联网暴露 + 核心数据/交易	24 小时内	72 小时
高危	可利用，影响重要系统	3 天	7 天
中危	需前置条件，影响一般系统	—	30 天
低危	利用困难或影响很小	—	90 天或风险接受

事件响应流程（含分级）：

级别	示例	响应要求
P1	核心业务中断、数据泄露、勒索加密	15 分钟响应，1 小时内上报，立即拉应急群
P2	单系统被入侵、大面积钓鱼中招	30 分钟响应，2 小时内控制
P3	单主机告警确认、异常外联	4 小时内处置
P4	低风险告警、策略咨询	工作日处理

其他必备流程：变更安全评审、上线安全卡点、权限申请与回收、第三方接入、重保值守、应急演练。

值班：三种现实解法

方式	成本	适用	代价
自建 7×24 轮值	高（至少 4~5 人才能轮转）	大型、金融	人力成本高、夜班质量难保证
轮值 + 托管（MSS）	中	中型	需要清晰的升级与授权机制
完全托管	低	小微、基层	依赖服务商质量，自己要有判断力

度量：这一层的灵魂

指标	定义	说明
MTTD	从攻击发生到被发现	需要日志与检测能力支撑
MTTR	从发现到处置完成	反映流程效率，不只看技术
漏洞闭环率	期内关闭漏洞 / 期内新增漏洞	低于 1 说明在欠账
超期率	超 SLA 漏洞占比	最能反映业务配合度
误报率	误报告警 / 总告警	过高会导致”告警疲劳”
覆盖率	纳管资产 / 全部资产	所有指标的前提
演练达成率	完成演练的计划项 / 计划项	检验预案是否可用

抗拒离职风险：让体系脱离个人

这是中型企业最容易忽略的一点。三个具体动作：

1. SOP 化：每个高频动作写成一页纸（谁、什么时候、打开哪个系统、点什么、判断标准、升级给谁）；
2. 双人备份：关键流程至少两人会，交接有清单；
3. 平台留痕：所有判断和处置记录在系统里，而不是微信里。

4.5 L4 持续优化层：度量、复盘、对抗、演进

运营不是做完就结束，需要持续回流数据，反向优化整个架构。

输入来源

告警统计、漏洞闭环数据、红蓝对抗结果、安全事件复盘、内外部审计、威胁情报、业务变化（新业务、上云、出海、并购）。

四类动作

1. 度量与归因：不只看”做了多少”，要看”风险降了多少”。区分过程指标（扫描次数、告警数量）和结果指标（暴露面收敛、MTTR、逃逸率），后者才是决策依据；
2. 复盘机制：事件复盘（5 Why，落到流程与架构改动）、攻防复盘（红队路径 → 检测规则 → 加固）、项目复盘（投入产出）；
3. 对抗与狩猎：红蓝常态化、紫队协同（红队发现、蓝队建规则、共同验证）、威胁狩猎（假设已被入侵，主动找痕迹）；
4. 策略与架构迭代：检测规则的生命周期管理（上线—观察—误报治理—下线）、防护策略随业务变化调整、架构随新场景演进（上云、多租户、AI 应用）。

特别提三个”新增面”

• 数据安全与隐私：分类分级、流转地图、跨境、去标识化，正在从”合规项”变成”架构项”；
• 供应链安全：开源组件、外包厂商、云服务商，风险不在你机房但账要算在你头上；
• AI 应用安全：提示注入、数据泄露、模型与 Agent 的权限边界——这是这两年新增的攻击面，很多企业的架构里还完全没有它的位置。

一个判断”是否真的在优化”的标准

看架构文档是否有版本演进记录。如果一年下来架构图一次没改，说明要么业务没变（不太可能），要么复盘结果没有回流到架构（更可能）。

4.6 五个横向切面：资产管理、合规、检测、运营、风险防控

这五个不是”第六层”，而是贯穿所有层的五个镜头。理解这一点，整个模型就通了。

切面	本质	输入	输出	关键指标	L1→L4 的形态变化
资产管理	知道保护什么	CMDB、云 API、扫描、DNS、流量	唯一台账 + 分级 + owner	覆盖率、准确率、暴露面	表格 → 平台 → 自动闭环
合规	满足外部约束	法规、标准、检查、客户审计	控制矩阵、证据、整改计划	符合率、整改及时率	突击补材料 → 常态化 → 自动取证
安全检测	用攻击视角找问题	资产、情报、业务变更	漏洞、攻击路径、检测规则	高危发现、复测通过率、逃逸率	年度渗透 → 定期 → 持续/众测
安全运营	让能力持续运转	告警、工单、事件	处置结果、SOP、指标	MTTD、MTTR、闭环率、误报率	救火 → 流程 → 平台化 → 自动化
风险防控	做取舍与决策	以上全部 + 业务影响	风险登记册、评分、处置决策	剩余风险、Top 风险收敛	拍脑袋 → 清单 → 量化 → 预测

为什么必须是横向？

因为它们是看问题的角度，不是建设的堆叠。同一台服务器，从资产切面看是”一条记录”，从合规切面看是”一个测评对象”，从检测切面看是”一个攻击目标”，从运营切面看是”一个告警来源”，从风险切面看是”一个风险载体”。五个角度合起来，才是一个完整对象。

如果把它们做成纵向的”五个模块”，就会出现典型的组织病：资产团队做的台账，合规团队不认；合规要的证据，运营团队不产生；检测发现的漏洞，风险团队不知道。横向切面的意义，就是强制这些能力在同一条数据链上对齐。

非常关键的一个澄清：很多人把安全架构理解成”从上往下堆叠设备”。但真实逻辑是：底层资产是根，驱动决定方向，平台是工具，运营才是骨架，优化形成闭环；五大模块是横向切面，不是纵向层级。这个逻辑理顺了，概念就不会混。

---

五、落地：从成熟度推导架构选型与路线图

前面三章是”看懂”，这一章是”落地”。核心方法四步：

1. 识别对象：规模 + 行业 → 约束条件；
2. 评估成熟度：用 2.5 的 12 题打分，找出短板集中在哪一层；
3. 裁剪能力：按下面的矩阵删减，只保留”当前阶段能运转”的部分；
4. 排路线：先补底层（资产），再补流程（漏洞/应急），最后上平台（集成），不要倒着来。

5.1 三套典型方案

方案 A：小微企业（目标 L1 → L2，年投入量级：几万到几十万）

优先级	建设内容	具体做法	验收标准
P0	资产台账	云控制台导出 + DNS/证书 + 漏扫发现，一张表，季度更新	能 10 分钟说清暴露面
P0	备份可恢复	核心数据每日备份 + 每季度恢复演练一次	能在 4 小时内恢复
P0	边界与账号	云防火墙 + WAF 默认规则 + 禁止账号共用 + 开启 MFA	无 0.0.0.0/0 高危端口
P1	基础合规	等保二级测评 + 整改闭环	测评通过，问题闭环
P1	检测与应急	年度渗透 + 主机安全 + 应急服务商联系方式	高危漏洞全部修复
P2	意识与终端	钓鱼演练、终端杀毒、补丁	中招率下降

明确不做：SOC、态势感知、自建值班、零信任全量改造。

方案 B：中型企业（目标 L2 → L3，年投入量级：几十万到几百万）

优先级	建设内容	具体做法	验收标准
P0	资产自动发现	云 API + 扫描 + 流量，多源合并，唯一 ID	覆盖率 >95%，月度更新
P0	漏洞工单化	漏洞平台/工单系统 + SLA + 超期升级	闭环率 >90%，超期率 <10%
P0	上线卡点	CI/CD 接入 SAST/SCA/镜像扫描	高危不放行
P1	告警统一入口	WAF/EDR/云审计告警收敛，分级分派	无一告警多平台
P1	应急体系	预案 + 联系人 + 年度演练 + 外部支援	一次真实演练达标
P1	合规常态化	合规-控制-证据映射表	检查时无需临时补
P2	检测增强	季度渗透 + 关键系统代码审计	高危清零
P2	度量看板	5~8 个核心指标月度趋势	能向管理层汇报

明确不做：自研扫描器、SOAR、全量零信任、自建 SOC。

方案 C：大型/金融/省直政务（目标 L3 → L4）

优先级	建设内容	关键点
P0	统一资产底座	唯一 ID 贯穿所有平台，变更自动同步
P0	集成平台（SOC/SIEM）	数据源接全、归一化、富化、告警治理
P0	运营中心与值班	分级研判、SLA、升级机制、值班质量考核
P1	SDL 左移	需求—设计—编码—测试—上线全流程卡点
P1	数据安全体系	分类分级、流转地图、加密与脱敏、审计
P1	红蓝对抗常态化	年度至少两轮，结果转规则
P2	自动化响应（SOAR）	先做 3~5 个高频剧本，跑通再扩
P2	度量与成本优化	结果指标 + 单位风险收敛成本

5.2 12 个月节奏（以中型企业为例）

阶段	重点	交付物
第 1~2 月	资产盘点 + 暴露面收敛	台账 v1、暴露面清单、紧急风险清单
第 3~4 月	漏洞流程 + 上线卡点	漏洞 SOP、工单、CI/CD 门禁
第 5~6 月	边界与账号治理	分区策略、堡垒机全覆盖、MFA
第 7~8 月	监控与告警收敛	统一告警入口、分级规则
第 9~10 月	应急体系 + 演练	预案、联系人、一次演练报告
第 11~12 月	合规复盘 + 年度规划	合规证据包、指标年报、下一年路线

5.3 六种典型架构错配

1. L1 上 SOC：日志源不全、无人研判，最后只剩一块大屏；
2. 只买设备不管账号：EDR 装了一半、堡垒机被绕过、服务账号长期有效，控制点形同虚设；
3. 合规完成 = 安全完成：测评通过但高危漏洞长期存在，一打就穿；
4. 人少却照搬大厂架构：图上 20 个模块，实际 owner 只有 2 个人；
5. 平台先行、资产欠账：平台上线半年，资产台账还是 Excel，所有告警都对不上对象；
6. 流程上墙、执行靠人：制度写了 80 页，实际全在微信群推进，没有系统留痕。

这六种错配的共同点：**都在回答”用什么”，却没有回答”给谁用、谁来运转”**——正好回到文章开头的那两个前置问题。

---

六、把架构画出来：四张图 + 三条原则

架构如果不能被表达，就无法被评审，也无法被传承。给一套最小可用的画法。

6.1 四张必需的图

图	回答的问题	画法要点
① 分层能力图	我们有哪些能力、分几层	就是你上面看到的分层总图，标注 owner 与建设状态
② 资产—控制点矩阵	关键资产在哪些位置被什么控制保护	行=核心资产/系统，列=预防/检测/响应/恢复，格=具体控制
③ 数据流与信任边界图	数据从哪到哪、跨了哪些边界	画数据流而不是设备；每条跨边界处标控制点与协议
④ 运营流程图	一个风险/事件怎么流转	泳道图：安全/研发/运维/业务/管理层，标 SLA 与升级点

6.2 三条原则

1. 一页纸原则：总图必须能在一页内讲完。细节用分图，不要把 50 个框塞进一张图；
2. 图例统一：控制类型（预防/检测/响应/恢复）、边界类型、数据等级，用固定颜色与形状，全公司一致；
3. 每个框都有 owner：没有 owner 的框，要么删掉，要么标为”规划中”，不要假装它存在。

6.3 一个最小架构文档结构

如果要从零写一份安全架构文档，用这 8 节就够：

1. 建设对象与约束（规模、行业、监管、预算）；
2. 当前成熟度评估（12 题打分 + 短板）；
3. 保护对象清单（资产分级、暴露面）；
4. 信任边界与域划分；
5. 控制点矩阵（资产 × 控制类型）；
6. 能力平台清单（功能/技术/集成，含 owner 与状态）；
7. 运营流程与指标（SOP 索引、SLA、看板）；
8. 演进路线（12 个月 + 三年）。

---

七、常见误区整理

1. ❌ 安全架构 = 买一套态势感知平台
   ✅ 平台只是能力层组件。没有资产、没有运营 SOP，平台就是告警垃圾生成器。

2. ❌ 所有企业都要做 SDL、红蓝对抗
   ✅ L1/L2 阶段投入红蓝对抗性价比极低，优先守住底线漏洞和勒索防护。红蓝对抗适合”基础已经扎实、需要验证检测能力”的组织。

3. ❌ 合规做完就等于安全架构落地
   ✅ 合规是最低底线。等保达标的系统依然可能存在高危漏洞，因为测评是抽样、是时点、是基线要求。

4. ❌ 安全团队越大，架构越完善
   ✅ 人再多，职责交叉、数据孤岛、流程不通也是低效。大型企业真正的瓶颈往往不是人，是没有统一的资产 ID 和统一的状态机。

5. ❌ 资产梳理是一次性工作
   ✅ 资产随业务上线、上云、扩缩容持续变化。资产管理的本质是持续运营，不是年度项目。

6. ❌ 工具越多越安全
   ✅ 工具越多，盲区越多（没人看的部分就是盲区）。每增加一个工具，要同时回答：谁运维、数据进哪、告警谁处理。

7. ❌ 安全是安全部门的事
   ✅ 安全部门负责发现、推动、度量；修复和业务决策必须落在业务侧。RACI 里”最终负责”给错人，流程一定推不动。

8. ❌ 零信任是一套产品
   ✅ 零信任是一种架构原则（不默认信任、持续验证、最小权限）。买一堆产品而不改身份与权限模型，只是贵一点的边界防护。

9. ❌ 上了自动化就能减少人
   ✅ 自动化减少的是重复劳动，增加的是对规则与剧本的维护要求。没有稳定的流程，自动化只会更快地制造错误。

10. ❌ 架构设计一次到位，之后照着执行
    ✅ 架构是跟着成熟度演进、跟着资产变化、跟着业务驱动持续生长的。一年没更新的架构图，基本等于没有架构。

---

八、结语

安全架构这个概念之所以模糊，本质是我们常常跳过”保护对象”和”成熟阶段”，直接去讨论上层技术组件。

把顺序倒回来，一切就清楚了：

• 先看清给谁做——什么规模、什么行业、什么监管、什么预算；
• 再评估在什么水平——L1 到 L4，短板在哪一层；
• 然后理解架构是什么——资产为根、驱动定向、平台承载、运营落地、优化闭环，五个切面横向贯穿；
• 最后才谈选什么、先做什么——按成熟度裁剪，按路线推进。

安全架构的终极目标，不是做到绝对无漏洞，而是让组织对自身攻击面、风险、管控手段有持续、清晰的感知，并且拥有可控、可迭代的风险收敛能力。

如果读完只记住一句话，我希望是这句：

架构不是画出来的，是长出来的；但能不能长对方向，取决于你一开始有没有看清自己是谁。

---

附录：术语速查

术语	含义
攻击面	攻击者可以触达并利用的资产与入口总和
信任边界	不同信任级别区域之间的分界，跨边界需控制
MTTD / MTTR	平均发现时间 / 平均响应处置时间
SLA	服务级别约定，此处指漏洞或事件的处置时限
RACI	执行/最终负责/被咨询/被通知的责任分配矩阵
SOC / SIEM	安全运营中心 / 安全信息与事件管理平台
SOAR	安全编排自动化与响应
XDR	跨端点、网络、云、身份的扩展检测与响应
SDL	安全开发生命周期
SAST/DAST/IAST/SCA	静态/动态/交互式应用安全测试、软件成分分析
MSS / MDR	托管安全服务 / 托管检测与响应
补偿性控制	无法直接修复风险时，用其他控制手段降低风险