AWS - 基本信息

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

组织层级

账户

在 AWS 中，有一个 根账户，它是您 组织中所有账户的父容器。然而，您不需要使用该账户来部署资源，您可以创建 其他账户以将不同的 AWS 基础设施分开。

从 安全 的角度来看，这非常有趣，因为 一个账户无法访问其他账户的资源（除非专门创建了桥接），因此您可以在部署之间创建边界。

因此，在一个组织中有 两种类型的账户（我们讨论的是 AWS 账户，而不是用户账户）：一个被指定为管理账户的单一账户，以及一个或多个成员账户。

  • 管理账户（根账户） 是您用来创建组织的账户。从组织的管理账户，您可以执行以下操作：

  • 在组织中创建账户

  • 邀请其他现有账户加入组织

  • 从组织中移除账户

  • 管理邀请

  • 对组织内的实体（根、OU 或账户）应用政策

  • 启用与支持的 AWS 服务的集成，以在组织中的所有账户之间提供服务功能。

  • 可以使用创建此根账户/组织时使用的电子邮件和密码作为根用户登录。

管理账户具有 付款账户的责任，并负责支付所有成员账户产生的费用。您无法更改组织的管理账户。

  • 成员账户 组成了组织中所有其他账户。一个账户一次只能是一个组织的成员。您可以将政策附加到一个账户，以仅对该账户应用控制。
  • 成员账户 必须使用有效的电子邮件地址，并可以有一个 名称，通常他们将无法管理账单（但可能会被授予访问权限）。
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

组织单位

账户可以被分组为 组织单位 (OU)。通过这种方式，您可以为组织单位创建 策略，这些策略将 应用于所有子账户。请注意，一个 OU 可以有其他 OU 作为子单位。

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

一个 service control policy (SCP) 是一种政策，指定用户和角色在受 SCP 影响的账户中可以使用的服务和操作。SCP 与 IAM 权限政策 类似，但它们 不授予任何权限。相反，SCP 指定了组织、组织单位 (OU) 或账户的 最大权限。当您将 SCP 附加到您的组织根或 OU 时，SCP 限制成员账户中实体的权限。

这是 即使是根用户也可以被阻止 执行某些操作的唯一方法。例如，它可以用于阻止用户禁用 CloudTrail 或删除备份。
绕过此限制的唯一方法是同时妥协配置 SCP 的 主账户（主账户无法被阻止）。

Warning

请注意，SCP 仅限制账户中的主体，因此其他账户不受影响。这意味着拥有一个 SCP 拒绝 s3:GetObject 不会阻止人们 访问您账户中的公共 S3 存储桶。

SCP 示例：

  • 完全拒绝根账户

  • 仅允许特定区域

  • 仅允许白名单服务

  • 拒绝禁用 GuardDuty、CloudTrail 和 S3 公共阻止访问

  • 拒绝安全/事件响应角色被删除或

修改。

  • 拒绝备份被删除。
  • 拒绝创建 IAM 用户和访问密钥

在 https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html 中查找 JSON 示例。

Resource Control Policy (RCP)

一个 resource control policy (RCP) 是一种政策，定义了 您 AWS 组织内资源的最大权限。RCP 在语法上与 IAM 政策类似，但 不授予权限——它们仅限制其他政策可以应用于资源的权限。当您将 RCP 附加到您的组织根、组织单位 (OU) 或账户时，RCP 限制受影响范围内所有资源的资源权限。

这是确保 资源不能超过预定义访问级别 的唯一方法——即使身份基础或资源基础政策过于宽松。绕过这些限制的唯一方法是同时修改由您组织的管理账户配置的 RCP。

Warning

RCP 仅限制资源可以拥有的权限。它们不直接控制主体可以做什么。例如，如果 RCP 拒绝对 S3 存储桶的外部访问，它确保存储桶的权限永远不会允许超出设定限制的操作——即使资源基础政策配置错误。

RCP 示例：

  • 限制 S3 存储桶，使其只能被您组织内的主体访问
  • 限制 KMS 密钥使用，仅允许来自受信任组织账户的操作
  • 限制 SQS 队列的权限，以防止未经授权的修改
  • 在 Secrets Manager 秘密上强制访问边界，以保护敏感数据

在 AWS Organizations Resource Control Policies documentation 中查找示例。

