跟着大公司学数据安全架构之AWSGoogle

近年来数据泄漏的事件层出不穷，网上可以搜到大量的数据泄漏新闻。从业者也都明白，数据泄漏只是一个结果，而原因有很多种，可能是一个越权漏洞，也可能是一个弱口令，有N种可能都会导致泄漏。传统的数据安全保障体系为什么没能有效遏制数据泄漏？是方法论出错了，还是执行不到位？带着这个问题，笔者研究了两家云服务厂商，试图从框架上寻找可借鉴的地方。结论是，有可借鉴的地方，但仍然不足以保证数据安全。

本文仅选择数据安全强相关内容，两家公司在云架构上比较相似，框架上都是通过IAM、KMS、加密、日志，并且都有专门针对数据安全的服务可供选择。

IAM本质上是一个信任系统，提供身份识别和访问管理功能。访问控制、角色、资源、审计、认证、日志、策略等都是这里要考虑的要素，对于大多数互联网公司而言，面上的东西其实都有，但缺少的是精细度。尤其体现在资源的细颗粒程度，例如我要对EC2进行IP分配，这就是一个资源，而IAM针对这个资源的策略可以有允许、禁止、申请等不同的资源级权限，再进一步，要能够根据不同的角色甚至标签进行。

诸如此类，要把资源做到细颗粒，表面上是对资源、角色、权限的框架定义，本质上是对整个系统底层基础统一化的要求。在一个底层不统一的基础上去谈框架，则要求框架有大规模的扩展性，对性能也是一个较大考验。

此外日志记录也是IAM的一项重要内容，从这里可以发现异常。

Google相对提供了另外一个IDENTITY AWARE PROXY，简称IAP，控制着云上的应用访问通道，也是BeyondCorp的作品之一。本质上是对应用的访问建立了一个代理的授权层，建立了一个应用级访问访问控制，而不是网络级的访问控制。

由于用户对上云的数据安全考虑，因此加密是云厂商的重点工作之一，这意味着你的数据在我的云上是加密的，而我无法窃取你的数据，因为只有你才拥有密钥。因此我会为你提供密钥管理服务、硬件加密模块服务，当然你也可以不信任我，我也支持你用第三方的密钥服务。

HSM/KMS除了对静态数据的加密，也可以用在其他的场景中。比如Web 服务器分载 SSL/TLS 处理，需要公有–私有密钥对和公有密钥证书，和每个客户端建立 HTTPS 会话，这时可以把计算工作让HSM承担，以达到SSL加速。再比如你在Oracle启用了加密，主加密密钥可以存在HSM中，因为HSM是个硬件，所以具有更高的安全性。

加密不是问题，实践中的问题在于密钥管理，密钥如何分发，怎样进行轮换，何时撤销，都是密钥的安全管理问题。两家云厂商都提供了自动更换密钥或到时提醒的功能，而且都能避免更换密钥时的重新加密。

KMS的密钥层次上和信任根：数据被分块用DEK加密，DEK用KEK加密，KEK存储在KMS中，KMS密钥使用存储在根KMS中的KMS主密钥进行包装，根KMS密钥使用存储在根KMS主密钥分配器中的根KMS主密钥进行包装，如果看晕了的话，直接看下图：

除此之外，amazon还单独提供了一个Secrets Manager的工具，用来管理各种key。例如有些开发会把数据库连接字符串写死在代码里，这样本身就有风险，再者如果需要更新凭证的话，也很容易漏掉某个程序。而Secrets Manager可以把凭证嵌入到应用里。同时不仅限于数据库连接串，也支持各种密码API密钥，密码的管理。

HSM/KMS是个基础设施提供密钥服务，真正的数据则在传输中、静态、使用中都进行了加密，Google和amazon都花了很多篇幅来说明加密。其中要点是：都是通过多层加密方式，多层加密能提供冗余数据保护，并可以根据需求选择最佳方法。而多层则包括了在存储块、设备层、备份等多层。但这仍然不能满足全部的要求，例如按照GDPR，存储系统使用的临时文件，进程失败的核心转储写入，也都是需要加密的。