Article 21(2)(d) 是一道供应商追问。自托管是你不再需要欠答案的回应。

TL;DR。 NIS2 Article 21(2)(d) 将供应链风险提升为董事会级别的议题，而非采购脚注。该指令本身并不强制要求自托管，但它确实追问了你的数据路径中存在哪些依赖，以及当其中某个供应商遭遇”黑色星期二”时你将面临什么。自托管基础设施能够消除大多数 SaaS 数据路径上四层中的三层，但并非全部四层。声称可以消除全部的，是让 CISO 在审计员面前陷入困境的营销话术。

• 指令原文与 ENISA 指引，用简明语言呈现。
• 大多数团队忘记绘制的四层 SaaS 数据路径。
• Rediacc 的双工具模型从供应商登记册中移除了哪些内容，又保留了哪些内容。
• 针对任何声称”NIS2 就绪”的供应商，一份包含六道问题的采购核查清单。

2020 年 7 月，Blackbaud 支付了赎金，事后才公之于众。他们事后通知了逾 13,000 个客户组织，在七个司法管辖区应对集体诉讼，最终以 4,950 万美元与各州检察长达成和解，并因披露误导性信息被 SEC 罚款 300 万美元。那 13,000 个组织中，每一个都与 Blackbaud 签有数据处理协议（DPA），大多数都审阅过 Blackbaud 的 SOC 2 报告，许多都将 Blackbaud 列入了供应商风险登记册，标注了分级评级、续约日期和责任人。

这一切都没有阻止连锁反应的发生。数据存储在 Blackbaud 边界内。当其备份环境遭到入侵时，每一个客户组织同时受到波及。

NIS2 Article 21(2)(d) 提出的问题比”你是否审计了你的供应商”更难回答。它追问的是数据路径中存在什么，以及当那个供应商遭遇”黑色星期二”时你将面临什么。对于大多数团队而言，答案是：“我们与他们同命运，而我们当时浑然不知。”

本文面向 2026 年重新谈判 DPA 的 CISO 和采购负责人。这是对 Article 21(2)(d) 的数据路径解读，而非认证合规解读。本文对自托管基础设施无法解决的问题同样坦诚，因为审计员会追问差距所在，而营销手册通常会略过这些。

21(2)(d) 究竟要求什么

指令英文原文如下（已略作删减以便阅读，暂无官方中文译本）：

“Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use […] and shall include at least the following: […] (d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”

这段文字对买方而言有两点关键。

第一，义务在于你，而非供应商。供应商的认证、SOC 2、ISO 27001，都是你风险评估的输入项，而非替代品。如果你的供应商拥有完美的合规态势却仍遭入侵，监管机构追问的将是你的供应商风险管理，而非对方的。

第二，义务范围超出合同本身。ENISA 2024 年实施指引，即委员会实施条例 (EU) 2024/2690 的附件 IV，明确了预期做法：维护 ICT 供应商登记册，按关键程度分类，对每个供应商评估其对你业务运营及其所处理数据的风险，并按既定周期更新评估。附件 IV 明确将”供应商的供应商”列为范围内，正是在这一层面，大多数团队才发现自己的供应商登记册根本算不上登记册，不过是贴了标签的合同清单。

从采购角度看，实际含义是：每一个对你生产数据拥有逻辑访问权的供应商，都必须被枚举、评分、持续监控，且须具备可替换性。“可替换”这一点，会打破大多数现有安排。

大多数团队忘记绘制的四层 SaaS 数据路径

与采购负责人坐下来，梳理一下当备份供应商的产品写入单条记录时会发生什么。诚实的数据路径从上至下如下所示：

1. 供应商应用层。 负责摄取你的数据、做出路由决策并执行业务逻辑的代码。运行在供应商基础设施上，由供应商维护、修补和监控。
2. 供应商云层。 应用程序运行所在的超大规模云服务商区域或供应商自有数据中心。存储卷、网络、IAM，通常是供应商与其签有次级处理商协议的超大规模云服务商。
3. 供应商密钥托管层。 保护供应商云中静态数据的加密密钥。在大多数 SaaS 安排中，密钥由供应商持有。“客户管理密钥”有时作为升级选项提供，但在此类安排中，密钥仍存储在供应商 IAM 可调用的超大规模云 KMS 中。
4. 供应商次级处理商层。 供应商所使用的第三方服务（CDN、可观测性、计费、客户支持工具等），这些服务可能传输或存储你的数据，或由此衍生的元数据。

这四层中的每一层都是你 Article 21(2)(d) 供应商登记册上的一个条目，各自有其事件历史、入侵波及范围和合同谈判空间。当你续签 SaaS 供应商合同时，实际上是隐式续签了全部四层，因为 SaaS 供应商的合同是你唯一能谈判的那份。

Blackbaud 事件是一次第 2 层入侵（供应商云），通过第 1 层（供应商应用）扩散，并因第 3 层（供应商密钥托管，即受影响数据库中无租户隔离的服务端密钥）而对每位客户可见。Blackbaud 的次级处理商并非入侵路径，但客户们由此发现了三个自己此前未曾列出的次级处理商。

Blackbaud、Druva 式密钥托管与级联模式

Blackbaud SEC 申报文件中有三个细节，对于 NIS2 解读至关重要。

第一，Blackbaud 持有客户数据的加密密钥，包括作为入侵目标的备份环境。当时没有提供客户管理密钥选项。在事后的 SEC 诉讼中，这被定性为控制缺口，而非违规，因为 Blackbaud 的合同允许此类安排。NIS2 在 Article 21(2)(d) 下对同样安排的审视更为严格，因为客户对于自己无法可见的控制措施，根本无法进行有意义的风险评估。

第二，此次入侵波及的备份数据比实时数据库还要陈旧。那些在 Blackbaud 主系统中已删除实时数据的客户组织，其数据仍通过备份环境遭到暴露。这就是级联模式：供应商被攻破后，历史数据同样难逃波及，尽管客户原以为这些数据早已超出范围。

第三，逾 13,000 个客户组织收到入侵通知。其中许多是小型非营利机构和学校，没有应对事件的运营能力，没有 DR 应对手册，也没有第二家备份供应商可以故障切换。从某种意义上说，供应商的事件变成了他们自己的事件。

对于 Druva 式现代 SaaS 备份，架构在某些方面更为先进（租户级密钥隔离更为普遍，更高层级提供 BYOK），但四层数据路径依然存在。供应商应用、供应商云（通常是 AWS）、密钥托管（有时由供应商持有，有时是客户 KMS 中的 BYOK，有时为混合模式）以及次级处理商。任何一层的入侵都会同时波及所有客户，因为每位客户的数据都在边界的同一侧。

这是结构性论点，并非针对 Druva 的批判。Druva 的合规管理比 Blackbaud 更为严格。论点的核心在于：任何为 SaaS 而设计的备份产品，其结构使得第 2 层和第 3 层入侵形成了 21(2)(d) 下客户无法切实履行的义务。

自托管消除四层中的三层

Rediacc 的构建方式有所不同。完整架构记录于架构页面，但与供应链相关的核心形态是两个通过 SSH 通信的二进制文件：

• rdc 运行在操作员的工作站上。它读取一个扁平 JSON 配置文件（位于 ~/.config/rediacc/），通过 SSH 连接到操作员自己的机器，并分发命令。
• renet 以 root 权限运行在操作员自己的服务器上，管理 LUKS 加密磁盘映像、隔离的 Docker 守护进程以及反向代理。

操作员无需登录 Rediacc 公司的基础设施即可执行备份、恢复或分叉操作。数据路径中不存在 Rediacc 公司的云服务。存储库的 LUKS 凭证存储在操作员的本地配置文件中（模式 0600），从不存储在服务器上，从不发送给 Rediacc。数据路径如下所示：

1. 操作员工作站。 运行 rdc，持有 LUKS 凭证。
2. 操作员自有服务器。 运行 renet，持有 LUKS 加密存储库。
3. 操作员自有备份目标。 任何兼容 rclone 的存储（S3、B2、OneDrive、本地 MinIO），接收加密卷。

不存在第 4 层。对于未选择使用实验性云适配器的操作员，Rediacc 公司不是次级处理商。对于自托管操作员，与 Rediacc 公司的关系是软件许可，而非数据处理协议。

这是数据路径论点，也是在供应商登记册讨论中应率先提出的正确论点。SaaS 竞争对手可以提供客户管理密钥（现代产品大多如此），但 SaaS 竞争对手无法提供”我们不是次级处理商”这一承诺。

在数据路径论点站稳脚跟之后，第二个要点是密钥托管。使用 Rediacc，LUKS 凭证存储在操作员的配置文件中，仅此而已。没有密钥托管，没有 Rediacc 公司可在操作员丢失凭证时提供的恢复服务。这也是零知识配置存储的推荐架构：加密密钥在客户端通过 passkey PRF 扩展派生，服务器仅存储不透明 blob。服务器无法读取 SSH 密钥、LUKS 凭证、IP 地址或任何明文配置。轮换访问令牌不会赋予服务器对历史数据的读取权限。

对于 Article 21(2)(h)（加密），这一点很重要。对于 Article 21(2)(d)（供应链），这一点更为关键，因为它消除了 Rediacc 公司通向操作员数据的最后一条逻辑访问路径。

自托管无法消除的内容

自托管改变了供应商清单的构成，并非删除了它。审计员仍会追问三件事：

1. 你仍然有供应商，只是换了一批。 硬件供应商（Hetzner、Hostinger、OVH，你的托管机房，或你自己的裸金属服务器）、虚拟化层（KVM、VMware）、操作系统（Debian、Ubuntu、RHEL）、容器镜像仓库（Docker Hub、GHCR、你的私有仓库），以及你的服务所拉取的基础镜像。其中每一项都是 Article 21(2)(d) 的登记条目。自托管改变了供应商清单，并没有删除它。

2. Rediacc 目前尚未拥有 ISO 27001、SOC 2 或 BSI C5。 这些在路线图上，尚未落地。对于将认证作为门控机制的采购团队，这是真实存在的摩擦。可防御的反驳正是本文一直在阐述的：数据路径论点意味着，那些认证所证明的大部分内容（供应商云安全控制、供应商人员访问管理、供应商次级处理商管理）都不在范围内，因为 Rediacc 公司不在数据路径中。这一论点需要谨慎、有据地呈现，而非在买方确实需要认证时以此替代认证。

3. GRC 层仍属于你。 Rediacc 为操作员提供包含 70 余个事件的哈希链审计日志（rdc audit verify 可端到端验证链的完整性）。但它不提供供应商登记册、控制框架或证据收集工作流。这些仍需借助 Drata、Vanta、OneTrust 或欧洲本土竞争者。配套的实际账单文章详细介绍了这种互补关系的成本结构。

你不再需要谈判的 DPA

为了使这一点具体化，以下是来自一次真实采购对话的”迁移前后”登记册条目（已匿名化处理）。买方是一家拥有 280 名员工的德国制造企业，依 Annex II 被归类为”重要实体”。其备份相关的原始供应商登记册条目如下：

迁移至 Hetzner 上的 Rediacc 之后：

两个登记条目，而非一个。关键级条目对应 IaaS 提供商，买方已有 DPA 和经过验证的退出方案，因为 IaaS 是大多数团队都知道如何管理的关系。Rediacc 条目为非关键级，因为它是软件许可，而非数据处理商。

这正是 CISO 最终倾向于减少数据平面 SaaS 依赖的结构性原因，即便从电子表格上看采购成本相近。登记册条目的形态截然不同。

采购核查清单

针对 2026 年销售周期中任何声称”NIS2 就绪”的供应商，六道问题：

1. 我们静态数据的加密密钥存储在哪里？ 如果答案是”在我们的 HSM 中”或”在我们可通过 IAM 调用的客户 KMS 中”，该供应商就在你的密钥托管链上。如果答案是”在你的本地配置文件中，从不存于我们的基础设施”，则不在。

2. 贵公司哪些人员在技术上可以读取我们的数据，忽略法律条款？ 不是”谁被授权”，而是”谁能够这样做，如果他们想要且审计日志被关闭的话”。如果答案不为零，这就是你内部人员风险评估的目标群体。

3. 恢复测试是基于真实生产克隆，还是基于合成测试数据？ Article 21(2)(c) 和 (e) 合并解读，要求备份能够真正恢复。仅对合成数据进行验证的供应商，验证的是备份文件完整性，而非恢复能力。（更多内容参见配套文章持续有效性评估。）

4. 你们的审计追踪是否记录了每个操作背后的行为者类型，即人工还是 AI 代理？ AI 代理活动是增长最快的审计日志类别。一份 2026 年不区分人工与代理的审计日志，到 2027 年将会被视为明显差距。

5. 请列出对我们数据（包括元数据）拥有逻辑访问权的每一个次级处理商。 “逻辑访问”是正确的措辞，“包含元数据的逻辑访问”是更好的措辞，因为仅元数据访问正是计费、可观测性和客户支持类次级处理商通常拥有的权限，即便有效载荷已加密，这也足以泄露敏感结构信息。

6. 如果贵公司在 2027 年被非欧盟买方收购，你们的退出方案是什么？ GDPR 的充分性框架、《云法案》和 FISA 702 都是动态变化的。供应商今天的数据驻留声明，不是三年后的保证。买方需要追问的是：如果供应商的所有权发生变化，数据路径会发生什么。

能清晰回答全部六道问题的供应商并不多见。能回答四道并坦诚承认另外两道存在差距的供应商，比自信地回答全部六道的供应商更值得信赖。可信度的信号，在于愿意说出尚未解决的问题。

对下一个续约周期的启示

如果你在未来十二个月内面临备份或 DR 续约，且 Article 21(2)(d) 已纳入采购评分表，三个具体行动：

1. 在白板上绘制你当前供应商的四层数据路径。如果你无法说出第三级次级处理商的名称，你就存在早于 NIS2 的登记册完整性问题，续约正是修复它的合适时机。
2. 用上述六道问题核查你的现有供应商。将答案发给你的 DPO 和审计员，询问差距是否已被接受。如果差距涉及第 3 层（密钥托管）或第 4 层（未枚举的次级处理商），那就是切入点。
3. 研究一下采用自托管控制平面后，替代方案的供应商登记册会是什么样子。比较的是登记册条目，而非许可证成本。许可证成本在两倍以内相差无几，但登记册条目的形态截然不同。（配套文章NIS2 合规栈的结构性成本详细梳理了哪些可以被消除，哪些依然存在。）

如果我们是你候选名单上的备选方案，承诺是具体的。请将你们的供应商问卷发给我们，我们将基于已部署实例填写，包含你的问题的真实答案，包括差距部分。如果你希望在提交文件前先了解架构，我们可以安排一次与创始人进行的 30 分钟架构评审。通往可防御登记册条目的路径，不是光鲜的宣传册，而是答案本身，包括令人不舒服的那些。

关于 Rediacc 能力与 NIS2 各条款的公开对照，参见 NIS2 与 DORA。关于更广泛的合规框架，参见合规概览、数据主权和本地部署。