ARN

Amazon Resource Name 是每个 AWS 内部资源的 唯一名称，其组成如下：

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

注意，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是允许您管理身份验证、授权和访问控制的服务。

  • 身份验证 - 定义身份和验证该身份的过程。此过程可以细分为：识别和验证。
  • 授权 - 确定身份在系统中经过身份验证后可以访问的内容。
  • 访问控制 - 授予对安全资源访问的方式和过程。

IAM可以通过其管理、控制和治理身份对您AWS账户内资源的身份验证、授权和访问控制机制的能力来定义。

AWS账户根用户

当您首次创建Amazon Web Services (AWS)账户时，您将开始使用一个具有对账户中所有AWS服务和资源的完全访问权限的单一登录身份。这是AWS账户的_根用户_，通过使用您用于创建账户的电子邮件地址和密码进行登录。

请注意，新创建的管理员用户将具有比根用户更少的权限。

从安全的角度来看，建议创建其他用户并避免使用此用户。

IAM用户

IAM _用户_是您在AWS中创建的实体，用于代表使用它与AWS交互的人员或应用程序。AWS中的用户由名称和凭据（密码和最多两个访问密钥）组成。

当您创建IAM用户时，您通过使其成为具有适当权限策略的用户组的成员（推荐）或直接将策略附加到用户来授予其权限。

用户可以启用MFA登录控制台。启用MFA的用户的API令牌不受MFA保护。如果您想要使用MFA限制用户的API密钥访问，您需要在策略中指明为了执行某些操作需要MFA（示例在这里）。

CLI

  • 访问密钥ID：20个随机的大写字母数字字符，如AKHDNAPO86BSHKDIRYT
  • 秘密访问密钥ID：40个随机的大小写字符：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU（无法检索丢失的秘密访问密钥ID）。

每当您需要更改访问密钥时，您应遵循以下过程：
创建一个新的访问密钥 -> 将新密钥应用于系统/应用程序 -> 将原始密钥标记为非活动 -> 测试并验证新访问密钥是否有效 -> 删除旧访问密钥

MFA - 多因素身份验证

它用于创建额外的身份验证因素，以补充您现有的方法，例如密码，从而创建多因素身份验证级别。
您可以使用免费的虚拟应用程序或物理设备。您可以使用像Google身份验证器这样的应用程序免费激活AWS中的MFA。

带有MFA条件的策略可以附加到以下内容：

  • IAM用户或组
  • 资源，例如Amazon S3桶、Amazon SQS队列或Amazon SNS主题
  • 可以被用户假设的IAM角色的信任策略

如果您想要通过CLI访问一个检查MFA的资源，您需要调用**GetSessionToken。这将为您提供一个包含MFA信息的令牌。
请注意，AssumeRole凭据不包含此信息**。

aws sts get-session-token --serial-number <arn_device> --token-code <code>

如此处所述，有很多不同的情况无法使用MFA。

IAM用户组

IAM 用户组 是一种一次性将策略附加到多个用户的方法，这可以更容易地管理这些用户的权限。角色和组不能成为组的一部分。

您可以将基于身份的策略附加到用户组，以便用户组中的所有用户都接收该策略的权限。您不能在策略（例如基于资源的策略）中将用户组标识为**Principal**，因为组与权限相关，而不是身份验证，主体是经过身份验证的IAM实体。

以下是用户组的一些重要特征：

  • 一个用户组可以包含多个用户，而一个用户可以属于多个组。
  • 用户组不能嵌套；它们只能包含用户，而不能包含其他用户组。
  • 没有默认的用户组会自动包含AWS账户中的所有用户。如果您想要这样的用户组，必须创建它并将每个新用户分配给它。
  • AWS账户中IAM资源的数量和大小是有限制的，例如组的数量，以及用户可以成为成员的组的数量。有关更多信息，请参见IAM和AWS STS配额。

IAM角色

IAM 角色与用户非常相似，因为它是一个具有权限策略的身份，决定它在AWS中可以做什么和不能做什么。然而，角色没有任何凭证（密码或访问密钥）与之关联。角色的设计目的是可以被任何需要它的人（并且有足够权限）假设。IAM用户可以假设一个角色以临时承担特定任务的不同权限。角色可以分配给使用外部身份提供者而不是IAM登录的联合用户。

