打造安全的 Open RAN

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

引言

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

• 硬件和软件解耦

• 云基础设施

• 网络功能之间的标准化开放接口

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

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 所示。

图 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 所示。

图 2

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

图 3

由于 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]已经为其正在进行的工作确定了几个指导原则，包括:

1. 支持使用行业标准协议与外部身份、凭证和访问管理系统(ICAM, identity, credential and access management)集成

2. 要求对所有访问进行认证和授权

3. 支持基于角色的访问控制(RBAC, role-based access control)。

4. 对 O-RAN 和外部组件之间的连接进行加密

5. 对 O-RAN 和外部组件之间的连接实施完整性检查

6. 支持静态数据加密

7. 防止重放攻击

8. 实现安全日志生成并收集集成到外部安全信息和事件管理(SIEM，security information and event management)。

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

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

1. 网络功能之间的安全通信

2. RIC 的安全框架

3. 安全的网络功能托管平台

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

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

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

2. 确保通信端点采用基于信任的身份验证

3. 用于身份验证的可信证书颁发机构

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

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

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

图 4

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

请注意，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 的示例流程。

图 5

• 步骤 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%1。有了基于云的集中式基带处理，考虑到不同基站基于时间的工作量变化，更容易汇集资源，并实施基于实际使用情况的节电机制，从而动态调整能耗。欧洲的一项 NGMN 研究表明，80%的无线网络只承载了 20%的流量 2，而跨基站的资源池有可能降低 DU/CU 的容量要求，并大大节省计算和能源需求。通过可扩展性和基于需求的使用，处理无线电软件的处理器(CPU 或 GPU)也可以在非高峰时期运行其他应用程序。而这是在基于专用的、不可重复使用的硬件的专有基带系统中不可能实现的。

1. https://www.datacenters.com/news/data-center-power-optimization-increase-efficiency-with-a-data-center-audit

2. https://www.ngmn.org/wp-content/uploads/NGMN_RANEV_D2_Further_Study_on_Critical_CRAN_Technologes_v1.0.pdf

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 中的程序和功能。

图 6

非实时 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 显示了典型的云原生平台，有三个不同的层次:

1. 基于容器的应用软件

2. 云原生软件栈包括不可变操作系统、Kubernetes 和容器运行时

3. 云原生硬件基础设施

图 7

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

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

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

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

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

1. 基于"设计安全(secure by design)"原则的安全软件开发

2. 基于 DevSecOps 的安全测试自动化

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

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

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

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

图 8

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

基于 DevSecOps 的安全测试自动化

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

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

图 9

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 云原生软件基础设施的安全性

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

1. 轻量级、专门构建的容器专用操作系统

2. 在节点上执行容器和管理容器镜像的容器运行时

3. 使容器的部署、管理、扩容和联网自动化的容器编排系统

容器专用操作系统

根据 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 内置控制包括:

1. 基于角色的访问控制(RBAC, Role based access control)在集群中基于 RBAC 提供了一个框架，为访问 Kubernetes API 的开发运维人员和应用程序实施最小权限原则。

2. 配置 pod 的安全上下文，限制其能力。

3. Pod 安全策略允许为工作负载在集群中运行的方式设定默认值，从而消除依赖于特权访问的相关攻击。

4. 使用 Kubernetes 网络策略控制 pod 和集群之间的流量。

5. Kubernetes 的网络策略允许控制进入和离开容器应用的网络访问。除此以外，还可以部署软件防火墙，以控制不同集群内或跨集群的容器间通信。

6. 使用命名空间来隔离敏感工作负载并创建安全边界，即将工作负载隔离到命名空间中，从而有助于遏制攻击并限制授权用户的错误或破坏性行为的影响。

7. 评估容器权限，坚持最小权限原则，为容器能够执行其预定的功能提供最小的权限和能力。

8. 在所有集群间和集群内的通信中使用双向 TLS。

9. 加密 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 网络中，建议使用基于硬件信任根和软件签名的安全启动来建立端到端的信任链。

图 10

6.2 O-RU 的安全平台

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

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

1. 供应链安全

2. 物理安全

3. 网络安全

供应链安全确保在整个制造的供应链过程中，从 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 相比所体现的一些关键区别。

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