构建合规的Web应用程序

导读：大多数组织中只有大约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。

公共云区(PBZ)包含一个Web应用服务器和一个数据存储。Web应用服务器接收互联网用户的连接，以及公司DMZ中的Web应用服务器的Web 服务请求。所有通信都基于TLS/SSL。从公司DMZ发送到公共云的Web服务请求都会通过SSL ClientAuth提供保护，在端点之间相互认证。

这类交易遵循以下步骤：

1. 用户在受控区中注册为客户并分配到一个惟一的Customer ID (CID)（此为C3数据）。客户名联系信息被指定为C2数据，而客户的订单细节被指定为C3数据。对C2数据进行加密、标记并将它们存储到EKMI中。 所有C3数据都会保存在PBZ中，并通过已经过客户端验证的SSL连接进行传递，同时传递的还有与会话相关的交易数据。参见图 4 的步骤 1。

图 4.RC3电子商务交易中的步骤

 

2.此时，用户的浏览器将被重定向到PBZ，在这里将完成大部分交易：

请求头部携带由DMZ中的Web应用服务器分配的会话标记；这允许将PBZ中的交易数据与受控区中的交易关联起来。参见图 4 中的步骤 2。

1. 检查产品列表。
2. 确定价格和供货情况。
3. 向购物车添加选中的产品。
4. 提供配送说明
5. 其他任何与支付无关的数据。

3.在准备付款时，用户的浏览器将重定向到公司DMZ服务器，用户将在其中提交信用卡以进行支付。确认交易后，会将敏感的C1数据加密、标记并保存到EKMI中。进行标记后，会通过客户端验证的Web服务请求将C3数据保存到PBZ中。参见图 4 中的步骤 3。

以下是一些有关电子商务交易的安全事项：

• 对数据安全法规的遵从性是通过将敏感和受控数据加密并保存到安全区的EKMI中来实现的。
• PBZ并不保存用户的任何机密信息。用户身份验证在受控区内进行，将为该用户分配一个有效的会话标记，将用户的浏览器重定向到PBZ，以便进行进一步的处理。
• DMZ和PBZ之间的通信是单向的，是从DMZ到PBZ。PBZ永远不会与受控区内的服务器进行通信；如果应用程序进行了相应的设计，那么就不会出现这种情况。这将确保PBZ内的任何危害都不会影响到受控区。
• 受控区内的服务器仅通过客户端认证的SSL Web务与PBZ进行通信。这可以避免将任何认证凭证存储到PBZ。（SSL客户端认证只要求在目标机器上存储有效和可信的数字证书，以对客户端连接进行 验证。然而，客户端必须向数字证书传递一个有效的私有密匙并加入SSL客户端认证协议）。

医疗RC3交易

本例（从较高层面上）类似于电子商务交易，惟一不同的是该交易进一步展示了如何将非结构化数据（如X光图片）的BLOB（二进制大对象）保存到PBZ中并满足合规性。我们假设患者的基本信息已经在交易之前创建完毕。

这类交易将遵循下面的步骤。

1. X光实验室的技术员将对自身进行认证以访问医院的受控区的服务器并建立会话。如果需要创建新患者的数据，那么将在受控区完成，其中将分配 一个患者ID(PID)。患者统计数据中的某些部分被指定为C1/C2数据；因此，它们将由EKMI加密并标记。医院可以选择将标记后的C1/C2数据保 存到受控区内，或通过安全的单向Web服务存储到PBZ中。参见图5的步骤 1。

图 5.RC3医疗交易中的步骤

 

1.该技术人员的浏览器会重定向到PBZ，她会在其中提交交易的非敏感数据，如：据此设计应用程序后，这部分交易将不需要传递任何 C1 或 C2 数据。参见 图 5 中的步骤 2。

1. 患者看病的日期和时间。
2. 请求医生的标识及其开具的处方。
3. 涉及的技术人员和采取的治疗措施。
4. 任何其他非敏感数据。
5. 准备好提交 X 光照片和放射师的报告后，技术人员的浏览器会重定向到受控区。技术人员会上传 X 光照片和报告，这些内容将通过 Web 应用程序转换为 XML 文档。转换后的 XML 文档包含必须加密的 C1 数据。

C1 数据将在 DMZ Web 应用服务器中接收并发送给一个加密引擎，后者将对较大的非结构化数据进行加密。将生成一个对称密匙并用于加密文档内容。对称密匙应交给 EKMI 保管，而加密的 X 光照片和报告将通过安全的 Web 服务请求存储到 PBZ 中。参见 图 5 的步骤 3。

所有适用于电子商务交易的安全事项均适用于医疗交易。惟一的区别是医疗交易中增加了非结构化数据，即 X 光照片，因此要求使用专门的引擎来处理大 BLOB 的加密和解密。

制造业RC3交易

该示例展示了一名工业环境中的工程师向生产线提交一份敏感文档（如材料单的设计图），以便进行相应的生产。

这类交易遵循下面的步骤。

1.工程师对受控区内的服务器进行认证并建立一个会话。随后将工程师重定向到PBZ。一个Web服务请求安全地将与会话有关的信息从SECZ传递到PBZ。

在PBZ中，工程师将创建一个新的交易，该交易仅接受将C3数据输入云中。然后为交易分配了一个惟一的交易ID，并在请求的响应标头中返回工程师的浏览器。

由于交易是关于制造工厂生产一个新部件，交易的公开部分将接受BOM的非敏感组件。参见图 6 的步骤 1。

图 6. RC3制造交易中的步骤

 

2.工程师的浏览器被重定向到SECZ，并将在其中提交交易的敏感内容。这些信息包括：

据此设计应用程序后，这部分交易会将必要的C1和C2数据传递到SECZ中，并对它们进行加密和标记。加密后的设计图将保存到PBZ中，因为它现在是非敏感的。参见图 6 的步骤 2。

所有适用于前两个交易的安全事项也同样适用于本交易。

1. 将要制造的对象的设计图。
2. BOM的敏感内容。
3. 有关装配的特殊说明（如果有）。
4. 其他任何敏感数据。

结束语

总而言之，如果使用适当的加密密匙管理，那么在使用公共云来计算和保存敏感数据的同时满足数据安全法规的要求是有可能的。实现这一目的的技术目前已 经可用；剩下要做的就是对应用程序进行设计，以便利用这些功能—主要使用这些功能来设计云应用程序，使它们可以对应用程序所访问的不同类别的数据应用不同 的安全资源级别。

关于作者：

Arshad Noor是StrongAuth公司的CTO，该公司位于美国硅谷，过去十年间一直从事企业密匙管理解决方案。Arshad Noor拥有25年的IT从业经验，其中超过12年的时间里都在部署密匙管理基础架构，用这些基础架构来保护全球范围内任务关键型环境中的敏感数据。