合规性
主页上说 “内置审计追踪。” 本页是该声明必须经受住考验的地方：具体的机制、实际的代码，以及审计人员无需要求我们信任某个仪表板即可运行的工具。
审计记录：哈希链式， 默认启用
Odysseus写入的每个审计事件都链接到前一个事件。每一行存储entry_hash = SHA-256(prev_hash || canonical_json(event))，因此修改或删除一行会破坏其之后所有内容的哈希值——不仅仅是该行本身。
这并非一个需要您记得开启的可选功能。HashChainConfig的文档注释明确指出：“该链默认启用——零值（禁用：false）……省略HashChain块即获得防篡改审计，无需额外”配置步骤（pkg/audit/hash_chain.go:19-23）。控制平面在启动时会宣告此状态：“Audit hash chain enabled (default-on; set HashChain.Disabled=true to opt out)”（pkg/audit/postgres_logger.go:247）。禁用它是一个经过慎重考虑并记录的行为，而非需要发现的默认设置。
锚定和外部见证 — 均为可选，均可插拔
除了链本身，Odysseus可以定期将哈希值锚定到您无需信任我们的两个地方：
- Vault Transit 签名。 当设置了
HashChainConfig.VaultTransitKey时，每个锚的条目哈希在存储前会通过 Vault 的transit/sign/{key}端点进行签名（pkg/audit/hash_chain.go:43-46,pkg/audit/postgres_logger.go:850-861）。保持该键未设置则不会进行签名 — 这是可选的，不是隐藏的依赖。 - 外部见证。 锚发布器接受任何实现了小型接口的见证 — Consul KV、S3 WORM 存储桶或您选择的其他存储 — 并在本地持久化写入后将锚镜像到该处。一个
nil见证只是禁用外部镜像；本地完整性不依赖于它（pkg/audit/hash_chain.go:51-56,pkg/audit/postgres_logger.go:863-889）。
一个工具，而非截图
odysseus-audit-verify 是一个独立的二进制文件 — 它是位于 cmd/odysseus-audit-verify/main.go 的自有 main 软件包，独立于控制平面构建和交付。为其提供审计数据库的凭据，它便会按 sequence_num 顺序遍历每一行，重新计算每个哈希值，并交叉检查每个锚点。它不通过 Odysseus API、仪表盘或平台自身渲染的任何组件工作。它直接连接到 Postgres，因此并非零网络工具，但它独立于正在运行的控制平面：审计人员可以将其指向一个数据库副本，并获得一个 Delta Telematics 无人能够操纵的答案。
它为每类问题报告一个不同的退出代码，这些代码记录在二进制文件自身的头部注释中：
| 退出代码 | 含义 |
|---|---|
0 | 链完整，所有锚点匹配 |
1 | 链完整性缺陷——链接断裂、哈希不匹配、条目缺失 |
2 | 锚点验证失败——锚点哈希不匹配或签名无效 |
3 | 操作错误——数据库不可达、行格式错误等 |
源：cmd/odysseus-audit-verify/main.go，第 12–18 行（已记录的行为）和第 56–59 行（退出代码常量本身）。
租户隔离由数据库强制执行，而非仅由应用程序
三个独立的边界，每个都可在代码中独立检查：
- Postgres 行级安全，失败关闭。 审计表在设置了
ENABLE ROW LEVEL SECURITY和FORCE ROW LEVEL SECURITY的情况下运行 — 一个专用测试断言两者均为true并解释了原因：如果没有它们，“这里的每个测试都会通过，而租户却可以读取彼此的审计跟踪”（pkg/audit/postgres_rls_test.go:197）。如果无法为查询设置租户安全上下文，则查询不会运行 — 该代码路径被标记为// Fail-closed: if we can't set RLS context, don't proceed with the query（pkg/audit/postgres_logger.go:1067）。 - 按租户的 Vault 路径。每个租户的密钥都存储在
tenants/<tenantID>/下，路径验证会拒绝该前缀之外的任何内容（pkg/vault/validation.go:25,51,61）。 - 按租户的 Docker 网络。内部网络命名为
<tenantID>-<network>，租户的默认网络是odysseus-<tenantID>-default— 默认情况下，租户的容器不会落入共享的内部网络（pkg/docker/client.go:1647-1652,1697-1700）。
我们实际的立场
我们不持有认证，也无意暗示。我们所拥有的是一份文档化的、自评的控制措施与五个框架的映射，它保存在安全团队自己的审计文档中，而非营销材料中：
| 框架 | 内部就绪性 | 备注 |
|---|---|---|
| SOC 2 Type II | 85% | 访问控制、审计日志 |
| ISO 27001 | 80% | 信息安全控制 |
| GDPR | 75% | 数据保护控制 |
| PCI DSS | 70% | 不处理支付数据 |
| HIPAA | 60% | 非我们主要用例 |
来源：docs/security/02-owasp-security-audit.md，“合规映射”表格，第490至498行。
这些是自我评估的准备就绪百分比，并非来自认可第三方的审计结果。我们在定价页面上也明确说明：措辞是“与SOC 2和ITSG-33对齐的控制措施和审计证据”，并非合规本身——做出这一措辞更改，正是因为目前尚无认证存在。如果情况有变，本页面将列出认证机构和日期；在此之前，请将上述所有百分比视作我们自身的功课，而非外部证明。
关于产生这些控制措施所基于的安全态势的审计，请参见安全审计页面。关于日常安全架构——身份验证、密钥管理、基础设施加固——请参见安全。
这些数字和声明是如何得出的
- 本页上的每一项声明都经过了直接核对，依据是引用旁边的文件名和行号，核对日期为 2026 年 8 月 21 日，而非取自该功能的早期描述。当某个机制是可选的（例如 Vault Transit 签名、外部见证者）时，我们会明确说明，而不是让上下文暗示其总是运行。
- 离线验证程序独立于控制平面，这是一个真实的属性 — 它是一个直接与 Postgres 通信的独立二进制文件 — 但它不是一个零依赖工具：它仍然需要凭证和到审计数据库（或其副本）的网络访问。我们如此描述它，而不是将其描述为完全离线。
- 合规百分比是我们内部的自我评估，其日期与包含它们的文档一致，并非由任何外部机构进行的认证声明。如果该文档被修订，此表格将变得陈旧，直到根据新版本重新核对。