IAM 权限模型底层原理

目录 身份认证确认“你是谁”⚙️ 授权流程决定“你能做什么”⚖️ 核心决策逻辑默认拒绝与显式拒绝 策略类型与影响范围 底层访问控制模型的融合IAM 权限模型的底层原理可以概括为以“默认拒绝”为基石通过“身份认证”确认请求者是谁再经由“策略评估引擎”对“请求上下文”与“策略规则”进行匹配最终做出“允许”或“拒绝”的授权决策。其核心运作流程与关键机制如下 身份认证确认“你是谁”在授权之前IAM 必须首先验证请求主体的身份。主体是使用实体如用户、角色来发送请求的人员或应用程序。认证凭据主体通过其登录凭据如用户名密码、访问密钥向 IAM 证明身份。IAM 会将凭据与可信的委托实体如 IAM 用户、角色进行比对。认证方式认证方式多样包括根用户密码、IAM 用户的长期凭据、或通过角色扮演获取的临时凭据。对于联合身份则由外部身份提供商IdP验证身份后传递凭据给 AWS。安全增强通常建议启用多重验证MFA来增强安全性。⚙️ 授权流程决定“你能做什么”当认证通过后主体发起的每一个操作请求都会进入授权评估流程。构建请求上下文当一个主体尝试执行操作时例如通过控制台、API 或 CLI会向 AWS 发送一个请求。这个请求包含了 IAM 评估所需的全部信息即请求上下文主要包括动作/操作主体想要执行的具体操作。资源操作所针对的目标 AWS 资源。主体发送请求的人员或应用程序。环境数据如 IP 地址、时间戳等。资源数据与请求资源相关的数据如标签。策略评估引擎IAM 使用请求上下文中的值找出所有适用于该请求的策略并逐一进行评估。这些策略主要以 JSON 文档形式存储明确了“谁”在“什么条件”下可以对“哪些资源”执行“什么操作”。⚖️ 核心决策逻辑默认拒绝与显式拒绝IAM 的策略评估遵循一套严格的布尔逻辑其核心原则是默认拒绝Default Deny所有的请求在初始状态下都被视为拒绝。只有在策略中被显式允许的操作才会被最终授权。显式拒绝优先Explicit Deny Overrides如果任何一条适用的策略中包含了针对该操作的显式拒绝那么无论其他策略是否允许该请求都会被无条件拒绝且评估过程会立即停止。允许的必要条件要让一个请求被允许请求的每一个部分动作、资源等都必须在至少一条适用的许可策略中被显式允许。 策略类型与影响范围在授权决策中不同类型的策略扮演着不同的角色身份型策略Identity-based Policies附加到 IAM 用户、组或角色上定义了该主体可以做什么。这是最常用的策略类型用于控制主体在其账户内的权限。资源型策略Resource-based Policies直接附加到资源上如 S3 存储桶定义了谁可以对这个资源做什么。它是实现跨账户访问的关键机制。 底层访问控制模型的融合IAM 的底层设计并非单一模型而是融合了多种经典访问控制思想以适应不同的授权场景基于角色的访问控制RBAC通过引入“角色”作为用户与权限之间的中间层简化了权限管理。将权限赋予角色再将角色赋予用户比直接管理每个用户的权限更高效。基于属性的访问控制ABAC通过评估主体、资源、环境等的属性标签来定义权限。这提供了更细粒度、更动态的授权能力例如“允许项目标签为‘ProjectX’的用户修改同样带有此标签的资源”总结来说IAM 的权限模型是一个建立在认证信任基础上以 JSON 策略为规则通过“默认拒绝、显式拒绝优先”这一严谨逻辑进行裁决的授权基础设施。