最常见的安全错误是“给 Admin 就行”。

Source: Dev.to

当我们在压力之下时，几乎总是选择最快的解决方案。出现故障、有人需要访问、交付临近。于是我们会做常规的事：先给宽泛的权限“暂时”。
问题在于，这种临时的权限往往会一直保留下去。

最小权限并不是偏执，而是一种原则。只授予必要的权限，让错误的影响保持在最小范围，安全性也更可预测。

什么是真正的最小权限

最小权限意味着：

• 只允许必要的操作
• 只针对必要的资源
• 只在需要时授予
• 只针对正确的身份

一个好的策略应回答：

• 这个系统需要做什么
• 会在什么资源上执行
• 哪些操作它永远不应该有权执行

IAM 不仅是安全，还是稳定性。拥有过多权限的角色会更快导致更多问题。

为什么在大规模下很重要

在小环境中，宽泛的权限可能不会立刻被滥用。但在大环境中，迟早会出现问题。

最小权限可以帮助你防止：

• 若凭证泄露导致的大规模影响
• 生产环境中的意外删除
• 没有人记得的旧角色
• 难以解释的审计记录

此外，它还能帮助排查问题。如果出现故障，我们知道访问限制是真实的。

我们常见的失误

最常见的模式有：

• 使用 *:* 通配符
• 复制策略后未清理
• 为所有需求使用同一个角色
• 永久保留的临时权限
• 未将部署权限与运行时权限分离

这些问题连优秀的团队也会遇到。解决办法是采用明确的模式。

示例：错误策略 vs 正确策略

示例 1：S3 访问

❌ 错误策略（过于宽泛）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

✅ 正确策略（受限且实用）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucketInPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-app-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["public/*"]
        }
      }
    },
    {
      "Sid": "ReadObjectsInPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-data/public/*"
    }
  ]
}

设计良好 IAM 的简易流程

• 将角色进行拆分
• 从最小权限开始，必要时再扩展
• 使用 SCP 和 permission boundaries 作为护栏
• 定期审查并清理权限

小项目：使用 Terraform 为 Lambda + S3 创建最小权限角色

目标

创建：

• 一个 S3 bucket
• 一个 Lambda 执行角色
• 一条最小权限策略
• 将策略附加到角色

Lambda 将能够：

• 仅从 public/ 读取
• 仅向 results/ 写入
• 将日志写入 CloudWatch