每次调用AWS的HTTPS API,IAM都挡在最前面。实际跑过AWS的人都知道,卡壳的地方往往就在这里——"AccessDenied报错""策略写了Allow为什么还被拒"" assumed了角色凭证却没变"。这些踩坑模式高度可预测。
本文按认证实际发生的顺序拆解IAM:先认证,再授权,最后操作。覆盖八个核心模块:认证与授权的本质区别、Principal概念、SigV4验证机制、六种策略类型、策略JSON结构、策略评估逻辑(Deny优先)、IAM Identity Center与短期凭证,以及实践中的红线清单。
![]()
认证与授权:两个独立环节
先把认证(AuthN)和授权(AuthZ)拆开。认证解决"你是谁"——AWS上,调用者就是生成SigV4签名的凭证所有者。授权解决"你能做什么"——AWS通过组合多条策略并统一评估来回答。
后文严格遵循这个顺序:先AuthN,后AuthZ。
Principal:谁在调用AWS
AWS把发起调用的实体称为Principal,任何能对资源执行操作的都算。IAM Group不是Principal,它只是给用户批量挂策略的容器,本身从不认证,也不能填进策略的Principal字段。
Root用户拥有账户的完全控制权,只有它能修改账单或关闭账户。正因如此,其他所有操作都不该用Root。AWS推荐的标准流程:创号后立即给Root绑定MFA(现在基本强制要求);绝不为Root创建访问密钥;日常通过IAM Identity Center登录或assume IAM Role;把Root凭证锁进保险箱。
MFA方面,TOTP(Google Authenticator、1Password等的6位码)可用,但AWS更推荐FIDO2/WebAuthn通行密钥或YubiKey等硬件密钥,因为能抗钓鱼。同时建议至少注册两种MFA方式,防止单点失效导致锁死。
用IAM Role替代IAM User
IAM User的访问密钥(AKIA开头)是长期有效的,一旦泄露,在你轮换前一直有效。"把密钥提交到GitHub,几小时内就被滥用"的故事从未减少。
IAM Role通过AssumeRole发放短期凭证解决这一问题:默认1小时过期,最长12小时。三个前置概念:STS(Security Token Service)是AWS发放临时凭证的服务,sts:AssumeRole等操作都调它;Trust Policy是绑在Role上的策略,决定谁允许assume这个Role。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.