📚 课程目录第3章审计追踪的核心要素

3、审计追踪的核心要素：数据完整性、可追溯性、不可否认性归纳总结

聊审计追踪，绕不开三个词：数据完整性、可追溯性、不可否认性。我个人认为，它们就像三条腿的凳子，少一条都站不稳。你在RNA-seq项目里做审计，说白了就是要同时管好这三件事。

为什么会这样？因为RNA-seq的数据链路太长了。从样本制备、测序、比对、定量到差异分析，中间经过十几个步骤，每一步都可能引入问题。没有完整性，数据本身不可信；没有可追溯性，出了问题找不到根因；没有不可否认性，责任归属一笔糊涂账。嗯，今天我们就把这三点掰开揉碎了讲清楚。

3.1 三个要素的内在联系

先看一张关系图，我习惯叫它「铁三角」。

你看，三个要素两两之间都有虚线连接，表示它们相互支撑。而审计追踪位于正中心，依赖这三个支柱才能运转起来。我在项目中见过太多案例——要么只做了完整性，忽略了可追溯性；要么日志是记录了，但没做防篡改，最后谁也说服不了谁。所以，三者必须一起上。

3.2 数据完整性——一切信任的根基

数据完整性，说白了就是保证数据在存、传、用这三个环节里没被人动过手脚。你做RNA-seq，原始FASTQ文件如果被篡改过，后面的比对、定量全是错的。你想想看，这多可怕。

实现数据完整性，最常用的手段就是哈希校验。SHA-256是目前的主流选择。

# 生成校验和文件
sha256sum raw_data/RNA_seq_sample1.fastq.gz > checksums.sha256

# 传输或存档后验证
sha256sum -c checksums.sha256
# 输出示例：
# raw_data/RNA_seq_sample1.fastq.gz: OK

我曾经接手过一个合作项目，对方传过来的FASTQ文件比对率只有30%。我花了两天排查参数、参考基因组版本，最后跑了一次校验和，发现文件在传输过程中损坏了。从那以后，我定了一条硬规矩：所有外部数据进来，第一件事就是跑SHA-256验证。你可以把这个步骤写进你的pipeline前置检查里。

关键指标：RNA-seq项目中至少要对以下文件做完整性校验——原始FASTQ、比对后的BAM、基因表达矩阵（counts/TPM）。这三类文件一旦损坏，下游分析全是废的。

除了哈希，版本控制也是完整性的一部分。你可能会说，Git不是管代码的吗？其实管理分析脚本、配置文件、甚至报告草稿都非常好用。

git init
git add configs/star_params.yaml
git commit -m "STAR v2.7.10a params for project P2025-0321"
git tag v1.0-initial

每次参数调整都留一个commit，你就能清楚地看到配置的演变历史。别嫌麻烦，我一个同事曾经因为忘了记录参数变更，重复跑了三周的分析。这种事，一次就够你长记性了。

3.3 可追溯性——还原每一个步骤

可追溯性，就是能顺着数据链路往回查。你拿到一个表达矩阵，要能回答这几个问题：

这个矩阵是从哪个BAM文件算出来的？
那个BAM又是用什么参数比对生成的？
原始FASTQ是谁在什么时候用哪个测序仪跑的？

我建议每个分析项目都建一个元数据清单，记录每个产出文件的「身世」。你看这个结构：

project_metadata.yaml

samples:
  - id: SAMPLE_001
    fastq_path: data/raw/SAMPLE_001_R1.fastq.gz
    fastq_checksum: sha256:a3f5b2c8...
    aligner: STAR
    aligner_version: 2.7.10a
    reference: GRCh38.p14
    bam_path: results/align/SAMPLE_001.bam
    bam_checksum: sha256:de9f1c3a...
    quantification: featureCounts
    quant_version: 2.0.6
    count_path: results/counts/SAMPLE_001.counts.txt

有了这份清单，任何一步出了问题，你都能往前追溯到源头。我在实际项目中就把这个YAML文件作为pipeline的必产物，没有它，分析结果不能交付。

小技巧：把元数据清单也纳入Git版本管理，每次pipeline跑完自动生成并提交。这样元数据本身也有了变更历史，可追溯性又提升了一层。

3.4 不可否认性——谁也无法抵赖

不可否认性，解决的是「人」的问题。数据没被篡改（完整性）、来源可查（可追溯性），但到底是谁在哪个时刻做了什么操作？如果没有记录，出了事大家互相推诿，那就麻烦了。

实现不可否认性的核心手段是操作日志+身份认证。每个人登录系统、运行分析、修改参数，都要留下带时间戳和身份标识的记录。

这是我在一个RNA-seq管理平台里定义的审计日志格式：

{
  "event_id": "EVT-20250321-00342",
  "timestamp": "2025-03-21T14:32:18+08:00",
  "user": "li.zhang@lab.org",
  "action_type": "PIPELINE_RUN",
  "pipeline": "STAR_align",
  "params_snapshot": {
    "outFilterMismatchNmax": "8",
    "outFilterMultimapNmax": "20"
  },
  "input_files": ["data/raw/SAMPLE_001_R1.fastq.gz"],
  "output_files": ["results/align/SAMPLE_001.bam"],
  "ip_address": "10.0.1.25",
  "digital_signature": "-----BEGIN PGP SIGNATURE----- ... -----END PGP SIGNATURE-----"
}

你看，时间、用户、操作内容、输入输出、IP地址、数字签名，一应俱全。这样的日志一旦写入，任何人（包括记录者自己）都改不了。

注意：日志存储必须使用追加写入（append-only）模式，配合写保护或区块链式的链式哈希，防止事后篡改。我曾经见过一个项目，日志存在普通文件里，结果有人偷偷改了时间戳，差点让审计作废。

对于参数变更这种高频操作，我习惯用带有签名的日志行：

2025-03-21 14:32:18 | li.zhang | STAR_align | --outFilterMismatchNmax 10→8 | IP:10.0.1.25 | SIG:OK
2025-03-21 15:10:05 | wang.yu | featureCounts | -s 2→1 | IP:10.0.1.26 | SIG:OK

每行都带签名，事后谁也抵赖不了。说句实话，这种严谨程度在合规审查（比如FDA 21 CFR Part 11）里是硬性要求，但即使没有外部审查，内部复盘时也能省去大量扯皮时间。

3.5 三要素的协同落地

讲了这么多，三个要素其实不能分开管。我在项目里把它们打包成一套审计追踪检查表，每次交付前逐项确认：

要素	核心问题	实现手段	RNA-seq 落地检查项
数据完整性	数据是否被篡改？	SHA-256校验、版本控制	FASTQ/BAM/counts 是否都有校验和？
可追溯性	数据从哪里来？经过了哪些处理？	元数据清单、Git追踪	每个产出文件能否追溯到原始数据和参数？
不可否认性	谁在什么时间做了什么？	append-only 审计日志、数字签名	每次pipeline运行和参数修改是否有带签名的日志？

这张表我贴在每个项目的根目录下，作为交付前的最后一道关卡。三个问题都回答「是」，审计追踪才算到位。

我的经验：别等到项目快结束了才补审计材料，那会把你累死。从项目启动的第一天就把完整性、可追溯性、不可否认性的工具链搭好，后面每个步骤自动生成，最后汇总就是顺手的事。

说到底，审计追踪不是给合规部门看的「表面功夫」。它是保护你项目成果、减少无效返工、提升团队信任度的工程手段。数据完整了、链路可查了、操作留痕了，你晚上睡觉都踏实。