亚马逊AWS官方博客
多账号环境下的密钥管理策略决策分析
概述
本文主要讨论了在云计算多账号环境下的密钥管理问题,并以亚马逊云计算平台以及Amazon Key Management Service (AWS KMS)密钥管理服务为讨论场景,从多个方面对自管理式和集中托管式的密钥管理方式进行了比较和分析,从而帮助企业进行密钥管理策略方面的决策。
问题
云计算的数据安全是企业关注的重点,无论是业务驱动或是合规驱动,数据存储加密都是业界公认的数据安全控制。加密离不开算法和密钥,在算法公开的场景中,密钥就成为关键安全变数,只有拥有了密钥才能对数据进行加密和解密。现实中,企业通常都拥有多个云平台账号,每个账号中都存在多种服务的加密密钥使用需求,多账号多服务给企业的密钥管理工作带来了复杂的挑战,是分而治之,还是集中管理?
现状
密钥管理就是创建密钥并授权服务或用户能安全的访问和使用密钥进行加密解密等操作,并能根据需要进行密钥的轮换、对密钥活动进行监控和审计、优化性能及降低成本等。而在多个账号的情况下,随着密钥的数量的增加和使用场景的多样化,选择更有有效的密钥管理方式成为了一个需要权衡多个变量的复杂决策问题。现实中,企业在多账号下的密钥管理主要有以下两种管理方式:
- 自管理式:数据拥有者在各自己的账号中管理各自的密钥。
- 集中托管式:所有密钥在一个集中的密钥管理账号中进行存储和管理,其它的账号中的使用者可以访问密钥管理账号中的密钥进行数据加密解密操作。
要素分析
具体到云计算平台环境,企业决策时必需要考虑云平台原生密钥管理服务的功能设计以及其与原生服务加密功能的整合方式对密钥管理所产生的影响。本文中以亚马逊云计算平台以及AWS KMS的密钥管理服务为例对影响密钥管理方式决策的几个重要因素进行了分析。
逻辑架构
在自管理式中,每个数据拥有者都各自管理自己所需的数据密钥,密钥存放于最靠近数据的位置,即在各自的亚马逊云账号中。其逻辑架构如下图所示:
而在集中托管式中,所有数据密钥由组织的密钥管理员进行集中管理,每个数据拥有者可使用密钥管理员提供的密钥进行数据加密解密操作。其逻辑架构类似下图:
责任分担
自管理式中,数据拥有者负责密钥管理的所有工作,包括密钥的创建、用户访问控制、密钥轮换、密钥权限控制等。而在集中托管式中,这些工作从数据拥有者转移到了云运维团队,云运维团队统一为多个账号提供密钥管理服务。
运维管理
自管理式中,随着企业账号数量的增加,容易发生管理不到位或是误操作的情况。集中托管式将原来由数据拥有者承担的管理工作收归集中到专门的密钥管理账号和角色上,集中托管式可以集中多个或所有密钥,为组织减少了总体的管理开销,同时具有专业技能的人员也有利于提升管理水平减少管理失误。集中托管式在运维上还更便于开展组织范围内的统一监控和事件响应,能配合扩展出更多解决方案来加强运维效率及安全。
性能影响
AWS KMS服务在单个云账号内有多种服务额度的限制,在集中托管中,整个组织中的资源账号所使用的密钥都将集中在一个账号中,这样相对自管理式中更容易达到这个账号的服务限额。比如:过多的密钥访问一旦达到了Amazon KMS服务的API调用速率限额,就会形成一个性能瓶颈,导致应用不能解密数据。为避免影响性能,企业要规划好用量。
账单成本
从成本上来看,集中托管式的密钥管理支持多个账号共用密钥,从而可以大大减少密钥数量,节省密钥创建的成本。从账单上来看,自管理式的账单由资源账号所承担,而集中托管式的账单由密钥管理账号来承担。
安全风险
自管理式的威胁暴露面更多。如果资源账号被攻陷,自管理式的密钥将暴露,加密的数据将不再安全。而集中托管式的密钥存在专用的安全账号中,在发生攻击后,企业可以阻断攻击者对密钥的访问,从而保护失陷账号中的数据不至于泄密。
合规要求
合规通常要求企业要符合责权分离和最小权限的安全原则。自管理方式比较容易出现密钥管理员和密钥用户的角色混用和过度授权的情况,多账号的合规管理比较困难。相比之下,集中托管式区分了多种角色并进行集中统一的管理,更容易实现相关合规要求。
决策工具
密钥管理方式决策时可以借助对比表和决策树等工具来辅助决策,以下给出一个使用对比表工具的示例,可供企业参考使用。
自管理式密钥管理 | 集中托管式密钥管理 | |
责任 | 数据拥有者 | 云运维团队,设置专门的密钥管理员角色 |
运维 | 多账号环境下管理难以统一运维 | 适合多账号的统一管理 |
性能 | 受账号服务额度限制,但性能稍好 | 受账号服务额度限制 |
成本 | 资源账号承担成本 | 密钥管理账号承担成本 |
安全 | 一般 | 更安全 |
合规 | 一般 | 更易合规 |
建议 | 一般情况下推荐 | 对安全和运维有较高要求的情况下推荐 |
两种方式没有简单优劣之分,借助上表中的多因素对比,能帮助企业进行决策。比如:某物流企业在对比后决定采取混合方式,对于基础设施服务采取集中托管式,而对业务采取自管理式,同时满足了运维和业务的密钥管理需求。
更多行动
密钥管理是数据加密中的基石,企业应该把密钥管理问题前置,在云安全设计初就对密钥管理进行思考和决策。无论采取自管理或是集中托管的密钥管理方式,后继仍需要采取更多的行动来持续完善。以下是一些共同的参考建议:
- 操作标准化:定义标准作业程序来指导和规范各个情景下的密钥管理操作。
- 方案的安全加固:设计预防性与检测性措施来保护密钥管理的每个环境不被利用或绕过。
- 易用性改进:简化和加快密钥管理的各个流程,比如通过Amazon Service Catalog提供自助密钥服务,或与企业工作流平台(如:Service Now)整合等。
- 可视化增强:提供密钥管理视图和报告。
- 跨云的密钥管理:考虑多云环境下的具体服务或应用(如云数据库等)的密钥管理问题,可作为多云企业的一个延伸方向。
除了以上共性建议之外,不同管理方式也有不同的行动方向。对于自管理式,特别要注意加入防范误操作的设计,比如:设计破窗访问密钥机制以防止错误配置而锁住密钥。对于集中托管式,可深挖组织级的安全特性,比如:利用Amazon Organizations的SCP来进行账号级的预防性保护等。
总结
通过本文,您已经了解在多账号情况下的自管理式和集中托管式这两种密钥管理方式,并学习了如何对基于Amazon KMS的密钥管理服务进行多因素的分析和对比。您可以利用类似的多因素分析方法来帮助您的密钥管理决策,期待收到您的反馈意见和建议,想要了解更多云计算安全内容您可以关注亚马逊云科技的博客。