可观测性与安全的融合：统一数据平台的建设实践

vipxieliang
0 阅读10分钟

1. 引言：当可观测性遇上安全

过去十年，可观测性（Observability）与安全（Security）几乎是两条平行演进的技术赛道。前者围绕 Metrics、Logs、Traces 三大支柱，服务于 SRE 与研发团队，目标是"更快发现并定位故障"；后者围绕威胁检测、事件响应、合规审计，服务于安全团队，目标是"更快发现并阻断攻击"。

但当我们把视角拉高会发现：两者本质上都在回答同一个问题——"系统里正在发生什么，以及这是否正常？" 故障与攻击在数据层面高度同构：一次异常的 CPU 飙升，可能是流量突增，也可能是一次挖矿木马；一次异常的出站连接，可能是业务调用，也可能是一次数据外泄。

本文从 CNCF 的行业观察出发，结合安全厂商收购可观测性公司的产业信号，探讨如何以 OpenTelemetry 为骨干构建统一数据采集层，用 Trace 关联分析还原攻击链路，并给出 Security Observability 平台的技术选型建议。

2. CNCF CTO 观察：可观测性与安全正在融合

CNCF CTO 在多个公开场合反复强调一个判断：可观测性与安全的边界正在消失。这一判断并非概念炒作，而是由三个现实因素共同推动：

  • 数据同源：安全检测所需的运行时行为数据（进程、网络、文件、系统调用），与可观测性所需的运行时上下文（服务、依赖、调用链）来自同一批采集点。重复采集意味着双倍开销与双份维护成本。
  • 响应同速：云原生环境下，攻击窗口以分钟计。安全团队如果还在等日志从另一个系统批量导出，就已经错过了最佳处置时机。可观测性平台提供的实时流式能力，正是安全响应所需要的。
  • 组织同频：越来越多企业将 SRE 与安全运营（SecOps）纳入同一个平台工程团队，共享数据底座与告警通道，避免"两套系统、两套口径、两套值班"。

CNCF 社区的具体动作也印证了这一趋势：OpenTelemetry 项目持续扩展对安全相关信号的支持，Falco 等运行时安全项目与可观测性生态的集成日益紧密，Kubernetes 审计日志、eBPF 采集等能力被逐步纳入统一的数据管道。

一句话总结：可观测性是安全的数据底座，安全是可观测性的价值延伸。

下图展示了可观测性与安全在数据、响应、组织三个维度上的融合关系：

flowchart TD
  subgraph OBS[可观测性侧]
    O1[Metrics指标]
    O2[Logs日志]
    O3[Traces调用链]
  end

  subgraph SEC[安全侧]
    S1[威胁检测]
    S2[事件响应]
    S3[合规审计]
  end

  subgraph BASE[统一数据底座]
    B1[同源采集点进程网络文件系统调用]
    B2[实时流式管道]
    B3[共享告警通道]
  end

  O1 --> B1
  O2 --> B1
  O3 --> B1
  S1 --> B1
  S2 --> B2
  S3 --> B3
  B1 --> B2
  B2 --> B3
  B3 --> S2

3. 安全厂商收购可观测性公司的行业信号

如果说 CNCF 的观察是"技术趋势"，那么资本市场的动作就是"产业确认"。近几年，多起安全厂商收购可观测性/日志分析公司的案例，释放出明确的行业信号：

信号维度具体表现深层含义
能力补齐安全厂商收购日志分析、APM、追踪类公司单纯依赖网络流量与终端 Agent 已不足以覆盖云原生攻击面
数据整合将安全事件与业务调用链数据打通检测需要业务上下文，否则误报率居高不下
平台化从单点工具走向统一数据平台客户不愿为"安全"和"运维"分别采购两套数据底座
商业模式按数据量计费向按价值/风险计费演进安全效果需要可度量，而度量依赖可观测数据

这些收购背后的共同逻辑是：安全产品的竞争力，正在从"检测规则的数量"转向"数据上下文的深度"。一个能回答"这个异常请求来自哪个服务、经过了哪些依赖、影响了哪些用户"的平台，其检测价值远高于一个只会喊"发现可疑 IP"的工具。

对建设者而言，这意味着选型时不应再把可观测性平台与安全平台割裂评估，而应优先考虑能否共享同一套采集、存储与查询能力。

从"单点工具"到"统一数据平台"的演进路径，可以更直观地理解这些收购背后的产业逻辑：

flowchart LR
  T1[单点安全工具规则数量竞争] --> T2[能力补齐收购日志APM追踪]
  T2 --> T3[数据整合安全事件与调用链]
  T3 --> T4[平台化统一数据底座]
  T4 --> T5[价值计费按风险效果度量]

4. 统一数据采集：OpenTelemetry 作为安全遥测的骨干

4.1 为什么选择 OpenTelemetry

