在 SLS 中分析ActionTrail跟踪投递日志

前言

操作审计（ActionTrail）是阿里云提供的云账号资源操作记录的查询和投递服务，可用于安全分析、资源变更追踪以及合规性审计等场景。阿里云客户在操作审计控制台可以查看近90天的操作日志，但在实际应用中，需要普遍分析基于全Region并且90天以上的操作事件，用于一些复杂的聚合查询分析。此时我们可以在ActionTrail控制台上创建跟踪将操作日志投递到指定日志服务（SLS），利用SLS的实时索引，查询分析数据的能力我们可以对全量的操作事件进行复杂的聚类分析查询。以下列举了一些结合SLS对行为分析，安全合规的一些使用场景。

AK泄漏了怎么办？

问题现状

某企业发现存在一些异常调用，怀疑是由于人事调动导致AK（AccessKey）的泄漏，那么如何去验证猜想？别着急，操作审计（ActionTrail）能够解决你的燃眉之急，在ActionTrail控制台完成投递跟踪到SLS之后，我们就可以借助SLS提供数据分析能力来分析AK的调用轨迹。

分析思路

具体的分析思路是我们可以获取AK调用来源IP的城市，一旦发现当前城市非企业所在地，那么就可以明确当前AK确实存在泄漏，需要通过RAM重新分配调整子账号权限。

查询分析语句

__topic__: actiontrail_audit_event and event.userIdentity.accessKeyId:<YourAccessKeyId> | SELECT count(1) as pv, city FROM (SELECT "event.sourceIpAddress" AS ip, ip_to_city("event.sourceIpAddress") as city FROM log) WHERE ip_to_domain(ip)!='intranet' GROUP BY city ORDER BY pv DESC

以上查询能够获取指定AK所产生调用的来源地址，并且给出具体的调用量，当然直接分析ip地址的网段也可以定位到指定AK是否存在异常调用。

是谁修改了ECS实例？

问题现状

企业上云之后对于内部云设施资源的审计越来越重视，云资源的安全合规操作也是企业上云的必经之路。对于企业内部云上资源的运维调度，以及相关的风险等级较高的资源调配操作，如何去获取指定资源（如ECS）的所有修改者，从中筛选得到非法来源的调用者，并以此进行责任追溯？以下提供了一种查询某段时间内高危操作的执行者。

分析思路

我们可以将关注的云产品以及执行操作按照执行者进行分组，统计每个云产业下任意一个API被谁执行以及执行的次数，从中筛选出一些非法的调用来源，并以此结果进行追责。

查询分析语句

__topic__: actiontrail_audit_event | SELECT serviceName, eventName, userName, count(1) as pv FROM (SELECT  "event.eventName" as eventName, "event.serviceName" as serviceName, "event.userIdentity.userName" as userName FROM log) WHERE (serviceName = <TargetServiceName> and eventName = <TargetEventName>) GROUP BY serviceName, eventName, userName

以上查询统计了对于指定云产品操作执行者列表，我们可以把TargetServiceName和TargetEventName分别指定为Ecs和DeleteInstances，如此一来便可以获取到所以执行Ecs实例的删除的操作者。定位到了Ecs实例的非法操作之后，我们需要获取非法的操作记录，以便于进行状态复原和问题修复：

__topic__: actiontrail_audit_event and event.serviceName:<TargetServiceName> and <TargetResourceId> and event.userIdentity.accessKeyId:<YourAccessKeyId>

自定义数据看板

随着云企业自身业务的快速发展，对于部分核心资源的调用频率周期需要产出完整的数据报表，用以资源容量的预估以及风险的预判。

需求分析

例如企业内部需要生成ECS实例创建近半年来的数据报表，通过分析同比以及环比来预测未来半年内资源扩充以便合理的控制和规划成本开销。

查询分析语句

__topic__: actiontrail_audit_event and event.serviceName:<TargetServiceName> and event.eventName:<TargetEventName> | select t, diff[1] as current, diff[2] as last_month, diff[3] as percentage from(select t, compare( pv , 2592000) as diff from (select count(1) as pv, date_format(from_unixtime(__time__), '%m') as t from log group by t) group by t order by t)

以上分析实现了一个数据报表，我们将TargetServiceName和TargetEventName两个变量分别指定为Ecs和CreateInstance，就能够获取出ECS实例每个月的创建次数，并且展示同比上个月的增长幅度。

可视化呈现

为了更加直观的展示数据变化趋势，可以折线图方式将效果进行呈现。

自定义仪表盘

日志服务可以根据仪表盘中的查询图表进行配置监控报警，实现实时服务状态的监控。除此之外我们也可以将自定义的统计图表添加到仪表盘中，以便实现定制化业务的实时监控，假设某企业需要对每个产品的日访问量做统计，当某个产品某日的访问量超过近60天的平均访问量的一定水位时，比如临界阈值到达150%时执行告警。

__topic__: actiontrail_audit_event |select a.serviceName, a.avg_pv, b.today_pv from (select serviceName, avg(pv) as avg_pv from (select "event.serviceName" as serviceName, count(1) as pv, date_format(from_unixtime(__time__), '%m-%d') as day from log group by serviceName, day) group by serviceName) a join (select "event.serviceName" as serviceName, count(1) as today_pv from log where date_format(from_unixtime(__time__), '%Y-%m-%d')=current_date group by serviceName) b on a.serviceName = b.serviceName

以上查询统计出各个云产品在近60天（时间区间可自定义）内的平均流量以及当天的实时的流量，我们可以折线图的方式进行呈现，当然我们可以添加过滤条件来排除不关注的云产品或者相关事件。接下来可以将该图标添加到已有的ActionTrail仪表盘中，并且新增对其的业务报警。

设置业务告警

在仪表盘中定位到新增的图标，点击右上角按钮新增告警，配置触发条件以及通知组即可完成，除此之外可以配置报警频率以及通知方式，具体配置可见SLS设置告警。其中$0表示第一条查询语句关联的原始图表数据，即每个云产品的当日访问量以及最近60天的平均访问量，$0.avg_pv即表示云产品最近60天的平均访问量。

结束语

本文旨在将SLS提供的实时索引，分析查询的能力与ActionTrail跟踪投递的操作事件相结合，对安全合规，行为分析，安全分析，资源变更行为追踪和行为合规性审计提供新的分析和构建思路。各位读者可以在上述提供的场景例子为借鉴，进一步引申，将操作审计的业务价值最大化。