柠檬铺

 导读：大多数组织中只有大约25%的数据属于敏感数据，这引发一个问题：您是否应该将云应用程序设计为使用全部的可用安全资源来保护所有的数据类 型？这种方式十分消耗资源；但您还可以采用另一种方法。在本文中，作者将为企业中的每种数据创建三个分类，当您在设计将使用这些数据的应用程序时，可以利 用这些分类判断如何应用安全性。这被称为 Regulatory Compliant Cloud Computing (RC3)。   作为IT系统的另一种部署策略，云计算的出现带来了许多机遇，同时也为传统的数据安全性带来了挑战。数据安全法规正在不断完善之中，这令信息技术专业人 士感到困惑：如何在利用云计算的同时实现法规遵从性，从而保护敏感信息。（例如，在2007和2009年分别有9400万和1.3亿张信用卡的资料被 盗，TJX和Heartland Payment Systems为此支付了2.20亿美元的罚金。这是迄今为止公开的最大规模的计算机系统敏感数据泄漏事件）。
解决方法有许多种，主要的两种是：

• 根本不使用云。
• 完全采用云计算。

依我看来，最佳的方式应该介于两者之间：在受控区域内保护和管理敏感数据，而在云中保存非敏感数据。这将允许公司满足数据安全法规，同时最大程度地利用公共云或私有云。
在本文中，我将描述一种特定类型的Web应用程序架构如何使用云计算优化IT投资，同时能够遵从数据安全法规。
传统的Web应用程序架构
从理论上讲，Web应用程序非常简单。浏览器（代表“客户端-服务器”连接中的客户端）显示表单并向用户请求数据。服务器由一个软件程序表示，在一个Web应用服务器上执行。用户提交表单后，服务器程序会接收并处理信息，然后根据结果返回一个响应。这种交互如图 1所示。
图 1.标准的Web应用程序架构

根据应用程序所执行的任务，模型可以变得更加复杂，但是它们都有一个共同的特性：Web表单必须识别服务器的统一资源定位符(URL)，这样，在用户提交表单以进行处理的时候，就可以让浏览器知道应该往哪儿发送表单数据。
对 于大部分应用程序，用户通常在整个交易期间与同一个服务器交互。然而，由于存在众多因素，对于交易的某些部分，可能会将浏览器重定向到不同的服务器，以及 不同的URL。当然，用户并不知道发生了重定向，因此他们感觉到交易非常顺利。更常见的情况是，重定向会朝向同一个域，即使是重定向到不同的服务器。
在一些电子商务应用程序中，可能会将浏览器重定向到支付处理器站点，在该站点将执行支付交易并重定向回原始站点来完成交易。该电子商务站点的优势是他们为交易的“支付-处理”部分构建和维护基础架构。这种重定向如图 2所示。
图 2.重定向到支付处理器

当前IT投资模式的缺点
当前的IT投资模式有许多缺点。以一个典型的电子商务应用程序为例，在当前的IT投资模式下，一家公司必须负责以下内容：
1.它必须针对应用程序的以下所有功能采购物理资源（计算、存储和网络）：

• 客户注册
• 产品管理
• 库存
• 购买交易
• 支付处理
• 履行交易

