周蘇靜

（中興通訊股份有限公司 南京 210012）

1 引言

2007年，作為斯坦福大學(xué)Clean State的項(xiàng)目成員，Casado M等人提出了SANE網(wǎng)絡(luò)架構(gòu)和Ethane網(wǎng)絡(luò)架構(gòu)，用于提供企業(yè)網(wǎng)絡(luò)中的安全管理[1]。由于技術(shù)本身的優(yōu)勢(shì)和相應(yīng)的技術(shù)推廣，這種網(wǎng)絡(luò)架構(gòu)被重新命名為軟件定義網(wǎng)絡(luò)（software defined networking,SDN），并被認(rèn)為是替代傳統(tǒng)層次網(wǎng)絡(luò)架構(gòu)、解決當(dāng)前和未來網(wǎng)絡(luò)爆炸性需求的一種革新技術(shù)[2]。有意思的是，目前的SDN版本，例如基于OpenFlow的SDN[3]對(duì)網(wǎng)絡(luò)安全卻很少提及。

鑒于互聯(lián)網(wǎng)技術(shù)的發(fā)展歷程經(jīng)驗(yàn)，人們廣泛意識(shí)到，網(wǎng)絡(luò)設(shè)計(jì)的初期就應(yīng)該考慮到其中的安全問題。于是近年來，也有不少對(duì)SDN的安全需求分析[4,5]、安全解決方案[6,7]提出，但是這一切都剛剛開始，本文對(duì)近年來的SDN安全進(jìn)展做一個(gè)初步總結(jié)，對(duì)其中的解決方案做一個(gè)初步分析。

2 SDN安全性簡(jiǎn)介

2.1 SANE架構(gòu)

SANE[1]是Casado M等人提出的一個(gè)理想的網(wǎng)絡(luò)架構(gòu)，原型實(shí)現(xiàn)后，在7個(gè)主機(jī)構(gòu)成的Ethernet上運(yùn)行了一個(gè)月。SANE的網(wǎng)絡(luò)架構(gòu)主要包含一個(gè)集中控制器（DC），其中的交換機(jī)、主機(jī)均要做相應(yīng)改造，以支持這種架構(gòu)，如圖1所示。

圖1 SANE的架構(gòu)和流程

集中控制器的功能主要包括：認(rèn)證所有網(wǎng)元、名稱解析、全網(wǎng)拓?fù)鋵W(xué)習(xí)、權(quán)能生成。其中權(quán)能 （capability）是SANE引入的一個(gè)數(shù)據(jù)類型，即加密的路徑信息。集中控制器和每個(gè)網(wǎng)元之間共享一個(gè)唯一密鑰，為任意兩個(gè)網(wǎng)元之間的通信計(jì)算路徑，并根據(jù)路徑上的網(wǎng)元和網(wǎng)元的密鑰生成一個(gè)權(quán)能，每個(gè)數(shù)據(jù)報(bào)文都攜帶一個(gè)權(quán)能，途徑上的每個(gè)交換機(jī)通過檢查權(quán)能決定是否允許通行。

如圖1所示，第1步，服務(wù)器B和客戶機(jī)A都進(jìn)行集中控制器認(rèn)證，獲得共享的密鑰；第2步，服務(wù)器B發(fā)布服務(wù)，設(shè)置訪問控制列表，其中客戶機(jī)A被允許訪問；第3步，客戶機(jī)A向集中控制器請(qǐng)求訪問服務(wù)器B，集中控制器從服務(wù)器B的訪問控制列表中查到A的權(quán)限，計(jì)算A到B的路徑，生成路徑上的權(quán)能，發(fā)給客戶機(jī)A；第4步，客戶機(jī)A訪問服務(wù)器B，每個(gè)Ethernet報(bào)文中都包含權(quán)能，權(quán)能有效期（設(shè)計(jì)為幾分鐘）后，客戶機(jī)A如果要繼續(xù)訪問服務(wù)器B，就需要再次申請(qǐng)權(quán)能。

如上所述，SANE架構(gòu)的效率比較低，不適合在實(shí)際中使用，因此Casado M等人又提出了Ethane架構(gòu)[1]。

2.2 Ethane架構(gòu)

Ethane[1]是個(gè)比較實(shí)用的提供集中網(wǎng)絡(luò)安全管理的網(wǎng)絡(luò)架構(gòu)，它把SANE架構(gòu)中橫向傳輸?shù)募用艿目刂茍?bào)文頭，變?yōu)榭v向傳輸?shù)募用芸刂菩畔ⅰ锌刂破骱徒粨Q機(jī)之間通過安全信道傳輸控制信息。

