云環(huán)境固有特性及其對(duì)密碼效能的挑戰(zhàn)*

高崇明，李躍武，楊建鋒

（1.新疆量子通信技術(shù)有限公司，新疆 烏魯木齊 830001；2.新疆?dāng)?shù)字證書中心，新疆 烏魯木齊 830001）

0 引言

密碼是網(wǎng)絡(luò)安全的核心與關(guān)鍵。網(wǎng)絡(luò)系統(tǒng)中密碼措施的效能，愈發(fā)受到網(wǎng)絡(luò)安全領(lǐng)域的關(guān)注。受此理念影響，人們開始熱衷于在傳統(tǒng)網(wǎng)絡(luò)安全措施的基礎(chǔ)之上，通過密碼強(qiáng)化安全保障。但是，深入分析后，經(jīng)常會(huì)發(fā)現(xiàn)，大量網(wǎng)絡(luò)安全系統(tǒng)中，密碼措施的效能并不樂觀，時(shí)常也會(huì)事與愿違，并不能全部達(dá)到預(yù)期的效果。在傳統(tǒng)的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中，由于實(shí)體和資產(chǎn)（如數(shù)據(jù)）的存在形式是明確的，只要正確分析業(yè)務(wù)流程，了解作業(yè)的邏輯過程，明確業(yè)務(wù)對(duì)實(shí)體真實(shí)性保障強(qiáng)度的需求程度、對(duì)行為真實(shí)性保障強(qiáng)度的需求程度、對(duì)數(shù)據(jù)存儲(chǔ)和傳輸?shù)乃矫苄耘c完整性保障強(qiáng)度的需求程度等基本問題（參考GB 17895—1999《計(jì)算機(jī)信息系統(tǒng)安全等級(jí)劃分準(zhǔn)則》），在具備合理的密碼應(yīng)用技能基礎(chǔ)上，總能夠配置出合理的解決方案，或者對(duì)既有解決方案給出合理的評(píng)價(jià)與判斷。在理論研究和實(shí)際工作中都發(fā)現(xiàn)，云計(jì)算環(huán)境下的密碼保障已經(jīng)變得不再簡(jiǎn)單。本文試圖通過對(duì)云架構(gòu)模型，數(shù)據(jù)中心，網(wǎng)絡(luò)、服務(wù)器和存儲(chǔ)設(shè)備的虛擬化，邊界及內(nèi)容分發(fā)網(wǎng)絡(luò)等云概念下的實(shí)體與資源的物理存在與邏輯存在的俯瞰，揭示云計(jì)算環(huán)境對(duì)商用密碼應(yīng)用規(guī)劃與設(shè)計(jì)方案的效能的挑戰(zhàn)。

1 物理存在與邏輯存在——云計(jì)算環(huán)境中的不同視域

云計(jì)算環(huán)境建立和分布在廣大的空間區(qū)域的大型物理設(shè)施之上，但對(duì)使用者所呈現(xiàn)的卻是邏輯上的網(wǎng)絡(luò)功能。對(duì)于維護(hù)者來講，電力、空調(diào)、線纜、機(jī)架、設(shè)備都是實(shí)實(shí)在在的物理存在；對(duì)于使用者（程序員或用戶側(cè)的維護(hù)者），感受到的卻是如云原生（Cloud Native）、Kubernetes（K8S）、Storage Plugin 和Network Pluginde，以及容器（虛擬化）、微服務(wù)、應(yīng)用程序接口（Application Programming Interface，API）服務(wù)器、基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）、平臺(tái)即服務(wù)（Platform as a Service，PaaS）、軟件即服務(wù)（Software as a Service，SaaS）等邏輯上的存在。這體現(xiàn)了不同角色在存在形式上針對(duì)云設(shè)施的視域差異性。

1.1 云的邏輯存在——租戶視域

大多數(shù)云租戶能感受到的是虛擬化的功能，比如云原生概念下的云應(yīng)用產(chǎn)品或服務(wù)，它們由應(yīng)用計(jì)算管理平臺(tái)K8S、存儲(chǔ)代理Storage Plugin 或者網(wǎng)絡(luò)代理Network Plugin 等支撐[1]。

如圖1所示K8S以一種master 和node的 方式，將其對(duì)云資源的劃分與管理功能呈現(xiàn)給用戶接口（User Interface，UI）和client。Master 由API Server、Controler、Scheduler 和etcd 構(gòu)成。

