用 IAM 筑牢权限围墙——零信任云上访问控制，我们这样帮客户守住最后一公里

发布时间：2026-05-24 16:56:55

用 IAM 筑牢权限围墙——零信任云上访问控制，我们这样帮客户守住最后一公里

有一次，我们接到一个紧急求救：一位客户的 AWS 账号被人在半夜创建了 12 台 GPU 实例，全部在挖矿，到早上账单已经冲到 2.6 万美元。排查下来发现，他们的一名前员工离职时，离职交接流程里漏掉了一个权限很高的 IAM 用户，而且这个用户的访问密钥被硬编码在一个 GitHub 公开仓库的配置文件里。黑客扫描 GitHub 发现了密钥，直接接管了账号。客户事后问我：“我们明明买了 亚马逊账号，也付了支持费，为什么 AWS 不阻止这种事？” 答案是：AWS 给你的是墙和锁，但锁不锁门，钥匙藏不藏好，是你自己的事。

IAM（Identity and Access Management）是 AWS 安全体系的中枢神经。它决定了谁（或什么服务）可以访问哪些资源，在什么条件下可以访问。我们 aws代理 在帮客户做 亚马逊服务器开通 时，至少花 30% 的交付时间在 IAM 策略设计和权限审计上。因为服务器配置错了最多宕机，权限配置错了可能倾家荡产。

IAM 的核心三元素：用户、角色、策略

IAM 用户：代表一个具体的人或应用程序，拥有长期的访问密钥或控制台密码。

IAM 角色：一种短期权限身份，可以被 AWS 服务（如 EC2、Lambda）或外部身份（如企业 SSO）临时代入，没有固定的密钥。

IAM 策略：用 JSON 编写的权限声明，定义“允许或拒绝什么操作，针对哪些资源，在什么条件下”。

新手最容易犯的错误是：给所有开发人员分配同一个 IAM 用户，并直接附加 AdministratorAccess 策略。这在安全上等同于裸奔。我们强制推行的基线是：每个人一个独立的 IAM 用户，并遵循最小权限原则——只授予完成任务所必需的最小权限，且对生产环境资源额外加上 MFA 条件。

从“全放”到“零信任”的权限设计五步法

第一步，审计现有权限。用 IAM Access Analyzer 扫描所有策略，找出哪些资源被过度暴露。Access Analyzer 能自动识别 S3 桶被外部账号访问的路径、IAM 角色的信任关系是否存在风险。第二步，按角色定义权限组。例如“开发者”、“运维”、“财务”三个组，为每个组创建对应的 IAM 组并附加权限策略。第三步，将用户加入组，禁止用户直接附加策略。第四步，强制 MFA，对任何涉及敏感操作（如删除 S3 桶、终止 EC2）的 API 调用要求 MFA 认证。第五步，定期轮换访问密钥，通过 IAM 凭证报告监控密钥的最后使用时间，停用超过 90 天不用的密钥。

角色扮演：让 EC2 免密钥访问 S3

一个经典错误：在 EC2 应用程序里硬编码 AWS 访问密钥去读写 S3。正确的做法是给 EC2 实例附加 IAM 角色，让角色拥有 S3 相关权限。这样应用程序通过实例元数据自动获取临时凭证，密钥不会出现在代码里，也无需手动管理。我们在 亚马逊服务器代理开通 时，对每一台启动的实例都默认分配一个最小权限的角色，杜绝硬编码密钥的存在。

权限边界与服务控制策略（SCP）

对于多账号环境或希望进一步收紧权限的客户，我们还会使用权限边界（Permissions Boundary）和 SCP。权限边界可以限制 IAM 用户能给自己创建的最大权限范围，防止权限过度提升。SCP 则是在 AWS Organizations 层面，对整个组织单元设置一道无法逾越的上限，比如禁止所有账号创建 IAM 用户、或禁止删除 CloudTrail 日志。我们作为代理商，在管理客户的 亚马逊服务器账户 时，经常使用 SCP 来防止客户内部的误操作扩散。

IAM 权限策略设计实战对比表

下面这张表总结了不同角色和场景下的权限设计建议：

角色/场景	推荐权限	应避免的操作	额外安全措施
初级开发者	只读 + 个人开发环境完整控制	生产环境终止实例、修改 VPC	MFA + 无生产环境密钥
资深运维	生产环境 EC2 管理 + CloudWatch 读写	IAM 用户管理、账单读取	MFA 强制，密钥按月轮换
财务/账单查看者	只读账单、Cost Explorer	任何资源的创建或修改	独立账号或组织单元
CI/CD 流水线角色	仅限部署目标 ECS/EKS + ECR 读写	S3 删除、数据库删除	限定 Source IP 条件
第三方审计工具	只读安全审计（SecurityAudit 策略）	写操作	限定角色代入来源
应用程序所在 EC2	仅其绑定的 S3 桶读写、RDS 连接	不访问其他资源	不使用 Access Key，仅角色

代理商在 IAM 安全上的“保镖”价值

IAM 配置复杂，策略 JSON 错一个字符可能导致全部放行。我们团队的 亚马逊代理 服务里，有一项叫“安全基线托管”的年度套餐，每月做一次 IAM 凭证报告审查，每季度做一次渗透模拟——尝试用已泄露密钥或过度授权的角色去攻击客户资源，然后修补发现的问题。不少客户一开始觉得我们“管太多”，但当他们看到模拟报告里显示某个开发人员可以删除整个生产数据库时，态度立刻转变。

说到底，云上安全是一个责任共担模型。AWS 负责云本身的安全，你负责云内部的安全。IAM 就是你手里最重要的一把锁。钥匙不乱扔，门锁常常换，风险就能被压到最低。对于任何想买 亚马逊账号出售 渠道账号、或者自建账号的用户，我的建议都是：在启动第一台服务器之前，先花一天时间把 IAM 策略和 MFA 配好。这可能是你在云上花得最值的一天。

如果需要更深入咨询了解可以联系全球代理上TG:@jinniuge  他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。