IAM 教學課程：根據標籤定義存取 AWS 資源的許可 - AWS Identity and Access Management
教學課程概觀必要條件步驟 1：建立測試使用者步驟 2：建立 ABAC 政策步驟 3：建立角色步驟 4：測試建立秘密步驟 5：測試檢視秘密步驟 6：測試可擴展性步驟 7：測試更新和刪除秘密Summary相關資源

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

IAM 教學課程：根據標籤定義存取 AWS 資源的許可

屬性為基礎的存取控制 (ABAC) 是一種授權策略，可根據屬性來定義許可。在 AWS 中，這些屬性稱為標籤。您可以將標籤連接到 IAM 資源，包括 IAM 實體 (使用者或角色) 和 AWS 資源。您可以定義使用標籤條件金鑰的政策，以根據主體的標籤來授與許可。當您使用標籤來控制對 AWS 資源的存取 ，您就是允許團隊和資源能夠用更少的 AWS 政策變更來增長。ABAC 政策的靈活性比傳統的 AWS 政策更佳，因為後者會要求您列出每個個別資源。如需 ABAC 及其優於傳統政策的詳細資訊，請參閱 ABAC 是做什麼用的 AWS？。

注意

您必須為每個工作階段標籤傳遞單一值。AWS Security Token Service 不支援多值工作階段標籤。

主題

教學課程概觀

本教學說明如何建立和測試政策，以允許具有主體標籤的 IAM 角色存取具有相符標籤的資源。當主體向 AWS 發出請求時，會根據主體和資源標籤是否相符來授與其許可。此策略允許個人僅對其任務所需的 AWS 資源進行檢視或編輯。

案例

假設您是 Example Corporation 這間大型公司的首席開發人員，也是經驗豐富的 IAM 管理員。您很熟悉如何建立及管理 IAM 使用者、角色和政策。您想要確保您的開發工程師和品質保證團隊成員可以存取所需資源。您也需要可隨著公司成長而擴展的策略。

您可以選擇使用 AWS 資源標籤和 IAM 角色主體標籤，來針對支援 ABAC 的服務實作 ABAC 策略，從 AWS Secrets Manager 開始。若要了解哪些服務支援以標籤為基礎的授權，請參閱 AWS 與 IAM 搭配使用的服務。若要了解您可以在政策中使用哪些標籤條件索引鍵與每個服務的動作和資源，請參閱適用於 AWS 服務的動作、資源和條件索引鍵。您可以設定您的 SAML 類型或 Web 身分提供者，將工作階段標籤傳遞至 AWS。當您的員工聯合進入 AWS 時，其屬性會套用到員工在 AWS 中所產生的主體。您接著可以使用 ABAC 來根據這些屬性允許或拒絕許可。若要了解搭配 SAML 聯合身分使用工作階段標籤與本教學的不同，請參閱 IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記。

您的工程和品質保證團隊成員負責 Pegasus 或 Unicorn 專案。您可以選擇下列 3 個字元的專案和團隊標籤值：

  • access-project = peg 適用於 Pegasus 專案

  • access-project = uni 適用於 Unicorn 專案

  • access-team = eng 適用於工程團隊

  • access-team = qas 適用於品質保證團隊

此外，您可以選擇要求 cost-center 成本分配標籤以啟用自訂 AWS 帳單報表。如需詳細資訊，請參閱 AWS Billing and Cost Management 使用者指南中的使用成本分配標籤。

重要決策摘要

  • 員工使用 IAM 使用者憑證登入，然後擔任其團隊和專案的 IAM 角色。如果您的公司有專屬身分系統，您可以設定聯合以允許員工在沒有 IAM 使用者的情況下擔任角色。如需更多詳細資訊，請參閱 IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記。

  • 相同的政策會連接至所有角色。動作會根據標籤而受允許或拒絕。

  • 員工可以建立新的資源，但僅限於將相同的標籤連接至套用到其角色的資源時。這可確保員工在建立資源之後能夠檢視資源。管理員不再需要使用新資源的 ARN 來更新政策。

  • 員工可以讀取其團隊所擁有的資源，不論專案為何。

  • 員工可以更新及刪除自己團隊和專案所擁有的資源。

  • IAM 管理員可以新增新專案的角色。他們可以建立並標記新的 IAM 使用者，以允許存取適當的角色。管理員不需要編輯政策來支援新的專案或團隊成員。

