AWS IAM 基本概念

引言

经常需要访问 AWS 资源，对 AWS 账户，用户，Role 等概念有些迷糊，所以今天就来了解一下 AWS 身份和访问管理 IAM。

什么是 AWS IAM

AWS Identity and Access Management (IAM) 是 Amazon Web Services 提供的一项服务，用于管理 AWS 资源的访问权限。通过 IAM，可以安全地控制用户、组和角色对 AWS 服务和资源的访问权限。IAM 是 AWS 安全模型的核心组成部分，确保只有经过授权的用户和应用程序才能访问 AWS 资源。

IAM 的主要概念

• 账户（Account）:
  AWS 账户代表一个独立的所有者空间，用于管理和计费 AWS 资源。每个账户都有一个唯一的 account-id。
  账户是资源的最高层级容器，所有的 AWS 资源都在某个 AWS 账户下创建和管理。
  账户可以被认为是一个公司或组织在 AWS 上的代表。

  在 AWS 中，账户划分通常根据组织的需求和最佳实践进行，以确保安全性、成本管理和资源隔离。以下是一些常见的 AWS 账户划分策略：

   - 按环境划分：开发账户，测试账户，生产账户
   - 按部门或团队划分：营销账户，销售账户，工程账户
   - 按项目划分：项目 A 账户，项目 B 账户
   - 按业务单元划分：业务单元 1 账户，业务单元 2 账户
   - 按混合划分：项目A-开发账户，项目A-生产账户，项目B-开发账户，项目B-生产账户
  

• 用户（User）：
  IAM 用户是 AWS 账户中的唯一身份，可以是个人、应用程序或服务。每个用户都有唯一的凭证（如用户名和密码、访问密钥）。

• 组（Group）：
  IAM 组是用户的集合。可以将用户添加到组中，并为组分配权限。组简化了权限管理，因为可以一次性为组中的所有用户分配权限。

• 角色（Role）：
  IAM 角色是具有特定权限的 AWS 身份，但没有特定的用户或组关联。角色通常用于跨账户访问、应用程序访问或临时访问。

• 策略（Policy）：
  IAM 策略是 JSON 文档，定义了允许或拒绝的权限。
  策略可以附加到用户、组或角色，以授予相应的权限。
  策略类型包括托管策略（由 AWS 提供或自定义创建）和内联策略（直接嵌入到单个用户、组或角色中）。

用户 User 和 角色 Role 的区别：

特性	IAM 用户（User）	IAM 角色（Role）
身份类型	个人或应用程序	临时身份，无长期凭证
凭证类型	长期凭证（访问密钥、用户名/密码）	临时凭证（通过 Assume Role 获取的临时安全令牌）
使用场景	持续访问 AWS 资源	临时访问、跨账户访问、应用程序访问、权限提升
权限分配	通过策略直接附加到用户	通过策略附加到角色，通过信任策略定义谁可以 Assume 角色
典型场景	为团队成员创建用户账户，分配长期访问权限	为跨账户访问、应用程序访问、临时权限提升创建角色

账户与用户、角色的关系:
用户和角色都存在于一个 AWS 账户的上下文中。账户作为根容器，拥有和管理其下的用户和角色。
用户是账户内的身份标识，拥有登录账户的能力和执行操作的权限，这些权限可以通过附加到用户的策略来精细控制。
角色不直接关联到具体的身份，而是被授予临时的访问权限，用于在需要时扮演，以获取执行特定任务所需的权限。
账户可以创建多个用户和角色，以满足不同的安全和管理需求，如最小权限原则、权限的临时访问等。

IAM 的主要功能

• 身份验证：
  管理用户和服务的身份凭证，如用户名和密码、访问密钥、MFA（多因素身份验证）等。
• 访问控制：
  定义和管理对 AWS 资源的访问权限，确保只有授权用户才能访问和操作资源。
• 权限管理：
  通过策略分配细粒度的权限，控制用户和服务可以执行的具体操作。
• 跨账户访问：
  通过角色和策略，允许不同 AWS 账户之间的安全访问。
