IAM权限--练习题做完这套题你对权限的理解会上一个台阶我刚接手一个后台系统权限梳理的时候碰上过一件挺头疼的事一个只负责看报表的账号不知道什么时候被塞进了一个“系统管理员”角色结果在一次误操作里把生产环境的配置项清掉了一部分。复盘的时候对方很无辜“我就是想看看日志方便排查问题。”问题就出在大家嘴上都说权限很重要但真正上手判断“谁能对哪个资源做什么”的时候全凭感觉。所以我花了不少时间整理了一套IAM权限练习题用来给团队做准入考核也用来做不定期的权限自查。今天把题目和拆解逻辑一并分享出来。这套题不绑定具体某个云平台主要看的是身份与访问管理IAM的通用规则主体、资源、动作、条件之间的关系以及权限叠加、角色继承、临时授权、跨账号访问这些高频场景。对刚接触IAM的初级运维、后端开发或者正打算系统梳理权限的团队成员来说应该都能直接用上。1. 先摸清权限题的“四要素”再谈做题很多人做权限题容易懵是因为一上来就盯着“能不能访问”这个结果忽略了权限判断其实是一套有输入条件的逻辑计算。做IAM题目首先得把四要素在脑子里立起来谁主体、对什么资源、做什么动作、在什么情况下条件。1.1 主体、资源、动作、条件一个都不能少主体用户、用户组、角色、服务账号等。题目里最常见的坑是“用户A通过角色拿到权限”和“用户A直接绑定策略拿到权限”这两条路径经常同时存在。资源可以是单个对象、一个目录、一类资源集合也可以是某个项目下的全部资源。动作读、写、删除、列出、创建、修改配置等。读和写都分清楚很多事故就是“只读账号”变成了“可写账号”。条件包括IP范围、时间段、是否多因素认证、请求来源、资源标签等。没有条件约束的授权相当于门禁卡在任何时间任何地点都能刷开。把这四个要素列成一张表题目就不会乱了。我自己的习惯是拿到任何一道IAM题先画一张简单的表格主体是谁资源范围是什么动作有哪些条件限制是什么然后才去看策略最终算出什么结果。1.2 权限判定的底层逻辑先看允许再看拒绝大多数IAM系统的判定结果可以抽象为三条规则默认拒绝没有任何显式允许的时候访问是失败的。允许叠加只要有一条策略允许就算其他策略没写最终也是允许。显式拒绝优先如果有一条策略明确写了拒绝那不管多少条允许都白搭。在练习题里最容易考的就是“允许叠加”和“显式拒绝优先”同时出现。比如某个角色允许写某个存储桶但另外一条策略明确拒绝写这个存储桶最终结果就是拒绝。很多做错的人是因为他记住了“拒绝优先”却忘了先判断策略的生效范围。如果拒绝策略和允许策略作用的是不同资源那根本不会冲突。所以做题第一步不是背结论而是把每一条策略的作用范围划出来。2. 这套题到底想练什么三种容易被忽略的能力有人问我IAM练习题是不是背熟概念就能过我的回答是概念只是门槛真正拉开差距的是下面三种能力区分授权路径的能力、识别隐式拒绝的能力、把业务需求翻译成权限模型的能力。2.1 看清一条权限是从“直接绑定”还是“角色继承”来的直接给用户绑定策略和把用户加入一个角色、再通过角色绑定策略最后的权限效果可能一样但管理含义完全不同。题目常常这么考用户A直接绑定了“读取日志”策略同时又加了“日志操作员”角色角色自带“清空日志”的允许权限。问A最终能做什么答案是都能做。因为权限的集合是所有允许权限的并集。角色不是把用户原来的权限覆盖掉而是新增一批允许项。这个点很反直觉不少人有“角色权限更大应该会覆盖用户原有的小权限”的错误印象。实际上覆盖只有在显式拒绝时才发生。出题人喜欢在这里埋雷就是想让做题的人意识到权限不是“后面覆盖前面”而是“所有允许都会叠加”。2.2 判断“没有写允许”到底是拒绝还是放行IAM的默认规则是隐式拒绝。但题目里经常反过来考某用户只绑定了一条策略策略里只写了“允许读取文件A”那他能读取文件B吗答案是不能因为没有显式允许。很多人会犹豫是不是因为他是文件的创建者所以默认有权限在多数IAM模型里创建资源并不等于默认拥有资源的全部权限资源拥有者权限同样需要授权策略支撑。这条能力放在实操里就是排查问题的基本功。线上出现权限报错时第一步不是去翻“这个用户有没有权限”而是去查“他有哪些允许策略、有没有显式拒绝策略、作用范围是不是覆盖了目标资源”。这种排查习惯用练习提前养成比出事以后再总结要划算得多。2.3 把需求转化成权限策略的建模感第三种能力更接近设计层面。题目常给一个场景“财务人员需要查看账单但只能看本部门的账单运维人员可以重启机器但不能修改配置实习生只有只读权限且只能在办公网段内访问。”要求你设计一套角色和策略。这类题看着没有标准答案其实有非常明确的评价尺度是否采用了最小权限、是否把共享权限抽成了角色、是否给高风险动作加了条件限制、是否考虑了临时场景。练的就是建模感不是单纯的记忆。3. 六道典型练习题从入门到易错完整拆解下面这六道题是我在团队里反复用过的高频题基本覆盖了权限判断的主要套路。每道题我都会完整写一遍题干、易错选项和解析逻辑。建议你先自己闭卷做一遍再看解析。3.1 第一道权限叠加题允许并非“二选一”题干用户A在“数据分析组”组角色绑定了“读取日志”策略。同时管理员单独给A绑定了一条“删除过期日志”的策略。请问A对日志资源的最终权限是什么选项一只能读不能删因为组角色的权限边界限制了个人策略选项二能读也能删因为两条策略的允许项叠加选项三能读也能删但删除动作必须经过二次审批选项四无法判断还需要看是否有显式拒绝策略解析正确答案是选项四。前三个选项都预设了一种情况但题干里没有提“显式拒绝”。如果环境里有一条拒绝策略哪怕用户自己绑定了删除策略也会被拒绝。另外组角色和单独策略之间不是互斥关系允许项会叠加。所以单凭题干给出的信息只能判断“允许的并集里含读和删除”但最终结果还要看有没有拒绝项以及拒绝项的作用范围。这道题真正的考点是看到“绑定多个策略”时不要立刻选一个看似最合理的最终权限而是要看完整证据链。3.2 第二道资源范围决定策略是否生效题干某用户绑定了一条“允许列出所有存储桶”的策略但存储桶“project-data”上单独设置了一条资源策略允许该用户对该桶进行读写。请问该用户能否读取project-data里的文件选项一可以因为桶级策略允许读写选项二不可以因为“列出所有存储桶”不等于“读取桶内文件”选项三无法判断因为没有明确是否拒绝了“读取”动作选项四可以但只能通过桶级策略访问不能通过全局列表访问解析正确是选项三。这里最容易选错的是选项二用户确实能列出桶但“读取文件”和“列出桶”是两个不同的动作。桶级策略允许的是读写所以如果没有任何显式拒绝用户是能读文件的。可题目并没有交代是否有一条更高级别的拒绝策略所以严谨的答案是“无法判断”。做题时要把动作粒度拆细——读、写、列、删是四个不同动作每个动作都需要单独授权。3.3 第三道角色继承后子角色还能“变小”吗题干父角色对项目X的“计算资源”有完全管理权限。子角色继承了父角色并且子角色上只写明“允许查看计算资源列表”。用户B被授予子角色问用户B对项目X计算资源的权限是什么选项一只能查看列表因为子角色覆盖了父角色选项二拥有完全管理权限因为继承是叠加关系不是覆盖关系选项三完全没有权限因为子角色只写了查看列表选项四看是否有显式拒绝若有拒绝拒绝优先解析正确是选项四在没有显式拒绝的情况下正确结果是选项二。角色继承在大多数IAM系统里都是“向上叠加”而不是“向下覆盖”。子角色只写了查看不代表父角色的管理权限没了。如果设计上想让子角色“变小”必须显式写拒绝。这道题考的是很多人对继承的误解。现实中角色继承层级越深权限叠加链路越长越容易失控所以练习题才要反复强调“继承不等于覆盖”。3.4 第四道临时授权到期已经在跑的任务怎么办题干管理员给某个账号授予了6小时的临时管理权限6小时后临时权限失效。在失效的一瞬间该账号已经建立的连接还在执行一个数据处理任务。问这个任务会怎样选项一立即中断因为权限已经失效选项二不受影响因为连接建立时权限有效后续沿用会话凭证选项三不一定取决于平台对会话时长和策略生效方式的处理选项四任务继续执行但无法发起任何新的管理操作解析正确是选项三。这是很多人在实操里踩过的坑——以为权限到期就和定时器一样秒级生效。实际上临时授权往往通过短期凭证实现已经有会话可能会沿用原凭证直到凭证过期另外有些系统策略评估是实时的有些则带有生效延迟。做题时不要默认“到期立即切断”而要理解权限策略和凭证有效期是两个维度。这题放在真实环境里非常重要因为临时授权的意义是“缩小风险窗口”而不是“精确定时切断所有动作”。如果你负责的生产系统有长耗时任务临时授权最好加上操作限制而不是只设时间。3.5 第五道最小权限设计的方案选择题干一个脚本仅需要定期读取某服务状态并发送告警。以下三种权限方案哪种最符合最小权限原则方案一给脚本绑定该服务的只读角色同时限定只能读取状态接口方案二给脚本绑定该服务的管理员角色方便调试时使用方案三给脚本绑定所有服务的只读角色防止将来新增需求时再提工单解析正确答案是方案一。方案二明显越权不必多说。方案三是典型陷阱——很多人觉得“只读”安全却忘了把所有服务都开放只读同样扩大了攻击面。一个脚本只需要读A服务状态就不该碰B服务。最小权限设计不是“把权限降成只读就行”而是“只给完成当前任务所必需的最小范围包括资源范围和动作范围”。做题时判断最小权限有三个维度动作降级能读就不写能写就不删、资源收窄单个资源能搞定就不授权整个目录、条件收紧来源IP、网络环境能限定就限定。3.6 第六道跨账号角色跳转信任策略写在哪一边题干账号A需要临时使用账号B的某个数据分析资源。管理员在账号B中创建了一个角色允许账号A的主账号身份代入该角色。请问信任谁、授权谁选项一账号A信任账号B账号A写入角色策略选项二账号B信任账号A账号B写入信任策略选项三账号A信任账号B账号A写入权限边界选项四账号B信任账号A账号A写入权限边界解析正确是选项二。跨账号访问核心是两个部分信任关系谁允许谁进来和权限策略进来之后能干什么。通常做法是被访问方账号B创建角色并在角色的信任策略里写明“允许账号A的某些身份代入”账号A侧则负责把代入动作授权给具体用户。这题的易错点在于把创建角色和信任策略的归属搞反。记住一句话资源在哪边授权责任就在哪边身份在哪边信任声明的受益者就在哪边。4. 复盘易错点做题时反复遇到的四颗地雷题目做多了你会发现出错其实集中在几个固定位置。以下四颗地雷我基本每次培训都会重点点名。4.1 把“创建角色”和“把角色授权给用户”混为一谈创建角色只是定义了一套权限模板不等于任何用户都能用。真正发生授权关系的是“把角色附加到用户/用户组/服务身份上”这一步。很多初级题会给这样一个场景管理员创建了一个“数据库运维”角色但没绑定给任何人问某个用户能否操作数据库。答案是绝对不能因为角色没有被赋予任何主体。我把这个点单独列出来是因为线上排查时有人看到系统里有这个角色就以为权限已经生效了结果折腾了半天。4.2 看到“管理员”三个字就以为是全权限有些题目会在角色名里带“管理员”比如“日志管理员”“备份管理员”。名字容易产生误导。实际判断要以策略内容为准不以角色名称推测权限。一个叫“日志管理员”的角色如果策略里只看日志那他就是只读的一个叫“访客”的角色如果策略里写了删除权限那他就是高风险的。命名只是管理习惯权限结论必须回到策略内容上。这点在练习题里反复出现因为现实中事故往往不是因为名字不够“吓人”而是因为名字太“贴切”导致没人细看策略。4.3 忽略条件项把条件里的限制当成装饰题目里如果出现“仅限内网IP”“需多因素认证”“资源标签必须为prod”这些不是无关信息而是影响判定结果的硬条件。我见过不少选项把条件淡化处理诱导你选择“有权限”。一旦条件不满足策略里的允许项就不能生效。真实的权限排查顺序应当是先看主体的允许项再看策略的作用范围最后看条件项是否满足。三步走完才能下结论。4.4 以为“资源创建者”天然拥有全部权限在部分系统里资源创建者会被自动赋予某些权限但这不是IAM的通用规则。练习题如果专门考这个点往往是提醒你不要凭直觉认为“谁创建的谁就能管”。在实际业务中经常会遇到“开发创建了某个存储桶但权限实际由平台团队统一管理”的情况。如果不特意给开发者配置权限他本人也可能被拒。5. 把练习题转化成权限治理习惯我的实操方法做题只是手段。我把这套题在团队里用了小半年以后总结出了几个让练习真正落地的动作这里分享给你们。5.1 用“权限四要素矩阵”审查每一个策略我建议你每拿到一个权限变更需求都先填一张小矩阵而不是直接改策略主体资源范围动作条件预期效果应用服务A项目X下的存储桶读、列来源IP限内网只读访问不写不删运维小组所有计算实例重启、查看状态需多因素认证运维操作必须二次验证实习生账号测试环境资源读办公网段禁止外网访问测试环境填完以后再做一次反问动作能不能再砍一个资源范围能不能再缩一层条件够不够严这套流程走下来权限设计一般不会出大问题。5.2 在隔离环境里把练习题“跑”一遍如果你们有测试用的云账号或模拟系统强烈建议把这套题中的场景在隔离环境里真实配置一遍。比如第三道角色继承题建一个父角色和一个子角色分别绑定再模拟用户去调用接口看看实际返回。很多抽象概念自己在控制台点一次就通了。我自己带新人时基本都用这个方式比口头讲十遍都有效。5.3 把错题当成权限评审的输入每个人做这套题错的点往往不一样但集中错误往往反映系统的真实问题。比如团队里很多人把“角色继承”理解错那真实环境中层级深的角色一定存在隐患。我会把这些错题记录整理成评审清单定期对线上角色做一次回溯有哪些角色继承层级超过了三层有没有角色名字叫“只读”但策略里有写权限这种从练习反哺线上治理的方式收益非常明显。6. 最后分享一个练题之外的排查技巧这套题做熟了以后真正帮我提高的反而不是题本身而是养成了一个“先列策略、再下结论”的习惯。遇到权限报错我会先打开策略列表把“允许项、拒绝项、资源范围、条件项”逐个看一遍再来判断是不是配置漏了或条件不满足而不是让用户反复试错。另外我习惯把容易混淆的权限判断题做成小卡片放在文档库里每次权限评审开始前让相关同事快速回答两三道。这种做法不需要专门腾时间培训几次评审下来团队的权限敏感度提升非常明显。如果你也在负责权限相关的工作不妨从我上面这六道题开始把它们当成日常评审的检查题用相信你也会发现很多原本要踩坑才能总结出来的经验提前用题目复盘一次能省下不少线上事故的善后成本。