EB如何以符合标准的方式确保Linux安全.docVIP

EB如何以符合标准的方式确保Linux安全 安全关键系统的开发和认证必须遵循明确定义的流程。Linux由社区开发，并无制造商承担法律责任，因此不满足这些要求。但是，诸多标准指明了允许Linux在关键安全环境中使用的方式。 近年来，由软件控制的系统的任务不断增长，其中包括医疗技术和汽车工程。功能系统开发的创新越来越多地产生于软件之中。如今，一辆高端汽车包含100多个电子控制单元，对其进行编程的程序代码超过1亿行。长期以来，功能往往是与ECU本身联系在一起，因此更多的功能意味着会有更多的ECU，这一点也可归因于行业供应链。日益增多的功能特性增加了ECU的数量，例如，在信息娱乐、互联性、驾驶辅助或自动驾驶方面。当各项功能同时进行交互时，就会导致复杂性剧增。 硬件和软件脱钩 降低这种复杂性的一种方法是将功能与ECU分离，从而做到软硬件脱钩。这样，计算能力集中于车载E/E架构中，即整个车辆电气系统中，因此功能完全是作为软件来实现的，来自多个供应商的不同功能必须在一个ECU上共存（图1）。例如，在飞机制造中使用的集成模块化航空电子（IMA）架构中可以观察到类似的系统架构发展。 这一方法与数据中心的操作也有相似之处：起初是通过虚拟化，现在则是通过容器化，不同的功能在同一硬件上运行。可以判断出，由此实现的从IaaS到FaaS的制造服务化业务模式也可应用于汽车行业，从而带来新的合作机遇。 从技术方面而言，整合必须确保应用程序之间不会产生干扰。在数据安全性的讨论中，通常将其称为多租户或租户安全性。 考虑到这一点，制造商和供应商都提出了这样的问题，即什么级别上的差异化是可行的：仅在功能级别，或者也在中间件、虚拟机监控程序和操作系统级别。这一问题尚未有明确答案，但是初步趋势已经显现：通过应用数据中心的部分技术，厂商也将应用这些业务模型并将自身集成到其结构之中。一旦中间件实现标准化，制造商的差异化将基本上发生在功能级别。在汽车领域，对于经典ECU，这一点是通过AUTOSAR（汽车开放系统架构）完成的，目前已扩展到具有自适应AUTOSAR的中央处理单元。 功能集中化 在医疗技术中，ECU的整合并不是最重要的。然而，该领域同样也经历着待集成功能数量的增加。经常可以看到，在统一的软件/硬件平台上进行模块化。同时，特定功能集中在设备中的一台控制计算机上：这一方式尤其适用于数据处理/可视化/记录、操作、组件之间以及与本地网络或互联网的通信。特别需要指出的是，处理和可视化通常是与安全相关的功能，必须确保其完整性。 图 1：车辆架构的演变 例如，如果医疗系统接收到探头的测量值，则整个系统将从患者权利和完整性的角度出发，确保此数据路径的安全关键性。视具体应用而定，需要一种机制来检测或防止跨通信路径以及系统内保存操作过程中的测量数据丢失或损坏。除了标准的数值误差分析之外，在数据准备期间还会出现一个问题：所使用的数学库和算法，其可靠性如何。最终必须确保结果得以呈现并正确传输。从架构到校验的不同级别上，必须以易于理解的方式对此进行规划和记录。 但是，对于医院运营者的法律障碍和合规要求往往造成不允许通过广域网来连接医疗设备。这也导致了整个设备生命周期内对于维护的要求相互矛盾即最新的软件与重新认证的必要性之间的矛盾。 开源软件 – 符合主线要求 开源软件在工业应用中最初由于功能安全和认证方面的原因被广泛排除在外，然而在过去的几年中，开源软件甚至也将这些领域征服。十多年来，医疗应用领域即是一个典型的例子。在汽车领域，Linux除了信息娱乐系统之外，目前也在车载中央计算机上首次亮相。 在这一情况下，所出现的关键问题与整个生命周期中的开发过程和软件维护均密切相关。一套成熟的标准、认证和审核在软件的规划、开发、测试和文档记录方面提供有益的流程说明，例如针对医疗技术的IEC 62304、或针对汽车行业的Automotive SPICE和ISO 26262。至少IEC 62304包含了生命周期管理要求。 但是，两个标准都没有充分考虑两个基本方面： 在开发过程和后期生命周期管理中，开源软件（特别是嵌入式Linux）的特定特征。 出于安全原因，连接到互联网并因此可在全球范围内访问的设备需要积极维护和定期更新。 尽管与台式机/服务器发行版本相比，嵌入式Linux复杂性大大减少，但仍然相当复杂，而且还是一款非常广泛、全面的软件，尽管其初衷是“简单就在于此”；它的开发和维护者并不是需要承担法律责任的制造商，而是乍看似乎不是很透明的匿名社区。这一软件是在标准化开发流程的控制范围之外创建的。现在，必须以符合标准的方式在后续生命周期阶段对其进行集成和维护。 该过程不再是独立地完成整个V模型： 针对Linux内核和其他开源组件，已经以官方文件形式设定了开发目标、质量目标以及由此衍生的狭义要求；但是，它们往往