IAM
本文约需 2 分钟阅读
IAM (Identity and Access Management，身份与访问管理) 是一种集中管理「谁」可以对「什么」执行「何种操作」的机制。它对认证 (身份验证) 与授权 (权限赋予) 进行统一控制，确保对组织资源的适当访问。随着云环境的普及，IAM 已从单纯的用户管理工具，进化为承担零信任架构核心的安全基础。IAM 的配置错误是数据泄露和系统入侵的最大原因之一，被列为安全检查清单的首要项目。
认证与授权的区别
理解 IAM 时最重要的概念，是认证 (Authentication) 与授权 (Authorization) 的区别。这两者密切相关，但却是完全不同的过程。
- 确认「你是谁?」
- 密码、生物识别、MFA
- 在登录时执行
- 发行 ID 令牌
- 判定「可以做什么?」
- 角色、策略、作用域
- 在访问资源时执行
- 验证访问令牌
一种常见的误解是认为「能够登录 = 所有操作都被允许」。把认证想象成入口的门卫、把授权想象成每个房间的钥匙，就容易理解了。OAuth 是授权的代表性协议，SSO 是认证的代表性协议。
访问控制模型的比较
IAM 中授权的实现方式有多种模型，需根据组织的规模和需求进行选择。访问控制的设计，是一个考验安全性与运维效率之间平衡的领域。
| 模型 | 判定基准 | 适用示例 | 课题 |
|---|---|---|---|
| RBAC | 角色 (Role) | 管理员、编辑者、查看者 | 角色爆炸 (组合数增大) |
| ABAC | 属性 (部门、时间段、IP) | AWS IAM 策略中的 Condition | 策略复杂化 |
| PBAC | 策略 (规则引擎) | OPA (Open Policy Agent) | 引入与运维成本高 |
在实务中，主流做法是以 RBAC 为基础，在需要精细控制的地方结合 ABAC 的混合方式。AWS IAM 正是采用了这种混合模型，可以在基于角色的基本结构上，通过 Condition 要素添加基于属性的条件。
最小权限原则
最小权限原则是构成 IAM 设计根基的理念。对用户和服务只赋予执行业务所需的最小限度权限，绝不授予任何不必要的权限。然而在实务中，人们往往容易屈服于「先赋予较宽的权限让它能跑起来」的诱惑。与企业的密码策略一样，IAM 策略也不可缺少定期盘点和删除不必要权限。
因 IAM 配置错误引发的事件
IAM 的配置错误是云环境中安全事件的最大原因。S3 存储桶的公开访问许可、过度的 IAM 角色权限、访问密钥硬编码等，配置错误的模式多种多样。在 2019 年的 Capital One 事件中，由于 WAF 配置错误与过度的 IAM 角色权限相结合，导致 1 亿人以上的个人信息泄露。
要防止此类事件，有效的做法是引入 IAM 策略的自动审计工具 (如 AWS IAM Access Analyzer、Azure AD Privileged Identity Management 等)，并通过基础设施即代码 (IaC) 对配置进行版本管理。在实现零信任安全时，IAM 也是应当最先整备的基础。IAM 与云安全实践书 (Amazon) 推荐用来进行系统性学习。
这篇文章对您有帮助吗？