AWS에서의 유저의 행위, 그리고 대상이 되는 자원의 행위는 모두 IAM 정책의 영향을 받게 되어 있습니다. 유저가 새로운 EC2나 S3 버킷을 만들거나 기존의 자원들의 삭제 그리고 S3 버킷에 파일이 업로드될 때 이 행동들은 사전에 정의된 IAM 정책에 의해 허용 여부가 결정된다는 의미입니다.
이 포스팅에서는 여러 IAM 유형들에 대해 알아보고자 합니다. IAM 정책의 유형에는 Service control policy(SCP), 권한 경계(Permissions boundaries), 자격 증명 기반 정책(Identity-based policy), 자원 기반 정책(Resource-based policy)이 있으며 이들에 대해 언제 어떤 유형의 정책을 사용하고 누가 정책을 소유하고 관리해야 하는지에 대해 알아보겠습니다.
Service control policy (SCP)
복수의 AWS 계정들을 그룹화 하고 중앙 집중식으로 관리하기 위해 필요한 AWS Organizations에 필요한 것이라고 할 수 있습니다. SCP는 조직, OU, 개별 계정의 권한의 최대치를 설정하는 것입니다.
정책의 큰틀에서의 가이드라인을 제시하다고 볼 수 있습니다. 사용자에게 직접적으로 권한을 부여하지는 않습니다 그저 AWS Organizations에 속한 계정들의 권한의 범위를 지정합니다. 주요 기능은 각 계정간 OU 간 조직 간 보안 범위를 일관되게 유지하는 것입니다. 예를 들어 AWS 계정들은 허용된 특정 AWS 조직 OU에 조인될 수 있는데 임의로 탈퇴할 수 없도록 하는 정책, 자원의 생성을 ap-northeast 가 아닌 다른 지역에서 생성하지 못하도록 하는 정책 등이 있습니다.
권한 경계(Permission boundaries)
자격 증명 기반 정책(Identity-based policy)에서 권한의 최대치를 설정할 수 있는 것입니다. IAM 정책에는 principal 이라는 속성이 있습니다. 정책이란 principal이 resource에 대해 condition에 따라 action의 허용 여부를 지정하는 것인데 이 principal (누가)의 권한은 permission boundaries와 자격 증명 기반 정책 양쪽에 부합해야 합니다. 권한 경계에서 S3 버킷 생성 권한이 없을 경우 S3의 모든 권한을 가진 자격 증명 기반 정책이 반영되어도 S3 버킷을 만들 수는 없습니다.
권한 경계는 사용자 기반 정책의 한 종류라고 볼 수 있지만 유저에게 직접 부여할 수 없습니다. SCP 처럼 가이드라인을 제시하는 것입니다. 권한 경계는 주로 IAM 정책 설정의 위임에 이용됩니다. 예를 들어 계정의 관리자 A 가 B에게 유저의 생성 업무를 위임하고자 합니다. 이렇게 생성된 일반 유저들에게는 지켜져야 하는 보안 정책이 몇 가지 있습니다. A는 B가 아래의 규정을 준수하는지 확신이 필요합니다.
- 사용자는 IAM을 사용하여 사용자, 그룹, 역할 또는 정책을 생성하고 관리할 수 없다.
- 사용자는 Amazon S3 logs 버킷 액세스가 불가능 하며 특정 EC2 인스턴스 접근이 불가능하다.
- 사용자는 사용자 자체 경계 정책을 제거할 수 없다.
위 사항이 적용되어 있는 IAM 정책을 만들어 새로운 유저들의 권한 경계로 설정함으로써 해당 규정을 준수할 수 있습니다.
자격 증명 기반 정책
Identity 기반 정책은 principal 즉 유저, 그룹, 역할에 첨부하는 정책입니다. IAM 정책은 principal 이 resource에 대해 condition에 따라 action의 허용 여부를 지정하는 것이라고 했습니다. 그런데 Identity 기반 즉 주체 행위를 하는 대상에게 부여하는 정책이기에 principal을 정의하지 않는 것이 특징입니다. "사용자 1"이라는 유저에게 이 정책을 첨부해 준 것이 principal = 사용자 1 이 되기 때문입니다.
Identity 기반 정책에는 AWS에서 직접 만들고 관리하는 AWS 관리형 정책, 사용자가 직접 만들고 관리하는 고객 관리형 정책 그리고 inline 정책이 있습니다. AWS 관리형 이나 고객 관리형은 재사용 가능하며 복수의 대상에게 부여할 수 있으며 inline 정책은 대상과 1:1로 매칭되는 만큼 의도치 않게 정책이 부여되는 실수를 줄일 수 있고 최소 권한 부여에 적합합니다.
자원 기반 정책
자원 기반 정책은 S3와 같은 자원에 첨부 가능한 정책입니다. IAM 정책은 principal 이 resource에 대해 condition에 따라 action의 허용여부를 지정하는 것인데 자원 기반 정책은 resource에게 어떤 principal이 사용 가능하게 해 줄지를 정하는 것입니다. 자원 기반 정책은 대상과 1:1로 매칭 되는 inline 정책이라는 특성을 가지고 있습니다. 정책을 정의하기 위해서는 IAM 항목이 아니라 해당 자원의 UI 콘솔에서 지정해야 합니다.
자원 기반 정책은 다수의 계정에서 광범위하게 사용되는 정책이 아닌 부가적인 정책입니다. 하나의 계정에 적합하게 부여되어 자격 증명 기반 정책과 혼용되어 사용됩니다. 예를 들어 계정 A 의A의 사용자 A는 계정 B의 S3 버킷 B에 접근권한이 있습니다. 하지만 S3 버킷 B의 자원 기반 정책에는 사용자 A의 접근을 허용하지 않고 있다면 A 계정의 사용자 A는 B 계정의 S3 버킷 B에 접근이 불가능합니다.
각 타입들을 어떻게 구성할까?
SCP, 권한 경계, 자격 증명 기반 정책, 자원 기반 정책을 활용한 예제 한번 알아보겠습니다. 하나의 계정에서 EC2를 생성하고 이 EC2가 같은 계정내의 S3 버킷에 파일을 읽고 쓰기를 하려 합니다. 그리고 다른 계정에 존재하는 S3 버킷의 파일을 읽기를 하려고 합니다.
Central Cloud 팀, Application 팀, Data Lake 팀 각 3개의 팀이 존재하며 Central Cloud 팀의 역할은 전체적인 보안과 거버넌스의 관리입니다. Application 팀의 역할은 새로운 앱을 빌드, 배포, 운영하는 것이며 개발된 앱이 배포되는 계정을 소유 관리합니다. Data Lake 팀의 역할은 데이터가 저장되는 계정을 소유 및 관리하는 것입니다.
- Central Cloud 팀 - 회사 전체의 보안과 거버넌스 관리
- Application 팀 - 새로운 애플리케이션 개발, 빌드, 배포, 운영, Application 계정 소유, 관리
- Data Lake 팀 - 데이터 관리 및 Data Lake 계정 소유, 관리
SCP 정책 적용
Central Cloud 팀은 기업이 소유한 모든 클라우드 계정에 대해 보안 책임을 가지고 있습니다. 그래서 여기에 해당되는 모든 계정들에게 2가지 SCP 정책을 적용하고자 합니다.
- 모든 API 전송은 암호화 되어야 한다.
- 기업의 AWS Organization에 속하는 계정들은 임의로 탈퇴가 불가능하다.
이 2가지 조건을 SCP로 적용해 AWS Organization에 속하는 계정들(Application 계정, Data Lake 계정) 에게 일괄적으로 적용하겠습니다.
정책 1
{
"Id": "ServiceControlPolicy",
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyIfRequestIsNotUsingSSL",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "PreventLeavingTheOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
}]
}Condition 항목에서 보듯이 SecureTransport 가 False 일 경우 모든 행위를 deny 하는 정책과 AWS Organization에서 탈퇴가 deny 되는 SCP 정책입니다.
권한 경계 정책 적용
Central Cloud 팀은 클라우드의 모든 보안 정책을 직접 생성하고 관리하기에는 업무 과부하가 심각해질 것이라고 예상하고 있습니다. 그래서 각 팀에게 필요한 IAM 정책을 직접 생성하고 관리하도록 하고자 합니다. 하지만 각 팀들이 생성한 IAM 정책들이 Central Cloud 팀이 규정해 놓은 가이드라인을 준수하길 원합니다.
Application 팀은 CI/CD 환경을 구축해 앱을 빌드, 배포, 운영하고자 합니다. 이 파이프라인은 직접 필요한 자원과 IAM 정책, 역할을 생성할 것입니다. Central Cloud 팀은 IAM 정책, 역할 생성을 Application 팀에게 위임했지만 가이드라인이 반드시 준수되길 원합니다. 파이프라인이 IAM 정책을 생성하도록 허용하지만 권한 경계를 통해 필요 이상의 권한이 부여됨을 제한하고자 하려는 목적입니다.
정책 2
{
"Id": "PermissionsBoundaryPolicy",
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage",
"sqs:PurgeQueue",
"sqs:GetQueueUrl",
"logs:PutLogEvents"
],
"Resource": "*"
}]
}해당 권한곙계는 위에 명시된 Action 외에는 묵시적 deny 되도록 설정해 놓은 것입니다. 만약 CI/CD 파이프 라인에서 S3 삭제 권한이 포함된 IAM 정책을 만들더라도 권한 경계에 포함되지 않기에 S3 삭제 행위는 불가능합니다.
자격 증명 기반 정책 적용
이 예에서 사내 팀들은 CI/CD 파이프라인을 통해서만 프로덕션 AWS 환경을 수정할 수 있습니다. 그렇지 않으면 프로덕션 환경에 대한 쓰기 액세스가 허용되지 않습니다. Application 계정에 액세스해야 하는 다양한 권한을 지원하기 위해 자격 증명 기반 정책이 포함된 세 가지 기본 IAM 역할이 필요합니다.
- 필요한 자원을 배포하는데 필요한 CI/CD 파이프라인 역할
- Central Cloud 팀의 일시적 권한 상승 프로세스 있는 read-only 역할
- Application 팀원을 위한 read-only 권한
위 3가지 역할은 Central Cloud 팀에 의해 생성되고 관리됩니다. Central Cloud 팀에게 계정 내 모든 자원에 대한 read-only 역할이 부여됩니다. 이는 AWS 관리형 ReadOnlyAccess 정책을 Central Cloud 팀에 연결해 가능합니다.
분석 및 트러블 슈팅을 위해 Application 팀 구성원에게도 read-only 역할이 부여됩니다. Application 팀은 EC2, S3, SQS, CloudFormation, CloudWatch에 대한 read-only 권한을 가질 수 있습니다.
정책 3
{
"Id": "DeveloperRoleBaselinePolicy",
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:Describe*",
"cloudformation:Get*",
"cloudformation:List*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"ec2:Describe*",
"ec2:Get*",
"ec2:List*",
"ec2:Search*",
"s3:Describe*",
"s3:Get*",
"s3:List*",
"sqs:Get*",
"sqs:List*",
"logs:Describe*",
"logs:FilterLogEvents",
"logs:Get*",
"logs:List*",
"logs:StartQuery",
"logs:StopQuery"
],
"Resource": "*"
}
]
}
CI/CD 파이프 라인을 통해 자원을 생성하기 때문에 계정에 대한 광범위한 권한을 가져야 합니다. 생성된 자원을 위해 필요한 정책, 역할 역시 파이프라인을 통해 생성되지만 권한 경계에서 제한된 범위를 넘을 수는 없습니다. 그리고 CI/CD가 생성하는 역할, 정책, 및 EC2 인스턴스에 대해 역할 경로를 지정해 다른 경로로 인해 생성된 역할이나 자원에 대해 영향을 끼치지 않도록 해야 합니다. 예를 들이 CI/CD 파이프라인에 생성하는 EC2 인스턴스의 경우 /cicdpipeline/application/ec2로 역할 경로를 지정해 놓음으로써 나머지 EC2 인스턴스와 구별이 가능합니다.
정책 4
{
"Id": "CICDPipelineBaselinePolicy",
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:*",
"sqs:*",
"s3:*",
"cloudwatch:*",
"cloudformation:*",
"logs:*",
"autoscaling:*"
],
"Resource": "*"
},
...
...
...
... 중략
{
"Effect": "Allow",
"Action": "iam:GetRole",
"Resource": [
"arn:aws:iam::111111111111:role/application-roles/*",
"arn:aws:iam::111111111111:role/aws-service-role/*"
]
}]
}CI/CD 파이프라인은 직접 자원과 IAM 역할, 정책을 생성, 삭제 및 변경 권한을 가지고 있습니다. 다만 권한 경계에 의해 제한된 권한에 벗어나는 것은 불가능합니다. 예를 들어 CI/CD가 IAM 정책을 하나 만들었습니다. IAM 정책 생성 권한을 가지고 있기 때문에 가능합니다. 하지만 CI/CD 파이프라인에게 IAM 정책을 생성하면서 특정 권한을 부여하지 못하도록 제한해 놓지 않았습니다. 그렇기 때문에 CI/CD 파이프라인이 부득이하게 권한 경계를 넘어서는 IAM 정책을 만들더라도 권한 경계에서 해당 권한이 차단되게 됩니다. 이렇게 CI/CD파이프라인에 의해 만들어진 것들이 권한 경계 이상의 권한을 가지는 것을 예방할 수 있습니다.
지금까지 언급된 자격 증명 기반 정책 외 하나의 역할이 더 있습니다. EC2 인스턴스에서 실행되는 앱이 S3 버킷에 대해 접근을 허용하는 역할입니다.
정책 5
{
"Id": "ApplicationRolePolicy",
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::DOC-EXAMPLE-
BUCKET1/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::DOC-EXAMPLE-
BUCKET2/*"
}]
}동일 계정 내 있는 버킷에 대해서 읽기, 쓰기 권한을 부여 외부 계정에 존재하는 버킷에 대해서는 읽기 권한을 부여하고 있습니다.
위에서 언급되었던 권한 경계를 다시 한번 보겠습니다.
정책 2
{
"Id": "PermissionsBoundaryPolicy"
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage",
"sqs:PurgeQueue",
"sqs:GetQueueUrl",
"logs:PutLogEvents"
],
"Resource": "*"
}]
}정책 5
{
"Id": "ApplicationRolePolicy",
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::DOC-EXAMPLE-
BUCKET1/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::DOC-EXAMPLE-
BUCKET2/*"
}]
}
권한 경계에서는 모든 S3 버킷에 대해 읽기 쓰기 권한을 부여하고 있습니다. 특정 S3 버킷에 대해 읽기, 쓰기 권한을 가진 정책 5는 정책 2 보다 좁혀진 범위인 것을 알 수 있습니다. 만약 정책 5에 s3:CreateBucket 권한을 추가한다면 어떻게 될까요? 새로운 버킷을 만드는 권한은 권한 경계의 범위를 넘어서기 때문에 정책5에 추가되어도 허용될 수 없습니다.
자원 기반 정책 적용
이 예에서 필요한 지원 기반 정책은 외부 계정의 버킷에 접근하기 위한 정책입니다. Data Lake 팀이 보유한 계정의 S3 버킷에 대해 Application 팀의 계정의 접근을 허용하는 정책이 필요합니다.
정책 6
{
"Version": "2012-10-17",
"Statement": [{
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/application-roles/ApplicationRole"
},
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*"
}]
}종합
- 해당 기업의 모든 AWS 계정(Application, Data Lake 계정)에 적용되는 SCP 설정
- CI/CD 파이프라인이 생성하는 자원, IAM 정책, 역할에 대한 권한 경계 설정
- Application 팀원들이 조회 및 트러블 슈팅을 위한 read-only 자격 증명 기반 IAM 역할 설정
- CI/CD 파이프라인이 직접 자원, IAM 정책, 역할을 생성, 삭제, 수정할 수 있는 자격 증명 기반 IAM 역할 설정
- 동일 계정 내 파이프라인이 생성한 EC2 인스턴스가 S3 버킷에 대해 읽기, 쓰기 가능한 자격 증명 기반 IAM 역할 설정
- 외부 계정의 S3 버킷에 읽기 권한을 설정하는 자원 기반 IAM 역할 설정
- Central Cloud 팀이 CI/CD 파이프라인이 생성한 대상을 조회하기 위한 read-only 자격 증명 기반 IAM 역할 설정
지금까지 만들어 놓은 7가지 정책이 어떤 기능을 하며 어떻게 적용되는지에 대해 정리해 봤습니다. 해당 예시를 통해 SCP, 권한 경계, 자격 증명 기반 IAM 역할, 자원 기반 IAM 역할이 어떻게 활용되는지에 대해 알아보았습니다. 저 역시 이번 포스팅을 번역하면서 각 개념들을 공부할 수 있는 기회가 되었습니다.
해당 포스팅은 https://aws.amazon.com/ko/blogs/security/iam-policy-types-how-and-when-to-use-them/ 을 번역하였습니다.
'AWS > IAM' 카테고리의 다른 글
| [번역] 기존의 on-premise Active Directory를 클라우드와 연동해 클라우드 계정 로그인 연동, 각종 웹 어플리케이션 SSO를 하는 방법 (0) | 2022.07.20 |
|---|---|
| AWS SCP, OU, Policy 에 대해 알아보자 (0) | 2022.04.20 |
| AWS IAM 정책(policy) 과 역할(role) 의 차이 (0) | 2022.04.05 |
| AWS IAM Identity base 와 resource base policy 의 차이 (0) | 2022.04.04 |
| 제로 트러스트 아키텍처 Cloud IAM 기반 태그별 권한 할당 (0) | 2022.03.10 |
