從雲消費者的角度談雲安全架構

簡介

雲應用開發者以及DevOps人員已經針對IaaS（Amazon AWS、Rackspace等）和PaaS（Azure、Google App Engine、Cloud Foundry等）平臺成功開發了數以萬計的應用。 這些平臺提供了基本的安全機制，諸如認證、DoS攻擊防禦、防火牆策略管理、日誌、基本使用者與帳戶管理等，但是安全顧慮依然是企業級雲實施的首要障礙。 對雲的安全顧慮，從安全配置部署于IaaS平臺之上的虛擬機器到在PaaS雲上管理使用者許可權，不可謂不廣泛。

鑒於雲服務能夠以多種方式進行提供，例如服務交付模型（SaaS、PaaS以及IaaS（SPI））與運維模型（公有、私有以及混合）的任意混合形式，雲安全顧慮與解決方案都是依賴于上下文（模式）。 因此，解決方案架構應該基於雲應用架構去適配這些顧慮、並構建安全護衛（控制項）。

如此，在雲應用架構師與DevOps人員在針對IaaS和PaaS平臺開發應用之時，他們有哪些架構框架和工具可以使用？ 在本文中，我將討論如何將「足夠的」安全性植入到部署于IaaS和PaaS雲上的應用。

雲安全－共同的職責

首先，讓我們討論雲安全的運維模型。 由定義來看，公有雲的雲安全是在雲消費者（你的企業）和雲服務提供者共同的職責，然而在私有雲裡面，消費者自身需要管理雲平臺的各個方面。 雲服務提供者負責確保公用的基礎設施，其中包括路由器、交換器、負載均衡、防火牆、虛擬層管理程式（hypervisor）、存儲網路、管理平臺、DNS、目錄服務以及雲API。

下圖描繪了雲服務中各個層次的安全職責由供應商與消費者共同承擔。

（點擊圖片查看更大尺寸）

在與某供應商簽下合約之前，對雲的服務能力做一次峰值分析非常重要。 這一練習能給雲平臺的成熟度、透明度以及與企業安全標準（如ISO 27001）和通用標準（如PCI DSS、HIPAA與SOX等）的遵從度提供指標。 雲安全成熟度模型可以説明加快應用向雲移植的戰略。 下面是你在評測雲服務提供者的安全成熟度之時可以使用的一組原則：

·公開安全性原則、遵從性與實踐：雲服務提供者應該展示其與行業標準框架（諸如ISO 27001、SS 16以及CSA雲控制項矩陣等）的遵從度。 由供應商授證的控制項應該滿足你的企業資料保護標準所要求的控制項標準。 當雲服務滿足ISO 27001或者SSAE 16的要求時，控制項的範圍應該被公示。 託管受管資料的雲必須遵守諸如PCI DSS、Sarbanes-Oxley和HIPAA的規定。

· 在被要求時公開：雲服務提供者在由於法律或管理需要必須公開之時應該公開相關的資料。

· 安全架構：雲服務提供者應該公開安全架構細節——它們可能説明或者會阻礙企業標準要求的安全管理。 例如，保證租用者之間互相隔離的虛擬化架構應該被公開。

· 安全自動化： 雲服務提供者應該通過發佈支援下述操作的API（HTTP／SOAP）支援安全自動化：

· 以XML或者企業日誌標準格式匯出和導入安全事件日誌、修改管理日誌、使用者授權（許可權）、使用者帳戶、防火牆策略、訪問日誌。

· 持續安全監控，包括對如雲審計（Cloud Audit）等演化中標準的支援。

·監理與安全職責：雲消費者與供應商的監理與安全管理職責應該被表述清晰。

雲安全威脅與防禦

雲計算是否給你的應用加重了安全威脅？ 哪些相關的新威脅？ 哪些傳統的威脅增強了或者減弱了？ 這些問題的答案都依賴于實際所使用的雲服務部署與運維模型的結合方式。 下圖展示了在對部署到雲的應用架構設計時，對安全控制項應該考量的依賴：

公有／混合雲——威脅

私有雲——威脅

防禦措施

IaaS

· OWASP Top 10

· 資料洩漏（ACL不充分）

· 由於管理台錯誤配置的許可權升級

· 利用虛擬機器弱點

· 通過API的DoS攻擊

· 授權鑰的防護過弱

· 虛擬機器隔離失敗

· OWASP Top 10

· （內部人員）資料竊取

· 由於管理台錯誤配置的許可權升級

· 針對OWASP Top 10脆弱點測試應用程式與API

· 強化虛擬機器鏡像