圖1 K8S 架構(gòu)的Master 和Node

具有復(fù)雜功能的用戶應(yīng)用，大多數(shù)會(huì)被分解為運(yùn)行在容器中的微服務(wù)，最終再重組成完整的功能得以實(shí)現(xiàn)。這些運(yùn)行微服務(wù)的容器，在K8S 中，由pod 承載。pod 之間不能直接聯(lián)系，要通過API Server 完成數(shù)據(jù)的交互。這一機(jī)制，顯然會(huì)使應(yīng)用中微服務(wù)之間的流量非常大。

pod 是Kubernetes的一個(gè)最小調(diào)度以及資源單元。用戶可以通過Kubernetes的pod API 生產(chǎn)一個(gè)pod，讓Kubernetes 對(duì)這個(gè)Pod 進(jìn)行調(diào)度，也就是把它放在某一個(gè)Kubernetes 管理的節(jié)點(diǎn)上運(yùn)行起來。一個(gè)pod 簡(jiǎn)單來說是對(duì)一組容器的抽象，它里面會(huì)包含一個(gè)或多個(gè)容器。

按照國(guó)標(biāo)GB 17895—1999的理念，每一個(gè)微服務(wù)都是一個(gè)主體，所有交互的數(shù)據(jù)都是客體，都是可管理的，也必定得到了管理系統(tǒng)的良好標(biāo)識(shí)。運(yùn)營(yíng)者也可以跟蹤與查找到這些標(biāo)識(shí)，否則，應(yīng)用也將會(huì)錯(cuò)亂。

1.2 云的物理存在——云運(yùn)營(yíng)商視域

云計(jì)算是一種模型[2,3]。所有的IT 資源與服務(wù)都是從底層基礎(chǔ)設(shè)施中抽象出來的，在多租戶的環(huán)境下按照需求和規(guī)模提供服務(wù)。每一種云都是服務(wù)與配置的組合。不管云的類型如何，沒有網(wǎng)絡(luò)就沒有云。各種應(yīng)用與數(shù)據(jù)將不能在云上傳遞。在云平臺(tái)下，云服務(wù)商需要將位于全國(guó)各地，甚至全球各地的數(shù)據(jù)中心連接成一個(gè)有機(jī)整體。每一個(gè)數(shù)據(jù)中心的服務(wù)器數(shù)量可達(dá)幾萬臺(tái)甚至幾十萬臺(tái)。圖2 為一個(gè)典型的云平臺(tái)整體網(wǎng)絡(luò)架構(gòu)，其中重要的組成部分包括可用域（Availability Zone，AZ）、區(qū)域網(wǎng)絡(luò)（Region Network，RN）、核心網(wǎng)絡(luò)（Core Network，CN），以及邊緣內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）部分。一個(gè)AZ 中包括了一個(gè)或者多個(gè)數(shù)據(jù)中心（Data Center，DC），一個(gè)Region 中又包含多個(gè)AZ；Edge/CDN 是與運(yùn)營(yíng)商直接相連的部分；整個(gè)網(wǎng)絡(luò)架構(gòu)中最核心的是CN，它通過連接設(shè)備將各個(gè)Region 和Edge/CDN 連接在一起，使整個(gè)網(wǎng)絡(luò)形成有機(jī)的整體。

圖2 典型的云平臺(tái)架構(gòu)

臉書、瞻博網(wǎng)絡(luò)、思科和谷歌等眾多公司都采用了Clos 架構(gòu)。應(yīng)用Clos 架構(gòu)的交換機(jī)的開關(guān)密度，與交換機(jī)端口數(shù)量N的關(guān)系是O(N)3/2，而傳統(tǒng)的交換架構(gòu)這個(gè)指標(biāo)是O(N2)，所以在N較大時(shí)，Clos模型能降低交換機(jī)內(nèi)部的開關(guān)密度。以臉書為例，開關(guān)矩陣類似于一塊布的纖維，所以交換機(jī)內(nèi)的架構(gòu)被稱為Switch Fabric。Fabric 架構(gòu)中，骨干（Spine）交換機(jī)與多個(gè)Fabric 交換機(jī)連接，為數(shù)據(jù)中心的多個(gè)最小構(gòu)成單元（Point Of Delivery，POD）提供連通性。其基本網(wǎng)絡(luò)架構(gòu)如圖3 所示，圖中用3 種方式表示了同一種網(wǎng)絡(luò)架構(gòu)。最上層是Spine 交換機(jī)，中間是Fabric 交換機(jī)，最下面是柜上交換機(jī)（switch on Top Of Rack，TOR）。

