本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # IAM 教學課程：定義根據標籤存取 AWS 資源的許可 屬性型存取控制 (ABAC) 是一種授權策略，可根據屬性來定義許可。在 中 AWS，這些屬性稱為*標籤*。您可以將標籤連接至 IAM 資源，包括 IAM 實體 （使用者或角色） 和 AWS 資源。您可以定義使用標籤條件金鑰的政策，以根據主體的標籤來授與許可。當您使用標籤來控制對 AWS 資源的存取時，您可以允許您的團隊和資源以較少的政策變更 AWS 來成長。ABAC 政策比傳統 AWS 政策更靈活，需要您列出每個個別資源。如需 ABAC 及其優於傳統政策的詳細資訊，請參閱 [使用 ABAC 授權根據屬性定義許可](introduction_attribute-based-access-control.md)。 **注意** 您必須傳遞每個工作階段標籤的單一值。 AWS Security Token Service 不支援多值工作階段標籤。 **Topics** + [ ## 教學課程概觀 ](#tutorial_attribute-based-access-control-overview) + [ ## 先決條件 ](#tutorial_abac_prereqs) + [ ## 步驟 1：建立測試使用者 ](#tutorial_abac_step1) + [ ## 步驟 2：建立 ABAC 政策 ](#tutorial_abac_step2) + [ ## 步驟 3：建立角色 ](#tutorial_abac_step3) + [ ## 步驟 4：測試建立秘密 ](#tutorial_abac_step4) + [ ## 步驟 5：測試檢視秘密 ](#tutorial_abac_step5) + [ ## 步驟 6：測試可擴展性 ](#tutorial_abac_step6) + [ ## 步驟 7：測試更新和刪除秘密 ](#tutorial_abac_step7) + [ ## 摘要 ](#tutorial-abac-summary) + [ ## 相關資源 ](#tutorial_abac_related) + [ # IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記 ](tutorial_abac-saml.md) ## 教學課程概觀 本教學說明如何建立和測試政策，以允許具有主體標籤的 IAM 角色存取具有相符標籤的資源。當主體向 AWS發出請求時，會根據主體和資源標籤是否相符來授與其許可。此策略允許個人僅檢視或編輯其任務所需的 AWS 資源。 **案例** 假設您是 Example Corporation 這間大型公司的首席開發人員，也是經驗豐富的 IAM 管理員。您很熟悉如何建立及管理 IAM 使用者、角色和政策。您想要確保您的開發工程師和品質保證團隊成員可以存取所需資源。您也需要可隨著公司成長而擴展的策略。 您可以選擇使用 AWS 資源標籤和 IAM 角色主體標籤，為支援它的服務實作 ABAC 策略，以 開頭 AWS Secrets Manager。若要了解哪些服務支援以標籤為基礎的授權，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。若要了解您可以在政策中搭配每個服務的動作和資源使用哪些標記條件金鑰，請參閱 [AWS 服務的動作、資源和條件金鑰](reference_policies_actions-resources-contextkeys.html)。您可以設定您的 SAML 類型或 Web 身分提供者，將[工作階段標籤](id_session-tags.md)傳遞至 AWS。當您的員工聯合到 時 AWS，其屬性會套用至其產生的委託人 AWS。您接著可以使用 ABAC 來根據這些屬性允許或拒絕許可。若要了解搭配 SAML 聯合身分使用工作階段標籤與本教學的不同，請參閱 [IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記](tutorial_abac-saml.md)。 您的工程和品質保證團隊成員負責 **Pegasus** 或 **Unicorn** 專案。您可以選擇下列 3 個字元的專案和團隊標籤值： + `access-project` = `peg` 適用於 **Pegasus** 專案 + `access-project` = `uni` 適用於 **Unicorn** 專案 + `access-team` = `eng` 適用於工程團隊 + `access-team` = `qas` 適用於品質保證團隊 此外，您選擇要求`cost-center`成本分配標籤來啟用自訂 AWS 帳單報告。如需詳細資訊，請參閱 *AWS 帳單與成本管理 使用者指南*中的[使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)。 **重要決策摘要** + 員工使用 IAM 使用者憑證登入，然後擔任其團隊和專案的 IAM 角色。如果您的公司有專屬身分系統，您可以設定聯合以允許員工在沒有 IAM 使用者的情況下擔任角色。如需更多詳細資訊，請參閱 [IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記](tutorial_abac-saml.md)。 + 相同的政策會連接至所有角色。動作會根據標籤而受允許或拒絕。 + 員工可以建立新的資源，但僅限於將相同的標籤連接至套用到其角色的資源時。這可確保員工在建立資源之後能夠檢視資源。管理員不再需要使用新資源的 ARN 來更新政策。 + 員工可以讀取其團隊所擁有的資源，不論專案為何。 + 員工可以更新及刪除自己團隊和專案所擁有的資源。 + IAM 管理員可以新增新專案的角色。他們可以建立並標記新的 IAM 使用者，以允許存取適當的角色。管理員不需要編輯政策來支援新的專案或團隊成員。 在此教學中，您將為每個資源加上標籤、為您的專案角色加上標籤並將政策新增至角色，以允許前述的行為。產生的政策允許角色 `Create`、`Read`、`Update` 和 `Delete` 存取以相同專案和團隊標籤所標記的資源。政策也允許跨專案 `Read` 存取以相同團隊標記的資源。 ![\[圖表顯示兩個專案，其中角色僅限於在其專案外部唯讀存取，同時擁有在其自己的專案中建立、讀取、更新和刪除資源的許可。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png) ## 先決條件 若要執行此教學課程中的步驟，您必須具備以下內容： + 您可以具有管理許可的使用者身分 AWS 帳戶 登入 。 + 您的 12 位數帳戶 ID，用於在步驟 3 中建立角色。 若要使用 尋找 AWS 您的帳戶 ID 號碼 AWS 管理主控台，請選擇右上角導覽列上的**支援**，然後選擇**支援中心**。帳戶號碼 (ID) 會顯示在左側導覽窗格。 ![\[支援 顯示帳戶號碼的中心頁面。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/account-id-support-center.console.png) + 體驗在 AWS 管理主控台中建立並編輯 IAM 使用者、角色和政策。不過，如果您需要記住 IAM 管理程序的協助，此教學提供的連結可讓您檢視逐步說明。 ## 步驟 1：建立測試使用者 針對測試，請建立四個 IAM 使用者，並授與其許可擔任具有相同標籤的角色。這可讓您更輕鬆地新增更多使用者到您的團隊。當您標記使用者時，使用者會自動取得擔任正確角色的存取權。如果使用者只在一個專案和團隊中工作，則您不必將使用者新增至角色的信任政策。 1. 建立下列名為 `access-assume-role` 的客戶受管政策。如需如何建立 JSON 政策的詳細資訊，請參閱 [建立 IAM 政策](access_policies_create-console.md#access_policies_create-start)。 **ABAC 政策：擔任任何 ABAC 角色，但僅限使用者和角色標籤相符時** 下列政策允許使用者擔任您帳戶中名稱字首為 `access-` 的任何角色。角色也必須以與使用者相同的專案、團隊和成本中心標籤來標記。 若要使用此政策，請將*斜體預留位置文字*取代為您的帳戶資訊。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/access-*", "Condition": { "StringEquals": { "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" } } } ] } ``` ------ 若要將本教學擴展為大量使用者，您可以將政策連接至群組，並將每個使用者新增至群組。如需詳細資訊，請參閱[建立 IAM 群組](id_groups_create.md)及[編輯 IAM 群組中的使用者](id_groups_manage_add-remove-users.md)。 1. 建立下列 IAM 使用者、連接 `access-assume-role` 許可政策。務必選取**為使用者提供 AWS 管理主控台的存取權限**，然後新增下列標籤。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 步驟 2：建立 ABAC 政策 建立下列名為 **access-same-project-team** 的政策。您會在後續步驟將此政策新增至角色。如需如何建立 JSON 政策的詳細資訊，請參閱 [建立 IAM 政策](access_policies_create-console.md#access_policies_create-start)。 如需您可以針對本教學進行調整的其他政策，請參閱下列頁面： + [控制 IAM 主體的存取權限](access_iam-tags.md#access_iam-tags_control-principals) + [Amazon EC2：允許以程式設計方式和在主控台中開始或停止使用者已標記的 EC2 執行個體](reference_policies_examples_ec2_tag-owner.md) + [EC2：依據比對主體和資源的標籤啟動或停止執行個體](reference_policies_examples_ec2-start-stop-match-tags.md) + [EC2：依據標籤啟動或停止執行個體](reference_policies_examples_ec2-start-stop-tags.md) + [IAM：擔任具有特定標籤的角色](reference_policies_examples_iam-assume-tagged-role.md) **ABAC 政策：僅在主體與資源標籤相符時，才存取 Secrets Manager 資源** 下列政策允許主體建立、讀取、編輯及刪除資源，但僅限資源受標記為與主體相同的鍵值對時。當主體建立資源時，必須新增 `access-project`、`access-team`、和 `cost-center` 標籤，其值符合主體的標籤。此政策也允許新增選用的 `Name` 或 `OwnedBy` 標籤。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllActionsSecretsManagerSameProjectSameTeam", "Effect": "Allow", "Action": "secretsmanager:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "access-project", "access-team", "cost-center", "Name", "OwnedBy" ] }, "StringEqualsIfExists": { "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}", "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}", "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}" } } }, { "Sid": "AllResourcesSecretsManagerNoTags", "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword", "secretsmanager:ListSecrets" ], "Resource": "*" }, { "Sid": "ReadSecretsManagerSameTeam", "Effect": "Allow", "Action": [ "secretsmanager:Describe*", "secretsmanager:Get*", "secretsmanager:List*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}" } } }, { "Sid": "DenyUntagSecretsManagerReservedTags", "Effect": "Deny", "Action": "secretsmanager:UntagResource", "Resource": "*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "access-*" } } }, { "Sid": "DenyPermissionsManagement", "Effect": "Deny", "Action": "secretsmanager:*Policy", "Resource": "*" } ] } ``` ------ **此政策的功能為何？** + `AllActionsSecretsManagerSameProjectSameTeam` 陳述式允許在所有相關資源上執行此服務的所有動作，但僅限於資源標籤符合主體標籤時。透過將 `"Action": "secretsmanager:*"` 新增至政策，政策會隨著 Secrets Manager 成長而成長。如果 Secrets Manager 新增新的 API 操作，您不需要將該動作新增至陳述式。陳述式使用三個條件區塊來實作 ABAC。只有在三個區塊全部傳回 true 時，才會允許此請求。 + 如果資源上有指定的標籤鍵，而且其值符合主體的標籤，則此陳述式的第一個條件區塊會傳回 true。此區塊會為不相符的標籤或不支援資源標記的動作傳回 false。若要了解此區塊不允許哪些動作，請參閱 [動作、資源和條件金鑰 AWS Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html)。該頁面顯示對 [**Secret** (秘密) 資源類型](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies)執行的動作支援 `secretsmanager:ResourceTag/tag-key` 條件索引鍵。部分 [Secrets Manager 動作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions)不支援該資源類型，包括 `GetRandomPassword` 和 `ListSecrets`。您必須建立額外的陳述式以允許這些動作。 + 如果請求中傳遞的每個標籤鍵都包含在指定清單中，則第二個條件區塊會傳回 true。此動作是使用 `ForAllValues` 搭配 `StringEquals` 條件運算子來完成。如果未傳遞金鑰或金鑰集的子集，則條件會傳回 true。這允許了不允許在請求中傳遞標籤的 `Get*` 操作。如果申請者包含了不在清單中的標籤鍵，則條件會傳回 false。在請求中傳遞的每個標籤鍵，都必須符合此清單的成員。如需詳細資訊，請參閱[用於多值內容索引鍵的集運算子](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)。 + 如果請求支援傳遞標籤 (如果這三個標籤都存在)，且符合主體標籤值，則第三個條件區塊會傳回 true。如果請求不支援傳遞標籤，此區塊也會傳回 true。這要歸功於條件運算子中的 [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists)。如果在支援該標籤的動作期間沒有傳遞任何標籤，或標籤鍵和值不相符，則區塊會傳回 false。 + `AllResourcesSecretsManagerNoTags` 陳述式允許第一個陳述式不允許的 `GetRandomPassword` 和 `ListSecrets` 動作。 + 如果主體所標記的存取團隊標籤與資源相同，則 `ReadSecretsManagerSameTeam` 陳述式允許唯讀操作。無論專案或成本中心標籤為何，都允許此操作。 + `DenyUntagSecretsManagerReservedTags` 陳述式拒絕從 Secrets Manager 移除鍵開頭為 "access-" 之標籤的請求。這些標籤用於控制對資源的存取，因此移除標籤可能會移除許可。 + `DenyPermissionsManagement` 陳述式拒絕建立、編輯或刪除 Secrets Manager 以資源為基礎的政策的存取。這些政策可用來變更秘密的許可。 **重要** 此政策使用策略來允許服務的所有動作，但會明確拒絕更改許可的動作。拒絕動作會覆寫任何其他允許主體執行該動作的政策。這可能會產生意外的結果。根據最佳實務，只有在該動作無論何種情況都不應允許的情況下，才使用明確拒絕。否則，請允許包含個別動作的清單，且將不需要的動作預設拒絕。 ## 步驟 3：建立角色 建立下列 IAM 角色，並連接您在先前步驟中建立的 **access-same-project-team** 政策。如需建立 IAM 角色的詳細資訊，請參閱 [建立角色以將許可授予 IAM 使用者](id_roles_create_for-user.md)。如果您選擇使用聯合，而非 IAM 使用者和角色，請參閱 [IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記](tutorial_abac-saml.md)。 | 任務職能 | 角色名稱 | 角色標籤 | 角色描述 | | --- | --- | --- | --- | | Pegasus 工程專案 | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | 允許工程師讀取所有工程資源，並建立和管理 Pegasus 工程資源。 | | Pegasus 品質保證專案 | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | 允許 QA 團隊讀取所有 QA 資源，並建立和管理所有 Pegasus QA 資源。 | | Unicorn 工程專案 | access-uni-engineering | access-project= `uni` access-team = `eng` cost-center = `123456` | 允許工程師讀取所有工程資源，並建立和管理 Unicorn 工程資源。 | | Unicorn Quality Assurance 專案 | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | 允許 QA 團隊讀取所有 QA 資源，並建立和管理所有 Unicorn QA 資源。 | ## 步驟 4：測試建立秘密 連接至角色的許可政策允許員工建立秘密。只有在秘密以其專案、團隊和成本中心來標記時，才允許此操作。以使用者身分登入來確認您的許可如預期般運作且擔任正確角色，並測試 Secrets Manager 中的活動。 **測試使用和不使用必要的標籤來建立秘密** 1. 在您的主要瀏覽器視窗中，保持以管理員使用者的身分登入，讓您可以檢閱 IAM 中的使用者、角色和政策。使用瀏覽器無痕式視窗或個別的瀏覽器進行測試。前往以下位置以 `access-Arnav-peg-eng` IAM 使用者身分登入 Secrets Manager 主控台：[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)。 1. 嘗試切換到 `access-uni-engineering` 角色。 此操作會失敗，因為 `access-project` 和 `cost-center` 標籤值與 `access-Arnav-peg-eng` 使用者和 `access-uni-engineering` 角色不相符。 如需在 中切換角色的詳細資訊 AWS 管理主控台，請參閱 [從使用者切換至 IAM 角色 (主控台)](id_roles_use_switch-role-console.md) 1. 切換到 `access-peg-engineering` 角色。 1. 使用下列資訊存放新的秘密。若要了解如何存放秘密，請參閱 *AWS Secrets Manager 使用者指南*中的[建立基本秘密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html)。 **重要** Secrets Manager 會顯示警示，指出您沒有與 Secrets Manager 搭配使用之其他 AWS 服務的許可。例如，若要建立 Amazon RDS 資料庫的憑證，您必須擁有描述 RDS 執行個體、RDS 叢集和 Amazon Redshift 叢集的許可。您可以忽略這些提醒，因為您未在本教學課程中使用這些特定 AWS 服務。 1. 在 **Select secret type (選取秘密類型)** 區段中，選擇 **Other type of secrets (其他類型的秘密)**。在兩個文字方塊中，輸入 `test-access-key` 和 `test-access-secret`。 1. 針對 **Secret name (秘密名稱)** 欄位輸入 `test-access-peg-eng`。 1. 從下表新增不同的標籤組合，並檢視預期的行為。 1. 選擇 **Store (存放)** 以嘗試建立秘密。在儲存失敗時，返回先前的 Secrets Manager 主控台頁面，並使用下表中的下一個標籤集。最後一個標籤集會受到允許，且將成功建立秘密。 下表顯示 `test-access-peg-eng` 角色的 ABAC 標籤組合。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. 登出並針對每個下列角色和標籤值來重複此程序的前三個步驟。在此程序的第四個步驟中，測試任何遺漏的標籤、選用標籤、不允許的標籤，和您選擇的無效標籤值。然後，使用必要標籤來建立具有下列標籤和名稱的秘密。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 步驟 5：測試檢視秘密 您連接到每個角色的政策允許員工檢視以其團隊名稱標記的任何秘密，不論他們的專案為何。在 Secrets Manager 中測試您的角色，確認您的許可如預期般運作。 **測試檢視包含和不含必要標籤的秘密** 1. 使用下列其中一個 IAM 使用者身分登入: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` 1. 切換至相符的角色： + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-uni-quality-assurance` 如需在 中切換角色的詳細資訊 AWS 管理主控台，請參閱 [從使用者切換至 IAM 角色 (主控台)](id_roles_use_switch-role-console.md)。 1. 在左側的導覽窗格中，選擇選單圖示以展開選單，然後選擇 **Secrets (秘密)**。 1. 無論您目前的角色為何，您應該都會看到資料表中的全部四個秘密。這是預期的結果，因為名為 `access-same-project-team` 的政策允許對所有資源執行 `secretsmanager:ListSecrets` 動作。 1. 選擇其中一個秘密的名稱。 1. 在秘密的詳細資訊頁面上，角色的標籤將決定您是否可以檢視頁面內容。將您的角色名稱與秘密名稱進行比較。如果這兩個名稱具有相同團隊名稱，則 `access-team` 標籤會相符。如果不相符，則會拒絕存取。 下表顯示每個角色的 ABAC 秘密檢視行為。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. 從頁面頂端的頁面導覽路徑中，選擇 **Secrets (秘密)** 以返回秘密清單。使用不同角色重複此程序中的步驟，以測試您是否可以檢視每個秘密。 ## 步驟 6：測試可擴展性 偏好以屬性為基礎的存取控制 (ABAC) 多過以角色為基礎的存取控制 (RBAC) 的重要原因是可擴展性。當您的公司新增專案、團隊或人員時 AWS，您不需要更新 ABAC 驅動的政策。例如，假設 Example Company 為名為 **Centaur** 的新專案提供資金。一位名為 Saanvi Sarkar 的工程師將擔任 **Centaur** 的主要工程師，同時繼續進行 **Unicorn** 專案。Sanvi 還將檢閱 **Peg** 專案的工作。另外還有幾位新聘的工程師，包括 Nikhil Jayashankar，只負責 **Centaur** 專案。 **將新專案新增至 AWS** 1. 以 IAM 管理原使用者身分登入，並開啟位於 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 的 IAM 主控台。 1. 在左側的導覽窗格中，選擇 **Roles (角色)**，然後新增名為 `access-cen-engineering` 的 IAM 角色 將 **access-same-project-team** 許可政策連接至角色，並新增下列角色標籤： + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. 在左側導覽窗格中，選擇 **Users (使用者)**。 1. 新增名為 `access-Nikhil-cen-eng` 的新使用者、連接名為 `access-assume-role` 的政策，並新增以下使用者標籤。 + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. 使用 [步驟 4：測試建立秘密](#tutorial_abac_step4) 和 [步驟 5：測試檢視秘密](#tutorial_abac_step5) 中的程序。在另一個瀏覽器視窗中測試 Nikhil 是否只能建立 **Centaur** 工程秘密，並且可以檢視所有工程秘密。 1. 在您以管理員身分登入的主要瀏覽器視窗中，選擇使用者 `access-Saanvi-uni-eng`。 1. 在 **Permissions (許可)** 標籤上，移除 **access-assume-role** 許可政策。 1. 新增下列名為 `access-assume-specific-roles` 的內嵌政策 。如需將內嵌政策新增至使用者的詳細資訊，請參閱 [為使用者或角色嵌入內嵌政策 (主控台)](access_policies_manage-attach-detach.md#embed-inline-policy-console)。 **ABAC 政策：僅擔任特定角色** 此政策允許 Saanvi 擔任 **Pegasus** 和 **Centaur** 專案的工程角色。您必須建立此自訂政策，因為 IAM 不支援多值標籤。您無法以 `access-project` = `peg` 和 `access-project` = `cen` 來標記 Saanvi 的使用者。此外， AWS 授權模型不能同時符合這兩個值。如需詳細資訊，請參閱[在 IAM 和 中標記的規則 AWS STS](id_tags.md#id_tags_rules)。您必須改為手動指定她可以擔任的兩個角色。 若要使用此政策，請將*斜體預留位置文字*取代為您的帳戶資訊。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/access-peg-engineering", "arn:aws:iam::111122223333:role/access-cen-engineering" ] } ] } ``` ------ 1. 使用 [步驟 4：測試建立秘密](#tutorial_abac_step4) 和 [步驟 5：測試檢視秘密](#tutorial_abac_step5) 中的程序。在另一個瀏覽器視窗中，確認 Saanvi 可以擔任這兩個角色。根據角色的標籤，檢查她是否只能為她的專案、團隊和成本中心建立秘密。同時確認她可以檢視工程團隊所擁有之任何秘密的詳細資訊，包括她剛建立的秘密。 ## 步驟 7：測試更新和刪除秘密 連接至角色的 `access-same-project-team` 政策允許員工更新和刪除任何以其專案、團隊和成本中心加上標籤的秘密。在 Secrets Manager 中測試您的角色，確認您的許可如預期般運作。 **測試更新和刪除含有與不含必要標籤的秘密** 1. 使用下列其中一個 IAM 使用者身分登入: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` + `access-Nikhil-cen-eng` 1. 切換至相符的角色： + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-peg-quality-assurance` + `access-cen-engineering` 如需在 中切換角色的詳細資訊 AWS 管理主控台，請參閱 [從使用者切換至 IAM 角色 (主控台)](id_roles_use_switch-role-console.md)。 1. 針對每個角色嘗試更新秘密描述，然後嘗試刪除下列秘密。如需詳細資訊，請參閱*AWS Secrets Manager 使用者指南*中的[修改秘密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html)以及[刪除與還原秘密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html)。 下表顯示每個角色的 ABAC 秘密更新和刪除行為。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 摘要 您現在已成功完成使用標籤進行以屬性為基礎的存取控制 (ABAC) 所需的所有步驟。您已學會如何定義標記策略。您已將該策略套用到主體和資源。您已建立並套用了實施 Secrets Manager 策略的政策。您也已了解當您新增專案和團隊成員時，ABAC 可以輕鬆擴展。因此，您可以使用測試角色登入 IAM 主控台，並體驗如何在 AWS中使用 ABAC 標籤。 **注意** 您已新增僅在特定條件下允許執行動作的政策。如果您將不同的政策套用至具有更廣泛許可的使用者或角色，則動作可能不會受限為需要標記。例如，如果您使用 `AdministratorAccess` AWS 受管政策為使用者提供完整的管理許可，則這些政策不會限制該存取。更多涉及多個政策時如何決定許可的詳細資訊，請參閱 [AWS 強制執行程式碼邏輯如何評估允許或拒絕存取的請求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。 ## 相關資源 如需相關資訊，請參閱下列資源： + [使用 ABAC 授權根據屬性定義許可](introduction_attribute-based-access-control.md) + [AWS 全域條件內容索引鍵](reference_policies_condition-keys.md) + [建立角色以將許可授予 IAM 使用者](id_roles_create_for-user.md) + [AWS Identity and Access Management 資源的標籤](id_tags.md) + [使用標籤控制對 AWS 資源的存取](access_tags.md) + [從使用者切換至 IAM 角色 (主控台)](id_roles_use_switch-role-console.md) + [IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記](tutorial_abac-saml.md) 若要了解如何監控帳戶中的標籤，請參閱[使用無伺服器工作流程和 Amazon CloudWatch Events 監控 AWS 資源上的標籤變更](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/)。 # IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記 屬性為基礎的存取控制 (ABAC) 是一種授權策略，可根據屬性來定義許可。在 中 AWS，這些屬性稱為標籤。您可以將標籤連接至 IAM 資源，包括 IAM 實體 （使用者或角色） 和 AWS 資源。當實體用於向 提出請求時 AWS，它們會成為委託人，而這些委託人包含標籤。 您也可以在擔任角色或與使用者聯合身分時傳遞[工作階段標籤](id_session-tags.md)。然後您可以定義使用標籤條件索引鍵的政策，以根據主體的標籤來授與許可。當您使用標籤來控制對 AWS 資源的存取 ，您就是允許團隊和資源能夠用更少的 AWS 政策變更來增長。ABAC 政策比傳統 AWS 政策更靈活，需要您列出每個個別資源。如需 ABAC 及其優於傳統政策的詳細資訊，請參閱 [使用 ABAC 授權根據屬性定義許可](introduction_attribute-based-access-control.md)。 如果您的公司使用 SAML 類型的身分提供者 (IdP) 來管理企業使用者身分，您可以將 SAML 屬性用於 AWS中精細的存取控制。屬性可包含成本中心識別符、使用者電子郵件地址、部門分類和專案指派。當您將這些屬性做為工作階段標籤傳遞時，您接著便可以根據這些工作階段標籤來控制對 AWS 的存取。 如要將 SAML 屬性傳遞到您的工作階段主體來完成 [ABAC 教學](tutorial_attribute-based-access-control.md)，請使用本主題中包含的變更，完成 [IAM 教學課程：定義根據標籤存取 AWS 資源的許可](tutorial_attribute-based-access-control.md) 中的任務。 ## 先決條件 如要執行步驟以使用 ABAC 的 SAML 工作階段標籤，您必須已具備以下項目： + 對 SAML 類型 IdP 的存取，可讓您使用特定屬性建立測試使用者。 + 以具有管理許可的使用者身分登入的能力。 + 體驗在 AWS 管理主控台中建立並編輯 IAM 使用者、角色和政策。不過，如果您需要記住 IAM 管理程序的協助，ABAC 教學課程提供的連結可讓您檢視逐步說明。 + 在 IAM 中體驗設定 SAML 類型的 IdP。如要檢視更多詳細資訊及更詳細 IAM 文件的連結，請參閱 [使用 AssumeRoleWithSAML 傳遞工作階段標籤](id_session-tags.md#id_session-tags_adding-assume-role-saml)。 ## 步驟 1：建立測試使用者 請跳過 [步驟 1：建立測試使用者](tutorial_attribute-based-access-control.md#tutorial_abac_step1) 中的說明。由於您的身分是定義在您的供應商中，您不需要為您的員工新增 IAM 使用者。 ## 步驟 2：建立 ABAC 政策 遵循 [步驟 2：建立 ABAC 政策](tutorial_attribute-based-access-control.md#tutorial_abac_step2) 中的說明，在 IAM 中建立指定受管政策。 ## 步驟 3：建立和設定 SAML 角色 當您使用 SAML 的 ABAC 教學課程時，您必須執行其他步驟來建立角色、設定 SAML IdP，以及啟用 AWS 管理主控台 存取。如需詳細資訊，請參閱[步驟 3：建立角色](tutorial_attribute-based-access-control.md#tutorial_abac_step3)。 ### 步驟 3A：建立 SAML 角色 建立單一角色，該角色信任您的 SAML 身分提供者，以及您在步驟 1 中建立的 `test-session-tags` 使用者。ABAC 教學會使用具備不同角色標籤的不同角色。因為您是從您的 SAML IdP 傳遞工作階段標籤，您只需要一個角色。若要了解如何建立 SAML 類型的角色，請參閱 [為 SAML 2.0 聯合身分建立角色 (主控台)](id_roles_create_for-idp_saml.md)。 將角色命名為 `access-session-tags`。將 `access-same-project-team` 許可政策連接到角色。編輯角色信任政策，以使用以下政策。如需如何編輯角色信任關係的詳細說明，請參閱 [更新角色信任政策](id_roles_update-role-trust-policy.md)。 以下角色信任政策會允許您的 SAML 身分提供者和 `test-session-tags` 使用者擔任角色。當 SAML 身分提供者和該使用者擔任角色時，必須傳遞三個指定工作階段標籤。`sts:TagSession` 動作是允許傳遞工作階段標籤的必要項目。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] } ``` ------ `AllowSamlIdentityAssumeRole` 陳述式允許工程和品質保證團隊的成員在 AWS 從 Example Corporation IdP 聯合到 時擔任此角色。`ExampleCorpProvider` SAML 供應商是在 IAM 中定義。管理員已設定 SAML 聲明，傳遞三個必要的工作階段標籤。聲明可以傳遞其他標籤，但必須要有這三個標籤。身分的屬性可針對 `cost-center` 和 `access-project` 標籤具備任何值。但是，`access-team` 屬性值必須與 `eng` 或 `qas` 相符，才能指出身分是位於 Engineering 或 Quality Assurance 團隊。 ### 步驟 3B：設定 SAML IdP 設定您的 SAML IdP，將 `cost-center`、`access-project` 和 `access-team` 屬性做為工作階段標籤傳遞。如需更多詳細資訊，請參閱 [使用 AssumeRoleWithSAML 傳遞工作階段標籤](id_session-tags.md#id_session-tags_adding-assume-role-saml)。 若要將這些屬性做為工作階段標籤傳遞，請在您的 SAML 聲明中包含下列元素。 ``` 987654 peg eng ``` ### 步驟 3C：啟用主控台存取 為您的聯合 SAML 使用者啟用主控台存取。如需更多詳細資訊，請參閱 [啟用 SAML 2.0 聯合主體來存取 AWS 管理主控台](id_roles_providers_enable-console-saml.md)。 ## 步驟 4：測試建立秘密 AWS 管理主控台 使用 `access-session-tags`角色聯合到 。如需詳細資訊，請參閱[啟用 SAML 2.0 聯合主體來存取 AWS 管理主控台](id_roles_providers_enable-console-saml.md)。然後遵循 [步驟 4：測試建立秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step4) 中的說明來建立秘密。搭配屬性使用不同的 SAML 身分，來匹配 ABAC 教學中指出的標籤。如需更多詳細資訊，請參閱 [步驟 4：測試建立秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step4)。 ## 步驟 5：測試檢視秘密 遵循 [步驟 5：測試檢視秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step5) 中的說明來檢視您在上一個步驟中建立的秘密。搭配屬性使用不同的 SAML 身分，來匹配 ABAC 教學中指出的標籤。 ## 步驟 6：測試可擴展性 遵循 [步驟 6：測試可擴展性](tutorial_attribute-based-access-control.md#tutorial_abac_step6) 中的說明來測試可擴展性。請使用下列屬性在您的 SAML 類型 IdP 中新增新的身分，來執行此作業： + `cost-center = 101010` + `access-project = cen` + `access-team = eng` ## 步驟 7：測試更新和刪除秘密 遵循 [步驟 7：測試更新和刪除秘密](tutorial_attribute-based-access-control.md#tutorial_abac_step7) 中的說明來更新和刪除秘密。搭配屬性使用不同的 SAML 身分，來匹配 ABAC 教學中指出的標籤。 **重要** 刪除您建立的所有秘密來避免產生費用。如需關於 Secrets Manager 定價的詳細資訊，請參閱 [AWS Secrets Manager 定價](https://aws.amazon.com/secrets-manager/pricing/)。 ## 摘要 您現在已成功完成使用 SAML 工作階段標籤和資源標籤進行許可管理必要的所有步驟。 **注意** 您已新增僅在特定條件下允許執行動作的政策。如果您將不同的政策套用至具有更廣泛許可的使用者或角色，則動作可能不會受限為需要標記。例如，如果您使用 `AdministratorAccess` AWS 受管政策為使用者提供完整的管理許可，則這些政策不會限制該存取。更多涉及多個政策時如何決定許可的詳細資訊，請參閱 [AWS 強制執行程式碼邏輯如何評估允許或拒絕存取的請求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。