腾讯云操作审计 CloudAudit：半夜删掉云服务器的那个人是谁

凌晨两点，一台跑了三年、承载着订单库的云服务器 CVM 突然消失，控制台里只剩一行"实例已退还"的冰冷记录。客户早上发现时，第一反应是催我抢修，而我做的第一件事却是打开腾讯云操作审计 CloudAudit。说实话，这类事故里，机器被"黑"掉的其实不多，被有权限的人顺手点掉的真不少；最难回答的问题从来不是"怎么恢复"，而是"到底是谁干的"。我在客户现场见过太多次"平时不记、出事无证"的窘境，所以这篇不绕弯，把 CloudAudit 到底记什么、该盯哪些事件、怎么让每条操作追到人、以及出事后的取证顺序讲清楚。这类问题我几乎每个月都会被问一次，答案往往不在出事的机器上，而在那本"登记簿"里。

CloudAudit 的定位：它到底记了什么

CloudAudit 是腾讯云原生的操作审计服务，核心就一句话：把账号下发生的操作行为，逐条记录成事件。你在控制台上点的每一个按钮，最终都会变成一次 API 调用，而这次调用是谁发的、从哪个 IP、用哪个身份、动了哪个资源、结果是成功还是失败，都会落成一条事件。它不是防攻击的设备，更像一本"谁来过的登记簿"。它的价值不在出事当天的抢修，而在平时就把"谁动过什么"钉成可查的记录。

它和云日志服务 CLS 不是一回事，这点常被混。CLS 更偏应用与业务日志的采集、检索、投递，管的是"程序在说什么"；CloudAudit 专注"操作与调用"这条线，管的是"人在动什么"。我一般把两者搭配起来用：出了事，先在 CloudAudit 里定位"谁在什么时候动了什么资源"，再回到 CLS 去看"那一刻业务侧发生了什么异常"，两条线一拼，因果基本就清了。

还有个细节很多人踩过坑：CloudAudit 的记录有留存窗口，超出窗口会滚动清理，它默认更偏向"近况回放"，不是"历史档案"。所以指望它自带长期保存是不现实的，想让记录活得久，必须主动把事件投递出去，这一点我后面单开一段讲。

在检索上，CloudAudit 支持按时间段、事件名称、资源类型、操作者身份这些维度筛选。我的习惯是先把范围压到"出问题那两三个小时"，再按事件名过滤关键动作，比一页页翻高效得多。事件里通常还能看到请求参数和返回结果，删除类操作会带上被删资源的标识，这对还原现场很有用——很多时候，"操作成功还是失败"这一栏，直接决定了你该去恢复什么。

事件维度：写操作才是要盯的那一类

审计事件里有一个维度特别关键——写操作和读操作要分开看。写操作会改状态：创建、删除、退还实例、改安全组、改访问密钥、调策略；读操作只是查看。

• 写操作：必须全量盯着，尤其是删除类、权限类、网络类，这三类出事最狠。

• 读操作：数量比写操作大得多，不必条条告警，但涉及访问密钥查看、对象存储列举这类敏感读取，要单独留。判断标准很简单：这个动作被别人做一次，你会不会紧张？会，就值得记。

回到半夜删机那个例子，我的排查顺序是固定的：按时间倒序，先圈出"退还/删除资源"这类写操作事件，再顺着事件看身份、来源 IP、时间戳和请求参数。有一次帮客户定位到，问题根本不是外部入侵，而是某个已离职同事的子账号密钥没回收，脚本里带的清理逻辑被误触发。你要问这跟审计有什么关系——如果当初没开审计、没留记录，我连这条线索都摸不到。

我还整理过一份"高危写操作清单"，每次做审计巡检都会挨个过一遍：退还或销毁实例、删除云硬盘与快照、修改安全组规则、变更 CAM 策略与子用户、创建或禁用访问密钥、关闭对象存储的版本控制、调整数据库访问白名单、修改负载均衡监听器。这些动作本身可能是正常运维，但共同点是——一旦被恶意或误操作执行，后果都不轻。这份清单我自己每季度跑一遍，花不了多少时间，却能提前发现几处悄悄松开的口子。审计的价值不是"看见了"，而是"看见了还能对得上人、对得上时间"。

让"是谁"落到实处：子账号加 CAM

CloudAudit 记的是"哪个身份发起了调用"，前提是每个操作都有独立身份。如果全公司共用主账号的访问密钥，审计里所有操作都会显示成同一个人，那这堆记录等于白记。我给客户的铁律是：用 CAM 给每个人开独立子用户，按最小权限授权，密钥绝不共享、绝不写进代码仓库。

角色 授权方式 密钥归属 审计里能看到

运维值班 子用户 + 只读常见资源 个人独享 具体到人

变更执行 子用户 + 指定资源写权限 个人独享 具体到人

自动化脚本 专用子用户 + 最小策略 独立密钥 具体到脚本

财务只读 子用户 + 账单只读 无需密钥 具体到人

主账号 仅保底 + 强制 MFA 不外发 尽量不用

