打造安全的Open RAN

O-RAN架构在为RAN网络引入更多灵活性和最佳实践的同时，也面临着更多的安全风险。本文分别从网元接口通信、RIC安全框架、云原生安全平台等角度全面介绍O-RAN架构在安全方面应该采取的措施。原文: Security in Open RAN

引言

Open RAN是O-RAN联盟在3GPP及其他标准的基础上标准化的开放式无线接入网络(RAN)架构，O-RAN联盟对于RAN功能的划分基于三个关键原则:

硬件和软件解耦
云基础设施
网络功能之间的标准化开放接口

在IT领域，很久以前就实现了软硬件的解耦，从而使得在特定领域出现了专业级软件供应商。这些公司的软件可以在任何硬件上运行，为运营商客户提供了多种选择。此外，还出现了同样丰富的硬件厂商生态系统。

[TOC]

1. 概述

虚拟化技术通过有效利用计算资源、消除硬件孤岛和提高自动化程度，帮助企业降低TCO(总拥有成本)。为了提供5G服务，运营商需要虚拟化网络，能够基于用户选择、策略驱动的服务来扩展服务。云原生架构允许将网络功能(NF)作为容器化微服务集群进行部署，每个微服务都可以独立部署、扩容和升级，从而不需要扩容整个应用程序，而只需要扩容NF中所需的组件。

各种网络功能之间的开放接口允许在网络中使用最好的设备，使运营商能够根据需要定制网络功能，从而在竞争中脱颖而出。

本文展示了通过采用零信任安全框架(zero-trust security framework)，Open RAN架构提供了一条通向比现在更安全的开放式网络和开放式接口的道路。尽管存在误解，但O-RAN技术规范中定义的开放接口提供了更多的独立可见性，并提供了全面增强更安全系统的机会。

5G和Open RAN实现了新的能力和控制点，使供应商、测试设备制造商、无线运营商和网络运营商能够有效评估、缓解和管理安全风险。本文详细介绍了O-RAN如何使运营商对其网络的端到端安全有充分的了解和控制。

庞大的云产业正在致力于解决安全问题，云RAN与其他云网络功能类似，有类似的安全要求和解决方案。云架构确保了弹性、可扩展性和解耦，并引入了AI/ML以及多接入边缘计算(MEC)等功能。例如，利用MEC可以在工厂收集和处理传感器流量，将DDoS检测及缓解转移到网络边缘，边缘事件可以与网络的其他部分隔离。微分段、容器化、虚拟化和网络切片从硬件上提供了增强的安全性和隔离性。安全措施是内建在系统中的，而不是像传统系统那样在事后加装。

2. 下一代RAN架构

3GPP[1]为5G NR gNB定义了如下架构，如图1所示。

gNB被分割成两个逻辑功能，称为CU(集中式单元)和DU(分布式单元)，如图1所示，两个实体通过3GPP TS 38.473[2]中定义的F1-C和F1-U接口连接。值得注意的是，3GPP架构并没有指定远程无线单元(RRU)的接口，PHY层和RF层之间的接口留给供应商实现。

O-RAN联盟是由定义Open RAN规范的领先供应商和运营商组成的团体，进一步分解了3GPP定义的CU和DU的网络功能[3]，这些功能通过开放、标准化的安全接口互联，如图2所示。

图3显示了3GPP和O-RAN的功能及接口划分，O-RAN联盟在3GPP的5G RAN架构之外增加了新的接口和功能。

由于O-RAN联盟建立在3GPP的5G NR架构之上，受益于3GPP为5G引入的高级安全功能[4]，包括:

增强的用户身份隐私性，即订阅隐藏标识符(SUCI, Subscription Concealed Identifier)
空口对终端和gNB之间的控制/用户面流量的全面保护(加密和完整性保护)
gNB接口的全面保护，包括CU-CP与CU-UP之间的E1接口，CU与DU之间的F1接口
增强的归属网络控制(身份验证)
基于SLA的网络切片的额外安全性

3. 基于零信任的Open RAN安全体系架构

基于"永不相信，总是验证(never trust, always verify)"原则，零信任(Zero Trust)旨在通过通过网络隔离、防止横向移动、提供L7威胁预防以及简化细化的用户访问控制来保护现代数字环境。

