关于程序员:打造安全的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 多平台公布