可观测性安全：数据脱敏、最小化采集与访问控制的纵深防线

日志/追踪里的敏感信息：
  - PII：手机号、邮箱、身份证、姓名、地址
  - 凭证：token、密码、cookie、Authorization 头
  - 业务机敏：订单金额、内部接口参数、数据内容
  - 基础设施：内部 IP、专有标签、集群名

风险场景：
  - 采集时被旁路截获（明文传输）
  - 存储被攻破 → 全部敏感数据泄露
  - 内部越权 → 不该看的人看了
  - 审计缺失 → 泄露了都不知道是谁

- 集中性：几套存储汇聚全公司敏感数据，单点风险巨大
- 长期性：遥测数据保留月/年 → 泄露窗口长
- 易忽视：团队只关心"功能"，安全常被忽略
- 难治理：日志分散、字段繁多，脱敏易遗漏

结论：可观测系统必须按"高价值资产"一样对待安全

原则：能不采集的敏感数据，一开始就别采

具体做法：
  - 日志不打印请求体/响应体（或只打必要的 sanitized 字段）
  - 追踪采样时避免记录 query 参数中的敏感信息
  - 指标绝不带 PII（用聚合指标替代明细）
  - debug 级别日志只在需要时短暂开启

收益：
  数据不产生 = 无需脱敏 = 无需担心泄露
  领比"全采了再删"便宜得多

只采"完成任务必需"的字段：
  - 排障需要 request_id/trace_id/错误码/时长
  - 多数情况下不需要原始 PII 字段
  - 产品分析可用"匿名化标识"而非原始标识

实践：
  - 埋点前评审字段必要性
  - 敏感字段默认不采集，需要时走审批

脱敏层级（越早越好）：
  1. 应用侧：打日志/埋点前就脱敏（最理想）
  2. 采集器（Agent/Collector）：就近正则替换
  3. 存储前：入库前兜底处理
  4. 查询时：返回前过滤（最后防线，不能依赖）

最佳实践：
  应用侧为主 + 采集侧兜底，两层夹住

手段一：掩码/截断
  user.email: a***@example.com
  phone: 138****0000

手段二：散列化
  原始值 → 一次/可逆 hash（需保留关联时）

手段三：删除/替换
  删除敏感标签；替换为固定占位符

手段四：字段级丢弃
  drop 掉含 token/password 命名的字段

对照表：敏感类型 → 脱敏动作 → 保留用途

# OTel Collector：transform 处理器脱敏
processors:
  transform/redact:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - "delete_key(attributes, \"http.request.header.authorization\")"
          - "replace_pattern(attributes, \"user.email\", \"value\", \"***\")"
    log_statements:
      - context: log
        statements:
          - "delete_key(body, \"token\")"

遥测数据在管道里传输：
  SDK → Agent → Collector → 存储，可能跨网络/跨机房
  → 全程 TLS（mTLS 更佳）防止中途截获

要点：
  - Collector 之间用 TLS/mTLS
  - 内部依赖暴露易，加密却常被忽略
  - 证书管理统一（内部 PKI / 服务网格）

静态加密（at-rest）：
  - 对象存储/Tsdb/日志后端启用加密（KMS）
  - 磁盘层加密 + 应用层加密（高敏感场景）

密钥管理：
  - KMS/密钥托管，杜绝密钥进配置文件/代码
  - 定期轮换

审计：存储层访问日志、异常访问告警

遥测数据访问的角色分级：
  只读普通用户（排障自己服务的日志）
  全局读者（SRE/安全，可跨服务）
  写/管理（配置、清理、导出）

原则：
  - 用户默认只看自己服务/团队的遥测数据
  - 全局/敏感数据（PII、跨团队）需更高权限
  - 匿名/权限不匹配直接拒绝

对遥测系统的"访问"也要观测：
  - 谁能看、看了什么、何时、为什么
  - 下载/导出敏感遥测数据 → 审批 + 审计
  - 异常访问（大量拉取/越权）→ 告警

落地：
  - 平台自带审计日志 + 集成 SIEM
  - 敏感数据（PII）访问单独审计
  - 暴露的演示面定期清理

GDPR/个保法对可观测数据的约束：
  - 最小化：只处理必要数据
  - 目的限制：采集的目的要明确
  - 保留期：数据不能无限留
  - 被遗忘权：用户可要求删除其数据
  - 泄露通知：敏感数据泄露须上报

→ 数据保留与删除策略必须可执行

保留策略设计：
  - 按数据类型定保留期（日志/指标/追踪不同）
  - 超期自动删除 / 归档（不可实时查询）
  - 用户删除请求 → 跨存储删除（需支持）

配套：
  - 数据留存矩阵（类型 × 保留时长 × 原因）
  - 能自动执行 + 可审计
  - 例外（法律保留）与常规分开

□ 源头最小化采集，默认不采集 PII
□ 应用侧脱敏 + 采集侧兜底，越早越好
□ 传输全链路 TLS（mTLS 更佳）
□ 存储加密 + 密钥托管，杜绝密钥散落
□ 遥测访问最小权限，只能看自己负责的
□ 敏感数据访问单独审计 + 异常告警
□ 数据保留设类型分保留期，超期自动删除
□ 支持数据删除请求（GDPR/合规）
□ 定期评审埋点字段与访问权限

可观测性安全 = 最小化采集 + 尽早脱敏 + 加密传输 + 最小权限 +
全程审计，让"看得清"的同时也能"守得住"。