· 包括加密、多因數認證、良好細微性授權、日誌等的安全控制

· 安全自動化——自動設定防火牆策略、授權帳戶、DNS、應用程式身份（詳見下文）

PaaS

［除了上述的威脅，還包括——］

· 通過API的許可權升級

· 平臺服務中（如訊息佇列、NoSQL、Blog服務）的許可權弱點

· 運行時引擎中的脆弱點導致租用者的隔離失敗

［除了上述的威脅，還包括——］

· 通過API的許可權升級

除了上述對資訊保密性和完整性的威脅，對服務可用性的威脅也需要被作為設計時應該考量的因素。 請記住安全架構的基本宗旨就是設計控制項保護資訊與服務的保密性、完整性和可用性（Confidentiality、Integrity、Availability，以下縮寫為CIA）。

針對雲服務可用性的威脅——雲服務（SaaS、PaaS、IaaS）可以通過DDoS攻擊或者由雲服務操作人員或者消費者錯誤的配置破壞。 這些錯誤可能會蔓延到整個雲，破壞託管雲應用的整個網路、系統和存儲。 為了達到持續可用性，雲應用的架構應該可以能夠承受處於單個資料中心或者某個地理地區（Geographic Region）的破壞。 最近的亞馬遜服務不可用事件——某個彈性塊存儲（Elastic Block Storage，EBS）導致了部署于US東部地區（east region）整個可用區（Availability Zone）的客戶應用不可用—— 就極好地解釋了這一弱點。 然而，架構可以容忍整個地區（Region）出錯的應用則極大地避免了這次服務不可用的影響，並且繼續向使用者提供服務。 作為設計原則，假設雲中的所有事物都會失敗，並且針對失敗去設計。 應用應該能夠承受地理地區的底層物理硬體的失敗以及服務崩潰。 應用與元件的松耦合在後一種情形下可以起到作用。

雲安全架構——計畫

作為第一步，架構師必須理解雲平臺（PaaS、IaaS）提供了哪些安全能力。 下圖解釋了雲服務安全性的架構。

（點擊圖片查看更大尺寸）

雲供應商的安全服務與能力不斷演化，而且互相不同。 因此你經常會發現安全機制，如鑰（key）管理和資料加密，將不可用。 譬如對於加密安全制物的AES 128位加密服務的需要，又譬如存管于鑰管理服務的鑰。 對於這些關鍵服務，你需要繼續依賴內部的安全服務。 對於如此依賴于內部服務的應用，「混合雲」部署架構模式或許是唯一可行的選擇。 另一常見的使用場景是單點登陸（SSO）。 企業內部實現的SSO也許無法擴展到雲應用，除非它基於雲服務提供者支援的SAML 1.1或者2.0使用了聯邦式（federation）架構。

下面是防禦雲服務風險的雲安全最佳實踐：

針對安全即服務（Security-as-a-service）設計架構——雲上的應用部署包括了多種服務的編排（orchestraion），其中包括DNS、負載均衡、網路QoS等服務的自動化。 與安全自動化屬於同一範疇的還包括雲安全區之間的防火牆策略、（SSL）證書供應（provision）、虛擬機器系統組態、帳戶許可權以及日誌配置的自動化。 依賴于防火牆策略創建、證書供應、鑰分發和應用入侵測試（pen testing）等的部署流程應該被遷移到自服務模型。 這種方式將終止人工接觸，也將使安全即服務的場景變得可能。 最終，這將消滅因為人類錯誤導致的威脅、提升運維效率，並將安全控制嵌入到雲應用。

實現聲音識別、訪問管理架構與實踐——可擴展的基於雲的集中式與彈性的架構對基於網路的存取控制將會更少依賴，並確保很強的使用者訪問管理架構。 雲存取控制架構應該給最終使用者以及授權使用者解決使用者與訪問管理生命週期的所有方面：使用者許可權設置（user provisioning）與取消（deprovisioning）、認證、聯盟、授權和審計。 聲音架構將使身份與訪問服務在公有雲、私有雲和混合雲中的所有場景下的再使用性成為可能。 同時採用安全權杖服務以及合適的使用者與許可權設置、審計跟蹤是好的實踐。 聯邦式架構是將企業內SSO擴展到雲服務的第一步。 這裡，你可以參閱雲安全聯盟第12卷獲取更多資訊。

利用API自動化防護——任何新的安全服務都應該擁有API（REST／SOAP）以支援自動化。 API可以説明自動化防火牆策略、配置強化（configuration hardening）以及應用部署時的存取控制。 這可以通過使用開源工具例如puppet結合雲服務提供者提供的API來實現。

