八项 SOV 准则:关于云主权的思考
“云主权”这个说法被宽泛地使用了很久。欧盟委员会的云主权框架(EU CSF)为这个术语赋予了结构:八项主权目标,编号 SOV-1 至 SOV-8。德国联邦信息安全局(BSI)随后将其中六项转化为一套可验证的准则目录——Criteria enabling Cloud Computing Autonomy(C3A)——该目录以 C5 合规为前提,并将其余两个领域留给其他框架。
本文不是对那份目录的摘要,而是对这八项准则本身的逐条解读——每项究竟要求什么——并站在 openEduSuite 这样一个平台的角度进行思考:一个由使用它的机构自行运营的自托管开源技术栈。把准则拿去衡量供应商,是采购;拿来衡量自己,则更有意思。
| # | 领域 | 核心问题 |
|---|---|---|
| SOV-1 | 战略主权 | 谁控制供应商的战略决策? |
| SOV-2 | 法律与司法管辖主权 | 服务实际上在谁的法律之下运营? |
| SOV-3 | 数据与 AI 主权 | 谁持有密钥,数据究竟在哪里? |
| SOV-4 | 运营主权 | 服务能否在没有非欧盟生命线的情况下运行? |
| SOV-5 | 供应链主权 | 我们知道这个服务由什么构成吗? |
| SOV-6 | 技术主权 | 我们能自己构建、修补和修改系统吗? |
| SOV-7 | 安全与合规主权 | 它达到公认的安全基线了吗? |
| SOV-8 | 环境可持续性 | 它能以这种方式运行几十年吗? |
SOV-1 —— 战略主权
第一项准则问的是:供应商是否在欧盟设立,并实际受欧盟内部控制——股权结构、治理和战略决策必须位于欧洲客户在最后关头能够施加影响的地方。C3A 通过对注册地、控制权以及所有权变更预先告知的要求将其具体化。
思考。 对于自托管平台,SOV-1 发生了倒转:机构就是供应商。这个准则并未消失——它变成了治理问题。谁来决定平台的路线图?谁的利益在驱动它?一个拥有公开代码仓库和贡献者社区的开源项目,让这种控制变得可辨识,这是企业科层制做不到的;但这也意味着,机构必须真正行使其所拥有的控制权。不行使的主权,等于没有主权。
SOV-2 —— 法律与司法管辖主权
第二项准则问的是:服务实际上在谁的法律之下运营。实际的检验是域外法律敞口:受非欧盟法律制度约束的供应商,无论服务器在哪里,都可能被强制交出数据。C3A 要求每年对此类敞口进行结构化评估,并保障国家主管机关的审计权——针对基本法规定的防御状态,还要求具备将运营移交给联邦当局的能力,包括物资和人员。
思考。 这是自托管最有优势的领域:由德国高校依照德国和欧盟法律运营的基础设施,没有可供外部义务传入的外国母公司。但思考不应止步于满足。数据本身对司法管辖是无感的——重要的是每一条通向数据的路径。身份联邦(DFN-AAI)、支持合同、监控服务,甚至隐私政策中一个被遗忘的分处理者:每一条都是一个小小的开口。司法管辖主权与其说是一种状态,不如说是一种让这些路径保持短暂的纪律。
SOV-3 —— 数据与 AI 主权
第三项准则问的是:客户在技术层面是否保有对数据的控制——可追溯的存储与处理位置、保存在供应商环境之外的加密密钥、通过开放标准集成外部身份提供商、必要时支持客户端加密。领域名称中的“AI”不是装饰——在机构数据上做训练与推理,面对的是同一个问题:谁决定数据的用途?
思考。 openEduSuite 在结构上回答了这个问题。数据从不离开机构的存储;密钥保存在机构自己的密钥管理中;身份提供商(Keycloak,经 DFN-AAI 联邦)属于机构自己。不存在关于导出或分处理的谈判,因为不存在交易对手。诚实的保留意见是:可追溯性是一种持续的工作。知道每个服务把状态存放在哪里——MariaDB 卷、对象存储桶、备份——是一项 ongoing 的测绘工作,而这条准则在无声地要求地图保持最新。
SOV-4 —— 运营主权
第四项准则是 C3A 落实得最具体的:服务必须能够在欧盟境内运营——由居住在欧盟的人员操作,拥有欧盟境内的 SOC 与网络连接——并且根据准则 SOV-4-09-C,在与非欧洲基础设施断连的情况下,服务的可用性、完整性、真实性和保密性不得受损,且至少每年测试一次。
思考。 自托管平台不依赖外国运营云,字面意义上的断连测试是平凡的。这条准则有意义的转译在于上游:技术栈仍然从全球生态系统中拉取容器镜像、安全补丁和上游版本。对开源而言,断连意味着能够——安全地——在磁盘上已有的东西之上持续运行相当长一段时间。这比任何供应商审计都更难,而且在这里,实践比声明更重要:镜像仓库、vendored 依赖、书面化的冻结与运营流程。诚实的回答是:openEduSuite 今天能够通过这个测试的一个有界版本,但不应宣称能通过无界版本。
SOV-5 —— 供应链主权
第五项准则问的是:运营者是否知道服务由什么构成——软硬件组件及其原产国,理想情况下以软件物料清单(SBOM)形式记录,并对关键依赖有缓解策略。
思考。 在这个领域,开源模式并不自动占优——它只是可审计。专有平台的供应链是合同问题;开放平台的供应链是一份你可以读的文件。openEduSuite 基于 Nix 的构建使依赖图在构建层面就是确定性的、可检查的——这已经走完了通往 SBOM 的大部分路程。剩下的思考关乎集中度:开源世界的大部分汇聚在少数上游项目和仓库上。对依赖的透明还不是对依赖的独立——但它是走向独立的先决条件。
SOV-6 —— 技术主权
第六项准则问的是:运营者能否独立地构建、修补和持续开发系统——C3A 要求源代码和文档在欧盟境内备份、保持不超过 24 小时的延迟,并具备紧急情况下独立打补丁的能力。
思考。 这是开源不再只是一个论点、而成为一个事实的领域。源代码不只是可获得;把它变成运行平台的构建系统就在代码仓库之中。安全补丁不需要等待供应商的发布周期——它需要的是维护者和流水线,而两者都已存在。这条准则的 24 小时备份要求从我们这一侧读来几乎有些讽刺:困难的部分不是留住代码,而是留住知识——运行手册、架构决策、配置选择背后的原因。当那个理解系统的人离开时,技术主权会悄然流失。
SOV-7 —— 安全与合规主权
第七项准则问的是:服务是否满足公认的欧洲安全要求——NIS2、DORA 以及正在成形中的 EUCS 等认证框架。C3A 有意不覆盖这个领域:它已由 BSI 既有的工具承担,首先是 C5:2026 和 IT-Grundschutz。
思考。 这个排除提醒我们:主权和安全是两条不同的轴。一个主权但不安全的服务,是修辞更好的风险;一个安全但处于外国司法管辖下的服务,是某一天可能失去的服务。openEduSuite 通过 ZKI IT-Grundschutz 对齐工作来处理这个领域——即 BSI 基线的高校版本,并作为策略代码强制执行。值得保留的思考:EU CSF 把 SOV-7 放在主权准则的列表里,但它实际上是入场券。它之上的一切都以它为前提。
SOV-8 —— 环境可持续性
第八项准则关注的是长期:高能效基础设施、循环经济的硬件实践,以及排放与资源消耗的透明计量。这是 C3A 明确排除的领域——不是因为不重要,而是因为它超出了网络安全主管部门的职责范围。
思考。 它被排除在目录之外,说明了主权通常是如何被框定的:它是法律与技术关系的属性,而非物理资源的属性。然而长期视角就是同一视角。一个在能源或物质上无法支撑几十年的平台谈不上主权,无论合同怎么写——依赖只会以成本和硬件短缺的形式到来,而不是以外国法院的信函。把一个校园的服务整合到一个适度且高利用率的 Kubernetes 集群上,本身也是对这条准则的一种回答——只是没有任何采购文件把它列出来。
把准则拿来衡量自己,揭示了什么
走完八项准则,有三点观察留存下来:
- 这些准则构成一架梯子,而大多数“主权”产品停留在第一级横档。 数据驻留部分回答了 SOV-3,此外什么都回答不了。各领域层层递进——没有运营独立(SOV-4),法律保护(SOV-2)价值有限;没有供应链与技术主权(SOV-5、SOV-6),运营独立也很脆弱。
- 对自托管平台而言,这些准则不是过滤器,而是镜子。 拿去问供应商,是带审计答案的采购问题;拿来问自己,则既令人不安又有所助益:我们真的能在与上游断连的情况下运营吗(SOV-4)?我们了解自己的供应链吗(SOV-5)?知识能比维护者活得更久吗(SOV-6)?诚实的回答大多是“越来越能,但尚不可证明”——这仍是一个比为我们不控制的服务贴合规徽章更好的处境。
- 被排除的两个领域恰恰最有意思。 SOV-7 表明,没有安全的主权只是姿态;SOV-8 表明,没有可持续性的主权只是暂时。目录的边界与目录的内容同样有价值。
这八项 SOV 准则或许会在它们进入招标和法律时发挥最大作用——但它们更含蓄的价值在于提供了一套词汇。它让一个机构能够精确地说出自己所说的主权是什么,然后去衡量它的平台——买来的或自建的——是否真的做到了。
参与贡献
如果贵机构经历过 C5 审计、EU CSF 评估,或者形成了自己的断连与 SBOM 实践,openEduSuite 社区将珍视你的视角——尤其是那些令人不安的发现。
访问 openedu.graphwiz.ai 获取架构文档与部署指南
拿准则衡量供应商,是采购;衡量自己,是照镜子——八项 SOV 准则只是让镜子保持平稳的框架。
说明与来源
- 所讨论的框架: 欧盟云主权框架(欧盟委员会)——SOV-1 至 SOV-8 结构及采购权重的来源;BSI C3A——Criteria enabling Cloud Computing Autonomy(目录 PDF;发布公告)——具体准则(SOV-4-09-C、SOV-4-01-C1/C2 等)以及有意排除 SOV-7 与 SOV-8 的来源。
- 解读声明: 文中关于 openEduSuite 的思考是项目团队的自我评估,不是审计结论。关于 C3A 目录要求的陈述以已发布的准则为准;报道(heise online、Computer Weekly,2026 年 4 月)对本解读有所助益,在此致谢。
- 无隶属关系: openEduSuite 与 BSI、欧盟委员会或任何云供应商均无关联。本文不构成法律建议。
- 商标声明: 文中提到的所有产品和标准名称(C5、C3A、IT-Grundschutz、NIS2、DORA、EUCS、Kubernetes、Keycloak、DFN-AAI、Nix、MariaDB)仅用于识别和信息说明。