零信任架构(ZTA, zero trust architecture)是基于零信任原则的网络安全架构，旨在防止数据泄露以及限制内部横向移动，以下内容来自NIST出版的800-207-"零信任架构"[5]。

网络安全的"零信任"(ZT)方法主要侧重于数据和服务保护，但可以也应该扩大到包括所有企业资产(设备、基础设施组件、应用程序、虚拟和云组件)和主体(终端用户、应用程序以及其他从资源中请求信息的非人类实体)。

在这种新范式下，企业必须假定没有隐性信任，并不断分析和评估其资产和业务功能的风险，然后制定保护措施，以减轻风险。在零信任中，这些保护措施通常包括尽量减少对资源(如数据和计算资源以及应用程序/服务)的访问，只允许那些被确认为需要访问的主体和资产，以及不断验证及授权每个访问请求的身份和安全状况。

对零信任架构的支持要求每个O-RAN组件遵守既定功能和保护措施。O-RAN联盟[6]已经为其正在进行的工作确定了几个指导原则，包括:

支持使用行业标准协议与外部身份、凭证和访问管理系统(ICAM, identity, credential and access management)集成
要求对所有访问进行认证和授权
支持基于角色的访问控制(RBAC, role-based access control)。
对O-RAN和外部组件之间的连接进行加密
对O-RAN和外部组件之间的连接实施完整性检查
支持静态数据加密
防止重放攻击
实现安全日志生成并收集集成到外部安全信息和事件管理(SIEM，security information and event management)。

以下各节的分析基于云原生Open RAN网络的假设，其网络功能被建模为容器化的微服务。

Open RAN安全建立在以下原则之上:

网络功能之间的安全通信

RIC的安全框架

安全的网络功能托管平台

4. 网络功能间的安全通信

本节探讨Open RAN中网络功能之间提供安全通信有关的内容。

在所有接口上进行安全通信
确保通信端点采用基于信任的身份验证
用于身份验证的可信证书颁发机构

4.1 在所有接口上进行安全通信

O-RAN联盟规定了开放和安全的架构，包括所有组件之间的安全接口，在这些接口上交换的通信基于密码学提供了加密、完整性保护和重放保护。

5G RAN网络安全架构如图4所示。

下表总结了ORAN网络中每个接口的保护机制。

接口	网络节点	安全机制	协议
E1	O-CU-CP和O-CU-UP	NDS/IP (IPSec)或DTLS	3GPP
Xn	源gNB和目标gNB	NDS/IP (IPSec)或DTLS	3GPP
后传(Backhaul)	O-CU-CP和5GC(N2)/O-CU-UP和5GC(N3)	NDS/IP (IPSec)或DTLS	3GPP
中传(F1, Midhaul)	O-CU-CP和O-DU(F1-C)/O-CU-UP和O-DU(F1-U)	NDS/IP (IPSec)或DTLS	3GPP
开放前传(Open Fronthaul, M-Plane)	O-RU和O-DU/SMO	SSHv2, TLS	O-RAN WG4
开放前传(Open Fronthaul, CUS-Plane)	O-DU和O-RU	进行中(20年12月)	O-RAN WG1 STG
O1	SMO和O-RAN管理的组件	进行中(20年12月)	O-RAN WG1 STG
E2	近实时RIC(xApp)和O-CU-CP	计划中(21年1季度)	O-RAN WG1 STG
A1	近实时RIC和非实时RIC	计划中(21年1季度)	O-RAN WG1 STG
O2	SMO和O-Cloud	计划中(21年2季度)	O-RAN WG1 STG

请注意，O-RAN联盟的一些规范仍在进行中，因此安全工作也在同步进行。为了保护开放前传LLS接口上的CUS-Plane消息[7]，O-RAN联盟目前正在确定所有威胁和漏洞，以及对CUS-Plane的影响。O-RAN联盟计划在2021年3月前完成分析并指定安全程序以保护CUS-Plane消息。

4.2 建立双向认证的信任

双向认证用于在两个实体之间相互认证，并建立安全的加密连接。双向认证可以防止在网络中引入流氓NF或xAPPs。

运营商X.509证书用于在基于IPsec和TLS协议建立安全连接时进行双向认证。