總是加密或者遮掩敏感性資料——今天的私有雲應用明天都可能會部署在公有雲。 因此無關乎未來的運維模型，應用架構應該加密所有的敏感性資料。

不要依賴于IP位址做認證服務——雲上的IP位址本就是朝三暮四，所以為了管理網路的存取控制，你不能僅僅依賴于它們。 採用證書（自簽名或者來自于可信的CA）以使部署在雲上的服務之間通過SSL連接成為可能。

日誌、日誌、日誌——應用應該集中式記錄所有安全事件的日誌，它會説明創建端到端的事務視圖，而且天生無可置否。 對於安全事故事件，日誌和審計跟蹤使唯一可靠的資料，由取證工程師用以調研和弄清楚應用是如何被濫用的。 雲是彈性的，日誌則是瞬息萬變，因此週期性將日誌檔遷移到不同的雲或者企業的資料中心是非常關鍵的。

持續監視雲服務——鑒於防衛控制可能無法滿足所有的企業標準，監視是非常重要的功能。 安全性監視應該利用雲服務產生的日誌、API和託管的雲應用以執行安全事件關聯。 由CSA提供的雲審計（cloudaudit.org）可以被用來完成這個任務。

雲安全原則

每個企業都有不同層次的風險容忍，這可以從產品開發文化、新技術採納、IT服務交付模型、技術戰略以及在安全工具與能力方面的投入上看出來。 當企業的營業單位決定利用SaaS產生商業收益，技術架構應該能夠支撐這個模型。 此外，安全架構應該與技術架構和原則一致。 下面是企業安全架構師應該考慮和定制的雲安全原則示例：

運行在雲上的服務應該遵循最小許可權原則。

多個安全區之間的隔離應該通過使用分層防火牆得以保證——雲防火牆、虛擬層管理程式（hypervisor）防火牆、客居系統（guest）防火牆以及應用程式容器。 雲上的防火牆策略應該遵守基於資料敏感性的可信任區隔離標準。

應用程式應該使用端到端的傳輸層的加密（SSL、TLS、IPSEC）以確保資料在部署于雲上的應用程式之間以及到部署于企業內部的應用程式之間的傳輸是安全的。

應用程式應該將認證與授權擴展到可信任的安全服務。 基於SAML 2.0，應該支援單點登陸。

資料遮掩和加密應該基於資料的敏感性而採用，並且與企業資料淨化標準相一致。

位於可信任區的應用程式應該被部署于經過授權的企業標準虛擬機器鏡像上。

在部署虛擬私有雲（virtual private cloud, VPC）時，應該使用行業標準的VPN協定，諸如SSH、SSL和IPSEC。

雲上的安全監控應該與既有的企業安全監控工具通過API集成在一起。

雲安全架構模式

在架構時加入適當的保護雲上資訊CIA的安全控制可以防禦雲安全威脅。 安全控制可以被作為與供應商、企業或者協力廠商供應商提供的服務交付（安全即服務，Security-as-a-Service）。 安全架構模式通常從安全控制的角度（安全護衛）——技術與流程——進行闡述。 這些安全控制和服務來源（企業、雲供應商、協力廠商）應該在安全模式中突出強調。

安全架構模式宛如北極星，可以加速應用往雲上的遷移，而又管理了安全風險。 此外，雲安全架構模式應該強調不同的服務與部署于雲服務之上的元件的可信任邊界。 這些模式也應該指出標準介面、安全協定（SSL、TLS、IPSEC、LDAPS、SFTP、SSH、SCP、SAML、OAuth、Tacacs、OCSP等）以及認證、權杖管理、授權、加密方法（雜湊、對稱式、非對稱式）、 加密演算法（三重DES、128位AES、448位加密（Blowfish）、RSA等）、安全事件日誌、對於策略與使用者屬性的真相來源（source-of-truth）及耦合模型（緊耦合或是松耦合）等機制。 最終，模式應該可以被用以創建安全檢查清單，需要用建構管理工具（如puppet）自動化起來。

通常，對於被雲應用消費的每項安全服務，其模式都應該強調下面的屬性（但是不局限于此）：

邏輯位置——本地到雲服務、內部雲、協力廠商雲。 位置可能會受到性能、可用性、防火牆策略以及服務監理的限制。

協定——調用服務的協定是什麼？ 例如基於X.509證書的REST風格的服務請求。

服務功能——服務的功能是什麼？ 例如加密制物、日誌、認證以及機器指紋。

輸入／輸出——輸入（包含控制的方法）、從安全服務得到的輸出是什麼？ 例如，輸入＝XML檔，輸出＝包括加密屬性的XML檔。

