4. 告警触发条件设计：异常访问频率、批量下载、权限变更、未授权操作
告警触发条件怎么设计？说白了，就是告警阈值该多重才合适。
这个度很难拿捏。阈值设得太低，告警洪峰能把人淹死；设得太高，真正的泄露可能已经结束你才发现。我个人习惯，把告警条件拆成四个维度来考虑。每个维度都能独立产生告警，又可以组合出更复杂的检测逻辑。
4.1 异常访问频率
频率异常是最基础的告警维度。核心思路是：在短时间内，同一个主体对 Secrets 的访问次数远超历史基线。
我在项目中遇到过这样的情况：某个 CI/CD 节点平时每分钟只拉取 2-3 次密钥，某天突然变成了每秒 300 次。这个问题的要害在于——不是人的操作，而是某个后门脚本在疯狂轮询。
核心检测逻辑：
- 滑动窗口统计： 固定 1 分钟 / 5 分钟 / 15 分钟窗口，统计访问次数。
- 基线对比： 与同时间段过去 7 天的 P95 访问量对比，超过 3 倍即触发。
- 时间衰减权重： 突发性尖峰比稳定高频更值得关注。
你想想看，一个正常业务 Pod 每天访问密钥的次数是有规律的。突然 5 分钟内访问了 1000 次 同一个 API ，这明显不正常。但要注意，如果你的服务正在经历流量高峰，这种告警就容易误报。
我的个人经验： 把全局频率告警和单密钥频率告警分开配置。全局告警用来抓批量扫描，单密钥告警用来抓针对特定高敏感密钥的异常查询。
阈值怎么设？我会用 "3-sigma" 原则作为初始值，然后观察两周，根据误报率调整到合理的基线。说白了，这是一个迭代的过程，别指望一次配置就能完美。
4.2 批量下载
批量下载比频率异常更凶狠。频率异常可能是扫描，但批量下载基本可以确定是一次成规模的泄露。
批量下载检测的核心在于：短时间内拉取大量不相关的 Secret 值。 而不是反复拉取同一个密钥。
我记得有个经典案例：攻击者通过一个被攻破的 Jenkins Slave 节点，在 3 分钟内调用了 GetSecretValue 接口超过 120 次，每次请求的都是不同的密钥。这种模式，正常的服务几乎不可能出现。
| 告警条件 | 检测维度 | 触发逻辑 | 响应策略 |
|---|---|---|---|
| 异常访问频率 | 单位时间访问次数 | 超基线 3 倍 | 告警 + 限流 |
| 批量下载 | 短时间内大量不同密钥 | 连续 10 次命中不同密钥 | 告警 + 阻断 |
| 权限变更 | 角色、策略、绑定关系 | 非变更窗口操作 | 告警 + 回滚 |
| 未授权操作 | 无权限调用 / 鉴权失败 | 连续失败 3 次 | 告警 + 封停令牌 |
注意：这里有一个容易被漏掉的细节。
批量下载告警要结合 滞后分析。攻击者可能会刻意放慢拉取节奏来绕过频率检测，比如每分钟只拉取 1 个新密钥。这种慢速“扫表”行为，必须配合用户行为分析（UEBA）模型来识别，单独靠固定阈值很难抓。
我建议对高价值密钥（比如 Root 凭证、数据库主账号）单独建立一个“亲和度”模型——如果某个主体拉了 A 密钥，又拉了 B 密钥，再拉 C 密钥，而这种组合在历史数据中从未出现过，立即触发高级告警。
4.3 权限变更
权限变更告警，我把它叫做“后院起火预警”。因为大部分 Secret 泄露的源头，其实都来自于权限滥用或权限误配置。
触发条件很简单：任何对 Secret 的读取权限、写入权限、管理权限的增删改操作，都需要触发告警。
但在实际落地时，你需要解决一个矛盾：权限变更有合法的（比如新员工入职、新服务上线），也有非法的（比如被攻击者修改策略给自己授权）。
避坑指南（我曾经掉进去过）：
- 只监控 "AttachRolePolicy" 事件，忽略了 "AddPermission"（S3 策略）和 "PutRolePolicy"。
- 没有关联 发起主体 的行为上下文。一个长期未使用的 IAM 用户突然修改了自己的权限，这比活跃管理员的操作可疑得多。
我通常把权限变更告警按照 风险等级 分成两档：
- 高危： 给非管理员身份添加 Secrets Manager 的读写权限；给跨账号角色添加 Secrets 读取权限。
- 中危： 修改 Secret 的轮换策略；修改 KMS 密钥授权。
其实权限变更最难的是去重。同一个变更操作可能会产生多条 CloudTrail 日志（事件发起、策略更新、策略挂载），你得设计好聚合逻辑，否则告警数量会膨胀到失控。
4.4 未授权操作
未授权操作告警，是最后一道防线。它的触发条件是：一条访问请求被服务端明确拒绝（AccessDenied），然后紧接着再次尝试。
这里有一个关键点——为什么要等到 再次尝试？
因为单次拒绝可能是配置错误、网络抖动、临时凭证过期。连续失败，才有攻击者在试探的嫌疑。
你想想看，如果一个 IP 在 10 分钟内对 Decrypt 操作返回了 5 次 AccessDenied，然后突然有一次成功，这说明什么？攻击者在逐步调整策略，直到找到正确的权限路径。这种模式必须引起重视。
我的检测框架：
- 聚合维度： 按源 IP + 目标 Secret + 操作类型
- 时间窗口： 5 分钟
- 阈值： 连续拒绝 ≥ 3 次，且拒绝与成功的比例超过 1:10
- 动作： 触发告警，同时自动为该访问凭证添加“临时受限”标签
但要注意，不要一棍子打死所有人。合法服务偶尔也会因为证书轮换产生 AccessDenied。这时候就需要结合上下文来判断——如果同一个服务在过去 24 小时内的 99% 操作都是成功的，突然出现了几次失败，很可能不是攻击，而是配置问题。
我曾经接手过一个案例，某团队误将生产密钥绑定到了测试集群的 IAM Role上。测试集群访问时一直 AccessDenied，但他们忽略了告警，以为是“测试环境而已，没关系”。结果攻击者通过测试集群的漏洞拿到了这个 Role 的临时凭证，直接在生产环境拉取了密钥。所以说，未授权操作告警不要只盯着攻击场景，配置缺陷同样值得关注。
4.5 综合告警编排：四维联动
上面四个维度单独拿出来都可以用，但真正好用的告警系统，不会孤立地看每个维度的信号。我会搭建一个告警权重评分机制：
四条触发条件同时命中，肯定是最严重的；但更多时候，是其中两三条同时触发。
- 异常访问频率 + 批量下载： 分数 9/10，立即阻断
- 权限变更 + 未授权操作： 分数 8/10，告警 + 暂停该用户的访问
- 仅异常访问频率： 分数 4/10，告警 + 限流
- 仅单条触发： 标记为观察，降低优先级
说白了，告警触发条件设计不是简单地把阈值写死在配置文件里。它需要你理解业务、理解攻击模式、理解误报成因。我每三个月会复盘一次告警数据，看看哪些告警被忽略了却最终导致了问题，哪些告警一直没人看。然后调优，再复盘，再调优。
上面这张图就是我常用的四维联动逻辑。四个维度的信号会输入到评分器，由评分器根据多维度的加权评分加上下文关联分析，算出最终风险分数。不同分数走不同的响应路径。这套逻辑，现在已经是我团队的标准配置了。