AWS - Basic Information
Last updated
Last updated
学习与实践 AWS Hacking:HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP Hacking: 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是允许您管理AWS账户内的身份验证、授权和访问控制的服务。
身份验证 - 定义身份和验证该身份的过程。此过程可以细分为：识别和验证。
授权 - 确定身份在系统中经过身份验证后可以访问的内容。
访问控制 - 授予安全资源访问权限的方法和过程。
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）。
每当您需要更改访问密钥时，您应遵循以下过程： &#xNAN;Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key
它用于创建额外的身份验证因素，以补充您现有的方法，例如密码，从而创建多因素身份验证级别。 您可以使用免费的虚拟应用程序或物理设备。您可以使用像Google身份验证器这样的应用程序免费激活AWS中的MFA。
带有MFA条件的策略可以附加到以下内容：
IAM用户或组
资源，例如Amazon S3桶、Amazon SQS队列或Amazon SNS主题
可以被用户假设的IAM角色的信任策略
如果您想要通过CLI访问一个检查MFA的资源，您需要调用**GetSessionToken。这将为您提供一个包含MFA信息的令牌。
请注意，AssumeRole凭据不包含此信息**。
作为这里所述，有很多不同的情况无法使用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 全球字段可以在任何服务中用于条件的文档在这里. The 每个服务中可以用于条件的特定字段的文档在这里.
这种策略是直接分配给用户、组或角色的。因此，它们不会出现在策略列表中，因为其他任何人都可以使用它们。 内联策略在您想要保持策略与应用于的身份之间的严格一对一关系时非常有用。例如，您想确保策略中的权限不会意外分配给除其预期身份以外的身份。当您使用内联策略时，策略中的权限不能意外附加到错误的身份。此外，当您使用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
以下权限授予各种元数据的读取访问：
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)
