MEC安全建設(shè)策略

何明，沈軍，吳國威

（1.中國電信股份有限公司研究院，廣東 廣州 510639；2.移動互聯(lián)網(wǎng)系統(tǒng)與應(yīng)用安全國家工程實(shí)驗(yàn)室，上海 200120）

0 引言

多接入邊緣計(jì)算（MEC,Multi-access Edge Computing）通過將能力下沉到網(wǎng)絡(luò)邊緣，在靠近用戶的位置上，提供IT 服務(wù)、環(huán)境和云計(jì)算能力，以滿足低時延、高帶寬的業(yè)務(wù)需求，是5G 網(wǎng)絡(luò)的關(guān)鍵能力之一。

MEC 具有更高的開放性，運(yùn)營商可以通過MEC 向授權(quán)的第三方開放其無線接入網(wǎng)絡(luò)，允許它們靈活、快速地在MEC 平臺上部署應(yīng)用程序和服務(wù)。但是，MEC 平臺的開放性在帶來使用便利的同時，也增加了風(fēng)險(xiǎn)暴露面，安全管理的復(fù)雜度劇增[1]；同時，其大多采用容器和微服務(wù)架構(gòu)，運(yùn)行時資源和行為快速變化、業(yè)務(wù)交互模式復(fù)雜，傳統(tǒng)網(wǎng)絡(luò)安全防護(hù)機(jī)制無法適應(yīng)這種快速變化的復(fù)雜的安全防護(hù)需求[2]。另外，邊緣節(jié)點(diǎn)資源的有限性也將對MEC 安全防護(hù)實(shí)施帶來挑戰(zhàn)。

為了應(yīng)對MEC 建設(shè)部署時可能面臨的安全問題，本文對MEC 安全需求進(jìn)行了分析，并提出了應(yīng)對策略建議。

1 MEC安全需求分析

在實(shí)際部署中，MEC 系統(tǒng)通常由MEC 業(yè)務(wù)管理平臺以及邊緣MEC 節(jié)點(diǎn)組成。其中，MEC 業(yè)務(wù)管理平臺集中式部署，主要負(fù)責(zé)MEC 業(yè)務(wù)的管理和控制，并與IT系統(tǒng)、云管系統(tǒng)、5G 核心網(wǎng)絡(luò)等對接實(shí)現(xiàn)計(jì)費(fèi)結(jié)算、服務(wù)開通、運(yùn)維管理、邊緣資源管理、網(wǎng)絡(luò)能力調(diào)用等功能。邊緣MEC 節(jié)點(diǎn)則分布式部署，包含MEC 應(yīng)用、MEP、虛擬化基礎(chǔ)設(shè)施，實(shí)現(xiàn)MEC 業(yè)務(wù)的直接處理。其中，MEP 接受來自MEC 業(yè)務(wù)管理平臺的管理調(diào)度，并執(zhí)行和實(shí)現(xiàn)相應(yīng)策略。具體架構(gòu)如圖1 所示：

圖1 MEC部署架構(gòu)示意圖

（1）MEC 業(yè)務(wù)管理平臺安全需求

MEC 業(yè)務(wù)管理平臺負(fù)責(zé)MEC 業(yè)務(wù)的管理和控制，如果被入侵，攻擊者可以非授權(quán)獲取MEC 資源控制權(quán)限或者獲取相關(guān)管理信息，從而可以非法控制MEC 資源，將威脅整個MEC 業(yè)務(wù)的正常運(yùn)營。

MEC 業(yè)務(wù)管理系統(tǒng)可以調(diào)用編排管理系統(tǒng)，實(shí)現(xiàn)對MEC 節(jié)點(diǎn)的靈活部署應(yīng)用，如果這個編排管理權(quán)限被濫用、非授權(quán)使用，或者編排管理通道被中間人劫持導(dǎo)致編排管理指令被惡意篡改，攻擊者可以對MEC 節(jié)點(diǎn)進(jìn)行惡意編排管理操作，將對整個MEC 業(yè)務(wù)帶來極大的安全威脅[3]。

因此，MEC 業(yè)務(wù)管理平臺的安全建設(shè)重點(diǎn)主要是提高自身安全防護(hù)能力，加強(qiáng)編排管理的安全可信。

