什么是云端密钥共享？

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

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

加密介绍

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

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

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

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

采用授权服务器进行集中加密；

加密直接被嵌入到每个文件当中（分散加密）。

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

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

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

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

云端数据库加密

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

不想让有权限的人（如数据库管理员）看到记录信息。

法律规定一些记录必须要加密（如交易记录中的xyk信息）。

数据存储在数据库的一个 Schema 中，但是数据的主人无法控制访问这些数据的账号（比如多人使用的共享账号，每个人都不能随意修改账号密码）。

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

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

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

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

2）存储安全哈希值

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

密钥管理

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

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

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

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

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

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

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

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

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

因为这个文件是加密的需要解锁。

为了应对云端数据的威胁，对数据进行加密是一种有效的解决手段。为了确保安全性，这种加密必须是独立于云平台的，也就是说加密机制不能由云平台自己来提供，除非可以证明秘钥对云平台是完全不可见的。

风险无处不在，关键在于如何进行有效防范。

应对方法：

检测发现

可以利用云应用检测工具发现当前所使用软件(包括谁使用及使用频率)，同时确定业务数据是否涉入。采用云访问安全代理(简称CASB)解决方案要求供应商提供影子IT评估意见以了解当前企业内部的IT问题严重程度。

风险评估

对特定应用进行制裁、监控及制止，才能构建良好的云应用环境。利用评级系统确定云应用风险特点。保证此评级与陈述体系能够对影子IT进行分析并便捷地上传、匿名化、压缩并缓存日志数据，然后轻松交付自动化风险评估陈述。

用户引导

确保全部员工了解常见网络违法战术。降低未知威胁带来的影响。未知威胁永久存在，但杰出的安全意识训练有助于缓解其后果。定期发布提醒并组织季度训练，这样能够轻松并以较低成本削减恶意软件风险。

策略执行

安全策略执行必须拥有高粒度与实时性。这些要求在云应用领域可能较难完成。根据用户做法、所用工具及事务规则设定策略控制方案，从而立足于用户群组、设备、方位、浏览器以及代理为背景设计相关内容。考虑使用安全网关(内部、公有云或混合云)，同时配合具备数据丢失预防(简称DLP)功能的CASB解决方案。

隐私与治理

云环境中的数据需要使用特殊的以数据为中心的安全策略。加密机制在各类环境下皆有其必要性，但加密令牌机制在云安全领域的作用往往尤为突出。保证加密机制不会影响到应用中的查找、排序、报告以及邮件发送等功能。如果加密机制令上述功能的正常使用受到不良影响，则用户往往会想办法回避加密。

加密流量管理

对于需要过超过五成流量进行加密的行业(例如金融服务及医疗卫生)，基于策略的流量解密可能需要匹配专门的SSL可视化子系统及/或专用网络架构。

事件响应

需要立足于低层级进行云部署以建立直观的人机界面，从而实现事件响应(例如多种格式查找、可视化、过滤及集成第三方SIEM系统)。

---