IAM角色由两种类型的策略组成：信任策略，不能为空，定义谁可以假设该角色，以及权限策略，不能为空，定义它可以访问什么。

AWS安全令牌服务（STS）

AWS安全令牌服务（STS）是一个网络服务，促进临时、有限权限凭证的发放。它专门用于：

IAM中的临时凭证

临时凭证主要与IAM角色一起使用，但也有其他用途。您可以请求具有比标准IAM用户更有限权限集的临时凭证。这防止您意外执行不被更有限凭证允许的任务。临时凭证的一个好处是它们在设定的时间段后会自动过期。您可以控制凭证的有效期。

策略

策略权限

用于分配权限。有两种类型：

  • AWS管理策略（由AWS预配置）
  • 客户管理策略：由您配置。您可以基于AWS管理策略创建策略（修改其中一个并创建自己的），使用策略生成器（一个帮助您授予和拒绝权限的GUI视图）或编写自己的策略。

默认情况下，访问被拒绝，如果指定了明确的角色，则将授予访问权限。
如果存在单个“拒绝”，它将覆盖“允许”，但AWS账户的根安全凭证的请求（默认允许）除外。

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

可以在任何服务中用于条件的全局字段在这里记录。
每个服务中可以用于条件的特定字段在这里记录。

内联策略

这种策略是直接分配给用户、组或角色的。因此，它们不会出现在策略列表中，因为其他任何人都可以使用它们。
内联策略在您想要保持策略与应用于的身份之间的严格一对一关系时非常有用。例如，您希望确保策略中的权限不会意外分配给除其预期身份以外的身份。当您使用内联策略时，策略中的权限不能意外附加到错误的身份。此外，当您使用AWS管理控制台删除该身份时，嵌入在身份中的策略也会被删除。这是因为它们是主体实体的一部分。

资源桶策略

这些是可以在资源中定义的策略。并非所有AWS资源都支持它们。

如果主体没有对它们的明确拒绝，并且资源策略授予它们访问权限，则允许它们。

IAM边界

IAM边界可以用来限制用户或角色应有的访问权限。这样，即使通过不同的策略授予用户一组不同的权限，如果他尝试使用它们，操作将失败。

边界只是附加到用户的策略，指示用户或角色可以拥有的最大权限级别。因此，即使用户具有管理员访问权限，如果边界指示他只能读取S·桶，那就是他能做的最大事情。

这、SCPs和遵循最小权限原则是控制用户权限不超过其所需权限的方式。

会话策略

会话策略是在角色被假定时设置的策略。这将类似于该会话的IAM边界：这意味着会话策略不授予权限，而是将权限限制为策略中指示的权限（最大权限为角色所拥有的权限）。

这对于安全措施非常有用：当管理员要假定一个特权很高的角色时，他可以将权限限制为会话策略中指示的权限，以防会话被破坏。

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

注意，默认情况下，AWS 可能会将会话策略添加到即将生成的会话中，这是由于其他原因。例如，在未经身份验证的 Cognito 假定角色中，默认情况下（使用增强身份验证），AWS 将生成带有会话策略的会话凭证，该策略限制会话可以访问的服务为以下列表。

因此，如果在某个时刻你遇到错误“…因为没有会话策略允许…”，而角色有权限执行该操作，那是因为有一个会话策略阻止了它。

身份联合

身份联合允许来自外部身份提供者的用户安全地访问 AWS 资源，而无需提供有效 IAM 用户帐户的 AWS 用户凭证。
身份提供者的一个例子可以是你自己的企业Microsoft Active Directory（通过SAML）或OpenID服务（如Google）。联合访问将允许其中的用户访问 AWS。

要配置这种信任，生成一个IAM 身份提供者（SAML 或 OAuth），该提供者将信任****其他平台。然后，至少一个IAM 角色被分配（信任）给身份提供者。如果来自受信任平台的用户访问 AWS，他将以提到的角色进行访问。

然而，通常你会希望根据第三方平台中用户的组别给予不同的角色。然后，多个IAM 角色可以信任第三方身份提供者，第三方平台将允许用户假定一个角色或另一个角色。

IAM 身份中心

