2. 企业网络与业务资产梳理

安全架构设计的第一步不是选设备、画拓扑,而是把“要保护什么”说清楚。资产梳理的产出直接决定后续边界划分、访问控制策略、日志采集范围和应急响应优先级。本节围绕三件事展开:资产如何分类分级、业务流与数据流如何识别、资产清单与责任矩阵如何落地。

一、资产分类:先按“形态+归属”建立骨架

资产分类的目标是让每一类资产都有统一的命名、归属和管控口径。企业网络中常见的资产可按以下维度归类:

  • 网络与安全设备:核心交换机、汇聚/接入交换机、路由器、防火墙、WAF、负载均衡、VPN 网关、IDS/IPS、堡垒机。
  • 计算与存储资源:物理服务器、虚拟机、容器节点、数据库实例、对象存储、备份存储。
  • 应用与中间件:Web 应用、API 网关、消息队列、缓存、认证服务、DNS、NTP。
  • 终端与办公资产:员工 PC、笔记本、移动终端、打印机、视频会议终端。
  • 数据资产:客户信息、订单、财务、合同、源代码、日志、密钥与证书。
  • 账号与权限资产:域账号、特权账号、服务账号、API Key、第三方接入账号。

分类不是目的,分类后要能回答“谁负责、在哪、暴露面多大、坏了影响谁”。因此建议每类资产至少绑定:资产编号、名称、类型、所属业务系统、部署位置(机房/云/办公区)、IP 或域名、责任人、运维人、生命周期状态。

二、资产分级:用“影响度×敏感度”定级

分级决定防护强度。推荐采用“业务影响度 + 数据敏感度”双维度定级,避免只按设备类型拍脑袋。示例分级规则如下(示例参数,企业可按自身情况调整):

级别判定要点典型资产基本要求
L4 核心中断直接影响对外交易或监管合规,数据含大量个人敏感信息核心交易库、支付网关、核心防火墙双活/冗余、最小权限、全量审计、变更双人复核
L3 重要中断影响内部关键流程,数据含客户或财务信息ERP、CRM、域控、堡垒机冗余、集中日志、季度权限复核
L2 一般短时中断可容忍,数据敏感度中等内部 OA、测试环境、部门文件服务器基线加固、月度补丁、日志留存
L1 低影响面小,数据可公开或已脱敏公共展示页、访客网络设备基础防护、按需审计

定级时建议给出可复核的打分:业务影响度 1~5 分,数据敏感度 1~5 分,两者相加或取高值映射到 L1~L4。例如某 CRM 系统业务影响 4 分、数据敏感 5 分,取高值映射为 L4;某测试环境业务影响 2 分、数据敏感 1 分,映射为 L2。定级结果必须由业务负责人确认,不能只由安全团队单方决定。

三、业务流与数据流识别:从“谁调用谁”到“数据经过哪”

业务流描述“用户/系统完成一件事经过哪些环节”,数据流描述“数据在这些环节中如何流动、存储、复制和出境”。识别方法建议从入口开始:

  1. 列出对外服务入口:域名、公网 IP、API 路径、VPN 入口、第三方回调地址。
  2. 沿调用链向下追踪:负载均衡 → WAF → 应用 → 中间件 → 数据库 → 缓存/消息队列。
  3. 标注每一跳的协议与端口,例如 HTTPS 443、MySQL 3306、Redis 6379、Kafka 9092。
  4. 标注数据形态:明文、加密、脱敏、令牌化;标注数据是否跨边界(互联网、办公网、生产网、云)。
  5. 标注数据留存位置与周期,例如订单库留存 5 年、日志留存 180 天。

识别过程中最容易遗漏的是“横向流”和“管理流”:数据库主从复制、备份流量、监控采集、堡垒机运维通道、CI/CD 发布通道。这些流量往往权限高、路径隐蔽,必须单独登记。

业务流与数据流识别(示例:电商下单链路) 用户/终端 公网 HTTPS 443 WAF / 负载均衡 TLS 卸载、限流 订单应用 业务逻辑、鉴权 支付网关 第三方回调 外部支付 持牌机构 Redis 缓存 会话/热点数据 Kafka 队列 异步削峰 订单数据库 MySQL 3306 备份存储 每日全量+增量 需登记的横向/管理流 • 数据库主从复制 3306 • 备份通道 22 / 873 • 监控采集 9100 / 9090 • 堡垒机运维 22 / 3389 • CI/CD 发布 443 / 6443 • 日志外发 514 / 9200 数据流标注要点 数据形态:明文 / 加密 / 脱敏 / 令牌化 | 跨边界:互联网→DMZ→生产网→云 | 留存:订单库 5 年、日志 180 天、备份 30 天 责任:入口归应用团队、数据库归 DBA、网络通道归网络团队、第三方回调归支付团队

四、资产清单:字段要能支撑决策

资产清单不是“设备台账”,而是安全运营的基础数据。建议字段包括:资产编号、资产名称、资产类型、业务系统、分级(L1~L4)、部署位置、IP/域名、端口、操作系统/中间件版本、责任人、运维人、数据敏感度、是否暴露互联网、最近一次补丁时间、最近一次权限复核时间、生命周期状态。

清单维护要解决“谁更新、何时更新、如何校验”三个问题。可行做法是:新建或变更资产必须走工单,工单关闭时同步更新清单;每月用扫描器或 CMDB 与清单做一次比对,差异项在 5 个工作日内确认;每季度由业务负责人签字确认分级与责任人。

五、责任矩阵:把 RACI 落到资产上

责任矩阵用于消除“都管等于没人管”。对每类资产明确四类角色:

  • R(执行):实际执行配置、补丁、备份、监控的人。
  • A(负责):对资产安全结果最终负责的人,通常为业务负责人或系统 owner。
  • C(咨询):提供安全、网络、合规意见的角色,如安全团队、网络团队。
  • I(知会):需要知晓变更或事件的角色,如运维值班、审计。

示例:某 L4 订单数据库,A 为订单业务负责人,R 为 DBA,C 为安全架构师与网络工程师,I 为运维值班与内审。当发生高危漏洞时,R 负责 24 小时内完成评估与修复,A 负责确认业务影响并批准变更窗口,C 提供修复方案与验证方法,I 接收事件通报。

资产分级、业务流、数据流、清单、责任矩阵五者要形成闭环:分级决定管控强度,业务流与数据流决定边界和监控点,清单承载字段,责任矩阵明确谁来做、谁确认。
常见误区:只梳理服务器不梳理账号与数据;只画业务流不标数据留存;清单长期不更新;责任矩阵只写部门不写具体角色。任何一项缺失,都会让后续安全策略失去依据。

完成本节梳理后,应能回答:企业有哪些 L4/L3 资产、它们承载哪些业务流、数据经过哪些边界、每项资产谁负责、下一次复核时间是什么时候。这些答案就是下一阶段安全架构设计的输入。