OpenTelemetry（OTel）已成为云原生可观测性的事实标准，其核心价值在于厂商中立的数据模型与统一的采集协议（OTLP）。将其作为安全遥测的骨干，有三点关键理由：

  1. 一次采集，多处消费：同一份 Trace/Log/Metric 数据，既可供 SRE 排障，也可供安全规则引擎检测，避免重复埋点。
  2. 语义约定可扩展：OTel 的 Semantic Conventions 为资源属性（如 k8s.pod.name、process.command_line）提供了标准化命名，安全检测规则可以直接基于这些属性编写，跨环境可移植。
  3. 生态完整：Collector 支持丰富的 Processor 与 Exporter，可在数据管道中完成脱敏、采样、富化与分流。

下图对比了传统"双管道"采集与 OTel 统一采集的差异：

flowchart TD
  subgraph OLD[传统双管道]
    X1[业务埋点] --> X2[可观测性后端]
    X3[安全Agent] --> X4[安全平台]
  end

  subgraph NEW[OTel统一管道]
    Y1[应用SDK与eBPF与审计日志] --> Y2[OTelCollector]
    Y2 --> Y3[可观测性后端]
    Y2 --> Y4[安全检测引擎]
  end

  OLD -.->|重复采集双份维护| NEW

4.2 采集架构设计

flowchart LR
  subgraph A[数据源层]
    A1[应用SDK OTel自动与手动]
    A2[eBPFAgent内核态行为]
    A3[K8s审计日志APIServer]
    A4[网络流量Flow与PCAP]
  end

  subgraph B[采集层]
    B1[OTelCollector DaemonSet]
    B2[OTelCollector Gateway集群]
  end

  subgraph C[处理层]
    C1[脱敏Processor]
    C2[采样Processor]
    C3[富化Processor资产身份标签]
  end

  subgraph D[消费层]
    D1[可观测性后端Trace Metric Log]
    D2[安全检测引擎规则与ML]
    D3[数据湖长期留存与回溯]
  end

  A1 --> B1
  A2 --> B1
  A3 --> B1
  A4 --> B1
  B1 --> B2
  B2 --> C1
  C1 --> C2
  C2 --> C3
  C3 --> D1
  C3 --> D2
  C3 --> D3

4.3 关键实践要点

  • 统一资源属性：为每个遥测数据附加 service.name、k8s.namespace.name、cloud.account.id 等资源标签，这是后续安全关联分析的"主键"。
  • 安全信号标准化：将进程执行、文件访问、网络连接等安全事件映射为 OTel Log 记录，并遵循统一的属性命名，避免各 Agent 各自为政。
  • 分级采样策略：对高价值安全信号（如特权进程启动、敏感文件访问）采用全量采集，对普通业务 Trace 采用尾部采样，平衡成本与覆盖。
  • 数据脱敏前置：在 Collector 层完成 PII 脱敏，确保安全数据留存不违反合规要求。
# OTel Collector 配置片段：安全信号分流示例
processors:
  batch:
    timeout: 5s
  attributes/security:
    actions:
      - key: telemetry.category
        value: security
        action: insert
  tail_sampling:
    policies:
      - name: security-critical
        type: string_attribute
        string_attribute:
          key: security.severity
          values: ["high", "critical"]
      - name: baseline
        type: probabilistic
        probabilistic:
          sampling_percentage: 10

exporters:
  otlp/observability:
    endpoint: obs-backend:4317
  otlp/security:
    endpoint: sec-engine:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/security, tail_sampling, batch]
      exporters: [otlp/observability, otlp/security]

5. 安全事件的 Trace 关联分析：从指标异常到攻击链路还原

5.1 核心思路

传统安全告警是"点"——一个可疑 IP、一次异常登录。而 Trace 提供的是"线"——一次请求从入口到出口的完整路径。将安全事件挂载到 Trace 上，就能把孤立的告警点连成可解释的攻击链路。

5.2 关联分析流程

flowchart TD
  S1[指标异常触发CPU与连接数突增] --> S2[定位异常时间窗与相关服务实例]
  S2 --> S3[检索该时间窗内相关Trace]
  S3 --> S4[提取Trace中的安全事件Span]
  S4 --> S5{是否存在可疑行为}
  S5 -->|是| S6[沿调用链回溯定位入口与横向移动]
  S5 -->|否| S7[标记为误报回流规则优化]
  S6 --> S8[生成攻击链路图与影响面评估]
  S8 --> S9[联动响应隔离阻断取证]

5.3 典型关联场景

场景一：从资源异常到挖矿木马

某 Pod CPU 持续 100%，可观测性平台告警。通过 Trace 关联发现该 Pod 在异常时段内启动了 xmrig 进程（来自 eBPF 采集的进程执行事件），并存在到矿池地址的出站连接。三个信号叠加，从"性能问题"升级为"安全事件"。

场景二：从异常出站到数据外泄

