北京
每次调用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.