（2）邊緣MEC 節(jié)點(diǎn)安全需求

1）物理層安全需求

當(dāng)MEC 業(yè)務(wù)節(jié)點(diǎn)部署在客戶側(cè)時，不受運(yùn)營商所控制，其物理安全訪問控制如果做得不到位，可能存在較高風(fēng)險(xiǎn)，直接影響MEC 的可用性、可信性。主要表現(xiàn)在：惡意人員可能拆解設(shè)備，惡意替換設(shè)備器件，運(yùn)行惡意軟件包；惡意人員可能通過物理端口非法接入設(shè)備和系統(tǒng)，進(jìn)行非授權(quán)操作，竊取敏感數(shù)據(jù)等；惡意人員可能對設(shè)備進(jìn)行物理破壞，影響MEC 可用性等。

因此，保障部署在客戶側(cè)的MEC 系統(tǒng)的物理安全成為MEC 建設(shè)必須解決的重要問題。

2）虛擬基礎(chǔ)設(shè)施層安全需求

MEC 節(jié)點(diǎn)承載在虛擬化基礎(chǔ)設(shè)施之上，面臨著與云虛擬化基礎(chǔ)設(shè)施相似的安全風(fēng)險(xiǎn)，需要保障虛擬化軟件安全。同時，由于MEC 應(yīng)用大多采用基于容器的微服務(wù)架構(gòu)，各容器共用宿主機(jī)內(nèi)核資源，因此存在容器與宿主機(jī)之間、容器與容器之間隔離方面的安全風(fēng)險(xiǎn)，具體包括進(jìn)程隔離、文件系統(tǒng)隔離、進(jìn)程間通信隔離等。雖然Docker 通過Namespaces 進(jìn)行了文件系統(tǒng)資源的基本隔離，但仍有/sys、/proc/sys、/proc/bus、/dev、time、syslog 等重要系統(tǒng)文件目錄和命名空間信息未實(shí)現(xiàn)隔離，而是與宿主機(jī)共享相關(guān)資源。攻擊者可能通過對宿主機(jī)內(nèi)核進(jìn)行攻擊達(dá)到攻擊其中某個容器的目的[4]。另外，由于容器所在主機(jī)文件系統(tǒng)存在聯(lián)合掛載的情況，惡意用戶控制的容器也可能通過共同掛載的文件系統(tǒng)訪問其他容器或宿主機(jī)，造成數(shù)據(jù)安全問題。

因此，MEC 裸金屬容器比普通云基礎(chǔ)設(shè)施中的虛機(jī)面臨更高的隔離方面的安全風(fēng)險(xiǎn)，需要加強(qiáng)安全隔離管控。

3）MEC 應(yīng)用安全需求

MEC 應(yīng)用基于MEC 主機(jī)的虛擬資源進(jìn)行實(shí)例化，接受MEP 的管控，提供行業(yè)應(yīng)用服務(wù)。

首先，MEC 應(yīng)用可能對5G 核心網(wǎng)產(chǎn)生安全威脅。由于邊緣UPF 需要跟MEC 應(yīng)用互通，如果隔離控制不當(dāng)，可能存在MEC 應(yīng)用對UPF 的攻擊，進(jìn)而影響到5G 核心網(wǎng)。如果UPF 跟MEC 應(yīng)用部署在同一個虛擬化平臺上，UPF 甚至可能被MEC 應(yīng)用擠占資源，影響轉(zhuǎn)發(fā)性能。另外，為了滿足客戶的個性化服務(wù)，可能需要進(jìn)行云邊協(xié)同，MEC 應(yīng)用可能會調(diào)用5G 核心網(wǎng)的某些能力，例如位置信息等，這時，如果訪問控制不當(dāng)，可能存在MEC 應(yīng)用對5G 核心網(wǎng)的安全威脅。因此，進(jìn)行MEC 建設(shè)時，必須做好MEC 與5G 核心網(wǎng)的安全隔離和訪問控制，降低安全威脅被引入5G 核心網(wǎng)的風(fēng)險(xiǎn)。

