本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 臨時安全憑證的許可
您可以使用 AWS Security Token Service (AWS STS) 來建立信任的使用者，並提供暫時安全登入資料，以控制對 AWS 資源的存取。如需 的詳細資訊 AWS STS，請參閱 [IAM 中的暫時安全憑證](id_credentials_temp.md)。在 AWS STS 發出臨時安全憑證後，它們在過期期間有效，且無法撤銷。但是，每次發出使用憑證的請求時，都會評估指派給臨時安全憑證的許可，因此您可以透過在發出憑證後變更其存取權來達到撤銷憑證的效果。
下列主題假設您具備 AWS 許可和政策的工作知識。如需有關這些主題的詳細資訊，請參閱 [AWS 資源的存取管理](access.md)。
**Topics**
+ [AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的許可](id_credentials_temp_control-access_assumerole.md)
+ [監控並控制使用擔任角色所採取的動作](id_credentials_temp_control-access_monitor.md)
+ [GetFederationToken 許可](id_credentials_temp_control-access_getfederationtoken.md)
+ [GetSessionToken 許可](id_credentials_temp_control-access_getsessiontoken.md)
+ [停用臨時安全性憑證的許可](id_credentials_temp_control-access_disable-perms.md)
+ [授予許可以建立暫時性安全憑證](id_credentials_temp_control-access_enable-create.md)
+ [授予許可以使用身分增強型主控台工作階段](id_credentials_temp_control-access_sts-setcontext.md)
# AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的許可
所擔任角色的許可政策，將會決定由 `AssumeRole`、`AssumeRoleWithSAML` 和 `AssumeRoleWithWebIdentity` 傳回的臨時安全憑證的許可。當您建立或更新角色時定義這些許可。
或者，您可以傳遞內嵌或受管的[工作階段政策](access_policies.md#policies_session)作為 `AssumeRole`、`AssumeRoleWithSAML` 或 `AssumeRoleWithWebIdentity` API 操作的參數。工作階段政策會為該角色的臨時憑證工作階段限制許可。所產生工作階段的許可會是角色的身分類型政策和工作階段政策的交集。您可以在後續 AWS API 呼叫中使用角色的臨時登入資料，來存取擁有該角色之帳戶中的資源。您無法使用工作階段政策來授予超出即將擔任角色之以身分為基礎政策所允許的許可。若要進一步了解 AWS 如何決定角色的有效許可，請參閱[政策評估邏輯](reference_policies_evaluation-logic.md)。
![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
進行「允許」或「拒絕」授權決策 AWS 時， `AssumeRole` 不會評估連接至發出原始呼叫之登入資料的 政策。使用者暫時放棄其原始許可，以支援由擔任角色指派的許可。在 `AssumeRoleWithSAML`和 `AssumeRoleWithWebIdentity` API 操作中，由於 API 的發起人不是 AWS 身分，因此沒有要評估的政策。
## 範例：使用 AssumeRole 指派許可
您可以將 `AssumeRole` API 操作與不同類型的政策一起使用。以下是幾個範例。
### 角色許可政策
在此範例中，您在呼叫 `AssumeRole` API 操作時未使用選用 `Policy` 參數來指定工作階段。指派給臨時憑證的許可由所擔任角色的許可政策決定。以下範例許可政策授予角色許可，以列出名為 `productionapp` 的 S3 儲存貯體中包含的所有物件。它還允許角色取得、放置和刪除該儲存貯體中的物件。
**Example 角色許可政策範例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### 工作階段政策作為參數傳遞
假設您想要讓使用者擔任與上一個範例相同的角色。但是，此時您希望該角色工作階段擁有的許可，只允許其取得 `productionapp` S3 儲存貯體中的物件，以及在其中放入物件。您不想讓他們刪除物件。實現此目的一種方法是建立新的角色並在該角色的許可政策中指定所需許可。實現此目的之另一種方法是呼叫 `AssumeRole` API，並將工作階段政策包含在可選的 `Policy` 參數做為 API 操作的一部分。所產生工作階段的許可會是角色的以身分為基礎的政策和工作階段政策的交集。工作階段政策不能用來授予超出即將擔任角色之以身分為基礎政策所允許的許可。如需有關角色工作階段許可的詳細資訊，請參閱 [工作階段政策](access_policies.md#policies_session)。
擷取新的工作階段臨時憑證後，您可以將這些資料傳遞給您希望擁有這些許可的使用者。
例如，假設以下政策做為 API 呼叫的參數傳遞。使用這項工作階段的人員所擁有的許可，將僅能執行下列動作：
+ 列出 `productionapp` 儲存貯體中的所有物件。
+ 取得並將物件放入 `productionapp` 儲存貯體中。
在以下工作階段政策中，`s3:DeleteObject` 許可會遭篩除，而且擔任的工作階段不會獲得 `s3:DeleteObject` 許可的授予。此政策設定角色工作階段的最大許可，並供以覆寫該角色的任何現有許可政策。
**Example 工作階段使用`AssumeRole` API 呼叫傳遞政策範例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### 以資源為基礎的政策
有些 AWS 資源支援以資源為基礎的政策，這些政策提供另一個機制來定義影響臨時安全登入資料的許可。只有少數資源 (例如 Amazon S3 儲存貯體、Amazon SNS 主題和 Amazon SQS 佇列) 支援資源式政策。以下範例使用名為 `productionapp` 的 S3 儲存貯體擴展前面的範例。以下政策連接至儲存貯體。
當您將下面以資源為基礎的政策連接到 `productionapp` 儲存貯體時，將拒絕*所有*使用者從儲存貯體中刪除物件的許可。(請參閱政策中的 `Principal` 元素。) 這包括所有擔任角色使用者，即使角色許可政策授予 `DeleteObject` 許可。明確 `Deny` 陳述式一律優先於 `Allow` 陳述式。
**Example 儲存貯體政策的範例**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
如需如何合併和評估多個政策類型的詳細資訊 AWS，請參閱 [政策評估邏輯](reference_policies_evaluation-logic.md)。
# 監控並控制使用擔任角色所採取的動作
[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)。
# GetFederationToken 許可
此 `GetFederationToken` 操作是由 IAM 使用者所呼叫並會傳回該使用者的臨時憑證。此操作會*聯合*使用者。指派給 AWS STS 聯合身分使用者工作階段的許可定義在兩個位置之一：
+ 該工作階段政策會以 `GetFederationToken` API 呼叫的參數傳遞。(這是最常見的)。
+ 以資源為基礎的政策，在政策的 `Principal`元素中明確命名 AWS STS 聯合身分使用者工作階段。(這是最少見的)。
工作階段政策是一種進階政策，且您會在以程式設計方式建立臨時工作階段時，以參數方式傳遞此政策。當您建立 AWS STS 聯合身分使用者工作階段並傳遞工作階段政策時，產生的工作階段許可是使用者身分型政策和工作階段政策的交集。您無法使用工作階段政策來授予超出即將聯合使用者之以身分為基礎政策所允許的許可。
在大部分情況下，如果您未通過 `GetFederationToken` API 呼叫的政策，則所產生的暫時安全憑證沒有許可。不過，以資源為基礎的政策可提供該工作階段的額外許可。您可以使用以資源為基礎的政策存取資源，該政策會將您的工作階段指定為允許的主體。
下圖顯示政策互動的視覺化呈現，以判斷對 `GetFederationToken` 呼叫傳回的暫時安全憑證的許可。
![\[IAM 使用者下圖顯示核取記號，指出工作階段許可是使用者身分型政策和工作階段政策的交集。工作階段許可也可以是使用者身分型政策和資源型政策的交集。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## 範例：使用 GetFederationToken 指派許可
您可以將 `GetFederationToken` API 動作與不同類型的政策一起使用。以下是幾個範例。
### 連接至 IAM 使用者的政策
在這個範例中，您有一個以瀏覽器為基礎的用戶端應用程式，它依賴於兩個後端的 Web 服務。一個後端服務是您自己的身分驗證伺服器，使用您自己的身分系統來驗證用戶端應用程式。另一個後端服務是 AWS 服務，可提供一些用戶端應用程式的功能。用戶端應用程式由您的伺服器進行身分驗證，您的伺服器會建立或擷取適當的許可政策。然後，您的伺服器呼叫 `GetFederationToken` API 以取得暫時安全憑證，並將這些憑證傳回給用戶端應用程式。然後，用戶端應用程式可以使用臨時安全登入資料直接向 AWS 服務提出請求。此架構可讓用戶端應用程式提出 AWS 請求，而無需內嵌長期 AWS 登入資料。
您的身分驗證伺服器使用名為 `token-app` 之 IAM 使用者的長期安全憑證來呼叫 `GetFederationToken` API。但長期 IAM 使用者憑證會保持在伺服器上且絕對不會發佈到用戶端。下列範例政策會連接至 `token-app` IAM 使用者，並定義 AWS STS 聯合身分使用者 （用戶端） 所需的最廣泛許可集。請注意，您的身分驗證服務需要 `sts:GetFederationToken`許可，才能取得 AWS STS 聯合身分使用者的臨時安全登入資料。
**Example 連接到呼叫 `GetFederationToken` 的 IAM 使用者 `token-app` 的政策範例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
上述政策會將多個許可授予 IAM 使用者。不過，僅此政策不會將任何許可授予 AWS STS 聯合身分使用者。如果此 IAM 使用者呼叫 `GetFederationToken`，且 未將政策作為 API AWS STS 呼叫的參數傳遞，則產生的聯合身分使用者沒有有效的許可。
### 工作階段政策作為參數傳遞
確保 AWS STS 聯合身分使用者獲指派適當許可的最常見方法是在 `GetFederationToken` API 呼叫中傳遞工作階段政策。擴展前面的範例，假設使用 IAM 使用者 `token-app` 憑證來呼叫 `GetFederationToken`。假設以下工作階段政策做為 API 呼叫的參數傳遞。所產生的 AWS STS 聯合身分使用者具有列出名為 `productionapp` 的 Amazon S3 儲存貯體內容的許可。該使用者無法對 `productionapp` 儲存貯體中的項目執行 Amazon S3 `GetObject`、`PutObject` 和 `DeleteObject` 動作。
聯合身分使用者會獲派這些許可，因為這些許可是 IAM 使用者政策和您傳遞之工作階段政策的交集。
AWS STS 聯合身分使用者無法在 Amazon SNS、Amazon SQS、Amazon DynamoDB 或任何 S3 儲存貯體中執行動作，但 除外`productionapp`。即使這些許可已授予給與 `GetFederationToken` 呼叫相關聯的 IAM 使用者，這些動作仍然會遭到拒絕。
**Example 工作階段政策作為 `GetFederationToken` API 呼叫的參數傳遞範例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
```
### 資源型政策
有些 AWS 資源支援以資源為基礎的政策，而這些政策提供另一種機制，可將許可直接授予 AWS STS 聯合身分使用者。只有部分 AWS 服務支援以資源為基礎的政策。例如，Amazon S3 具有儲存貯體，Amazon SNS 具有主題，並且 Amazon SQS 具有可以連接政策的佇列。如需有關支援以資源為基礎的政策的所有服務的清單，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md) 並查看表格中的「以資源為基礎的政策」資料列。您可以使用資源型政策，直接將許可指派給 AWS STS 聯合身分使用者。透過在資源型政策的 `Principal`元素中指定 AWS STS 聯合身分使用者的 Amazon Resource Name (ARN) 來執行此操作。以下範例使用名為 `productionapp` 的 S3 儲存貯體說明此範例並擴展前面的範例。
以下以資源為基礎的政策已連接到儲存貯體。此儲存貯體政策允許名為 Carol AWS STS 的聯合身分使用者存取儲存貯體。當前述的範例政策連接至 `token-app` IAM 使用者時，名為 Carol AWS STS 的聯合身分使用者具有許可，可在名為 的儲存貯體上執行 `s3:GetObject`、 `s3:PutObject`和 `s3:DeleteObject`動作`productionapp`。即使沒有工作階段政策做為 `GetFederationToken` API 呼叫的參數傳遞時，也是如此。這是因為在此案例中，名為 Carol AWS STS 的聯合身分使用者已由下列以資源為基礎的政策明確授予許可。
請記住，只有當 AWS STS 這些許可同時明確授予 IAM 使用者***和***聯合身分使用者時， AWS STS 才會授予聯合身分使用者許可。也可以由以資源為基礎的政策授予 （在帳戶中），該政策在政策的 AWS STS `Principal`元素中明確命名聯合身分使用者，如下列範例所示。
**Example 允許存取聯合身分使用者的儲存貯體政策範例**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
如需有關如何評估政策的詳細資訊，請參閱[政策評估邏輯](reference_policies_evaluation-logic.md)。
# GetSessionToken 許可
呼叫 `GetSessionToken` API 操作或 `get-session-token` CLI 命令的主要時間是，當使用者必須透過多重要素驗證 (MFA) 進行身分驗證時。可以編寫只允許特定操作的一項政策，且只有在這些操作是由經過 MFA 身分驗證的使用者提出的請求時，才允許執行。為成功通過 MFA 身分驗證檢查，使用者必須先呼叫 `GetSessionToken`，並且包含可選的`SerialNumber` 和 `TokenCode` 參數。如果使用者成功通過 MFA 裝置身分驗證，`GetSessionToken` API 操作傳回的憑證包含 MFA 內容。此內容表示使用者通過 MFA 身分驗證，並且獲得 API 操作授權，其需要 MFA 身分驗證。
## GetSessionToken 需要的許可
使用者要取得工作階段權杖並不需要許可。`GetSessionToken` 操作的目的是使用 MFA 驗證使用者的身分。您不能使用政策來控制驗證操作。
若要授予執行大部分 AWS 操作的許可，請將具有相同名稱的動作新增至政策。例如，若要建立使用者，您必須使用 `CreateUser` API 操作、`create-user` CLI 命令或 AWS 管理主控台。若要執行這些操作，您必須擁有一個政策，其可讓您存取 `CreateUser` 動作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
您可以在您的政策中包含 `GetSessionToken` 動作，但不會影響使用者執行 `GetSessionToken` 操作的能力。
## GetSessionToken 授予的許可
如果使用 IAM 使用者的憑證呼叫 `GetSessionToken`，臨時安全性憑證與 IAM 使用者會有相同的許可。同樣地，如果 使用 AWS 帳戶根使用者 登入資料`GetSessionToken`呼叫 ，則暫時安全登入資料具有根使用者許可。
**注意**
我們建議您不要使用根使用者憑證呼叫 `GetSessionToken`。相反的，請遵循我們的[最佳實務](best-practices-use-cases.md)，並建立具有所需許可的 IAM 使用者。然後，使用這些 IAM 使用者與 進行日常互動 AWS。
當您呼叫 `GetSessionToken` 時您獲得的臨時憑證有下列功能和限制：
+ 您可以使用登入資料來存取 ， AWS 管理主控台 方法是將登入資料傳遞至位於 的聯合單一登入端點`https://signin.aws.amazon.com/federation`。如需詳細資訊，請參閱[啟用 AWS 主控台的自訂身分代理程式存取](id_roles_providers_enable-console-custom-url.md)。
+ 您**無法**使用憑證來呼叫 IAM 或 AWS STS API 操作。**您可以使用**它們來呼叫其他服務的 API 操作 AWS 。
將此 API 操作和其限制及功能與在 [比較 AWS STS 登入資料](id_credentials_sts-comparison.md) 建立臨時安全性憑證的 API 操作相較
如需有關使用 `GetSessionToken` 的受 MFA 保護之 API 存取的詳細資訊，請參閱 [透過 MFA 實現安全的 API 存取](id_credentials_mfa_configure-api-require.md)。
# 停用臨時安全性憑證的許可
暫時安全憑證在過期之前持續有效。這些憑證在指定的持續時間內有效，從 900 秒 (15 分鐘) 至最長 129,600 秒 (36 小時)。預設工作階段持續時間為 43,200 秒 (12 小時)。您可以撤銷這些憑證，但也必須變更 IAM 使用者或角色的許可，以停止使用遭洩漏的憑證進行惡意帳戶活動。每次使用指派給臨時安全登入資料的許可來提出 AWS 請求時，都會進行評估。從登入資料中移除所有許可後，使用它們的 AWS 請求會失敗。
政策更新可能需要幾分鐘的時間才會生效。對於 IAM 角色工作階段，您可以撤銷角色的臨時安全憑證，以強制所有擔任該角色的使用者重新驗證並請求新的憑證。如需詳細資訊，請參閱[撤銷角色的臨時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)。
您無法變更 的許可 AWS 帳戶根使用者。同樣地，以根使用者身分登入時，您無法更改呼叫 `GetFederationToken` 或 `GetSessionToken` 建立的暫時安全憑證許可。因此，我們建議您不要以根使用者身分呼叫 `GetFederationToken` 或 `GetSessionToken`。
如需有關如何變更 IAM 使用者的許可的程序，請參閱[變更 IAM 使用者的許可](id_users_change-permissions.md)。
如需有關如何變更 IAM 角色的許可的程序，請參閱[更新角色的許可](id_roles_update-role-permissions.md)。
**重要**
您無法在 IAM 中編輯從 IAM Identity Center 許可集建立的角色。您必須撤銷 IAM Identity Center 中使用者的作用中許可集工作階段。如需詳細資訊，請參閱 *IAM Identity Center User Guide* 中的 [Revoke active IAM role sessions created by permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)。
**Topics**
+ [拒絕存取與角色關聯的所有 IAM 角色工作階段](#deny-access-to-all-sessions)
+ [拒絕存取特定 IAM 角色工作階段](#deny-access-to-specific-session)
+ [拒絕存取具有條件內容索引鍵的臨時安全憑證工作階段](#deny-access-to-specific-session-condition-key)
+ [使用資源型政策拒絕存取特定主體](#deny-access-with-resource-based)
## 拒絕存取與角色關聯的所有 IAM 角色工作階段
此程序拒絕與角色關聯的**所有** IAM 角色工作階段的許可。當您擔心被以下身分進行可疑存取時，請使用此方法：
+ 使用跨帳戶存取權的其他帳戶中的主體
+ 具有存取您帳戶中 AWS 資源許可的外部使用者身分
+ 在行動或 Web 應用程式中，已透過 OIDC 提供者驗證的使用者
若要變更或移除透過呼叫 `AssumeRole`、`AssumeRoleWithSAML`、`AssumeRoleWithWebIdentity`、`GetFederationToken` 或 `GetSessionToken` 而取得的指派給臨時安全憑證的許可，您可以編輯或刪除為角色定義許可的身分型政策。
**重要**
如果存在允許主體存取的以資源為基礎的政策，您還必須為該資源新增明確拒絕。如需詳細資訊，請參閱 [使用資源型政策拒絕存取特定主體](#deny-access-with-resource-based)。
**若要拒絕存取與角色關聯的**所有** IAM 角色工作階段**
1. 登入 AWS 管理主控台 並開啟 IAM 主控台。
1. 在導覽窗格中，選擇**角色**。
1. 選擇要編輯的角色名稱。您可以使用搜尋方塊來篩選清單。
1. 選擇**許可**索引標籤。
1. 選取要編輯的相關政策。在編輯客戶管理政策之前，檢閱**連接的實體**索引標籤，以避免中斷對可能已連接相同政策的其他身分的存取。
1. 選擇 **JSON** 標籤並更新政策以拒絕所有資源和動作。
**注意**
這些許可與 AWS 受管政策 [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) 中的許可相同。您可以將此 AWS 受管政策連接至您想要拒絕所有存取的任何 IAM 使用者或角色。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. 在 **Review** (檢視) 頁面上，查看政策 **Summary** (摘要)，然後選擇 **Save changes** (儲存政策) 以儲存您的工作。
在更新政策時，所做出的變更將影響與該角色關聯的所有暫時安全憑證的許可，包括在更改該角色的許可政策之前發行的憑證。
更新政策之後，您可以[撤銷角色的暫時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)以立即撤銷角色所發行憑證的所有許可。
## 拒絕存取特定 IAM 角色工作階段
當您使用全部拒絕政策更新 IAM 角色或完全刪除該角色時，有權存取該角色的所有使用者都會中斷。您可以拒絕存取，而不會影響與該角色關聯的所有其他工作階段的許可。
您可以使用[條件內容索引鍵](#deny-access-to-specific-session-condition-key)或[以資源為基礎的政策](#deny-access-with-resource-based)拒絕 `Principal` 的許可。
**提示**
您可以使用 AWS CloudTrail 日誌來尋找聯合身分使用者的 ARNs。如需詳細資訊，請參閱[如何使用 輕鬆識別您的聯合身分使用者 AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/)。
## 拒絕存取具有條件內容索引鍵的臨時安全憑證工作階段
您可以在想要拒絕存取特定臨時安全憑證工作階段的情況下使用身分型政策中的條件內容索引鍵，而不影響建立憑證的 IAM 使用者或角色的許可。對於 IAM 角色，在更新政策之後，您還可以[撤銷角色的臨時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)工作階段，以立即撤銷所有發行的憑證。
如需條件內容索引鍵的詳細資訊，請參閱 [AWS 全域條件內容索引鍵](reference_policies_condition-keys.md)。
### aws:PrincipalArn
您可以在身分型政策中使用條件內容索引鍵 [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn)，依 Amazon Resource Name (ARN) 拒絕存取特定主體。您可以透過在政策的條件元素中指定暫時安全登入資料與之關聯的 AWS STS IAM 使用者、角色或聯合身分使用者工作階段的 ARN 來執行此操作。
**若要依 ARN 拒絕存取特定主體**
1. 在 IAM 主控台導覽窗格中，選擇**使用者**或**角色**。
1. 選擇要編輯的 IAM 使用者或角色的名稱。您可以使用搜尋方塊來篩選清單。
1. 選擇**許可**索引標籤。
1. 選取要編輯的相關政策。在編輯客戶管理政策之前，檢閱**連接的實體**索引標籤，以避免中斷對可能已連接相同政策的其他身分的存取。
1. 選擇 **JSON** 標籤並為主體 ARN 新增拒絕陳述式，如下列範例所示。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. 在 **Review** (檢視) 頁面上，查看政策 **Summary** (摘要)，然後選擇 **Save changes** (儲存政策) 以儲存您的工作。
### aws:SourceIdentity
您可以在身分型政策中使用條件內容索引鍵 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)，拒絕存取與 IAM 角色工作階段關聯的特定來源身分。只要角色工作階段是在委託人使用任何 AWS STS `assume-role`\$1 CLI 命令或 AWS STS `AssumeRole`\$1 API 操作擔任角色時，透過設定`SourceIdentity`請求參數發出，就會套用。您可以透過在政策的 `Condition` 元素中指定臨時安全憑證關聯的來源身分來執行此操作。
與內容索引鍵 [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname) 不同，在設定來源身分之後，無法變更值。`aws:SourceIdentity` 索引鍵會出現在由角色所採取的所有動作的請求內容中。當您使用工作階段憑證來擔任另一個角色時，來源身分仍然存在於後續角色工作階段。從另一個角色取得及擔任角色稱為[角色鏈結](id_roles.md#iam-term-role-chaining)。
下列政策顯示如何使用條件內容索引鍵 `aws:SourceIdentity` 拒絕存取暫時安全憑證工作階段的範例。如果您指定與角色工作階段關聯的來源身分，則它會拒絕含有具名來源身分的角色工作階段，而不會影響建立憑證的角色的許可。在此範例中，發出角色工作階段時，主體設定的來源身分為 `nikki_wolf@example.com`。具有來源身分 `nikki_wolf@example.com` 的角色工作階段發出的任何請求都會遭拒，因為來源身分包含在政策條件中，且政策效果設定為 `Deny`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
您可以在身分型政策中使用條件內容索引鍵 [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) 拒絕存取與 IAM 使用者或角色關聯的所有或特定臨時安全憑證工作階段。您可以透過在政策的 `Condition`元素中指定暫時安全登入資料相關聯的 IAM AWS STS 使用者、角色或聯合身分使用者工作階段的唯一識別符 (ID) 來執行此操作。
下列政策顯示如何使用條件內容索引鍵 `aws:userid` 拒絕存取暫時安全憑證工作階段的範例。
+ `AIDAXUSER1` 代表 IAM 使用者的唯一 ID。指定 IAM 使用者的唯一 ID 作為內容索引鍵 `aws:userid` 的值將拒絕存取 IAM 使用者。其中包括透過呼叫 `GetSessionToken` API 建立的任何臨時安全憑證工作階段。
+ `AROAXROLE1:*` 代表與 IAM 角色關聯的所有工作階段的唯一 ID。將 IAM 角色的唯一 ID 和 caller-specified-role-session-name 部分中的萬用字元 (\$1) 指定為內容索引鍵 `aws:userid` 的值將拒絕與該角色關聯的所有工作階段。
+ `AROAXROLE2:` 代表擔任角色工作階段的唯一 ID。在擔任角色唯一 ID 的 caller-specified-role-session-name 部分中，如果使用 StringLike 條件運算子，您可以指定角色工作階段名稱或萬用字元。如果您指定角色工作階段名稱，則它會拒絕具名角色工作階段，而不會影響建立憑證的角色的許可。如果您為角色工作階段名稱指定萬用字元，則它會拒絕與角色關聯的所有工作階段。
**注意**
呼叫者指定的角色工作階段名稱是擔任角色工作階段的唯一識別碼的一部分，可能會在角色鏈結期間變更。當一個角色擔任另一個角色時，會發生角色鏈結。當委託人使用 API 操作擔任角色時，會使用 AWS STS `AssumeRole` `RoleSessionName`請求參數設定角色工作階段名稱。
+ `account-id:` 代表 AWS STS 聯合身分使用者工作階段的唯一 ID。IAM 使用者透過呼叫 `GetFederationToken` API 來建立此工作階段。為 AWS STS 聯合身分使用者工作階段指定唯一 ID 會拒絕具名聯合身分工作階段，而不會影響建立憑證的 IAM 使用者的許可。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
如需主體索引鍵值的特定範例，請參閱 [主體索引鍵值](reference_policies_variables.md#principaltable)。如需有關 IAM 唯一識別碼以及如何取得它們的資訊，請參閱[唯一識別碼](reference_identifiers.md#identifiers-unique-ids)。
## 使用資源型政策拒絕存取特定主體
若要使用資源型政策限制對特定主體的存取，您可以使用 `Condition` 元素中的條件內容索引鍵 [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) 或 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)。資源型政策是連接至資源的許可政策，可控制誰可以存取資源，以及他們可以對其執行哪些動作。
當您使用`aws:PrincipalARN`內容金鑰時，請在政策的條件元素中指定與暫時安全登入資料相關聯的 IAM AWS STS 使用者、角色或聯合身分使用者工作階段的 ARN。下列範例政策示範如何在資源型政策中使用 `aws:PrincipalARN` 內容索引鍵：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
當您使用 `aws:SourceIdentity` 內容索引鍵時，在政策的 `Condition` 元素中指定與角色的臨時安全憑證關聯的來源身分值。只要角色工作階段是在委託人使用任何 AWS STS `assume-role`\$1 CLI 命令或 AWS STS `AssumeRole`\$1 API 操作擔任角色時，透過設定`SourceIdentity`請求參數發出，就會套用。下列範例示範如何在資源型政策中使用 `aws:SourceIdentity` 內容索引鍵：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
如果您僅更新主體的身分型政策，其仍然可以執行資源型政策中允許的動作，除非在身分型政策中明確拒絕這些動作。
**若要在資源型政策中拒絕存取特定主體**
1. 請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md) 以查看服務是否支援以資源為基礎的政策。
1. 登入 AWS 管理主控台 並開啟 服務的 主控台。每個服務在主控台中都有不同的位置用於附加政策。
1. 編輯資源型政策。新增拒絕政策陳述式以指定憑證的識別資訊：
1. 在 `Principal` 元素中，輸入萬用字元 (\$1)。在 `Condition` 元素中，主體將受到限制。
1. 在 `Effect` 元素中，輸入 "Deny"。
1. 在 `Action` 中，輸入服務命名空間和要拒絕的動作名稱。若要拒絕所有動作，請使用萬用字元 (\$1)。例如：`"s3:*"`。
1. 在 `Resource` 元素中，輸入目標資源的 ARN。例如：`"arn:aws:s3:::amzn-s3-demo-bucket"`。
1. 在 `Condition` 元素中，指定 `aws:PrincipalARN` 或 `aws:SourceIdentity` 內容索引鍵。
如果您使用 `aws:PrincipalARN` 內容索引鍵，請輸入要拒絕其存取之主體的 ARN。
如果您使用 `aws:SourceIdentity` 內容索引鍵，請在角色工作階段中輸入要拒絕存取的來源身分值。
1. 儲存您的工作。
# 授予許可以建立暫時性安全憑證
依預設，IAM 使用者沒有為 AWS STS 聯合身分使用者工作階段和角色建立臨時安全憑證的許可。您必須使用政策提供您的使用者這些許可。雖然您可以直接授予許可給使用者，我們強烈建議您將許可授予群組。這可讓許可的管理更輕鬆。當有人不再需要執行與許可相關的任務時，您只需從群組中移除許可。如果其別人需要執行該任務，將它們新增到群組以授予許可。
若要授予 IAM 群組為 AWS STS 聯合身分使用者工作階段或角色建立臨時安全憑證的許可，您可以連接能夠授予以下一個或兩個權限的政策：
+ 若要讓 OIDC 和 SAML 聯合主體存取 IAM 角色，請將存取權授予 AWS STS `AssumeRole`。
+ 對於不需要角色的 AWS STS 聯合身分使用者，將存取權授予 AWS STS `GetFederationToken`。
如需有關 `AssumeRole` 和 `GetFederationToken` API 操作間差異的詳細資訊，請參閱 [請求臨時安全憑證](id_credentials_temp_request.md)。
IAM 使用者也可以呼叫 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 建立臨時安全憑證。使用者呼叫 `GetSessionToken` 不需要許可。此操作的目的是使用 MFA 驗證使用者的身分。您不能使用政策來控制身分驗證。這表示您無法避免 IAM 使用者呼叫 `GetSessionToken` 來建立臨時憑證。
**Example 授予許可以擔任角色的政策範例**
下列範例政策授予 呼叫 中`UpdateApp`角色`AssumeRole`的許可 AWS 帳戶 `123123123123`。當使用 `AssumeRole` 時，代表聯合身分使用者建立安全憑證的使用者 (或應用程式)，無法委派角色許可政策中未指定的許可。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example 授予許可以建立聯合身分使用者的暫時性安全憑證的政策範例**
下列範例政策會授予許可以存取 `GetFederationToken`。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**重要**
當您授予 IAM 使用者許可，讓他們能夠透過 `GetFederationToken` 為 AWS STS 聯合身分使用者建立臨時安全憑證時，請留意，這會允許這些使用者委派自己的許可。如需在 IAM 使用者和 之間委派許可的詳細資訊 AWS 帳戶，請參閱 [委派存取權限的政策範例](id_roles_create_policy-examples.md)。如需有關如何控制暫時性安全憑證的許可的詳細資訊，請參閱[臨時安全憑證的許可](id_credentials_temp_control-access.md)。
**Example 授予使用者有限許可以建立聯合身分使用者的暫時性安全憑證的政策範例**
當您讓 IAM 使用者呼叫 `GetFederationToken`，最佳實務是限制 IAM 使用者可以委派的許可。例如，下列政策顯示如何讓 IAM 使用者僅為名稱開頭為 *Manager* AWS STS 的聯合身分使用者建立臨時安全登入資料。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# 授予許可以使用身分增強型主控台工作階段
身分增強主控台工作階段可在 AWS IAM Identity Center 使用者登入時將使用者和工作階段 IDs AWS 包含在使用者的主控台工作階段中。例如，Amazon Q Developer Pro 利用身分增強型主控台工作階段來個人化服務體驗。如需有關身分增強型主控台工作階段的詳細資訊，請參閱 *AWS IAM Identity Center User Guide* 中的 [Enabling identity-enhanced console sessions](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html)。如需有關 Amazon Q Developer 設定的資訊，請參閱 *Amazon Q Developer User Guide* 中的 [Setting up Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html)。
為了讓身分增強型主控台工作階段可供使用者使用，您必須使用身分型政策向 IAM 主體授予代表其自己的主控台工作階段的資源的 `sts:SetContext` 許可。
**重要**
依預設，使用者無權為身分增強型主控台工作階段設定內容。為此，您必須在身分型政策中向 IAM 主體授予 `sts:SetContext` 許可，如下面的政策範例所示。
下列以身分為基礎的政策範例會將 `sts:SetContext`許可授予 IAM 主體，允許主體為自己的主控台工作階段設定身分增強型 AWS 主控台工作階段內容。政策資源 `arn:aws:sts::account-id:self`代表呼叫者的 AWS 工作階段。如果跨多個帳戶部署相同的許可政策 (例如使用 IAM Identity Center 許可集部署此政策)，則可以將 `account-id` ARN 區段取代為萬用字元 `*`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------