安全引擎检测到某服务向陌生域名发起大量 HTTPS 请求。通过 Trace 回溯，发现该请求源自一个被注入的依赖库，且调用链上游是用户数据查询接口。由此确认这是一次供应链投毒导致的数据外泄尝试。

场景三：从登录异常到横向移动

身份系统报告某账号在短时间内从多个地域登录。通过 Trace 关联该账号发起的 API 调用，发现其访问了多个本无权限的服务，且调用模式呈现明显的自动化扫描特征，判定为凭证泄露后的横向移动。

三个典型场景在信号来源与攻击阶段上的对应关系如下：

flowchart LR
  C1[场景一资源异常] --> R1[CPU飙升与xmrig进程与矿池连接]
  R1 --> A1[挖矿木马执行阶段]

  C2[场景二异常出站] --> R2[陌生域名HTTPS与被注入依赖库]
  R2 --> A2[供应链投毒外泄阶段]

  C3[场景三登录异常] --> R3[多地域登录与越权API扫描]
  R3 --> A3[凭证泄露横向移动阶段]

5.4 实现要点

  • Span 与安全事件对齐：在关键 Span 上附加 security.event.type、security.risk.score 等属性，使安全事件天然具备调用链上下文。
  • 统一时间基准：所有采集点必须做时钟同步（NTP/PTP），否则跨源关联会因时间漂移而失效。
  • 保留原始数据：关联分析往往需要回溯原始日志，因此需在数据湖中保留足够长的原始数据窗口（建议不少于 30 天）。

6. 构建 Security Observability 平台的技术选型

6.1 选型原则

  • 开放优先：优先选择支持 OTLP、OpenTelemetry 语义约定的组件，避免被单一厂商锁定。
  • 存算分离：采集、存储、查询分层解耦，便于按需扩展与成本优化。
  • 安全内建：脱敏、访问控制、审计日志应作为平台的基础能力，而非事后补丁。

6.2 分层选型建议

层次能力要求候选方案
采集层多源接入、低开销、可扩展OpenTelemetry Collector、eBPF Agent（如 Cilium Tetragon、Falco）
传输层高吞吐、可靠投递Kafka / Pulsar 作为缓冲与解耦
存储层多模态存储、冷热分层ClickHouse（日志/事件）、Prometheus 兼容 TSDB（指标）、对象存储（Trace 与归档）
查询分析层关联查询、链路还原支持 TraceQL / SQL 的查询引擎，图数据库辅助链路建模
检测层规则 + 行为基线 + MLSigma 规则引擎、Falco 运行时规则、异常检测模型
响应层自动化编排SOAR 平台、K8s 准入控制、网络策略联动

各层组件之间的数据流向与职责边界如下：

flowchart LR
  L1[采集层OTelCollector与eBPF] --> L2[传输层Kafka与Pulsar]
  L2 --> L3[存储层ClickHouse与TSDB与对象存储]
  L3 --> L4[查询分析层TraceQL与SQL与图数据库]
  L4 --> L5[检测层Sigma与Falco与ML]
  L5 --> L6[响应层SOAR与准入控制与网络策略]
  L6 -.->|反馈优化规则| L5

6.3 落地路线图

flowchart LR
  P1[阶段一统一采集OTel标准化] --> P2[阶段二数据打通Trace与安全事件关联]
  P2 --> P3[阶段三检测增强规则与基线ML]
  P3 --> P4[阶段四闭环响应自动化处置]
  • 阶段一（1–2 个月）：完成 OTel Collector 部署与核心服务接入，统一资源属性规范。
  • 阶段二（2–3 个月）：打通 Trace 与安全事件数据，建立关联查询能力，验证 2–3 个典型场景。
  • 阶段三（3–6 个月）：沉淀检测规则库，引入行为基线，降低误报率。
  • 阶段四（持续）：对接响应编排，实现从检测到处置的自动化闭环。

6.4 常见坑与规避

  • 数据量失控：安全信号全量采集容易导致存储成本飙升，务必提前设计采样与保留策略。
  • 关联字段缺失：如果早期没有统一资源属性，后期关联分析会非常痛苦，务必在阶段一就定好规范。
  • 组织壁垒：技术打通容易，团队协作难。建议设立联合平台团队，共享 SLO 与值班机制。

7. 总结

可观测性与安全的融合，不是把两个系统简单拼在一起，而是在数据层面建立统一的语言。OpenTelemetry 提供了这套语言，Trace 关联分析提供了还原攻击链路的方法论，而分层解耦的技术选型则保证了平台的可演进性。

对于正在建设统一数据平台的团队，建议从"统一采集"这一最小切口入手，先让数据流起来，再逐步叠加检测与响应能力。融合的价值不在于工具的数量，而在于当异常发生时，你能用同一份数据同时回答"哪里坏了"和"谁在攻击"。

avatar
文章
阅读
粉丝