除此之外还有其他许多任务。这通常会在几年之后导致产生额外的负担，即随着当前的基础架构逐渐老化，无法满足理想的性能需求，可能需要从现有的基础架构过渡到一个新的基础架构。
2.它还必须确保计算基础架构的冗余性，从而确保业务能够持续运营，这通常会导致投资翻倍。
3. 它还必须为整个基础架构提供保护。由于大部分站点并不区分敏感数据和非敏感数据，安全框架通常会应用于基础架构和数据的所有部分。这意味着存在资源分配不 当的情况，因为非敏感信息不需要具备与敏感信息相同程度的保护。（在过去几年里，由于 PCI-DSS [Payment Card Industry Data Security Standard]的原因，站点会对“PCI区”和“非PCI区”、“PCI数据”和“非PCI数据”进行区分。从安全的角度讲，PCI区和数据通常要比 非PCI部分获得更多的关注和投资。虽然这可以视为一种优化，由于非PCI区位于站点的网络边界内，公司仍然会花大笔资金保护数据，如果采用本文所述的架 构设计应用程序，则会使这种情况有所改变）。
这种投资模式在过去40年中一直没有发生变化。虽然从大型机时代开始每笔投资的资本支出就呈现显著减少的趋势，但是，尽管存在商业服务器和开源软件，需要为数十万用户提供服务的应用程序仍然需要可观的资本支出。
云的出现改变了投资模式
云 计算技术的出现（特别是公共云）极大地改变了IT投资的模式。有了云之后，不再需要在前期进行大额的高风险投资，并且这些投资不会随时间而贬值。由于缩减 了开支，公司可以只构建他们所需的IT服务，并根据使用付费。这种变化带来了巨大的经济效益，新的公司只需更少的预算即可进入市场。
与这种变化同等重要的是交付并管理IT服务，防止将敏感数据的工作外包出去。虽然可以通过签约方式委托给第三方，但是数据所有者仍然需要确保对安全法规的遵从性。
因此，我认为Web应用程序的架构师和设计者将发现本文所述的模型会帮助他们满足法律义务，同时能够充分地利用云计算的优势。
实现合规的云计算
业务交易通常包含敏感数据和非敏感数据。至于哪些数据属于敏感数据以及非敏感数据与敏感数据的比例，则取决于业务及交易类型。
但是，假设在正常的分布条件下，对于大多数业务，非敏感数据和敏感数据的比例大约为4:1。因此，在一个安全的范围内计算、存储和管理敏感数据，同时在公共云中计算、存储和管理非敏感数据，这样做可以明显提高IT投资效率。
我 将这种架构称之为Regulatory Compliant Cloud Computing (RC3)：在这种计算模型中，业务交易将涉及受控制区和公共云。敏感数据将在企业（或受委托的外包公司）安全范围以内的受控区内进行加密、标记和管理， 而所有非敏感数据将驻留在公共云中。如图 3所示。
图 3. Regulatory Compliant Cloud Computing 架构模型

接下来，我们将了解RC3架构中的数据分类，然后了解各个行业场景中的数据交易在RC3结构中的工作方式。
RC3的数据分类
构建RC3应用程序的先决条件是将数据分为三个类别。这样做十分有必要，因为这样做可以将应用程序设计为分别处理这三种数据；从而简化业务部门与开发并支持IT服务的技术人员之间的沟通。
让我们来了解一下RC3分类。
类别 1/C1：包含敏感数据和受控数据。如果将这类数据披露给公众，则会导致罚款、法律诉讼和名誉损失。类型1数据包括信用卡号、社会保障号码、银行账户号或其他此类数据。
类型 2/C2：由敏感但非受控数据组成。这些数据是非受控的，但是如果披露给公众将对公司产生不利影响，和/或导致被披露的实体信誉受损。类型2数据包括雇员薪酬；特定产品系列的销售数字；客户的姓名、性别和年龄等。
类型 3/C3：包含非敏感数据。换而言之，任何非C1或C2的数据。例如，产品描述、图片等。
需要注意的是数据分类不是一成不变的：当敏感数据在一个精心设计的加密和密匙管理(EKM)系统中被标记后，它实际上被呈现为非敏感数据。这种情况下，在进行加密和标记后，即使C1/C2数据，也会被划分为C3数据。
采用这些分类后，使用RC3结构的公司将能够确保：

• 使用C1数据都将在一个安全的网络范围内的受控区中处理和存储。这些区域将证明它们符合相应的数据安全法规。C1的数据标记（进行加密并用标记替换后的敏感数据）会保存到公共云中。
• 所有C2数据都将在安全的区域（不一定是受控区）中处理。C2的数据标记也可以保存在公共云中。
• 所有C3数据都将在公共云中处理和保存。

应用程序必须编写为能够处理这种数据隔离；而Web应用程序架构（特别是将浏览器重定向到目标服务器的能力）正适合处理这种模型。
以下小节将介绍不同行业中的几个示例。不过，该模型可应用于任何具有类似挑战的行业。
电子商务RC3交易
以 电子商务RC3交易为例（从较高的层面上讲），我已经使用Java™应用程序模型描述了这种场景，但是您应当知道该模型并不只是针对Java，可以轻松地 应用于.NET框架，或使用任何脚本语言，如PHP、Ruby等。此外，虽然示例展示了Amazon Web Services (AWS)的应用，但是仅是展示而已；该模型可以轻松应用于任何公共云基础架构，如Azure、vCloud、IBM® SmartCloud等。
受 控区包括一个公司隔离区(DMZ)和一个安全区(SECZ)。Web应用服务器位于DMZ区内，接收来自互联网用户的连接。它与SECZ中的数据库服务器 和企业密匙管理基础架构(EKMI）进行通信。EKMI负责对所有C1和C2数据进行加密、标记和管理密匙。EKMI将实现满足数据安全法规所要求的所有 控制。所有通信都基于TLS/SSL。