連接到雲，第3部分: 雲治理和安全性--保護 HybridCloud 應用程式的安全

本文是關於構建混合雲應用程式、考察雲計算的治理和安全性系列文章的第 3 部分，同時也是最後一部分。 本文通過考察如何向 Amazon Simple Queue Service (SQS) 添加存取控制策略擴展了第 2 部分的 HybridCloud 應用程式。 詳細瞭解 HybridCloud 應用程式如何向雲服務驗證自己的身份，以及如何向 Amazon 的 S3 (Simple Storage Service) 添加審計跟蹤。 最後，看看 Google Apps 如何使用 OAuth，以及 Force.com 雲服務如何通過內置測試避免由於疏忽引起的拒絕服務（Denial-of-Service，DoS）攻擊。

簡介

雲治理涉及到對使用雲服務應用策略。 考慮雲治理時，看看它的反面是有好處的：組織使用雲服務時沒有任何監管，從而造成一片混亂。 為了避免這種混亂局面，在使用雲服務時應用策略，以控制隱私資訊洩露到雲中，以及控制濫用雲服務（畢竟雲服務是需要付費的）。 治理和安全就緒之後，就可以自信放心地使用雲計算了。

來自 SOA 治理的經驗

常用縮略詞


API：應用程式設計介面 DSA：數位簽章演算法 IP：Internet 協定 IT：資訊技術 REST：具像狀態傳輸 SOA：面向服務架構 SSL：安全通訊端層 URI：統一資源定位符 WSDL：Web 服務描述語言 XML：可擴展標記語 言

治理 是採用 SOA 之後才流行起來的。 在 SOA 領域中，治理被劃分為設計階段治理（為 Web 服務定義策略）和運行時治理（實際上是將這些策略應用到即時資料流中）。

雲平臺（就像 SOA 中的服務）主要是通過 Web 服務 API 訪問的，因此它們應該與 SOA 治理同屬於一個類別。 至少您可以重用 SOA 治理中的原則。

SOA 治理通常依賴于註冊器。 這是一個中心點，使用者可以在這裡查看 SOA 中的服務，以及查看應用到服務的策略。 標準的 WS-Policy 及其互補 WS-Attachment 規範允許將策略分配到 SOA 中的服務。 因此，服務包含一個指向該策略的 「指標」。 註冊器在服務和策略之間管理這種關係。

SOA 治理產品提供的另一個重要功能是管理服務的生命週期。 這是指控制和跟蹤服務變更的能力，以及控制誰有權力更改服務。 當這種功能就緒之後，組織就能確定服務是由誰創建的，以及由誰在何時更改它。

是不是有了 SOA 治理就意味著雲治理問題已經得到解決呢？ 這不是絕對的。 向雲服務發送的消息和從雲服務發出的消息一般都不是 SOAP，並且這些服務通常不是 WSDL 定義的，這兩個標準通常出現在 SOA 治理中。 這意味著不能簡單地將雲服務導入到 SOA 治理註冊器中。 雲計算使用的 Web 服務繞過 SOAP 和 WSDL，而是利用羽量級的 REST 式服務，REST 式服務因為簡單而在開發人員中得到廣泛使用。

虛擬機器是雲計算的另一個新方面，它將雲計算與 SOA 區分開來。 除了利用 Web 服務之外，雲計算還利用了虛擬機器。 Amazon Elastic Compute Cloud (EC2) 環境可以看作一種虛擬化主控環境，而不是一組服務。 因此，Amazon EC2 的治理可以看作是虛擬機器治理的一個例子。 尤其是虛擬機器的部署很可能得到一個混亂的局面，因為組織可能會使用許多彼此之間稍微不同的虛擬機器。 就像許多 VMware 或 Citrix Xen 使用者的體驗一樣，個體使用者也很難跟蹤虛擬機器。 想像一下，對於一個組織問題就要複雜得多，如果虛擬機器駐留在協力廠商雲服務上的話，就更加難上加難了。

不過，虛擬機器（VM）治理與 SOA 治理的 「生命週期治理」 有一些相同之處。 在 Amazon EC2 雲中，VM 是 Amazon Machine Image (AMI) 的一個實例。 能夠實施規則，以讓特定使用者可以部署某些 AMI 非常重要。 在更精細的級別上，能夠控制誰可以重啟 VM，誰可以向現有的 VM 環境添加容量，以及誰可以刪除現有的虛擬機器實例，這也是很重要的。

上述的最後一項（即刪除 Amazon AMI 實例）尤其重要，因為組織必須為使用這些實例付費。 定價基於使用（當映射處於運行狀態時）和資料流量。 如果沒有雲治理系統，可能會運行更多不需要運行的 AMI 機器實例，從而帶來不必要的成本。 不過，反過來也是成立的：如果沒有雲治理解決方案，就可能會誤刪有用的 AMI 實例。 AMI 實例的生命週期管理避免了無用實例，就像 SOA 治理處理不使用治理框架時無用服務不斷在組織中滋生一樣。

