云数据库加密

    第一件事需要考虑加密数据的必要性。所有的数据库都具有限制访问的功能。某些合适的实现已经足以保护数据机密性。

    其他需要通过加密来保护存储在数据库中的数据的因素有：对数据库的特权用户（如数据库管理员）隐藏数据；为了遵守法律法规，数据拥有者不能通过帐户来控制对数据的访问（如使用共享账户）。

    当使用云数据库，特别是用到了数据库的SaaS解决方案时，数据库的正常功能将会降低，迫使数据库或云应用能访问密钥，除非能在密文上操作。

    数据加密会带来复杂度和性能上的成本。除了加密之外，还有一些别的有效方法：

    使用对象安全。使用SQL准许及废除声明去约束账户访问这些数据。这些账户中哪些准许访问的必须严格控制，以确保只有授权的用户才能访问。

    存储安全哈希值。存储这些数据的哈希值而不是直接存储这些数据，这能允许企业的程序能证明持有者有正确的值而不必实际存储它。

    密钥管理

    在公有云计算中一个很困难的过程就是密钥管理，公有云中的多租户模型造成其上运行的过程需要考虑密钥管理问题。

    最简单的应用案例是在公有云中有应用程序运行，加密数据的从企业内部流到公有云中，密钥仅供企业内部使用。有的加密引擎能够在数据流出时加密，在数据流入时解密。当公有云上的其他处理过程（例如批处理）需要访问密钥去解密数据时，一个使用密钥的应用程序将变得复杂。

    企业中使用者需要拥有他们自己的密钥，而不是一个能用于访问整个企业的单独的共享密钥。最简单的解决方法是采用一个加密引擎，基于实体身份信息为每一个用户或实体分配（或管理）一个密钥。以这种方式，为一个实体特别加密的任何信息将为那一实体所维护。如果一个群体内的实体需要共享数据，那么可以为管理群体访问的应用程序分配一个群体级别密钥，并在群体内的实体间共享密钥。密钥在企业内部应该像这一部分前面讨论的那样进行管理。

    当数据存储在公有云环境中，在停用这一环境时，证明所有数据（尤其是PII或SPI数据或隶属于法律法规的数据）已经从公有云环境中删去，包括其他媒体如复制盘等，将存在着问题；维护当地密钥管理能够从密钥管理系统中废除（或删除或丢失）密钥，以确保任何数据残留在公有云的数据不能被解密，来提供这一保证。

    如果云服务提供商和用户没有一个有效的密钥管理过程，加密数据就没有多大价值。 在服务提供方，需要关注的因素包括：服务器拥有加密的数据，同时访问密钥服务器缺少职责划分；数据库管理员能访问个人密钥；或数据库服务架构依赖于单一密钥。

    使用密钥加密密钥，在内存中产生加密密钥，以及只存储密钥服务器的加密密钥，都是能控制和保护密钥本身的有效的架构解决方案。构建任何解决方案时都应该考虑这些。 客户端密钥管理，在本身并不安全的设备（如移动终端）上保护密钥，或者这一设备没有得到同等级别的控制，都是需要考虑的因素。

    实践中的具体建议

    在企业应用的具体实践中，可以遵循如下一些有益的建议：

    当使用任何形式的加密或解密产品时，应用最好的密钥管理措施；

    如有可能，应该使用可信源中现成的技术，以得到最佳实践；

    使用最好的密钥管理实践，获取技术和产品用于加密、解密、签署，并从可信源中核实；

    尤其建议组织要维护他们自己的密钥或使用已经运营这种服务的可信密码服务；

    如果一个组织需要使用存在云中的数据运行分析或其他的处理，这个组织应该基于一个平台如Hadoop开发，从云中的数据源中导出数据；

    密钥的管辖范围能在个人或集体级别维护；

    集体访问的管理可以使用现成的技术，如DRM系统，或者其他运行在桌面或笔记本上，用以加密硬盘、文件和email消息的软件；

    为了维护最好的实践措施和通过审计，企业应该自己管理他们的密钥，或者使用来自于加密软件提供商那里的可信服务；

    现有加密技术中使用的密钥如DRM和硬盘加密产品应该在企业内部，使用密钥存储技术来集中管理；硬件安全调制应该用于存储密钥，以及处理加密操作如加解密、签名和修改等；

    企业使用者应该通过注册步骤去启用企业中的加密操作和其他处理，如能根据需要来访问加/解密钥的内容感知或保格式加密系统；

    基于身份认证的所有组件，将技术部署整合进公司系统，在处理流程中做授权决定使用捆绑加密操作来管理加解密过程的密钥；

    如有可能，使用现有的系统如E-DRM或数据防泄露（DLP）；

    将加密操作和密钥管理捆绑到公司的身份认证系统上，为组织提供最大灵活度的整合，以及使用组织已经了解、审计过的或检验过的技术。

    另外，对于云数据库的加密，可以参考如下实践建议：

    使用标准算法。不要使用专用的不规范的技术，专用加密算法没有被证明且容易被攻破；

    避免使用旧的不安全的加密标准如数据加密标准（DES）；

    使用对象安全。即使在加密的情况下，也应该坚持使用基本对象安全（SQL准许及废除声明）去阻止对数据的访问；

    不要加密主键或者索引列。如果加密主键，将必须加密所有的参考外部键。如果企业加密索引列，当企业曾是使用加密数值时，查询数据将会很慢；

    使用柱状的方法去加密（因为大数据系统使用这种方式）。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。