4. Rekor日志告警:Rekor条目异常检测、日志篡改告警、重复条目告警

Rekor 是 Sigstore 生态中的透明性日志(Transparency Log),负责永久记录所有签名元数据、构建证明和软件物料清单(SBOM)。一旦攻击者绕过 Rekor 的不可篡改保证,整个供应链信任链将崩塌。本章聚焦三类核心告警场景:条目异常检测、日志篡改告警与重复条目告警,帮助安全团队建立实时监控与响应能力。

4.1 Rekor 日志架构与告警触发点

Rekor 基于 Merkle 树结构存储条目,每个条目包含 body(签名负载)、integratedTime(提交时间戳)和 logIndex(唯一索引)。告警系统通过以下三个关键接口捕获异常:

  • API 层:/api/v1/log/entries 与 /api/v1/log/entries/retrieve 的请求频率与负载特征。
  • 存储层:Merkle 树哈希一致性校验(GetTreeState 端点)。
  • 索引层:logIndex 的连续性检查与重复 UUID 检测。
关键指标基线:正常 Rekor 实例每秒处理 50–200 条条目,Merkle 树根哈希每 10 秒更新一次。任何偏离此基线的行为都应触发告警。
Rekor 日志告警触发架构图 Rekor 日志告警触发架构 API 层 /api/v1/log/entries 存储层 Merkle 树哈希校验 索引层 logIndex 连续性 告警引擎 条目异常检测 日志篡改告警 重复条目告警

4.2 条目异常检测

条目异常检测关注单个 Rekor 条目的内容与元数据是否偏离预期。攻击者可能提交伪造的签名负载、篡改 integratedTime 或插入恶意 body 内容。

4.2.1 检测规则与阈值

检测维度 规则描述 告警阈值
body 结构校验 检查 body 是否为合法 JSON 且包含必需字段(spec、kind、apiVersion) 连续 3 条解析失败
integratedTime 漂移 条目时间戳与当前系统时间偏差超过 300 秒 单条即告警
签名算法异常 使用非标准或已废弃的签名算法(如 MD5、SHA-1) 单条即告警
负载大小异常 body 大小超过 1MB 或小于 128 字节 单条即告警
最佳实践:将条目异常检测与 SIEM 系统集成,使用 rekor-cli get --log-index 快速拉取异常条目进行人工审核。

4.2.2 异常条目检测代码示例

# 使用 rekor-cli 与 jq 检测异常条目
# 检查 body 是否为合法 JSON
rekor-cli get --log-index 12345 --format json | jq '.body | fromjson | .spec'

# 检查 integratedTime 是否在合理范围内
rekor-cli get --log-index 12345 --format json | jq '.integratedTime'
# 与当前时间戳对比
date +%s

# 批量检测最近 100 条条目的负载大小
for i in $(seq 1000 1100); do
  size=$(rekor-cli get --log-index $i --format json | jq '.body' | wc -c)
  if [ $size -gt 1048576 ] || [ $size -lt 128 ]; then
    echo "ALERT: logIndex $i has abnormal body size: $size bytes"
  fi
done

4.3 日志篡改告警

Rekor 的不可篡改性依赖于 Merkle 树的一致性校验。日志篡改告警用于检测以下攻击场景:

  • 树根哈希不一致:攻击者修改历史条目后未更新 Merkle 树根。
  • 检查点伪造:攻击者伪造 Signed Tree Head(STH)以掩盖篡改行为。
  • 分叉攻击:攻击者向不同客户端展示不同的 Merkle 树状态。

4.3.1 一致性校验流程

  1. 从可信源(如 Rekor 公共实例或公证人)获取当前 STH。
  2. 使用 rekor-cli get-tree-state 获取本地 Rekor 实例的树状态。
  3. 比较两个 STH 的 rootHash 与 treeSize。
  4. 若不一致,立即触发 日志篡改告警。