其次，當(dāng)不同MEC 應(yīng)用共享同一MEC 平臺時，增加了風(fēng)險(xiǎn)暴露面，如果隔離不當(dāng)，就可能發(fā)生某一APP由于自身漏洞被惡意利用，向其他APP 進(jìn)行惡意攻擊，或者影響整個MEC 平臺安全可用性的風(fēng)險(xiǎn)。由于MEC應(yīng)用共享資源，也可能存在某一APP 由于外部攻擊或者自身運(yùn)行異常，導(dǎo)致占用資源過高，從而影響其他應(yīng)用的正常運(yùn)營的風(fēng)險(xiǎn)。另外，這些不同MEC 應(yīng)用的安全等級可能并不相同，MEC 平臺需要考慮如何為這些應(yīng)用提供不同安全等級的安全防護(hù)。

4）MEP 安全需求

MEP 是MEC 節(jié)點(diǎn)本地的“大腦”，負(fù)責(zé)提供MEC系統(tǒng)功能服務(wù)、服務(wù)注冊、APP 權(quán)限控制、流量規(guī)則控制和DNS 域名解析處理等能力，其主要面臨權(quán)限管控以及不可用等安全風(fēng)險(xiǎn)。

首先，MEP 提供開放接口，并對MEC 應(yīng)用進(jìn)行權(quán)限控制。如果這個接口的權(quán)限控制不當(dāng)，或者被惡意篡改，可能存在MEC 能力被濫用、惡意使用的風(fēng)險(xiǎn)。

其次，MEP 如果遭受DDOS 攻擊或者自身存在資源死鎖等問題，可能影響MEP 的可用性，進(jìn)而影響整個MEC 節(jié)點(diǎn)的可用性。

因此，MEP 需要加強(qiáng)對開放接口的安全管控，同時，在自身實(shí)現(xiàn)上應(yīng)具備高可用高可靠的安全機(jī)制。

2 MEC安全建設(shè)策略

從上述安全需求分析可知，MEC 網(wǎng)絡(luò)安全建設(shè)需要著重通過物理安全建設(shè)、安全隔離、細(xì)粒度的授權(quán)控制、規(guī)范MEC 應(yīng)用及平臺開發(fā)和配置等增強(qiáng)MEC 自身安全防護(hù)能力。同時，引入鏡像安全管控、容器安全管控等技術(shù)手段，適應(yīng)MEC 應(yīng)用安全防護(hù)需求，具體安全建設(shè)框架如圖2 所示：

圖2 MEC安全建設(shè)框架

（1）物理安全建設(shè)

根據(jù)國家等保相關(guān)要求，MEP 以及云側(cè)MEC 業(yè)務(wù)管理平臺所在機(jī)房應(yīng)滿足其所承載MEC 業(yè)務(wù)的等級保護(hù)要求。

當(dāng)UPF 和MEC 下沉到客戶側(cè)時，運(yùn)營商應(yīng)該對客戶側(cè)機(jī)房提出物理環(huán)境要求。并且為降低數(shù)據(jù)泄露風(fēng)險(xiǎn)，敏感數(shù)據(jù)應(yīng)不在本地存儲。例如，UPF 應(yīng)該只在PDU 會話階段保留用戶SUPI 等敏感信息，待會話結(jié)束后應(yīng)立即清除相關(guān)信息。另外，UPF 和MEC 設(shè)備應(yīng)具備防拆、防盜、防惡意斷電、防篡改等物理安全保護(hù)機(jī)制，關(guān)閉不用的網(wǎng)絡(luò)接口，管控本地加載系統(tǒng)路徑，不允許從外掛的存儲設(shè)備啟動系統(tǒng)，并對升級補(bǔ)丁和程序的來源和完整性進(jìn)行檢測。在條件允許時，可使用可信計(jì)算保證物理服務(wù)器的可信，確保只有經(jīng)過驗(yàn)證的代碼才可加載、執(zhí)行。

（2）網(wǎng)絡(luò)安全建設(shè)

1）平面隔離

首先，應(yīng)遵循平面隔離原則，將管理平面、業(yè)務(wù)平面、存儲平面分別占用獨(dú)立物理網(wǎng)口，做到物理隔離，保證從物理層面互不干擾。平面內(nèi)根據(jù)不同功能接口可進(jìn)行子網(wǎng)劃分，進(jìn)行邏輯隔離，例如管理平面可繼續(xù)劃分為：虛擬化平臺管理子網(wǎng)、MEC 業(yè)務(wù)管理子網(wǎng)、維護(hù)管理子網(wǎng)等。

