德国保护关键基础设施的 KRITIS 框架刚刚经历了十年以来最重大的变革。《NIS2 实施法案》（Gesetz zur Umsetzung der NIS-2-Richtlinie，简称 NIS2UmsG）于 2025 年 12 月 6 日生效，大幅修订了自 2009 年以来一直管理关键基础设施运营商 IT 安全义务的《联邦信息安全局法案》（BSIG）。
对于能源、水务、医疗、交通或 IT 和电信等行业的运营机构而言，这并非一次小幅更新。受监管的对象范围、必须履行的职责以及证明合规的方式都发生了具体变化。本文将解释哪些内容已更改、哪些保持不变，以及在选择云平台时这些变化的实际意义。
什么是 KRITIS 以及新法律下的新含义
KRITIS（Kritische Infrastrukturen 的缩写）是德国联邦对关键基础设施的称呼。长期以来，KRITIS 相关设施的运营商一直受到 BSIG 规定的特定 IT 安全义务的约束，并由德国联邦信息安全局（BSI，Bundesamt für Sicherheit in der Informationstechnik）负责监管。
在新法律下，术语发生了变化。修订后的 BSIG 不再将“Kritische Infrastrukturen”作为主要类别。相反，它监管besonders wichtige Einrichtungen（特别重要的实体）和wichtige Einrichtungen（重要实体）。现在被称为kritische Anlagen（关键设施）的运营商是第一组实体的子集，仍面临最严格的要求。他们在之前 BSIG 下承担的义务大部分被保留，但在结构上进行了重组，并在某些领域有所收紧。
涵盖的行业大致保持不变：能源、交通、金融、医疗、水务、食品、IT 和电信、航天以及废物管理。发生变化的是阈值逻辑、部分特定行业的规则，以及受该框架约束的整体范围——不仅包括 KRITIS 运营商，还包括更广泛的 NIS2 类别下的数万家机构。
一个显著的结构性变化是：金融行业被拆分为两个部分——Finanzwesen（金融）和Leistungen der Sozialversicherung sowie Grundsicherung für Arbeitsuchende （社会福利和求职者基本收入）。私营保险提供商不再包含在内。受欧盟 DORA 法规约束的机构可免除某些 BSIG 报告和审计义务，因为这两个框架存在显著重叠。
关键设施运营商现在必须做什么
对于kritische Anlagen的运营商，核心义务——注册、事件报告、实施适当的技术和组织措施以及定期提供合规证据——仍然有效。但一些细节已经改变。
注册现在分为双轨制。现有的 KRITIS 运营商不仅必须在一直使用的现有 MIP 门户（Melde- und Informationsportal）中注册，还必须在新的 BSI 门户中注册为besonders wichtige Einrichtung。已注册用户的截止日期为 2025 年 12 月 6 日起三个月内，即 2026 年 3 月 6 日。新运营商必须从一开始就完成这两项注册。
审计周期延长了。 此前，运营商必须每两年提交一次合规证据。根据新的 BSIG，周期改为每三年一次。BSI 已直接通知现有运营商其各自的新截止日期。
事件报告遵循 NIS2 结构。 之前的 KRITIS 报告义务现已完全纳入 NIS2 框架。通过 MIP 报告的运营商无需在 BSI 门户中重复报告——BSI 已确认此过渡安排将至少持续到 2026 年 7 月 31 日。
攻击检测系统仍是强制性的。 2021 年 IT-SiG 2.0 引入的部署能够检测安全相关事件系统的要求，在 BSIG 第 31 条下继续适用于关键设施运营商。BSI 已发布关于这些系统必须具备的功能指南（Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung），可通过 BSI 下载页面获取。
取消共享联系点 (GÜAS)。 此前与同行业同行共享通用联系结构的运营商，现在必须各自维持与 BSI 的直接联系安排。
为什么云平台选择是一项 KRITIS 合规决策
修订后的 BSIG 明确要求运营商评估其技术供应商的可靠性，包括运行其关键工作负载的平台。这并非新要求，但现在更正式地嵌入到了框架中。特别是对于云基础设施，这引发了超越认证和 SLA 的问题。
超大规模公共云平台（如 AWS、Azure、GCP）具有难以与 KRITIS 要求协调的结构特征。数据路由决策是动态做出的，这使得在技术上很难保证数据永远不离开德国或欧盟。其内部系统（如管理程序、网络堆栈）无法进行独立审计，这与供应链评估要求产生冲突。此外，总部位于美国的提供商仍受《云法案》（18 U.S.C. § 2713）约束，该法案可强制要求披露数据，无论数据存储在何处，这与 BSIG 框架下的数据主权义务直接冲突。
这并不意味着超大规模云平台不能成为运营商基础设施的一部分。但这意味着对于被归类为关键的工作负载，平台问题具有监管权重，而不仅仅是运营权重。
合规云平台应具备的特质
根据修订后的 BSIG 和 BSI 指南的要求，支持 KRITIS 监管工作负载的云平台需要能够证明其在以下几个方面的能力：
架构实现高可用性——不仅是合同承诺的运行时间，还包括内置于计算、存储和网络层的冗余，无单点故障。
具有完全数据驻留控制的本地或私有部署——运营商必须能够验证数据的处理和存储位置，且无未经披露的外部路由。
静态和传输中加密、由运营商控制的密钥管理，以及租户之间严格的网络隔离。
符合 BSI 指南的攻击检测能力——实时监控、异常检测以及与 SIEM 工具的集成。
完整的审计日志——每一次 API 调用、每一次配置更改、每一次管理操作，均可导出供 BSI 检查和每三年的合规证据提交。
可审计的软件供应链——基于开源基础并发布软件物料清单 (SBOM)，以便运营商能够进行法律要求的可靠性评估。
FishOS 如何应对 KRITIS 要求
FishOS 由 Sardina Systems 开发，是一个将 OpenStack、Kubernetes 和 Ceph 集成到单个自动化堆栈中的云管理平台。它专为本地和私有云部署而设计，这意味着运营商可以保留对数据驻留和处理位置的直接控制，而不依赖于外部云基础设施或外国司法管辖区。
在可用性方面，FishOS 包含一个专有的健康监控组件，可持续分析实时指标和日志数据。据 Sardina Systems 介绍，它采用了一种被称为“计算机免疫学”的方法——不仅能识别故障状态，还能在导致停机之前识别性能下降的“患病”状态。这与传统的监控工具有所不同。
在安全和审计方面，FishOS 提供集中式审计日志，涵盖整个基础设施的用户和系统级操作，并支持 SIEM 集成。根据对该平台的第三方评估，FishOS 包含集成的 SIEM 功能，用于检测和响应环境内的安全威胁。
在供应链透明度方面，FishOS 构建于开源组件（OpenStack、Ceph、Kubernetes）之上，具有可公开审计的代码库。Sardina Systems 提供 SBOM 文档，直接支持修订后 BSIG 所要求的供应链可靠性评估。
FishOS 通过其 FishOS Move It 工具支持从 VMware 和其他传统平台迁移，采用最小停机时间方法或针对实时环境的更改块跟踪 (CBT) 技术。这两种方法在生产站点均有可靠的记录。
FishOS 提供了架构基础——本地主权、开源可审计性、高可用性以及运营工具——这些都是运营商构建和证明合规基础设施所需要的。
从何处开始 KRITIS 合规
如果您的机构可能属于修订后 BSIG 的监管范围——无论是作为现有的 KRITIS 运营商，还是作为 NIS2 类别下新受监管的实体——当务之急是：
首先，核实您是否符合更新后的 BSI-KritisV 规定的Betreiber kritischer Anlagen（关键设施运营商）身份，或者是否属于更广泛的 NIS2 框架下的besonders wichtige（特别重要）或wichtige Einrichtung（重要实体）。BSI 已为此发布了自评工具。
其次，如果您已在 MIP 中注册为 KRITIS 运营商，请在 2026 年 3 月 6 日之前在新的 BSI 门户中启动besonders wichtige Einrichtung的注册。
第三，根据 BSIG 第 30 条和第 31 条的技术要求评估您当前的基础设施，特别是围绕攻击检测、审计日志和供应链文档方面。
