基线检查工具_云资源安全合规基线自动化检查与配置

1 云资源安全合规基线需求和问题

云平台通过自服务接口提供了快速的资源供给方式，用户通过云平台console或者云管平台可以灵活按需快速构建云资源，甚至可以在几分钟构建自己的虚拟数据中心，资源的快速构建已不是什么难事，真正的难事在于如何有效治理好云资源，安全合规治理、标签治理、配置与安全基线检查等都不是什么容易的事。

如果前面有云管则可以挡一道，做一些配置限制、基线检查以及自动调整，但同时也失去了部分灵活性，并且也难以做到覆盖所有规范点。部分企业采用保姆式，云基础资源的申请均由云部门统一管理，包括创建和更新，通过一系列流程完成云资源最终交付，业务部门只需要能够通过堡垒机访问即可，这样其实工作都压在了云部门，交付也失去了敏捷性。

无论采用哪种方式，管理员都避免不了对云资源进行审计和检查，云基础资源管理员往往需要花费大量的时间去检查资源是否满足安全合规性、是否符合监管要求、是否遵循安全配置基线，常做的工作如检查资源的标签是否完备并且符合规范、安全组是否开放了高危端口、虚拟机是否使用了满足要求的黄金AMI、业务有没有考虑跨多AZ、磁盘是否加密、虚拟机是否直接挂弹性IP等等，虚拟机资源甚至还需要类似主机IDS工具做进一步OS级别的基线检查。

通常我们有如下几种方法来完成如上工作：

• 人肉检查。最土的办法，登录每个业务账号一个一个检查，这种方式费力不讨好，效率低下。

• 脚本轮询检查。通过调用云平台API检查资源是否合规及满足配置基线。这种方法在资源规模不大的情况下效率还可以，但很考验工程师的脚本能力，脚本维护起来也比较难。

• 云平台托管服务。这是比较推荐的方法，很多云平台都提供了资源的合规性检查服务，比如OpenStack的Congress服务、AWS Config服务等。

第一种方法没什么可说的，一两个账户可以这么玩，几十上百个账户基本不可行。第二种方法最大的问题是脚本开发和维护比较难，除非自己实现一套规则引擎框架，否则一个规则一个脚本，根本无法维护。

因此我们主要讨论第三种方案，以AWS为例简要介绍如何利用AWS托管服务做基线自动检查与配置。

2 安全基线自动化检查与配置相关服务简介

2.1 操作记录审计服务

安全基线自动化配置和检查从用户操作的时间点就已经开始了，云平台每一次在处理API调用时都会记录谁在什么时候执行了什么操作，每一次操作都会产生一个事件，事件中还会包含API调用的请求参数、创建的资源对象等信息。

这个功能不仅是监管以及安全审计要求，也是真正实现基于事件驱动的基线检查持续性和实时性的基础。

CloudTrail是AWS的审计服务，记录了所有通过AWS管理控制台、AWS开发工具包、命令行工具和其他AWS服务执行的任何操作。

2.2 事件与性能监控服务

光产生了操作记录事件还不行，要实现基线自动化配置和检查，还需要把这些事件监控起来，因此需要监控服务。监控服务不仅仅包括监控其他服务的性能指标，还包括监控所有的事件和日志。由于监控指标和事件往往都会很多，因此监控服务还需要支持根据一定的条件进行数据过滤，传统的监控服务如Zabbix、Prometheus都支持。

Cloudwatch是AWS的监控服务，支持根据规则过滤和监视各种事件。

2.3 Serverless计算

事件产生了并且也监控起来了，剩下最后一步就是真正的action。你可以订阅这些事件或者轮询发生的事件，然后自己起一个虚拟机部署handler服务来处理消费这些事件。但我认为最适合用来做action的是serverless计算，又称函数计算。

这是因为：

• 依次处理的事件通常都是独立无状态的，因此不需要后台服务和存储介质来专门保存状态。

• 我们处理的事件产生通常是无时间规律的，这种场景不适合起一个专门的服务轮询监视，不仅不能保证处理的即时性，还可能由于无事件产生出现服务器资源闲置，浪费计算资源。而基于事件触发的函数计算能最小粒度的实现按需按量计算、收费，省时省钱。

AWS Lambda服务是AWS的函数计算服务，支持各种事件触发，其中包括Cloudwatch。