# Amazon VPC 엔드포인트 정책으로 AWS STS에 대한 액세스 제어
AWS Security Token Service에 대한 인터페이스 VPC 엔드포인트(AWS STS)를 생성할 때 엔드포인트 정책을 연결할 수 있습니다. 정책은 엔드포인트를 사용할 수 있는 보안 주체와 수행할 수 있는 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 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 보안 주체 | 페더레이션 호출자 | 설명 |
| --- | --- | --- | --- |
| `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`를 사용하여 대상 역할을 조직으로 제한합니다. 역할의 신뢰 정책은 페더레이션 ID가 어떤 역할을 수임할 수 있는지에 대한 기본 제어로 유지됩니다.
네트워크 경계 제어 구현에 대한 자세한 내용은 [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 작업 허용
다음 엔드포인트 정책은 특정 계정의 보안 주체가 모든 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 보안 주체를 허용합니다. 두 번째 문은 `"Principal": "*"`를 사용하여 페더레이션 호출자를 일치시키고 `aws:ResourceAccount`을 사용하여 대상 역할을 동일한 계정으로 제한합니다. 역할의 신뢰 정책은 페더레이션 ID가 어떤 역할을 수임할 수 있는지에 대한 기본 제어로 유지됩니다.
## 예: 특정 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` 조건을 사용할 필요가 없습니다.
**참고**
첫 번째 문은 모든 보안 주체에 대한 모든 작업을 허용합니다. 두 번째 문의 거부는 조직 외부의 인증된 AWS 보안 주체에 우선합니다. 페더레이션 호출자는 첫 번째 문에서 허용되며, 거부 문의 `Principal` 요소가 일치하지 않기 때문에 거부의 영향을 받지 않습니다.