在此教學中，您將為每個資源加上標籤、為您的專案角色加上標籤並將政策新增至角色，以允許前述的行為。產生的政策允許角色 Create、Read、Update 和 Delete 存取以相同專案和團隊標籤所標記的資源。政策也允許跨專案 Read 存取以相同團隊標記的資源。

ABAC 教學許可設計

必要條件

若要執行此教學課程中的步驟，您必須具備以下內容：

  • 您可以用來以具有管理許可之使用者身分登入的 AWS 帳戶。

  • 您的 12 位數帳戶 ID，用於在步驟 3 中建立角色。

    若要使用 AWS Management Console 尋找您的 AWS 帳戶 ID 號碼，請在右上角的導覽列選擇 Support (支援)，接著選擇 Support Center (支援中心)。帳戶號碼 (ID) 會顯示在左側導覽窗格。

  • 體驗在 AWS Management Console 中建立並編輯 IAM 使用者、角色和政策。不過，如果您需要記住 IAM 管理程序的協助，本教學課程會提供可讓您檢視 step-by-step 指示的連結。

步驟 1：建立測試使用者

針對測試，請建立四個 IAM 使用者，並授與其許可擔任具有相同標籤的角色。這可讓您更輕鬆地新增更多使用者到您的團隊。當您標記使用者時，使用者會自動取得擔任正確角色的存取權。如果使用者只在一個專案和團隊中工作，則您不必將使用者新增至角色的信任政策。

  1. 建立下列名為 access-assume-role 的客戶受管政策。如需如何建立 JSON 政策的詳細資訊，請參閱 建立 IAM 政策。

    ABAC 政策：擔任任何 ABAC 角色，但僅限使用者和角色標籤相符時

    下列政策允許使用者擔任您帳戶中名稱字首為 access- 的任何角色。角色也必須以與使用者相同的專案、團隊和成本中心標籤來標記。

    若要使用此政策，請將斜體預留位置文字取代為您的帳戶資訊。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::account-ID-without-hyphens: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 使用者群組 及 在 IAM 使用者群組中新增和移除使用者。

  2. 建立下列 IAM 使用者、連接 access-assume-role 許可政策。務必選取為使用者提供 AWS Management Console 的存取權限，然後新增下列標籤。如需建立和標記新使用者的詳細資訊，請參閱 建立 IAM 使用者 (主控台)。

    ABAC 使用者
    使用者名稱 使用者標籤索引鍵 使用者標籤值

    access-Arnav-peg-eng

    access-project

    access-team

    cost-center

    peg

    eng

    987654

    access-Mary-peg-qas

    access-project

    access-team

    cost-center

    peg

    qas

    987654

    access-Saanvi-uni-eng

    access-project

    access-team

    cost-center

    uni

    eng

    123456

    access-Carlos-uni-qas

    access-project

    access-team

    cost-center

    uni

    qas

    123456

步驟 2：建立 ABAC 政策

建立下列名為 access-same-project-team 的政策。您會在後續步驟將此政策新增至角色。如需如何建立 JSON 政策的詳細資訊，請參閱 建立 IAM 政策。

如需您可以針對本教學進行調整的其他政策，請參閱下列頁面：

ABAC 政策：僅在主體與資源標籤相符時，才存取 Secrets Manager 資源

下列政策允許主體建立、讀取、編輯及刪除資源，但僅限資源受標記為與主體相同的鍵值對時。當主體建立資源時，必須新增 access-project、access-team、和 cost-center 標籤，其值符合主體的標籤。此政策也允許新增選用的 Name 或 OwnedBy 標籤。