Open RAN中所有网元，即O-CU-CP、O-CU-UP、O-DU和O-RU，都支持基于X.509证书的认证和相关功能，如基于安全传输的接入(EST, Enrollment over Secure Transport)或3GPP指定的CMPv2等协议与运营商的证书授权(CA)服务器进行自动注册和再注册。

近实时RIC中的xAPPs像其他微服务一样需要安全工作，O-RAN联盟有望在通过E2接口进行通信之前使用CA签名的X.509证书进行认证。

图5介绍了在与CA服务器进行证书注册时，如何使用基于证书的认证来认证O-CU、O-DU和O-RU的示例流程。

步骤1-2: 当O-RU启动时，分配给该O-RU服务的O-CU-CP、O-CU-UP和O-DU实例将由编排器实例化(如果尚未实例化)。
步骤3: O-CU-CP、O-CU-UP和O-DU基于3GPP规范与CA服务器执行EST或基于CMPv2的证书注册程序，以获得运营商证书。在建立IPSec或TLS连接时，运营商证书被用于后续认证。
步骤4: 在O-CU上执行必要的OAM操作(如果有的话)，包括更改默认密码。
步骤5-9: 作为O-RU上电操作的一部分执行，与安全有关的主要步骤解释如下:
- O-RU基于O-RAN M-Plane规范第3.1.1和3.1.4节[8]中规定的DHCP选项，从DHCP服务器获得其IP地址、EMS或OSS地址。
- O-RU向CA服务器进行证书注册，获取运营商证书。
- O-RU应通过NETCONF call home机制通知EMS或OSS。O-RU的运营商证书被用来与EMS进行认证。OSS/EMS应使用二级NETCONF控制器的地址(即O-DU的地址)配置O-RU。
- O-RU应以NETCONF call home机制通知O-DU，以安全的获得O-RU的配置。O-RU的运营商证书被用来与O-DU进行认证。

4.3 可信证书认证

建议根据AICPA/CICA WebTrust Program for Certification Authorities对证书颁发机构(CA)进行审计。从而提高对Open RAN中用于认证网络组件的CA服务器的信心和信任。

5. RIC安全框架

5.1 近实时RIC(Near-RT RIC)的安全问题

近实时RIC是包含第三方可扩展微服务(称为xApps)的SDN组件，为传统上在gNB内管理的网络功能执行选定的无线电资源管理(RRM, radio resource management)服务。近实时RIC通过O-RAN标准化的开放E2接口与O-CUCP、O-CU-UP和O-DU对接，还通过A1和O1接口与非实时RIC以及服务管理和编排框架对接。

近实时RIC的主要安全考虑包括:

近实时RIC与O-CU-CP/O-CU-UP/O-DU之间的安全E2接口
冲突解决和xApp身份验证
近实时RIC中的用户标识

5.1.1 近实时RIC与O-CU-CP/O-CU-UP/O-DU之间的安全接口

接口安全在4.2节中介绍。

5.1.2 冲突解决和xApp身份验证

xApp之间的冲突解决不一定是安全问题，但如果处理不当就会导致漏洞。

当近实时RIC中的xApp与E2节点启动RIC订阅流程时，近实时RIC平台中的订阅管理器执行订阅策略并跟踪由xApp和RAN功能启动的订阅，以及与这些订阅相关的事件触发。订阅管理器可以通过以下一种或多种方式解决xApp之间的信令冲突:

订阅管理器不允许一个以上的xApp基于同一事件触发器订阅同一NF。
如果有一个以上的xApp订阅了同一个NF，并从E2节点获得了相同的指示信息，那么只要不优化相同的或密切相关的参数，订阅管理器可以允许他们同时控制E2节点的NF。
如果有一个以上的xApp订阅了同一个NF，并从E2节点获得了相同的指示信息，并且如果他们优化了密切相关的参数，那么订阅管理器可以允许他们同时控制和优化这些参数，并通过锁和回退定时器来保持排他性。

