本文是关于构建混合云应用程序、考察云计算的治理和安全性系列文章的第 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:CurrentTime" : "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 已被请求调查与云计算相关的风险。随着对云治理和安全性的理解不断深入，相信云治理和安全产品能够取得进展。