集中控制器的功能包括認(rèn)證網(wǎng)元和用戶、許可檢查、路由計(jì)算、交換機(jī)管理。Ethane并沒有規(guī)定具體的認(rèn)證方法，Casado M等人的原型實(shí)現(xiàn)中使用證書和SSL協(xié)議認(rèn)證交換機(jī)和集中控制器，并用SSL加密集中控制器和交換機(jī)之間的通信。交換機(jī)不僅不需要檢查權(quán)能，甚至不需要目前Ethernet交換機(jī)和3層交換機(jī)的一些功能。

2.3 SDN架構(gòu)

SDN架構(gòu)[3]如圖2所示，SDN具有如下優(yōu)點(diǎn)：高可擴(kuò)展性/高靈活性的網(wǎng)絡(luò)部署、精細(xì)高效的數(shù)據(jù)流控制等。SDN提供對(duì)網(wǎng)絡(luò)設(shè)備的集中式、自動(dòng)化管理、統(tǒng)一的策略執(zhí)行，和目前的網(wǎng)絡(luò)架構(gòu)相比提高了可靠性、安全性。而傳統(tǒng)的網(wǎng)絡(luò)安全應(yīng)用,如訪問控制、防火墻、入侵檢測(cè)、入侵防御等也可利用SDN控制器的開放API實(shí)現(xiàn)或者方便地集成到SDN中。

圖2 SDN架構(gòu)

如上所述，SDN架構(gòu)提供了一個(gè)平臺(tái)，可以為它提供安全保障，并提供安全服務(wù)。大多數(shù)研究者認(rèn)為，目前積累的網(wǎng)絡(luò)安全技術(shù)完全能夠勝任SDN的安全需求，如王淑玲等人提出的SDN安全技術(shù)架構(gòu)[8,9]和傳統(tǒng)網(wǎng)絡(luò)安全技術(shù)架構(gòu)基本無差異。但是具體提供哪些安全機(jī)制，如何設(shè)計(jì)、實(shí)現(xiàn)，還在研究中。

3 SDN的安全需求

Hartman S和Wasserman M等人認(rèn)為SDN的安全需求主要發(fā)生在應(yīng)用層和控制層之間，包括應(yīng)用的授權(quán)、認(rèn)證、隔離以及策略沖突的消解[5]。

控制層（或控制平面）和基礎(chǔ)設(shè)施層（或轉(zhuǎn)發(fā)平面）之間，在一個(gè)交換機(jī)被一個(gè)控制器控制的情況下，安全威脅模型比較簡(jiǎn)單，現(xiàn)有的OpenFlow中的相關(guān)規(guī)范經(jīng)過細(xì)化后可以滿足安全需求[4]；而一個(gè)交換機(jī)被多個(gè)控制器控制的情況下，安全威脅模型比較復(fù)雜，需要考慮控制器之間的授權(quán)、增加控制器對(duì)交換機(jī)資源的細(xì)粒度的訪問控制，這正是現(xiàn)有OpenFlow規(guī)范所缺乏的。

對(duì)于如何在SDN架構(gòu)上實(shí)現(xiàn)傳統(tǒng)的網(wǎng)絡(luò)安全應(yīng)用，如訪問控制、防火墻、入侵檢測(cè)、入侵防御等，或者如何定義SDN控制器的相關(guān)API以實(shí)現(xiàn)上述功能，也是一個(gè)值得研究的課題。

選擇哪些網(wǎng)絡(luò)安全應(yīng)用在SDN架構(gòu)上實(shí)現(xiàn)，也是要考慮的問題，一方面由于SDN API的局限，如基于DPI（深度報(bào)文檢測(cè)）的安全應(yīng)用不能作為SDN的一個(gè)應(yīng)用實(shí)現(xiàn)；另一方面，放棄現(xiàn)有的軟件實(shí)現(xiàn)而在SDN上重新實(shí)現(xiàn)，所花費(fèi)的代價(jià)是否值得也是一個(gè)問題。SDN架構(gòu)的優(yōu)勢(shì)在于低成本地、靈活地實(shí)現(xiàn)一些傳統(tǒng)應(yīng)用，甚至或許能夠引出一些創(chuàng)新的網(wǎng)絡(luò)安全應(yīng)用/服務(wù)。

4 SDN安全解決方案

4.1 應(yīng)用的授權(quán)、認(rèn)證、隔離

應(yīng)用的隔離事關(guān)安全，但也是安全網(wǎng)絡(luò)操作系統(tǒng)會(huì)遇到的問題，尤其是虛擬化技術(shù)經(jīng)常遇到的問題，在此不探求解決方案。下面主要關(guān)注應(yīng)用的授權(quán)、認(rèn)證。

