我的aws学习心得
背景
我们将大量数据文件放在S3上，有一天突然发现一个重要文件不见，是谁删除的什么时候删除的？我想知道啊！
S3 server access log没开，到就去Cloudtrail看看吧！
可是去Cloudtrail event history查，竟然没有？是的，默认Cloudtrail是不记录文件删除日志的，必须手动创建一个Trail，将S3 Data Event选上才有啊！如下图，画圈的地方要选上的！
但即使把日志都导出到S3里边了，查询起来那城堆的json文件也另人眼花！
推荐方法
使用Guardduty S3保护功能，不需要自己保存日志，Guardduty使用Machine Learning方法就能帮你分析日志与IAM 异常行为。
step 1 启用Guardduty
快速多账号的打开方法请见GitHub.
如果在平台上一键开启，别忘记把S3 保护点开，默认是关闭状态，如下图：
step 2 建立Baseline
由于机器学习算法需要一段时间学习你aws account中的log来建立baseline，请等待一个月左右。正好有30天免费的使用体验。
当baseline成功建立后，Guardduty就会针对你aws account中的S3访问情况进行多种异常报警，包括读，写，删除。
下图即为检测到异常删除行为的告警截图：
step 3 在securityhub中集中监控
由于Guardduty是region服务，如果使用多region，则建议进入security hub聚合region进行集中监控,如下图为aws managed insights：
当然支持自定义insight，可以单独把“删除S3 object“的行为做成一个custom insight!如下图：
Securityhub综合告警
当报警非常多的时候，比如我们有上百个AWS accounts，开了17个Regions，服务非常多，那么我们可以通过使用Securityhub聚合功能，将Guardduty检测到delete活动同时没有打开versioning备份的S3，自动找出来，生成一条Critical的告警，如下图：
操作方法请见my Github 或联系您AWS的服务人员咨询
更进一步
我们还可以进一步针对重点S3进行筛选，比如S3里的文件是“敏感数据”，“重要文件”，“关键资产”等情况，均可通过security hub的功能进行自定义。还可以通过使用security hub custom action来设计一些自动修复操作。
参考资料
【1】Amazon S3 Protection in Amazon GuardDuty
【2】impact-s3-anomalousbehavior-delete
