AWS加密与存储安全:KMS、Secrets Manager及数据静态安全解析
1. KMS与网络考量
KMS作为一种托管服务,完全驻留在集中式云网络中,这带来了一个独特的问题。为了执行加密功能,各个服务需要具备连接到AWS KMS的能力。这增加了安全问题的风险,因为原本可能不连接互联网的服务现在需要这样做。不过,网络安全问题可以通过VPC端点来解决。
1.1 KMS授权回顾
在领域驱动设计(DDD)的业务用例中,KMS授权有助于为服务提供更好的模块化。例如,在一个内部组织系统中,有两个相互通信的领域。一个领域负责跟踪员工工资的敏感信息,使用AWS KMS进行强加密,并限制只有该领域内的特定特权服务才能访问此密钥。另一个是报告领域,通常不需要访问员工工资的特权信息,但在某些特定情况下,需要聚合敏感信息并解密工资信息。
KMS授权允许在不临时向任何外部上下文开放密钥的情况下控制对密钥的访问。一旦业务用例结束,这些授权可以被撤销,从而实现访问控制。
1.2 KMS账户与拓扑结构
在AWS中,有界上下文通常遵循业务级别的领域。不同的领域可能会创建单独的账户以保持操作独立性。然而,依赖加密的服务可能难以分类,因为加密通常涉及上下文之间的通信,可能跨越AWS账户。幸运的是,CMK不受任何账户级别的限制,不同账户的服务可以继续使用CMK。
CMK的存放位置有两种选择:
| 选项 | 描述 | 优点 | 缺点 |
| — | — | — | — |
| 选项1 | 将CMK放在有界上下文内,与特定领域的AWS账户中的其他服务一起 | 易于保护单个领域,能清晰分离各个领域,无集中
超级会员免费看
订阅专栏 解锁全文
56

被折叠的 条评论
为什么被折叠?



