强曰为道

与天地相似,故不违。知周乎万物,而道济天下,故不过。旁行而不流,乐天知命,故不忧.
文档目录

01 - Rekor 概述:透明日志与供应链安全

第 1 章:Rekor 概述

在软件供应链攻击日益猖獗的今天,Rekor 提供了一种透明、可审计、不可篡改的记录机制,为软件构件的来源和完整性提供了强有力的保障。


1.1 供应链安全背景

1.1.1 什么是供应链攻击?

供应链攻击(Supply Chain Attack)是指攻击者通过渗透软件的开发、构建或分发环节,在软件中注入恶意代码,从而影响所有下游用户。

近年来重大供应链攻击事件:

事件时间影响攻击方式
SolarWinds Orion2020.1218,000+ 组织构建系统被入侵,注入后门
Codecov Bash Uploader2021.0429,000+ 用户Docker 镜像被篡改
Log4Shell (CVE-2021-44228)2021.12数十亿设备开源库漏洞
ua-parser-js2021.108M+ 周下载npm 包被劫持
3CX 供应链攻击2023.03600,000+ 企业构建环境被渗透

1.1.2 供应链攻击的分类

                    ┌─────────────────────────────┐
                    │      软件供应链攻击类型       │
                    └──────────────┬──────────────┘
           ┌──────────────────────┼──────────────────────┐
           ▼                      ▼                      ▼
    ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
    │  源码层攻击   │     │  构建层攻击   │     │  分发层攻击   │
    │              │     │              │     │              │
    │ - 恶意 PR    │     │ - CI 篡改    │     │ - 镜像替换   │
    │ - 账号劫持   │     │ - 构建注入   │     │ - 包劫持     │
    │ - 依赖混淆   │     │ - 签名替换   │     │ - CDN 污染   │
    └──────────────┘     └──────────────┘     └──────────────┘

1.1.3 为什么传统签名不够?

传统的 GPG 签名虽然能验证来源,但存在以下局限:

  1. 密钥管理困难:GPG 密钥容易丢失、泄露或被盗用
  2. 缺乏透明性:签名是私密的,无法公开审计
  3. 信任链断裂:用户很难建立对签名者的信任
  4. 无法追溯历史:如果密钥泄露,无法确定历史签名是否可信

1.2 Sigstore 生态

1.2.1 Sigstore 是什么?

Sigstore 是一个由 Google、Red Hat、Chainguard 等公司联合发起的开源项目,旨在通过一系列工具和服务,使软件签名和验证变得免费、简单且自动化

1.2.2 Sigstore 核心组件

Sigstore 由三个核心组件构成,协同工作:

┌─────────────────────────────────────────────────────────────────┐
│                      Sigstore 生态                              │
│                                                                 │
│   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐         │
│   │   Fulcio    │   │   Cosign    │   │   Rekor     │         │
│   │             │   │             │   │             │         │
│   │  证书颁发   │   │  签名验证   │   │  透明日志   │         │
│   │  (CA)       │   │  (工具)     │   │  (记录)     │         │
│   └──────┬──────┘   └──────┬──────┘   └──────┬──────┘         │
│          │                 │                 │                 │
│          ▼                 ▼                 ▼                 │
│   OIDC 身份验证     签名 / 验证        不可篡改记录            │
│   短期证书          容器镜像           所有签名事件             │
│   无需密钥管理      blob / 文件        包含证明                 │
└─────────────────────────────────────────────────────────────────┘
组件全称功能
Fulcio免费的短期证书颁发机构(CA),基于 OIDC 身份颁发代码签名证书
CosignContainer Signing签名和验证工具,支持容器镜像、blob、S3 对象等
RekorRecord Keeper透明日志服务器,记录所有签名事件,提供可审计性
CT LogCertificate Transparency Log证书透明日志,记录 Fulcio 颁发的所有证书

1.2.3 工作流程

一个典型的 Sigstore 签名流程如下:

开发者                     Sigstore 服务                   验证者
  │                           │                              │
  │  1. OIDC 身份验证请求      │                              │
  │ ───────────────────────►  │                              │
  │                           │                              │
  │  2. 返回短期证书           │                              │
  │ ◄───────────────────────  │                              │
  │                           │                              │
  │  3. 用私钥签名构件         │                              │
  │  4. 上传签名到 Rekor      │                              │
  │ ───────────────────────►  │                              │
  │                           │                              │
  │  5. 返回签名 + 包含证明    │                              │
  │ ◄───────────────────────  │                              │
  │                           │                              │
  │  6. 发布构件 + 签名        │                              │
  │ ─────────────────────────────────────────────────────►   │
  │                           │                              │
  │                           │  7. 查询签名记录              │
  │                           │ ◄───────────────────────────  │
  │                           │                              │
  │                           │  8. 返回日志条目 + 包含证明   │
  │                           │ ──────────────────────────►  │

1.3 Rekor 是什么?

1.3.1 定义

Rekor 是 Sigstore 项目的透明日志组件,基于 Google 的 Trillian 透明日志框架构建。它的核心目标是:

为软件供应链中的所有签名和验证操作提供一个公开、不可篡改、可审计的日志记录。

1.3.2 核心特性

特性说明
不可篡改基于 Merkle Tree 的数据结构,任何修改都会导致哈希链断裂
公开可审计任何人都可以查询和验证日志中的条目
包含证明可以数学证明某个条目确实存在于日志中
多方支持支持多种签名格式:cosign、GPG、x509、PKCS7 等
RESTful API提供标准的 HTTP API 便于集成
免费使用公共实例由 Sigstore 项目维护,无需付费

1.3.3 Rekor 记录什么?

Rekor 记录的每条日志条目(Log Entry)包含以下信息:

{
  "body": {
    "kind": "hashedrekord",
    "apiVersion": "0.0.1",
    "spec": {
      "data": {
        "hash": {
          "algorithm": "sha256",
          "value": "abc123..."
        }
      },
      "signature": {
        "content": "base64-encoded-signature",
        "publicKey": {
          "content": "base64-encoded-public-key"
        }
      }
    }
  },
  "integratedTime": 1704067200,
  "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ff16df83ce14f839b8b2d1b34",
  "logIndex": 12345678,
  "verification": {
    "inclusionProof": { ... }
  }
}

1.4 透明日志原理

1.4.1 什么是透明日志?

透明日志(Transparency Log)是一种只能追加(append-only)的日志数据结构,具有以下属性:

  1. 不可篡改(Append-Only):一旦数据被写入,就无法被修改或删除
  2. 可验证(Verifiable):任何人都可以验证日志的完整性
  3. 包含证明(Inclusion Proof):可以证明某条记录确实存在于日志中
  4. 一致性证明(Consistency Proof):可以证明日志在不同时间点之间保持一致

1.4.2 与传统日志的对比

特性传统数据库日志传统审计日志透明日志(Rekor)
防篡改❌ 管理员可修改⚠️ 依赖系统完整性✅ 密码学保证
公开验证❌ 需要权限❌ 内部系统✅ 任何人可验证
包含证明❌ 不支持❌ 不支持✅ 数学证明
一致性证明❌ 不支持❌ 不支持✅ 数学证明
去中心化❌ 单点信任❌ 单点信任⚠️ 可多实例运行

1.4.3 Merkle Tree 简介

透明日志的核心数据结构是 Merkle Tree(默克尔树),一种哈希二叉树:

                    Root Hash
                   ┌────┴────┐
              Hash(0-1)    Hash(2-3)
              ┌──┴──┐      ┌──┴──┐
          Hash0  Hash1  Hash2  Hash3
            │      │      │      │
           Data0  Data1  Data2  Data3

关键特性:

  • 根哈希(Root Hash):任何叶子节点的变化都会导致根哈希改变
  • 包含证明:只需 O(log n) 个哈希值即可证明某个数据存在
  • 不可篡改:修改历史数据会破坏哈希链

1.5 适用场景

1.5.1 典型使用场景

场景说明Rekor 的作用
容器镜像签名确保 Docker/OCI 镜像未被篡改记录所有镜像签名事件
CI/CD 流水线自动化构建和发布时验证构件提供构建产物的签名审计日志
开源项目发布验证发布包来自可信维护者公开透明地记录发布签名
合规审计满足法规对软件供应链的要求提供完整的签名和验证历史
SBOM 关联将软件物料清单与签名绑定记录 SBOM 的签名和来源
密钥泄露追溯密钥泄露后确定影响范围通过时间戳判断签名有效性

1.5.2 企业场景示例

场景 1:金融行业合规

一家银行需要确保其部署的所有容器镜像都经过安全团队审核。通过 Rekor:

┌─────────────┐    签名    ┌─────────────┐    记录到    ┌─────────────┐
│  开发团队   │ ─────────► │  安全团队   │ ──────────► │    Rekor    │
│  构建镜像   │            │  审核签名   │             │  透明日志   │
└─────────────┘            └─────────────┘             └──────┬──────┘
                                                              │
                                                     验证 + 包含证明
                                                              │
                                                              ▼
                                                     ┌─────────────┐
                                                     │  生产环境   │
                                                     │  部署验证   │
                                                     └─────────────┘

场景 2:开源项目信任链

一个开源项目希望用户能验证下载的二进制文件:

  1. 维护者通过 GitHub OIDC 身份认证
  2. 使用 cosign 签名构建产物
  3. 签名记录自动写入 Rekor
  4. 用户通过 Rekor 验证签名的真实性和时间

1.5.3 不适用场景

场景原因
存储大量数据Rekor 存储的是哈希值和签名,不是原始数据
实时访问控制Rekor 是日志记录系统,不是权限管理系统
加密存储透明日志的设计前提是公开可审计
极高吞吐量写入公共实例有速率限制,需要私有部署解决

1.6 Rekor 与类似技术对比

技术类型主要用途与 Rekor 的关系
Certificate Transparency (CT)证书透明日志SSL/TLS 证书审计Rekor 的设计灵感来源
Sigstore CT Log证书透明日志Fulcio 证书审计与 Rekor 互补
Ledger / Blockchain分布式账本去中心化交易Rekor 更轻量,无需共识机制
AWS CloudTrail审计日志AWS API 调用记录中心化,不同信任模型
The Update Framework (TUF)软件更新安全包管理器安全可与 Rekor 配合使用

1.7 动手体验:第一条 Rekor 查询

让我们先通过命令行快速体验 Rekor 的能力:

# 安装 rekor-cli
brew install sigstore/tap/rekor-cli

# 查询公共 Rekor 服务器的日志信息
rekor-cli loginfo

# 预期输出示例:
# [rekor root hash]: <root_hash>
# [tree size]: 123456789
# [tree ID]: <tree_id>

注意:公共 Rekor 实例(rekor.sigstore.dev)记录了全球 Sigstore 用户的签名记录,日志树大小已达数十亿条。


1.8 本章小结

要点说明
供应链安全是当前的重大挑战传统签名方案存在密钥管理和透明性不足的问题
Sigstore 提供了完整的签名生态Fulcio + Cosign + Rekor 三位一体
Rekor 是透明日志服务基于 Merkle Tree,提供不可篡改的记录
透明日志提供密码学保证包含证明和一致性证明是核心能力
适用范围广泛容器签名、CI/CD、合规审计等场景

扩展阅读


下一章02 - 安装与配置 — 安装 rekor-cli、rekor-server 及相关工具。