對于MEC 和UPF 同在一個虛擬化平臺的一體機(jī)形態(tài)，必須保證MEC 和UPF 的管理和控制平面完全隔離，只允許UPF 的數(shù)據(jù)平面與MEC 互通。

2）數(shù)據(jù)平面安全域劃分和訪問控制

根據(jù)與互聯(lián)網(wǎng)連接暴露程度以及自身安全級別，業(yè)務(wù)節(jié)點(diǎn)應(yīng)繼續(xù)劃分安全子域，不同安全子域在網(wǎng)絡(luò)、計(jì)算、存儲等資源上應(yīng)進(jìn)行隔離，并在域間采用防火墻、ACL等措施實(shí)施訪問控制。應(yīng)加強(qiáng)控制管理平面的訪問控制，僅允許指定管理網(wǎng)元訪問管理平面端口，降低非授權(quán)接入的安全風(fēng)險(xiǎn)。

對于MEC 業(yè)務(wù)管理平臺，建議至少劃分為以下4 個安全域：

◆DMZ 域：面向互聯(lián)網(wǎng)開放的門戶；

◆業(yè)務(wù)管理域：承擔(dān)MEC 業(yè)務(wù)管理功能的各子系統(tǒng)；

◆編排域：承擔(dān)編排管理功能的網(wǎng)元，包括MEO、MEPM 等；

◆公共組件域：承擔(dān)公共服務(wù)的組件，包括：鏡像倉庫、日志組件、監(jiān)控組件等。

對于邊緣MEC 節(jié)點(diǎn)，建議至少劃分為以下3 個安全域：

◆MEC 應(yīng)用域：MEC 應(yīng)用，屬于DMZ 區(qū)域；

◆MEP 域：提供MEP 功能的組件；

◆公共組件域：承擔(dān)公共服務(wù)的組件，包括：日志組件、中間件、安全服務(wù)組件等。

如果UPF 和MEC 同在一個虛擬化平臺的一體機(jī)形態(tài)，則邊緣MEC 節(jié)點(diǎn)需增加一個安全域：UPF 域。

考慮到容器級隔離機(jī)制較弱，建議MEP 與MEC 應(yīng)用采用不同的虛擬機(jī)承載，同時不同安全等級的MEC 應(yīng)用之間也應(yīng)該采用不同的虛擬機(jī)進(jìn)行承載。

對于同一應(yīng)用來說，由于微服務(wù)之間的網(wǎng)絡(luò)流量多為東西向流量，且微服務(wù)之間的業(yè)務(wù)訪問關(guān)系非常復(fù)雜，東西流量的隔離和訪問控制應(yīng)采用支持容器的應(yīng)用級防火墻，實(shí)現(xiàn)微服務(wù)內(nèi)部應(yīng)用層面的隔離。目前，傳統(tǒng)防火墻主要由支持Kubernetes Network Policy 的第三方插件，通過IPTables 實(shí)現(xiàn)L3、L4 層的邏輯隔離。隨著業(yè)務(wù)規(guī)模的不斷增大，在主機(jī)之間構(gòu)建大量的網(wǎng)絡(luò)規(guī)則，將使IPTables 不堪重負(fù)，不僅性能將大受影響，同時這些海量策略規(guī)則的維護(hù)也將難以為繼。因此，為了適應(yīng)大規(guī)模復(fù)雜網(wǎng)絡(luò)的隔離要求，可考慮引入容器級應(yīng)用層防火墻，實(shí)現(xiàn)微服務(wù)層面的訪問控制。

另外，還應(yīng)在邊緣UPF 上設(shè)置訪問控制策略，對目標(biāo)地址是UPF 設(shè)備的數(shù)據(jù)平面流量進(jìn)行過濾，僅允許白名單內(nèi)的IP 地址及對應(yīng)的協(xié)議訪問，降低UPF 遭受攻擊的安全風(fēng)險(xiǎn)。同時，邊緣UPF 應(yīng)限制指定MEC 應(yīng)用占用的帶寬，避免通道被單一MEC 應(yīng)用流量擠占，影響其他MEC 應(yīng)用；同時，禁止MEC 應(yīng)用主動向UE 發(fā)送報(bào)文，降低對UE 終端的安全威脅。

