# 监控和控制使用所担任角色执行的操作 [IAM 角色](id_roles.md)是 IAM 中分配[权限](access_policies.md)的对象。当您使用 IAM 身份或来自 AWS 以外的身份[担任该角色](id_roles_manage-assume.md)时，将会收到具有分配给该角色的权限的会话。 当您在 AWS 中执行操作时，则有关您会话的信息可以记录到 AWS CloudTrail 以便您的账户管理员进行监控。管理员可以配置角色以要求身份来传递自定义字符串，该字符串标识在 AWS 中执行操作的个人或应用程序，称为源身份。此身份信息在 AWS CloudTrail 中存储为*源身份*。当管理员查看 CloudTrail 中的活动时，他们可以查看源身份信息，以确定谁通过担任角色会话执行了操作或执行了哪些操作。 设置源身份后，它会出现在任何在角色会话期间执行的 AWS 操作的请求中。当角色用于通过 AWS CLI 或者 AWS API 担任其他角色时，设置的值仍然存在，这称为[角色链](id_roles.md#iam-term-role-chaining)。在角色会话期间无法更改已设置的值。管理员可以根据源身份的存在或值配置精细权限，以进一步控制使用共享角色执行的 AWS 操作。您可以决定是否可以使用源身份属性、是否需要该属性以及可以使用哪些值。 使用源身份的方式与使用角色会话名称和会话标签的方式大有不同。设置后，源身份值无法更改，并且对角色会话执行的任何其他操作将持续存在。以下是如何使用会话标签和角色会话名称的说明： + **Session tags**（会话标签）- 您也可以在代入角色或联合身份用户时传递会话标签。担任角色时会出现会话标签。您可以定义策略，这些策略使用标签条件键来根据主体的标签向其授予权限。然后您可以使用 CloudTrail 查看为代入角色或联合身份用户而发出的请求。要了解会话标签的更多信息，请参阅 [在 AWS STS 中传递会话标签](id_session-tags.md)。 + **Role session name**（角色会话名称）- 您可以在角色信任策略中使用 `sts:RoleSessionName` 条件键，以要求您的用户在代入角色时提供特定的会话名称。角色会话名称可用于区分角色由不同主体使用时的角色会话。要了解角色会话名称的更多信息，请参阅 [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)。 我们建议您在要控制担任角色的身份时使用源身份。源身份在挖掘 CloudTrail 日志以确定是何人在使用该角色执行操作时也很有用。 **Topics** + [设置以使用源身份](#id_credentials_temp_control-access_monitor-setup) + [有关源身份的需知信息](#id_credentials_temp_control-access_monitor-know) + [设置源身份时所需的权限](#id_credentials_temp_control-access_monitor-perms) + [在担任角色时指定源身份](#id_credentials_temp_control-access_monitor-specify-sourceid) + [使用具有 AssumeRole 的源身份](#id_credentials_temp_control-access_monitor-assume-role) + [使用具有 AssumeRoleWithSAML 的源身份](#id_credentials_temp_control-access_monitor-assume-role-saml) + [使用具有 AssumeRoleWithWebIdentity 源身份](#id_credentials_temp_control-access_monitor-assume-role-web-id) + [使用源身份信息控制访问](#id_credentials_temp_control-access_monitor-control-access) + [在 CloudTrail 中查看源身份](#id_credentials_temp_control-access_monitor-ct) ## 设置以使用源身份 设置以使用源身份的方式取决于担任角色时使用的方法。例如，您的 IAM 用户可以直接使用 `AssumeRole` 操作。如果您具有企业身份（也称为人力身份），则他们可能会使用 `AssumeRoleWithSAML` 访问您的 AWS 资源。如果终端用户访问您的移动应用程序或 Web 应用程序，他们可能会使用 `AssumeRoleWithWebIdentity`。以下是一个高级别的工作流概览，可帮助您了解如何进行设置以在现有环境中利用源身份信息。 1. **配置测试用户和角色** — 使用预生产环境，配置测试用户和角色，并配置其策略以允许设置源身份。 如果您对联合身份使用身份提供程序 (IdP)，请将 IdP 配置为在断言或令牌中传递您选择的源身份的用户属性。 1. **担任角色** — 测试所担任角色并将源身份传递给您为测试而设置的用户和角色。 1. **查看 CloudTrail** — 查看 CloudTrail 日志中测试角色的源身份信息。 1. **培训您的用户** — 在预生产环境中进行测试后，请确保用户知道如何传递源身份信息（如有必要）。设置要求用户在生产环境中提供源身份的最后期限。 1. **配置生产策略** — 为生产环境配置策略，然后将其添加到生产用户和角色中。 1. **监控活动** — 使用 CloudTrail 日志监控您的生产角色活动。 ## 有关源身份的需知信息 使用源身份时请记住以下事项。 + 连接到身份提供程序 (IdP) 的所有角色的角色信任策略都必须具有 `sts:SetSourceIdentity` 权限。对于信任策略中没有此权限的角色，`AssumeRole*` 操作将失败。如果您不想更新每个角色的角色信任策略，则可以使用单独的 IdP 实例传递源身份。然后仅将 `sts:SetSourceIdentity` 权限添加到连接至单独 IdP 的角色。 + 当身份设置源身份时，`sts:SourceIdentity` 密钥将出现在请求中。对于角色会话期间执行的后续操作，`aws:SourceIdentity` 密钥将出现在请求中。AWS 不控制 `sts:SourceIdentity` 或 `aws:SourceIdentity` 密钥中源身份的值。如果选择要求源身份，则必须选择希望用户或 IdP 提供的属性。出于安全考虑，您必须确保可以控制如何来提供这些值。 + 源身份值的长度必须介于 2 到 64 个字符之间，只能包含字母数字字符、下划线和以下字符：**. , \$1 = @ -**（连字符）。您不能创建以文本 **aws:** 开头的值。此前缀是专为 AWS 内部使用预留的。 + 当 AWS 服务或服务关联角色代表联合身份或工作人员身份执行操作时，源身份信息不会被 CloudTrail 捕获。 **重要** 您无法切换为 AWS 管理控制台 中在担任角色时需要设置源身份的角色。要担任这样的角色，您可以使用 AWS CLI 或者 AWS API 来调用 `AssumeRole` 操作并指定源身份参数。 ## 设置源身份时所需的权限 除了与 API 操作匹配的操作之外，您的策略中还必须具有以下仅限授权执行的操作： ``` sts:SetSourceIdentity ``` + 要指定源身份，主体（IAM 用户和角色）必须具有对 `sts:SetSourceIdentity` 的权限。作为管理员，您可以在角色信任策略和主体的权限策略中对此进行配置。 + 当您使用另一个角色担任角色时，该操作称为[角色链](id_roles.md#iam-term-role-chaining)，在担任角色的主体的权限策略和目标角色的角色信任策略中都需要对 `sts:SetSourceIdentity` 的权限。否则，担任角色的操作将失败。 + 使用源身份时，连接到 IdP 的所有角色的角色信任策略都必须具有 `sts:SetSourceIdentity` 权限。对于连接到 IdP 的任何角色，如果在没有此权限的情况下，`AssumeRole*` 操作将失败。如果您不想更新每个角色的角色信任策略，则可以使用单独的 IdP 实例传递源身份，然后将 `sts:SetSourceIdentity` 权限仅添加到与单独的 IdP 连接的角色。 + 要跨账户边界设置源身份，您必须在两个位置包含 `sts:SetSourceIdentity` 权限。该权限必须位于原始账户中主体的权限策略和目标账户中角色的角色信任策略中。例如，当某个角色用于在另一个账户中使用[角色链](id_roles.md#iam-term-role-chaining)担任某个角色时，您可能需要执行此操作。 作为账户管理员，假设您希望允许 IAM 用户 `DevUser` 在您的账户中担任在同一账户中的 `Developer_Role`。但是，您希望只有当用户已将源身份设置为其 IAM 用户名时才允许此操作。那么，您可以将以下策略附加到 IAM 用户。 **Example 附加到 DevUser 的基于身份的策略示例** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/Developer_Role" }, { "Sid": "SetAwsUserNameAsSourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::123456789012:role/Developer_Role", "Condition": { "StringLike": { "sts:SourceIdentity": "${aws:username}" } } } ] } ``` 要强制实施可接受的源身份值，可以配置以下角色信任策略。该策略为 IAM 用户提供 `DevUser` 权限以担任该角色并设置源身份。`sts:SourceIdentity` 条件键定义可接受的源身份值。 **Example 源身份的角色信任策略示例** ------ #### [ JSON ] **** ``` { "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`。 **Example 示例 AssumeRole CLI 请求** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \ ``` 当 AWS 评估请求时，请求上下文将包含 `DevUser` 的 `sts:SourceIdentity`。 ## 在担任角色时指定源身份 当您使用 AWS STS `AssumeRole*`API 操作来获取角色的临时安全凭证时，可以指定源身份。您使用的 API 操作因您的使用案例而异。例如，如果您使用 IAM 角色授予 IAM 用户访问 AWS 资源的权限（而其通常并不具有此权限），则可以使用 `AssumeRole` 操作。如果您使用企业联合身份验证来管理工作人员用户，则可以使用 `AssumeRoleWithSAML` 操作。如果您使用 OIDC 联合身份验证来允许终端用户访问您的移动或 Web 应用程序，则可以使用 `AssumeRoleWithWebIdentity` 操作。以下部分介绍如何在每个操作中使用源身份。要了解有关临时凭证常见场景的更多信息，请参阅 [临时凭证的常见情形](id_credentials_temp.md#sts-introduction)。 ## 使用具有 AssumeRole 的源身份 `AssumeRole` 操作返回一组可用于访问 AWS 资源的临时凭证。您可以使用 IAM 用户或角色凭证来调用 `AssumeRole`。要在代入角色时传递源身份，请使用 `-–source-identity` AWS CLI 选项或 `SourceIdentity` AWS API 参数。以下示例说明如何使用 AWS CLI 指定源身份。 **Example 示例 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 管理控制台访问的更多信息，请参阅[使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md)。有关 AWS CLI 或 AWS API 访问的详细信息，请参阅[SAML 2.0 联合身份验证](id_roles_providers_saml.md)。有关为 Active Directory 用户设置 SAML 联合身份的教程，请参阅 AWS 安全博客中的[使用 Active Directory AWS 联合身份验证服务 (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) 的亚马逊云科技联合身份验证。 作为管理员，您可以使用 AWS STS `AssumeRoleWithSAML` 操作，允许公司目录的成员联合身份到 AWS 中。要执行此操作，您必须完成以下任务： 1. [在企业中配置 SAML 提供程序](id_roles_providers_saml_3rd-party.md)。 1. [在 IAM 中创建 SAML 提供商](id_roles_providers_create_saml.md) 1. [在 AWS 中为 SAML 联合主体配置角色及其权限](id_roles_create_for-idp_saml.md)。 1. [完成配置 SAML IdP 并为 SAML 身份验证响应创建断言](id_roles_providers_create_saml_assertions.md)。 要为源身份设置 SAML 属性，请包含 `Attribute` 元素，并将 `Name` 属性设置为 `https://aws.amazon.com/SAML/Attributes/SourceIdentity`。使用 `AttributeValue` 元素指定源身份的值。例如，假设您要将以下身份属性作为源身份传递。 `SourceIdentity:DiegoRamirez` 要传递这些属性，请在 SAML 断言中包含以下元素。 **Example SAML 断言的示例片段** ``` DiegoRamirez ``` ## 使用具有 AssumeRoleWithWebIdentity 源身份 调用 `AssumeRoleWithWebIdentity` 操作的主体使用兼容 OpenID Connect（OIDC）的联合身份验证进行身份验证。此操作返回一组可用于访问 AWS 资源的临时凭证。有关将 OIDC 联合身份验证用于 AWS 管理控制台访问的更多信息，请参阅 [OIDC 联合身份验证](id_roles_providers_oidc.md)。 要从 OpenID Connect (OIDC) 传递源身份，您必须在 JSON Web Token (JWT) 中包含源身份。当您提交 `AssumeRoleWithWebIdentity` 请求时，请在令牌的 `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` 命名空间中包含源身份。要了解有关 OIDC 令牌和声明的更多信息，请参阅《Amazon Cognito 开发人员指南》**中的[将令牌与用户群体结合使用](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)。 例如，以下解码的 JWT 是一个令牌，用于通过 `Admin` 源身份调用 `AssumeRoleWithWebIdentity`。 **Example 解码的 JSON Web 令牌示例** ``` { "sub": "john", "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](reference_policies_iam-condition-keys.md#ck_sourceidentity) 密钥将出现在请求中。设置源身份后，[aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) 密钥存在于角色会话期间提出的所有后续请求中。作为管理员，您可以编写策略，授予条件授权以根据源身份属性的现状或值执行 AWS 操作。 假设您希望要求开发人员设置源身份，以承担一个关键角色，该角色有权写入生产关键 AWS 资源。再假设您使用 `AssumeRoleWithSAML` 向您的工作人员身份授予了 AWS 访问权限。您只希望高级开发人员 Saanvi 和 Diego 具有该角色的访问权限，因此您可以为角色创建以下信任策略。 **Example 源身份的角色信任策略示例 (SAML)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SAMLProviderAssumeRoleWithSAML", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } }, { "Sid": "SetSourceIdentitySrEngs", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ 信任策略包含 `sts:SourceIdentity` 的条件，需要将源身份设置为能够使 Saanvi 或 Diego 担任关键角色。 或者，如果您使用 OIDC 提供者进行联合身份验证，并用 `AssumeRoleWithWebIdentity` 对用户进行身份验证，您的角色信任策略可能如下所示。 **Example 源身份的角色信任策略示例（OIDC 提供商）** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com" }, "Action": [ "sts:AssumeRoleWithWebIdentity", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "server.example.com:aud": "oidc-audience-id" }, "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ ### 角色链和跨账户要求 假设您想允许已经担任 `CriticalRole` 的用户在另一个账户中担任 `CriticalRole_2`。获得以用户担任 `CriticalRole` 的角色会话凭证用于[角色链](id_roles.md#iam-term-role-chaining)到不同账户中的第二个角色，`CriticalRole_2`。该角色正在以跨账户边界的形式担任。因此，`sts:SetSourceIdentity` 权限必须在权限策略中授予 `CriticalRole`，在角色信任策略中授予 `CriticalRole_2`。 **Example CriticalRole 上的权限策略示例** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2" } ] } ``` ------ 为确保跨账户边界设置源身份，以下角色信任策略仅信任 `CriticalRole` 的角色主体来设置源身份。 **Example CriticalRole\$12 上的角色信任策略示例** ------ #### [ JSON ] **** ``` { "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` 所设置值不同的源身份，则担任角色请求将被拒绝。 **Example 示例 AssumeRole CLI 请求** ``` aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \ --role-session-name Audit \ ``` 当调用主体担任角色时，请求中的源身份将从第一个担任的角色会话保留。因此，`aws:SourceIdentity` 和 `sts:SourceIdentity` 密钥将会出现在请求上下文中。 ## 在 CloudTrail 中查看源身份 您可以使用 CloudTrail 查看为代入角色或联合身份用户而发出的请求。您还可以查看角色或用户请求，以便在 AWS 中执行操作。CloudTrail 日志文件包括有关所代入角色或联合身份用户会话的源身份集的信息。有关更多信息，请参阅 [使用 AWS CloudTrail 记录 IAM 和 AWS STS API 调用](cloudtrail-integration.md)。 例如，假设用户提出 AWS STS `AssumeRole` 请求，并设置了源身份。您可以在 CloudTrail 日志的 `requestParameters` 键中找到 `sourceIdentity` 信息。 **Example AWS CloudTrail 日志中的示例 requestParameters 部分** ``` "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "111122223333" }, "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/DevRole", "roleSessionName": "Dev1", "sourceIdentity": "source-identity-value-set" } ``` 如果用户使用所担任的角色会话执行操作，则源身份信息将出现在 CloudTrail 日志的 `userIdentity` 密钥中。 **Example 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-integration.md#cloudtrail-integration_examples-iam-api)。有关 CloudTrail 日志文件中所包含信息的更多详细信息，请参阅 *AWS CloudTrail 用户指南*中的 [CloudTrail 事件参考](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html)。