多云密钥管理

安全地存储数据对于组织来说是一个重大的挑战，特别是在当今的云计算世界。而且，随着多云变得司空见惯，组织面临的挑战将会加剧。

在以往，组织内部使用的硬件安全模块(HSM)通过提供可防篡改的物理安全设施保护数据。同样，加密密钥管理(通常以服务的形式)有助于为密钥和密钥存储提供一个集中的、安全的存储库。

但是，云计算加剧了加密管理的挑战。传统加密方法的应用性稍差，这是由于云计算对技术底层的抽象程度较低。

例如，考虑将应用程序部署到IaaS中。操作系统下的所有内容都由云计算提供商提供。物理附加服务(如HSM)的实施不受客户的直接控制。因此，客户可以使用云服务提供商提供的硬件安全模块(HSM)产品。

对于PaaS和SaaS，硬件安全模块(HSM)是不可选择的，除非云服务提供商提供这些服务，其基础设施也超出范围。这意味着从客户的角度来看，无法通过云计算提供商使用API​​进行密钥管理服务。

许多云服务提供商提供了一些选项来帮助进行云计算加密管理。例如，微软Azure提供密钥库，AWS提供密钥管理服务，谷歌云平台提供云密钥管理服务。这些产品都可以帮助解决云计算提供商的云服务中的安全存储问题。

尽管这些云计算提供商提供的服务运行良好，但它们是特定于云计算提供商的，并且它们在提供给客户的接口方面都有所不同。

那么，当客户需要跨多个云计算提供商或混合环境的加密管理服务时会发生什么呢?IT领导者必须了解多云密钥管理如何应对这些挑战，以及如何成功实施它以保护混合和多云基础设施。

多云密钥管理涉及将密钥管理功能扩展到使用多个不同云平台中。云密钥管理即服务(KMaaS)模型应运而生，以快速配置基于云计算的服务。

根据云密钥管理即服务(KMaaS)产品的不同，可以通过密钥管理互操作性协议(从密钥管理服务器请求密钥的标准)通过使用云计算提供商提供的存根模块的REST API来请求密钥，例如使用密钥管理服务的公钥加密标准。

这样做的优点之一是它可以规范与密钥管理机制的接口。因此，使用基础密钥管理器的应用程序变得更加可移植。例如，应用程序组件用于请求访问密钥或其他机密的机制与当前托管在数据中心的应用程序相同，即使该组件可能会迁移到云平台。无论是出于灾难恢复或安全需求，还是将其迁移到公共云或在公共云之间迁移，都是如此。这可以通过运行环境之间移动的最小化或将数据导出到另一个位置时重新加密来增强安全性。

除了编程接口的标准化，KMaaS还规范了管理。其管理要素(例如记帐，批准流程，关键库存的维护和其他任务)是集中的。这可以实现集中可见性，并减少与管理人员进行管理工作流有关的成本。

IT领导者需要认识到，使用KMaaS工具并不意味着组织的使用是安全的。彻底审查和验证KMaaS选项是很重要的。

进入KMaaS市场时，需要注意以下4个事项：

• (1) 确保存储和检索密钥的机制从架构的角度有利于组织的使用。例如，计划部署Java应用程序的组织可能会优先考虑提供Java加密扩展的供应商。
• (2) 除了考虑与客户使用相关的性能和安全要求之外，还要考虑组件和应用程序将如何连接到服务。即使使用REST API(这是与服务接口的最普遍的机制)，也要从需要密钥的位置连接到密钥管理服务。在其他情况下，则不需要这样做。例如，没有直接出站连接的受保护的虚拟私有云。在这种情况下，客户需要找到一种机制，使其能够连接、代理请求、使用供应商提供的可以缓存或探索替代方法的组件。
• (3) 清点将存储在KMaaS中的现有数据。如果已经有本地密钥管理服务，需要检查其中存储了什么内容以及如何使用这些数据。这种事先的评估可以帮助IT主管设定期望值，了解转移使用的难度，并确定哪些访问方法最有效。除其他特殊要求外，还应特别注意如何验证和批准访问请求，以及如何处理密钥轮换和到期。
• (4) 认识到当前的多云密钥管理流程可能不同。需要注意无法或不需要更换现有组件的情况。例如，如今使用物理HSM的组织可能会发现存储在其中的密钥无法导出。而这是大多数HSM的默认设置，因为加密操作是在设备本身中执行的。这意味着密钥永远不会离开HSM的边界，而密钥管理器(即KMaaS或其他方式)的行为方式也不相同。一些组织可能具有合法的安全性或使用要求，而这是有利的。在根据业务风险和需求确定正确的方法时，了解密钥为何以保护密钥的方式进行保护是重要的要素。