2. 资产测绘与业务流梳理

分区与微隔离的失败，绝大多数不是策略引擎不够强，而是事实基础不牢：不知道有哪些资产、谁在调用谁、数据往哪里流，策略就只能靠猜。资产测绘与业务流梳理的目标，是把“网络里有什么”和“它们之间怎么交互”变成可核对、可更新、可被策略引用的结构化事实。它回答四个问题：资产是谁（身份与归属）、在哪里（位置与网络属性）、和谁说话（依赖关系）、说什么（协议、端口、数据方向与敏感级别）。

一、五类测绘对象：应用、服务、数据、用户、设备

资产测绘不是简单拉一份 IP 清单，而是按五个维度建立对象模型，并让它们之间可以互相引用。

• 应用：业务视角的最小单元，如“订单中心”“支付网关”。一个应用通常由多个服务实例、数据库、缓存和外部依赖组成，是分区策略的顶层归属单位。
• 服务：应用对外或对内暴露的可调用能力，如 order-api:8080、payment-callback:443。微隔离策略最终落在服务之间的允许/拒绝关系上。
• 数据：需要保护的对象，如用户身份信息、支付流水、订单明细。数据分级（公开/内部/敏感/核心）决定策略的严格程度和审计要求。
• 用户：人、角色或系统账号，如运维管理员、第三方对接账号、批处理任务账号。用户维度决定“谁能访问什么”，是零信任中身份策略的输入。
• 设备：承载服务的物理机、虚拟机、容器、网络设备与终端。设备提供位置、网段、标签（如 env=prod、zone=dmz），是策略执行的落点。

五类对象通过统一标识关联：应用包含服务，服务运行在设备上，服务读写数据，用户访问服务。缺少任一维度，策略都会出现盲区——只有 IP 没有应用归属，就无法按业务分区；只有应用没有数据分级，就无法判断哪些流量必须加密或审计。

二、识别方法：从被动流量到主动核对

实际测绘通常组合四类数据源，互相补全与验证：

1. 被动流量分析：在核心交换或虚拟化层镜像流量，解析五元组、TLS SNI、HTTP Host、DNS 查询，得到“谁在何时访问谁”。优点是覆盖真实行为，缺点是无法发现长期静默的依赖。
2. 主动扫描与探针：对已知网段做端口与服务识别，结合 CMDB、容器编排 API（如 Kubernetes 的 Service/Endpoint）、云平台资产接口，补齐资产清单与标签。
3. 配置与代码分析：读取应用配置文件、服务注册中心、负载均衡与防火墙规则，提取声明式依赖，如数据库连接串、消息队列地址、外部 API 域名。
4. 人工访谈与核对：与业务、开发、运维确认关键依赖和例外路径，尤其是低频但关键的批处理、灾备同步和第三方回调。

四类数据源合并后，需要做一次“依赖收敛”：把同一服务的多个实例合并为一个逻辑节点，把同一应用的服务聚合成应用组，把无法归属的流量标记为“待确认”，而不是直接放行或丢弃。

三、业务依赖图与数据流图：两种视角，一张事实底图

业务依赖图回答“谁依赖谁”，节点是应用或服务，边是调用关系，标注协议、端口、调用频率和方向。数据流图回答“数据从哪里来、经过谁、到哪里去”，节点是数据存储与处理环节，边是数据流向，标注数据类型、敏感级别和是否加密。两者可以叠加为一张事实底图：同一张图上既能看到服务调用链，也能看到敏感数据经过的路径。

绘制时建议遵循三条规则：一是方向明确，调用方指向被调用方，数据流按实际写入/读取方向；二是粒度一致，同一张图内节点粒度保持在同一层（应用级或服务级），避免混画；三是标注可验证，每条边至少记录协议、端口、来源证据（流量/配置/访谈），便于后续复核。

四、从事实底图到分区与微隔离策略

测绘结果要能直接支撑分区决策。常用做法是：先按应用归属和数据敏感级别划分安全域，例如将订单中心与订单库划入“交易区”，支付网关与支付流水库划入“支付区”，消息队列划入“中间件区”，第三方对接单独划入“外联区”。然后依据依赖图，只允许必要的服务调用跨区，其余默认拒绝。

以图中为例，可导出如下策略意图（示例，非实测）：

这张表就是微隔离策略的雏形。它的价值不在于“写得多全”，而在于每条规则都能追溯到证据：来自哪次流量分析、哪份配置、哪次访谈。当业务变更时，只需更新对应边和证据，策略即可同步调整。

五、持续维护：测绘不是一次性项目

资产和依赖会随发布、扩缩容、第三方变更而漂移。建议把测绘做成周期性任务：每周对比流量与资产清单，发现新增或消失的服务；每月复核一次跨区依赖，确认是否仍有业务必要；每次上线前要求开发提交依赖声明，与流量观测结果比对。对于长期无流量但仍在清单中的依赖，标记为“待清理”，避免策略被历史遗留关系撑大。

完成本节工作后，你应当得到三份可交付物：一份五类对象关联的资产清单、一张标注了协议端口与证据来源的业务依赖/数据流叠加图、一份可追溯到证据的跨区访问策略意图表。它们共同构成后续分区设计与微隔离落地的唯一事实基础。