日志存储与管理：选方案、管数据、守边界

说到日志存储，很多团队一开始都觉得简单——找个地方把日志丢进去不就行了？但我见过太多项目，上线三个月后存储爆了、查询慢成狗、等要审计的时候发现日志早被覆盖了。说白了，存储方案选不对，后面的安全分析全白搭。

这一章，我们就聊聊日志该往哪存、怎么管、怎么淘汰。嗯，都是我在一线被坑过之后总结出来的经验。

4.1 主流日志存储方案对比

现在业界用得最多的三个流派：ELK Stack、Splunk 和 云原生方案（比如各云的日志服务）。我个人习惯把选型核心放在三个维度：成本、查询性能、运维复杂度。

4.1.1 ELK Stack 实战要点

ELK 是开源方案的标杆。但我每次给团队培训时都会强调：Logstash 不是唯一的采集选择，Filebeat + Kafka 才是生产标配。为什么呢？因为 Logstash 吃内存太狠了，尤其在解析复杂日志时。

一个典型的 DSPM 安全日志采集管道长这样：

# Filebeat 配置片段 (filebeat.yml)
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/dspm/audit/*.log
  fields:
    log_type: "key_operation"
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "dspm-audit-logs"
  partition.round_robin:
    reachable_only: true

这里的 multiline 配置很关键——我记得有次排查问题，发现一条密钥操作日志被拆成了 6 行，就是因为没配这个。嗯，DSPM 审计日志通常是多行结构，必须合并。

4.1.2 Splunk 使用心得

Splunk 在安全圈地位很高。说白了，它的搜索语言（SPL）确实强大，尤其适合做复杂的关联分析。但我要泼盆冷水——索引器的容量规划是 Splunk 部署中最容易翻车的地方。

我们在做密钥审计场景时，会直接把 DSPM 系统通过 HTTP Event Collector (HEC) 推日志：

# 使用 curl 向 Splunk HEC 发送日志
curl -k https://splunk-hec.example.com:8088/services/collector/raw \
  -H "Authorization: Splunk <your-hec->" \
  -d '{
    "event": "2025-01-15 10:30:22, user=audit-admin, action=key_rotate, key_id=KMS-00123, result=success",
    "sourcetype": "dspm:key_audit",
    "host": "kms-server-01",
    "time": 1736908222
  }'

4.2 数据生命周期管理

日志不是存得越久越好。一来合规有要求，二来存储有成本。我在做安全架构时，必做的一步就是跟法务和合规部门对一遍日志保留周期。

典型的 DSPM 日志生命周期分为四个阶段：

1. 热区（Hot）：近 7 天的日志，SSD 存储，支持秒级交互查询
2. 温区（Warm）：7～90 天的日志，HDD 存储，支持分钟级查询
3. 冷区（Cold）：90～365 天的日志，对象存储，需解冻才可查询
4. 归档（Frozen）：超过 1 年的日志，压缩后存到低成本存储或磁带，仅用于法律取证

为什么是这个周期？拿密钥操作日志来说，PCI DSS 要求保留至少 7 年，但大多数安全事件在 90 天内就能发现。我习惯把 90 天作为一个分界线——90 天内的日志确保随时可查，90 天以后的走归档。

4.2.1 Elasticsearch 的索引生命周期管理（ILM）

如果你用 ELK，就别手动删索引了。Elasticsearch 自带的 ILM 策略完全可以搞定：

PUT _ilm/policy/dspm_audit_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "1d"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "allocate": {
            "require": {
              "data_tier": "data_warm"
            }
          },
          "force_merge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          }
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "allocate": {
            "require": {
              "data_tier": "data_cold"
            }
          },
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

4.3 归档策略与合规要求

归档不是把日志拖到一个文件夹就完事了。DSPM 涉及密钥管理，归档日志本身的加密和完整性验证是硬要求。

我们的归档流程一般是：

• 格式：统一转成 JSON Lines (.jsonl)，方便后续解析
• 压缩：使用 gzip 或 zstd，我习惯用 zstd，压缩比高解压还快
• 加密：归档文件使用项目专用的 KMS 密钥做 AES-256-GCM 加密
• 校验：每个归档包附带 sha256 校验和，离线存一份
• 存储：至少两份异地副本，避免单点灾难

下面是 DSPM 审计日志的整个存储与管理流程框架，我把它画成了一张图，方便你理解数据从产生到归档的完整链路：