流程而非產品

一般都認為 SOA 治理是一個流程而不是產品。 雲治理也堅守這一規則。 要實施治理規則要求開發人員知道治理框架已經就緒。 例如，如果 SOA 治理註冊器已經部署，那麼開發人員必須知道應該在這裡註冊 Web 服務（尤其是它們的 WSDL 定義）。 如果沒有通過註冊，Web 服務就在監視之中。 如果沒有要求開發人員通過雲服務所在的組織註冊使用雲服務，也會發生類似于 SOA 治理中出現的事情。

在 SOA 治理領域中，除了由註冊器提供的設計階段治理之外，還有一個運行時治理，並且在這個階段實施在註冊器中配置的規則。 服務的規則實施點通常體現為嵌入式代理或網路媒介，比如 XML 閘道。

對於 SOA 治理中的註冊器和運行時實施點（比如代理或 XML 閘道），在雲計算中都是不存在的。 這意味著雲計算服務沒有可供使用者查看所有服務和相關策略的中心點。 儘管策略在連接的雲計算端實施（由雲服務提供者實施），但是它們並沒有在用戶端實施。 因此，雲計算的治理面臨重要的挑戰。

無用的雲

雲計算在很多方面都類似于早期的 Web 服務。 開發人員可能獨自決定使用這一新技術，並且最終使用了。 公司的 IT 管理人員是不能覺察到這種情況的。 然後，才慢騰騰的添加治理這把保護傘。 此時，許多組織已經進入雲計算的前期治理階段。 開發人員在專案中玩弄 AMI 映射的情況並不少見；即使最初的原型化要求使用個人的 Amazon 帳戶和信用卡。

用戶端治理 —— 未能付諸實施？

雲服務提供者通常不必提前將服務停機資訊提交給客戶。 另外，當發生服務意外停止時，雲服務提供者沒有責任通知雲服務使用者。 為了監控雲服務的回應時間和可用性，必須具備一個用戶端元件。 用戶端元件（例如，XML 閘道）監控到雲平臺的連接。 如果連線速度很慢，XML 閘道將發出一個警告，或者採取補救措施，比如使用它的緩存進行回應。 通過以這種方式使用緩存，可以減輕雲服務停機造成的影響。

用戶端上的 XML 閘道還能掃描雲資料，看看是否洩露隱私資訊或公司的敏感性資料。 在將資料上傳給雲供應商之前，應該對資料進行加密，或者有選擇地加密一部分資料。 例如，XML 閘道應該能夠確保上傳給雲計算供應商的資料被去除身份，從而使該資料與隱私資訊沒有關聯。

XML 閘道，比如 Vordel XML Gateway Cloud Edition，將過濾上傳到雲平臺的資料流程，以及將策略應用到雲服務的訪問。 這樣，XML 閘道為用戶端連接到雲服務提供一條通道。

將控制應用到 HybridCloud 應用程式

在本系列的第 2 部分中，您就開始創建 HybridCloud 應用程式，它利用了 Amazon Web Services。 考慮雲治理和安全性時，您將看到 Amazon Web Services 如何驗證這個應用程式，以及如何對它應用策略。

Amazon 密匙

HybridCloud 應用程式利用了 Amazon SQS 雲服務。 SQS 像所有 Amazon Web Services (AWS) 一樣，需要使用訪問密匙 ID 和關聯私有密匙。 我們看到在 HybridCloud JAVA™ 代碼中使用 Amazon 密匙，並將這些密匙硬編碼到在 Amazon SQS 雲中使用的應用程式中。 這些密匙是什麼，我們來詳細查看一下。

什麼是 RSA？

字母 「RSA」 是 「Rivest, Shamir, Adleman」 的首字母縮寫，他們首先發明了 RSA 非對稱加密演算法。

熟悉 Public Key Infrastructure (PKI) 的讀者可能認為這兩個密匙實際上是公共和私有密匙，它們是非對稱關聯密匙對，就像 RSA 或 DSA 用於數位簽章和加密的密匙一樣。 Access Key ID 用作一個識別碼，它識別訪問 AWS 服務的一方。 它在概念上類似于使用者名，可以在不加密請求中發送。 事實上，當 Amazon S3 雲服務用於線上存儲時， Access Key ID 就構成了 URL 的一部分。 如果給一個使用者分配的 Access Key ID 為 「12456789」，那麼用於獲取使用者存儲在 Amazon S3 上的 bucket 檔之一時，所用的 URL 將為：HTTPs://s3.amazonaws.com/123456789- bucketname/filekey。

