Canonical
16 December 2024

《网络弹性法案，CRA》对物联网制造商而言意味着什么

Compliance CRA cybersecurity IoT devices lang:cn

欧盟《网络弹性法案》即将施行。之前的博客中已经深入讨论过即将施行的这一法规，公司网站和福布斯技术委员会的早期文章中介绍了该法案的背景和规定，后期的文章中则探讨了它对使用开源的企业意味着什么（您也可以在《福布斯》阅读）。不过，留给设备和软件达到该法案中网络安全新要求的时间越来越少了，笔者想要讨论一下应该如何完善您的设备设计和网络安全基础。在本篇博客中，笔者将介绍网络安全的蓝图，并概述如果是物联网或设备制造商，您应该做些什么来达到 CRA 规定的要求。

设备制造商如何为 CRA 做好准备

大体而言，CRA 所涉及的是所有设备制造商和开发商都应该关注的几个关键领域。其中包括：

强有力的组织安全流程
设备设计层面的良好网络安全原则
强健的设备安全性，例如更好的身份管理和默认访问
明确的漏洞监控和修补流程
关于持续为市场上的设备提供支持和安全更新的清晰计划
适当和标准化的漏洞发现报告渠道和流程
安全缺陷和漏洞的公开信息及认识
设备软件供应链的详尽清单
关于合法收集、存储和处理私人用户数据的明确且合规的政策

当然，像“提高设备安全性”这样的概念似乎让人无所适从。您会从哪里开始呢？那么，作为第一步，笔者强烈推荐我们针对设备安全所采用的 Ubuntu 蓝图。下面来看看我们的蓝图如何指导我们实现符合要求的设备设计。

Ubuntu 蓝图助力创建符合 CRA 要求的安全设备

从操作系统级别开始

您应该始终假设您的设备将部署在不安全的环境中。因此，设备所部署的操作系统是您需要考虑的最关键安全因素，因为它是所有其他安全措施的基础。

操作系统应当简单、功能正常且具有最小攻击面

在 CPU 周期、内存和存储方面，物联网设备通常只有极少的可用资源。因此，这些设备使用的操作系统需要简化，并占用尽可能少的空间。

然而，减少数据使用和提高简化程度不仅仅是让操作系统在设备上运行；它还需要帮助提高操作系统的安全性。复杂度越低，漏洞点越少。

物联网操作系统需要包含安全更新

每天都有新的漏洞被发现，CRA 强制要求在漏洞出现时尽快发现、修补并报告被利用风险。设备设计以及设备操作系统本身，都需要具备强大的支持基础，以及简单的持续补丁和远程更新方式。

操作系统必须采用集中更新机制

对于任何必须满足 CRA 就绪要求的物联网操作系统而言，在可靠且自动更新软件的能力方面不存在任何商量余地。这一点对于涵盖大量设备（不具备定期或可预知更新计划的设备，没有明确的最终用户更新 UI 的设备，或者部署在极难接近位置的设备）的物联网部署尤其重要。

对更新进行身份验证同样重要。经身份验证的更新可以作为一种保护机制，避免用户遭受人为错误或供应商故障的负面影响。当设备接收更新时，务必确保这些更新验证无误。

操作系统应内置自动更新回滚功能

当然，有时会出错。比如推送的更新有误，或者更新引入了新的、不可预见的漏洞。设备上的操作系统需要一种机制来确保不会出现以下情况：如果更新失败，操作系统必须能够自动回滚到最后已知的工作配置，从而最大限度地保证设备不仅安全，而且功能正常。

完整安全的系统和其他关键文件

防止可信文件受到未经授权的篡改至关重要。作为基准，必要的设备和应用程序文件应当经过身份验证，并受到只读保护以防不必要的更改。这些文件还需要更换通用数字认证。这样可以在安装之前更好地检查每个快照的完整性，并保证持续保持这种完整性。

应用程序应是自包含式和沙盒化的

有时候，应用程序或设备需要彼此共享数据，但这些应被视为特殊情况并专门设计为一项功能或程序。这是因为默认允许数据在应用程序或文件之间自由流动会给恶意行为者提供了一个有力的攻击媒介。默认情况下，应该将您的文件和应用程序隔离在它们各自的限制性沙盒中，最大限度地减少恶意或故障应用程序可能造成的损害。

操作系统应采用熟悉的架构和已知的编码方法

越简单越好。使用小众的框架、架构或语言来构建设备或应用程序可能会很吸引人，但在已知的框架和生态系统中运行几乎总是更好。一般来说，使用更传统的堆栈和设备操作系统可以享受更多的支持、更快的修复和更好的漏洞发现功能，这有助于您响应 CRA 的安全和披露要求。

从一开始就必须考虑长期持续支持

产品周期短和利润率低，使得许多公司没有动力提供高成本的长期支持。然而，CRA 却要求制造商在其设备的整个生命周期内提供一份更新计划表。

您所采用的市场法应该考虑能够使其具有成本效益且操作简单的支持策略，以确保您的产品即使超过预期生命周期也能保持可行性和功能性。

文档和软件供应链应清晰完整

CRA 将要求您记录和披露有关产品或服务的大量信息。鉴于其长长的要求列表——包括从制造商信息、产品用例和功能，到设备的完整软件物料清单（SBOM）和安全属性等的一切要求——这会是一项高强度的工作。除了改进内部文档，您还应该完善上游供应商的选择标准，以充分利用具有文档完备且可用的依赖项、组件和其他重要信息列表的软件堆栈。获得所有这些信息的最简单的方法可能是，通过保持长期全面文档记录的商业供应商或大型开源组织来使用软件。

考虑使用为 CRA 做好准备的提供商

独自满足 CRA 的要求是一个难度十足的挑战。如果您对自己的软件供应链及其能否达到 CRA 的监管标准、文档要求、漏洞披露要求和透明度期望没有把握，则应对您的服务和软件提供商进行评估，选择那些能够帮助您轻松达到 CRA 义务要求的提供商。

对于某些配置和设备设计，更简单的方法是使用围绕 CRA 遵从性设计的开源工具堆栈。Canonical 开发和维护的许多工具和产品——从 Ubuntu 到 Kubernetes，再到 MicroCloud、OpenStack 等等——在设计阶段就考虑到安全性，享受安全维护和漏洞修补支持，并且符合 CRA 中的监管要求。除此之外，诸如 Ubuntu Pro for Devices 等服务可以确保您的设备获得长达 12 年的安全维护。

总的来说，CRA 将对您的物联网设备产生很大的影响。从文档要求和更新计划到长期的设备生命周期管理，您始终需要考虑物联网设备设计和安全性的许多因素。如果想要让您的产品在欧盟市场上保持可行性，您不仅要重新审视您的物联网设备运行的操作系统和技术堆栈，还应该重新审视您所依赖的并使产品做好上市准备的网络安全方案和流程。