Hartman S和Wasserman M等人探討了3種授權(quán)、認(rèn)證機(jī)制應(yīng)用在SDN上的可能性，尤其是在跨域的情況下[5]：第1種，通過代理認(rèn)證；第2種，直接分發(fā)跨域的認(rèn)證憑據(jù)（如對(duì)稱密鑰、證書的私鑰等）；第3種，通過聯(lián)合認(rèn)證方式（如 OAuth[10]、ABFAB[11]）。其中最后一種方式，即聯(lián)合認(rèn)證方式，具有靈活的特點(diǎn)，便于在多種場(chǎng)合使用。但是參考文獻(xiàn)[5]并沒有給出OAuth、ABFAB在SDN上的具體應(yīng)用方式。

OAuth[10]本質(zhì)上是一種授權(quán)協(xié)議，用于用戶或一個(gè)應(yīng)用授權(quán)給另一個(gè)用戶或應(yīng)用訪問其擁有的資源，而不泄露第一個(gè)用戶或應(yīng)用的認(rèn)證憑據(jù)（如密鑰等）。OAuth架構(gòu)的實(shí)體包括被授權(quán)方（client）、授權(quán)方（resource owner）、授權(quán)服務(wù)器（authorization server）、資源服務(wù)器（resource server）。

OAuth的工作流程包括授權(quán)碼 （authorization code）方式、隱式授權(quán)（implicit grant）方式、資源主口令（resource owner password credential）方式、客戶密鑰（client credential）方式。其中，資源主口令方式是OAuth為了兼容引入的授權(quán)方式，客戶密鑰方式和上述第2種直接分發(fā)跨域密鑰類似，而隱式授權(quán)方式是簡(jiǎn)化的授權(quán)碼方式，為了方便JavaScript實(shí)現(xiàn)的被授權(quán)方。

OAuth還有一種基于斷言（assertion）的框架[12]，是為了兼容其他的身份認(rèn)證管理系統(tǒng)。OAuth的斷言框架中，有一種是客戶端代表用戶的場(chǎng)景，和授權(quán)代碼方式類似，被授權(quán)方利用第三方token service發(fā)來的斷言向授權(quán)服務(wù)器請(qǐng)求訪問令牌。斷言框架的優(yōu)點(diǎn)是能夠兼容很多斷言形式，如資源主的授權(quán)簽名。

綜上所述，認(rèn)為適于SDN架構(gòu)的OAuth是授權(quán)碼方式，是可以在斷言框架下實(shí)現(xiàn)的授權(quán)碼方式。兩個(gè)不同控制器上的應(yīng)用分別作為被授權(quán)方和資源主，資源主所在的控制器上的一個(gè)模塊或者一個(gè)獨(dú)立于兩個(gè)控制器的服務(wù)器可以作為授權(quán)服務(wù)器。

具體地，如圖3所示，App2為被授權(quán)方，App3為資源主，App2要訪問App3的資源，就要從AS獲得訪問令牌。一種方式是App2直接從App3獲得斷言，使用斷言從AS獲得訪問令牌；另一種方式是App3把App2的資源請(qǐng)求轉(zhuǎn)向到AS，AS對(duì)App3認(rèn)證后，通過App3給App2發(fā)放授權(quán)碼，App2使用授權(quán)碼從AS獲得訪問令牌。App3也可以是控制器2的一個(gè)模塊，這時(shí)App2直接向控制器2申請(qǐng)?jiān)L問資源。

ABFAB架構(gòu)[11]主要提供統(tǒng)一或聯(lián)合認(rèn)證，其中的實(shí)體包括用戶（client）、認(rèn)證依賴方（relying party，RP）、認(rèn)證提供方（identity provider，IdP）。其中被授權(quán)方和IdP之間有長(zhǎng)期關(guān)系，例如被授權(quán)方是IdP的注冊(cè)用戶，雙方共享密鑰；RP和IdP有聯(lián)盟關(guān)系，RP依賴IdP提供的認(rèn)證結(jié)果；RP根據(jù)IdP提供的認(rèn)證結(jié)果為被授權(quán)方提供相對(duì)應(yīng)的服務(wù)。

利用ABFAB架構(gòu)為SDN提供跨域認(rèn)證，可以將兩個(gè)控制器上的模塊、應(yīng)用或獨(dú)立的認(rèn)證服務(wù)器作為RP，互相作為對(duì)方的IdP。

具體的例子如圖4所示，App2想訪問控制器2控制的資源，控制器上的RP模塊請(qǐng)求App2所屬的IdP認(rèn)證，從IdP獲得認(rèn)證結(jié)果，決定是否授權(quán)給 App2相應(yīng)的資源。

