关于程序员:打造安全的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]曾经为其正在进行的工作确定了几个领导准则，包含:

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

下表总结了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的示例流程。

• 步骤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)也能够在非顶峰期间运行其余应用程序。而这是在基于专用的、不可重复使用的硬件的专有基带零碎中不可能实现的。

1. https://www.datacenters.com/news/data-center-power-optimizati...\
2. 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显示了典型的云原生平台，有三个不同的档次:

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

以下章节将别离介绍形成云原生平台的三个档次的平安特色。

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

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

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

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

1. 基于"设计平安(secure by design)"准则的平安软件开发
2. 基于DevSecOps的平安测试自动化
3. 开源和第三方库中的破绽治理

基于"设计平安"准则的平安软件开发

软件开发生命周期(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 云原生软件基础设施的安全性

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

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网络中，倡议应用基于硬件信赖根和软件签名的平安启动来建设端到端的信赖链。

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*

本文由mdnice多平台公布