3）5G 核心網(wǎng)訪問控制

為降低對5G 核心網(wǎng)可能引入的安全風(fēng)險(xiǎn)，需要對邊緣MEC 節(jié)點(diǎn)到5G 核心網(wǎng)的流量進(jìn)行訪問控制。

首先，MEC 調(diào)用5GC 能力，應(yīng)統(tǒng)一通過MEP 的認(rèn)證授權(quán)，并由MEP 通過MEC 業(yè)務(wù)管理平臺提交申請。同時，MEC 業(yè)務(wù)管理平臺在接入5G 核心網(wǎng)之前須經(jīng)過全面的安全風(fēng)險(xiǎn)評估，且需對流量進(jìn)行必要的訪問控制和安全檢測。

其次，MEC 業(yè)務(wù)管理平臺在提供流量引導(dǎo)、QoS、位置訂閱及計(jì)費(fèi)功能相關(guān)參數(shù)時不能傳遞DNN、S-NSSAI、SUPI 等核心網(wǎng)參數(shù)信息。

第三、邊緣UPF 與SM 之間應(yīng)采用白名單的方式進(jìn)行訪問控制，僅允許指定IP 和MAC 地址的邊緣UPF 與SMF 互訪，從而降低偽冒UPF 設(shè)備與5GC 通信的風(fēng)險(xiǎn)。

（3）MEC 平臺自身安全增強(qiáng)

MEC 平臺相關(guān)系統(tǒng)應(yīng)在開發(fā)和配置時進(jìn)行安全增強(qiáng)，提高自身安全防護(hù)能力。

首先應(yīng)加強(qiáng)認(rèn)證鑒權(quán)及細(xì)粒度的權(quán)限控制。應(yīng)采用白名單、證書等方式對MEC 業(yè)務(wù)的編排管理組件進(jìn)行雙向認(rèn)證與鑒權(quán)，避免非授權(quán)網(wǎng)元的接入。同時，應(yīng)對管理權(quán)限進(jìn)行隔離，包括MEC 應(yīng)用和MEP 平臺的管理隔離、第三方應(yīng)用之間的管理隔離，避免越權(quán)操作和數(shù)據(jù)泄露。

其次要加強(qiáng)對開放接口API 的安全管控。應(yīng)對API接口調(diào)用采用證書等方式進(jìn)行認(rèn)證與鑒權(quán)，防止API 被非法調(diào)用，并在具體實(shí)現(xiàn)上具備防止重放攻擊、中間人攻擊等安全防護(hù)手段。建議啟用API 白名單機(jī)制，限制可接入的應(yīng)用，并具有API 級別的操作權(quán)限控制，降低API 被攻擊的風(fēng)險(xiǎn)。同時應(yīng)具備API 接口高可用性保證措施，具備異常服務(wù)的處理機(jī)制，保護(hù)核心服務(wù)的可用性。

第三，保障通信安全。在MEC 平臺相關(guān)組件之間應(yīng)啟用TLS 加密傳輸，并對傳輸參數(shù)進(jìn)行簽名驗(yàn)證，防止信息被篡改。

第四，具備鏡像安全保障機(jī)制。應(yīng)該啟用鏡像簽名校驗(yàn)功能，在鏡像安裝和升級前驗(yàn)證鏡像的數(shù)字簽名、確保鏡像的完整性和可信性。并且通過“項(xiàng)目”方式對用戶及鏡像倉庫進(jìn)行組織管理，單個用戶可以在多個鏡像倉庫的同一項(xiàng)目里有不同的權(quán)限，實(shí)現(xiàn)基于角色的訪問控制。

（4）安全檢測和防護(hù)手段建設(shè)

對于采用容器微服務(wù)化架構(gòu)的MEC 平臺相關(guān)系統(tǒng)，應(yīng)部署容器鏡像安全掃描系統(tǒng)，實(shí)現(xiàn)對容器鏡像的安全掃描，確保只有通過核查的鏡像文件才能部署上線，避免帶病入網(wǎng)；同時應(yīng)建設(shè)容器運(yùn)行階段的安全檢測能力，及時發(fā)現(xiàn)容器運(yùn)行期間的異常行為。