AWS IAM 身份中心（AWS 单点登录的继任者）扩展了 AWS 身份和访问管理（IAM）的功能，提供一个集中位置，将用户及其对 AWS 账户和云应用程序的访问管理汇集在一起。

登录域将类似于 <user_input>.awsapps.com。

要登录用户，可以使用 3 个身份源：

  • 身份中心目录：常规 AWS 用户
  • Active Directory：支持不同的连接器
  • 外部身份提供者：所有用户和组来自外部身份提供者（IdP）

在身份中心目录的最简单情况下，身份中心将拥有用户和组的列表，并能够为他们分配策略到组织的任何账户。

为了给身份中心用户/组访问一个账户，将创建一个信任身份中心的 SAML 身份提供者，并在目标账户中创建一个信任身份提供者并带有指示策略的角色。

AwsSSOInlinePolicy

可以通过内联策略向通过 IAM 身份中心创建的角色授予权限。在被授予AWS 身份中心内联策略的账户中创建的角色将具有名为**AwsSSOInlinePolicy**的内联策略中的这些权限。

因此，即使你看到两个带有名为**AwsSSOInlinePolicy的内联策略的角色，也并不意味着它们具有相同的权限**。

跨账户信任和角色

用户（信任）可以创建一个带有某些策略的跨账户角色，然后允许另一个用户（受信任）访问他的账户，但仅限于新角色策略中指示的访问权限。要创建此角色，只需创建一个新角色并选择跨账户角色。跨账户访问角色提供两个选项。提供你拥有的 AWS 账户之间的访问，以及提供你拥有的账户与第三方 AWS 账户之间的访问。
建议指定被信任的用户，而不是放置一些通用内容，因为如果不这样做，其他经过身份验证的用户（如联合用户）也可能滥用此信任。

AWS Simple AD

不支持：

  • 信任关系
  • AD 管理中心
  • 完整的 PS API 支持
  • AD 回收站
  • 组托管服务账户
  • 架构扩展
  • 无法直接访问操作系统或实例

Web 联合或 OpenID 身份验证

该应用程序使用 AssumeRoleWithWebIdentity 创建临时凭证。然而，这并不授予访问 AWS 控制台的权限，仅授予对 AWS 内部资源的访问。

其他 IAM 选项

  • 你可以设置密码策略设置选项，如最小长度和密码要求。
  • 你可以下载“凭证报告”，其中包含有关当前凭证的信息（如用户创建时间、密码是否启用等）。你可以每四小时生成一次凭证报告。

AWS 身份和访问管理（IAM）提供细粒度的访问控制，覆盖所有 AWS。使用 IAM，你可以指定谁可以访问哪些服务和资源，以及在什么条件下。通过 IAM 策略，你管理对你的员工和系统的权限，以确保最小权限。

IAM ID 前缀

在此页面中，你可以找到根据其性质的键的IAM ID 前缀：

标识符代码描述
ABIAAWS STS 服务承载令牌

| 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 身份验证

为了让常规用户通过 CLI 认证到 AWS，你需要有本地凭证。默认情况下，你可以在 ~/.aws/credentials 中手动配置它们，或通过运行 aws configure。
在该文件中，你可以有多个配置文件，如果使用aws cli时未指定配置文件，则将使用该文件中名为**[default]**的配置文件。
带有多个配置文件的凭证文件示例：

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

如果您需要访问不同的AWS账户，并且您的配置文件被授予访问在这些账户内假设角色的权限，您就不需要每次手动调用STS（aws sts assume-role --role-arn <role-arn> --role-session-name sessname）并配置凭证。

您可以使用~/.aws/config文件来指示要假设的角色，然后像往常一样使用--profile参数（assume-role将以透明的方式为用户执行）。
配置文件示例：

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

使用此配置文件，您可以像这样使用 aws cli：

aws --profile acc2 ...

如果您正在寻找类似的东西，但针对浏览器，您可以查看扩展 AWS Extend Switch Roles。

自动化临时凭证

如果您正在利用一个生成临时凭证的应用程序，每隔几分钟在终端中更新它们可能会很麻烦。可以通过在配置文件中使用 credential_process 指令来解决此问题。例如，如果您有一些易受攻击的网络应用程序，您可以这样做：

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

请注意，凭据 必须 以以下格式返回到 STDOUT：

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

参考

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks