亚马逊AWS官方博客
推出 CloudTrail Insights:识别并响应异常 API 活动
在云中构建软件可以从一开始就简化仪器系统的日志记录。借助 AWS CloudTrail 之类的工具,可以轻松跟踪对 AWS 账户和服务采取的每项操作,从而提供查找导致给定更改的事件的一种方法。但是,并非所有日志条目都有用。当一切都非常顺利时,这些日志条目就像是工厂车间中稳定、令人放心的机械嗡嗡声。当开始出现问题时,嗡嗡声会使您更难得知哪台设备出了问题。大型软件系统也是如此:日志数据量可能很大。筛选这些记录来查找可操作信息非常繁琐。通常需要大量的定制软件或定制集成,并且在添加新服务时可能导致漏报和警报疲劳。
这就是软件自动化和机器学习可以提供帮助的地方。今天,我们将在所有商业 AWS 区域中推出 AWS CloudTrail Insights。CloudTrail Insights 自动分析 CloudTrail 路径中的写入管理事件,并提醒您异常活动。例如,如果 TerminateInstance
事件的增加与既定基准有所不同,则将其视为 Insight 事件。这些事件使查找和响应异常 API 活动比以往更加容易。
启用 AWS CloudTrail Insights
CloudTrail 跟踪用户活动和 API 使用情况。它提供了 AWS 账户活动的事件历史记录,包括通过 AWS 管理控制台、AWS 开发工具包、命令行工具和其他 AWS 服务执行的操作。随着 AWS CloudTrail Insights 的推出,您只需单击几下即可启用机器学习模型,检测这些日志中的异常活动。AWS CloudTrail Insights 将分析历史 API 调用、识别使用模式并为异常活动生成 Insight 事件。
您还可以使用 put-insight-selectors
命令在 AWS 命令行界面 (CLI) 的路径上启用 Insights:
$ aws cloudtrail put-insight-selectors --trail-name trail_name --insight-selectors '{"InsightType": "ApiCallRateInsight"}'
启用后,CloudTrail Insights 会将事件发送到路径详细信息页面上指定的 S3 存储桶。与其他 CloudTrail Events 一样,事件也将发送到 CloudWatch Events,并可选发送到 CloudWatch Logs 日志组。这提供了警报选项,从响应 CloudWatch 事件的复杂规则到自定义 AWS Lambda 函数。启用 Insights 后,将分析路径的历史事件。发现的异常使用模式将在 30 分钟内显示在 CloudTrail 控制台中。
使用 CloudTrail Insights
在本文中,我们将介绍一些来自 AWS 控制台的 AWS CloudTrail Insights 事件。如果您想通过 AWS CLI 查看 Insight 事件,可以将 CloudTrail LookupEvents
调用与事件类别
参数配合使用。
$ aws cloudtrail lookup-events --event-category insight [--max-item] [--lookup-attributes]
快速浏览 CloudTrail Insights 列表,会跳出 RunInstances
事件。运行更多的 EC2 实例成本高昂,而且我肯定搞错了配置,以至于创建了比之前更多的实例,因此,我想详细了解一下。让我们将列表筛选为只有这些事件,然后看看我们可以从 AWS CloudTrail Insights 中学到什么。
让我们深入了解最新事件。
这里我们看到,在一分钟内,RunInstances
API 调用量激增。通过 Insight 图形,我们可以将原始事件看作 JSON。
{
"Records": [
{
"eventVersion": "1.07",
"eventTime": "2019-11-07T13:25:00Z",
"awsRegion": "us-east-1",
"eventID": "a9edc959-9488-4790-be0f-05d60e56b547",
"eventType": "AwsCloudTrailInsight",
"recipientAccountId": "-REDACTED-",
"sharedEventID": "c2806063-d85d-42c3-9027-d2c56a477314",
"insightDetails": {
"state": "Start",
"eventSource": "ec2.amazonaws.com",
"eventName": "RunInstances",
"insightType": "ApiCallRateInsight",
"insightContext": {
"statistics": {
"baseline": {
"average": 0.0020833333},
"insight": {
"average": 6}
}
}
},
"eventCategory": "Insight"},
{
"eventVersion": "1.07",
"eventTime": "2019-11-07T13:26:00Z",
"awsRegion": "us-east-1",
"eventID": "33a52182-6ff8-49c8-baaa-9caac16a96ce",
"eventType": "AwsCloudTrailInsight",
"recipientAccountId": "-REDACTED-",
"sharedEventID": "c2806063-d85d-42c3-9027-d2c56a477314",
"insightDetails": {
"state": "End",
"eventSource": "ec2.amazonaws.com",
"eventName": "RunInstances",
"insightType": "ApiCallRateInsight",
"insightContext": {
"statistics": {
"baseline": {
"average": 0.0020833333},
"insight": {
"average": 6},
"insightDuration": 1}
}
},
"eventCategory": "Insight"}
]}
在这里,我们可以看到基线 API 调用量为 0.002。这意味着通常每 500 分钟大约有一次对 RunInstances
的调用,因此我们在图中看到的活动肯定是不正常的。通过单击 CloudTrail Events 选项卡,我们可以查看分组到此 Insight 事件中的各个事件。这看上去可能是正常的 EC2 自动扩展活动,但我仍然想深入了解和确认一下。
通过在此选项卡中展开事件并单击“查看事件”,我可以直接访问 CloudTrail 中的事件以获取更多信息。在查看了事件元数据以及相关的 EC2 和 IAM 资源后,我已经确认,尽管这种行为不正常,但不必担心。看起来自动扩展实现了预期效果,并且创建了正确的实例类型。
注意事项
在开始之前,您需要了解一些重要的注意事项:
- 针对每种 Insight 类型每分析 100,000 个写入管理事件,CloudTrail Insights 的成本为 $0.35。在启动时,API 调用量详情是唯一可用的类型。
- 活动基准的范围是 CloudTrail 路径在其中运行的区域和帐户。
- 帐户首次启用 Insights 事件后,如果检测到异常活动,则可以预期在启用 Insights 的 36 小时内收到第一批 Insights 事件。
- 在发现新的异常活动时,会进行记录,在大多数情况下,会在 30 分钟内将 Insight 事件发送到目标 S3 存储桶和 AWS 控制台。
如果您有任何疑问或功能请求,请告诉我,祝您快乐构建!