bucket 是在 Amazon S3 中定義的檔存儲容器。 要定義您在 S3 上所需的空間，必須創建一個 bucket 並給它一個在整個 Amazon 系統中唯一的名字。

Access Key ID 在 URL 中是完全可見的，這意味著它還被儲存在網路基礎設施的日誌中，該基礎設施向 Amazon S3 路由請求以訪問檔。 因此，任何路由器或代理都能夠訪問 Access Key ID。 它對身份驗證的作用不大，因為它很容易找到。 實際上，它用於識別目的，而不是用於身份驗證。

Secret Access Key 才是用於身份驗證的。 不過，它不是由用戶端發送給 AWS 服務。 相反，它被用於創建某種形式的數位簽章，而該簽名用於證明擁有 Secret Access Key。 這種擁有權證明類似于 SSL 握手協定使用加密來證明用戶端是私有密匙的持有者，而不需要發送密匙本身。 用戶端能夠使用密匙表明該密匙在它的控制之下。

對於 PKI 公共和私有密匙，它們之間存在一個數學關係式。 使用私有密匙加密的資料可以使用對應的公共密匙解密。 這是基於 PKI 的數位簽章的基礎。 只有密匙的持有者能夠創建簽名，而所有能夠訪問公共密匙（通過來自 X.509 Certificate）的人都可以驗證簽名。

Amazon Web Services 模型中的 Secret Access Key 沒有這些屬性。 相反，您可以將它看作是 Amazon.com 和使用 AWS 資源（比如它的雲服務）的開發人員之間的秘密。 不能與他人共用 Secret Access Key，避免他們通過它訪問 Amazon 雲服務。 因為開發人員需要為使用雲服務付費，所以 Secret Access Key 落入它人手中會很危險，可能招致巨額帳單。 如果您懷疑協力廠商能夠訪問 Secret Access Key，那麼可以線上創建一個新的 Secret Access Key。

在您的 HybridCloud 應用程式中，密匙是硬編碼在應用程式本身的。 不過，除非您使用 JAVA 模糊處理（obfuscator），否則攻擊者可能對應用程式實施反向工程，從而發現密匙。 這是需要使用 JAVA 模糊處理的主要原因。

HybridCloud 應用程式的策略

在本系列的第 2 部分中，您看到了 HybridCloud 應用程式向 Amazon SQS 發送 X-射線資料。 因為 X-射線圖像是隱私的醫學資料，所以必須在用戶端掃描它看看是否存在隱私資料。 當該資料到達 Amazon SQS 之後再掃描就晚了。 這是使用本地閘道連接到雲計算資源的另一個原因。

HybridCloud 應用程式的另一個安全事項是鎖住對 Amazon SQS 服務的訪問，從而僅允許可信用戶端存取該服務。 這可以使用 Amazon SQS 策略實現。 在 JavaScript Object Notation (JSON) 中定義 Amazon SQS 策略。

讓我們考察一些您可能應用到 HybridCloud 應用程式的 Amazon SQS 策略（要獲得詳細資訊和原始程式碼，請查看本系列的第 2 部分）。

首先，這個策略指定只有具備 Amazon Web Services 帳號 1234567890 的開發人員能夠訪問佇列，它由具有資源 URI /987654321/queue1 的開發人員所有（見 清單 1）。

清單 1. 查看 Amazon SQS 策略

{ "Version": "2008-10-17", "Id": 12345678901234567890 "Statement": { "Sid":"Queue1_SendMessage", "Effect": "Allow", " Principal": { "AWS": "1234567890" }, "Action": "SQS:SendMessage", "Resource": "/987654321/queue1" }}

現在，仔細查看該策略的內容。 首先看到的是版本資訊。 當時，該欄位的唯一有效值為 2008-10-17。 接下來，可以看到規則的 ID。 它在 Amazon Web Services 中必須是唯一的識別碼。 "Statement" 是實際的策略。 在這個策略中，您可以看到 Resource 就是 Amazon SQS 佇列。 您正在指定某個特定的 "Principal"（在本例中為 AWS 使用者）可以訪問特定的佇列，並且僅有指定的主體能夠訪問該佇列。

您還可以設置一個策略，它根據日期、時間和源 IP 位址控制 SQS 佇列的訪問，如 清單 2所示。

清單 2. 設置控制 SQS 佇列訪問的策略

"Condition" : [{ "DateGreaterThan" : { "AWS:CurrentTime" : "2009-04-10T09:00:00Z" } "DateLessThan": { "AWS:CurrentTi me" : "2009-04-10T17:30:00Z" } "IpAddress" : { "AWS:SourceIp" : ["4.3.2.1/24"] }}]

在這個例子中，該策略表明用戶端僅能在 2009 年 4 月 10 上午 9 點至下午 5:30 訪問佇列，並且僅限於特定的 IP 位址段。