{
 "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 的動作、資源和條件索引鍵。該頁面顯示對 Secret (秘密) 資源類型執行的動作支援 secretsmanager:ResourceTag/tag-key 條件索引鍵。部分 Secrets Manager 動作不支援該資源類型，包括 GetRandomPassword 和 ListSecrets。您必須建立額外的陳述式以允許這些動作。

    • 如果請求中傳遞的每個標籤鍵都包含在指定清單中，則第二個條件區塊會傳回 true。此動作是使用 ForAllValues 搭配 StringEquals 條件運算子來完成。如果未傳遞金鑰或金鑰集的子集，則條件會傳回 true。這允許了不允許在請求中傳遞標籤的 Get* 操作。如果申請者包含了不在清單中的標籤鍵，則條件會傳回 false。在請求中傳遞的每個標籤鍵，都必須符合此清單的成員。如需詳細資訊，請參閱 多值內容索引鍵。

    • 如果請求支援傳遞標籤 (如果這三個標籤都存在)，且符合主體標籤值，則第三個條件區塊會傳回 true。如果請求不支援傳遞標籤，此區塊也會傳回 true。這要歸功於條件運算子中的 ...IfExists。如果在支援該標籤的動作期間沒有傳遞任何標籤，或標籤鍵和值不相符，則區塊會傳回 false。

  • AllResourcesSecretsManagerNoTags 陳述式允許第一個陳述式不允許的 GetRandomPassword 和 ListSecrets 動作。

  • 如果主體所標記的存取團隊標籤與資源相同，則 ReadSecretsManagerSameTeam 陳述式允許唯讀操作。無論專案或成本中心標籤為何，都允許此操作。

  • DenyUntagSecretsManagerReservedTags 陳述式拒絕從 Secrets Manager 移除鍵開頭為 "access-" 之標籤的請求。這些標籤用於控制對資源的存取，因此移除標籤可能會移除許可。

  • DenyPermissionsManagement 陳述式拒絕建立、編輯或刪除 Secrets Manager 以資源為基礎的政策的存取。這些政策可用來變更秘密的許可。

重要

此政策使用策略來允許服務的所有動作，但會明確拒絕更改許可的動作。拒絕動作會覆寫任何其他允許主體執行該動作的政策。這可能會產生意外的結果。根據最佳實務，只有在該動作無論何種情況都不應允許的情況下，才使用明確拒絕。否則，請允許包含個別動作的清單，且將不需要的動作預設拒絕。

步驟 3：建立角色

建立下列 IAM 角色，並連接您在先前步驟中建立的 access-same-project-team 政策。如需建立 IAM 角色的詳細資訊，請參閱 建立角色以委派許可給 IAM 使用者。如果您選擇使用聯合，而非 IAM 使用者和角色，請參閱 IAM 教學課程：針對 ABAC 使用 SAML 工作階段標記。

ABAC 角色
任務職能 角色名稱 角色標籤 角色描述

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/。

  2. 嘗試切換到 access-uni-engineering 角色。

    此操作會失敗，因為 access-project 和 cost-center 標籤值與 access-Arnav-peg-eng 使用者和 access-uni-engineering 角色不相符。

    如需有關在 AWS Management Console 中切換角色的詳細資訊，請參閱 切換到角色 (主控台)

  3. 切換到 access-peg-engineering 角色。

  4. 使用下列資訊存放新的秘密。若要了解如何存放秘密，請參閱 AWS Secrets Manager 使用者指南中的建立基本秘密。

    重要

    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。

    2. 針對 Secret name (秘密名稱) 欄位輸入 test-access-peg-eng。

    3. 從下表新增不同的標籤組合，並檢視預期的行為。

    4. 選擇 Store (存放) 以嘗試建立秘密。在儲存失敗時，返回先前的 Secrets Manager 主控台頁面，並使用下表中的下一個標籤集。最後一個標籤集會受到允許，且將成功建立秘密。

    test-access-peg-eng 角色的 ABAC 標籤組合
    access-project 標籤值 access-team 標籤值 cost-center 標籤值 其他標籤 預期行為
    (無) (無) (無) (無) 已拒絕，因為 access-project 標籤值不符合角色的值 peg。
    uni eng 987654 (無) 已拒絕，因為 access-project 標籤值不符合角色的值 peg。
    peg qas 987654 (無) 已拒絕，因為 access-team 標籤值不符合角色的值 eng。
    peg eng 123456 (無) 已拒絕，因為 cost-center 標籤值不符合角色的值 987654。
    peg eng 987654 owner = Jane 已拒絕，因為政策不允許額外的標籤 owner，即使所有三個必要標籤都存在且其值符合角色的值。
    peg eng 987654 Name = Jane 已允許，因為三個必要標籤都存在，且其值符合角色的值。您也可以包含選用的 Name 標籤。

  5. 登出並針對每個下列角色和標籤值來重複此程序的前三個步驟。在此程序的第四個步驟中，測試任何遺漏的標籤、選用標籤、不允許的標籤，和您選擇的無效標籤值。然後，使用必要標籤來建立具有下列標籤和名稱的秘密。

    ABAC 角色和標籤
    使用者名稱 角色名稱 秘密名稱 秘密標籤

    access-Mary-peg-qas

    access-peg-quality-assurance

    test-access-peg-qas

    access-project = peg

    access-team = qas

    cost-center = 987654

    access-Saanvi-uni-eng

    access-uni-engineering

    		 test-access-uni-eng

    access-project = uni

    access-team = eng

    cost-center = 123456

    access-Carlos-uni-qas

    access-uni-quality-assurance

    test-access-uni-qas

    access-project = uni

    access-team = qas

    cost-center = 123456

步驟 5：測試檢視秘密

您連接到每個角色的政策允許員工檢視以其團隊名稱標記的任何秘密，不論他們的專案為何。在 Secrets Manager 中測試您的角色，確認您的許可如預期般運作。

測試檢視包含和不含必要標籤的秘密

  1. 使用下列其中一個 IAM 使用者身分登入:

    • access-Arnav-peg-eng

    • access-Mary-peg-qas

    • access-Saanvi-uni-eng

    • access-Carlos-uni-qas

  2. 切換至相符的角色：

    • access-peg-engineering

    • access-peg-quality-assurance

    • access-uni-engineering

    • access-uni-quality-assurance

    如需在 AWS Management Console 中切換角色的詳細資訊，請參閱 切換到角色 (主控台)。

  3. 在左側的導覽窗格中，選擇選單圖示以展開選單，然後選擇 Secrets (秘密)。

  4. 無論您目前的角色為何，您應該都會看到資料表中的全部四個秘密。這是預期的結果，因為名為 access-same-project-team 的政策允許對所有資源執行 secretsmanager:ListSecrets 動作。

  5. 選擇其中一個秘密的名稱。

  6. 在秘密的詳細資訊頁面上，角色的標籤將決定您是否可以檢視頁面內容。將您的角色名稱與秘密名稱進行比較。如果這兩個名稱具有相同團隊名稱，則 access-team 標籤會相符。如果不相符，則會拒絕存取。

    每個角色的 ABAC 秘密檢視行為
    角色名稱 秘密名稱 預期行為
    access-peg-engineering test-access-peg-eng 允許
    test-access-peg-qas 已拒絕
    test-access-uni-eng 允許
    test-access-uni-qas 已拒絕
    access-peg-quality-assurance test-access-peg-eng 已拒絕
    test-access-peg-qas 允許
    test-access-uni-eng 已拒絕
    test-access-uni-qas 允許
    access-uni-engineering test-access-peg-eng 允許
    test-access-peg-qas 已拒絕
    test-access-uni-eng 允許
    test-access-uni-qas 已拒絕
    access-uni-quality-assurance test-access-peg-eng 已拒絕
    test-access-peg-qas 允許
    test-access-uni-eng 已拒絕
    test-access-uni-qas 允許

  7. 從頁面頂端的頁面導覽路徑中，選擇 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/ 的 IAM 主控台。

  2. 在左側的導覽窗格中，選擇 Roles (角色)，然後新增名為 access-cen-engineering 的 IAM 角色 將 access-same-project-team 許可政策連接至角色，並新增下列角色標籤：

    • access-project = cen

    • access-team = eng

    • cost-center = 101010

  3. 在左側導覽窗格中，選擇 Users (使用者)。

  4. 新增名為 access-Nikhil-cen-eng 的新使用者、連接名為 access-assume-role 的政策，並新增以下使用者標籤。

    • access-project = cen

    • access-team = eng

    • cost-center = 101010

  5. 使用 步驟 4：測試建立秘密 和 步驟 5：測試檢視秘密 中的程序。在另一個瀏覽器視窗中測試 Nikhil 是否只能建立 Centaur 工程秘密，並且可以檢視所有工程秘密。

  6. 在您以管理員身分登入的主要瀏覽器視窗中，選擇使用者 access-Saanvi-uni-eng。

  7. 在 [權限] 索引標籤上，移除access-assume-role權限原則。

  8. 新增下列名為 access-assume-specific-roles 的內嵌政策 。如需將內嵌政策新增至使用者的詳細資訊，請參閱 為使用者或角色嵌入內嵌政策 (主控台)。

    ABAC 政策：僅擔任特定角色

    此政策允許 Saanvi 擔任 Pegasus 和 Centaur 專案的工程角色。您必須建立此自訂政策，因為 IAM 不支援多值標籤。您無法以 access-project = peg 和 access-project = cen 來標記 Saanvi 的使用者。此外，AWS 授權模型無法同時符合這兩個值。如需更多詳細資訊，請參閱 IAM 和 AWS STS 中的標記規則。您必須改為手動指定她可以擔任的兩個角色。

    若要使用此政策，請將斜體預留位置文字取代為您的帳戶資訊。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeSpecificRoles",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
            ]
        }
    ]
}

  9. 使用 步驟 4：測試建立秘密 和 步驟 5：測試檢視秘密 中的程序。在另一個瀏覽器視窗中，確認 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

  2. 切換至相符的角色：

    • access-peg-engineering

    • access-peg-quality-assurance

    • access-uni-engineering

    • access-peg-quality-assurance

    • access-cen-engineering

    如需在 AWS Management Console 中切換角色的詳細資訊，請參閱 切換到角色 (主控台)。

  3. 針對每個角色嘗試更新秘密描述，然後嘗試刪除下列秘密。如需詳細資訊，請參閱AWS Secrets Manager 使用者指南中的修改秘密以及刪除與還原秘密。

    每個角色的 ABAC 秘密更新和刪除行為
    角色名稱 秘密名稱 預期行為

    access-peg-engineering

    test-access-peg-eng

    		 允許
    test-access-uni-eng 已拒絕
    test-access-uni-qas 已拒絕

    access-peg-quality-assurance

    		 test-access-peg-qas 允許
    test-access-uni-eng 已拒絕

    access-uni-engineering

    		 test-access-uni-eng 允許
    test-access-uni-qas 已拒絕

    access-peg-quality-assurance

    		 test-access-uni-qas 允許

Summary

您現在已成功完成使用標籤進行以屬性為基礎的存取控制 (ABAC) 所需的所有步驟。您已學會如何定義標記策略。您已將該策略套用到主體和資源。您已建立並套用了實施 Secrets Manager 策略的政策。您也已了解當您新增專案和團隊成員時，ABAC 可以輕鬆擴展。因此，您可以使用測試角色登入 IAM 主控台，並體驗如何在 AWS 中使用 ABAC 標籤。

注意

您已新增僅在特定條件下允許執行動作的政策。如果您將不同的政策套用至具有更廣泛許可的使用者或角色，則動作可能不會受限為需要標記。例如，如果您使用 AdministratorAccess AWS 受管政策授與使用者完整管理許可，則這些政策不會限制該存取。更多涉及多個政策時如何決定許可的詳細資訊，請參閱 決定是否允許或拒絕帳戶中的請求。

如需相關資訊，請參閱下列資源：

若要了解如何監控帳戶中的標籤，請參閱使用無伺服器工作流程和 Amazon E CloudWatch vents 監控AWS資源上的標籤變更。