AWS JSON 정책 요소: NotPrincipal
NotPrincipal 요소를 사용하여 IAM 사용자, 페더레이션 사용자, IAM 역할, AWS 계정, AWS 서비스 또는 NotPrincipal 요소에 지정된 기타 보안 주체를 제외한 모든 보안 주체에 대한 액세스를 거부할 수 있습니다.
VPC 엔드포인트를 포함한 일부 AWS 서비스에 대한 리소스 기반 정책에는 ID를 사용할 수 있습니다. 리소스 기반 정책은 리소스에 직접 삽입할 수 있는 정책입니다. IAM ID 기반 정책 또는 IAM 역할 신뢰 정책에는 NotPrincipal 요소를 사용할 수 없습니다.
NotPrincipal은 "Effect":"Deny"와 함께 사용해야 합니다. "Effect":"Allow"와 함께 사용은 지원되지 않습니다.
중요
NotPrincipal을 사용해야 하는 시나리오는 거의 없습니다. NotPrincipal을 사용하기 전에 다른 권한 부여 옵션을 살펴보는 것이 좋습니다. NotPrincipal을 사용할 경우 여러 정책 유형의 영향을 해결하기 어려울 수 있습니다. 대신 ARN 조건 연산자와 함께 aws:PrincipalArn 컨텍스트 키를 사용하는 것이 좋습니다. 자세한 내용은 모든 보안 주체 단원을 참조하십시오.
Deny와 함께 NotPrincipal 지정
NotPrincipal과 Deny를 함께 사용할 경우, 거부되지 않은 보안 주체의 계정 ARN도 지정해야 합니다. 지정하지 않으면 정책에서 해당 보안 주체를 포함하는 전체 계정에 대한 액세스가 거부될 수 있습니다. 정책에 포함하는 서비스에 따라 AWS에서 먼저 계정을 검증한 후 사용자를 검증할 수 있습니다. 위임된 역할 사용자(역할을 사용하는 사람)를 평가할 때 AWS는 먼저 계정을 검증한 후 위임된 역할 사용자를 평가합니다. 위임된 역할 사용자는 그 역할을 위임 받을 때 지정된 역할 세션 이름으로 식별할 수 있습니다. 따라서 사용자 계정의 ARN을 명시적으로 포함시키거나, 역할의 ARN과 해당 역할을 포함하는 계정의 ARN을 모두 포함시킬 것을 권장합니다.
중요
권한 경계 정책이 연결된 IAM 사용자 또는 역할에는 Deny 효과를 포함하는 NotPrincipal 정책 요소가 있는 리소스 기반 정책 문을 사용하지 않도록 합니다. Deny 효과를 포함하는 NotPrincipal 요소는 NotPrincipal 요소에 지정된 값에 관계없이 권한 경계 정책이 연결된 IAM 보안 주체를 항상 거부합니다. 이로 인해 원래 리소스에 액세스할 수 있는 일부 IAM 사용자 또는 역할이 해당 리소스에 더 이상 액세스할 수 없습니다. NotPrincipal 요소 대신 액세스를 제한하기 위해 ArnNotEquals 조건 연산자를 aws:PrincipalArn 컨텍스트 키와 함께 사용하도록 리소스 기반 정책 문을 변경하는 것이 좋습니다. 권한 경계에 대한 자세한 내용은 IAM 엔터티의 권한 범위 섹션을 참조하세요.
참고
최선의 결과를 위해 정책에 계정의 ARN을 포함시켜야 합니다. 모든 경우에 해당하는 것은 아니지만 일부 서비스에서는 계정 ARN이 필요합니다. 기존 정책은 필요한 ARN 없이 계속 적용되지만 이러한 서비스를 포함하는 새 정책은 계정 ARN을 포함시켜야 합니다. IAM은 이러한 서비스를 추적하지 않으므로 계정 ARN을 항상 포함시키는 것이 좋습니다.
다음 예제들은 같은 정책 설명에 있는 NotPrincipal과 "Effect":
"Deny"를 효과적으로 사용하는 방법을 보여줍니다.
예 동일하거나 다른 계정의 IAM 사용자의 예
다음 예제에서는 AWS 계정 444455556666에서 Bob이라는 이름의 사용자만 제외하고 모든 보안 주체의 리소스 액세스가 명시적으로 거부되었습니다. 모범 사례로서 NotPrincipal 요소는 사용자 Bob과 Bob이 속한 AWS 계정(arn:aws:iam::444455556666:root)의 ARN을 모두 포함한다는 점을 유념하세요. NotPrincipal 요소에 Bob의 ARN만 추가될 경우, 정책의 효과에 따라 사용자 Bob을 포함하는 AWS 계정에 대한 액세스가 명시적으로 거부될 수 있습니다. 경우에 따라, 사용자는 자신의 상위 계정보다 많은 권한을 가질 수 없습니다. 따라서 Bob의 계정에 대한 액세스가 명시적으로 거부되면 Bob은 리소스에도 액세스하지 못할 수도 있습니다.
이 예제는 444455556666가 아닌 같은 또는 다른 AWS 계정의 리소스에 연결된 리소스 기반 정책의 정책 설명에 포함될 때 의도한 대로 작동합니다. 이 예제 자체로는 Bob에게 액세스 권한을 부여하지 않지만 명시적으로 거부된 보안 주체 목록에서 Bob만 제외됩니다. Bob에게 리소스 액세스 권한을 허용하려면 다른 정책 문으로 "Effect":
"Allow"를 작성함으로써 액세스를 명시적으로 허용해야 합니다.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "NotPrincipal": {"AWS": [ "arn:aws:iam::444455556666:user/Bob", "arn:aws:iam::444455556666:root" ]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::BUCKETNAME", "arn:aws:s3:::BUCKETNAME/*" ] }] }
예 동일하거나 다른 계정의 IAM 역할의 예
다음 예제에서는 AWS 계정 444455556666에서 cross-account-audit-app이라는 이름의 위임된 역할 사용자만 제외하고 모든 보안 주체의 리소스 액세스가 명시적으로 거부되었습니다. 모범 사례로서, NotPrincipal 요소는 수임된 역할 사용자(cross-account-audit-app), 역할(cross-account-read-only-role) 및 역할이 속한 AWS 계정(444455556666)의 ARN을 포함합니다. NotPrincipal 요소에 역할의 ARN이 누락될 경우 정책 효과에 따라 역할에 대한 액세스가 명시적으로 거부될 수 있습니다. 마찬가지로, NotPrincipal 요소에 역할이 속한 AWS 계정의 ARN이 누락될 경우에는 정책의 효과에 따라 AWS 계정과 그 계정의 모든 엔터티에 대한 액세스가 명시적으로 거부될 수 있습니다. 경우에 따라, 위임된 역할 사용자는 자신의 상위 역할보다 많은 권한을 가질 수 없고, 역할은 자신의 상위 AWS 계정보다 많은 권한을 가질 수 없습니다. 따라서 역할 또는 계정에 대한 액세스가 명시적으로 거부되면 위임된 역할 사용자는 리소스에 액세스하지 못할 수 있습니다.
이 예제는 444455556666 이 아닌 다른 AWS 계정의 리소스에 연결된 정책 문이 리소스 기반 정책의 정책 문에 포함되기 때문에 의도한 대로 효과가 나타납니다. 이 예제 자체에서는 위임된 역할 사용자인 cross-account-audit-app에게 액세스를 허용하지 않지만 명시적으로 거부된 보안 주체 목록에서 cross-account-audit-app만 제외됩니다. cross-account-audit-app에게 리소스 액세스 권한을 부여하려면 다른 정책 문으로 "Effect":
"Allow"를 작성함으로써 액세스를 명시적으로 허용해야 합니다.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "NotPrincipal": {"AWS": [ "arn:aws:sts::444455556666:assumed-role/cross-account-read-only-role/cross-account-audit-app", "arn:aws:iam::444455556666:role/cross-account-read-only-role", "arn:aws:iam::444455556666:root" ]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::Bucket_AccountAudit", "arn:aws:s3:::Bucket_AccountAudit/*" ] }] }
NotPrincipal 요소에 위임된 역할 세션을 지정할 때 와일드카드(*)를 사용하여 “모든 세션”을 의미할 수 없습니다. 보안 주체는 항상 특정 세션의 이름을 지정해야 합니다.
