Easy-Vibe 云计算 IAM 实战身份与访问管理的权限治理指南【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe导读本指南是 Easy-Vibe 课程中《7-基础设施与运维》附录的一部分cloud-iam.md系统讲解云上 IAMIdentity and Access Management身份与访问管理的核心概念与落地方法。文章以「如何在不把钥匙交给错误的人的前提下方便地授予云访问权限」为主线覆盖用户/组/角色/策略四类核心实体、AK/SK 密钥治理、MFA 多因素认证、跨账户 Role Assume以及一套可照抄的 10 人团队权限架构实施方案。读完你将掌握 IAM 策略的 JSON 语法与优先级判定规则并能独立为团队搭建最小权限、无长期密钥的云权限体系。在深入之前建议先补齐两个前置概念Token 是什么可阅读 大语言模型导论 中的「Tokenization Token」小节Prompt 是什么可参考 Prompt 工程 中 System / User / Assistant 的基本结构。0. 引言为什么一上云就容易「踩雷」很多人第一次使用云服务时都有过类似的经历图省事把 AccessKey 直接写进代码并推送到 GitHub给所有员工都开了「管理员权限」结果有人手滑删掉了生产数据库项目交接后没人说得清还有谁持有离职员工的账号凭据听说过 MFA但觉得「太麻烦」而从未启用。直觉上我们会认为「这些员工安全意识到位吗」但大多数情况下问题并不在人而在于缺少一套权限管理系统。面对这些挑战仅仅「小心一点」已经不够了。我们需要一套系统化的权限管理方法论——这正是IAMIdentity and Access Management要解决的问题Prompt 工程解决的是「如何把话说清楚」而云权限管理解决的是「谁可以做什么」。1. IAM/RAM 概览从「门禁系统」讲起1.1 类比公司的智能门禁系统假设公司搬进一栋新办公楼场景没有 IAM有 IAM新员工入职发一把能开所有门的万能钥匙发一张只能开本部门区域的门禁卡员工离职钥匙丢了没人知道在谁手里在系统中立即注销其门禁卡——所有门都无法打开外包人员把钥匙借给他用几天发放一张 3 天后自动过期的临时门禁卡访客前台发一把钥匙发放一次性访客码仅对会议室有效IAM身份与访问管理就像这套「智能门禁系统」身份Identity是谁员工、外包、访客、应用程序访问Access能开哪些门允许执行哪些操作管理Management钥匙如何发放、如何回收、如何留痕。1.2 AWS IAM 与阿里云 RAM不同云厂商都有各自的 IAM 实现云厂商服务名称核心概念AWSIAMIdentity and Access ManagementUser、Group、Role、Policy阿里云RAMResource Access Management用户、用户组、角色、权限策略腾讯云CAMCloud Access Management用户、用户组、角色、策略华为云IAM用户、用户组、委托、策略AzureAzure AD RBACUser、Group、Role、RBAC虽然名称各不相同但核心概念是相通的用户User代表一个具体的人或应用用户组Group为一组用户批量管理权限角色Role定义一组可被「扮演」的权限集合策略Policy具体的权限规则允许/拒绝什么。2. 用户、组、角色到底该用哪个2.1 三种「身份」的区别用办公室场景做类比概念类比适用场景特点用户User拥有自己工位和门禁卡的正式员工长期、稳定的团队成员拥有永久的登录凭据密码、AK/SK用户组Group「技术部」「销售部」等部门权限批量管理不能登录只是一个权限容器角色Role临时访客卡、外包临时卡临时授权、跨账户访问没有永久凭据通过「扮演」获取临时凭据2.2 实战案例一家创业公司的权限进化史阶段 1创始团队2-3 人问题直接用 Root 账户登录控制台因为「更方便」 风险Root 账户拥有全部权限——一旦泄露整个账户万劫不复阶段 2团队扩张5-10 人改进为每个人创建 IAM 用户分配不同权限 新问题 - 运维工程师小王离职了——他的 AK/SK 还散落在哪些服务器上 - 新来的前端需要 S3 只读权限后端需要 RDS 权限——逐个手动配置太繁琐阶段 3标准化10-30 人改进 1. 按角色创建 IAM 用户组 - Developers开发S3、EC2、RDS 读写 - DevOps运维全权限但必须使用 MFA - ReadOnly只读可查看所有资源不能修改 - QAs测试测试环境资源访问 2. 使用 IAM 角色 - EC2 实例使用 Instance Profile服务器上不再存放 AK/SK - 跨账户访问通过 Role Assume不再共享 AK/SK - CI/CD 使用 OIDC Federation不再存储长期凭据阶段 4多账户 / 企业级30 人架构 - Master Account主账户只做账单与组织管理不部署资源 - Audit Account审计账户集中收集所有账户的日志 - Dev Account开发账户开发环境 - Staging Account预发布账户测试环境 - Prod Account生产账户生产环境权限最严格 权限流转 - 开发者默认只对 Dev 账户有读写权限 - 需要变更生产环境时提交工单临时扮演 Prod 账户中的角色 - 所有 Assume 操作由 CloudTrail 记录并定期审计3. 角色与策略权限管理的「灵魂」3.1 角色的本质信任 权限一个 IAM 角色由两个核心部分组成信任策略Trust Policy谁可以扮演这个角色权限策略Permission Policy扮演角色之后可以做什么用一出戏剧来类比概念类比说明角色Role剧本里的「哈姆雷特」定义了要演的是什么戏权限集合信任策略Trust Policy导演说「谁能演哈姆雷特」可以是「本剧团的演员」本账户用户、「借来的别团演员」跨账户、「特邀嘉宾」外部 IdP权限策略Permission Policy剧本的内容哈姆雷特能做什么念台词、比剑、发疯具体权限扮演角色Assume Role演员登上舞台小李被导演选为哈姆雷特登上舞台后就拥有了剧本里定义的全部权限临时凭据Temporary Credentials演出许可小李拿到一张「临时演出许可」演出结束即失效3.2 策略Policy权限的「语法」IAM 策略是一份 JSON 文档用来定义「谁可以对哪些资源执行哪些操作」。一个完整的策略示例{ Version: 2012-10-17, Statement: [ { Sid: AllowS3ReadWrite, Effect: Allow, Action: [s3:GetObject, s3:PutObject, s3:DeleteObject], Resource: arn:aws:s3:::my-app-bucket/*, Condition: { StringEquals: { aws:RequestedRegion: ap-northeast-1 }, Bool: { aws:MultiFactorAuthPresent: true } } }, { Sid: DenySensitiveData, Effect: Deny, Action: s3:*, Resource: arn:aws:s3:::my-app-bucket/sensitive/* } ] }关键字段解释字段含义示例Version策略语法版本2012-10-17Statement权限声明数组可包含多条规则[...]Sid声明 ID可选用于标识这条规则AllowS3ReadWriteEffect效力Allow允许或 Deny拒绝AllowAction允许/拒绝的操作支持通配符s3:GetObject、s3:*Resource涉及的资源通过 ARN 标识arn:aws:s3:::bucket/*Condition可选仅在特定条件下生效区域限制、MFA 要求等3.3 权限优先级Deny Allow 默认拒绝IAM 的权限判定可以用一句话概括显式 Deny 永远优先没有 Allow 就默认拒绝。判定流程1. 先检查是否存在 Deny 策略 ├─ 存在 Deny → 拒绝无论是否有 Allow └─ 没有 Deny → 继续检查 2. 再检查是否存在 Allow 策略 ├─ 存在 Allow → 允许 └─ 没有 Allow → 拒绝默认拒绝原则实战案例保护敏感数据// 策略 1开发者的常规权限 { Effect: Allow, Action: [s3:*], Resource: arn:aws:s3:::company-data/* } // 策略 2保护敏感目录即使开发者拥有 s3:* 也生效 { Effect: Deny, Action: [s3:*], Resource: arn:aws:s3:::company-data/sensitive/* }要点开发者虽然拥有s3:*的 Allow 权限但对敏感目录存在显式 DenyDeny 优先级更高因此开发者无法访问敏感数据即使该开发者是管理员这条 Deny 依然生效Root 账户除外。4. 访问密钥AK/SK一把必须小心保管的钥匙4.1 什么是 AK/SKAccess Keys访问密钥是云服务为程序化 API 调用提供的长期凭据由两部分组成组成名称作用类比Access Key ID访问密钥 ID标识你是谁类似用户名账号Secret Access Key秘密访问密钥证明你是你类似密码PIN 码4.2 为什么 AK/SK 是「高危物品」实战案例一家创业公司的教训小李是一家创业公司新来的后端开发。入职第一周他需要调试一个文件上传功能# 小李的代码严重的安全问题 import boto3 # 为了调试方便AK/SK 直接写在代码里 s3 boto3.client( s3, aws_access_key_idAKIAIOSFODNN7EXAMPLE, aws_secret_access_keywJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY, region_nameap-northeast-1 ) def upload_file(file_path, bucket_name, object_name): s3.upload_file(file_path, bucket_name, object_name) print(f文件已上传至 s3://{bucket_name}/{object_name}) # 测试上传 upload_file(./test.jpg, my-company-bucket, uploads/test.jpg)一周之后发生的事小李把代码推送到 GitHub包括 AK/SKGitHub 上的代码被爬虫扫描AK/SK 被提取攻击者利用这些凭据创建了大量 EC2 实例挖矿月底账单多出 12,000 美元审计时发现 AK/SK 泄露小李被约谈……这个案例教会我们什么错误做法正确做法在代码中硬编码 AK/SK使用 IAM 角色让程序自动获取临时凭据把 AK/SK 提交进 Git 仓库用.gitignore忽略配置文件并使用密钥管理服务长期不轮换同一套 AK/SK定期轮换 AK/SK优先用临时凭据替代长期凭据给 AK/SK 过大的权限遵循最小权限原则只授予必要权限4.3 AK/SK 安全使用指南场景 1本地开发# 正确做法用 AWS CLI 配置凭据而不是写进代码 aws configure # 然后输入 Access Key ID 和 Secret Access Key # 它们会被保存在 ~/.aws/credentials 中权限设为 600 # 代码中无需任何凭据 import boto3 s3 boto3.client(s3) # 自动从 ~/.aws/credentials 读取场景 2服务器 / EC2# 正确做法使用 IAM Instance Profile # 1. 创建 IAM 角色挂载所需权限如 S3ReadOnly # 2. 创建 Instance Profile 并关联该角色 # 3. 启动 EC2 时选择这个 Instance Profile # 代码中完全不需要凭据 import boto3 s3 boto3.client(s3) # 自动从 EC2 元数据服务获取临时凭据 # 临时凭据会自动轮换不用担心过期场景 3CI/CD 流水线# 正确做法OIDC FederationOpenID Connect # 以 GitHub Actions 为例 # 1. 在 AWS 中创建信任 GitHub 的 OIDC Identity Provider # 2. 创建 IAM 角色其信任策略允许指定 GitHub 仓库扮演 # 3. 在 GitHub Actions 中配置 name: Deploy on: [push] jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # 重要允许请求 OIDC Token contents: read steps: - uses: actions/checkoutv3 - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentialsv2 with: role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole aws-region: ap-northeast-1 # 注意这里没有 Access Key完全使用临时凭据 - name: Deploy run: aws s3 sync ./build s3://my-bucket/小结AK/SK 使用的安全层级安全层级做法适用场景风险等级最高使用 IAM 角色无长期凭据EC2、Lambda、ECS、CI/CD极低高使用 OIDC FederationGitHub Actions、GitLab CI低中使用密钥管理服务本地开发、小团队中低使用环境变量快速原型、个人项目高极低在代码中硬编码任何场景都不推荐极高5. 多因素认证MFA给账户再加一把「锁」5.1 什么是 MFAMFAMulti-Factor Authentication多因素认证也称 2FA双因素认证是一种要求用户在登录时提供两种或以上不同认证因素的安全机制因素类型是什么示例知识因素你知道什么只有用户本人知道的信息密码、PIN持有因素你拥有什么用户持有的物理设备手机、硬件密钥生物因素你是什么用户的生物特征指纹、人脸识别5.2 为什么 MFA 如此重要真实数据说明问题攻击方式没有 MFA 的成功率有 MFA 的成功率密码猜测 / 暴力破解高极低缺少第二因素窃取密码的钓鱼攻击高极低钓鱼页面拿不到 MFA 验证码密码泄露来自其他网站高极低缺少第二因素微软安全报告2020MFA 可以拦截99.9%的自动化攻击。5.3 MFA 实战为 AWS Root 账户开启 MFA步骤 1登录 AWS 控制台使用 Root 账户邮箱和密码登录点击右上角账户名选择「Security Credentials」。步骤 2启用 MFA找到「Multi-factor authentication (MFA)」区域点击「Assign MFA device」选择 MFA 设备类型推荐「Authenticator app」。步骤 3配置虚拟 MFA在手机上安装 Google Authenticator 或 Microsoft Authenticator扫描二维码或手动输入密钥输入 App 中显示的 6 位验证码需要连续输入两次因为验证码每 30 秒刷新一次。完成你的 Root 账户现在受 MFA 保护了。6. 跨账户访问如何安全地「登门做客」6.1 为什么需要跨账户访问随着公司规模增长许多企业采用多账户架构来隔离不同环境账户类型用途权限要求Master Account组织管理、账单几乎不使用Security Audit集中收集所有账户日志对其他账户只读Shared Services共享资源镜像仓库等其他账户只读Development开发环境开发者全权限Staging测试 / 预发布环境测试人员权限Production生产环境严格受限需审批问题Production 账户的 EC2 如何从 Shared Services 账户拉取镜像方案 A把 AK/SK 写进 Production 的用户数据危险有 AK/SK 泄露风险方案 B跨账户 Role Assume推荐临时凭据自动轮换6.2 跨账户 Role Assume 的原理账户 A (Production) 账户 B (Shared Services) | | | 1. 请求 Assume Role | | 我想扮演账户 B 的 ECRReadRole | |------------------------------------------| | | | 2. 校验信任策略 | | 账户 A 允许扮演我吗| | | | 3. 返回临时凭据 | | AccessKeyId, SecretKey, SessionToken | |------------------------------------------| | | | 4. 使用临时凭据访问 ECR | | docker pull 账户B.dkr.ecr... |要点临时凭据默认有效期为 1 小时最长可配置为 12 小时代码中不保存任何长期凭据信任策略可以限制谁能扮演角色例如指定账户、指定外部 ID。6.3 实战配置跨账户 ECR 访问场景Production 账户的 EC2 需要从 Shared Services 账户拉取 Docker 镜像。步骤 1在 Shared Services 账户创建 IAM 角色登录 Shared Services 账户的 AWS 控制台进入 IAM → Roles → Create role选择「Another AWS account」输入 Production 账户的 Account ID可选开启「Require external ID」并输入一串随机字符串提高安全性挂载权限AmazonEC2ContainerRegistryReadOnly命名角色CrossAccountECRReadRole。步骤 2获取角色 ARN创建完成后复制角色的 ARNarn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole步骤 3配置 Production 账户的 EC2 实例方法 A使用 Instance Profile推荐在 Production 账户创建 IAM 角色供 EC2 使用信任策略信任 EC2 服务权限策略允许扮演跨账户角色{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: sts:AssumeRole, Resource: arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole } ] }创建 Instance Profile 并关联此角色启动 EC2 时选择该 Instance Profile。方法 B在 EC2 用户数据中动态 Assume Role#!/bin/bash # 安装 AWS CLI yum install -y aws-cli # 扮演跨账户角色 CREDS$(aws sts assume-role \ --role-arn arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole \ --role-session-name EC2PullSession) # 提取临时凭据 export AWS_ACCESS_KEY_ID$(echo $CREDS | jq -r .Credentials.AccessKeyId) export AWS_SECRET_ACCESS_KEY$(echo $CREDS | jq -r .Credentials.SecretAccessKey) export AWS_SESSION_TOKEN$(echo $CREDS | jq -r .Credentials.SessionToken) # 登录 ECR aws ecr get-login-password --region ap-northeast-1 | \ docker login --username AWS --password-stdin SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com # 拉取镜像 docker pull SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest步骤 4测试跨账户访问在 Production 账户的 EC2 上执行# 测试能否完成 Role Assume aws sts get-caller-identity # 应显示arn:aws:sts::PRODUCTION_ACCOUNT_ID:assumed-role/CrossAccountECRReadRole/EC2PullSession # 测试能否列出 Shared Services 账户的 ECR 仓库 aws ecr describe-repositories --registry-id SHARED_SERVICES_ACCOUNT_ID完成Production 账户的 EC2 现在可以安全地拉取 Shared Services 账户的镜像且无需共享任何长期凭据。7. 实战从零搭建一套安全的权限体系7.1 从零构建权限架构假设你是某 10 人创业公司的技术负责人需要从零设计 AWS 权限架构。以下是推荐的实施步骤第一阶段Root 账户保护第 1 天目标保护 Root 账户——最重要的账户 1. 为 Root 账户开启 MFA强制 - 推荐硬件 MFAYubiKey或 Google Authenticator 2. 创建 IAM 管理员账户 - 用户名admin或你的名字 - 权限AdministratorAccess后期再收敛 - 开启 MFA 3. 删除 Root 账户的 Access Key如果创建过 - Root 账户永远不应拥有 AK/SK 4. 配置 Root 账户使用告警 - CloudWatch SNSRoot 账户登录时发送邮件/SMS 通知第二阶段团队权限分组第 1 周目标把团队成员分组批量管理权限 1. 分析团队角色 - 后端开发2 人 - 前端开发1 人 - 移动端开发1 人 - 产品经理1 人 - 设计师1 人 - 创始人/管理员3 人 2. 创建 IAM 用户组 Group: Developers ├── 成员所有开发者后端、前端、移动端 ├── 权限 │ ├── EC2启动、停止、查看但不能删除他人的实例 │ ├── S3开发环境桶的读写 │ ├── RDS只读不能改动生产数据库 │ └── CloudWatch查看日志 └── 限制仅限 ap-northeast-1 区域 Group: ProductTeam ├── 成员产品经理、设计师 ├── 权限 │ ├── S3只读查看数据文件 │ ├── CloudWatch Dashboard查看监控图表 │ └── Cost Explorer查看账单不能修改 └── 限制仅只读不能改动任何资源 Group: Administrators ├── 成员创始人、技术负责人 ├── 权限AdministratorAccess └── 要求操作必须使用 MFA 3. 为每个人创建 IAM 用户并加入对应用户组 - 不直接给个人授权始终通过用户组管理 - 开启 MFA强制第三阶段应用层优化第 2-4 周目标让应用安全地访问 AWS 资源 1. EC2 实例使用 Instance Profile - 服务器上不再配置 AK/SK - 创建 IAM 角色并挂载所需权限如 S3 读写 - 创建 Instance Profile 并关联角色 - 启动 EC2 时选择该 Instance Profile - 应用代码直接用 boto3无需配置凭据 2. 如果必须使用 AK/SK第三方集成 - 用 AWS Secrets Manager 保存 AK/SK - 应用启动时从 Secrets Manager 读取 - 配置定期轮换90 天 - 监控 AK/SK 的使用情况 3. 为所有 API 调用配置 CloudTrail - 创建独立的 S3 桶存放日志 - 开启日志文件校验防篡改 - 对关键事件发送 SNS 通知如 Root 账户使用、策略变更第四阶段安全加固持续进行目标建立持续的安全监控与改进 1. 启用 AWS Config - 监控资源配置变更 - 合规性检查如安全组是否对 0.0.0.0/0 开放 2. 启用 IAM Access Analyzer - 持续分析资源策略 - 识别外部访问如 S3 桶是否公开 3. 定期检查 IAM 配置 - 每月排查未使用的 IAM 用户和角色 - 检查 Access Key 使用情况 - 核实用户组成员是否合理 4. 建立安全事件响应流程 - AK/SK 泄露时立即删除、轮换、审计影响范围 - 发现异常 API 调用时立即调查、收敛权限8. 常见误区与规避策略8.1 十大 IAM 反模式#反模式为什么不好正确做法1用 Root 账户做日常操作Root 拥有全部权限一旦泄露损失无法控制创建 IAM 管理员账户Root 仅在必要时使用2给所有人 AdministratorAccess违反最小权限原则放大误操作与内鬼风险按角色分组只授必要权限3在代码中硬编码 AK/SK可能经 GitHub 泄露且难以轮换使用 IAM 角色、环境变量或密钥管理服务4长期不轮换 AK/SK凭据泄露后风险窗口期过长制定 90 天轮换策略更好的是改用临时凭据5忽略 MFA密码泄露后账户立刻失守为所有 IAM 用户开启 MFA高权限用户尤其必要6不用 CloudTrail无法审计谁做了什么出事后无法溯源开启 CloudTrail日志存放到独立审计账户7IAM 策略写得过于宽松例如Resource: *、Action: *攻击面过大明确写出资源 ARN 和具体 Action8离职员工 IAM 用户不清理僵尸账户会成为后门建立离职流程立即停用并删除 IAM 用户9不用 IAM Access Analyzer无法发现过于宽松的资源策略如公开的 S3 桶启用 IAM Access Analyzer定期检查外部访问10不在测试环境验证策略直接应用到生产可能导致服务中断用 IAM Policy Simulator 测试先在测试环境验证9. 术语表英文术语中文翻译说明IAMIdentity and Access Management身份与访问管理管理用户身份与访问权限的云服务RAMResource Access Management资源访问管理阿里云 IAM 服务的名称Root AccountRoot 账户注册时创建的拥有最高权限的归属账户IAM UserIAM 用户 / 子账户由 Root 创建、日常使用的子身份IAM RoleIAM 角色没有长期凭据的临时权限实例必须「扮演」IAM PolicyIAM 策略以 JSON 格式定义的权限规则ARNAmazon 资源名全局唯一的资源标识符AK/SK访问密钥 / 秘密密钥程序化访问云 API 的凭据STSSecurity Token Service提供临时安全凭据的服务MFA多因素认证需要两个及以上因素的认证方式SSO单点登录一次登录即可访问多个系统的认证方式ExternalId外部 ID用于防止混淆代理人攻击的安全标识CloudTrail云审计服务记录云账户中所有 API 调用与操作总结云访问管理的三大核心原则云访问管理不是一劳永逸的动作而是必须随着团队规模与业务需求不断演进起步阶段1-10 人保护 Root 账户MFA 不用于日常操作创建 IAM 管理员账户基础分组Developers、Admins。成长阶段10-50 人精细化的权限分组前端、后端、运维、产品等用 IAM 角色替代 AK/SK开启 CloudTrail 审计定期做权限检查。成熟阶段50 人 / 多账户多账户架构Dev、Staging、Prod 分离集中式日志审计账户自动化权限检查与告警完善的权限申请与审批流程。记住三条核心原则最小权限原则只授予必要权限不给 AdministratorAccess不用长期凭据优先使用 IAM 角色与临时凭据杜绝 AK/SK 泄露开启 MFA尤其是 Root 账户与高权限账户——这是性价比最高的安全措施。本指南对应的完整原文见 docs/de-de/appendix/7-infrastructure-and-operations/cloud-iam.md其他语言版本可在 docs 目录 的zh-cn、en、ja-jp等子目录中找到。本文属于 Easy-Vibe 课程的基础设施与运维附录建议结合课程主线的部署与运维相关内容学习需要确认文中涉及的 STS、CloudTrail 等服务的完整定义可对照上文第 9 节术语表逐一查阅。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考