# VPC エンドポイントポリシーによる AWS STS へのアクセスのコントロール
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 は、基本的に異なる 2 つのタイプの発信者からのリクエストを処理します。VPC エンドポイントポリシーは、正当なリクエストを意図せずにブロックしないように、両方のタイプを考慮する必要があります。
**認証された AWS プリンシパル**
AWS Signature Version 4 (SigV4) でリクエストに署名する IAM ユーザーと IAM ロール。これらの発信者には、`aws:PrincipalOrgID`、`aws:PrincipalAccount`、`aws:PrincipalArn` などの標準条件キーがあり、リクエストコンテキストで使用できます。
**フェデレーティッド発信者**
`AssumeRoleWithSAML` または `AssumeRoleWithWebIdentity` を呼び出す SAML 2.0 および OpenID Connect (OIDC) プリンシパル。これらの発信者は、SigV4 署名ではなく SAML アサーションまたは JSON ウェブトークン (JWT) で認証します。リクエスト時に AWS アイデンティティがないため、リクエストコンテキストには、`aws:PrincipalOrgID`、`aws:PrincipalAccount`、`aws:PrincipalArn` などのプリンシパルベースの条件キーは含まれません。
**重要**
VPC エンドポイントポリシーがアクセスを許可するために `aws:PrincipalOrgID` のみに依存している場合、非 AWS プリンシパルには条件キーがないため、フェデレーティッド `AssumeRoleWithSAML` および `AssumeRoleWithWebIdentity` 呼び出しは黙示的に拒否されます。
### AWS STS がフェデレーティッド発信者の VPC エンドポイントポリシーを評価する方法
フェデレーティッド発信者が VPC エンドポイントを介して `AssumeRoleWithSAML` または `AssumeRoleWithWebIdentity` を呼び出す場合、以下が適用されます:
+ 発信者は AWS プリンシパルではありません。`aws:PrincipalOrgID`、`aws:PrincipalAccount`、`aws:PrincipalArn` などの条件キーは、リクエストコンテキストでは使用できません。
+ フェデレーティッド発信者には、リクエストコンテキストに条件キー `aws:PrincipalIsAWSService` がありません。
+ 引き受けるロールは AWS リソースです。`aws:ResourceOrgID` や `aws:ResourceAccount` などのリソースベースの条件キーは使用可能であり、ターゲットロールを参照します。
+ ロールの信頼ポリシーは、フェデレーテッドアクセスのプライマリ認可ゲートのままになります。VPC エンドポイントポリシーは、追加のネットワークレベルの境界を提供します。
これらの発信者には利用可能なプリンシパルベースの条件キーがないため、フェデレーティッド発信者に適用する必要がある VPC エンドポイントポリシーステートメントを記述する場合は、`aws:ResourceOrgID` または `aws:ResourceAccount` を使用することをお勧めします。
## AWS STS VPC エンドポイントポリシーで利用可能な条件キー
次の表は、AWS STS VPC エンドポイントを介してリクエストを行うときに一般的に使用される条件キーと、各発信者タイプのリクエストコンテキストでの可用性を示しています。追加の条件キーは、ここに記載されている条件キー以外にも利用可能です。
**発信者タイプ別の条件キーの可用性**
| 条件キー | 認証された AWS プリンシパル | フェデレーティッド発信者 | [Description] (説明) |
| --- | --- | --- | --- |
| `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"
}
}
}
]
}
```
最初のステートメントでは、`aws:PrincipalOrgID` とともに `"Principal": {"AWS": "*"}` を使用して、組織からの認証された AWS プリンシパルを許可します。2 番目のステートメントでは、`"Principal": "*"` を使用してフェデレーティッド発信者を照合し、`aws:ResourceOrgID` を使用してターゲットロールを組織に制限します。ロールの信頼ポリシーは、フェデレーティッドアイデンティティがどのロールを引き受けることができるかについて、プライマリコントロールのままになります。
ネットワーク境界コントロールの実装の詳細については、「[AWS でのデータ境界の構築](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)」および GitHub ウェブサイトの「[データ境界ポリシーの例](https://github.com/aws-samples/data-perimeter-policy-examples)」を参照してください。
## 例: 特定のアカウントにすべての AWS STS アクションを許可する
次の VPC エンドポイントポリシーは、特定のアカウントのプリンシパルにすべての 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"
]
}
}
}
]
}
```
最初のステートメントでは、`aws:PrincipalAccount` とともに `"Principal": {"AWS": "*"}` を使用して、指定されたアカウントからの認証された AWS プリンシパルを許可します。2 番目のステートメントでは、`"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"
}
}
}
]
}
```
このポリシーは、このエンドポイントを介して `GetCallerIdentity`、`GetSessionToken`、`AssumeRoleWithWebIdentity` などの他の AWS STS アクションをブロックします。`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` 条件が不要になります。
**注記**
最初のステートメントでは、すべてのプリンシパルに対するすべてのアクションを許可します。2 番目のステートメントでの拒否は、組織外の認証された AWS プリンシパルに対して優先されます。フェデレーティッド発信者は最初のステートメントによって許可され、拒否ステートメントの `Principal` 要素がそれらを照合しないため、拒否による影響を受けません。