AWS KMS 和 S3加密

AWS KMS服务 是AWS 提供的一个托管服务，用户能够用这个服务来建立和管理CMK，加密秘钥等等任务。值得注意的是，KMS的硬件平台是对多个用户开放的，尽管逻辑上他们彼此不能访问，可是若是特别在乎安全性的话，能够使用AWS HSM模块，这个就是指定的设备了，固然他的价格就贵了几十倍不止了。

下面看看如何使用KMS加密来增强咱们S3 Bucket的安全性。

例子：咱们打算建立2个用户James 和 Johnny，他们都属于同一个组，他们都具备S3的管理权限，以及对其余服务的ReadOnlyAccess的权限。咱们为James 建立 一个KMS的 Master Key，加密一个Bucket，而后咱们看看有什么效果。

首先，建立两个用户和一个组，分配对应的权限

接下来，咱们去KMS服务，新建一个Key。KMS里面咱们能够建立 Symmetric （一个加密的Key）或者 Asymmetric （公钥/私钥对）的Key，前者通常是用于EBS，S3加密等等，后者用于SSH远程访问等等。

在高级选项里面，他支持KMS，External和 CloudHSM。这里咱们选择KMS，也就是由AWS来管理的 Key material。

给一个标签和名字

选择 Key的管理人员为James，默认AWS的管理员天然是有权限管理的，这里是给其余IAM用户授予的权限

选择Key的用户为James。只有对应的用户能够访问被这个Key加密过的文件

最后生成一个CMK

KMS 用户管理的Key默认是没有rotation的，可是咱们能够打开，每一年会自动更新一次

接下来，建立一个新的Bucket用于测试

而后新开一个浏览器，用James登录。James是有S3的管理权限的，所以我能够上传一个txt文件。

默认这个txt文件是不能公网访问的，因此我把Block public access关掉

再Make Public

这样子就能够从公网访问了

到目前为止，都是正常的共享操做，没有涉及到任何加密。
下面，咱们在管理员帐号里面，修改这个Bucket的 默认加密设置，默认他的SSE是关掉的，咱们打开，同时选择加密方式为 SSE-KMS, 选择咱们本身建立的CMK

再回到James的帐号试试看访问咱们的confidential.txt文件，仍是能够正常经过公网访问，仔细看看这个文件的加密状况，发现没有加密。这说明了在咱们的Bucket上Enable SSE以前的文件，都不会自动加密！

做为对比，我再从新上传一个新的拷贝

看看这个新的文件的属性，发现他已经加密了

把这个新的文件也设置为Make Public，而后试着访问一下他的公网URL，失败。这是由于尽管咱们设置了Public，可是咱们使用了SSE-KMS加密，匿名访问用户没法解密这个文件，所以失败

接下里咱们切换到Johnny的帐号试试看。

Johnny去访问一下咱们的第二个文件，即便是直接Open，也显示失败，由于他不是咱们指定的Key User，所以没有权限访问被咱们的CMK加密过的文件

最后，咱们来看看删除Key有什么效果
假设James 对老板心怀不满，打算跳槽前报复一下社会，因而他把他全部的CMK都删了。 他能够选择 Schedule Key Deletion 。

AWS默认机制最低要求至少有7个工做日的冷静期时间来完全删除这个CMK，这个期间，管理员能够反悔以前的删除操做，由于一旦完全删除，那么被这个Key加密过的文件都没法访问了。

切换到管理员用户，访问一个这个加密过的文件，发现提示报错，这说明一旦开始删除的过程，即便是在冷静期，用户也没法访问被加密过的文件了

切换回KMS的界面，发现咱们能够 Cancel key deletion，取消以前的操做

工做流程中，为了预防这种恶意事件的发生，管理员应该配置一些预警方式。咱们能够经过Cloudtrail 发送Logs到Cloudwatch，而后Cloudwatch里面能够配置Event触发Lambda 或者直接经过Cloudwatch 的metric filter来发送SNS通知。或者，按期执行Config来检查Compliance，若是有异常，发送通知也是能够的。

CloudWatch Metric Filter 发送警报能够参考个人另一个博文 https://blog.51cto.com/beanxyz/2582202