• 临时安全凭证：
  通过角色和 AWS STS（安全令牌服务），为用户和服务生成临时安全凭证，简化访问管理。

ADFS ，SAML 和 AWS 的关联

在 AWS 环境中，ADFS 可以用来实现身份联合，允许用户使用他们在企业的 Active Directory 中的凭据来登录 AWS 管理控制台或进行程序访问。这样，企业可以保持对用户身份的集中管理，同时允许用户访问 AWS 资源而无需为他们创建单独的 AWS IAM 用户。

使用 ADFS 进行身份联合的基本步骤包括：

设置 ADFS：在企业的网络中配置 ADFS 服务，包括设置信任关系和声明规则。
配置 AWS 作为信任方：在 AWS IAM 中创建一个身份提供商（Identity Provider, IdP），并配置 SAML 元数据以建立信任关系。
创建角色和策略：在 AWS 中创建 IAM 角色和相应的权限策略，这些角色将被联合用户扮演。
用户登录：用户通过企业的登录门户使用其 Active Directory 凭据登录。ADFS 验证用户的身份，并向 AWS 发送一个包含用户身份和角色信息的 SAML 断言。
访问 AWS：用户被授予扮演指定 IAM 角色的权限，从而可以访问 AWS 资源。
通过这种方式，ADFS 为企业提供了一种安全、高效的方法来管理对 AWS 资源的访问权限，同时简化了用户的登录过程。

ADFS 活动目录联合服务

ADFS（Active Directory Federation Services）是一种由微软提供的身份认证服务，它允许用户利用单一登录（SSO）技术来访问跨多个系统和应用的数据和资源，无论这些资源是位于本地网络还是分布在互联网上。ADFS 是基于标准的网络身份认证协议，如 SAML（Security Assertion Markup Language），实现身份信息的共享。

ADFS 的主要功能和特点包括：

单一登录（SSO）：用户可以使用一组凭据（通常是他们的企业域凭据）来访问多个应用和服务，无需为每个服务单独登录。

身份联合：ADFS 允许不同组织之间的身份信息共享，使得用户可以使用自己组织的身份凭据访问另一个组织的资源。

安全的身份认证和授权：ADFS 使用加密和数字签名来确保在不同安全域之间传输的身份信息的安全性和完整性。

基于声明的身份认证：ADFS 使用声明（claims）来表示用户的身份信息和属性，这些声明可以在不同的系统和应用之间传递，用于身份认证和授权决策。

与 Active Directory 的集成：ADFS 与 Active Directory（AD）紧密集成，可以直接利用 AD 中的用户账户和组织结构信息，简化了身份管理和访问控制的配置。

ADFS 的应用场景包括跨组织访问控制、云服务访问管理、企业内部应用的单一登录等。通过使用 ADFS，组织可以提高安全性，同时为用户提供更便捷的访问体验。

SAML 安全断言标记语言

SAML（Security Assertion Markup Language）是一种开放标准，用于在安全域之间交换身份验证和授权数据。SAML 是基于 XML 的，它允许身份提供者（IdP）通过断言向服务提供者（SP）传递关于主体（通常是指用户）的身份信息，从而使得用户可以在不同的系统和应用之间进行安全的单一登录（SSO）。

SAML 主要用于实现两个或多个不同系统之间的单一登录（SSO），使得用户可以使用一组凭据来访问多个应用或服务。它广泛应用于企业环境中，特别是在需要跨多个系统和服务进行身份验证和授权的场景中。

SAML 工作流程大致如下：

用户请求访问服务提供者（SP）的资源。
如果用户尚未认证，服务提供者将请求重定向到身份提供者（IdP）进行认证。
用户在身份提供者处进行认证（如果尚未登录，则需要登录）。
身份提供者验证用户的凭据，如果认证成功，它将生成一个包含用户身份信息的 SAML 断言。
身份提供者将 SAML 断言发送回服务提供者。
服务提供者验证 SAML 断言的有效性，如果验证成功，用户将被授予对请求资源的访问权限。

SAML 断言通常包含以下信息：

