亚马逊云官方代理 亚马逊云 AWS 账号身份认证集成
别再把 AWS 密钥当零食吃了
朋友，你有没有在某个深夜，对着终端里一行 aws configure 手抖输进公司主账号的 AccessKey？有没有在 GitHub 提交记录里，发现某位新同事悄悄把 credentials 文件 commit 了？有没有在安全扫描报告里，看到「高危：明文密钥暴露」被标成血红色？——别急着删历史记录，先深呼吸。这不是你的错，是整个团队对「身份认证」的理解，还卡在「能连上就行」的 1.0 阶段。
先搞清一个铁律：AWS 不认人，只认凭证
AWS 根本不知道你是张三李四王五，它只认三样东西：谁（Principal）、想干啥（Action）、在哪干（Resource）。而「谁」这个身份，必须由一串可验证的数字凭证来证明。这就像去银行办业务，柜员不看脸，只验身份证+指纹+短信验证码。AWS 的「身份证」叫 IAM Identity，而「指纹+短信」就是它的认证组合拳。
IAM 用户 ≠ 你本人，只是个虚拟账户
很多人以为创建个 IAM 用户就等于「绑定了自己」。错。IAM 用户是个独立实体，自带密码、AccessKey、MFA 设备，但它和你的人事系统、邮箱、工牌毫无关系。它就像一张借书证——可以注销、重置、禁用，但不会因为你离职自动作废。所以，别给开发同学开永久 AccessKey，那不是授权，是埋雷。记住：IAM 用户适合长期运维人员，不适合开发日常调用。
角色（Role）才是真正的「临时工中介」
角色才是 AWS 认证体系的灵魂。它不绑定密码，不发密钥，只接受「被代入」。比如 EC2 实例启动时，挂载一个角色，实例内程序就能自动获得临时凭证；Lambda 执行时，用执行角色获取 S3 权限；甚至你本地用 aws sts assume-role，也能临时切换身份。关键在于：角色的凭证有效期默认 1 小时，最长 12 小时，过期自动失效——这比任何「定期轮换密钥」的制度都靠谱。
联合身份：让 AWS 接入你的现有身份源
如果你公司已有 Azure AD、Okta、JumpCloud 或自建 Keycloak，恭喜，你不用在 AWS 里重复维护几百个 IAM 用户。联合身份就是让你的员工用公司邮箱+AD 密码，一键登录 AWS 控制台，且权限随 AD 组自动同步。
SAML 2.0：老派但稳如泰山
SAML 是企业级单点登录（SSO）的事实标准。配置要点就三条：① 在 IdP（如 Okta）导出元数据 XML；② 在 AWS IAM 中创建 SAML 提供商，上传该 XML；③ 建立角色并设置信任策略，明确允许哪些 IdP 的哪些断言（如 https://aws.amazon.com/SAML/Attributes/Role）过来扮演。最常翻车的是 ARN 写错——别手敲，复制粘贴；还有 IdP 端没填对 AWS 的 ACS URL（https://signin.aws.amazon.com/saml），结果跳转后直接 404。
OIDC：现代应用的首选，尤其适合 DevOps 流水线
OIDC 更轻量，天然支持 JWT，特别适合 GitHub Actions、GitLab CI、Jenkins 这类场景。举个真例子：你在 GitHub Org 启用 OIDC，为 prod-terraform workflow 创建角色，信任 GitHub 的 issuer（https://token.actions.githubusercontent.com），并限制 subject 为 repo:myorg/infra:ref:refs/heads/main。这样，只有主干分支的 Terraform 流水线才能临时获取生产环境权限，且每次运行都是全新短期凭证——再也不会出现「CI 机密泄露导致全量 S3 被删」的惨剧。
跨账号访问：别再共享 Root 或疯狂复制策略
多账号架构（Organizations）已是 AWS 最佳实践，但账号间权限怎么打通？答案永远是：用角色，而不是复制用户、共享密钥、或开放宽泛策略。
经典双角色模型：信任方 & 被信任方
假设 Account A（日志账号）要读取 Account B（应用账号）的 CloudWatch Logs。步骤极简：① Account B 创建角色 LogReaderInAppAccount，信任策略允许 Account A 的根账号（arn:aws:iam::A_ID:root）代入；② Account A 创建角色 LogPullerFromLogsAccount，权限策略允许 sts:AssumeRole 到 B 的角色；③ A 中的 Lambda 或 CLI 执行 assume-role，拿到临时凭证后直连 B 的日志服务。全程无密钥、无硬编码、权限最小化——审计时，你只需查两条信任策略，清爽得像刚洗过的玻璃。
亚马逊云官方代理 MFA：不是锦上添花，是强制底线
AWS 控制台登录、Root 账户操作、删除 KMS 密钥、变更账单信息……所有高危动作，MFA 都是硬性开关。别信「我们小团队没黑客盯」——90% 的云入侵始于弱密码+无 MFA。推荐方案：硬件 YubiKey（防钓鱼）＞ Google Authenticator（便捷）＞ SMS（已不推荐，易被 SIM 劫持）。更狠一招：在 IAM 策略中加一条 "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "true"}}，让所有敏感 API 必须带 MFA 令牌才能通过，连 CLI 都逃不掉。
最后送你三条血泪口诀
- 密钥零容忍：开发环境一律用角色（EC2/Lambda/Container）或 OIDC；CI/CD 流水线禁用 AccessKey；本地调试优先用 SSO 登录或
aws sso login。 - 权限最小化不是口号：用 IAM Access Analyzer 检查未使用权限；用 IAM Policy Simulator 验证策略效果；新策略上线前，先用
aws iam simulate-principal-policy模拟一百次边界条件。 - 审计留痕要闭环：开启 CloudTrail 全区域日志，投递到独立审计账号的 S3；用 Athena 查询「谁在什么时间调用了什么 API」；配合 Config Rules 自动检测「未启用 MFA 的用户」「过期 90 天的 AccessKey」，告警直达钉钉群。
写完这篇，我顺手删掉了自己 ~/.aws/credentials 里那个躺了三年的测试密钥。不是因为怕，而是终于明白：真正的安全感，从不来自「我藏得好」，而来自「我根本没留门」。AWS 的身份认证不是一道墙，而是一套精密的水闸系统——每道闸门都有编号、有日志、有时效、有审批流。你修好它，云才真正属于你；否则，你只是租了个随时可能漏水的集装箱。
