咨询AWS环境下人工使用服务账号访问DB实例的告警实现方案

这个需求的核心坑点根本不是“怎么抓服务账号的访问”——而是别把正常的自动化程序化访问误报进来。大部分人一开始写规则直接抓“所有服务账号访问DB的事件”，最后告警里一半是跑批、一半是CI/CD，过不了一周整个告警规则就会被运维直接无视。

先搭好最小可用的数据采集底座 #

所有规则的前提是你能拿到足够细的访问上下文，别靠CloudTrail的粗粒度日志凑数：

• 对所有纳入监控的RDS/Aurora/自建EC2托管DB，开通数据库活动流（DAS），把全量登录事件、会话属性、源IP、用户名同步到CloudWatch Logs，日志粒度要细到能拿到客户端连接时上传的所有参数，比如PostgreSQL的application_name、MySQL的program_name。
• 给所有程序化访问的链路强制加固定连接标识：不管是Lambda函数、EC2上的跑批任务、EKS里的微服务、Jenkins流水线，在DB连接字符串初始化部分强制加写死的会话参数，比如统一加application_name=aws_svc_automation_<服务名>，这个改动零业务侵入，只要改一行连接配置就行。

写零误报的核心触发规则 #

告警必须同时满足所有下面三个条件才触发，少一个都不发告警，从根源上砍掉90%的误报：

• 登录DB使用的用户名/身份，在预先维护的所有服务账号白名单内（别用模糊匹配，把每个服务账号的DB用户名、对应的AWS身份ARN列成固定清单，定期同步更新）
• 当前会话携带的客户端标识，没有命中任何程序化访问的固定标识集合（也就是没有刚才统一加的aws_svc_automation_*标记）
• 当前访问的源IP，不在所有自动化运行环境的出口IP白名单内（把VPC NAT网关IP、EKS节点段、CI系统固定出口、Lambda直连的VPC端点IP全列进去）

补硬校验的兜底防漏机制 #

光靠上面的规则还是容易被绕过，比如有人手动改连接参数把application_name改成和自动化标识一模一样的，这时候要叠两层不依赖客户端传参的硬校验：

• 关联CloudTrail日志做身份溯源：如果这次获取DB凭证的操作（比如调用Secrets Manager取密码、从本地配置读取长期密钥），是由人类身份触发的——也就是走了SSO登录、跳板机交互会话、本地手动配置的长期密钥，而不是通过EC2实例元数据拿临时凭证、服务关联角色AssumeRole、Lambda执行角色调用的，不管客户端传什么参数，只要用服务账号登了DB，直接触发高优先级告警。
• 加会话特征校验：如果登录后的会话没有出现程序化访问的典型特征（比如固定间隔的健康检查查询、持续几小时的长连接、批量数据导出操作），反而出现人工操作的特征（比如短时间连续切换查询、交互式命令行的操作痕迹、单会话10-30分钟就断开），就算带了自动化标记，也要触发二次校验告警。

做降噪的收尾优化 #

别一开始就想搞大而全的严卡规则，先从最小交集的规则跑1个月，再根据真实的误报、漏报调整白名单：

• 把固定的人工运维场景加例外窗口：比如DBA每月做的服务账号密钥轮换、故障排查时人工用服务账号临时登库，提前把操作的时间窗口、源IP加到临时白名单，别为了抓异常把正常的运维操作全拦了。
• 告警触发的时候把上下文打全：包括触发告警的人类身份、源IP、使用的服务账号、对应的DB实例、会话里执行的前几条SQL，别只发一句“检测到服务账号访问DB”的空泛告警，不然过两周规则就没人看了。

内容的提问来源于stack exchange，提问作者Sreelal Raveendran Pillai