监控和控制使用所担任角色执行的操作 - AWS Identity and Access Management

监控和控制使用所担任角色执行的操作

IAM 角色是 IAM 中分配权限的对象。当您使用 IAM 身份或来自 AWS 以外的身份担任该角色时,将会收到具有分配给该角色的权限的会话。

当您在 AWS 中执行操作时,则有关您会话的信息可以记录到 AWS CloudTrail 以便您的账户管理员进行监控。管理员可以配置角色以要求身份来传递自定义字符串,该字符串标识在 AWS 中执行操作的个人或应用程序,称为源身份。此身份信息在 AWS CloudTrail 中存储为源身份。当管理员查看 CloudTrail 中的活动时,他们可以查看源身份信息,以确定谁通过担任角色会话执行了操作或执行了哪些操作。

设置源身份后,它会出现在任何在角色会话期间执行的 AWS 操作的请求中。当角色用于通过 AWS CLI 或者 AWS API 担任其他角色时,设置的值仍然存在,这称为角色链。在角色会话期间无法更改已设置的值。管理员可以根据源身份的存在或值配置精细权限,以进一步控制使用共享角色执行的 AWS 操作。您可以决定是否可以使用源身份属性、是否需要该属性以及可以使用哪些值。

使用源身份的方式与使用角色会话名称和会话标签的方式大有不同。设置后,源身份值无法更改,并且对角色会话执行的任何其他操作将持续存在。以下是如何使用会话标签和角色会话名称的说明:

  • Session tags(会话标签)- 您也可以在代入角色或联合身份用户时传递会话标签。担任角色时会出现会话标签。您可以定义策略,这些策略使用标签条件键来根据委托人的标签向其授予权限。然后您可以使用 CloudTrail 查看为代入角色或联合身份用户而发出的请求。要了解会话标签的更多信息,请参阅 在 AWS STS 中传递会话标签

  • Role session name(角色会话名称)- 您可以在角色信任策略中使用 sts:RoleSessionName 条件键,以要求您的用户在代入角色时提供特定的会话名称。角色会话名称可用于区分角色由不同委托人使用时的角色会话。要了解角色会话名称的更多信息,请参阅 sts:RoleSessionName

我们建议您在要控制担任角色的身份时使用源身份。源身份在挖掘 CloudTrail 日志以确定是何人在使用该角色执行操作时也很有用。

设置以使用源身份

设置以使用源身份的方式取决于担任角色时使用的方法。例如,您的 IAM 用户可以直接使用 AssumeRole 操作。如果您具有企业身份(也称为人力身份),则他们可能会使用 AssumeRoleWithSAML 访问您的 AWS 资源。如果终端用户访问您的移动应用程序或 Web 应用程序,他们可能会使用 AssumeRoleWithWebIdentity。以下是一个高级别的工作流概览,可帮助您了解如何进行设置以在现有环境中利用源身份信息。

  1. 配置测试用户和角色 — 使用预生产环境,配置测试用户和角色,并配置其策略以允许设置源身份。

    如果您对联合身份使用身份提供程序 (IdP),请将 IdP 配置为在断言或令牌中传递您选择的源身份的用户属性。

  2. 担任角色 — 测试所担任角色并将源身份传递给您为测试而设置的用户和角色。

  3. 查看 CloudTrail — 查看 CloudTrail 日志中测试角色的源身份信息。

  4. 培训您的用户 — 在预生产环境中进行测试后,请确保用户知道如何传递源身份信息(如有必要)。设置要求用户在生产环境中提供源身份的最后期限。

  5. 配置生产策略 — 为生产环境配置策略,然后将其添加到生产用户和角色中。

  6. 监控活动 — 使用 CloudTrail 日志监控您的生产角色活动。

有关源身份的需知信息

