打造安全的 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. 
   

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

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

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

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

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