证书透明度日志监控第3页：数据采集、接入与数据治理

01 · 数据源全景

CT监测可复用的数据源可分为四类：全量直连（官方日志API/静态tiles，自主可控、时效最好）、检索服务（crt.sh、Censys，适合回溯与调查）、流式管道（CertStream生态，适合实时告警）、批量分析（BigQuery公开数据集，适合研究）。组合使用、互为冗余是本页的核心建议。

注：各服务条款与限额以官网为准；托管类数据源不可替代全量直连，二者应互为校验。另：Cloudflare Radar证书透明度监控面板已于2026年8月转为正式可用（GA），提供按日志、CA维度的签发与合规状态看板，可作态势指标（子课题06）的补充来源。

02 · RFC 6962日志直连采集

对每份目标日志（Chrome∪Apple日志列表内、状态为usable），采集器执行以下循环：

• 日志列表获取：采集范围以两份浏览器日志列表中状态为"活跃（usable）"的日志全集为基线——Chrome列表由Google发布（gstatic.com/ct/log_list/v3/log_list.json），Apple列表由Apple发布（valid.apple.com/ct/log_list/current_log_list.json）；
• 进度锚点：周期调用get-sth获取tree_size；以本地已入库的最大entry_index为游标；
• 批量拉取：get-entries?start=N&end=M顺序拉取，单批上限通常为1000条（以各日志实现为准）；多日志间并行、单日志内限速，遵守运营方礼貌要求；
• 断点续传：游标与原始响应持久化（磁盘/位点表），进程重启后从断点续传；异常跳批须回退重试；
• 完整性校验（三重）：①按RFC 6962复算每条leaf_hash与MerkleTreeLeaf；②验证STH签名（get-roots获取日志公钥集）；③与第二独立监控源比对STH（tree_size+根哈希一致），可发现日志分裂视图——该职能即第2页所述"审计者"角色；
• 到期与变更跟踪：日志按时间分片到期（停收新条目），列表新增/移除须自动同步，避免采集中断造成盲区。

# 检索含关键词的证书（identity 匹配 CN 与 SAN），JSON 输出
curl -s "https://crt.sh/?q=identity:examplebrand&output=json" \
  | jq -r '.[].name_value' | sort -u | head -50

# 按域名后缀拉取（%. 为 crt.sh 通配后缀语法），配合 exclude=expired 过滤
curl -s "https://crt.sh/?q=%25.example.com&output=json&exclude=expired"

注：crt.sh适合调查与规则调试；生产告警链路不应依赖第三方检索服务的可用性。

03 · 静态日志（tiles）采集

Static CT日志的读路径完全静态化（C2SP tlog-tiles规范）：日志发布checkpoint（含日志标识、树大小、根哈希与签名）与tile/data/N（第N片，固定256条）两类静态资源。采集要点：

• 增量diff：轮询checkpoint发现树增长→按需下载新tile→本地重组；checkpoint带有HTTP缓存语义，轮询成本低；
• 无状态高并发：tiles由对象存储/CDN承载，可多线程并行回扫历史，天然适合冷启动全量初始化；
• issuer去重：tiles内以issuer关键信息去重存储证书链，重构完整链需同时拉取issuer bundle（get-roots/issuer索引）；
• 合入即终态：静态日志"先排序落片、后签发SCT"，条目一旦发布即不可变——采集端无需处理v1的"MMD窗口内未合入"状态机。

04 · 流式接入与消息格式

实时告警链路推荐基于CertStream协议接入：服务器持续拉取多份日志，通过WebSocket向订阅者推送新条目。典型消息结构如下（字段名以实际实现为准）：

{
  "data": {
    "update_type": "PrecertLogEntry",          // 或 X509LogEntry
    "leaf_cert": {
      "subject": {"CN": "login-secure.example-brand.net"},
      "extensions": {"subjectAltName": {"DNS": [
        "login-secure.example-brand.net",
        "www.login-secure.example-brand.net"]}},
      "fingerprint": "9f:2a:...", "not_before": 1735689600, "not_after": 1743465600
    },
    "chain": [{"subject": {"CN": "E5"}, "issuer": {"CN": "ISRG Root X1"}}],
    "source": {"name": "example-log", "url": "https://log.example/"},
    "cert_index": 123456789, "seen": 1735689661.42
  },
  "message_type": "certificate_update"
}

• 生产注意：断线指数退避重连；多日志推送可能乱序（以cert_index与CT时间戳排序）；消费端背压（磁盘持久化位点，参考certstream-server-rust设计）；
• 时间基准：统一使用SCT/日志时间戳（见第2页§02 info-box），不依赖推送到达时间。

05 · 存储与索引设计

推荐"原始层+规范化层"两层架构：原始JSONL完整入对象存储（取证与回放），规范化层入列式库（ClickHouse）或搜索引擎（OpenSearch/ES）支撑检索与聚合。

• 索引策略：san_list倒排（前缀/后缀分词）、sha256唯一索引、not_before+issuer组合索引支撑时序规则；
• IDN规范化：NFKC规范化+小写化+去尾部点；punycode与unicode双写，检测用unicode视图、溯源用原始值；
• 通配符处理：*.example.com拆解为example.com并置wildcard标志位，参与品牌匹配但不直接生成告警。

06 · 去重、规范化与数据质量

6.1 三类去重

6.2 数据质量SLO

• 解析失败率、字段缺失率、源断流时长纳入日常监控；每源维护"最近条目年龄"看板；
• 数据缺口回补：断流恢复后按游标/checkpoint回溯补齐，并在数据集中标记缺口区间，避免时序规则误判。

07 · 数据量级与成本估算

以Let's Encrypt为锚点（其官方十周年数据）：2024年日均签发400万张以上，2025年9月末单日首次突破1000万张，此后日签发量常达千万量级；叠加precert/final双记录与全球其他CA，全网CT日志日新增条目为千万级。量级测算：

• 存储估算：规范化记录约0.5—1KB/条→日增数GB至十GB级，年累计数TB级；原始JSONL更大，需冷热分层（全量30天热区+归档）；
• 降本策略：非关注域名（不在任何品牌词库/白名单交集内）仅存指纹+SAN+时间三元组，全量证书体只保留命中检测规则的部分。

08 · 法律合规与伦理

• 数据属性：CT日志为公开数据，且证书本身不含注册人联系方式（与WHOIS/RDAP因隐私保护（redaction）而信息萎缩形成鲜明对照）——这是CT相较注册数据源的合规优势；
• 关联数据边界：管道若叠加RDAP/被动DNS/URL情报富化，须分别遵守对应数据源条款；《个人信息保护法》框架下，应避免采集与分析无关的个人可识别信息；
• 内部域名泄露的双向性：企业私有子域进入公开CT日志是公认风险（缓解：内部系统使用内部CA，见第7页§07）；同理，对外监测时获取的他方内部域名信息应按敏感信息管理，对外共享前最小化；
• 法规框架：采集、存储、分析、共享全流程遵守《网络安全法》《数据安全法》《个人信息保护法》，处置协同遵循《反电信网络诈骗法》（2022-12-01施行）。

本节参考来源（第3页）

以下均为真实可查来源（规范原文、官方文档、开源项目仓库）。