我的aws學習心得

背景

我們將大量數據文件放在S3上，有一天突然發(fā)現一個重要文件不見，是誰刪除的什么時候刪除的？我想知道啊！
S3 server access log沒開，到就去Cloudtrail看看吧！
可是去Cloudtrail event history查，竟然沒有？是的，默認Cloudtrail是不記錄文件刪除日志的，必須手動創(chuàng)建一個Trail，將S3 Data Event選上才有??！如下圖，畫圈的地方要選上的！

Screen Shot 2022-09-07 at 10.54.03.png

但即使把日志都導出到S3里邊了，查詢起來那城堆的json文件也另人眼花！

推薦方法

使用Guardduty S3保護功能，不需要自己保存日志，Guardduty使用Machine Learning方法就能幫你分析日志與IAM 異常行為。

step 1 啟用Guardduty

快速多賬號的打開方法請見GitHub.
如果在平臺上一鍵開啟，別忘記把S3 保護點開，默認是關閉狀態(tài)，如下圖：

Screen Shot 2022-09-07 at 11.02.07.png

step 2 建立Baseline

由于機器學習算法需要一段時間學習你aws account中的log來建立baseline，請等待一個月左右。正好有30天免費的使用體驗。
當baseline成功建立后，Guardduty就會針對你aws account中的S3訪問情況進行多種異常報警，包括讀，寫，刪除。
下圖即為檢測到異常刪除行為的告警截圖：

Screen Shot 2022-09-07 at 10.30.31.png

step 3 在securityhub中集中監(jiān)控

由于Guardduty是region服務，如果使用多region，則建議進入security hub聚合region進行集中監(jiān)控,如下圖為aws managed insights：

Screen Shot 2022-09-07 at 11.10.06.png

當然支持自定義insight，可以單獨把“刪除S3 object“的行為做成一個custom insight!如下圖：

Screen Shot 2022-09-07 at 12.13.40.png

Securityhub綜合告警

當報警非常多的時候，比如我們有上百個AWS accounts，開了17個Regions，服務非常多，那么我們可以通過使用Securityhub聚合功能，將Guardduty檢測到delete活動同時沒有打開versioning備份的S3，自動找出來，生成一條Critical的告警，如下圖：

Securityhub S3數據丟失告警

操作方法請見my Github 或聯(lián)系您AWS的服務人員咨詢

更進一步

我們還可以進一步針對重點S3進行篩選，比如S3里的文件是“敏感數據”，“重要文件”，“關鍵資產”等情況，均可通過security hub的功能進行自定義。還可以通過使用security hub custom action來設計一些自動修復操作。

參考資料

【1】Amazon S3 Protection in Amazon GuardDuty
【2】impact-s3-anomalousbehavior-delete