使用源身份时请记住以下事项。

  • 连接到身份提供商 (IdP) 的所有角色的角色信任策略都必须具有 sts:SetSourceIdentity 权限。对于信任策略中没有此权限的角色,AssumeRole* 操作将失败。如果您不想更新每个角色的角色信任策略,则可以使用单独的 IdP 实例传递源身份。然后仅将 sts:SetSourceIdentity 权限添加到连接至单独 IdP 的角色。

  • 当身份设置源身份时,sts:SourceIdentity 密钥将出现在请求中。对于角色会话期间执行的后续操作,aws:SourceIdentity 密钥将出现在请求中。AWS 不控制 sts:SourceIdentityaws:SourceIdentity 密钥中源身份的值。如果选择要求源身份,则必须选择希望用户或 IdP 提供的属性。出于安全考虑,您必须确保可以控制如何来提供这些值。

  • 源身份值的长度必须介于 2 到 64 个字符之间,只能包含字母数字字符、下划线和以下字符:. , + = @ -(连字符)。您不能创建以文本 aws: 开头的值。此前缀是专为 AWS 内部使用预留的。

  • 当 AWS 服务或服务关联角色代表联合身份或工作人员身份执行操作时,源身份信息不会被 CloudTrail 捕获。

重要

您无法切换为 AWS Management Console 中在担任角色时需要设置源身份的角色。要担任这样的角色,您可以使用 AWS CLI 或者 AWS API 来调用 AssumeRole 操作并指定源身份参数。

设置源身份时所需的权限

除了与 API 操作匹配的操作之外,您的策略中还必须具有以下仅限授权执行的操作:

sts:SetSourceIdentity
  • 要指定源身份,委托人(IAM 用户和角色)必须具有对 sts:SetSourceIdentity 的权限。作为管理员,您可以在角色信任策略和委托人的权限策略中对此进行配置。

  • 当您使用另一个角色担任角色时,该操作称为角色链,在担任角色的委托人的权限策略和目标角色的角色信任策略中都需要对 sts:SetSourceIdentity 的权限。否则,担任角色的操作将失败。

  • 使用源身份时,连接到 IdP 的所有角色的角色信任策略都必须具有 sts:SetSourceIdentity 权限。对于连接到 IdP 的任何角色,如果在没有此权限的情况下,AssumeRole* 操作将失败。如果您不想更新每个角色的角色信任策略,则可以使用单独的 IdP 实例传递源身份,然后将 sts:SetSourceIdentity 权限仅添加到与单独的 IdP 连接的角色。

  • 要跨账户边界设置源身份,您必须在两个位置包含 sts:SetSourceIdentity 权限。该权限必须位于原始账户中委托人的权限策略和目标账户中角色的角色信任策略中。例如,当某个角色用于在另一个账户中使用角色链担任某个角色时,您可能需要执行此操作。

作为账户管理员,假设您希望允许 IAM 用户 DevUser 在您的账户中担任在同一账户中的 Developer_Role。但是,您希望只有当用户已将源身份设置为其 IAM 用户名时才允许此操作。那么,您可以将以下策略附加到 IAM 用户。

例 附加到 DevUser 的基于身份的策略示例

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/Developer_Role" }, { "Sid": "Set_AWSUserName_as_SourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::123456789012:role/Developer_Role", "Condition": { "StringLike": {"sts:SourceIdentity": "${aws:username}"} } } ] }

要强制实施可接受的源身份值,可以配置以下角色信任策略。该策略为 IAM 用户提供 DevUser 权限以担任该角色并设置源身份。sts:SourceIdentity 条件键定义可接受的源身份值。

例 源身份的角色信任策略示例

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDevUserAssumeRole", "Effect": "Allow", "Principal": {"AWS": " arn:aws:iam::123456789012:user/DevUser"}, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": {"sts:SourceIdentity": "DevUser"} } } ] }

借助 IAM 用户 DevUser 的凭证,用户将尝试担任使用以下 AWS CLI 请求的 DeveloperRole

例 示例 AssumeRole CLI 请求

aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \

当 AWS 评估请求时,请求上下文将包含 DevUsersts:SourceIdentity

在担任角色时指定源身份

