網優雇傭軍

近日，愛立信官網發布了一篇名為《Security considerations of Open RAN》的文章，引起業內人士廣泛轉發。

文中指出，隨著行業向vRAN和O-RAN發展，采用基于風險的方法來充分解決安全風險非常重要。對于包括O-RAN的任何新興技術，安全性在設計之初就應該完整構建，而不是事后再補。為了確保O-RAN能滿足運營商安全級別，愛立信基于對O-RAN標準的參與和實踐，指出其存在一些安全風險。

3GPP RAN架構與O-RAN架構的區別

如上圖，3GPP R15引入了CU和DU分離的RAN架構，定義了CU-CP(控制面)和CU-UP(用戶面)之間的E1接口，以及CU與DU之間的F1接口。

但O-RAN進一步開放前傳接口，并在管理層和RAN新引入了Non-Real-Time RIC和Near-Real-Time RIC兩個控制器，同時新增了A1、E2、O1、O2等接口。

從架構上不難看出，為了實現開放化和智能化，Open RAN架構更加復雜，這可能會增加如下安全風險。

開放前傳接口安全風險

在傳統RAN部署方式下，DU和RU來自同一廠家，DU和RU之間的前傳接口由單廠家實現。而O-RAN采用7-2x開放前傳接口，O-DU和O-RU可以來自不同的廠家。

當O-DU和O-RU來自不同廠家時，意味著O-DU不能完全控制O-RU，需要通過更高層的服務管理與編排層來輔助管理，這可能會帶來通過前傳接口向O-DU之上的北向系統發起中間人攻擊的風險。

Near-Real-Time RIC安全風險

為了便于理解，我們先來科普一下O-RAN架構中的Non-Real-Time RIC和Near-Real-Time RIC這兩個控制器，以及SMO(服務管理與編排)。

(O-RAN架構)

SMO，Service Management and Orchestration，類似NFV中的MANO，負責管理網絡功能和NFVI基礎設施，其包含的管理接口和管理內容如下：

? O1接口：負責管理網絡功能(vNF)，包括配置、告警、性能、安全管理等。

? O2接口：負責管理云平臺(o-cloud)的資源和負載管理。

? M-Plane接口：負責對O-RU管理。

RIC，全稱為Radio intelligent controller，無線智能控制器。顧名思義，就是通過引入AI實現RAN運維自動化、智能化。

Non-Real-Time，指非實時部分，負責處理時延要求大于1秒的業務，比如數據分析、AI模型訓練等。

Near-Real-Time，指近實時部分，負責處理時延要求小于1秒(50ms-200ms)的業務，比如無線資源管理、切換決策、雙連接控制、負載均衡等。

Non-Real-Time RIC位于SMO內，通過從RAN和應用服務器收集全域相關數據，進行數據分析和AI訓練，并將推理和策略通過A1接口下發、部署于Near-Real-Time RIC。

Near-Real-Time RIC位于RAN內，負責收集和分析RAN的即時信息，結合Non-Real-Time RIC提供的額外或全局信息，并通過Non-Real-Time RIC下發的推理模型和策略，實時監控和預測網絡和用戶行為變化，并根據策略(比如QoE目標)實時對RAN參數進行調整，包括調整資源分配、優先級、切換等。比如，預測到網絡即將發生擁塞，Near-RT RIC根據推理實時調整網絡參數以預防擁塞。

Near-Real-Time RIC中包含了多個xAPP。

(xAPPs與RAN功能的關系)

xAPP是可以由第三方獨立部署的應用，它將AI推理模型和策略部署于其中，并且不同的xAPP與不同的RAN功能關聯，從而使得RAN功能組件具備靈活的可編程性和可擴展性。

總之，O-RAN通過引入Non-Real-Time RIC和Near-Real-Time RIC，兩者合力可基于AI對網絡負載均衡、移動性管理、多連接控制、QoS管理、網絡節能等功能進行主動優化和調整，最終實現網絡智能化、自動化。

但對于這樣的架構，愛立信指出，O-RAN中的Near-Real-Time RIC存在潛在的安全漏洞，包括Near-Real-Time RIC與gNodeB沖突、xAPPs沖突、xAPP信任根、RIC中的UE標識等問題。

Near-Real-Time RIC與gNodeB沖突

由O-RAN架構可知，Near-Real-Time RIC作為一個邏輯實體，或者說由多個xAPPs組成的軟件平臺，其部署于gNodeB(CU-CP、CU-UP和/或DU)之上。

Near-Real-Time RIC可通過E2接口在xAPPs與gNodeB之間交換數據，來實現每個xAPP控制一個或多個RRM(無線資源管理)功能。比如，Near-Real-Time RIC可以通過E2接口讓特定的xAPP與CU-CP之間交換數據來控制移動性和負載均衡。