这里顺带把账号合规说透：市面上流传的"腾讯云实名账号买卖"，看着省事，实则是把业务挂在别人的实名主体下。一旦出事，审计里根本追不到真正的责任人，还可能牵涉违规。正规路径永远是用自己的主体开一个合规的腾讯云实名账号，再在其上搭 CAM 子账号体系，把权限拆开、把密钥管住——这才是既安全又合规的替代方案。

再补两点实操：给高权限子用户强制开启 MFA，避免密码一泄就被人登进去；能用临时密钥（STS）的地方就别发长期密钥，临时凭据到期自动失效，天然压低泄漏窗口。至于权限巡检，我建议每个季度拉一次 CAM 授权清单，把长期不用的子用户和宽得离谱的策略挑出来收一收——权限是会"长胖"的，没人盯着只会越来越松。

访问密钥泄漏后：取证与止损的顺序

密钥泄漏是我最不愿半夜接到、却又接得最多的一类电话。顺序错了，证据就没了，业务也可能被你亲手搞崩。下面这个顺序我用了很多次，照着走基本不会翻车。

先留证，后动手：第一时间导出一段时间窗的 CloudAudit 事件，重点看该密钥被调用的异常时间点、来源 IP 和调用动作，先把证据握在手里。

先禁用，后删除：把泄漏密钥先停用而不是立即删掉，确认没有正常业务依赖，再审慎删除。

顺藤摸瓜：查这个身份近期还有哪些写操作——是否新建了子用户、动了安全组、开了公网端口，攻击者常借被控身份做二次布局。

修复入口：密钥到底怎么出去的，从代码仓库、镜像、聊天记录里找根因，不换入口等于没修。

被攻击者利用密钥调用 API，通常有几个可识别特征：短时间内高频调用、来自明显非办公网段的 IP、突然创建计费资源（挖矿类的典型动作），以及批量列取对象存储。这些在 CloudAudit 里都有痕迹，前提是你提前开了审计、并且留够了时间窗。临时抱佛脚是查不到的。我一般会把这些特征做成一条告警规则，命中就推送，别等人去看。

补一个容易忽略的取证细节：导出事件时把"调用来源 IP"和"用户代理"一起看。同一个身份、突然从两个相隔万里的 IP 交替调用，基本可以判定密钥被复制外流了；而调用动作集中在你平时根本不用的接口上，说明对方正在做探测。这些判断不需要什么高深工具，需要的是你手里有一份足够长时间窗的记录，能拿日常行为做对比。

审计记录怎么长期留存

把 CloudAudit 事件投递到 COS 或日志服务做长期归档，是我给客户的标配动作。投递到 COS 的好处是成本低、可设置生命周期、能做账号隔离，最好放在另一个受控账号、或一个"只写不读"的存储桶里，防止攻击者拿到权限后反手把审计删了。投递到日志服务的好处是检索方便，能按关键字配置告警，异常动作能第一时间推出来。我自己一般两者都用：热数据放日志服务便于随时查，冷数据放 COS 便于长存。说到底，日志一旦被删就再也回不来，所以存储侧的删除权限必须单独收紧，别和业务权限混在一起。另外，定期把导出的审计记录做一次归档检查，确认投递任务没有静默失败也很关键——投递一旦断了没人发现，等于又退回没留存的起点。

还有一点，投递链路本身也要防单点：投递用的那个身份最好只具备"写入目标存储"的权限，拿不到删除权限，也碰不到业务资源。这样即使业务账号整个失守，审计记录依然在另一个账号里躺着，攻击者删不掉。我见过客户把审计桶的删除权限和业务权限混在同一个策略里，结果真是"一锅端"，这个错误代价太大。留存的意义，是"事后能追"和"合规能交差"两头都得够。

FAQ

Q：CloudAudit 是默认就开着的吗？

A：事件记录通常会随操作自动产生，但长期留存和告警都要自己配投递；你不主动做，过了留存窗口就真查不到了。

Q：只靠 CloudAudit 能不能满足等保的审计要求？

A：它是重要的技术支撑之一，但等保审计还牵涉日志留存时长、审计记录防篡改等要求，要结合日志服务和存储策略一起设计，单靠一项不够。

Q：子账号很多，管理会不会更乱？

A：用 CAM 用户组加策略模板批量授权，配合定期权限巡检，其实比全公司共用主账号清晰得多，谁越权一眼能看出来。

Q：密钥可能泄漏了，先删还是先查？

A：先禁用并留证，再排查业务依赖，最后才删除。顺序颠倒，往往既丢了证据、又把业务搞崩。

Q：审计记录到底要留多久？

A：按行业规范和等保要求来设计，关键不是临时拍一个数字，而是做到"能留、可查、防篡改、防删除"。

结语

审计不是出事才想起来的事。今天就去 CloudAudit 里看一眼最近一周的写操作，确认三件事：每个能改你资源的人是不是都有独立身份、密钥有没有被共享、记录有没有做投递。这三件小事做完，半夜那通电话再打来时，你至少能稳稳说出"是谁"。审计这东西平时看不见价值，出事那天却是唯一能说话的证据；它不解决所有问题，但没有它，很多问题你连问都问不出口。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。