当您使用 AWS STS AssumeRole*API 操作来获取角色的临时安全凭证时,可以指定源身份。您使用的 API 操作因您的使用案例而异。例如,如果您使用 IAM 角色授予 IAM 用户访问 AWS 资源的权限(而其通常并不具有此权限),则可以使用 AssumeRole 操作。如果您使用企业联合身份验证来管理工作人员用户,则可以使用 AssumeRoleWithSAML 操作。如果您使用 Web 联合身份验证来允许终端用户访问您的移动或 Web 应用程序,则可以使用 AssumeRoleWithWebIdentity 操作。以下部分介绍如何在每个操作中使用源身份。要了解有关临时凭证常见场景的更多信息,请参阅 临时凭证的常见情形

使用具有 AssumeRole 的源身份

AssumeRole 操作返回一组可用于访问 AWS 资源的临时凭证。您可以使用 IAM 用户或角色凭证来调用 AssumeRole。要在代入角色时传递源身份,请使用 -–source-identity AWS CLI 选项或 SourceIdentity AWS API 参数。以下示例说明如何使用 AWS CLI 指定源身份。

例 示例 AssumeRole CLI 请求

aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \

使用具有 AssumeRoleWithSAML 的源身份

委托人调用 AssumeRoleWithSAML 操作使用基于 SAML 的联合身份进行身份验证。此操作返回一组可用于访问 AWS 资源的临时凭证。有关将基于 SAML 的联合身份用于 AWS Management Console访问的更多信息,请参阅使 SAML 2.0 联合身份用户能够访问 AWS Management Console。有关 AWS CLI 或 AWS API 访问的详细信息,请参阅关于基于 SAML 2.0 的联合身份验证。有关为 Active Directory 用户设置 SAML 联合身份的教程,请参阅 AWS 安全博客中的使用 Active Directory AWS 联合身份验证服务 (ADFS) 的亚马逊云科技联合身份验证。

作为管理员,您可以使用 AWS AWS STS 操作,允许公司目录的成员联合身份到 AssumeRoleWithSAML 中。要执行此操作,您必须完成以下任务:

要为源身份设置 SAML 属性,请包含 Attribute 元素,并将 Name 属性设置为 https://aws.amazon.com/SAML/Attributes/SourceIdentity。使用 AttributeValue 元素指定源身份的值。例如,假设您要将以下身份属性作为源身份传递。

SourceIdentity:DiegoRamirez

要传递这些属性,请在 SAML 断言中包含以下元素。

例 SAML 断言的示例片段

<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity"> <AttributeValue>DiegoRamirez</AttributeValue> </Attribute>

使用具有 AssumeRoleWithWebIdentity 源身份

委托人调用 AssumeRoleWithWebIdentity 操作使用兼容 OpenID Connect (OIDC) 的 Web 联合身份进行身份验证。此操作返回一组可用于访问 AWS 资源的临时凭证。有关将基于 Web 联合身份用于 AWS Management Console访问的更多信息,请参阅关于 Web 联合身份验证

要从 OpenID Connect (OIDC) 传递源身份,您必须在 JSON Web Token (JWT) 中包含源身份。当您提交 AssumeRoleWithWebIdentity 请求时,请在令牌的 http://aws.amazon.com/source_identity 命名空间中包含源身份。要了解有关 OIDC 令牌和声明的更多信息,请参阅 Amazon Cognito 开发人员指南 中的 将令牌与用户池结合使用

例如,以下解码的 JWT 是一个令牌,用于通过 Admin 源身份调用 AssumeRoleWithWebIdentity

例 解码的 JSON Web 令牌示例

{ "sub": "johndoe", "aud": "ac_oic_client", "jti": "ZYUCeRMQVtqHypVPWAN3VB", "iss": "https://xyz.com", "iat": 1566583294, "exp": 1566583354, "auth_time": 1566583292, "https://aws.amazon.com/source_identity":"Admin" }

使用源身份信息控制访问

当初始设置源身份时,sts:SourceIdentity 密钥将出现在请求中。设置源身份后,aws:SourceIdentity 密钥存在于角色会话期间提出的所有后续请求中。作为管理员,您可以编写策略,授予条件授权以根据源身份属性的现状或值执行 AWS 操作。

