監控並控制使用擔任角色所採取的動作 - AWS Identity and Access Management

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

監控並控制使用擔任角色所採取的動作

IAM 角色是 IAM 中受指派許可的物件。當您從外部使用 IAM 身分或身分假設該角色時 AWS,您會收到一個工作階段,其中包含指派給該角色的許可。

當您在中執行動作時 AWS,可以記錄有關工作階段的資訊,以 AWS CloudTrail 便您的帳戶管理員監控。管理員可以將角色設定為要求身分傳遞自訂字串,以識別在 AWS中執行動作的人員或應用程式。此身分資訊會儲存為 AWS CloudTrail中的來源身分。當管理員檢閱中的活動時 CloudTrail,他們可以檢視來源身分識別資訊,以決定使用假設角色工作階段執行動作的人員或哪些動作。

設定來源識別之後,就會出現在角色工作階段期間所 AWS 採取的任何動作的要求中。當角色透過 AWS CLI 或 AWS API (稱為角色鏈結) 擔任其他角色時,所設定的值仍然存在。設定的值無法在角色工作階段期間變更。系統管理員可以根據來源身分識別的存在狀態或值來設定精細的權限,以進一步控制使用共用角色執行的 AWS 動作。您可以決定是否可以使用來源身分屬性、是否需要,以及可以使用的數值。

您使用來源身分的方式與角色工作階段名稱和工作階段標記有很大的不同。來源身分值在設定之後即無法變更,而且對於對角色工作階段採取的任何其他動作,會持續存在。以下說明如何使用工作階段標籤和角色工作階段名稱:

  • 工作階段標籤 – 您也可以在擔任角色或與使用者聯合身分時傳遞工作階段標籤。擔任角色時,工作階段標籤即會出現。您可以定義使用標籤條件金鑰的政策,以根據主體的標籤來授與許可。然後,您可以使用 CloudTrail 來檢視為擔任角色或同盟使用者所做的要求。若要進一步了解工作階段標籤,請參閱 傳遞工作階段標籤 AWS STS

  • 角色工作階段名稱 – 您可以在角色信任政策中使用 sts:RoleSessionName 條件金鑰,請求您的使用者在擔任角色時提供特定的工作階段名稱。當不同主體使用角色時,角色工作階段名稱可用來區分角色工作階段。若要深入瞭解角色工作階段名稱,請參閱 sts: RoleSessionName

當您想要控制擔任角色的身分時,建議您使用來源身分。來源識別對於採礦 CloudTrail 記錄檔來判斷使用此角色執行動作的使用者也很有用。

設定以使用來源身分

您設定為使用來源身分的方式將取決於擔任角色時所使用的方法。例如,您的 IAM 使用者可能會直接使用 AssumeRole 操作擔任角色。如果您擁有企業身分識別 (也稱為員工身分識別),他們可能 AWS 會使用AssumeRoleWithSAML. 如果最終使用者要存取您的行動或 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 內部使用。

  • CloudTrail 當 AWS 服務或服務連結角色代表聯合身分或員工身分執行動作時,不會擷取來源身分識別資訊。

重要

假設角色時,您無法切換至中需要設定來源識別的角色。 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": "SetAwsUserNameAsSourceIdentity", "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,嘗試假設DeveloperRole使用下列 AWS CLI 要求。

範例 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:SourceIdentityDevUser

擔任角色時指定來源身分

當您使用其中一個 AWS STS AssumeRole* API 作業取得角色的臨時安全登入資料時,您可以指定來源身分識別。您使用的 API 操作會視您的使用案例而有所不同。例如,如果您使用 IAM 角色授與 IAM 使用者存取他們通常無法存取的 AWS 資源,則可以使用該AssumeRole作業。如果您使用企業聯合身分來管理人力使用者,可以使用 AssumeRoleWithSAML 操作。如果您使用 OIDC 聯盟來允許使用者存取您的行動或 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 \

搭配 AssumeRoleWith SAML 使用來源身分識別

主體呼叫 AssumeRoleWithSAML 操作是使用 SAML 類型的聯合進行身分驗證。此作業會傳回一組可用來存取 AWS 資源的暫時認證。如需有關使用 SAML 型聯合進行存取的詳細資訊,請參 AWS Management Console 閱。使 SAML 2.0 聯合身分使用者能夠存取 AWS Management Console如需有關 AWS CLI 或 AWS API 存取的詳細資訊,請參閱SAML 2.0 聯合身分。如需為您的 Active Directory 使用者設定 SAML 聯盟的教學課程,請參閱安全性部落格中的使用中目錄AWS 同盟服務 (ADFS) 的同盟驗證。 AWS

身為系統管理員,您可以允許公司目錄的成員 AWS 使用此 AWS STS AssumeRoleWithSAML作業聯合。若要執行此操作,您必須完成下列任務:

若要設定來源身分的 SAML 屬性,請包含 Attribute 元素與設定為 https://aws.amazon.com/SAML/Attributes/SourceIdentityName 屬性。使用 AttributeValue 元素指定來源身分的值。例如,假設您希望將下列身分屬性作為來源身分傳遞。

SourceIdentity:DiegoRamirez

如要傳遞此屬性,請在您的 SAML 聲明中包含下列元素。

範例 SAML 聲明的程式碼片段範例
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity"> <AttributeValue>DiegoRamirez</AttributeValue> </Attribute>

使用來源身分 AssumeRoleWithWebIdentity

調用AssumeRoleWithWebIdentity操作的主體使用 OpenID Connect(OIDC)兼容的聯合進行身份驗證。此操作會傳回一組暫時憑證,讓您用來存取 AWS 資源。如需使用 OIDC 同盟進行存取的詳細資訊,請參 AWS Management Console 閱。OIDC 聯盟

若要從 OpenID Connect (OIDC) 傳遞來源身分,您必須在 JSON Web 權杖 (JWT) 中包含來源身分。在您提交 AssumeRoleWithWebIdentity 請求時,您必須在權杖中的 https://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 資源之權限的關鍵角色。還要想像一下,您授予 AWS 訪問您的員工身份使用AssumeRoleWithSAML. 您只希望資深開發人員 Saanvi 和 Diego 能夠存取角色,因此您為該角色建立下列信任政策。

範例 來源身分的角色信任政策範例 (SAML)
{ "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,則您的角色信任原則可能如下所示。

範例 來源身分的角色信任政策範例 (OIDC 提供者)
{ "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 而取得的角色工作階段憑證用於將角色鏈結至另一個帳戶中的第二個角色 CriticalRole_2。角色是跨帳戶界限擔任。因此,必須在 CriticalRole 的許可政策和 CriticalRole_2 的角色信任政策中授予 sts:SetSourceIdentity 許可。

範例權限原則 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 記錄檔包含針對假定角色或同盟使用者工作階段設定之來源識別的相關資訊。如需更多資訊,請參閱 使用以下方式記錄 IAM 和 AWS STS API 呼叫 AWS CloudTrail

例如,假設使用者提出 AWS STS AssumeRole要求,並設定來源身分識別。您可以在 CloudTrail 日誌中的requestParameters密鑰中找到sourceIdentity信息。

範例 記錄檔中的範例 requestParameters 區段 AWS CloudTrail
"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金鑰中。

範例 記錄檔中的 userIdentity 金鑰範例 AWS CloudTrail
{ "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 事件參考〉。