控制描述——安全服務提供了什麼安全控制？ 例如，防衛資訊保密性、使用者認證和應用認證。

執行者——誰是服務的使用者？ 例如，終端（End Point）、終端使用者、企業管理員、IT審計員和架構師。

下圖是由開放安全架構組（open security architecture group，opensecurityarchitecturegroup.org）發佈的雲安全架構模式的子集。

該模式展示了執行者（架構師、終端使用者、業務經理、IT經理）與系統（終端、雲、託管于雲上的應用程式、安全服務）的交付，以及為了防護執行者與系統（訪問管理、DoS防禦、邊界防護、鑰加密與管理等）而採用的控制。 讓我們仔細看看本模式描述的細節。

雲服務提供者方的基礎設施安全服務（控制）

正如本模式所展示，雲服務提供者應該提供對DoS防護以及針對由手機與PC發起的會話的保密性與完整性防護的安全控制。 通常，這些會話由瀏覽器或者用戶端應用程式發起，並使用SSL／TLS進行傳輸，直到由雲服務提供者管理的負載均衡為止。 雲服務提供者通常並不共用DoS防護機制，因為駭客們可以很容易地濫用它。

（內部或雲服務提供者）的應用程式安全服務

安全服務，諸如使用者身份識別、認證、訪問管理、設備識別、加密服務以及鑰管理，既可以位於雲服務提供者、企業資料中心，這兩者也可以結合起來。

下圖的第二種模式展示了源自CSA身份域的身份與訪問模式。

（點擊圖片查看更大尺寸）

本模式展示了一組常見的雲存取控制用例，諸如使用者註冊、認證、帳戶許可權設置、策略管理（policy enforcement）、日誌、審計與計量。 它強調了執行者（終端使用者、企業企業用戶、協力廠商身技人員、雲服務擁有者）與託管在雲、企業內部或者協力廠商的服務的交付。

本模式闡述了下述方面：

雲服務提供者方的身份安全服務（控制）

雲上面運行著下述的服務：

認證服務支援由企業門戶（本地AuthN介面）發起的、常常使用SAML協定傳輸的使用者認證。 經認證的會話在雲上的會話存儲之中維護。

帳戶與使用者資料設置服務支援創建新帳戶和使用者資料——常常是通過調用SPML（Service Provisioning Markup Language）或者雲服務提供者的特定API。 使用者資料存儲與使用者資料存儲。

雲策略管理服務被用以管理原則，比如指示雲上的哪個資源可以被終端使用者訪問。 使用這項服務，雲服務擁有者（企業）就可以執行管理功能，而終端使用者可以請求對雲資源的訪問。 雲策略都存儲于雲策略存儲。

認證服務日誌與審計服務支援雙重功能，首先是雲上事件（包括安全事件）的日誌，其次是審計之用。 訪問這項服務時可以採用雲審計協定和API。

計量服務跟蹤了雲資源的使用。 財務部門可以將這項服務用於收費，也可以用於費用對賬。

企業的身份安全服務

在本模式中，應用程式的子集被託管于企業內部：

雲註冊介面提供了使用者註冊、管理和設置新的雲資源的介面服務。 認證和授權是通過雲服務管理的。

雲使用報表介面可以由終端使用者用來聲稱使用報表。

雲配置（provisioning）服務被用來配置雲資源（計算、存儲、網路、應用程式服務）。 存取控制（AuthN、AuthZ）和會話管理在雲服務端管理了。

位於協力廠商的身份安全服務

在本模式下,雲應用程式依賴于協力廠商提供並託管于協力廠商的身符識別服務。 這些服務支援協力廠商使用者訪問雲資源，代表企業執行業務功能。 例如備份和應用監控服務。 在該模型中,使用者設置、認證和訪問管理功能被委託給了協力廠商服務。

結論

通過瞭解可以利用哪些來自于雲平臺或服務提供者的服務，你可以將安全構建進入你的程式，而不用在你應用程式的邊界之內再去重新創造這些能力——因此避免了昂貴的「附加」保障。 一個良好的實踐是創造可以運用在設計階段的安全原則和架構模式。 架構模式可以説明在設計階段就弄清楚了在哪裡（雲，抑或協力廠商，抑或企業）實施了控制，這樣，適當的安全控制就被融入進了應用程式的設計中去。 在創造雲安全模式的時候，記住相關的威脅與「風險適當」原則。 最終，雲安全架構應該支援開發的需要，以保護處理和儲存在雲端的資料的保密性、完整性和可用性。

(責任編輯：呂光)