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