本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # AWS JSON 政策元素： Principal 使用資源型 JSON 政策中的 `Principal` 元素來指定允許或拒絕存取資源的主體。 您可以在[資源型政策](access_policies_identity-vs-resource.md)中使用 `Principal` 元素。許多服務支援資源型政策，包括 IAM。IAM 資源型政策類型是角色信任政策。在 IAM 角色中，使用角色信任政策中的 `Principal` 元素來指定誰可擔任該角色。對於跨帳戶存取，您必須指定信任帳戶的 12 位數識別碼。若要了解在您信任區域 (受信任組織或帳戶) 外帳戶中的主體是否具有擔任您角色的許可，請參閱[什麼是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。 **注意** 在您建立角色後，您可以變更帳戶為「\$1」，以允許每個人擔任該角色。若執行此操作，我們強烈建議您限制誰可以透過其他方式存取角色，例如 `Condition` 元素會限制只能存取特定 IP 地址。切勿讓任何人都能存取您的角色！ 支援資源型政策的其他資源範例包括 Amazon S3 儲存貯體或 AWS KMS key。 您不能使用身分型政策中的 `Principal` 元素。身分型政策是指您連接到 IAM 身分 (使用者、群組或角色) 的許可政策。在這些情況中，主體由政策連接的身分隱含識別。 **Topics** + [如何指定主體](#Principal_specifying) + [AWS 帳戶 主體](#principal-accounts) + [IAM 角色主體](#principal-roles) + [角色工作階段主體](#principal-role-session) + [OIDC 聯合身分主體](#principal-federated-web-identity) + [SAML 聯合身分主體](#principal-saml) + [IAM 使用者主體](#principal-users) + [IAM Identity Center 主體](#principal-identity-users) + [AWS STS 聯合身分使用者主體](#sts-session-principals) + [AWS 服務主體](#principal-services) + [AWS 選擇加入區域中的服務主體](#principal-services-in-opt-in-regions) + [所有主體](#principal-anonymous) + [其他資訊](#Principal_more-info) ## 如何指定主體 您可以在資源型政策的 `Principal` 元素中指定主體，或在支援主體的條件金鑰中指定。 您可以在政策中指定以下任何主體： + AWS 帳戶 和根使用者 + IAM 角色 + 角色工作階段 + IAM 使用者 + 聯合身分使用者主體 + AWS 服務 + 所有主體 您無法將使用者群組識別為政策 (例如資源型政策) 中的主體，因為群組與許可 (而非驗證) 相關，並且主體是經過驗證的 IAM 實體。 您可以使用陣列在以下幾節中為每個主體類型指定一個以上的主體類型。陣列可以使用一個或多個值。當您在元素中指定多個主體時，便會授予每個主體許可。這是邏輯 `OR`，而不是邏輯 `AND`，因為您一次只會驗證為一位主體。如果包含多個值，請使用方括號 (`[` 和 `]`)，並以逗號分隔陣列的每個項目。下列範例政策會定義 123456789012 帳戶或 555555555555 帳戶的許可。 ``` "Principal" : { "AWS": [ "123456789012", "555555555555" ] } ``` **注意** 您不能使用萬用字元來符合部分主體名稱或 ARN。 ## AWS 帳戶 主體 您可以在資源型政策的 `Principal`元素或支援主體的條件索引鍵中指定 AWS 帳戶 識別符。這會委派帳戶的授權。當您允許存取其他帳戶時，該帳戶中的管理員必須接著授予該帳戶中身分 (IAM 使用者或角色) 的存取權。當您指定 時 AWS 帳戶，您可以使用帳戶 ARN (arn：aws：iam：：*account-ID*：root)，或由帳戶 ID 後面加上 `"AWS":`字首的縮短表單。 例如，指定帳戶 ID `123456789012`，您就可以使用以下其中一種方法來指定 `Principal` 元素中的帳戶： ``` "Principal": { "AWS": "arn:aws:iam::123456789012:root" } ``` ``` "Principal": { "AWS": "123456789012" } ``` 帳戶 ARN 和簡化帳戶 ID 的行為方式相同。兩者都會委派帳戶的許可。使用 `Principal` 元素中的帳戶 ARN 不會將許可限制為帳戶的根使用者。 **注意** 當您儲存包含簡化帳戶 ID 的資源型政策時，服務可能會將其轉換為主體 ARN。如此並不會變更政策的功能。 有些 AWS 服務支援指定帳戶委託人的其他選項。例如，Amazon S3 可讓您使用以下格式指定[正式使用者 ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId)： ``` "Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" } ``` 您也可以使用 陣列 AWS 帳戶，將多個 （或正式使用者 ID) 指定為委託人。例如，您可以使用全部三種方法在儲存貯體政策中指定主體。 ``` "Principal": { "AWS": [ "arn:aws:iam::123456789012:root", "999999999999" ], "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" } ``` ## IAM 角色主體 您可以在資源型政策的 `Principal` 元素中指定 IAM 角色主體 ARN，或在支援主體的條件金鑰中指定。IAM 角色是身分。在 IAM 中，身分是您可以指派許可的資源。角色信任另一個已驗證的身分來擔任該角色。這包括 AWS 中的主體或來自外部身分提供者 (IdP) 的使用者。當主體或身分擔任角色時，他們會收到具有擔任角色許可的暫時安全憑證。當他們使用這些工作階段登入資料在 中執行操作時 AWS，就會成為*角色工作階段主體*。 當您在資源型政策中指定角色主體時，主體的有效許可會受限於限制角色許可的任何政策類型。其中包括工作階段政策和許可界限。如需有關如何評估角色工作階段的有效許可的詳細資訊，請參閱 [政策評估邏輯](reference_policies_evaluation-logic.md)。 若要在 `Principal` 元素中指定角色 ARN，請使用以下格式： ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" } ``` **重要** 如果角色信任政策中 `Principal` 元素包含指向特定 IAM 角色的 ARN，則該 ARN 會在儲存政策時轉換為角色的唯一主體 ID。如果有人希望藉由刪除並重新建立角色來提升特權，這麼做可有助於減輕此類風險。您通常不會在主控台中看到此 ID，因為在顯示信任政策時，IAM 會反向轉換回角色 ARN。不過，如果您刪除角色，則關係會中斷。即使重新建立角色，您的政策都不再適用，因為新角色有不符合信任政策中所儲存的主體 ID 的新主體 ID。發生這種情況時，委託人 ID 會顯示在以資源為基礎的政策中，因為 AWS 無法再將其對應回有效的 ARN。結果是，如果您刪除並重新建立了信任政策的 `Principal` 元素所引用的角色，您必須編輯政策中的角色來以正確 ARN 替換主體 ID。當您儲存政策時，ARN 再次轉換為角色的新主體 ID。如需詳細資訊，請參閱[了解 AWS處理政策中已刪除的 IAM 角色](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies)。 或者，您可以指定角色主體作為資源型政策中的主體，或使用 `aws:PrincipalArn` 條件金鑰[建立廣泛許可政策](#principal-anonymous)。當您使用此索引鍵時，角色工作階段主體會根據擔任的角色 ARN 授予許可，而不是根據所產生之工作階段的 ARN 授予許可。由於 AWS 不會將條件金鑰 ARNs 轉換為 IDs，因此如果您刪除角色，然後使用相同名稱建立新角色，則授予角色 ARN 的許可會保留。在資源型政策的 `Principal` 元素中，使用 `aws:PrincipalArn` 條件金鑰及萬用字元 (\$1) 授予的許可，不受身分型政策類型 (例如許可界限或工作階段政策) 的限制，除非身分型政策包含明確拒絕。 ## 角色工作階段主體 您可以在資源型政策的 `Principal` 元素中指定角色工作階段，或在支援主體的條件金鑰中指定。當主體或身分擔任角色時，他們會收到具有擔任的角色許可的暫時安全憑證。當他們使用這些工作階段登入資料在 中執行操作時 AWS，就會成為*角色工作階段主體*。 您用於角色工作階段主體的格式取決於用來擔任角色 AWS STS 的操作。 **重要** AWS 建議您盡可能在政策中使用 [IAM 角色主體](#principal-roles)，而不是角色工作階段主體。視需要使用`Condition`陳述式和條件索引鍵進一步縮小存取範圍。 若要在 `Principal`元素中指定角色工作階段主體 ARN，請使用下列格式： ``` "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" } ``` 此外，系統管理員可以設計程序來控制如何發出角色工作階段。例如，他們可以為使用者提供一鍵式解決方案，以建立可預測的工作階段名稱。如果您的系統管理員執行這項操作，則可以在政策或條件金鑰中使用角色工作階段主體。否則，您可以在 `aws:PrincipalArn` 條件金鑰中將角色 ARN 指定為主體。將角色指定為主體的方式可以變更產生工作階段的有效許可。如需詳細資訊，請參閱[IAM 角色主體](#principal-roles)。 ## OIDC 聯合身分主體 OIDC 聯合委託人是使用 JSON Web 字符 (JWT) 從 OIDC 相容 IDP 呼叫 AWS STS `AssumeRoleWithWebIdentity` API 時所使用的委託人，也稱為 OpenID 提供者 (OP)，以請求臨時 AWS 憑證。OIDC 聯合委託人可以代表您 AWS 帳戶中的 OIDC IDP，或 4 個內建身分提供者：Login with Amazon、Facebook、 Google和 [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)。 從其 OIDC IDP 發出 JWT 的使用者、工作負載或系統可以使用 `AssumeRoleWithWebIdentity` JWT 呼叫 ，為設定為信任發出 JWT 的 OIDC IDP 的 IAM 角色請求臨時 AWS 安全登入資料。只要符合 [AWS STS列出的需求](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites)，JWT 可以是 ID 權杖、存取權杖或透過任何其他方法提供的 JWT 權杖。如需詳細資訊，請參閱[常見案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html)和[透過 OIDC 提供者請求憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity)。 在您的角色信任政策中使用此委託人類型，允許或拒絕`AssumeRoleWIthWebIdentity`使用 中存在的 OIDC IDP AWS 帳戶或四個內建 IDPs許可。若要在角色信任政策的 `Principal` 元素中指定 OIDC 聯合身分主體 ARN，請針對內建的 OIDC IDP，使用下列四種格式之一： ``` "Principal": { "Federated": "cognito-identity.amazonaws.com" } ``` ``` "Principal": { "Federated": "www.amazon.com" } ``` ``` "Principal": { "Federated": "graph.facebook.com" } ``` ``` "Principal": { "Federated": "accounts.google.com" } ``` 使用新增至帳戶的 OIDC 提供者 (例如 GitHub) 時，需要在角色的信任政策中指定提供者的 ARN。此組態可讓您撰寫 IAM 政策，專門控制透過自訂身分提供者進行驗證之使用者的存取權。 ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" } ``` 例如，如果 GitHub 是受信任的 Web 身分提供者，則角色信任政策的 `Principal` 元素中的 OIDC 角色工作階段 ARN 會使用下列格式： ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" } ``` 如需詳細資訊，請參閱 [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)。 角色信任政策以外的政策類型不支援 OIDC 聯合身分主體。 ## SAML 聯合身分主體 *SAML 聯合委託人*是呼叫 AWS STS `AssumeRoleWithSAML` API 以使用 SAML 聲明請求臨時 AWS 登入資料的委託人。您可以使用 SAML 身分提供者 (IdP) 登入，然後使用此操作擔任 IAM 角色。與 類似`AssumeRoleWithWebIdentity`， `AssumeRoleWithSAML` 不需要 AWS 登入資料進行身分驗證。反之，使用者會先向 SAML 身分提供者進行身分驗證，然後使用其 SAML 聲明進行 `AssumeRoleWithSAML` API 呼叫，或重新導向至 AWS 登入/SAML 頁面以登入 AWS 管理主控台。如需哪些主體可以使用此操作擔任角色的詳細資訊，請參閱 [比較 AWS STS 登入資料](id_credentials_sts-comparison.md)。 在角色信任政策中使用此主體類型，以根據受信任的 SAML 身分提供者允許或拒絕許可。若要在角色信任政策的 `Principal` 元素中指定 SAML 身分角色工作階段 ARN，請使用下列格式： ``` "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" } ``` ## IAM 使用者主體 您可以在資源型政策的 `Principal` 元素中指定 IAM 使用者，或在支援主體的條件金鑰中指定。 **注意** 在 `Principal` 元素中，[*Amazon Resource Name (ARN)*](reference_identifiers.md#identifiers-arns) 的使用者名稱部分區分大小寫。 ``` "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" } ``` ``` "Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:user/user-name-1", "arn:aws:iam::AWS-account-ID:user/user-name-2" ] } ``` 當您在 `Principal` 元素中指定使用者時，您無法使用萬用字元 (`*`) 來表示「所有使用者」。主體必須一律指定特定的使用者。 **重要** 如果角色信任政策中您的 `Principal` 元素包含指向特定 IAM 使用者的 ARN，則該 ARN 會在儲存政策時將 ARN 轉換為使用者的唯一主體 ID。如果有人希望藉由刪除並重新建立使用者來提升特權，這麼做可有助於減輕此類風險。您通常不會在主控台中看到此 ID，因為在顯示信任政策時還會反向轉換回使用者的 ARN。不過，如果您刪除使用者，則關係會中斷。即使重新建立使用者，政策都不再適用。這是因為新的使用者有新的主體 ID，其不符合儲存在信任政策中的 ID。發生這種情況時，委託人 ID 會顯示在以資源為基礎的政策中，因為 AWS 無法再將其對應回有效的 ARN。結果是，如果您刪除並重新建立了信任政策的 `Principal` 元素所引用的使用者，您必須編輯角色來以正確 ARN 替換不正確的主體 ID。當您儲存政策時，IAM 再次將 ARN 轉換為使用者的新主體 ID。 ## IAM Identity Center 主體 在 IAM Identity Center 中，資源型政策中的主體必須定義為 AWS 帳戶 主體。若要指定存取權，請參照條件區塊中許可集合的角色 ARN。如需詳細資訊，請參閱《IAM Identity Center 使用者指南》**中的[資源政策、Amazon EKS 和 AWS KMS中的參考許可集合](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html)。 ## AWS STS 聯合身分使用者主體 您可以在資源型政策的 `Principal` 元素中指定*聯合身分使用者工作階段*，或在支援主體的條件金鑰中指定。 **重要** AWS 建議您限制使用 AWS STS 聯合身分使用者工作階段。改為使用 [IAM 角色](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)。 聯合身分使用者主體是透過使用長期 AWS STS IAM 憑證呼叫 `GetFederationToken`的操作建立。聯合身分使用者許可是呼叫 `GetFederationToken` 的主體與作為參數傳遞至 `GetFederationToken` API 的工作階段政策之間的交集。 在 中 AWS，IAM 使用者或 AWS 帳戶根使用者 可以使用長期存取金鑰進行身分驗證。如需哪些主體可以使用此操作聯合身分的詳細資訊，請參閱 [比較 AWS STS 登入資料](id_credentials_sts-comparison.md)。 + **IAM 聯合身分使用者** – IAM 使用者使用 `GetFederationToken` 操作進行聯合，該操作會產生此 IAM 使用者的聯合身分使用者工作階段。 + **聯合身分根使用者** – 根使用者使用 `GetFederationToken` 操作進行聯合，該操作會產生此根使用者的聯合身分使用者工作階段。 當 IAM 使用者或根使用者請求 AWS STS 使用此操作的臨時登入資料時，他們會開始臨時聯合身分使用者工作階段。此工作階段的 ARN 是以聯合的原始身分為基礎。 若要在 `Principal` 元素中指定聯合身分使用者工作階段 ARN，請使用以下格式： ``` "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" } ``` ## AWS 服務主體 您可以在資源型政策的 `Principal`元素或支援主體的條件金鑰中指定 AWS 服務。*服務主體*是服務的識別碼。 服務可擔任的 IAM 角色 AWS 稱為*[服務角色](id_roles.md#iam-term-service-role)*。服務角色必須包含信任政策。*信任政策*是連接到角色的資源型政策，這些政策定義可擔任該角色的主體。有些服務角色具有已預先定義的信任政策。不過，在某些情況下，您必須在信任政策中指定服務主體。IAM 政策中的服務主體不能為 `"Service": "*"`。 **重要** 服務主體的識別碼包含服務名稱，而且通常採用以下格式： `service-name.amazonaws.com` 服務主體是由服務定義。您可以藉由開啟 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)，檢查**服務連結角色**資料欄中是否為**是**，並開啟**是**連結，以檢視該服務的服務連結角色文件，從而尋找某些服務的服務主體。尋找該服務的 **Service-Linked Role Permissions** (服務連結角色許可) 區段，以檢視服務主體。 以下範例顯示一個可以連接到服務角色的政策。政策啟用兩種服務，分別為 Amazon ECS 和 Elastic Load Balancing，來擔任角色。然後服務可以執行指派給角色的許可政策所授予的任何任務 (不顯示)。若要指定多個服務主體，不用指定兩個 `Service` 元素；您可以只使用一個該元素。實際上，您可以將一組多個服務主體作為單一 `Service` 元素的值。 ``` "Principal": { "Service": [ "ecs.amazonaws.com", "elasticloadbalancing.amazonaws.com" ] } ``` ## AWS 選擇加入區域中的服務主體 您可以在數個 AWS 區域以及您必須選擇加入的部分區域中啟動資源。如需您必須選擇加入的區域完整清單，請參閱 *AWS 一般參考*指南中的[管理 AWS 區域](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)。 當選擇加入區域中 AWS 的服務在相同區域內提出請求時，服務主體名稱格式會識別為其服務主體名稱的非區域化版本： `service-name.amazonaws.com` 當選擇加入區域中 AWS 的服務向另一個區域提出跨區域請求時，服務主體名稱格式會識別為其服務主體名稱的區域化版本： `service-name.{region}.amazonaws.com` 例如，您有一個位於區域 `ap-southeast-1` 中的 Amazon SNS 主題，而 Amazon S3 儲存貯體位於選擇加入區域 `ap-east-1`。您想要設定 S3 儲存貯體通知，將訊息發佈到 SNS 主題。若要允許 S3 服務將訊息張貼到 SNS 主題，您必須透過該主題以資源為基礎的存取政策授與 S3 服務主體 `sns:Publish` 權限。 如果您指定 S3 服務主體的非區域化版本 `s3.amazonaws.com`，則在存取政策主題中，從儲存貯體到主題的 `sns:Publish` 要求將會失敗。下列範例會在 SNS 主題存取政策的 `Principal` 政策元素中指定非區域化 S3 服務主體。 ``` "Principal": { "Service": "s3.amazonaws.com" } ``` 由於儲存貯體位於選擇加入的區域，而且要求是在同一個區域之外發出，因此 S3 服務主體會顯示為區域化服務主體名稱 `s3.ap-east-1.amazonaws.com`。當選擇加入區域中的服務向另一個區域提出請求時，您必須使用區域化 AWS 服務主體名稱。指定區域化服務主體名稱後，如果儲存貯體向位於另一個區域的 SNS 主題發出 `sns:Publish` 要求，則該要求將會成功。下列範例會在 SNS 主題存取政策的 `Principal` 政策元素中指定區域化 S3 服務主體。 ``` "Principal": { "Service": "s3.ap-east-1.amazonaws.com" } ``` 只有在您指定區域化服務主體名稱時，從選擇加入區域至另一個區域的跨區域要求的資源政策或服務主體型允許清單才會成功。 **注意** 對於 IAM 角色信任政策，建議使用非區域化服務主體名稱。IAM 資源是全球性的，因此可以在任何區域中使用相同的角色。 ## 所有主體 可使用萬用字元 (\$1) 在資源型政策的 `Principal` 元素中或支援主體的條件金鑰中指定所有主體。[資源型政策](access_policies.md#policies_resource-based) *授予*許可和[條件金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)用於限制政策陳述式的條件。 **重要** 強烈建議您不要在資源型政策的 `Principal` 中搭配使用萬用字元 (\$1) 與 `Allow` 效果，除非您打算授予公開或匿名存取。否則，請指定預定的主體、服務或 `Principal` 元素中的 AWS 帳戶，然後進一步限制 `Condition` 元素中的存取。IAM 角色信任政策尤其如此，因為它們允許其他主體成為您帳戶中的主體。 對於資源型政策，搭配使用萬用字元 (\$1) 與 `Allow` 效果可授權存取所有使用者，包括匿名使用者 (公開存取)。對於您帳戶中的 IAM 使用者和角色主體，不需要其他許可。對於其他帳戶中的主體，他們也必須在其帳戶中具有身分型許可，以允許他們存取您的資源。這稱為[跨帳戶存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)。 對於匿名使用者，下列元素相同： ``` "Principal": "*" ``` ``` "Principal" : { "AWS" : "*" } ``` 您不能使用萬用字元來比對部分主體名稱或 ARN。 以下範例顯示可用於明確拒絕所有主體的資源型政策 (而不是 [AWS JSON 政策元素： NotPrincipal](reference_policies_elements_notprincipal.md))，但在 `Condition` 元素中指定的主體*除外*。此政策應[新增至 Amazon S3 儲存貯體](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html)。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny", "Effect": "Deny", "Action": "s3:*", "Principal": "*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*", "arn:aws:s3:::amzn-s3-demo-bucket" ], "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name" } } } ] } ``` ------ ## 其他資訊 如需詳細資訊，請參閱下列內容： + *Amazon Simple Storage Service 使用者指南*中的[儲存貯體政策範例](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) + *Amazon Simple Notification Service 開發人員指南*中的 [Amazon SNS 政策範例](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS) + *Amazon Simple Queue Service 開發人員指南*中的 [Amazon SQS 政策範例](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) + *AWS Key Management Service 開發人員指南*中的[索引鍵政策](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) + *AWS 一般參考* 中的[帳戶識別符](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) + [OIDC 聯合身分](id_roles_providers_oidc.md)