假设您希望要求开发人员设置源身份,以承担一个关键角色,该角色有权写入生产关键 AWS 资源。再假设您使用 AssumeRoleWithSAML 向您的工作人员身份授予了 AWS 访问权限。您只希望高级开发人员 Saanvi 和 Diego 具有该角色的访问权限,因此您可以为角色创建以下信任策略。

例 源身份的角色信任策略示例

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Principal": { "AWS": " arn:aws:iam::111111111111:role/CriticalRole" }, "Action": [ "sts:AssumeRoleWithSAML", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": ["Saanvi", "Diego"] } } } ] }

信任策略包含 sts:SourceIdentity 的条件,需要将源身份设置为能够使 Saanvi 或 Diego 担任关键角色。

角色链和跨账户要求

假设您想允许已经担任 CriticalRole 的用户在另一个账户中担任 CriticalRole_2。获得以用户担任 CriticalRole 的角色会话凭证用于角色链到不同账户中的第二个角色,CriticalRole_2。该角色正在以跨账户边界的形式担任。因此,sts:SetSourceIdentity 权限必须在权限策略中授予 CriticalRole,在角色信任策略中授予 CriticalRole_2

例 CriticalRole 上的权限策略示例

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2" } ] }

为确保跨账户边界设置源身份,以下角色信任策略仅信任 CriticalRole 的角色委托人来设置源身份。

例 CriticalRole_2 上的角色信任策略示例

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": " arn:aws:iam::111111111111:role/CriticalRole" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "aws:SourceIdentity": ["Saanvi","Diego"] } } } ] }

用户使用从担任 CriticalRole 获得的角色会话凭证进行以下调用。源身份是在担任 CriticalRole 期间设置的,因此无需再次显式设置。如果用户尝试设置与担任 CriticalRole 所设置值不同的源身份,则担任角色请求将被拒绝。

例 示例 AssumeRole CLI 请求

aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \ --role-session-name Audit \

当调用委托人担任角色时,请求中的源身份将从第一个担任的角色会话保留。因此,aws:SourceIdentitysts:SourceIdentity 密钥将会出现在请求上下文中。

在 CloudTrail 中查看源身份

您可以使用 CloudTrail 查看为代入角色或联合身份用户而发出的请求。您还可以查看角色或用户请求,以便在 AWS 中执行操作。CloudTrail 日志文件包括有关所代入角色或联合身份用户会话的源身份集的信息。有关更多信息,请参阅

例如,假设用户提出 AWS STS AssumeRole 请求,并设置了源身份。您可以在 CloudTrail 日志的 requestParameters 键中找到 sourceIdentity 信息。

例 AWS CloudTrail 日志中的示例 requestParameters 部分

"eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "123456789012" }, "eventTime": "2020-04-02T18:20:53Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.64", "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86", "requestParameters": { "roleArn": "arn:aws:iam::123456789012:role/Assumed_Role", "roleSessionName": "Test1", "sourceIdentity": "source-identity-value-set", },

如果用户使用所担任的角色会话执行操作,则源身份信息将出现在 CloudTrail 日志的 userIdentity 密钥中。

例 AWS CloudTrail 日志中的 userIdentity 密钥示例

{ "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAJ45Q7YFFAREXAMPLE: Dev1", "arn": "arn: aws: sts: : 123456789012: assumed-role/DevRole/Dev1", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAJ45Q7YFFAREXAMPLE", "arn": "arn: aws: iam: : 123456789012: role/DevRole", "accountId": "123456789012", "userName": "DevRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-02-21T23: 46: 28Z" }, "sourceIdentity": "source-identity-value-present" } } }

要查看 CloudTrail 日志中的示例 AWS STS API 事件,请参阅 CloudTrail 日志中的 IAM API 事件示例。有关 CloudTrail 日志文件中所包含信息的更多详细信息,请参阅 AWS CloudTrail 用户指南中的 CloudTrail 事件参考