Spine 交換機(jī)相當(dāng)于核心交換機(jī)。Spine 和Leaf 交換機(jī)之間通過等價(jià)多路徑（Equal cost multipath，ECMP）動(dòng)態(tài)選擇多條路徑，Leaf Switch 相當(dāng)于傳統(tǒng)3 層架構(gòu)中的接入交換機(jī)，作為TOR 直接連接物理服務(wù)器。

在Fabric 架構(gòu)中，存在著兩個(gè)切面，左右切面是一個(gè)個(gè)POD，前后切面被稱為SP（Spine Plane）。SP的數(shù)量總共有4 個(gè)，每個(gè)也是一個(gè)3 級(jí)Clos 架構(gòu)。在SP中，Leaf是Fabric交換機(jī)，Spine就是Spine交換機(jī)。每個(gè)SP 中，由48 個(gè)Spine 交換機(jī)和N個(gè)Fabric 交換機(jī)相連組成，N的值相當(dāng)于當(dāng)前數(shù)據(jù)中心接入的POD 數(shù)。SP的三級(jí)Clos 架構(gòu)和POD的3 級(jí)Clos 架構(gòu)，共同構(gòu)成了數(shù)據(jù)中心的5 級(jí)Clos 架構(gòu)。因?yàn)樵赑OD 內(nèi)，F(xiàn)abric 交換機(jī)通過48 個(gè)口與TOR 連接，所以在SP的Clos 架構(gòu)中，F(xiàn)abric 交換機(jī)的輸入輸出端口數(shù)量都是48個(gè)。根據(jù)Clos架構(gòu)的特性，在SP中，Spine 交換機(jī)的數(shù)量只要大于或等于48，不論N（POD數(shù)）等于多少，都可以保證網(wǎng)絡(luò)架構(gòu)無阻塞。當(dāng)然實(shí)際中N還受限于Spine 交換機(jī)的端口密度。

由于每個(gè)POD 有4 個(gè)Fabric 交換機(jī)，所以總共有4 個(gè)SP，如圖3 所示。除了前面描述的POD和SP，圖3 中還有黃色的Edge Plane，這是為數(shù)據(jù)中心提供南北向流量的模塊。它們與Spine 交換機(jī)的連接方式，與二層的Spine/Leaf 架構(gòu)一樣。并且它們也是可以水平擴(kuò)展的。

與傳統(tǒng)的三層網(wǎng)絡(luò)架構(gòu)采用的生成樹協(xié)議（SpanningTreepProtocol，STP），以及STP的改良版快速生成樹協(xié)議（Rapid Spanning Tree Protocol，RSTP）和多生成樹（Multiple Spanning Tree，MST），還有虛擬局域網(wǎng)（Virtual Local Area Network，VLAN）、內(nèi)部網(wǎng)關(guān)協(xié)議（Open Shortest Path First，OSPF）、加強(qiáng)型內(nèi)部網(wǎng)關(guān)路由協(xié)議（Enhanced Interior Gateway Routing Protocol，EIGRP）、內(nèi) 部邊界網(wǎng)關(guān)協(xié)議（Internal Border Gateway Protocol，IBGP）不同，Clos 是一個(gè)L2 和L3 混合的網(wǎng)絡(luò)，采用的是外部邊界網(wǎng)關(guān)協(xié)議（External Border Gateway Protocol，EBGP），采用4 字節(jié)抽象形式語法（Abstract Syntax Notation Dotone，ASN），對(duì)于10 萬個(gè)服務(wù)器，每機(jī)架40 個(gè)的情形，需要2 500 個(gè)ASN，超過2 字節(jié)ASN的1 023 個(gè)的國(guó)際標(biāo)準(zhǔn)。

在整個(gè)網(wǎng)絡(luò)中，AZ 由與圖3 類似的結(jié)構(gòu)連接而成。區(qū)域又由AZ 連接而成。兩者方式都是類似的，最終通過核心交換設(shè)備把所有區(qū)域連接起來。Fabric 正如其含義一樣，以非常龐大的數(shù)量，既連接了交換點(diǎn)，又連接著被交換設(shè)備。

