4. 策略数据源：日志、配置、网络流等

做策略自动推导，第一步不是写算法，而是搞清楚数据从哪来。我见过不少团队，算法模型调得飞起，结果倒在了数据质量上——说白了，垃圾进垃圾出。这章咱们聊聊常见的策略数据源：日志、配置、网络流，以及其他几种你可能忽略的"沉默"来源。

4.1 三大主力数据源

我个人习惯把策略数据源分成三类：日志类、配置类、流量类。它们各有侧重，也各有脾气。

4.2 日志：最真实的"脚印"

日志不会撒谎。你配置里写了允许A访问B，但A到底有没有访问过？日志说了算。

常见日志类型

• 防火墙日志：源IP、目的IP、端口、协议、动作(allow/deny)、时间戳。我最常用它来反推最小化策略。
• 系统审计日志：Linux auditd、Windows Security Event。记录进程级访问，粒度更细。
• 应用日志：Nginx access log、数据库查询日志。能暴露业务层面的访问关系。

日志预处理常见步骤

1. 解析：将非结构化日志转成结构化字段（IP、端口、时间等）
2. 去重：同一连接反复log只保留一个代表
3. 时间窗口切片：按小时/天聚合，观察周期性
4. 异常过滤：扫描器、爬虫、health check等机器流量需单独标记

# 一个简单的日志解析示例（Python伪代码）
import re

log_line = "2025-04-01 10:23:45 ALLOW TCP 10.0.1.5:54321 -> 10.0.2.10:443"
pattern = r"(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) (ALLOW|DENY) (\w+) (\d+\.\d+\.\d+\.\d+):(\d+) -> (\d+\.\d+\.\d+\.\d+):(\d+)"
match = re.match(pattern, log_line)
if match:
    timestamp, action, proto, src_ip, src_port, dst_ip, dst_port = match.groups()
    print(f"{src_ip} -> {dst_ip}:{dst_port} {action}")

4.3 配置：官方的"意图"

配置是管理员写下的"应该怎么做"，但实际环境里经常出现配置和日志打架的情况——配置开放了，但没人用；配置关闭了，业务却绕道走了。所以配置必须结合日志一起看。

• ACL规则：Cisco ASA、华为、iptables。每条规则有顺序、匹配条件、动作。
• 安全组/网络策略：AWS Security Group、Kubernetes NetworkPolicy。典型的声明式配置。
• IAM策略：云上的角色绑定、权限边界。影响的是身份层面的访问，容易跟网络策略搞混。

4.4 网络流：看不见的"血管"

网络流数据不像日志那样记录每一次请求，而是以流为单位汇聚：谁跟谁在什么时间、用了多少流量。NetFlow v5/v9、sFlow、IPFIX是主流协议。

网络流数据的关键字段

网络流与日志的对比

• 日志：每个请求都记录，体积大，适合精细审计。
• 网络流：压缩聚合，体积小，适合宏观趋势分析。
• 说实话，我一般两者都用——用网络流发现所有通信对，再用日志确认具体端口和动作。

4.5 其他补充数据源

除了上面三个主力，还有几个容易被忽略的"冷门"来源：

• CMDB / 资产管理系统：提供IP与应用的映射关系。没有这个，你推导出来的策略只能写IP，写不了"允许nginx访问mysql"这种语义化的规则。
• DNS日志：把IP转换成域名，帮助理解业务归属。
• 变更记录：Git提交、ITSM工单。能告诉你哪些策略是人为改过的，推测意图。

4.6 数据源融合：一张核心结构图

下图展示了我常用的数据源融合框架。你可以看到日志、配置、网络流、CMDB各自输入，经过解析、关联、去噪后，汇聚到统一的策略基线与访问关系层。

4.7 数据质量：决定策略推导成败的关键

数据源再多，质量不行等于零。我在项目中总结了几条硬指标：

4.8 小结