企業架構師的雲端資安架構視圖
使用情境方式檢驗基於政策式的資安方式
本文為企業架構師提供了一種發展基於風險的方式來保護雲端運算的方法。 所提倡的方法主要基於 The Open Group 中的雲端安全和 SOA 專案的關鍵工作產品(key work product)。
同時也是幫助參與雲端運算的企業架構師了解如何從多個不同的角度和場景處理雲端運算中的安全性。 我們還將提供有關如何以基於風險的方式評估和減緩資安問題的建議。
我們將介紹了一種基於場景的方法來理解一般企業(也就是雲端運算的消費者)和雲端提供商(如AWS, Azure, GCP等,以下簡稱CSP)資安政策之間的關係、可能出現的差異以及解決這些差異的可用選項。 我們將聚焦在IAM作為政策驅動(policy-driven)的資安問題的範例，並使用IAM來說明可應用於雲端中資安其他面向的方法。
通過這個場景，我們能確定雲端運算中的資安與處理其他聯合政策場景(federated policy scenarios)沒有本質上的區別，但實際上是開放、協作姿態的額外驅動力。 我們還能確定，採用基於政策的方法並利用開放標準可以大大強化企業的雲端資安。 通過採用這種方法，我們確保以安全、可靠和及時的方式實現無邊界資訊流。更多的無邊界資訊流的解釋可參閱本部落格無邊界資訊流一文。
簡介
背景
雲端運算現今仍是企業與其IT 部門的熱門選項之一。 以
- 很少或最少的費用(pay as you go)
- 有限的義務(shared responsibility)
- 更高的靈活性和敏捷性實現幾乎無限的容量(理論上)
但許多企業仍然對雲端運算存在疑慮。 事實上，根據大多數調查，60–80% 的企業將資安問題列為使用雲端的首要障礙。
這種看法促使在 The Open Group Cloud Work Group 下建立了一個專案，主要在檢查雲端運算的安全性。 該專案一直在產生以“雲端安全”為標題的工作產品。
這個專案發現，當涉及到企業的 IT 採購決策時，公有雲只是一個額外的選項。 CSP並非天生不安全。 根據特定企業的資安狀況，我們甚至可能會看到某些CSP的資安狀況可能優於我們自己企業的資安狀況。(光是CSP拿到的資安認證就比一般企業多得多)
資安架構建構區塊(Architectural Building Blocks)
資安架構建構區塊(以下簡稱ABB)是雲端安全框架中的元素。 它們在分析期間和在基於風險的雲端運算安全方法中發展緩解控制項(mitigating control)時使用。
上圖說明了每個構建區塊以及它們如何相互關聯。我們將聚焦在"資安政策管理"和"身份、權限和訪問存取(IAM)管理"。以下是每個建構區塊的說明。而有關於甚麼是建構區塊可參閱本部落格TOGAF的建構區塊(Building Block)一文。
命令與控制管理
命令和控制管理呈現的是一個企業的整體"業務和風險"目標。 這些目標構成了企業中所有營運的基礎，包括其"風險承受能力和安全態勢"。
資安政策管理
資安政策管理呈現以資安政策的形式實現上一層(命令和控制管理)中規定的業務目標。 這些資安政策是資安方案的主要目標，通過上圖中的各式政策(包含人員、流程和技術)來實現。因此，資安政策管理是資安所有面向的核心關注點。
身分、權限與存取管理(IAM)
IAM 關注於確保
- 正確的實體(人員/電腦/服務)能夠在
- 正確的等級和正確的時間
- 存取正確的資源
這包括管理身份的整個生命週期以及授予適當授權身份的相應存取控制還有合規報告。
資料與資訊保護管理
這個建構區塊關注資料和資訊的保護。 這包括啟用加密、資料完整性、資料保留以及與資訊資產的機密性和完整性相關的其他安全方面的控制項。
軟體、系統與服務保證
這個建構區塊聚焦於在整個軟體生命週期中如何設計、開發、測試、操作和維護軟體、系統和服務。
IT服務管理
這個建構區塊實際上是其他服務管理學科的組合，並與資安相關聯。 例如，與資安相關的事件(event)、事故(incident)和問題(Problem)管理。 這是資安與傳統 IT 學科的重要交會點。
威脅與弱點管理
通過主動檢查運作中的雲端基礎架構，這個建構區塊能夠主動應對基礎架構中可能發生的新安全威脅。 這包括弱點掃描、虛擬補丁以及安全測試和回應的其他面向。
所謂虛擬補丁(virtual patching亦稱漏洞防護) 是一種防止威脅利用已知漏洞或弱點來發動攻擊的安全措施。虛擬修補的作用在於透過一些政策和規則來防範並攔截經由網路發動的漏洞攻擊。
實體資產管理
實物資產管理解決了追蹤構成系統的實體資產的問題。
風險與合規管理
風險與合規管理提供一種方法，該方法可分析對於"特定控制項和程序"的合規性以及用"定量和(或)定性"的方式所評估出的風險。 這有助於企業評估整體安全態勢，以及它是否符合命令和控制管理設定的風險目標。
安全模式
安全的整個目標是由影響安全政策的"命令和控制管理"所驅動的。 安全政策規定了身份存取和授權、資料和資訊保護、軟體、系統和服務保證、IT 服務、威脅和漏洞以及實體資產管理的目標。 來自這些建構區塊的佐證和工件被用作風險和合規管理的輸入，它向"命令和控制管理"提供"合規報告和曝險"。 這產生了一個封閉的迴圈系統，該系統允許命令和控制管理根據通過風險和合規管理定量或定性的相對風險暴露來調整影響其他建構區塊的政策。
範圍
我們將聚焦於一個業務場景來說明有關雲端運算中身份、權限和存取政策管理的安全問題。 為了聚焦在這個主題，我們特意選擇了公有雲的 SaaS服務。 這樣做是因為它使我們能夠解決最普遍的問題類別。 其中一些議題在私有雲和(或) IaaS 情況下幾乎沒有相關性，但我們描述的方法仍然有相關。 而且SaaS 經常作為公有雲的交付模型。
原則
The Open Group Cloud Work Group的"雲端和 SOA" 專案的安全性定義了一組安全架構原則。 以下這些原則與本文特別相關：
- 開放性(Openness):
在企業環境中，開放性至關重要。這包括支持所有主要平台、runtimes、開發語言，支援主要產業標準，公開界面和演算法，沒有模糊的安全性，有文件記錄的信任和威脅模型，以及支持通用標準和類似的正式安全驗證計劃。 - 法規設計(Design for regulations):
法規推動了 IT 資安專案中的許多要求，並且法規會隨著時間的推移而變化。 為了解決這個問題，它需要能靈活支援政府法規和產業標準設定的約束性，以及法規、標準和業務策略與用於實施它們的資安政策之間的可追溯性。 - 隱私設計(Design for privacy):
在現今的資料共享時代，隱私變得越來越重要。 解決方案應凸顯出隱私資訊的使用和相應的資料保護機制，並開啟通知(notice)、選擇和存取的原則。 - 延伸性設計(Design for extensibility):
好的解決方案是組件式的(component-based)，將"機制的管理"與"機制本身"分開，以支持同一框架下的多種機制。 已部署的系統必須允許在現有管理框架內加入和延伸新機制。 - 基於政策的存取:
雲端服務的使用將受到政策控制。 而政策應該在應用程序之外。 - 多租戶(Multi-tenancy):
雲端運算模型必須支援雲端的多個租戶之間的隔離。
雲端安全聯盟(CSA)還為雲端定義了一套身份管理原則。 這些原則與我們的業務場景相關：
- 預設情況下，CSP不應尋求變成身份提供商(identity providers)，除非服務於令人信服的大眾利益(如變成非營利組織)並且 IDP 是一項核心業務。
- 消費者(也就是一般企業)應獎勵CSP，CSP將其服務作為依賴方提供給知名和受信任的身份提供商，並儘量減少他們自己收集的身份資訊。
- 強化型身份驗證應該是無所不在的、靈活的，並且由身份提供商提供原生支援(natively supported)。
- 身份提供商有責任發行個人可以使用的 ID，而不僅僅是為了與該提供商的關係。 這包括政府企業僅為自己的員工充當身份提供者，合作夥伴需要接受退出該業務的策略方向。
- 主要的雲端身份提供商需要公開承諾遵守“網路中立(network-neutrality)”原則，使其自己的 SaaS 商業應用程式不比第三方 SaaS 商業應用程序具有競爭優勢。
場景中使用的術語
在本文中，我們使用了許多術語來描述業務場景。 為清楚起見，我們自作主張的定義了以下術語。
買家(Buyer)
買家是與賣家簽訂服務交付合約的組織(購買雲端服務的企業)。
賣家(Seller)
賣家是負責向買家提供雲端服務的實體。 賣家也可能是CSP也可能是代理的SI。 最終，賣家對交付買家約定的服務負有合約責任。
提供商(Provider)
提供商負責交付某些雲端服務。 這些服務可能是買家從賣家購買的部分或全部服務範圍。 提供商也可以使用來自其他提供者的服務。 例如，SaaS 提供商可以使用交付 SaaS 應用程式的 PaaS 提供商的服務。也就是說提供商可能是CSP原廠，或是SI加工CSP原廠服務再提供給一般企業。
消費者(Consumer)
消費者是提供商提供的服務的接受者。 在某些情況下，這可能是終端用戶； 在其他情況下，如果提供商依賴另一提供商提供的服務，則它也可能是消費者。 例如，在不同提供商的 IaaS服務 上託管其 SaaS 的提供商。
責任與義務
責任與義務的區別出現在許多不同的業務和 IT 領域； 雲端運算也不例外。 當一個企業決定開始使用雲端運算時，使用雲端的企業本身仍然對cloud-based service的實現負責。
例如，企業的 IT 部門可能會選擇利用公有雲 IaaS 來解決容量高峰需求。 在這種情況下，CSP有＂責任＂的 將IaaS 交付給企業。 但，IT 部門則有＂義務＂的向企業提供 IT 服務。
業務場景
我們使用涉及一個買家/消費者企業和三個賣家/供應商企業的場景，每一家企業都使用不同的CSP服務。 此外，其中一位賣家既是提供商又是消費者。 通過這樣做，我們可以更容易地解決許多複雜問題，同時保持場景的可管理性。
實際業務場景(如下圖)是一個電商， A企業對外建立了一個電商網站服務。 對於企業而言，無論其IT服務是內部提供還是外部提供，對使用者完全透明是很重要的。 上游提供商提供這樣的服務，我們把它稱為第一級上游廠商 。 第一級上游廠商其實也有自己的上游廠商所以它也必須跟它的上游商串接，我們稱之為第二級上游廠商。 第二級上游廠商使用了另一個雲端提供商的服務。 而第一級上游廠商通常不會只有一家上游廠商，通常會有好幾家，但我們把事情稍微簡化一下，整個事情看起來像以下這樣：
我們可以將其視為一組三個成對的買家/賣家關係，但必須考慮到 第一級上游廠商作為提供商-消費者的角色可以在A企業 和其他兩個賣家之間建立間接關係，這從安全的角度來看可能會產生重大影響。 特別是，很明顯，屬於A企業的資料在與其他三方的交互中暴露並可能被存儲，並且Ａ企業 無法直接控制第二級上游廠商交互。
這裡涉及許多資安事項，但本文只聚焦在一個主要建構區塊：身份、權限和存取管理。 對於這些資安方面，各家企業(也就是上圖業務場景中的各方企業)通常都有自己的政策。 他們處理政策管理的方式可能會有所不同，並導致以下三種情況之一(每對關係)：
- 賣家主導資安政策管理，任何買家都必須遵循賣家的政策。
- 買家主導資安政策管理，任何賣家都必須遵循買家的政策。。
- 雙方各管各的，並實施政策交換框架(framework for policy exchange)。
上述的這些情況中的每一種都會對資安問題的責任和義務產生影響。 在每種情況下，我們都會查看可用於協調各方（以及必要時由一方單獨執行）資安政策的機制，以確保責任方執行的行動支持另一方的問責制需求。請注意，雲端運算的多租戶是一個重要因素。
身分、權限與存取管理(IAM)
在這一部分我們聚焦在政策管理建構區塊，因為這些件建構區塊包含身分與存取政策。
狀況一：賣家的規則
如果我們用 IAM 來回應這種情況，核心問題是主要存儲庫（即最終決定存取權限的存儲庫）屬於賣家。 換句話說，所有身份、角色、群組和存取政政策都必須出現在這裡，並按照賣家規定的條件進行定義。 當然，政策的執行是發生在賣家的區域。如下架構圖。
所有使用者配置(user provisioning)都發生在賣方的區域中，並且對於買家區域中公開的服務，不可能有完整的 SSO。 另外一點是，這不符合我們的開放性原則，也不符合 CSA 的首要原則（CSP不應尋求成為身份提供商）。 此外，我們可以在多大程度上支持法規設計或隱私設計原則也值得懷疑。
顯然，這種形式的所有建構區塊的責任完全由賣家承擔。 與我們將考慮的所有情況和選項一樣，問責制(也就是義務)完全由A企業負責。 A企業 在這裡沒有任何責任，因為它不管理此特定服務的 IAM 的任何面向。
當然還有另外兩個配對關係需要考慮：第一級上游廠商到 第二級上游廠商A和 第一級上游廠商到 第二級上游廠商B。 如果賣家的規則也適用於此，則每個配對關係都有一個主存儲庫，但完整的場景有三個 — — 而且我們無法擁有相同資訊的三個主存儲庫。
解決此問題的一種相對常見的方法是使用 SAML((Security Assertion Markup Language)和 SPML((Service Provisioning Markup Language)等標準，以在存取控制和使用者配置方面實現一定程度的透明度。 這可能如下圖的建構區塊產生。
在這種情況下，A企業確實承擔了一些責任，因為電商服務的客戶是在該區域和賣方區域中提供的。 政策管理仍然是賣家的責任，因為例如，導致發行 SAML token的身份驗證過程與存取 第一級上游廠商服務沒有直接關係。
儘管如此，我們仍然面臨很多複雜性。 賣家和買家的存儲庫資訊格式常常是不一樣的，即使我們可以保持語義一致。 一般而言，我們必須假設有必要在提供(Provisioning)和存取時在各方之間對映使用者資訊。 這通常需要一些自定義功能。 如果所有各方都在交換此類資訊，並且如果他們都沒有在考慮整個場景的情況下設計他們的身份和存取政策，我們可以很容易就會變成下圖那種情況，這很明顯為日後分道揚鑣留下了很大的空間。 然而，場景驅動(scenario-driven)方法的價值在於揭示這種複雜性。 這些知識有助於風險分析和緩解控制的發展。
我們怎樣才能把事情簡化呢？ 我們可以先仔細考慮在第二級上游廠商中需要為哪些實體配置存取權限。 這些服務的消費者其實就是第一級上游廠商。 沒有充分的業務理由在這些提供商的存儲庫中有著A企業的客戶資料。 上游廠商可能是最終產品的所有者，但不是服務的消費者。 如果我們可以採用這種方法，那麼我們就可以從存取控制的角度將場景簡化為三個獨立的成對關係。 （注意：隱私和其他合規性問題並不那麼容易處理，但不是本文的主題。）顯然，這將取決於三個上游提供商的能力。 建議的方法基於幾個核心原則，最重要的是開放性（通過 SAML）和基於政策的存取。 它還在某種程度上支持與身份提供者的＂離散和通用(discrete and generalized)＂角色相關的 CSA 原則。
狀況二：買家的規則
這種情況可以被視為理想世界，因此很難實現。 從本質上講，它要求賣家信任買家以確保只有經過適當身份驗證和授權的使用才能存取買家服務的方式來定義和實施政策。 結果是來自買家區域的任何使用者都將自動取的存取權限。 事實上，使用 SAML 可靠地實現這一點並不難。
實際上，當然不是所有使用者都擁有相同的權限。 如何解決這個問題將取決於賣家應用程式界面（UI 或 API）的細緻度。 如果提供了更細緻度的選項，那麼也許所有的授權都可以在買家端進行控制，而賣家只需要能夠管理他們這邊的 SAML 交易。
但是，如果細緻度不夠，則有必要在 SAML ticket中提供額外的聲明（例如，角色），賣方可以使用它來確定更細緻的存取權限。
在這兩種情況下，除了可能出於稽核目的外，賣家對使用者的身份不感興趣。
那麼為什麼這可能很難實現呢？ ㄟ…，最初的問題是許多 SaaS 服務是圍繞管理自己的存儲庫構建的，可能不願意甚至無法適應更開放的模型。 無論我們多麼希望它有所不同，供應商採用這種方法是完全可以理解的。 它提供了一個最低的公分母，並且更接近於許多專有商業軟體在內部運行的現狀。 換句話說，它可能更容易銷售！ 另一方面，雲端範式(Cloud paradigm)可能是從過時的提供商中心主義轉向更開放方法的最佳動力。 如果並非場景中的所有賣家都採用這種模型，則問題會加劇。 第一級上游廠商還需要發布自己的 SAML tokens。 然而，如果產業力量足以促進採用開放性、可擴展性和基於政策的存取原則以及與身份提供者的離散和通用角色相關的 CSA 原則，那麼這種變化就會發生。
狀況三：合作方式
在狀況三的這個模型中，各方根據需要和適當地交換身份和政策資訊。 這使每間企業都可以在不影響其他企業的情況下，在實現自己的目標和義務所必需的範圍內管理和執行政策。
為實現這一點，各方將需要支援此類行為的標準和協議。 除了已經提到的 SAML（或 WS-Federation）之外，還有 XACML 和 OAuth 等標準可用並且使用越來越廣泛。 另一個相關標準是 InfoCard，最著名的是 Microsoft CardSpace 。
下面的圖 9說明了一種方法。 A企業 負責其自己區域中的政策定義和所有政策管理以及其自己的使用者的產生。 這三個供應商各自負責執行這些政策。 XACML 和 OAuth 等標準用於傳輸政策資訊。 很明顯，這種方式符合開放性的原則，是直接政策驅動(Policy-driven)。 此外，它通過最小化各方之間的耦合(coupling)來支援隱私和可延伸性的設計原則。
我們可以很容易地預見到這一點的許多變化，其中多方定義政策或控制使用者存儲庫。 在這些情況下，政策交換或多或少是雙邊的，並且可能交換使用者屬性，但每一方仍然掌握自己的資訊。 供應商和消費者都可能不願意支持多種標準，而替代方案可能是大量的客製，主要是在消費者方面。 如果我們在我們的場景中考慮到三個提供商的多個租戶，則可以設想資訊交換相當複雜。 對此的一種回應是一種特殊形式的雲端提供商，即IdSP(Identity Service Provider)。 這是雲端服務聚合器的一種形式，僅限於提供身份和政策服務，並且（通常）與身份提供者(Identity Provider)不同。
可以考慮在這種情況下部署建構區塊的多種變化。 原則上，IdSP 還可以使用買家定義的政策來管理政策執行。 IdSP 也可能扮演身份提供者或供應中心(Provisioning Hub)的角色。 CSA 原則提倡獨立身份提供者的存在。 但是，原則中沒有建議這應該是與 IdSP 相同的一方。 消費者尤其需要仔細查看 IdSP 聲明或提供哪些建構區塊，並確保此架構將滿足他們的資安政策或可以採取令人滿意的緩解措施。 反過來，各方的資安政策應該充分認識到我們強調的原則。
上述我們討論的所有選項都沒有改變這樣一個事實，
即遵守A企業的政策的責任仍然由A企業 本身承擔。 買家可以根據合約要求賣家承擔責任，一些國家隱私立法要求在該區域共同承擔責任，但買家不能免除他自己的責任。
這使得正確理解責任以及部署哪些（相關）建構區塊的全部含義變得更加重要。
結論
隨著企業朝向採用公有雲產品，雲端運算中的安全性將繼續成為企業關注的重要議題。 安全議題不能基於雲端服務模型（BPaaS、SaaS、PaaS、IaaS）進行分類。 需要著眼於買家與賣家的資安政策、問責制、責任、靈活性以及最終基於風險的緩解控制來檢查它們。 這些是架構方法所關注的問題。 雲端安全和 SOA專案產生的架構建構區塊和其他工作產品提供了一個優秀的檢視資訊安全模型，並確保買家和賣家的政策可以保持一致。
希望利用雲端運算的企業架構師可以參考本文，以了解如何有條不紊地採用基於風險的方法將安全性應用於雲端運算。
