一、桶策略概述：基本概念与作用
桶策略这东西，说白了就是一道门禁。它控制谁能进、谁不能进，以及进来之后能做些什么。我刚开始接触对象存储时，总觉得这玩意儿就是写几条JSON规则，没什么大不了的。直到有一次，生产环境因为一条配置写错了，导致敏感日志被全部公开……嗯，从那以后，我再也不敢小看桶策略了。
1.1 什么是桶策略
桶策略（Bucket Policy）是一个基于 JSON 的访问控制规则集。它附着在存储桶上，用来定义哪些主体（User、Role、Service）可以对桶内的对象执行哪些操作。你可以把它理解成贴在门口的一张「通行须知」——上面写着什么人、什么时候、能干什么。
我个人习惯把桶策略拆成三部分来看：
- 主体（Principal）——谁想进来？可以是用户、角色、甚至匿名访问者。
- 动作（Action）——想干什么？读、写、删除、列出对象，还是修改加密配置？
- 条件（Condition）——有没有额外限制？比如来源 IP、是否使用 HTTPS、是否要求特定加密算法。
举个例子，你写一条策略只允许来自公司内网的 IP 读取日志，那么即使有人拿到了密钥，只要他不是从内网来的，照样被挡在外面。这就是桶策略的精细之处。
1.2 桶策略的核心作用
为什么我们要专门花三十章来讲桶策略和加密日志的关系？因为它的作用比想象中要多。我梳理了几个关键点：
- 权限精细化：不只能控制读写，还能控制是否允许覆盖、是否允许修改加密设置、是否允许读取元数据。
- 安全增强：强制要求 HTTPS、强制检查加密方式、拒绝不安全的请求。
- 跨账户授权：你可以允许另一个账号访问你的日志桶，但严格限定他只能读特定的前缀。
- 与加密策略联动：桶策略里可以写条件，要求客户端必须使用指定的加密方法（例如 SSE-KMS），否则拒绝请求。这是保证加密日志合规性的关键。
| 策略类型 | 适用场景 | 风险等级 |
|---|---|---|
| 私有（Private） | 默认情况，仅桶拥有者能读写 | 低 |
| 公共读（Public Read） | 静态网站、对外分享日志 | 中 |
| 公共读写（Public Read/Write） | 公开上传区域，极不推荐用于日志 | 高 |
| 授权策略（Conditional） | 所有生产环境推荐，配合加密条件 | 低（正确配置时） |
重点提醒：我见过很多团队给日志桶配了「公共读」策略，理由是方便调试。一旦日志中包含用户敏感信息（IP、账号、操作明细），这就是合规灾难。请务必将日志桶的默认策略设为私有，然后再按需添加授权。
1.3 桶策略与加密日志的关系
你可能会问：「桶策略和加密日志有什么关系？加密不是由桶的加密配置单独管理吗？」
没错，桶可以配置默认加密（SSE-S3、SSE-KMS、SSE-C）。但桶策略可以强制要求请求携带特定的加密头部，或者拒绝未加密的写入请求。举个例子：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-log-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}
]
}上面这条策略说：「任何人想往 my-log-bucket 里放对象，必须指定 SSE-KMS，否则拒绝。」这样一来，所有写入的日志都是加密的——你想存明文都不行。
我在项目中遇到过一种情况：运维人员错误地停用了桶的默认加密配置，但因为桶策略强制加密条件还在，后续所有写入请求全部返回 403。当时排查了好久，最后发现是策略比默认配置「优先级更高」——桶策略是强制检查，而默认加密只是后备方案。
我的建议：把桶策略当作「安全基线」，把桶的默认加密当作「兜底」。两者配合使用，加密日志才算真正落地。
1.4 桶策略的评估流程
了解评估流程，才能配置出靠谱的策略。我画了一张图，把核心判断步骤串起来了：
我曾经踩过一个坑：我以为桶策略评估通过后就不再检查加密了，结果在最严格的安全审计中，对方指出我漏掉了「加密算法」条件。后来我养成了习惯，在策略里同时限制 s3:x-amz-server-side-encryption 和 s3:x-amz-server-side-encryption-aws-kms-key-id，确保加密方式和密钥都被锁定。
1.5 桶策略与日志审计的关系
桶策略不只是「防坏人」，它还影响日志本身的记录行为。你想想看：
- 如果策略拒绝匿名写入，那么所有被拒绝的请求也会被记录到访问日志中。
- 如果策略允许读取但限制加密，读取行为会触发日志，但读取时如果客户端请求不满足加密条件，依然会被拒绝——拒绝事件也会写日志。
- 日志本身也可能存储在同一个桶里？嗯，这里要注意。如果日志桶和原始桶是同一个，那策略的递归问题就来了。我建议你总是把访问日志写入另一个受管桶，并专门给那个桶配一套更严格的安全策略。
所以，桶策略的每一条规则，都会在日志记录里留下痕迹。你配置得越精细，日志就越能反映真实的访问模式，这对后续的安全分析和故障排查都大有好处。
好了，关于桶策略的基本概念和作用，我们就先聊到这儿。记住，桶策略是加密日志安全的第一道防线，也是最后一道。后面所有加密相关的章节，都会基于这个基础来展开讨论。