资源策略是什么？先看懂这一层
好，我们正式进入正题。第2章要聊的是资源策略的基本概念。说实话，很多团队做Secrets审计做到一半就卡住了，根本原因就是没搞明白「资源策略」到底管什么。我先给个最直白的定义：资源策略就是定义「谁能用什么资源、怎么用」的一套规则。
在云上，资源可能是对象存储里的一个桶、数据库的一张表、或者是Kubernete的命名空间。而Secrets——、数据库密码、TLS证书——本质上也是一种特殊资源。所以我做审计时，不会把Secrets和普通资源割裂开看，而是把它们放在同一套策略框架下检查。
1.1 Secrets的两种类型
我个人习惯把Secrets分成两类。为什么要分？因为它们的访问模式完全不同，审计时盯的重点也不一样。
| 类型 | 例子 | 访问场景 |
|---|---|---|
| 静态Secrets | 数据库密码、、SSH密钥 | 配置时注入，长期有效 |
| 动态Secrets | 临时令牌、JWT、STS凭证 | 运行时获取，短期有效 |
你在审计日志里看到静态Secrets的访问，往往集中在部署、配置变更这些环节。而动态Secrets的访问记录，通常跟业务请求走，频率更高、更分散。
1.2 资源策略的四个关键要素
讲到这里，我得抛出一个框架。不管是AWS的IAM策略、Kubernete的RBAC，还是自研系统的权限模型，你都可以用这四要素去套。搞懂了它们，审计日志里的每一行记录就都能对号入座。
- 主体（Principal）： 谁在访问？可以是用户、服务账户、角色、或者整个命名空间。
- 资源（Resource）： 访问的是哪个Secrets？用ARN、路径或者标签来定位。
- 动作（Action）： 执行了什么操作？读、写、删除、列举——每个动作的审计价值不一样。
- 条件（Condition）： 在什么环境下允许？IP范围、时间段、MFA状态、TLS版本……
你想想看，一条Secrets访问日志要是有价值，至少得把这四个字段对齐。缺任何一个，排查时就得靠猜。
1.3 最小权限原则的审计落地
「最小权限」这个词都快被说烂了。但在审计场景里，它有一个非常具体的定义：任何一次Secrets访问，都应该可解释、可追溯。
我记得有次帮客户做事后审计，发现某个只读账号居然有Secrets的删除权限。问下去才知道，是半年前一次权限配置迁移留下的遗留问题。这就是典型的「权限蒸发」——权限只增不减。
怎么在审计日志里发现这类问题？我建议你关注两个指标：
- 权限使用率： 90天内实际使用过的权限。
- 权限覆盖率： 已分配权限中，被审计日志证明实际使用过的比例。
# 伪代码示例：计算某个主体的权限覆盖率
used_actions = query_audit_log(principal, date_range)
granted_actions = query_policy(principal)
覆盖率 = len(used_actions) / len(granted_actions) * 100
# 如果覆盖率低于30%，说明分配了太多用不上的权限
1.4 资源策略的生命周期
策略不是写出来就完事了。它得经历：定义、部署、生效、审计、回收。很多团队在「回收」这一步做得特别差。
举个例子，一个服务下线了，但它的IAM角色或ServiceAccount还在。对应的Secrets访问权限也没清掉。这就留了一个后门。我在审计日志里见过最夸张的案例：一个三年前下线的测试服务，还在每天定时去读生产环境的数据库密码。原因是CronJob的密钥轮换脚本用了硬编码的凭证，且没人清理。
所以你在做审计时，一定要把「已下线资源」的访问记录单独拎出来看。这些日志往往最能暴露问题。
1.5 本章知识体系总览
下面这张SVG图，把上面聊的内容串起来了。你可以把它当成一张检查清单：每次审计前，先对照这张图确认有没有遗漏的关键环节。
你看，从策略中心出发，四个方向分别对应Secrets类型、四要素、最小权限和生命周期。审计日志里的每一条记录，归根到底都能映射到这张图上的某个节点。
好了，这一章的概念就聊到这儿。概念本身不复杂，但它们是后续所有审计方法的基础。下一层我们会直接聊日志本身——什么样的日志才是有价值的、应该从哪里开始采集。嗯，到时候再细说。