严重告警:日志篡改告警一旦触发,应视为最高优先级安全事件。立即隔离受影响的 Rekor 实例,并从备份恢复 Merkle 树状态。

4.3.2 一致性校验代码示例

#!/bin/bash
# Rekor 日志篡改检测脚本

TRUSTED_STH=$(curl -s https://rekor.sigstore.dev/api/v1/log/treeState | jq -r '.rootHash')
LOCAL_STH=$(rekor-cli get-tree-state --format json | jq -r '.rootHash')

if [ "$TRUSTED_STH" != "$LOCAL_STH" ]; then
  echo "ALERT: Log tampering detected!"
  echo "Trusted rootHash: $TRUSTED_STH"
  echo "Local rootHash:   $LOCAL_STH"
  # 发送告警到 Slack / PagerDuty
  curl -X POST -H "Content-type: application/json" \
    --data "{\"text\":\"Rekor 日志篡改告警: rootHash 不一致\"}" \
    https://hooks.slack.com/services/YOUR_WEBHOOK
else
  echo "OK: Merkle tree is consistent."
fi

4.4 重复条目告警

重复条目告警用于检测攻击者向 Rekor 提交相同负载的多个条目,以混淆审计或掩盖恶意活动。重复条目通常具有相同的 body 内容或相同的 UUID。

4.4.1 重复条目检测策略

检测方法 实现方式 误报率
body 哈希去重 对每个条目的 body 计算 SHA-256 哈希,存入布隆过滤器 低(0.1%)
UUID 唯一性检查 监控 /api/v1/log/entries 返回的 UUID 是否重复 极低(0.01%)
时间窗口去重 在 5 分钟窗口内,相同 body 出现超过 3 次即告警 中(需结合业务上下文)

4.4.2 重复条目检测代码示例

# 使用 Python 脚本检测重复条目
import requests
import hashlib
from collections import defaultdict

REKOR_API = "https://rekor.sigstore.dev/api/v1/log/entries"
body_hash_map = defaultdict(list)

# 获取最近 500 条条目
response = requests.get(f"{REKOR_API}?limit=500")
entries = response.json()

for uuid, entry in entries.items():
    body_hash = hashlib.sha256(entry['body'].encode()).hexdigest()
    body_hash_map[body_hash].append(uuid)

# 检测重复
for body_hash, uuids in body_hash_map.items():
    if len(uuids) > 1:
        print(f"ALERT: Duplicate entries detected for body hash {body_hash}")
        print(f"UUIDs: {', '.join(uuids)}")
重复条目检测流程 重复条目检测流程 获取条目列表 计算 body 哈希 布隆过滤器查重 ? 触发重复条目告警 条目正常,继续监控

4.5 告警响应与自动化

针对三类 Rekor 告警,建议建立以下自动化响应流程:

告警类型 自动响应动作 升级条件
条目异常检测 隔离异常条目,通知安全分析师人工审核 连续 10 条异常 / 涉及关键签名者
日志篡改告警 立即暂停 Rekor 写入,从备份恢复 Merkle 树 任何一次触发即升级
重复条目告警 自动删除重复条目(保留第一条),记录审计日志 同一 body 重复超过 10 次
自动化工具推荐:使用 rekor-monitor(开源)或 Falco 规则引擎实现 Rekor 告警的实时检测与自动响应。所有告警事件应写入不可篡改的审计日志(如 AWS CloudTrail 或 Splunk)。

4.6 本章小结

  • 条目异常检测:关注 body 结构、时间戳漂移、签名算法和负载大小,使用 rekor-cli 与 jq 实现批量检测。
  • 日志篡改告警:通过 Merkle 树一致性校验(STH 对比)检测篡改行为,一旦触发立即隔离实例。
  • 重复条目告警:基于 body 哈希去重与 UUID 唯一性检查,结合布隆过滤器降低误报率。
  • 自动化响应:为每类告警定义明确的自动动作与升级条件,确保安全团队在 SLA 内完成处置。