圖3 一個(gè)典型Clos 網(wǎng)絡(luò)架構(gòu)實(shí)例

2 K8S的Pod 與Clos 網(wǎng)絡(luò)的Fabric

在K8S 云管理平臺(tái)上，作為所有資源重新劃分與功能組合的結(jié)果，pod 以最基本的容器形式出現(xiàn)，用以承載應(yīng)用分解為微服務(wù)后的計(jì)算邏輯單元。應(yīng)用服務(wù)的運(yùn)行過程，最終體現(xiàn)為各pod 之間數(shù)據(jù)的交互，以及pod 對(duì)存儲(chǔ)和網(wǎng)絡(luò)資源的調(diào)用過程。按照我國(guó)GB/T 22239—2019《信息安全技術(shù) 網(wǎng)絡(luò)安全等級(jí)保護(hù)基本要求》和GB/T 22240—2020《信息安全技術(shù)網(wǎng)絡(luò)安全等級(jí)保護(hù)定級(jí)指南》等等級(jí)保護(hù)標(biāo)準(zhǔn)的基本理念，以及密碼應(yīng)用基本要求GM/T 0054—2018《信息系統(tǒng)密碼應(yīng)用基本要求》的基本理念，各個(gè)pod 理應(yīng)是安全考察的最基本邏輯單元。

2.1 可信計(jì)算

pod 容器應(yīng)為其所承載的微服務(wù)計(jì)算提供可信環(huán)境，同時(shí)承載各pod 本身的容器也應(yīng)當(dāng)有可信計(jì)算的要求。然而，由于K8S 采用的Master-Node 結(jié)構(gòu)中，所有pod 對(duì)外是通過API 服務(wù)器中介的，這些API 服務(wù)器具有對(duì)外通信的職能。所以API 服務(wù)器的可信性就是極大的問題。

2.2 密碼服務(wù)及其調(diào)用主體

承載微服務(wù)的pod，有可能分布在不同的AZ，甚至云架構(gòu)的不同區(qū)域，也就是說，微服務(wù)的計(jì)算設(shè)備在物理空間位置上可能分布在全國(guó)，甚至全球。這就帶來了傳輸安全的需求。安全性如何保障，是一個(gè)不得不面對(duì)的現(xiàn)實(shí)問題。假如采用密碼技術(shù)，按照其應(yīng)用框架[4]，必定要有pod的對(duì)密碼資源的調(diào)用過程，以及密碼資源層的服務(wù)過程和密碼管理基礎(chǔ)設(shè)施的維護(hù)機(jī)制，但在實(shí)際過程中，諸如安全認(rèn)證、真實(shí)性、完整性等功能的需求，對(duì)密碼資源的物理位置要求不明顯。事實(shí)上，無論傳輸，還是存儲(chǔ)的私密性需求，都對(duì)密碼資源的物理位置非常敏感。因?yàn)樵谠铺摂M化環(huán)境中實(shí)際運(yùn)行的是應(yīng)用的虛擬化實(shí)例，而Pod 最終在哪個(gè)物理CPU 等硬件資源上生成，實(shí)際上是不能預(yù)知的。這些物理CPU的位置，可能與邏輯上提供密碼服務(wù)的資源相距數(shù)千公里。為認(rèn)識(shí)到這一點(diǎn)，以圖1 為例，假如在某時(shí)刻，平臺(tái)在組織用戶應(yīng)用的計(jì)算資源時(shí)，涉及的pod1 假設(shè)運(yùn)行在區(qū)域1的AZ1的數(shù)據(jù)中心1 內(nèi)Fabric1 這根連線所連接的服務(wù)器上，而pod2 在區(qū)域2的AZ2的數(shù)據(jù)中心1 內(nèi)fabric2 所連接的服務(wù)器上。pod1 和pod2 在計(jì)算協(xié)同時(shí)，都通過API 服務(wù)器實(shí)現(xiàn)數(shù)據(jù)交互。按照網(wǎng)絡(luò)安全等級(jí)保護(hù)制度2.0（簡(jiǎn)稱等保2.0）和密碼應(yīng)用基本要求，這里都要求引入私密性保障。于是，設(shè)計(jì)者必須面對(duì)一個(gè)現(xiàn)實(shí)的問題，即如圖4 所示密碼技術(shù)應(yīng)用模型中，密碼資源保障層的實(shí)體，部署在整個(gè)云架構(gòu)的哪個(gè)位置，才更有利？

圖4 密碼應(yīng)用技術(shù)框架

一個(gè)不假思索的想法可能是，由用戶應(yīng)用設(shè)計(jì)者決定?？杉?xì)想之下就會(huì)發(fā)現(xiàn)，應(yīng)用設(shè)計(jì)者并不知道podn在什么位置，實(shí)際上對(duì)podn的維護(hù)是由K8S 完成的。這樣看來，K8S 是有義務(wù)考慮，所生成的實(shí)體之間交互時(shí)，可能涉及虛擬通道的私密性問題。假如這里是pod1、API 服務(wù)器和pod2 之間的通信，那么不禁要問，K8S 有這個(gè)機(jī)能嗎？更普遍性的問題是，有任何一種云管理平臺(tái)在生成實(shí)體時(shí)，同時(shí)生成了這些實(shí)體之間的安全傳輸通道（比如VPN）了嗎？答案顯然是否定的。這是因?yàn)?，如果答案是肯定的，那么在面?duì)如此靈活的實(shí)體生成需要時(shí)，它們所涉及的密鑰管理問題怎么實(shí)現(xiàn)？尤其是實(shí)體的密鑰存儲(chǔ)在哪里？能適應(yīng)哪個(gè)安全等級(jí)的需要？因此，在進(jìn)行平臺(tái)設(shè)計(jì)時(shí)，還應(yīng)考慮到的是，平臺(tái)并無法決定哪些實(shí)體之間不必要通信，只能默認(rèn)所有實(shí)體均需要維護(hù)安全傳輸通道。這個(gè)數(shù)量將是O(N2)。這里N是整個(gè)云平臺(tái)中生成的類似于pod 樣的實(shí)體的總數(shù)目。對(duì)于一個(gè)有數(shù)十萬臺(tái)服務(wù)器的云平臺(tái)，如果每個(gè)服務(wù)器不承載百倍千倍的虛擬實(shí)體，虛擬化實(shí)際是沒有意義的。以100 000臺(tái)服務(wù)器，1 000 倍的實(shí)體數(shù)量估算，這個(gè)數(shù)量級(jí)是1016。這是所涉及的具有完整的密碼保障系統(tǒng)（如VPN）的數(shù)量級(jí)。這是任何云設(shè)施都無法保障其安全的。目前也沒有任何云平臺(tái)能做到這一點(diǎn)。

2.3 Fabric（纖維）

Fabric 是連接云中所有物理端口的物理連接線。云中的所有數(shù)據(jù)互動(dòng)，最終都表現(xiàn)在某一組Fabric中的數(shù)據(jù)傳送。運(yùn)行在容器（如Pod）中的微服務(wù)的任何一次活動(dòng)，總對(duì)應(yīng)著一組特定的Fabrics 配合。于是，另一個(gè)自然的想法是，將容器里運(yùn)行的服務(wù)所涉及的所有Fabrics 兩端都加裝安全設(shè)備。對(duì)于預(yù)設(shè)的系統(tǒng)，F(xiàn)abric的這種動(dòng)作雖是確定的，卻不可預(yù)知。從這個(gè)意義上講，這是混沌現(xiàn)象的特征。而這種特征，使得無法預(yù)判為哪些Fabrics 準(zhǔn)備的密碼設(shè)備，因此這個(gè)想法也是無法實(shí)現(xiàn)的。

3 結(jié)語

本文先從云的邏輯模型和物理模型營(yíng)造了討論問題的語言工具，同時(shí)俯瞰了目前云環(huán)境的全貌和細(xì)節(jié)，從宏觀上概覽了云網(wǎng)絡(luò)架構(gòu)和K8S 管理平臺(tái)，從微觀上深入到Fabrics 和容器（如pod）的概念。此外，還結(jié)合GB17895、等保2.0 及GM/T0054 對(duì)安全保障能力的基本要求，分析了云計(jì)算環(huán)境下，安全問題對(duì)密碼應(yīng)用的迫切要求，最后概述了云的某些固有特性對(duì)密碼措施的效能的挑戰(zhàn)。