本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# AWS STS 使用 VPC 端點政策控制對 的存取
當您為 AWS Security Token Service (AWS STS) 建立介面 VPC 端點時，您可以連接端點政策。政策控制哪些主體可以使用端點，以及他們可以執行哪些 AWS STS 動作。如果您未連接政策，端點會使用預設政策，允許不受限制地存取所有委託人的所有 AWS STS 動作。
VPC 端點政策不會自行授予許可。它們可做為與其他政策搭配使用的額外界限。端點政策和發起人的適用政策都必須允許請求成功。
如需 VPC 端點政策的詳細資訊，請參閱《*Amazon* [VPC 使用者指南》中的使用端點政策控制對 VPC 端點的存取](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)。
**Topics**
+ [預設 VPC 端點政策](#reference_sts_vpc_endpoint_policies_default)
+ [AWS STS VPC 端點政策的重要考量事項](#reference_sts_vpc_endpoint_policies_considerations)
+ [AWS STS VPC 端點政策可用的條件索引鍵](#reference_sts_vpc_endpoint_policies_condition_keys)
+ [範例：允許組織的所有 AWS STS 動作](#reference_sts_vpc_endpoint_policies_example_org)
+ [範例：允許特定帳戶的所有 AWS STS 動作](#reference_sts_vpc_endpoint_policies_example_accounts)
+ [範例：限制為特定 AWS STS 動作](#reference_sts_vpc_endpoint_policies_example_actions)
+ [範例：拒絕非組織存取，同時允許聯合](#reference_sts_vpc_endpoint_policies_example_deny)
## 預設 VPC 端點政策
如果您在建立端點時未連接自訂政策， 會 AWS 連接下列預設政策。此政策允許無限制存取端點。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}
```
若要限制對端點的存取，請連接自訂端點政策。
## AWS STS VPC 端點政策的重要考量事項
AWS STS 處理來自兩種基本上不同類型來電者的請求。您的 VPC 端點政策必須考慮這兩種類型，以避免意外封鎖合法請求。
**已驗證的 AWS 主體**
使用 AWS Signature 第 4 版 (SigV4) 簽署請求的 IAM 使用者和 IAM 角色。這些呼叫者在請求內容中具有標準條件索引鍵`aws:PrincipalOrgID`，例如 `aws:PrincipalAccount`、 和 `aws:PrincipalArn` 。
**聯合發起人**
呼叫 `AssumeRoleWithSAML`或 的 SAML 2.0 和 OpenID Connect (OIDC) 主體`AssumeRoleWithWebIdentity`。這些發起人使用 SAML 聲明或 JSON Web 權杖 (JWTs) 進行身分驗證，而不是 SigV4 簽章。由於它們在請求時沒有 AWS 身分，因此請求內容不包含主體型條件索引鍵，例如 `aws:PrincipalOrgID`、 `aws:PrincipalAccount`和 `aws:PrincipalArn`。
**重要**
如果您的 VPC 端點政策僅依賴 `aws:PrincipalOrgID`來允許存取，則會隱含拒絕聯合`AssumeRoleWithSAML`和`AssumeRoleWithWebIdentity`呼叫，因為非AWS 委託人沒有條件金鑰。
### 如何 AWS STS 評估聯合發起人的 VPC 端點政策
當聯合發起人`AssumeRoleWithWebIdentity`透過 VPC 端點叫用 `AssumeRoleWithSAML`或 時，適用下列情況：
+ 發起人不是 AWS 委託人。請求內容中無法使用條件索引鍵`aws:PrincipalOrgID`，例如 `aws:PrincipalAccount`、 和 `aws:PrincipalArn` 。
+ 聯合發起人在請求內容`aws:PrincipalIsAWSService`中沒有 條件索引鍵。
+ 正在擔任的角色是 AWS 資源。`aws:ResourceAccount` 可使用 `aws:ResourceOrgID`和 等資源型條件索引鍵，並參考目標角色。
+ 角色的信任政策仍然是聯合存取的主要授權閘道。VPC 端點政策提供額外的網路層級界限。
我們建議您在撰寫必須套用至聯合發起人的 VPC 端點政策陳述式`aws:ResourceAccount`時使用 `aws:ResourceOrgID`或 ，因為這些發起人沒有可用的主體型條件金鑰。
## AWS STS VPC 端點政策可用的條件索引鍵
下表顯示透過 AWS STS VPC 端點提出請求時，每個呼叫者類型的請求內容中常用的條件索引鍵及其可用性。除了此處列出的條件索引鍵之外，還有其他條件索引鍵可用。
**依呼叫者類型的條件索引鍵可用性**
| 條件鍵 | 已驗證的 AWS 主體 | 聯合發起人 | 說明 |
| --- | --- | --- | --- |
| `aws:PrincipalOrgID` | 是 | 否 | 呼叫主體的組織 ID |
| `aws:PrincipalAccount` | 是 | 否 | 呼叫主體的帳戶 ID |
| `aws:PrincipalArn` | 是 | 否 | 呼叫主體的 ARN |
| `aws:PrincipalIsAWSService` | 是 （評估為 false) | 否 （金鑰不存在） | 發起人是否為 AWS 服務主體 |
| `aws:ResourceOrgID` | 是 | 是 | 擁有所請求資源之帳戶的組織 ID |
| `aws:ResourceAccount` | 是 | 是 | 擁有所請求資源的帳戶 ID |
**注意**
對於已驗證的 AWS 委託人 (IAM 使用者和角色）`aws:PrincipalIsAWSService`， 會出現在請求內容中，並評估為 false。對於聯合發起人，此金鑰完全不存在於請求內容中。檢查 的條件`"Bool": {"aws:PrincipalIsAWSService": "false"}`不符合聯合發起人，因為金鑰不存在。
## 範例：允許組織的所有 AWS STS 動作
下列端點政策會將 AWS STS VPC 端點限制在您的組織，同時支援聯合存取。它允許組織中已驗證主體的所有 AWS STS 動作，並分別允許聯合發起人擔任組織中的角色。聯合發起人 (`AssumeRoleWithSAML` 和 `AssumeRoleWithWebIdentity`) 需要單獨的陳述式，因為他們在請求內容`aws:PrincipalOrgID`中沒有 。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOrganizationPrincipals",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-exampleorgid"
}
}
},
{
"Sid": "AllowFederatedAssumeRole",
"Effect": "Allow",
"Principal": "*",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:AssumeRoleWithWebIdentity"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceOrgID": "o-exampleorgid"
}
}
}
]
}
```
第一個陳述式使用 `"Principal": {"AWS": "*"}`搭配 `aws:PrincipalOrgID`來允許來自您組織的已驗證 AWS 主體。第二個陳述式使用 `"Principal": "*"`來比對聯合發起人，並使用 將目標角色限制為您的組織`aws:ResourceOrgID`。角色的信任政策仍然是可擔任哪些角色的聯合身分的主要控制項。
如需實作網路周邊控制的詳細資訊，請參閱 GitHub 網站上的[在 上建置資料周邊 AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)和[資料周邊政策範例](https://github.com/aws-samples/data-perimeter-policy-examples)。
## 範例：允許特定帳戶的所有 AWS STS 動作
下列端點政策允許特定帳戶中主體的所有 AWS STS 動作。當您的帳戶不屬於組織時，請使用此政策。在不同的陳述式中允許聯合發起人，因為他們在請求內容`aws:PrincipalAccount`中沒有 。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificAccountPrincipals",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalAccount": [
"111122223333",
"444455556666"
]
}
}
},
{
"Sid": "AllowFederatedAssumeRole",
"Effect": "Allow",
"Principal": "*",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:AssumeRoleWithWebIdentity"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": [
"111122223333",
"444455556666"
]
}
}
}
]
}
```
第一個陳述式使用 `"Principal": {"AWS": "*"}`搭配 `aws:PrincipalAccount`來允許來自指定帳戶的已驗證 AWS 委託人。第二個陳述式使用 `"Principal": "*"`來比對聯合發起人，並使用 將目標角色限制為相同的帳戶`aws:ResourceAccount`。角色的信任政策仍然是可擔任哪些角色的聯合身分的主要控制項。
## 範例：限制為特定 AWS STS 動作
下列端點政策僅允許已`AssumeRole`驗證的委託人和`AssumeRoleWithSAML`聯合發起人，兩者都適用於組織中的角色。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAssumeRoleByOrgPrincipals",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-exampleorgid"
}
}
},
{
"Sid": "AllowSAMLFederation",
"Effect": "Allow",
"Principal": "*",
"Action": "sts:AssumeRoleWithSAML",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceOrgID": "o-exampleorgid"
}
}
}
]
}
```
此政策`AssumeRoleWithWebIdentity`會透過此端點封鎖其他 AWS STS 動作`GetCallerIdentity`，例如 `GetSessionToken`、 和 。調整`Action`元素以符合您的需求。
## 範例：拒絕非組織存取，同時允許聯合
下列端點政策使用明確拒絕來封鎖組織外部已驗證的主體，同時保留聯合發起人的存取權。此方法從廣泛的允許開始，並新增目標拒絕陳述式。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAll",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
},
{
"Sid": "DenyNonOrgPrincipals",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sts:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-exampleorgid"
}
}
}
]
}
```
拒絕陳述式使用 `"Principal": {"AWS": "*"}`，其範圍僅限於已驗證的 AWS 主體。聯合發起人 (SAML 和 OIDC) 不是 AWS 主體，並且與此`Principal`元素不相符，因此拒絕不適用於它們。此方法可避免需要複雜的 `Null`或 `Bool`條件來切出聯合發起人的例外狀況。
**注意**
第一個陳述式允許所有主體的所有動作。第二個陳述式中的拒絕優先於組織外部已驗證的 AWS 主體。第一個陳述式允許聯合發起人，且不受拒絕影響，因為拒絕陳述式中的 `Principal`元素與其不相符。