同時，需要根據(jù)所承載MEC 業(yè)務(wù)的等級保護(hù)要求，在云側(cè)MEC 業(yè)務(wù)管理系統(tǒng)以及邊緣MEC 節(jié)點(diǎn)配備相應(yīng)的安全檢測和防護(hù)能力。考慮到邊緣節(jié)點(diǎn)資源有限，對于漏洞掃描、堡壘機(jī)、日志審計(jì)、數(shù)據(jù)庫審計(jì)、網(wǎng)頁防篡改、WEB 漏洞掃描等時延要求不高、可遠(yuǎn)程提供的安全能力建議基于云側(cè)集約化安全能力池提供。對于防火墻、WAF 等會影響性能的防護(hù)能力，則通過靠近邊緣MEC 節(jié)點(diǎn)的邊緣安全能力池提供。對于需要部署在MEC 節(jié)點(diǎn)的容器安全檢測檢測引擎、病毒防護(hù)引擎等，應(yīng)隨MEC 節(jié)點(diǎn)同步部署。

（5）MEC 安全運(yùn)維管理

安全是動態(tài)發(fā)展的，需要通過安全運(yùn)維實(shí)時監(jiān)測MEC 運(yùn)行狀況，及時發(fā)現(xiàn)和處置安全風(fēng)險(xiǎn)。

首先，應(yīng)具備資產(chǎn)管理功能，能對MEC 相關(guān)資產(chǎn)進(jìn)行自動識別、資產(chǎn)基礎(chǔ)數(shù)據(jù)的收集、處理和統(tǒng)計(jì)分析，具備通過關(guān)聯(lián)分析方法與策略實(shí)現(xiàn)MEC 的安全風(fēng)險(xiǎn)分析與預(yù)警能力。

其次，應(yīng)在上線前驗(yàn)收環(huán)節(jié)，以及運(yùn)行期間開展對MEC 相關(guān)系統(tǒng)的主機(jī)、應(yīng)用、容器引擎、K8S 等的漏洞掃描和安全基線合規(guī)性核查，并及時進(jìn)行安全整改。

第三，應(yīng)配套建設(shè)鏡像安全管理能力，支持審查鏡像可信來源，對鏡像的證書標(biāo)簽和倉庫來源進(jìn)行可信檢測；鏡像倉庫支持鏡像掃描和基線核查能力，并采用數(shù)字簽名等技術(shù)對鏡像進(jìn)行完整性校驗(yàn)，在鏡像上傳和下載過程中比對簽名，保證鏡像的一致性和完整性。同時對鏡像進(jìn)行權(quán)限和訪問控制，針對不同的鏡像和不同的用戶，設(shè)置不同的訪問權(quán)限。

第四，應(yīng)對MEC 系統(tǒng)的安全策略和配置的實(shí)施、變更等維護(hù)操作進(jìn)行管理，防止因配置不當(dāng)或誤操作而導(dǎo)致的運(yùn)營安全風(fēng)險(xiǎn)。

第五，應(yīng)對內(nèi)部管理人員和第三方維護(hù)人員進(jìn)行集中的身份認(rèn)證管理與訪問控制。建議基于4A 系統(tǒng)實(shí)現(xiàn)維護(hù)管理人員的集中賬號管理、認(rèn)證授權(quán)管理、訪問控制和行為操作安全審計(jì)。并遵循權(quán)限最小化原則，建立權(quán)限分離機(jī)制。

第六，應(yīng)保存MEC 相關(guān)系統(tǒng)的登錄、維護(hù)操作、安全等日志信息，并定期開展MEC 系統(tǒng)相關(guān)日志的安全審計(jì)，包括但不限于賬號和權(quán)限審計(jì)、繞行審計(jì)、異常行為審計(jì)等方面，審計(jì)記錄應(yīng)做好留存。

3 結(jié)束語

本文分析了MEC 在建設(shè)部署時的安全需求，分別從物理安全建設(shè)、網(wǎng)絡(luò)安全建設(shè)、MEC 平臺自身安全增強(qiáng)、安全檢測與防護(hù)手段建設(shè)、安全運(yùn)維管理等方面提出了MEC 安全建設(shè)策略，期望能對相關(guān)組織和人員在MEC安全建設(shè)部署方面提供一定的參考和借鑒。