主体（Subject）：指示了断言关于谁的信息，通常是用户的唯一标识符。
身份验证声明（Authentication Statement）：包含了用户身份验证的信息，如身份验证的时间和方法。
属性声明（Attribute Statement）：可选，包含了用户的其他属性信息，如角色或电子邮件地址。
授权决策声明（Authorization Decision Statement）：可选，包含了关于用户对某资源的访问权限的信息。
SAML 使得跨域身份验证变得简单和安全，减少了用户需要记住多个用户名和密码的负担，同时也简化了身份和访问管理的过程。

ADFS,SAML,AWS 之间的集成步骤

场景描述
假设你有一个企业内部的 Active Directory（AD），并且使用 ADFS 作为身份提供者（IdP）。你希望你的员工能够使用他们的 AD 凭据登录到 AWS 管理控制台，而不需要单独的 AWS 账户。

步骤

1. 在 ADFS 中配置 AWS 作为信任的服务提供者：
   打开 ADFS 管理控制台，选择“添加信任的服务提供者”。
   输入 AWS 提供的 SAML 元数据 URL 或上传元数据文件。
   配置 SAML 属性，以便 ADFS 可以向 AWS 发送正确的 SAML 响应。

2. 在 AWS 中配置 SAML 提供者：
   登录到 AWS 管理控制台，打开 IAM 控制台。
   选择“身份提供者”，然后选择“添加提供者”。
   选择“SAML”作为提供者类型，输入提供者名称，并上传 ADFS 的 SAML 元数据文件。

3. 创建 IAM 角色并配置信任关系：
在 IAM 控制台中，创建一个新的角色。
选择“SAML 2.0 联合身份验证”作为信任实体。
选择刚刚创建的 SAML 提供者，并配置信任关系。
为角色分配适当的权限策略。

4. 配置 SAML 断言：
   在 ADFS 中，配置 SAML 断言规则，以便在用户成功登录后，向 AWS 发送用户的身份信息和权限。

IAM，SAML 和 ADFS 实例

例如：同事 A 和同事 B 都申请了 AWS 某账户下某一 Role 的权限，他们可以分别登入AWS， 访问基于该 AWS 账号下该 Role 赋予的资源。
A 同事登入 AWS：
Account ID: 366054198411
Account name: assumed-role/ADFS-SystemOperator/aa@company.reg.net

B 同事登入 AWS:
Account ID: 366054198411
Account name: assumed-role/ADFS-SystemOperator/bb@company.reg.net

当 A 同事和 B 同事登录 AWS 时，他们实际上是通过他们各自的企业身份认证系统登录的（如 ADFS，活动目录联合服务）使用相同的 AWS 账户（账户 ID 为 366054198411）登录 AWS，但扮演相同角色（ADFS-SystemOperator）的不同实例。这种方式通常用于企业环境中，允许多个用户使用他们的企业身份（例如，他们的企业电子邮件地址）在不需要 AWS IAM 用户的情况下访问 AWS 资源，这种情况通常发生在使用 AWS Identity and Access Management (IAM) 角色和身份联合（Federation）时。

具体来说：

Account ID：这是 AWS 账户的唯一标识符，两位同事使用的是同一个AWS账户。
Account name：这里的账户名实际上描述了用户的身份信息，包括他们所扮演的角色和个人的标识符。
assumed-role：表明用户是通过扮演一个 IAM 角色来进行身份验证的。这是一种常见的身份联合使用场景，允许用户通过外部身份提供者登录。
ADFS-SystemOperator：这是 IAM 角色的名称，表明这个角色可能具有系统操作相关的权限。使用 ADFS 进行身份联合时，角色名称通常会反映角色的用途或权限级别。
aa@company.reg.net / bb@company.reg.net：这是两位同事的企业电子邮件地址，用作区分不同用户的标识符。在 AWS 的上下文中，这表明虽然他们访问的是同一个账户，但是通过他们各自的企业身份进行了区分。

这种配置允许企业通过 ADFS 等身份联合服务，以安全且管理集中的方式控制员工对 AWS 资源的访问，同时避免了需要为每个用户单独创建和管理 AWS IAM 用户的复杂性。