RAN基于软件的省电机制。
随着解耦的RAN计算资源转移到数据中心，可以利用全球数据中心的电源优化趋势实现更高的电源效率。自2010年以来，数据中心功耗增加了6%，但与此同时，数据中心计算量却增加了550%¹。有了基于云的集中式基带处理，考虑到不同基站基于时间的工作量变化，更容易汇集资源，并实施基于实际使用情况的节电机制，从而动态调整能耗。欧洲的一项NGMN研究表明，80%的无线网络只承载了20%的流量²，而跨基站的资源池有可能降低DU/CU的容量要求，并大大节省计算和能源需求。通过可扩展性和基于需求的使用，处理无线电软件的处理器(CPU或GPU)也可以在非高峰时期运行其他应用程序。而这是在基于专用的、不可重复使用的硬件的专有基带系统中不可能实现的。

https://www.datacenters.com/news/data-center-power-optimizati...\

https://www.ngmn.org/wp-content/uploads/NGMN_RANEV_D2_Further...

5.1.3 近实时RIC中的用户标识

在RIC内维护用户的隐私非常重要。ORAN WG3正在研究近实时RIC内的UE识别问题，可以通过3GPP定义的Trace ID、RAN UE ID、RAN网络接口特定的临时UE ID的组合，以及通过将这些IE相互关联来解决。通常情况下，最理想的是近实时RIC在近实时颗粒度(从10ms到1s)内保持UE识别的持久性，而UE的永久ID不暴露给xApp。当RIC中的临时ID在RAN节点中被释放时，其失效状态将通过正常的E2通信来处理。在任何情况下这都不是一个UE隐私问题或DoS攻击威胁问题。

5.2 非实时RIC(Non-RT RIC)的安全问题

非实时RIC是O-RAN系统中的一个组件，通过声明性策略和目标意图对RAN进行非实时控制，在下面的图6中介绍。

非实时RIC部署在服务管理和编排框架(SMO, service management and orchestration)中，通过在O1接口上提供小区参数的最佳配置，为小区级优化提供声明性策略指导。
非实时RIC也通过A1接口向近实时RIC发送用于UE级优化的声明性策略。
然后，近实时RIC将非实时RIC通过A1接口推荐的声明性策略转化为E2接口的UE控制命令式策略。
非实时RIC为策略指导和非实时优化开发ML/AI驱动的模型，作为rApp微服务部署。这些rApp通过A1接口与xApp交互，以优化底层RAN中的程序和功能。

非实时RIC的主要安全考虑包括:

非实时RIC与O-CU-CP/O-CU-UP/O-DU之间的安全接口
非实时RIC与O-CU-CP/O-CU-UP/O-DU之间的冲突解决

5.2.1 非实时RIC与O-CU-CP/O-CU-UP/O-DU之间的安全接口

接口安全在4.2节中介绍。

5.2.2 非实时RIC与O-CU-CP/O-CU-UP/O-DU之间的冲突解决

通常当RAN所用策略和目标意图与非实时RIC不同时，对于底层RAN节点(如O-CU)的管理就会在RRM中出现冲突，而这是rApp与底层RAN节点的运作造成信令冲突的根源。然而，使用RIC的订阅策略，可以强制实现排他性，使RAN的订阅流程由近实时RIC管理，从而避免造成信令冲突。

6. 网络组件的安全平台

与当今互联网和公共云一样，O-RAN联盟的RAN架构完全建立在云原生架构上。O-RAN网络中的云原生网络功能，即O-CU-CP、O-CU-UP、O-DU、近实时RIC和非实时RIC，都托管在云原生平台上，与云计算行业使用的云原生平台非常相似。O-RU是PNF，托管在一个非虚拟化平台上。

接下来，我们将全面讨论这些平台的安全考虑。

6.1 云原生网络功能的安全平台

O-RAN架构使用云原生平台承载O-CU-CP、O-CU-UP、O-DU、近实时RIC和非实时RIC网络功能。图7显示了典型的云原生平台，有三个不同的层次:

基于容器的应用软件
云原生软件栈包括不可变操作系统、Kubernetes和容器运行时
云原生硬件基础设施

以下章节将分别介绍构成云原生平台的三个层次的安全特征。

6.1.1 基于容器的应用软件安全性

工作负载是部署在云上的应用程序或服务，容器提供了对基础设施的封装，其中应用程序和依赖库从实际运行环境中被抽象了出来。

容器通常被认为比虚拟机的安全性要低，但值得注意的是，在IT行业中，容器已经被用于构建类似于银行业务等应用程序，这些应用在安全要求方面的重要性不亚于电信应用，而且在自动化安全和建立最佳实践方面已经有了长足发展。

在Open RAN中使用了以下行业标准做法，以确保基于容器的应用软件的安全:

基于"设计安全(secure by design)"原则的安全软件开发
基于DevSecOps的安全测试自动化
开源和第三方库中的漏洞管理

基于"设计安全"原则的安全软件开发

软件开发生命周期(SDLC)是一个框架，用于对应用程序从立项到下线的全过程进行建模。过去，企业通常只在SDLC结束时作为测试的一部分进行安全相关活动。由于介入较晚，很难发现错误、缺陷和其他漏洞，造成修复成本和时间都大大增加。更糟糕的是，可能根本就无法发现任何安全漏洞。

安全的SDLC涉及将安全测试和其他与安全相关的活动整合到现有开发流程中。图8显示了标准SDLC流程是如何在软件开发的各个阶段增强安全实践的。

对部署在O-RAN网络中的工作负载(如近实时RIC中的xAPP、O-CU-CP和O-CU-UP以及O-DU微服务)使用安全的SDLC流程，可以确保尽早发现系统缺陷，让参与设计、开发、测试和部署的所有利益相关者认识到安全考虑，并全面降低企业的内在业务风险。

基于DevSecOps的安全测试自动化

自现代计算开始，安全测试在很大程度上是一种独立于软件开发的活动，专注安全的专业QA人士在测试阶段进行测试。

容器开发生命周期的DevSecOps方法确保将安全内建到CI/CD流水线的每个阶段中。

DevSecOps背后的理念来自SDLC提出的尽早开始安全测试。DevSecOps将各种安全控制整合到DevOps的工作流程中，如使用静态应用安全测试(SAST, static application security testing)的安全编码分析，自动化单元、功能和集成测试。这使得开发人员能够近乎实时的修复代码中的安全问题，而不需要等到SDLC的最后阶段。

O-RAN联盟软件架构利用了"安全自动化"的进步和云计算的"左移"趋势，确保在O-RAN网络中运行的工作负载得到安全验证(在构建/部署阶段)，并在运营商网络部署之前发现漏洞并及时采取基于风险的行动。

开源和第三方库中的漏洞管理

开源库和开源软件使开发人员能够满足当今加速发展的时间要求。然而，由于软件中存在未解决的漏洞，也可能使平台受到攻击。

软件组件分析(SCA, Software component analysis)是一种开源管理工具，有助于识别使用第三方和开源软件的潜在风险领域。SCA软件自动扫描所有开源组件，创建材料清单(BOM)，检查政策和许可证的合规性、安全风险和版本更新。SCA通常是在扫描后生成的报告中还提供补救已发现漏洞的见解。

专门的容器镜像扫描工具通过识别和提供镜像中所有漏洞的修复路径，为容器提供自动化漏洞管理。这些工具被集成到CI/CD流水线中，并提供对容器镜像的持续评估。

在O-RAN网络中使用软件组件分析工具可以部署先进的漏洞管理流程，包括自动跟踪、分析应用程序的开源组件、识别组件漏洞和基于工具的漏洞修复。

遵守NIST SCRM和CISA ICT SCRM的供应链风险管理要求。

6.1.2 云原生软件基础设施的安全性

云原生软件基础设施包括以下内容:

轻量级、专门构建的容器专用操作系统
在节点上执行容器和管理容器镜像的容器运行时
使容器的部署、管理、扩容和联网自动化的容器编排系统

容器专用操作系统

根据NIST SP 800-190的建议[9]，云原生软件基础设施依赖于为运行容器化应用程序而不是为减少操作系统攻击面而构建和配置的主机操作系统。此外，容器专用操作系统遵循不可变基础设施范式，防止安装任何额外的独立软件包，以阻止病毒和恶意软件的入侵，整个操作系统被作为单一实体进行管理，任何额外功能都必须作为容器来安装。操作系统实现了强大的隔离和强制访问控制(MAC, mandatory access control)机制，如SELinux，以限制容器可以做的事情，从而保护操作系统不受容器的影响，容器之间也不相互影响。该操作系统还支持内置的Linux功能，如控制组(cgroups)和命名空间，为在容器内运行的应用程序提供隔离环境。该操作系统还支持磁盘加密，包括通过利用Linux统一密钥设置(LUKS, linux unified key setup)加密的根分区。

容器运行时

云原生软件基础设施包括轻量级、符合OCI标准、与Kubernetes一致的容器运行时(如CRI-O)，以减少漏洞风险。

云原生软件基础设施(容器专用操作系统、容器运行时、磁盘......)必须支持通过使用FIPS 140-2验证的加密技术在FIPS模式下运行。

Kubernetes的原生安全性

Kubernetes提供内置的安全功能来保护容器环境，包括网络安全、资源隔离、访问控制、日志和审计。一些常见的有助于加强安全的Kubernetes内置控制包括:

基于角色的访问控制(RBAC, Role based access control)在集群中基于RBAC提供了一个框架，为访问Kubernetes API的开发运维人员和应用程序实施最小权限原则。
配置pod的安全上下文，限制其能力。
Pod安全策略允许为工作负载在集群中运行的方式设定默认值，从而消除依赖于特权访问的相关攻击。
使用Kubernetes网络策略控制pod和集群之间的流量。
Kubernetes的网络策略允许控制进入和离开容器应用的网络访问。除此以外，还可以部署软件防火墙，以控制不同集群内或跨集群的容器间通信。
使用命名空间来隔离敏感工作负载并创建安全边界，即将工作负载隔离到命名空间中，从而有助于遏制攻击并限制授权用户的错误或破坏性行为的影响。
评估容器权限，坚持最小权限原则，为容器能够执行其预定的功能提供最小的权限和能力。
在所有集群间和集群内的通信中使用双向TLS。
加密etcd数据存储，以保护基础设施和应用程序的密钥，或支持与外部vault的整合。

利用Kubernetes operator提高安全性

Kubernetes operator是Kubernetes的软件扩展，利用自定义资源，以自动化方式管理服务及其组件。这些operator可以被云原生软件平台利用，以达到特定的安全目的。

通过硬件管理operator限制对特权应用的需求
通过合规operator持续监测集群的合规性
通过文件完整性监控operator检测影响平台完整性的任何攻击
通过平台管理operator消除人为错误、对抗配置漂移并执行安全配置
通过审计和日志operator管理审计配置和日志并转发到SIEM

基于云原生O-RAN网络可以利用容器运行时和容器编排平台(如Kubernetes)的原生安全控制，为其承载的容器化工作负载提供深度安全防御。

基于行业基准的云基础设施安全配置

云基础设施的配置基于行业最佳实践，如操作系统、Docker和Kubernetes的CIS基准，以及由3GPP和GSMA联合定义的网络设备安全保障规范(NESAS, Network Equipment Security Assurance Scheme)，为多供应商和运营商提供了一致的框架和共同的外部审计计划，从而确保适当的安全控制在平台中得到落实，并减少平台的攻击面。

一些常见的安全控制措施包括禁用未使用的端口和未使用的服务，工作负载的最小权限原则(PLoP)，保护存储中的数据，使用RBAC进行用户访问控制等。

O-RAN网络中的所有虚拟化平台都按照3GPP的安全保证规范[10]和其他知名的行业基准，如CIS[11]的标准进行加固，确保安全控制在平台的每一层都得到实施，从而减少平台的攻击面。

利用云安全态势管理(cloud security posture management)检测和补救配置错误

配置错误是导致云端数据泄露的首要原因。我们需要一种机制确保所部署的云资源的配置在第一天是正确和安全的，并在第二天及以后保持这种状态。这被称为云安全态势管理(CSPM, cloud security posture management)。

云计算行业已经使用CSPM安全工具来持续监测云环境，以检测可能导致违反合规性和数据泄露的错误配置漏洞。

随着基于O-RAN的网络采用云原生架构，运营商现在有办法部署先进的CSPM工具，以防止网络配置的自然"漂移"并减少潜在攻击。

商业云原生混合平台

在商业云原生混合平台上实现标准化，可使运营商获得以下安全优势:

经过Kubernetes认证的平台，可灵活的在内部或虚拟私有云中安全运行，支持来自SMO、RIC、CU和DU的O-RAN拓扑结构变化，具有零接触配置功能。
通过动态更新延长软件生命周期，解决新的CVE问题，并随着时间推移对断开连接的环境进行优化。
支持多租户，因此多厂商软件可以安全托管在同一个集群中。
支持基础架构遵从性扫描(OpenSCAP)和补救。
带有漏洞扫描的容器注册表，以消除O-RAN平台(如近实时RIC)上的漏洞以及相关的xApp和rApp的漏洞。

6.1.3 云原生硬件基础设施的安全考虑

O-RAN实现了硬件和软件的解耦，允许基于不同的供应商构建平台。

6.1.3.1 凭证和静态数据的安全存储

建议O-RAN硬件配备基于硬件的安全模块，如TPM，以管理、生成和安全存储加密密钥。基于硬件的安全模块也是为了提供硬件信任根，通过提供安全的密钥存储飞地，在签名和签名验证阶段实现最小加密功能，从而实现安全计算。

静态数据必须使用基于硬件的安全模块产生的密钥进行加密。

6.1.3.2 建立软件信任链

如果没有网络信任链中所有组件的充分参与，零信任是无法实现的。

图10说明了在数字系统中坚持零信任时建立信任链的关键方面。

可信硬件

该硬件由防篡改的"硬件信任根(hardware root of trust)"设备构建，为存储加密密钥和证书以及所有在该硬件上运行的软件提供了一个安全环境。该设备将暴露简单的用户界面，供应用程序在需要使用该设备来存储密钥、检索证书时使用。

可信软件

在部署时，所有软件层，包括固件、云原生软件栈和容器工作负载，都会强制进行软件签名，并进行认证的版本升级，以使恶意软件更难侵入运营商控制的组件。

通过安全启动建立端到端信任链

安全启动要求每次启动都要从一个不能在现场更新的软件开始，这个软件被称为可信度量根核心(CRTM, Core Root of Trust for Measurement)。

此后，在启动过程中，平台中的每一个软件在被下层的软件执行之前都会执行完整性验证。这就建立了一个端到端的软件信任链，软件完整性验证的信任锚是软件签名证书。

在O-RAN网络中，建议使用基于硬件信任根和软件签名的安全启动来建立端到端的信任链。

6.2 O-RU的安全平台

攻击者在未经授权的情况下进入未受保护的O-RU管理界面，可以让攻击者窃取未受保护的私钥、证书、哈希值和/或注入恶意软件和/或操纵现有O-RU软件。攻击者可以进一步对包括O-DU在内的其他网络组件发起拒绝服务、入侵和重放攻击。

因此，O-RU平台的加固将确保足够的设备安全，以大幅减少未受保护的O-RU中存在的攻击面。O-RU上的安全预防措施可分为三个方面:

供应链安全
物理安全
网络安全

供应链安全确保在整个制造的供应链过程中，从O-RU到其最终的安装地点和调试，都遵循受控的安全监管链过程，确保对O-RU进行适当的跟踪和标记。

物理安全确保物理O-RU用不可篡改的螺钉密封，不能轻易被破坏或打开，在篡改或强行打开的情况下，所有O-RU的功能将被禁用，从而使O-RU变得无法操作。此外，所有物理和逻辑端口都是安全和隔离的，因此不能被用作进入扩展RAN网络的漏洞入口。

从网络安全角度来看，O-RU确保所有认证和通信安全协议得到正确执行和遵守。为了确保可靠和安全的软件升级，实施TPM程序，以防止下载流氓软件。最后，加固功能，如在不使用时禁用不必要的软件组件和接口，以正确的权限级别运行软件，对存储的数据进行扰乱/加密，以及安全启动和基于硬件的安全模块，都是典型的O-RU全面安全程序的一部分，以抵御以及防止对O-RU的未授权访问。

7. Open RAN的关键安全差异

下表强调了Open RAN与封闭式RAN或传统gNB相比所体现的一些关键区别。