但問題來了，Near-Real-Time RIC控制RRM功能，gNodeB也執行RRM功能，兩者之間沒有明確的功能界限劃分，這可能造成Near-Real-Time RIC和gNodeB供應商之間存在決策沖突，從而可能導致網絡不穩定，甚至帶來攻擊者可以利用的漏洞，比如，攻擊者可以利用惡意的xAPP故意觸發與gNodeB內部相沖突的RRM決策而導致服務拒絕。

xAPPs沖突

Near-Real-Time RIC中的xAPPs可以由不同的供應商提供，比如，一家供應商可提供用于移動性管理的xAPP，另一家供應商可提供用于負載均衡的xAPP。

除非能做到完美協調，否則不同xAPP可能會做出相互沖突的決策，比如，用于移動性管理的xAPP和用于負載均衡的xAPP，在同一時刻為同一用戶觸發了不同的切換決策，該聽誰的？這可能會引發無線鏈路故障風險。

在O-RAN規范中已指出xAPPs之間存在以下可能的沖突：

? 直接沖突：不同的xAPPs請求修改同一參數。

? 間接沖突：不同的xAPPs請求修改不同的參數，但修改這些參數會產生相反的效果，比如天線下傾角和測量偏移。

? 隱式沖突：不同的xAPPs請求修改不同的參數，這些參數不會產生相反的效果，但可能會導致網絡整體性能下降。

由于xAPPs沖突會導致網絡不穩定或性能下降，攻擊者就可能會利用這個漏洞來攻擊網絡，令網絡存在安全隱患。

xAPP信任根

Near-Real-Time RIC中的xAPP具有處理特定小區，一組UE，以及特定UE的行為的能力。簡單的說，xAPP可以追蹤某個特定用戶，并可以通過從A1接口接收命令設定特定UE的優先級，這存在VIP用戶的大致位置和優先級設置會通過故障xAPP暴露或惡意更改的潛在風險。因此，為了減輕這些風險，需要從硬件到應用程序建立牢固的信任鏈。

此外，愛立信在文章中還指出軟硬件解耦增加了對信任鏈的威脅，以及開源代碼增加了漏洞的暴露等其他安全隱患。

對于這些問題，愛立信認為，隨著RAN向虛擬化、開放化發展，行業應該采用全新的方式來處理安全性，并表示將繼續在O-RAN聯盟中發揮領導作用，整合安全最佳實踐，以確保O-RAN滿足運營商的安全級別。

愛立信于2018年12月申請加入O-RAN，2019年2月正式加入O-RAN，并在O-RAN工作組中占有兩個主席職位。作為O-RAN的主要成員之一，愛立信基于對O-RAN的深入研究，在今年3月份主持的一次Open RAN網絡研討會上，也提出了以上類似的觀點。

在會上，愛立信O-RAN Program Manager Per Emanuelsson指出，由于O-RAN引入了Non-Real-Time RIC、Near-Real-Time RIC和更多開放接口，存在以下挑戰：

1)Non-Real-Time RIC和A1接口

盡管通過Non-Real-Time RIC和A1接口，可收集包括核心網、傳輸網和應用等更廣域的數據，并實現閉環的自動化網絡等，但存在用例不清晰、價值不明確等問題。

2)Near-Real-Time RIC

Near-Real-Time RIC包含了多個xAPP，需一組xAPP與CU-CP(CU的控制面)交互完成無線管理決策，比如切換，這可能會帶來以下問題：

? xAPP之間發生沖突

不同的xAPP同時運行于相同的無線資源和UE，要實現在ms級內相互協作是一大挑戰。

? xAPP與CU-CP沖突

像切換、負載均衡等無線資源管理功能，本身是相互強關聯的，而O-RAN將這些功能模塊通過xAPP的方式拆分部署于Near-Real-Time RIC和CU-CP中，這并不是最優的選擇。

3)開放的前傳接口

愛立信認為，開放前傳接口后，運營商可以從不同的設備商購買DU和RU設備，有助于擴大產業生態。

但存在以下挑戰：

? 增加測試和集成工作量

? 會明顯降低RAN性能

4)云化RAN

云化RAN解耦了硬件和軟件，并將軟件部署于標準的COTS硬件之上(至少部分是COTS硬件)，有利于組成資源池，擴大供應商生態。

但存在以下挑戰：

? 相比專用硬件，性能會下降

? 設備功耗會增加

本文參考：

Security considerations of Open RAN，Ericsson

O-RAN overview，Per Emanuelsson，Ericsson O-RAN Program Manager

如有翻譯和理解不當之處，請留言指正。

總結

以上是生活随笔為你收集整理的mano安全_爱立信：O-RAN存在的安全风险的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。