云资源一多，“这个配置是谁改的”就很难回答。服务器突然关机、安全组莫名放开端口、子账号误删数据库，这类事故最耗时的通常是找人、找时间、找原因，修复反而是后面的事。阿里云操作审计（ActionTrail）会把账号下的操作记下来，出了问题可以直接查到操作人、时间和来源。下面说清楚它记什么、怎么配，并通过两个示例场景看它在排查中怎么用。
阿里云审计记录什么
审计记录的是对云资源发起的操作事件，包括在控制台点击、通过 SDK 或 API 调用，以及其他云产品触发的服务级操作。一条事件通常包含以下信息：
- 操作人：主账号、RAM 子账号或角色。
- 操作时间：精确到秒的时间戳。
- 操作来源：源 IP 地址，以及用户代理，比如控制台或某个 SDK。
- 操作对象：事件名称，例如关闭实例、修改安全组规则。
- 请求和结果：请求参数，以及操作是成功还是失败。
审计只记录“做了什么”，不记录资源内部的业务数据。它能告诉你谁删了数据库，却还原不出数据库里的内容。业务数据的备份和留存仍需要另外做。
事件历史与追踪：两种用法
实际使用时，可以把审计分成两层来理解：
- 事件历史：控制台默认提供的近期查询，适合临时排查。查询窗口有限，超过时间的记录需要通过其他方式留存。
- 追踪（Trail）：手动创建的持久化配置，可以把事件投递到对象存储 OSS 或日志服务 SLS，用于长期保存、检索和告警。
两者的差别主要在用途。偶尔查一次，事件历史够用。如果要满足等保、审计或内部合规要求，就应该创建追踪，把日志投递到独立存储里。
案例一：ECS 实例在夜间被关机（示例场景）
某电商团队周一早上发现，核心订单服务的 ECS 实例处于停止状态。运维同事最初怀疑宿主机故障，但监控里没有硬件告警，这个方向很快就排除了。
接下来的排查比较直接：
- 打开操作审计控制台，按资源 ID 和事件名 StopInstance 过滤。
- 查到周日 23 点 40 分有一条记录，操作人是名为 deploy-bot 的 RAM 子账号，来源 IP 指向一台已经下线的测试机。
- 对照该子账号的 AccessKey 使用记录，确认它在一次脚本迁移后仍保留着生产环境的权限。
原因是一个过期的自动化脚本误调了停机接口。团队随后轮换了该子账号的密钥，收回不必要的生产权限，并把 StopInstance 这类高危事件接入告警。权限如果没有收干净，老脚本就会一直是隐患，这一步比找出是谁更关键。
案例二：安全组端口被放开（示例场景）
另一家公司的安全团队在日常巡检中发现，一台数据库相关的安全组出现了 3306 端口对 0.0.0.0/0 开放的规则。
只看当前配置，无法判断这条规则什么时候加上、是谁加的。团队使用已投递到日志服务的追踪数据，以 AuthorizeSecurityGroup 作为事件名检索，得到以下信息：
- 规则是在两天前的工作时间添加的。
- 操作人是某开发人员的子账号，来源 IP 属于公司办公网段。
- 同一时段，该账号还调用过多次查询类接口，说明操作者当时在排查连接问题，更像是误操作，而不是入侵。
确认之后，团队删除了这条规则，并在 SLS 中设置告警：一旦出现对 0.0.0.0/0 的授权事件，立即通知安全值班群。此后三个月内，这类误操作没有再发生。
配置步骤
- 创建追踪：在操作审计控制台新建追踪，选好覆盖范围，是单账号还是资源目录下的多账号。
- 选择投递目标：需要长期保存的，投递到 OSS 并设置生命周期规则；需要检索和告警的，同时投递到 SLS。
- 设置权限：审计日志的读取权限应单独授予安全或审计角色。普通运维账号不必拥有删除追踪的权限。
- 配置告警：优先覆盖删除实例、修改安全组、变更 RAM 权限、禁用日志等高危事件。
- 定期验证：每季度抽查一次投递是否正常，避免日志悄悄中断而没人察觉。
几个常见误区
- 以为开了就一定完整：追踪需要明确覆盖的地域和账号，遗漏的区域不会自动被记录。开完之后对照一下资源清单，会踏实很多。
- 日志只存在同一账号里：攻击者拿到管理员权限后，可能会一并删除日志。把投递目标放在独立账号，或加上锁定策略，会可靠很多。
- 只看记录，不做告警：事后追溯有价值，但删实例、开端口这类操作，最好在发生时就能被发现。
小结
阿里云审计解决的是“谁在什么时候做了什么”这个问题。临时排查用事件历史就够了；要做长期合规和自动告警，就需要建立追踪，并把日志投递到独立存储。配置完成后，定期确认投递和告警仍在正常工作。