区别点	Open RAN	封闭式RAN
开放前传的安全	提供了为保护该接口所采取的安全措施的可见性。开放的、标准化的接口消除了专有的和可能不受信任的实施所带来的漏洞或风险。	为保护封闭式RAN中的CPRI接口而采取的保护措施不详。
运营商在建立安全平台方面拥有完全的控制权	Open RAN的解耦架构允许网络运营商通过选择符合所有必要行业安全标准和认证的供应商来建立云原生平台。	运营商无法控制虚拟化平台是如何构建的，完全由供应商驱动。
在云基础设施中更好的执行安全控制	云基础设施供应商将直接根据与运营商的协议，负责云基础设施的安全。	运营商对云基础设施供应商没有直接的可见性。
解耦平台提供了更好的可见性和自动化网络检测	云原生架构使运营商能够部署最新的安全工具，以监测漏洞并根据需要自动采取补救措施。	运营商对这些信息没有可见性，完全依赖供应商来检测和补救网络中的漏洞。
在开发容器化应用程序时采用行业最佳实践	允许采用行业最佳实践，如"安全设计"、DevSecOps，在开发容器化应用程序时进行自动化测试。运营商还可以选择与供应商合作，确定并影响供应商使用的CI/CD流程。	完全由供应商驱动，运营商没有机制来验证供应商使用的软件开发过程。
加密密钥的保护	NG-RAN的加密密钥(KgNB)存储在CU中，位于网络内部的一个集中式数据中心。	储存在基站，有可能被盗(特别是当gNB没有实施HSM时)。

8. 结论

Open RAN的核心基于云原生架构，该架构也是当今互联网和公共云的基石。虚拟化部署有成熟的安全实践，并在整个云计算行业中采用。电信网络中的虚拟化部署并不新鲜，运营商已经在数据中心拥有了虚拟化基础设施，许多运营商已经为网络中的其他组件部署了虚拟工作负载，包括: 分组核心网、IMS以及如CDN等其他应用。通过解耦架构，运营商现在将额外受益于当今大型云基础设施供应商在管理大型IT云环境方面的专业安全知识和经验。

现在运营商明白了建立和维护安全的基础设施需要什么，因此重新获得了控制权。Open RAN建立在云原生平台上，在硬件/基础设施供应商、混合云平台供应商和RAN软件供应商之间建立了明确的职责和责任，使网络运营商能够选择符合所有必要的行业安全标准和认证的供应商。

Open RAN采用了云计算行业中的安全最佳实践。软件开发过程中的"左移"策略将安全控制和实践整合到软件开发的各个阶段。随着DevSecOps集成到CI/CD流水线中，也将自动化带入安全代码审查和安全测试中。使用自动化工具来检测、修复开源软件中的漏洞，并检测和管理安全态势，帮助运营商提供快速检测和解决网络中的异常情况。

O-RAN联盟的RAN架构建立在零信任的安全基础上，网元之间相互认证以进行通信，所有通信都通过O-RAN联盟的安全规范所规定的基于行业最佳实践的安全接口进行传输。虽然标准仍在不断发展，但开放无线网络的先驱和生态系统供应商，如Altiostar、Mavenir、Fujitsu和Red Hat，以及早期采用者，如Rakuten、Vodafone、Telefonica、NTT Docomo和DISH，都确保了所有接口都使用基于证书的安全。

Open RAN网络中的每个网络组件都按照3GPP的安全保证规范和其他著名的云计算行业基准(如CIS)进行了平台加固，从而保护网络不被攻击者获得未经授权的访问，避免网络受到拒绝服务(DOS)攻击或获得非法访问。

总之，开放、标准化的接口消除了专有的以及可能不受信任的实施所带来的漏洞或风险，并为运营商提供了对云环境和一般网络的全面可视性和控制。

参考文献

[1] 3GPP TS 38.401: NG-RAN; Architecture description\
[2] 3GPP TS 38.473: NG-RAN; F1 Application Protocol (F1AP)\
[3] O-RAN Architecture Description (O-RAN.WG1.O-RAN-Architecture-Description)\
[4] 3GPP TS 33.501: Security architecture and procedures for 5G system (Release 16)\
[5] NIST Special Publication 800-207: Zero Trust Architecture\
[6] O-RAN Architecture Description Chapter X – O-RAN Security\
[7] O-RAN Control, User and Synchronization Plane Specification (O-RAN WG4.CUS)\
[8] O-RAN Management Plane Specification (O-RAN.WG4.MP)\
[9] NIST Special Publication 800-190: Application Container Security Guide\
[10] 3GPP TS 33.511: Security Assurance Specification (SCAS) for the next generationNode B (gNodeB) network product class\
[11] CIS benchmarks: https://www.cisecurity.org/cis-benchmarks/

*你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。 \
微信公众号：DeepNoMind*

本文由mdnice多平台发布