想象你第一天入职一座叫「云端智算园区」的科技园。园区里每一栋楼都是一个 AI 服务：数据仓库楼里存着训练素材（S3）、算力楼里跑着模型训练任务（SageMaker）、AI 工坊里供你调用生成图片和大语言模型（Bedrock）。门禁系统由安保老周统一管理：员工刷卡进楼、访客领临时手环、每个房间有独立的放行单、监控室记录着每一次刷卡，物业每年还组织安全评级——这套「园区安保体系」，就是 AWS 上的 IAM（身份与访问管理）权限模型。 对刚入职的 AI 研究员小雅来说，门禁不是限制，而是保护：数据不被乱删、模型不被外人碰、每个服务只做自己分内的事。这篇教程会跟着小雅在园区的第一周，讲透 IAM 的用户与角色、策略设计、最小权限、跨服务授权、安全审计、合规检查，以及落地时的权衡取舍。你会发现，云上 AI 的安全防线，本质就是一套做得极其精细的「门禁规则」。

岗位关联

理解 IAM 权限模型是云上 AI 系统的安全地基：掌握它，你才能在团队中设计出既高效又合规的 AI 服务访问方案，成为 AI 基础设施团队里不可或缺的安全守门人。

目录
  1. 可视化演示
  2. IAM基础架构：工牌、部门和访客证
  3. 策略设计原则：门禁放行单的写法
  4. 最小权限实践：只开必须的门
  5. 跨服务授权：部门间的临时通行
  6. 安全审计方案：监控录像与巡检
  7. 合规检查流程：年度安保评级
  8. 落地权衡决策：集中门禁还是分楼管理
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示AWS AI服务中IAM身份-策略-服务三层权限模型、最小权限原则对比及CloudTrail安全审计流水线。

本节配有交互动效（进入视口后自动加载，约 3KB）。

IAM权限模型架构 身份-策略-服务三层授权 Allow=Effect:Allow AND Resource:Match 统一权限控制

IAM基础架构：工牌、部门和访客证

老周领着小雅来到园区主门，指着闸机说：「这里不认脸，只认工牌。」每位员工入职都会领到一张长期工牌，这就是 IAM 用户；刷卡按部门放行，算法部、数据部、安全部各有各的权限，这就是 IAM 用户组；而临时来支援的顾问，领的是限时访客手环，到期自动失效，这就是 IAM 角色。三者合起来，构成了园区（也就是 AWS 账户）里所有身份的基础骨架。

在 AWS 上，一个「身份」要真正干活，还得带上凭证：长期工牌对应 访问密钥（Access Key），用于命令行和 API 调用；访客手环对应 临时令牌，由安全令牌服务（STS）签发，通常几十分钟到几小时就过期。正如小雅不能拿工牌当万能钥匙，每个身份在网络世界里能调用哪些 AI 服务接口，全由凭证背后绑定的权限决定——这就是身份与权限分离的起点。

进一步看，门禁其实有两道闸机。第一道问「你是谁」：刷卡验证工牌真伪，这叫 认证；第二道问「你能做什么」：检查放行单上是否包含你要进的房间，这叫 授权。小雅第一次去数据仓库楼取训练数据，刷工牌通过了认证，却因为放行单上没有「读训练桶」的权限而被拦住——认证通过不代表授权通过，两者是独立判断的。

傍晚，小雅把工牌挂好走出园区，忽然明白：老周说的「认牌不认人」不是冷淡，而是严谨——身份可以被伪造，但一套好的门禁体系会让伪造的成本高到不值得。IAM 基础架构的核心，就是用用户、组、角色三种身份，配合认证与授权的双闸机，把「谁」和「能做什么」彻底分开管理。

访问成功=认证(你是谁)⏟工牌真伪  ∧  授权(你能做什么)⏟门禁放行单\text{访问成功} = \underbrace{\text{认证}(\text{你是谁})}_{\displaystyle \text{工牌真伪}} \;\land\; \underbrace{\text{授权}(\text{你能做什么})}_{\displaystyle \text{门禁放行单}}
通俗地说：认证是「证明你是你」，授权是「允许你做这件事」。两道闸门都打开，访问才成功。
  1. 主体认证先验证身份是否真实有效，相当于闸机读取工牌芯片判定真伪
    Authentication:Principal→{真,假}\text{Authentication}: \text{Principal} \rightarrow \{\text{真}, \text{假}\}
  2. 权限授权再检查该身份是否拥有目标操作权限，相当于匹配房间放行单
    Authorization:Policy(Principal,Action,Resource)→{允许,拒绝}\text{Authorization}: \text{Policy}(\text{Principal}, \text{Action}, \text{Resource}) \rightarrow \{\text{允许}, \text{拒绝}\}
  3. 两者合取认证通过且授权允许，用逻辑与连接，缺一不可
    访问成功=认证真∧授权允许\text{访问成功} = \text{认证真} \land \text{授权允许}

策略设计原则：门禁放行单的写法

第二天，小雅发现每扇门旁边都贴着一张放行单，上面写着：允许算法部成员、在上班时间、进入训练数据间、可以读取和上传但不可以删除。这就是 IAM 策略（Policy）的现实投影——一份用 JSON 写的机器可读放行单。

一张标准的策略 JSON 由几个关键字段组成：Effect 决定放行还是拦截（Allow/Deny）；Action 列出允许或禁止的操作，比如 s3:GetObject 读数据、bedrock:InvokeModel 调模型；Resource 指明作用在哪些资源上，通常写成带 ARN（资源唯一编号）的通配符路径；Condition 附加条件，比如限定来源 IP、限定时间段，相当于放行单上的「仅限工作日」备注。

但门禁最微妙的规则是评估逻辑。老周说：「哪怕放行单写得再漂亮，只要监控室的黑名单里有一条 Deny 命中，谁也进不去。」这就是 IAM 的显式拒绝优先原则：先扫所有 Deny，任何一个匹配就当场拒绝；没有 Deny 命中，再找 Allow；两层都没匹配，默认拒绝（隐式拒绝）。小雅试过在策略里同时写了「允许读取」和「拒绝删除」，结果是读取放行、删除被拦——规则顺序不影响结果，优先级才是关键。

小雅把放行单的三档逻辑抄进笔记本，配了个顺口溜：「黑名单优先，白名单次之，查无此人就关门。」策略设计的原则至此清晰：写清 Effect、圈定 Action 与 Resource、善用 Condition，剩下的交给评估引擎按固定优先级裁决。理解这一点，是后面所有安全实践的地基。

Decision={Deny,∃ 显式拒绝Allow,∃ 显式允许∧¬∃ 显式拒绝Deny,全部不匹配（隐式拒绝）\text{Decision} =\begin{cases}\text{Deny}, & \exists\, \text{显式拒绝} \\\text{Allow}, & \exists\, \text{显式允许} \land \lnot \exists\, \text{显式拒绝} \\\text{Deny}, & \text{全部不匹配（隐式拒绝）}\end{cases}
决策分成三档：有显式 Deny 直接拒绝；没有 Deny 但找到 Allow 才放行；什么都没有就默认拒绝。记住「黑名单最高，白名单其次，没名单最惨」。
  1. 显式拒绝扫描IAM 引擎把所有策略中的 Deny 找出来，只要命中就立即判决拒绝
    ∃ p∈Policies:Effect(p)=Deny⇒拒绝\exists\, p \in \text{Policies}: \text{Effect}(p)=\text{Deny} \Rightarrow \text{拒绝}
  2. 显式允许扫描没有任何 Deny 命中时，再找匹配的 Allow，找到即放行
    ∃ p∈Policies:Effect(p)=Allow⇒允许\exists\, p \in \text{Policies}: \text{Effect}(p)=\text{Allow} \Rightarrow \text{允许}
  3. 隐式拒绝兜底Allow 和 Deny 都未命中，默认拒绝——这是安全默认值
    ¬∃ Allow∧¬∃ Deny⇒拒绝\lnot \exists\, \text{Allow} \land \lnot \exists\, \text{Deny} \Rightarrow \text{拒绝}

最小权限实践：只开必须的门

入职第三天，小雅拿到一份权限审计报告，发现自己居然能删整个训练数据桶。老周把她叫到监控室：「你平时只做读数据、跑训练、写模型日志三件事，为什么要给你开全部权限？这不是信任问题，是风险问题。」这句话引出了 IAM 最著名的原则——最小权限：每个身份只拥有完成本职工作所需的最小权限集合。

落地最小权限有几个抓手。第一是 权限边界（Permissions Boundary）：像给工牌划一道「不可逾越的上限」，即使角色绑定了高权限策略，实际生效的权限也不会超出边界，相当于「你最多能进这些楼，再多说也没用」。第二是 仅需授权：写策略时从白名单思维出发，只列明确要用的 Action 和 Resource，而不是从云厂商的全权限模板里删改。第三是 持续收敛：权限不是一次配置就结束，要定期清理闲置角色、回收未使用的策略，像整理衣柜一样不断扔掉不穿的衣服。

有效权限的计算，可以看作「策略并集」与「权限边界」的交集。小雅的角色绑定了三份策略，每份的权限合并成一个大集合，但权限边界像一把剪刀，把超出工作范围的部分剪掉。她终于明白：权限配置不是「越多越安全」，而是「越精准越安全」。

小雅把访问密钥从训练脚本里删掉，换成了绑定最小权限的角色，并在策略里只保留了 s3:GetObject 和 logs:PutLogEvents。一周后她感慨：最省心的安全配置，不是给人戴上最重的枷锁，而是把每个人本不需要的钥匙提前回收——这正是最小权限的智慧。

Peffective=(⋃i=1nPi)∩PboundaryP_{\text{effective}} = \left( \bigcup_{i=1}^{n} P_i \right) \cap P_{\text{boundary}}
多个策略的权限先取并集（叠加），再和权限边界取交集（收窄）。并集保证能干活，边界保证不越界。
  1. 策略并集一个角色绑定多份策略，权限会叠加成并集而非交集
    Punion=⋃i=1nPiP_{\text{union}} = \bigcup_{i=1}^{n} P_i
  2. 边界取交若设置了权限边界，真正生效的权限是并集与边界的交集
    Peffective=Punion∩PboundaryP_{\text{effective}} = P_{\text{union}} \cap P_{\text{boundary}}
  3. 最小化目标理想状态是有效权限恰好覆盖任务所需，不多不少
    Prequired⊆Peffective⊆PboundaryP_{\text{required}} \subseteq P_{\text{effective}} \subseteq P_{\text{boundary}}

跨服务授权：部门间的临时通行

周四，小雅要跑一个大规模训练任务。训练服务需要自己去数据仓库楼取数据、去模型楼写产物，但训练服务不是人，它没有工牌。老周给了她一张「服务角色」申请表：为训练服务创建一个专用角色，让服务在运行时扮演这个角色去干活——这就是 IAM 角色在服务场景下的典型用法。

角色要能被扮演，必须先通过 信任策略（Trust Policy）这道关卡。信任策略写在角色身上，内容类似于「允许 SageMaker 服务代表我使用这个角色」，它决定了「谁有资格扮演我」。小雅配置时特别注意：信任策略里只写入 SageMaker 这一个服务，绝不写 * 通配，否则园区里任何服务都能借这个角色乱跑。这就像访客登记表上只填了「算力楼后勤」一个名字，其他部门代领手环一律不认。

扮演成功后，安全令牌服务（STS）会颁发一组临时凭证——限时手环，有效期默认一小时，到期自动作废，无需人工回收。整个链条可以画成一张接力图：训练服务先发起扮演请求，角色核验信任策略，通过后颁发临时令牌，服务再持令牌访问目标资源。和长期密钥相比，临时令牌的最大好处是「过期」：就算手环被偷，一小时后它自己就失效了。

训练任务顺利跑完后，小雅在控制台看到那组临时凭证早已过期归零。她意识到：跨服务授权解决的不只是「怎么让服务有权限」，更是「怎么让权限自己会过期、会消失」。在 AI 工作流里，训练、推理、数据管道环环相扣，用好服务角色和信任策略，才能让每个环节都拿到恰好够用的临时钥匙。

ServiceA→AssumeRole(扮演)RoleB→临时令牌(有期限)ResourceC\text{Service}_A \xrightarrow{\text{AssumeRole(扮演)}} \text{Role}_B \xrightarrow{\text{临时令牌(有期限)}} \text{Resource}_C
跨服务授权的本质：服务 A 通过扮演角色 B 获得一张限时通行证，再拿这张证去访问资源 C。全程没有长期密钥，证到点就失效。
  1. 发起扮演请求服务 A 带着自身身份调用 STS 的 AssumeRole 接口，申请扮演角色 B
    STS.AssumeRole(PrincipalA,RoleB)\text{STS.AssumeRole}(\text{Principal}_A, \text{Role}_B)
  2. 信任策略校验角色 B 的信任策略检查 A 是否在可信名单中，匹配才允许继续
    TrustPolicy(RoleB,PrincipalA)=匹配⇒允许扮演\text{TrustPolicy}(\text{Role}_B, \text{Principal}_A) = \text{匹配} \Rightarrow \text{允许扮演}
  3. 令牌换访问校验通过后 STS 颁发临时凭证，A 持令牌访问资源 C，超时自动失效
    Credential临时→Scope 受限ResourceC\text{Credential}_{\text{临时}} \xrightarrow{\text{Scope 受限}} \text{Resource}_C

安全审计方案：监控录像与巡检

周五下午，老周带小雅走进监控室，满墙屏幕滚动着刷卡记录。「这是 CloudTrail，园区里每一次刷门禁、按电梯、进机房，全部留痕。」在 AWS 上，CloudTrail 会记录所有 API 调用日志：谁调的、调了什么接口、作用于哪个资源、什么时间，一条不落。AI 服务的每一次模型调用、每一次数据读取，都在日志里。

光有录像还不够，还需要巡检。老周指着另一个屏幕说：「这是 Access Analyzer——门禁巡检员。它每天分析所有放行单和信任关系，专门揪出「本不该对外开放的权限」，比如某个角色不小心被设置成可以被外部账号扮演，或者某个 S3 桶策略允许了公网访问。」这类问题单靠人眼很难发现，Access Analyzer 的价值就是把「看不见的敞口」变成一条条可处理的告警。

更高级的监控是异常告警。园区会为每位员工建立「日常动线基线」：几点刷卡、常去哪栋楼、平均刷几次。如果某天凌晨三点，小雅的工牌突然在数据仓库楼连刷五十次，系统算出的异常得分就会爆表。AWS 上可以用基线统计配合 Athena 查询日志，或用 GuardDuty 做威胁检测，当偏差超过阈值就通知安全团队。

小雅看着监控屏上自己白天的刷卡轨迹，终于理解「审计」二字的重量：日志不是用来事后追责的摆设，而是用来提前发现异常的雷达。CloudTrail 记录事实，Access Analyzer 暴露敞口，异常检测捕捉反常——三者配合，才能让 AI 服务的安全状态始终「看得见、说得清」。

异常得分=∣ x−μ基线 ∣σ基线\text{异常得分} = \frac{\left|\, x - \mu_{\text{基线}}\, \right|}{\sigma_{\text{基线}}}
把当前行为和历史基线比较：偏离得越远，得分越高。超过预设阈值就触发告警，防止「水煮青蛙」式的缓慢异常。
  1. 建立历史基线统计过去一段时间内某主体行为的均值 μ 与波动 σ，相当于记住每个人的日常动线
    μ=1N∑i=1Nxi,σ=1N∑i=1N(xi−μ)2\mu = \frac{1}{N}\sum_{i=1}^{N} x_i, \quad \sigma = \sqrt{\frac{1}{N}\sum_{i=1}^{N}(x_i - \mu)^2}
  2. 计算偏差距离当前行为 x 与基线均值之差除以标准差，得到标准化偏离程度
    z=∣x−μ∣σz = \frac{|x - \mu|}{\sigma}
  3. 阈值判定z 超过预设阈值 θ 即触发告警，比如深夜突然批量调用模型推理
    z>θ⇒Alertz > \theta \Rightarrow \text{Alert}

合规检查流程：年度安保评级

月底，园区请来第三方评测机构做年度安保评级。评测机构不关心哪扇门好不好看，只对照清单逐项检查：是否禁用了根账号日常使用？是否启用了多因素认证？密钥是否定期轮换？权限是否遵循最小权限？这份清单，就是云安全领域的合规框架——SOC 2、ISO 27001、PCI DSS 等，各有各的检查项，但核心都指向同一件事：你的身份与权限管理是否可证明地安全。

合规不是一次性考试，而是定期审查的循环。小雅所在的 AI 团队每季度做一次权限复盘：导出所有 IAM 策略，比对实际使用情况，删除三个月内零调用的角色；检查信任策略里有没有出现 * 通配或陌生账号；核对 CloudTrail 是否完整开启。每一次审查，都可能发现「权限漂移」——比如某次排障时随手加了一条临时放行，事后忘了撤，权限就悄悄扩大了。

人工审查总有疏漏，所以园区还引入了自动化检查。AWS Config 可以持续扫描资源，用托管规则自动判定「该启用的服务是否启用、该限制的访问是否放开」；配合 Systems Manager 的定时脚本或 CI/CD 流水线，每周自动生成合规报告，不合规项直接派发整改工单。自动化把「想起来才查」变成「每天替你查」。

评级结果出来，园区拿到 A 级。老周对小雅说：「评级不是墙上的奖状，而是让客户敢把数据放进来的底气。」合规检查的本质，是把零散的安全操作标准化、证据化——当 AI 服务要服务金融、医疗客户时，这份「可证明的安全」往往比技术本身更能赢得信任。

合规=⋀i=1n检查项i(账号,资源)\text{合规} = \bigwedge_{i=1}^{n} \text{检查项}_i(\text{账号}, \text{资源})
合规 = 所有检查项同时通过。逻辑与的合取意味着：任何一个检查项失败，整体就不合规——像体检报告里有一项超标就得复查。
  1. 控制项定义合规框架把安全要求拆成一系列可判定的检查项，相当于体检清单
    检查项i:账号×资源→{通过,失败}\text{检查项}_i: \text{账号} \times \text{资源} \rightarrow \{\text{通过}, \text{失败}\}
  2. 全局合取所有检查项必须同时为「通过」，用逻辑与逐项连接
    合规=检查项1∧检查项2∧⋯∧检查项n\text{合规} = \text{检查项}_1 \land \text{检查项}_2 \land \cdots \land \text{检查项}_n
  3. 短板效应任意一项失败整体即不合规，整改后需重新检查
    ∃ i:检查项i=失败⇒不合规\exists\, i: \text{检查项}_i = \text{失败} \Rightarrow \text{不合规}

落地权衡决策：集中门禁还是分楼管理

小雅在园区待满一周，开始思考更深的问题：门禁系统应该由总部统一管，还是让每栋楼自己管？这就是 IAM 治理中的集中与分散权衡。集中管控（比如把所有 AI 服务的角色都集中在安全团队手里）便于统一审计、口径一致，但响应慢，团队加个权限要走三天流程；分散自治让各团队灵活调整，但风格容易失控，出现「一个园区五十套门禁规则」的混乱。成熟的做法通常是分级治理：核心数据楼集中管控，创新实验楼适度放权。

第二个决策点是密钥轮换频率。长期密钥就像宿舍钥匙，用得越久，被复制的风险越大。安全团队面临一个权衡：频繁轮换更安全，但每轮换一次，所有依赖旧密钥的脚本、服务都要跟着更新，可能引发停机。工程上的折中是：能不用长期密钥就不用，一律走临时令牌；必须用的长期密钥，设置最短轮换周期（比如 90 天），并用 Secrets Manager 自动托管和轮换。

第三个决策点是多账户隔离。一座园区可以划分成独立楼栋：开发楼、测试楼、生产楼，各自独立核算、独立报警。AWS 上的多账户策略（比如用 Organizations 按环境建账号）把故障和安全事件的「爆炸半径」限制在一个账户内——就算开发环境被攻破，生产环境的模型和数据也毫发无损。当然，多账户也会带来管理成本，需要借助控制塔（Control Tower）等工具统一铺底策略。

一周下来，小雅从「拿到工牌就开心」的新人，成长为能独立设计团队门禁方案的负责人。她终于明白：IAM 从来不是「配一次就完事」的静态清单，而是一连串动态权衡——集中与分散、安全与效率、隔离与成本，每一条决策都在为「安全」和「好用」之间找那个合理的甜点。掌握这套权衡思维，才是 IAM 最佳实践真正的精髓。

风险期望=P(凭证泄露)×影响×凭证有效期\text{风险期望} = P(\text{凭证泄露}) \times \text{影响} \times \text{凭证有效期}
安全风险由泄露概率、影响范围、有效期三个因子相乘决定。最小权限压缩影响，轮换和临时令牌压缩有效期——两个因子一起降，风险自然变小。
  1. 泄露概率凭证出现在错误位置的频率，比如被硬编码进代码仓库的概率
    P(泄露)∝1管控强度P(\text{泄露}) \propto \frac{1}{\text{管控强度}}
  2. 影响范围泄露后能触碰的数据和服务面，最小权限直接压缩这个因子
    影响=∑可访问资源敏感度\text{影响} = \sum_{\text{可访问资源}} \text{敏感度}
  3. 有效期压缩轮换密钥和临时令牌把有效期从「年」压到「小时」，风险随之线性下降
    风险∝T有效期\text{风险} \propto T_{\text{有效期}}

AI 应用场景

场景一：模型训练中的跨服务免密授权

阶段：模型训练 / 数据准备

解决的问题：训练任务需要读取 S3 中的训练数据并写回模型产物。传统做法常把长期访问密钥写进训练脚本或环境变量，密钥一旦被容器镜像泄露，整个数据桶就暴露了。用 IAM 服务角色后，训练容器通过 STS 自动获取临时凭证，全程无硬编码密钥。

具体案例：小雅在 SageMaker 提交训练任务时，在控制台选择了一个预先创建的 SageMaker 执行角色。该角色的策略只允许读取 ai-data/train 桶、写入 ai-model/output 桶，信任策略限定仅 SageMaker 可扮演。训练容器启动后自动获得一小时有效期的临时令牌，任务结束令牌即失效。

场景二：生成式 AI 应用的调用审计

阶段：模型推理 / 运维监控

解决的问题：Bedrock 等生成式 AI 服务的每次模型调用都耗费成本、可能触及敏感数据，安全团队需要知道「谁在什么时间调用了哪个模型」。没有审计，违规调用和密钥滥用无法被追溯。

具体案例：安全团队开启 CloudTrail 并创建跟踪事件，将 bedrock:InvokeModel 等调用日志投递到 S3，再用 Athena 做 SQL 分析：统计各用户调用频次、按小时聚合异常峰值；同时启用 IAM Access Analyzer，对允许外部主体访问的角色生成发现结果并逐一整改。

场景三：MLOps 流水线的最小权限落地

阶段：模型部署 / CI/CD

解决的问题：模型从训练到上线要经过构建、测试、部署多个环节，每个环节如果共用一把「万能钥匙」，一次流水线攻破就可能波及生产端点。最小权限要求每个环节各配一个专用角色，权限收窄到只碰自己的资源。

具体案例：为 CodePipeline 的部署阶段单独创建角色，策略只允许 sagemaker:UpdateEndpoint 和 sagemaker:DescribeEndpoint，且 Resource 用参数化 ARN 锁定到指定端点；触发凭证由服务动态签发，团队半年内未再发生过「误操作删掉生产模型」的故障。

Python 演示

python57 行
import fnmatch  class PolicyEvaluator:    """模拟 AWS IAM 权限评估：显式 Deny 优先于 Allow，默认隐式拒绝。"""     def __init__(self):        self.policies = []     def add_policy(self, effect, actions, resources, principal="*"):        self.policies.append({            "effect": effect,            "principal": principal,            "actions": list(actions),            "resources": list(resources)        })     def match(self, rule, principal, action, resource):        if rule["principal"] != "*" and rule["principal"] != principal:            return False        if not any(fnmatch.fnmatch(action, a) for a in rule["actions"]):            return False        if not any(fnmatch.fnmatch(resource, r) for r in rule["resources"]):            return False        return True     def evaluate(self, principal, action, resource):        for rule in self.policies:            if rule["effect"] == "Deny" and self.match(rule, principal, action, resource):                return "deny"        for rule in self.policies:            if rule["effect"] == "Allow" and self.match(rule, principal, action, resource):                return "allow"        return "deny"  # 隐式拒绝：没有任何策略命中  def main():    ev = PolicyEvaluator()    ev.add_policy("Allow", ["s3:GetObject", "s3:PutObject"],                  ["arn:aws:s3:::ai-data/*", "arn:aws:s3:::ai-data/train/*"],                  principal="scientist")    ev.add_policy("Deny", ["s3:DeleteObject", "s3:PutObject"],                  ["arn:aws:s3:::ai-data/prod/*"], principal="scientist")     cases = [        ("scientist", "s3:GetObject", "arn:aws:s3:::ai-data/train/set.csv"),        ("scientist", "s3:PutObject", "arn:aws:s3:::ai-data/prod/model.bin"),        ("scientist", "s3:DeleteObject", "arn:aws:s3:::ai-data/train/set.csv"),        ("engineer", "s3:GetObject", "arn:aws:s3:::ai-data/train/set.csv"),    ]    for principal, action, resource in cases:        result = ev.evaluate(principal, action, resource)        print(f"{principal:10s} {action:20s} -> {result}")  if __name__ == "__main__":    main()
目的：用不到 60 行实现一个简化版 IAM 策略评估器，验证「显式 Deny 优先于 Allow、无匹配则隐式拒绝」的核心规则。
  1. def match(self, rule, principal, action, resource):检查一条策略是否同时满足主体、操作、资源三个条件，相当于门禁放行单的逐项比对
  2. if rule["effect"] == "Deny" and self.match(...)第一轮先扫全部显式拒绝，命中立即返回 deny，体现黑名单最高优先级
  3. if rule["effect"] == "Allow" and self.match(...)第二轮才看允许，只有无 Deny 命中时 Allow 才生效
  4. return "deny" # 隐式拒绝两层都没命中就默认拒绝，这是 IAM 的安全兜底
  5. fnmatch.fnmatch(action, a)用通配符匹配 Action 和 Resource，支持 s3:Get*、arn:aws:s3:::ai-data/* 这类写法
  6. ev.add_policy("Deny", [...], ["arn:aws:s3:::ai-data/prod/*"], ...)演示「允许写入普通目录，但生产目录显式拒绝」的精细化策略

常见误区

误区刚接触云上 AI 服务时，觉得用根账号（相当于园区总钥匙）最方便，省去配用户建角色的麻烦，一人一钥匙，想操作什么就操作什么。

正解根账号拥有账户内所有权限，且无法被策略限制，是风险最高的身份。一旦根密钥泄露，攻击者可以删除所有 AI 模型、窃取全部训练数据、修改账单。最佳实践是：为 root 启用 MFA，创建日常使用的 IAM 用户和角色，root 只用于极少数账户级操作。就像园区总钥匙锁在保险柜里，日常开门用个人工牌。

为何常见：小团队起步时觉得「配置 IAM 是只有大公司才做的事」，把省事误当成效率，忽略了 root 的高危性恰恰在于「省事的代价是零防护」。

误区为了「保险」，把多个高权限策略都绑到同一个角色上，觉得策略越多、覆盖越全，就越不容易出问题。

正解IAM 中多个策略的权限是取并集的——绑的策略越多，有效权限越大，攻击面反而越宽。安全来自「收窄」而非「堆叠」：用最小权限原则只保留任务必需的 Action 和 Resource，再辅以权限边界设上限。放行单写得越精炼，出错的概率越低。

为何常见：人们常把「安全」误解为「加东西」，就像以为防盗门装得越多越安全，却忘了每多一扇门都多一个可能被撬的锁。

误区写策略时以为和防火墙规则一样，后面的规则覆盖前面的，于是把 Deny 放在 Allow 后面保证「最后说了算」。

正解IAM 策略的评估结果与书写顺序完全无关，决定权在优先级：显式 Deny 永远压过一切 Allow；没有 Deny 时 Allow 才生效；都没有则隐式拒绝。无论策略 JSON 里 Deny 写在前面还是后面，只要匹配就会拦截。这好比黑名单永远优先于门禁放行单执行。

为何常见：很多人从防火墙 ACL 或代码覆写的经验迁移过来，想当然地认为「后配置优先」，却没有理解 IAM 是一套独立的、以 Deny 为最高优先级的判定模型。

误区让训练服务访问 S3 时，直接把一组长期访问密钥配置到服务环境变量里，觉得「给钥匙最直接」，反正密钥在内部环境不会泄露。

正解长期密钥无论放在哪儿都是「不定时炸弹」——容器镜像会被共享、日志会打印环境变量、源码仓库可能被拖库。正确做法是创建服务角色，用信任策略限定只有指定服务能扮演，再通过 STS 获取临时令牌访问资源。临时令牌会自动过期，泄露风险窗口被压缩到分钟级。

为何常见：长期密钥的「配置简单、一次到位」让人产生路径依赖，忽略了它背后「永不失效」的巨大隐患；跨服务角色的委托模型则需要多几步配置，容易被视为麻烦。

误区在控制台开启了 CloudTrail 日志后，就觉得「反正有记录了」，从此不再看日志，也没有配置任何告警。

正解审计日志的价值在于「被分析、被告警、被行动」。如果日志躺在 S3 里无人问津，攻击者早就利用完漏洞离开了。有效实践是：用 Athena 定期查询异常调用、用 Access Analyzer 扫描外部访问敞口、用基线偏差算法触发实时告警。录像不还原到现场，监控就只是摆设。

为何常见：人们容易把「留痕」误当作「防护」，觉得只要有记录就尽到了责任；实际上从日志到告警再到处置，是一整条需要主动运营的链路。

面试题

Q1. 在 IAM 中，哪种身份实体最适合表示「临时借用的项目权限」？

单选题 · easy

  • A.IAM 用户（长期固定工牌）
  • B.IAM 角色（临时通行证）← 正确答案
  • C.用户组（部门成员分组）
  • D.根账号（园区总钥匙）

答案：B。IAM 角色没有长期凭证，通过被扮演获得临时令牌，天然适合临时借用的场景。用户是长期身份，组是批量管理用户的容器，根账号是账户级超级身份，都不具备「临时、可扮演」的特性。

Q2. 关于 IAM 权限评估中 Deny 与 Allow 的优先级，下列说法正确的是？

单选题 · easy

  • A.Allow 永远优先于 Deny
  • B.Deny 与 Allow 的作用完全相同
  • C.显式 Deny 优先于一切 Allow← 正确答案
  • D.后配置的策略优先生效

答案：C。IAM 评估逻辑中显式 Deny 拥有最高优先级，任何匹配的 Deny 都会直接覆盖 Allow。这与书写顺序无关，也与策略数量无关。理解「黑名单优先」是读懂 IAM 一切权限行为的前提。

Q3. 下列哪个 AWS 服务专门记录 API 调用日志，用于安全审计？

单选题 · easy

  • A.AWS Config（资源检查）
  • B.AWS CloudTrail（行为录像）← 正确答案
  • C.AWS Shield（流量防护）
  • D.AWS WAF（网络过滤）

答案：B。CloudTrail 记录账号内所有 API 调用事件，包括谁调用、调用什么、作用于哪个资源、何时发生，是审计的日志底座。Config 管配置合规、Shield 抗 DDoS、WAF 过滤 Web 流量，都不承担 API 调用审计职责。

Q4. 调用 STS 的 AssumeRole 接口后，调用方获得的是什么？

单选题 · mid

  • A.长期有效的访问密钥对
  • B.账号根凭据的副本
  • C.临时安全令牌与临时密钥← 正确答案
  • D.一个新的 IAM 用户

答案：C。AssumeRole 的核心输出是临时凭证，包含临时访问密钥和安全令牌，并带有效期（默认 1 小时）。它不会生成长期密钥，也不会克隆根凭据或创建 IAM 用户，这正是跨服务授权的安全基础。

Q5. 服务角色的「信任策略」主要解决什么问题？

单选题 · mid

  • A.规定角色能执行哪些操作
  • B.决定哪些主体可以扮演该角色← 正确答案
  • C.统一角色命名与编号规范
  • D.设置角色登录密码强度

答案：B。信任策略是角色的「准入门槛」，它声明「谁有资格扮演我」，比如只允许 SageMaker 服务扮演。角色能执行什么操作由权限策略决定，与信任策略职责不同；命名规范和密码强度与信任策略无关。

Q6. 关于权限边界（Permissions Boundary），下列说法正确的是？

单选题 · mid

  • A.权限边界能够扩大角色的权限
  • B.权限边界限制有效权限的上限← 正确答案
  • C.权限边界只在审计时才生效
  • D.权限边界完全替代其他策略

答案：B。权限边界是有权权限的天花板：角色实际生效的权限 = 所有策略并集 ∩ 权限边界。它只能收窄不能扩大，始终参与每次请求的评估，也不能替代其他策略，而是与其他策略叠加约束。

Q7. IAM Access Analyzer 的核心能力是什么？

单选题 · hard

  • A.自动生成新的访问密钥
  • B.发现可能被外部主体访问的资源← 正确答案
  • C.完全替代 IAM 的身份认证
  • D.自动加密所有 S3 存储桶

答案：B。Access Analyzer 持续分析资源策略和信任策略，找出「允许外部访问」的敞口，比如策略中意外出现的 Principal: "*" 或跨账号信任。它不生成密钥、不替代认证、不负责加密，专注发现过度暴露。

Q8. 下列哪些行为违反了最小权限原则？

多选题 · easy

  • A.给算法工程师授予 S3 全权限← 正确答案
  • B.为每位员工创建专属 IAM 用户
  • C.生产环境用根账号做日常操作← 正确答案
  • D.为 API 调用配置长期访问密钥← 正确答案

答案：ACD。算法工程师只需读写特定桶，S3 全权限明显越界；根账号拥有无上限权限，日常操作违反最小权限；长期密钥让权限永不过期，扩大风险窗口。为员工创建专属用户是身份隔离的正确做法，不违反最小权限。

Q9. 保护根账号的推荐做法包括哪些？

多选题 · mid

  • A.启用多因素认证（MFA）← 正确答案
  • B.完全禁用根账号所有权限
  • C.避免用根账号做日常运维← 正确答案
  • D.把根密钥共享给全体开发

答案：AC。根账号应启用 MFA 并封存，仅用于极少数账户级操作。根账号无法被完全禁用，其设计上保留账户级权限；共享根密钥是严重违规行为，会让整个账户失去保护。正确姿势是日常用 IAM 用户和角色。

Q10. 在 AI 工作流的跨服务授权场景中，正确的安全做法包括？

多选题 · hard

  • A.使用服务角色替代长期密钥← 正确答案
  • B.信任策略限定授予方账号← 正确答案
  • C.角色绑定最小权限策略← 正确答案
  • D.把角色名称写进代码仓库共享

答案：ABC。服务角色配合信任策略与最小权限策略，是跨服务授权的最佳组合：角色提供临时凭证、信任策略限定谁可扮演、权限策略限定能做什么。把角色信息写进代码仓库会让凭证配置信息泄露，破坏安全边界。