您可以使用 AddPermission 和 RemovePermission 方式設置和刪除針對每個佇列的特定訪問權。

當然，Amazon SQS 的策略是由雲服務提供者操作的。 不過，如果要加密發送給雲供應商的資料，或者需要在發送之前進行掃描，那麼用戶端 XML 閘道設備是完成這個任務的最佳工具。

現在，您已經知道如何鎖定對 Amazon SQS 服務上的 HybridCloud 應用程式的訪問，接下來可以粗略看看來自 Amazon、Google 和 Salesforce 的雲安全解決方案。

Amazon S3

Amazon S3 (Simple Storage Service) 是用於線上存儲的雲服務。 它被 Web 網站用作後端存放裝置，比如照片共用網站 SmugMug。 當然，也可以使用它存儲私有公司資料。 您存儲在 Amazon S3 上的資料可能是敏感的，這取決於上下文。 如果您的資料是隱私的，那麼在將它上傳到 Amazon SQS 服務之前使用 XML 閘道對其進行加密。 此外，要跟蹤資料在 Amazon SQS 中是如何被訪問的。 除了隱私性問題之外，您還希望跟蹤 S3 的使用，因為它是需要付費的。 沒有人希望收到令人驚愕的巨額帳單，而且還不能完整地審計該帳單。 為此，要打開 Amazon S3 服務的日誌記錄，這非常重要。

一種開啟 Amazon S3 bucket 日誌的簡單方法是使用 Cloudberry Explorer 應用程式打開 S3 實例的日誌記錄。 Cloudberry Explorer 為 Amazon S3 提供一個很好的 GUI 前端。 在 Cloudberry Explorer 中，您僅需選擇一個 bucket 並按一下工具列上的 Logging 按鈕。 現在，勾選 Use logging 核取方塊。 從下拉清單中選擇用於包含日誌檔的 bucket。 在我們的例子中，這個 bucket 為 cloudberry.log。 實際上，日誌是寫到 Amazon 雲服務上的。 日誌檔必須寫到同一個地理位置的 bucket 中（即 US 應用程式必須寫到 US 日誌中）。 日誌檔的費用將添加到每月的帳單中，因為它使用了 Amazon S3 存儲空間。 不過，審計誰訪問了您的 Amazon S3 存儲服務所需的日誌空間不會很大，因此這筆開銷是很小的（相對而言）。

Google Apps

Google 提供一個稱為 Google Secure Data Connector (SDC) 的工具，它將用戶端 JAVA 應用程式連接到 Google Apps 雲服務。 它在本地網路和 Google Apps 之間提供一個加密連接。 這主要用於將 Google Apps 應用程式連接到本地網路。 構建它的目的是確保 Google Apps 能夠通過該連接進行連接。 另外，它還提供篩檢程式，用於限制哪個 Google Apps 部件能夠訪問哪個內部系統，這很像防火牆規則，不過它僅是應用程式級別的。 除了控制哪個應用程式能被訪問之外，您還可以添加使用者級別的控制。 這允許組織控制誰能訪問 Google Apps 服務。

Google Apps SDS 的身份框架使用的是 OAuth。 例如，宿主的 Google Apps 服務能夠使用 OAuth 向本地應用程式表示它們（及其使用者）的身份。 目前還沒有廣泛部署 OAuth。 不過，Amazon 對 OAuth 的支援可能會改變這個局面。

Force.com：保護和嚴格測試

正如您在本系列的第 1 部分所見，Salesforce 的 Force.com 雲服務使用一種稱為 Apex 的程式設計語言。 Force.com 要求駐留在其雲平臺上的 Apex 代碼包含 「保證」，以確保代碼按預期運行。 這必須占到開發人員的 Apex 類的 75% 以上，最好是 100%。 實施這種措施的目的是避免在整個系統上發生因疏忽招致的拒絕服務（Denial-of-Service，DoS）攻擊。 例如，必須在專門的測試代碼中捕捉到佔用大量資源的無限迴圈代碼。 為了增加另一重保護，Force.com 還強行實施限制（稱為統治者），以在堆疊深度和字串大小級別上執行規則。

儘管其他雲供應商沒有類似于 Force.com 的測試約束，但遵循它們的建議是有好處的，即便您不使用 Force.com 作為雲平臺。 除了防止 DoS 攻擊之外，您還需要確保雲供應商寄來的帳單基本符合預期。

結束語

許多用於解決雲安全的計畫已經就緒，比如 Cloud Security Alliance。 目前，領先的雲供應商有 Amazon、Google 和 Force.com。 不過，雲並不是完全值得信賴的：由於存在資料管理問題，Federal Trade Commission 已被請求調查與雲計算相關的風險。 隨著對雲治理和安全性的理解不斷深入，相信雲治理和安全產品能夠取得進展。