hosteons中文网

“如果你不信任他们，你就把数据加密。”这是数据安全专家常常挂在嘴边的一句话。部署在企业内部的数据中心，由于单位组织完全控制全部的软/硬件设备，所以数据要不要加密由企业规章制度界定。

但是在云端，多个互不认识的租户共用计算资源，每个租户需要加密的数据自然就更多，需要加密的数据越多，业务流程越复杂，密钥管理也就越繁重。所以，在实际的操作过程中，我们要综合考虑各个因素，制定出一套既满足安全要求又不大幅度增加加/解密和密钥管理的工作难度的方案。

加密介绍

根据企业的规章制度，某些数据被列为机密并必须要加以保护，当前存储在企业内部的机密数据开始被陆续迁入云端，所以数据保护的力度必须要加大。把机密数据存储在企业的安全边界之外，这增加了数据保护的复杂度，同时也增加了风险系数。

关于云端的数据加密，以下因素必须慎重考虑。

1）不单单在传输过程中需要加密保护，在云端存储和使用数据的过程中也依然需要加密保护。

2）存储在云端并被共享的非结构化数据文件保护方法有以下两种：

• 采用授权服务器进行集中加密；
• 加密直接被嵌入到每个文件当中（分散加密）。

当使用经第一种方法加密的文件时，首先要联系授权服务器进行解密，比如微软的 Word 文字处理软件会自动联系服务器并完成身份验证和解密工作。

3）加/解密的密钥的管理期限就是数据的整个生命周期，在数据被销毁之前如果密钥丢失，则会导致数据无法解密。另外，对于密钥的保护和正当使用，要尽可能避免依赖云服务提供商。

4）保护那些经常被忽视却又包含敏感信息的文件，比如日志文件和元数据如果不加以保护，那么很可能成为数据泄露的途径。

5）云端的加密密钥应具备足够的强度（如 AES-256），且与同一单位组织内部的加密密钥一致。提倡使用开放的且经过验证的加密格式，尽可能避免使用特有的加密格式。

云端数据库加密

首先考虑数据要不要加密，因为加密数据会提高成本并使得业务处理复杂化。目前几乎所有的数据库都具备权限管理机制，如果配置得当，数据库管理系统本身就能很好地保护敏感数据。如果遇到下面 3 种情况，那么我们就不得不对数据库中的记录进行加密了：

• 不想让有权限的人（如数据库管理员）看到记录信息。
• 法律规定一些记录必须要加密（如交易记录中的信用卡信息）。
• 数据存储在数据库的一个 Schema 中，但是数据的主人无法控制访问这些数据的账号（比如多人使用的共享账号，每个人都不能随意修改账号密码）。

当人们使用云端数据库，尤其是 SaaS 应用（该应用需要使用数据库）时，如果数据库不能操作加密的数据，那么数据库的功能会大打折扣。当然，前提是数据库管理系统或者应用能够访问密钥。

数据加密是以提高复杂度和降低性能为代价的，下面是一些替代的方法。

1）使用数据库本身的对象安全机制

数据库中的表、视图、存储过程、函数等统称为对象，对这些对象的访问，数据库管理系统本身提供了一套权限管理机制，诸如账号、分组、角色、授权、撤权等。要严格控制那些被授权的账号，确保这些账号只分配给正确的人。

2）存储安全哈希值

只存储数据的哈希值，而不直接存储数据本身。这使得你的应用程序能证明持有正确哈希值的人就是持有正确数据的人，因为数据与哈希值是一一对应关系，即 hash（data）=x，把 x 存储在数据库中，而 data 存储在另外一个私密的地方，从 x 是无法反算出 data 的。

密钥管理

无论是采用对称加密算法还是采用非对称加密算法，密钥的管理都是重中之重，尤其是对于多租户模式的公共云端来说，密钥管理是一个比较繁重的任务。

最简单的案例是应用在云端运行，而只在企业内部使用密钥对迁移到云端的数据进行加密——在企业的网络安全边界部署一个加密引擎，只要通过这个加密引擎，那么离开企业的数据就会自动加密，而进入企业的数据则会自动解密。

而下面这种情况会把事情搞得很复杂：如果一个使用密钥的应用又包含其他需要使用密钥解密数据的进程（如一个批处理应用可能包含很多进程），且这些进程又驻留云端，那么此时的密钥需要离开企业内部的网络安全边界而进入云端。

企业一般为每个需要加密功能的实体（用户、设备、进程等）分配单独的密钥，这样就不用共享一个密钥，从而避免带来很多隐患。

为了管理众多的实体密钥，最简便的方法是部署一个基于身份的密钥管理中心，从而使得为一个具体实体加密的任何数据只对该实体本身有效。如果同一个组的成员确实需要共享数据，那么可以给该组分配组级的密钥，同组成员共享组级密钥。正如前面所提到的那样：密钥的管理必须局限在企业内部。

如果数据存储在公共云环境中，那么在退出这个环境时，需要确保所有的数据（特别是 PII、SPI 数据或受到监管的数据）已经从公共云环境中删除，其中包括其他存储介质（如备份磁带）上的数据。本地管理密钥的做法很容易实现这个目标：只要从本地密钥管理中心删除相应的密钥即可，从而保证残留在公共云的任何数据再也不能被解密。

如果云服务提供商和消费者不严格执行各自的密钥管理流程，那么数据加密就没有什么实际意义。比如云服务提供商，如果职责混乱，大家可以随意访问密钥服务器和存储了加密数据的服务器，或者 DBA 能随意访问数据库中的个人密钥，那么数据加密就形同虚设。

同样，比如云服务消费者，如果存储密钥的终端设备本身就不安全（如移动设备）或者没有达到与加密系统同等安全级别的终端设备，这就像用木板做保险柜，那么这时加密数据无疑也是形同虚设。

围绕如何保护密钥本身，方案设计师通常的做法是采用密钥来加密密钥，只在内存中产生有效密钥，并且只存储加密过的密钥。这理解起来有点绕，其实就是把密钥当作普通的数据再次进行加密。