本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 監控並控制使用擔任角色所採取的動作 [IAM 角色](id_roles.md)是 IAM 中受指派[許可](access_policies.md)的物件。當您使用來自 外部的 IAM 身分或身分[擔任該角色](id_roles_manage-assume.md)時 AWS，您會收到具有指派給該角色之許可的工作階段。 當您在 中執行動作時 AWS，您的工作階段相關資訊可以記錄到 AWS CloudTrail ，以供帳戶管理員監控。管理員可以將角色設定為要求身分傳遞自訂字串，以識別在 AWS中執行動作的人員或應用程式。此身分資訊會儲存為 AWS CloudTrail中的*來源身分*。當管理員查看 CloudTrail 中的活動時，他們可以查看來源身分資訊以判斷曾使用擔任角色工作階段執行動作者。 設定來源身分後，它會出現在角色工作階段期間所採取任何 AWS 動作的請求中。當角色用於透過 AWS CLI 或 AWS API 擔任另一個角色時，設定的 值會持續存在，稱為[角色鏈結](id_roles.md#iam-term-role-chaining)。設定的值無法在角色工作階段期間變更。管理員可以根據來源身分的存在或值來設定精細許可，以進一步控制使用共用角色採取 AWS 的動作。您可以決定是否可以使用來源身分屬性、是否需要，以及可以使用的數值。 您使用來源身分的方式與角色工作階段名稱和工作階段標記有很大的不同。來源身分值在設定之後即無法變更，而且對於對角色工作階段採取的任何其他動作，會持續存在。以下說明如何使用工作階段標籤和角色工作階段名稱： + **工作階段標籤** – 您也可以在擔任角色或與使用者聯合身分時傳遞工作階段標籤。擔任角色時，工作階段標籤即會出現。您可以定義使用標籤條件金鑰的政策，以根據主體的標籤來授與許可。您可以使用 CloudTrail 來檢視為了擔任角色或聯合身分使用者而提出的請求。若要進一步了解工作階段標籤，請參閱 [在 中傳遞工作階段標籤 AWS STS](id_session-tags.md)。 + **角色工作階段名稱** – 您可以在角色信任政策中使用 `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` 操作擔任角色。如果您有企業身分，也稱為人力身分，他們可能會使用 存取您的 AWS 資源`AssumeRoleWithSAML`。如果最終使用者要存取您的行動或 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`，嘗試`DeveloperRole`使用以下 AWS CLI 請求擔任 。 **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 評估請求時，請求內容會包含 `sts:SourceIdentity`的 `DevUser`。 ## 擔任角色時指定來源身分 當您使用其中一個 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 安全部落格中的[AWS 使用 Active Directory 聯合服務 (ADFS) 進行聯合身分驗證](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/)。 身為管理員，您可以允許公司目錄的成員 AWS 使用 AWS STS `AssumeRoleWithSAML`操作聯合到 。若要執行此操作，您必須完成下列任務： 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` 元素與設定為 `https://aws.amazon.com/SAML/Attributes/SourceIdentity` 的 `Name` 屬性。使用 `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 權杖 (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 資源許可的關鍵角色。也假設您使用 授予對人力資源身分的 AWS 存取權`AssumeRoleWithSAML`。您只希望資深開發人員 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`。角色是跨帳戶界限擔任。因此，必須在 `CriticalRole` 的許可政策和 `CriticalRole_2` 的角色信任政策中授予 `sts:SetSourceIdentity` 許可。 **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"] } } } ] } ``` ------ 使用者使用擔任 CritealRole 所取得的角色工作階段憑證進行下列呼叫。來源身分是在擔任 CrealRole 期間所設定，所以不需要再次明確設定。如果使用者嘗試設定的來源身分與擔任 `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 日誌檔案包含經擔任角色或聯合身分使用者工作階段的來源身分設定資訊。如需詳細資訊，請參閱[使用 記錄 IAM 和 AWS STS API 呼叫 AWS CloudTrail](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)。