OAuth和ABFAB也可結(jié)合使用，例如，App3利用ABFAB獲得對(duì)App2的認(rèn)證結(jié)果后，給App2發(fā)放斷言，App2使用該斷言從AS獲得訪問令牌，如圖5所示。

圖 3 OAuth在SDN上的一個(gè)應(yīng)用

4.2 策略沖突的消解

Porrasy P等人提出一種安全加固的控制平面操作系統(tǒng) FortNOX[6]。FortNOX通過擴(kuò)展開源的NOX操作系統(tǒng)的Send_Openflow_Command模塊，增加了策略沖突消解功能。來自不同應(yīng)用的策略被設(shè)定不同的安全等級(jí)，如來自安全應(yīng)用，即可信任的應(yīng)用，如防火墻、入侵檢測(cè)、入侵防御等提供安全服務(wù)的應(yīng)用的策略具有最高優(yōu)先級(jí)，控制層操作系統(tǒng)的本地應(yīng)用產(chǎn)生的策略具有中等優(yōu)先級(jí)，其他提供業(yè)務(wù)的應(yīng)用被分配最低優(yōu)先級(jí)。

擴(kuò)展后的FT_Send_Openflow_Command匯集所有應(yīng)用產(chǎn)生的策略，驗(yàn)證接收到的來自應(yīng)用的策略攜帶的數(shù)字簽名，對(duì)策略進(jìn)行源認(rèn)證；檢查策略沖突是否存在，并根據(jù)應(yīng)用的優(yōu)先級(jí)決定策略沖突發(fā)生時(shí)的動(dòng)作。

4.3 網(wǎng)絡(luò)安全應(yīng)用的實(shí)現(xiàn)

Shin S等人提出了一個(gè)在SDN架構(gòu)上開發(fā)網(wǎng)絡(luò)安全應(yīng)用的開發(fā)環(huán)境FRESCO[7]，F(xiàn)RESCO本身作為SDN應(yīng)用層的一個(gè)應(yīng)用，運(yùn)行在上面所述的安全加固的控制層操作系統(tǒng)（增強(qiáng)的NOX）上。

FRESCO包含實(shí)現(xiàn)若干基本安全模塊，如掃描探測(cè)，復(fù)雜的安全應(yīng)用模塊通過對(duì)基本模塊的組合實(shí)現(xiàn)，如把掃描導(dǎo)引到蜜罐。

5 結(jié)束語

本文對(duì)SDN和網(wǎng)絡(luò)安全相關(guān)的架構(gòu)進(jìn)行了調(diào)研，分析了SDN的安全需求和安全應(yīng)用的現(xiàn)狀，探討了SDN應(yīng)用的認(rèn)證、授權(quán)解決方案。

1 Casado M.Architectural support for security management in enterprisenetworks.DoctoralDissertation,Stanford University,2007

2 ONF．Software-Defined Networking:the New Norm for Networks.ONFWhite Paper,2012

3 ONF．OpenFlow Switch Specification Version 1.3.1,2012

4 Wasserman M,Hartman S.Security Analysis of the Open Networking Foundation (ONF)OpenFlow Switch Specification.IETF Draft(draft-mrw-sdnsec-openflow-analysis),2013

5 Hartman S,Wasserman M,Zhang D.Security Requirements in the Software Defined Networking Model, IETF Draft(draft-hartman-sdnsec-requirements),2013

6 Porrasy P,Shinz S,Yegneswaran V,et al.A security enforcement kernel for OpenFlow networks.Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking(HotSDN),Helsinki,Finland,August 2012

7 Shin S,Porras P,Yegneswaran V,et al.FRESCO:modular composable security services for software-defined networks.Proceedings of the ISOC Network and Distributed System Security Symposium,San Diego,CA,February 2013

8 王淑玲，李濟(jì)漢，張?jiān)朴碌?SDN架構(gòu)及安全性研究.電信科學(xué)，2013(3)

9 郭春梅，張如輝，畢學(xué)堯.SDN網(wǎng)絡(luò)技術(shù)及其安全性研究.信息網(wǎng)絡(luò)安全，2012(8)

10 Hardt D.The OAuth 2.0 Authorization Framework.IETF RFC6749,2012

11 Howlett J,Hartman S,Tschofenig H,et al.Application Bridging for Federated Access Beyond Web (ABFAB)Architecture.IETF Draft(draft-ietf-ABFAB-arch),2012

12 Campbell B,Mortimore C,Jones M,et al.Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants.IETF Draft(draft-ietf-oauth-assertions),2013