IAM 엔터티용 권한 경계
IAM 엔터티용 권한 경계 (Permissions boundaries for IAM entities)
AWS는 IAM 엔터티(사용자·역할)에 대한 **권한 경계(permissions boundaries)**를 지원해요. 권한 경계는 관리형 정책을 사용해 아이덴티티 기반 정책이 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능이에요. 엔터티의 권한 경계는 엔터티가 아이덴티티 기반 정책과 권한 경계가 모두 허용하는 작업만 수행할 수 있게 해요.
출처: 문서
본문
정책 유형에 대한 자세한 내용은 정책 유형을 참고하세요.
중요
권한 경계 정책이 연결된 IAM 사용자·역할에 대해, Deny 효과와 함께 NotPrincipal 정책 요소를 포함하는 리소스 기반 정책을 사용하지 마세요. Deny 효과와 함께 NotPrincipal 요소를 사용하면 NotPrincipal 요소에 지정된 값과 무관하게 권한 경계 정책이 연결된 어떤 IAM 프린시펄이든 항상 거부돼요. 이로 인해 그렇지 않으면 리소스에 접근할 수 있었을 일부 IAM 사용자·역할이 접근을 잃게 돼요.
리소스 기반 정책에서 NotPrincipal 요소 대신 ArnNotEquals 조건 연산자를 aws:PrincipalArn 컨텍스트 키와 함께 사용하도록 변경하길 권장해요. NotPrincipal 요소에 대한 자세한 내용은 AWS JSON 정책 요소: NotPrincipal을 참고하세요.
AWS 관리형 정책이나 고객 관리형 정책을 사용해 IAM 엔터티(사용자·역할)의 경계를 설정할 수 있어요. 그 정책은 사용자·역할의 최대 권한을 제한해요.
예를 들어 Shirley라는 IAM 사용자가 Amazon S3, Amazon CloudWatch, Amazon EC2만 관리할 수 있어야 한다고 가정해요. 이 규칙을 적용하려면 다음 정책으로 Shirley 사용자의 권한 경계를 설정할 수 있어요.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*"
],
"Resource": "*"
}
]
}
정책으로 사용자의 권한 경계를 설정하면 그 정책은 사용자의 권한을 제한하지만 자체적으로 권한을 제공하지는 않아요. 이 예시에서 정책은 Shirley의 최대 권한을 Amazon S3, CloudWatch, Amazon EC2의 모든 작업으로 설정해요. Shirley는 권한 정책이 허용하더라도 IAM을 포함한 다른 어떤 서비스에서도 절대 작업을 수행할 수 없어요. 예를 들어 Shirley 사용자에 다음 정책을 추가할 수 있어요.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
}
이 정책은 IAM에서 사용자 만들기를 허용해요. 이 권한 정책을 Shirley 사용자에게 연결하고 Shirley가 사용자를 만들려 하면 작업이 실패해요. 권한 경계가 iam:CreateUser 작업을 허용하지 않기 때문이에요. 이 두 정책을 감안하면 Shirley는 AWS에서 어떤 작업도 수행할 권한이 없어요. Amazon S3 같은 다른 서비스의 작업을 허용하도록 다른 권한 정책을 추가해야 해요. 또는 권한 경계를 업데이트해 IAM에서 사용자를 만들 수 있게 할 수도 있어요.
경계로 실효 권한 평가
IAM 엔터티(사용자·역할)의 권한 경계는 엔터티가 가질 수 있는 최대 권한을 설정해요. 이는 그 사용자·역할의 실효 권한을 바꿀 수 있어요. 엔터티의 실효 권한은 그 사용자·역할에 영향을 주는 모든 정책이 부여하는 권한이에요. 계정 안에서 엔터티의 권한은 아이덴티티 기반 정책, 리소스 기반 정책, 권한 경계, AWS Organizations SCP, 세션 정책의 영향을 받을 수 있어요. 다양한 정책 유형에 대한 자세한 내용은 AWS Identity and Access Management의 정책과 권한을 참고하세요.
이 정책 유형 중 하나라도 작업에 대한 접근을 명시적으로 거부하면 요청이 거부돼요. 여러 권한 유형이 엔터티에 부여하는 권한은 더 복잡해요. AWS가 정책을 평가하는 방법에 대한 자세한 내용은 정책 평가 로직을 참고하세요.
- 경계가 있는 아이덴티티 기반 정책 — 아이덴티티 기반 정책은 사용자, 사용자 그룹, 역할에 연결되는 인라인 또는 관리형 정책이에요. 아이덴티티 기반 정책은 엔터티에 권한을 부여하고, 권한 경계는 그 권한을 제한해요. 실효 권한은 두 정책 유형의 교집합이에요. 두 정책 중 하나의 명시적 거부가 허용을 덮어요.
- 리소스 기반 정책 — 리소스 기반 정책은 지정된 프린시펄이 정책이 연결된 리소스에 어떻게 접근할 수 있는지 제어해요.
- IAM 사용자용 리소스 기반 정책 — 같은 계정 안에서 (AWS STS 페더레이션 사용자 프린시펄 세션이 아닌) IAM 사용자 ARN에 권한을 부여하는 리소스 기반 정책은 아이덴티티 기반 정책이나 권한 경계의 암시적 거부에 제한되지 않아요.
- IAM 역할용 리소스 기반 정책
- IAM 역할 — IAM 역할 ARN에 권한을 부여하는 리소스 기반 정책은 권한 경계나 세션 정책의 암시적 거부에 제한돼요.
- IAM 역할 세션 — 같은 계정 안에서 IAM 역할 세션 ARN에 권한을 부여하는 리소스 기반 정책은 수임 역할 세션에 직접 권한을 부여해요. 세션에 직접 부여된 권한은 아이덴티티 기반 정책, 권한 경계, 세션 정책의 암시적 거부에 제한되지 않아요. 역할을 수임하고 요청을 하면 요청하는 프린시펄은 역할 자체의 ARN이 아니라 IAM 역할 세션 ARN이에요.
- AWS STS 페더레이션 사용자 프린시펄 세션용 리소스 기반 정책
- AWS STS 페더레이션 사용자 프린시펄 세션 — AWS STS 페더레이션 사용자 프린시펄 세션은
GetFederationToken을 호출해 만든 세션이에요. 페더레이션 사용자가 요청을 하면 요청하는 프린시펄은 페더레이션한 IAM 사용자의 ARN이 아니라 페더레이션 사용자 ARN이에요. 같은 계정 안에서 페더레이션 사용자 ARN에 권한을 부여하는 리소스 기반 정책은 세션에 직접 권한을 부여해요. 세션에 직접 부여된 권한은 아이덴티티 기반 정책, 권한 경계, 세션 정책의 암시적 거부에 제한되지 않아요. - 그러나 리소스 기반 정책이 페더레이션한 IAM 사용자의 ARN에 권한을 부여한다면, 세션 동안 AWS STS 페더레이션 사용자 프린시펄이 보내는 요청은 권한 경계나 세션 정책의 암시적 거부에 제한돼요.
- AWS STS 페더레이션 사용자 프린시펄 세션 — AWS STS 페더레이션 사용자 프린시펄 세션은
- AWS Organizations SCP — SCP는 전체 AWS 계정에 적용돼요. 계정 안의 프린시펄이 보내는 모든 요청의 권한을 제한해요. IAM 엔터티(사용자·역할)는 SCP, 권한 경계, 아이덴티티 기반 정책의 영향을 모두 받는 요청을 보낼 수 있어요. 이 경우 세 정책 유형이 모두 허용할 때만 요청이 허용돼요. 실효 권한은 세 정책 유형의 교집합이에요. 세 정책 중 하나의 명시적 거부가 허용을 덮어요.
- AWS CLI 명령이나 AWS API 작업으로 계정이 AWS Organizations의 조직 멤버인지 알 수 있어요. 조직 멤버는 SCP의 영향을 받을 수 있어요. 이 데이터를 보려면 AWS Organizations 엔터티에 대한
organizations:DescribeOrganization작업의 권한이 있어야 해요. AWS Organizations 콘솔에서 작업을 수행하려면 추가 권한이 있어야 해요. SCP가 특정 요청을 거부하고 있는지, 또는 실효 권한을 바꾸려면 AWS Organizations 관리자에게 문의하세요.
- AWS CLI 명령이나 AWS API 작업으로 계정이 AWS Organizations의 조직 멤버인지 알 수 있어요. 조직 멤버는 SCP의 영향을 받을 수 있어요. 이 데이터를 보려면 AWS Organizations 엔터티에 대한
- 세션 정책 — 세션 정책은 역할이나 페더레이션 사용자의 임시 세션을 프로그래밍 방식으로 만들 때 파라미터로 전달하는 고급 정책이에요. 세션의 권한은 세션을 만드는 데 사용된 IAM 엔터티(사용자·역할)와 세션 정책에서 와요. 엔터티의 아이덴티티 기반 정책 권한은 세션 정책과 권한 경계에 의해 제한돼요. 이 정책 유형 집합의 실효 권한은 세 정책 유형의 교집합이에요. 세 정책 중 하나의 명시적 거부가 허용을 덮어요. 세션 정책에 대한 자세한 내용은 세션 정책을 참고하세요.
권한 경계로 책임 위임
권한 경계를 사용해 사용자 생성 같은 권한 관리 작업을 계정의 IAM 사용자에게 위임할 수 있어요. 이렇게 하면 다른 사람이 특정 권한 경계 안에서 우리를 대신해 작업을 수행할 수 있어요.
예를 들어 María가 X-Company AWS 계정의 관리자라고 가정해요. 그녀는 사용자 생성 업무를 Zhang에게 위임하고 싶어요. 하지만 Zhang이 다음 회사 규칙을 준수하는 사용자를 만들도록 보장해야 해요.
- 사용자는 IAM으로 사용자, 그룹, 역할, 정책을 만들거나 관리할 수 없어요.
- 사용자는 Amazon S3 logs 버킷에 접근할 수 없고
i-1234567890abcdef0Amazon EC2 인스턴스에 접근할 수 없어요. - 사용자는 자신의 경계 정책을 제거할 수 없어요.
이 규칙을 적용하기 위해 María는 다음 작업을 완료해요. 각각의 세부 사항은 아래에 포함돼요.
- María는 계정의 모든 새 사용자용 권한 경계로 쓸
XCompanyBoundaries관리형 정책을 만들어요. - María는
DelegatedUserBoundary관리형 정책을 만들고 Zhang의 권한 경계로 할당해요. María는 자신의 관리자 사용자 ARN을 기록해 두고 정책에서 그것을 사용해 Zhang이 접근하지 못하게 해요. - María는
DelegatedUserPermissions관리형 정책을 만들고 Zhang의 권한 정책으로 연결해요. - María는 Zhang에게 새 책임과 제한에 대해 알려요.
작업 1: María는 먼저 새 사용자들의 경계를 정의하는 관리형 정책을 만들어야 해요. María는 Zhang이 사용자에게 필요한 권한 정책을 줄 수 있게 하되 그 사용자들이 제한되기를 원해요. 이를 위해 그녀는 XCompanyBoundaries라는 이름의 다음 고객 관리형 정책을 만들어요. 이 정책은 다음을 해요.
- 사용자에게 여러 서비스에 대한 전체 접근을 허용
- IAM 콘솔에서 제한된 자체 관리 접근을 허용. 이는 콘솔에 로그인한 뒤 비밀번호를 변경할 수 있다는 뜻이에요. 초기 비밀번호는 설정할 수 없어요. 이를 허용하려면
AllowManageOwnPasswordAndAccessKeys스테이트먼트에"*LoginProfile"작업을 추가해요. - 사용자가 Amazon S3 logs 버킷이나
i-1234567890abcdef0Amazon EC2 인스턴스에 접근하는 것을 거부
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ServiceBoundaries",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*",
"dynamodb:*"
],
"Resource": "*"
},
{
"Sid": "AllowIAMConsoleForCredentials",
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:GetAccountPasswordPolicy"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswordAndAccessKeys",
"Effect": "Allow",
"Action": [
"iam:*AccessKey*",
"iam:ChangePassword",
"iam:GetUser",
"iam:*ServiceSpecificCredential*",
"iam:*SigningCertificate*"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::logs",
"arn:aws:s3:::logs/*"
]
},
{
"Sid": "DenyEC2Production",
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0"
}
]
}
각 스테이트먼트는 서로 다른 목적을 가져요.
ServiceBoundaries스테이트먼트는 지정된 AWS 서비스에 전체 접근을 허용해요. 이는 새 사용자가 이 서비스들에서 하는 작업이 사용자에 연결된 권한 정책에 의해서만 제한된다는 뜻이에요.AllowIAMConsoleForCredentials스테이트먼트는 모든 IAM 사용자를 나열할 접근을 허용해요. 이 접근은 AWS Management Console의 Users 페이지를 탐색하는 데 필요해요. 또한 계정의 비밀번호 요구 사항을 볼 수 있게 해주는데, 이는 비밀번호를 변경할 때 필요해요.AllowManageOwnPasswordAndAccessKeys스테이트먼트는 사용자에게 자신의 콘솔 비밀번호와 프로그래밍 방식 접근 키만 관리하게 해요. Zhang 또는 다른 관리자가 새 사용자에게 전체 IAM 접근 권한 정책을 할당하면 중요해요. 그 경우 그 사용자가 자기 또는 다른 사용자의 권한을 변경할 수 있게 되는데, 이 스테이트먼트가 그것을 방지하는 거예요.DenyS3Logs스테이트먼트는 logs 버킷에 대한 접근을 명시적으로 거부해요.DenyEC2Production스테이트먼트는i-1234567890abcdef0인스턴스에 대한 접근을 명시적으로 거부해요.
작업 2: María는 Zhang이 모든 X-Company 사용자를 만들 수 있되 XCompanyBoundaries 권한 경계로만 만들도록 허용하고 싶어요. 그녀는 DelegatedUserBoundary라는 다음 고객 관리형 정책을 만들어요. 이 정책은 Zhang이 가질 수 있는 최대 권한을 정의해요.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CreateOrChangeOnlyWithBoundary",
"Effect": "Allow",
"Action": [
"iam:AttachUserPolicy",
"iam:CreateUser",
"iam:DeleteUserPolicy",
"iam:DetachUserPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"
}
}
},
{
"Sid": "CloudWatchAndOtherIAMTasks",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"iam:CreateAccessKey",
"iam:CreateGroup",
"iam:CreateLoginProfile",
"iam:CreatePolicy",
"iam:DeleteGroup",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteUser",
"iam:GetAccountPasswordPolicy",
"iam:GetGroup",
"iam:GetLoginProfile",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRolePolicy",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAccessKeys",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListEntitiesForPolicy",
"iam:ListGroups",
"iam:ListGroupsForUser",
"iam:ListMFADevices",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListRolePolicies",
"iam:ListSSHPublicKeys",
"iam:ListServiceSpecificCredentials",
"iam:ListSigningCertificates",
"iam:ListUserPolicies",
"iam:ListUsers",
"iam:SetDefaultPolicyVersion",
"iam:SimulateCustomPolicy",
"iam:SimulatePrincipalPolicy",
"iam:UpdateGroup",
"iam:UpdateLoginProfile",
"iam:UpdateUser"
],
"NotResource": "arn:aws:iam::123456789012:user/Maria"
},
{
"Sid": "NoBoundaryPolicyEdit",
"Effect": "Deny",
"Action": [
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion"
],
"Resource": [
"arn:aws:iam::123456789012:policy/XCompanyBoundaries",
"arn:aws:iam::123456789012:policy/DelegatedUserBoundary"
]
},
{
"Sid": "NoBoundaryUserDelete",
"Effect": "Deny",
"Action": "iam:DeleteUserPermissionsBoundary",
"Resource": "*"
}
]
}
각 스테이트먼트는 서로 다른 목적을 가져요.
CreateOrChangeOnlyWithBoundary스테이트먼트는 Zhang이XCompanyBoundaries정책으로 권한 경계를 설정한 경우에만 IAM 사용자를 만들 수 있게 해요. 이 스테이트먼트는 또한 기존 사용자의 권한 경계를 같은 정책으로만 설정할 수 있게 해요. 마지막으로 이 스테이트먼트는 Zhang이 이 권한 경계가 설정된 사용자의 권한 정책을 관리할 수 있게 해요.CloudWatchAndOtherIAMTasks스테이트먼트는 Zhang이 다른 사용자·그룹·정책 관리 작업을 완료할 수 있게 해요.NotResource정책 요소에 나열되지 않은 어떤 IAM 사용자에 대해서든 비밀번호를 재설정하고 접근 키를 만들 권한이 있어요. 이는 사용자의 로그인 문제를 돕게 해줘요.NoBoundaryPolicyEdit스테이트먼트는 Zhang이XCompanyBoundaries정책을 업데이트하는 접근을 거부해요. 그는 자기나 다른 사용자의 권한 경계를 설정하는 데 사용되는 어떤 정책도 변경할 수 없어요.NoBoundaryUserDelete스테이트먼트는 Zhang이 자기나 다른 사용자의 권한 경계를 삭제하는 접근을 거부해요.
그런 다음 María는 DelegatedUserBoundary 정책을 Zhang 사용자의 권한 경계로 할당해요.
작업 3: 권한 경계는 최대 권한을 제한하지만 자체적으로 접근을 부여하지 않으므로, María는 Zhang의 권한 정책을 만들어야 해요. 그녀는 DelegatedUserPermissions라는 다음 정책을 만들어요. 이 정책은 정의된 경계 안에서 Zhang이 수행할 수 있는 작업을 정의해요.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "IAM",
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
},
{
"Sid": "CloudWatchLimited",
"Effect": "Allow",
"Action": [
"cloudwatch:GetDashboard",
"cloudwatch:GetMetricData",
"cloudwatch:ListDashboards",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Sid": "S3BucketContents",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::ZhangBucket"
}
]
}
각 스테이트먼트는 서로 다른 목적을 가져요.
IAM스테이트먼트는 Zhang에게 IAM에 대한 전체 접근을 허용해요. 하지만 그의 권한 경계가 일부 IAM 작업만 허용하므로, 그의 실효 IAM 권한은 그의 권한 경계에 의해서만 제한돼요.CloudWatchLimited스테이트먼트는 Zhang이 CloudWatch에서 다섯 개의 작업을 수행할 수 있게 해요. 그의 권한 경계가 CloudWatch의 모든 작업을 허용하므로, 그의 실효 CloudWatch 권한은 그의 권한 정책에 의해서만 제한돼요.S3BucketContents스테이트먼트는 Zhang이ZhangBucketAmazon S3 버킷을 나열할 수 있게 해요. 하지만 그의 권한 경계가 어떤 Amazon S3 작업도 허용하지 않으므로, 그의 권한 정책과 무관하게 어떤 S3 작업도 수행할 수 없어요.
참고
Zhang의 정책은 그가 접근할 수 없는 Amazon S3 리소스에 접근할 수 있는 사용자를 만들 수 있게 해요. 이런 관리 작업을 위임함으로써 María는 효과적으로 Zhang을 Amazon S3 접근에 신뢰하는 거예요.
그런 다음 María는 DelegatedUserPermissions 정책을 Zhang 사용자의 권한 정책으로 연결해요.
작업 4: 그녀는 Zhang에게 새 사용자를 만드는 지침을 줘요. 그녀는 그에게 필요한 어떤 권한이든 가진 새 사용자를 만들 수 있지만, XCompanyBoundaries 정책을 권한 경계로 할당해야 한다고 알려줘요.
Zhang은 다음 작업을 완료해요.
- Zhang은 AWS Management Console로 사용자를 만들어요. 사용자 이름
Nikhil을 입력하고 콘솔 접근을 활성화해요.Requires password reset옆의 체크박스를 선택 해제해요. 위 정책들이 사용자가 IAM 콘솔에 로그인한 뒤에만 비밀번호를 변경할 수 있게 하기 때문이에요. - Set permissions 페이지에서 Zhang은
IAMFullAccess와AmazonS3ReadOnlyAccess권한 정책을 선택해 Nikhil이 작업을 할 수 있게 해요. - Zhang은 Set permissions boundary 섹션을 건너뛰며 María의 지침을 잊어요.
- Zhang은 사용자 세부 정보를 검토하고 Create user를 선택해요.
- 작업이 실패하고 접근이 거부돼요. Zhang의
DelegatedUserBoundary권한 경계는 그가 만드는 어떤 사용자든XCompanyBoundaries정책을 권한 경계로 사용해야 한다고 요구해요. - Zhang은 이전 페이지로 돌아가요. Set permissions boundary 섹션에서
XCompanyBoundaries정책을 선택해요. - Zhang은 사용자 세부 정보를 검토하고 Create user를 선택해요.
- 사용자가 생성돼요.
Nikhil이 로그인하면 권한 경계가 거부하지 않는 범위에서 IAM과 Amazon S3에 접근할 수 있어요. 예를 들어 IAM에서 자신의 비밀번호를 변경할 수 있지만 다른 사용자를 만들거나 자신의 정책을 편집할 수는 없어요. Nikhil은 Amazon S3에 읽기 전용 접근이 있어요.
누군가 logs 버킷에 Nikhil이 버킷에 객체를 넣을 수 있게 하는 리소스 기반 정책을 추가해도, 그는 여전히 버킷에 접근할 수 없어요. 그 이유는 logs 버킷의 어떤 작업이든 그의 권한 경계에 의해 명시적으로 거부되기 때문이에요. 어떤 정책 유형의 명시적 거부든 요청이 거부되게 해요.
하지만 Secrets Manager 시크릿에 연결된 리소스 기반 정책이 Nikhil에게 secretsmanager:GetSecretValue 작업을 허용한다면, Nikhil은 시크릿을 검색하고 복호화할 수 있어요. 그 이유는 Secrets Manager 작업이 그의 권한 경계에 의해 명시적으로 거부되지 않고, 권한 경계의 암시적 거부는 리소스 기반 정책을 제한하지 않기 때문이에요.