企业官网建设流程全解析

目录

🔐 身份认证：确认“你是谁”

⚙️ 授权流程：决定“你能做什么”

⚖️ 核心决策逻辑：默认拒绝与显式拒绝

📋 策略类型与影响范围

🔗 底层访问控制模型的融合

IAM 权限模型的底层原理可以概括为：以“默认拒绝”为基石，通过“身份认证”确认请求者是谁，再经由“策略评估引擎”对“请求上下文”与“策略规则”进行匹配，最终做出“允许”或“拒绝”的授权决策。

其核心运作流程与关键机制如下：

🔐 身份认证：确认“你是谁”

在授权之前，IAM 必须首先验证请求主体的身份。主体是使用实体（如用户、角色）来发送请求的人员或应用程序。

• 认证凭据：主体通过其登录凭据（如用户名密码、访问密钥）向 IAM 证明身份。IAM 会将凭据与可信的委托实体（如 IAM 用户、角色）进行比对。

• 认证方式：认证方式多样，包括根用户密码、IAM 用户的长期凭据、或通过角色扮演获取的临时凭据。对于联合身份，则由外部身份提供商（IdP）验证身份后传递凭据给 AWS。

• 安全增强：通常建议启用多重验证（MFA）来增强安全性。

⚙️ 授权流程：决定“你能做什么”

当认证通过后，主体发起的每一个操作请求都会进入授权评估流程。

1. 构建请求上下文：当一个主体尝试执行操作时（例如，通过控制台、API 或 CLI），会向 AWS 发送一个请求。这个请求包含了 IAM 评估所需的全部信息，即请求上下文，主要包括：

   • 动作/操作：主体想要执行的具体操作。

   • 资源：操作所针对的目标 AWS 资源。

   • 主体：发送请求的人员或应用程序。

   • 环境数据：如 IP 地址、时间戳等。

   • 资源数据：与请求资源相关的数据，如标签。

2. 策略评估引擎：IAM 使用请求上下文中的值，找出所有适用于该请求的策略，并逐一进行评估。这些策略主要以 JSON 文档形式存储，明确了“谁”在“什么条件”下，可以对“哪些资源”执行“什么操作”。

⚖️ 核心决策逻辑：默认拒绝与显式拒绝

IAM 的策略评估遵循一套严格的布尔逻辑，其核心原则是：

• 默认拒绝（Default Deny）：所有的请求在初始状态下都被视为拒绝。只有在策略中被显式允许的操作，才会被最终授权。

• 显式拒绝优先（Explicit Deny Overrides）：如果任何一条适用的策略中包含了针对该操作的显式拒绝，那么无论其他策略是否允许，该请求都会被无条件拒绝，且评估过程会立即停止。

• 允许的必要条件：要让一个请求被允许，请求的每一个部分（动作、资源等）都必须在至少一条适用的许可策略中被显式允许。

📋 策略类型与影响范围

在授权决策中，不同类型的策略扮演着不同的角色：

• 身份型策略（Identity-based Policies）：附加到 IAM 用户、组或角色上，定义了该主体可以做什么。这是最常用的策略类型，用于控制主体在其账户内的权限。

• 资源型策略（Resource-based Policies）：直接附加到资源上（如 S3 存储桶），定义了谁可以对这个资源做什么。它是实现跨账户访问的关键机制。

🔗 底层访问控制模型的融合

IAM 的底层设计并非单一模型，而是融合了多种经典访问控制思想，以适应不同的授权场景：

• 基于角色的访问控制（RBAC）：通过引入“角色”作为用户与权限之间的中间层，简化了权限管理。将权限赋予角色，再将角色赋予用户，比直接管理每个用户的权限更高效。

• 基于属性的访问控制（ABAC）：通过评估主体、资源、环境等的属性（标签）来定义权限。这提供了更细粒度、更动态的授权能力，例如，“允许项目标签为‘ProjectX’的用户修改同样带有此标签的资源”

总结来说，IAM 的权限模型是一个建立在认证信任基础上，以 JSON 策略为规则，通过“默认拒绝、显式拒绝优先”这一严谨逻辑进行裁决的授权基础设施。