公共云区(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年的时间里都在部署密匙管理基础架构，用这些基础架构来保护全球范围内任务关键型环境中的敏感数据。

(责任编辑：12图资源库)