1. IAM 概述：定义、核心组件与安全地位

咱们开门见山。IAM（Identity and Access Management，身份与访问管理），说白了就是回答三个问题：你是谁？你能干什么？谁允许你这么干？ 听起来简单，实际落地时坑特别多。

我自己的习惯是把它拆成两层：身份层（你是谁）和权限层（你能干什么）。这两层一旦没对齐，安全就漏风了。你想想看，如果同事离职了账号还没销，或者某个开发被配了生产环境的 root 权限，后果都不用我多说。

1.1 IAM 的定义

IAM 是一套管理数字身份、控制资源访问策略的体系。它覆盖了从用户注册、认证、授权、审计到账号回收的全生命周期。

• 身份（Identity）：用户、设备、服务、……任何需要访问你系统的东西都得有一个身份。
• 认证（Authentication）：证明“你就是你”——密码、MFA、证书、生物特征。
• 授权（Authorization）：确认你能碰什么——权限策略、角色绑定、条件约束。
• 审计（Auditing）：记录谁在什么时候干了啥——不可否认、可追溯。

1.2 IAM 核心组件

我把常见的 IAM 组件分成五块，每一块都有对应的攻击面。你做完这一章就知道后面怎么防了。

这里我想多说一句，授权引擎 往往是攻防最激烈的地方。AWS IAM 里一条 S3 策略写错了，可能直接把整个桶暴露给公网。我去年帮一个 SaaS 团队复盘，发现他们用了 ABAC 但条件写成了 StringEquals，结果本应是“仅允许访问自己部门数据”的策略变成了“所有部门都能看”。原因？就是一个属性键写成了驼峰。你说冤不冤。

1.3 IAM 在安全体系中的重要性

OK，咱们聊点宏观的。你随便找一个安全框架（NIST CSF、ISO 27001、CIS Controls），身份管理 永远排在前两三章。为什么？

1. 边界失效后的兜底：零信任大旗喊着“永不相信，始终验证”，内核就是 IAM。防火墙破了你还能靠权限卡住。
2. 横向移动的刹车片：攻击者拿到一个低权限账号，想通过 IAM 误配提升到管理员？如果策略够严，这路就堵死了。
3. 合规审计的命门：GDPR、SOX、PCI-DSS 全要求精细化权限管理和可审计日志。IAM 不到位，合规直接红灯。
4. 数据泄露的第一道锁：据我看到的报告统计，60% 以上的云数据泄露和 IAM 配置错误直接相关。不是外网攻击多叼，而是内部权限太大了。

讲到这里，你可能会问：“那我应该从哪开始？” 答案是：先画清楚你的身份域和资源域。下面这张图能帮你快速理清主线。

上面这张图把 IAM 体系分成三大块，外加底部的安全目标和常见攻击面。我特别想让你注意底部的三个攻击点——弱凭证、策略过度宽松、僵尸账号，这是我们后面十几章反复要打交道的对手。你在设计 IAM 模型时，脑子里要时刻挂着一根弦：任何一次身份变更或策略修改，都可能被对手利用成突破口。

1.4 为什么把 IAM 安全放到第一章？

因为它是所有安全控制的基础。如果你连谁在访问都搞不清，防火墙、WAF、IDS 全白搭。我记得有次红蓝对抗模拟，蓝队花了上万块钱买各种安全设备，结果红队只用了两个步骤：1）从公开仓库里找到一个被泄露的 AWS Access Key；2）用这个 Key 调用 IAM:ListUsers 和 IAM:GetPolicy，直接找到了一个未限制“*”的管理员策略，然后提权到管理员。全程没碰一个漏洞。

所以这门课咱们从源头开始，把 IAM 的每一层都拆开来看。你只有把“身份 - 权限 - 审计”这个三角的地基打牢了，后续的零信任、容器安全、多云管控才能立得住。