Last updated
学习与实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
在 AWS 中有一个 根账户， 它是您 组织中所有账户的父容器。然而，您不需要使用该账户来部署资源，您可以创建 其他账户以将不同的 AWS 基础设施分开。
从 安全 的角度来看，这非常有趣，因为 一个账户无法访问其他账户的资源（除非专门创建了桥接），因此您可以在部署之间创建边界。
因此，组织中有 两种类型的账户（我们讨论的是 AWS 账户，而不是用户账户）：一个被指定为管理账户的单一账户，以及一个或多个成员账户。
管理账户（根账户） 是您用来创建组织的账户。从组织的管理账户，您可以执行以下操作：
在组织中创建账户
邀请其他现有账户加入组织
从组织中移除账户
管理邀请
对组织内的实体（根、OU 或账户）应用策略
启用与受支持的 AWS 服务的集成，以在组织中的所有账户之间提供服务功能。
可以使用创建此根账户/组织时使用的电子邮件和密码作为根用户登录。
管理账户具有 付款账户的责任，并负责支付所有由成员账户产生的费用。您无法更改组织的管理账户。
成员账户 组成组织中所有其他账户。一个账户一次只能是一个组织的成员。您可以将策略附加到一个账户，以仅对该账户应用控制。
成员账户 必须使用有效的电子邮件地址，并可以有一个 名称，一般来说，他们将无法管理账单（但可能会被授予访问权限）。
账户可以被分组为 组织单位 (OU)。通过这种方式，您可以为组织单位创建 策略，这些策略将 应用于所有子账户。请注意，一个 OU 可以有其他 OU 作为子单位。
一个 服务控制策略 (SCP) 是一种策略，指定用户和角色在受该 SCP 影响的账户中可以使用的服务和操作。SCP 与 IAM 权限策略 类似，但它们 不授予任何权限。相反，SCP 指定了组织、组织单位 (OU) 或账户的 最大权限。当您将 SCP 附加到您的组织根或 OU 时，SCP 限制成员账户中实体的权限。
这是 即使是根用户也可以被阻止 执行某些操作的唯一方法。例如，它可以用于阻止用户禁用 CloudTrail 或删除备份。 绕过此限制的唯一方法是同时妥协配置 SCP 的 主账户（主账户无法被阻止）。
请注意，SCP 仅限制账户中的主体，因此其他账户不受影响。这意味着拥有一个拒绝 s3:GetObject 的 SCP 不会阻止人们 访问您账户中的公共 S3 存储桶。
SCP 示例：
完全拒绝根账户
仅允许特定区域
仅允许白名单服务
拒绝禁用 GuardDuty、CloudTrail 和 S3 公共阻止访问
拒绝删除或修改安全/事件响应角色。
拒绝删除备份。
拒绝创建 IAM 用户和访问密钥
在 https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html 中查找 JSON 示例。
亚马逊资源名称 是每个 AWS 内部资源的 唯一名称，其组成如下：
注意，AWS中有4个分区，但只有3种调用方式：
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM是允许您管理身份验证、授权和访问控制的服务。
身份验证 - 定义身份和验证该身份的过程。此过程可以细分为：识别和验证。
授权 - 确定身份在系统中经过身份验证后可以访问的内容。
访问控制 - 授予安全资源访问权限的方法和过程。
IAM可以通过其管理、控制和治理身份对您AWS账户内资源的身份验证、授权和访问控制机制的能力来定义。
当您首次创建Amazon Web Services (AWS)账户时，您将开始使用一个具有对账户中所有AWS服务和资源的完全访问权限的单一登录身份。这是AWS账户的_根用户_，通过使用您创建账户时使用的电子邮件地址和密码进行登录。
请注意，新创建的管理员用户将具有比根用户更少的权限。
从安全的角度来看，建议创建其他用户并避免使用此用户。
IAM_用户_是您在AWS中创建的实体，用于代表使用它与AWS交互的人员或应用程序。AWS中的用户由名称和凭据（密码和最多两个访问密钥）组成。
当您创建IAM用户时，您通过将其设置为具有适当权限策略的用户组的成员（推荐）或直接将策略附加到用户来授予其权限。
用户可以启用MFA登录控制台。启用MFA的用户的API令牌不受MFA保护。如果您想要使用MFA限制用户的API密钥访问，您需要在策略中指明为了执行某些操作需要MFA（示例在这里）。
访问密钥ID：20个随机的大写字母数字字符，如AKHDNAPO86BSHKDIRYT
秘密访问密钥ID：40个随机的大小写字符：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU（无法检索丢失的秘密访问密钥ID）。
每当您需要更改访问密钥时，您应遵循以下过程： 创建一个新的访问密钥 -> 将新密钥应用于系统/应用程序 -> 将原始密钥标记为非活动 -> 测试并验证新访问密钥是否有效 -> 删除旧访问密钥
它用于创建额外的身份验证因素，以补充您现有的方法，例如密码，从而创建多因素身份验证级别。 您可以使用免费的虚拟应用程序或物理设备。您可以使用像Google身份验证这样的应用程序免费激活AWS中的MFA。
带有MFA条件的策略可以附加到以下内容：
IAM用户或组
资源，例如Amazon S3桶、Amazon SQS队列或Amazon SNS主题
可以被用户假设的IAM角色的信任策略
如果您想要通过CLI访问一个检查MFA的资源，您需要调用**GetSessionToken。这将为您提供一个包含MFA信息的令牌。
请注意，AssumeRole凭据不包含此信息**。
As stated here，有很多不同的情况无法使用MFA。
IAM 用户组 是一种一次性将策略附加到多个用户的方法，这可以使管理这些用户的权限变得更容易。角色和组不能成为组的一部分。
您可以将基于身份的策略附加到用户组，以便用户组中的所有用户都接收该策略的权限。您不能在策略（例如资源基于的策略）中将用户组标识为**Principal**，因为组与权限相关，而不是身份验证，主体是经过身份验证的IAM实体。
以下是用户组的一些重要特征：
一个用户组可以包含多个用户，而一个用户可以属于多个组。
用户组不能嵌套；它们只能包含用户，而不能包含其他用户组。
没有默认的用户组会自动包含AWS账户中的所有用户。如果您想要这样的用户组，您必须创建它并将每个新用户分配给它。
AWS账户中IAM资源的数量和大小是有限制的，例如组的数量，以及用户可以成为成员的组的数量。有关更多信息，请参见 IAM和AWS STS配额。
IAM 角色与用户非常相似，因为它是一个具有权限策略的身份，决定了它在AWS中可以做什么和不能做什么。然而，角色没有任何凭证（密码或访问密钥）与之关联。角色并不是唯一与一个人关联，而是旨在被任何需要它的人（并且有足够权限）假设。IAM用户可以假设一个角色以临时承担特定任务的不同权限。角色可以被使用外部身份提供者而不是IAM登录的联合用户分配。
IAM角色由两种类型的策略组成：信任策略，不能为空，定义谁可以假设该角色，以及权限策略，不能为空，定义它可以访问什么。
AWS安全令牌服务（STS）是一个网络服务，促进临时、有限权限凭证的发放。它专门为以下目的量身定制：
临时凭证主要与IAM角色一起使用，但也有其他用途。您可以请求具有比标准IAM用户更有限权限集的临时凭证。这防止您意外执行不允许的任务。临时凭证的一个好处是它们在设定的时间段后会自动过期。您可以控制凭证的有效期。
用于分配权限。有两种类型：
AWS管理策略（由AWS预配置）
客户管理策略：由您配置。您可以基于AWS管理策略创建策略（修改其中一个并创建自己的），使用策略生成器（一个帮助您授予和拒绝权限的GUI视图）或编写自己的策略。
默认情况下，访问被拒绝，如果指定了明确的角色，则将授予访问权限。 如果存在单个“拒绝”，它将覆盖“允许”，但AWS账户的根安全凭证的请求（默认允许）除外。
The global fields that can be used for conditions in any service are documented here. The specific fields that can be used for conditions per service are documented here.
这种策略是直接分配给用户、组或角色的。因此，它们不会出现在策略列表中，因为其他任何人都可以使用它们。 内联策略在您想要保持策略与应用于的身份之间的严格一对一关系时非常有用。例如，您希望确保策略中的权限不会意外分配给除其预期身份以外的身份。当您使用内联策略时，策略中的权限不能意外附加到错误的身份。此外，当您使用 AWS 管理控制台删除该身份时，嵌入在身份中的策略也会被删除。这是因为它们是主体实体的一部分。
这些是可以在资源中定义的策略。并非所有 AWS 资源都支持它们。
如果主体没有对它们的明确拒绝，并且资源策略授予他们访问权限，则他们被允许。
IAM 边界可用于限制用户或角色应有的权限。这样，即使通过不同的策略授予用户不同的权限，如果他尝试使用它们，操作也会失败。
边界只是附加到用户的策略，指示用户或角色可以拥有的最大权限级别。因此，即使用户具有管理员访问权限，如果边界指示他只能读取 S· 桶，那就是他能做的最大限度。
这、SCPs 和 遵循最小权限原则是控制用户权限不超过其所需权限的方式。
会话策略是在某种情况下假定角色时设置的策略。这将像是该会话的IAM 边界：这意味着会话策略不授予权限，而是将其限制为策略中指示的权限（最大权限为角色所拥有的权限）。
这对于安全措施非常有用：当管理员要假定一个非常特权的角色时，他可以将权限限制为仅在会话策略中指示的权限，以防会话被破坏。
注意，默认情况下，AWS 可能会向即将生成的会话添加会话策略，这是由于第三方原因。例如，在 未认证的 Cognito 假定角色 中，默认情况下（使用增强身份验证），AWS 将生成 带有会话策略的会话凭证，该策略限制会话可以访问的服务 为以下列表。
因此，如果在某个时刻你遇到错误“...因为没有会话策略允许...”，而角色有权限执行该操作，那是因为 有一个会话策略阻止了它。
身份联合 允许来自外部身份提供者的用户 安全地访问 AWS 资源，而无需提供有效 IAM 用户帐户的 AWS 用户凭证。 身份提供者的一个例子可以是你自己的企业 Microsoft Active Directory（通过 SAML）或 OpenID 服务（如 Google）。联合访问将允许其中的用户访问 AWS。
要配置这种信任，生成一个 IAM 身份提供者（SAML 或 OAuth），该提供者将 信任 其他平台。然后，至少一个 IAM 角色被分配（信任）给身份提供者。如果来自受信平台的用户访问 AWS，他将以提到的角色进行访问。
然而，你通常希望根据第三方平台中用户的 组别给予不同的角色。然后，多个 IAM 角色可以信任 第三方身份提供者，第三方平台将允许用户假定一个角色或另一个角色。
AWS IAM 身份中心（AWS 单点登录的继任者）扩展了 AWS 身份和访问管理（IAM）的功能，提供一个 集中位置，将 用户及其对 AWS 帐户和云应用程序的访问管理汇集在一起。
登录域将类似于 <user_input>.awsapps.com。
要登录用户，可以使用 3 个身份源：
身份中心目录：常规 AWS 用户
Active Directory：支持不同的连接器
外部身份提供者：所有用户和组来自外部身份提供者（IdP）
在身份中心目录的最简单情况下，身份中心将拥有用户和组的列表，并能够 为他们分配策略 到 组织的任何帐户。
为了给予身份中心用户/组对帐户的访问，将创建一个 信任身份中心的 SAML 身份提供者，并在目标帐户中创建一个 信任身份提供者并具有指示策略的角色。
可以通过 IAM 身份中心创建的角色的内联策略授予权限。在被授予 AWS 身份中心内联策略 的帐户中创建的角色将具有名为 AwsSSOInlinePolicy 的内联策略中的这些权限。
因此，即使你看到两个带有名为 AwsSSOInlinePolicy 的内联策略的角色，也 并不意味着它们具有相同的权限。
用户（信任）可以创建一个带有某些策略的跨账户角色，然后 允许另一个用户（受信任） 访问他的帐户，但仅 具有新角色策略中指示的访问权限。要创建此角色，只需创建一个新角色并选择跨账户角色。跨账户访问的角色提供两个选项。提供你拥有的 AWS 账户之间的访问，以及提供你拥有的账户与第三方 AWS 账户之间的访问。 建议 指定被信任的用户，而不是放置一些通用的内容，因为如果不这样做，其他经过身份验证的用户（如联合用户）也可能滥用此信任。
不支持：
信任关系
AD 管理中心
完整的 PS API 支持
AD 回收站
组托管服务账户
架构扩展
无法直接访问操作系统或实例
该应用程序使用 AssumeRoleWithWebIdentity 创建临时凭证。然而，这并不授予对 AWS 控制台的访问，仅授予对 AWS 内部资源的访问。
你可以 设置密码策略设置，选项如最小长度和密码要求。
你可以 下载“凭证报告”，其中包含有关当前凭证的信息（如用户创建时间、密码是否启用...）。你可以每 四小时 生成一次凭证报告。
AWS 身份和访问管理（IAM）提供 细粒度的访问控制，覆盖所有 AWS。使用 IAM，你可以指定 谁可以访问哪些服务和资源，以及在什么条件下。通过 IAM 策略，你管理对你的员工和系统的权限，以 确保最小权限。
在 此页面 中，你可以找到根据其性质的 IAM ID 前缀：
ABIA | |
ACCA | 上下文特定凭证 |
AGPA | 用户组 |
AIDA | IAM 用户 |
AIPA | Amazon EC2 实例配置文件 |
AKIA | 访问密钥 |
ANPA | 管理策略 |
ANVA | 管理策略中的版本 |
APKA | 公钥 |
AROA | 角色 |
ASCA | 证书 |
ASIA | 临时（AWS STS）访问密钥 ID 使用此前缀，但仅在与秘密访问密钥和会话令牌组合时是唯一的。 |
以下权限授予各种元数据的读取访问：
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
为了让常规用户通过 CLI 认证到 AWS，你需要拥有 本地凭证。默认情况下，你可以在 ~/.aws/credentials 中 手动 配置它们，或通过 运行 aws configure。
在该文件中，你可以拥有多个配置文件，如果 未指定配置文件，使用 aws cli 时，将使用该文件中名为 [default] 的配置文件。
具有多个配置文件的凭证文件示例：
如果您需要访问不同的AWS账户，并且您的配置文件被授予访问在这些账户内假设角色的权限，您不需要每次手动调用STS（aws sts assume-role --role-arn <role-arn> --role-session-name sessname）并配置凭证。
您可以使用~/.aws/config文件来指示要假设的角色，然后像往常一样使用--profile参数（assume-role将以透明的方式为用户执行）。
配置文件示例：
使用此配置文件，您可以像这样使用 aws cli：
如果您正在寻找类似的东西，但用于浏览器，您可以查看扩展 AWS Extend Switch Roles。
学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE) 学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE)
