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