この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
저번에는 IAM을 대략적으로 알아보았습니다.
이번에는 IAM 정책에 대하여 조금 더 자세히 알아보도록 하겠습니다.
무엇을 알아보는가
우선 IAM 정책이 무엇인지에 대해서는 저번 글의 설명을 읽어봐주세요.
(IAM 정책 각 유형들은 무슨 차이점이?)
이 중 오늘 알아볼 내용은 자격 증명 기반 정책과 리소스 기반 정책에 대해서 입니다.
우선 결론부터
자격 증명 기반 정책은 사용자, 그룹 또는 역할에 연결되는 정책을 의미합니다. 관리형 정책과 인라인 정책으로 나뉩니다.
- 이 중 AWS 관리형 정책은 AWS 에서 기본적으로 생성하고 관리하는 정책입니다.
- 특히 AWS 관리형 직무 정책이란 "직무에서의 관리를 위한 AWS 정책"을 의미합니다.
- 인라인 정책은 단일 사용자, 그룹 또는 역할에 직접 추가하는 정책입니다.
리소스 기반 정책은 리소스에 연결되는 정책을 의미합니다. 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 권한을 부여하고 이러한 권한이 적용되는 조건을 정의합니다.
다음과 같은 이미지로 관리됩니다.
- 자격 증명 기반 정책
- 관리형 정책
- AWS 관리형 정책
- AWS 직무에 관한 관리형 정책
- 그 이외의 관리형 정책
- 고객 관리형 정책
- 인라인 정책
- 리소스 기반 정책
그럼 각 정책에 대해 알아보도록 하겠습니다.
자격 증명 기반 정책
자격 증명 기반 정책은 단순하게 정책을 부여한 자격 증명(IAM 사용자 또는 사용자 그룹 및 역할)이 무슨 작업을 어느 리소스에서 어떤 조건에서 수행할 수 있는지를 제어하는 정책입니다.
관리형 정책
관리형 정책은 독립적인 자원입니다. 어떤 자격 증명에도 연결되지 않은 상태에서도 존재할 수 있으며, 여러 자격 증명에서 공유할 수도 있습니다.
AWS 관리형 정책
AWS에서 생성 및 관리하는 독립적인 정책입니다.
AWS 관리형 정책은 여러 가지 일반 사용 사례에서 권한을 제공할 목적으로 설계되었습니다. 정책명에서 대략적인 사용처를 파악할 수 있습니다.
- ~~~FullAccess
- 전체 액세스 AWS 관리형 정책은 서비스에 대한 전체 액세스 권한을 부여하여 서비스 관리자에 대한 권한을 정의합니다
- ~~~PowerUser
- 파워 사용자 AWS 관리형 정책은 파워 사용자용으로 설계되어있습니다
- ~~~[Read/Write]OnlyAccess
- 부분 액세스 AWS 관리형 정책은 권한 관리 액세스 수준 권한을 허용하지 않고 AWS 서비스에 대한 특정 액세스 수준을 제공합니다
이와 같이 기본적으로 생성된 AWS 관리형 정책은 다른 자격 증명에서도 사용이 가능하며 정책을 직접 작성하는 것보다 쉽게 적절한 권한을 핟당할 수 있습니다.
단, AWS 관리형 정책에 정의되어 있는 권한은 변경할 수 없습니다. 따라서 권한의 변경이 자주 발생할 것으로 생각되는 자격 증명에는 적용하지 않는 것이 좋습니다.
또한 AWS 관리형 정책은 여러 자격 증명에 할당할 수 있습니다. 전체적인 이미지를 그림으로 나타내면 다음과 같습니다.
AWS 직무에 관한 관리형 정책
IT 업계의 일반적인 직무 기능(job function)을 AWS 정책으로 구현한 것과 같습니다. 이 정책을 적용하면 특정 직무 담당자에게 기대되는 작업 수행에 필요한 권한을 부여할 수 있습니다.
직무 기능의 AWS 관리형 정책은 각 직무에 대해 예상되는 작업에 따라 필요한 권한을 사용자 정의한 AWS 관리형 정책입니다. 즉, 서비스에 중점을 둔 것이 아닌 업무에 필요한 작업의 추상화에 중점을 둔 정책입니다.
정의된 직무 기능은 다음과 같습니다.
- 결제 직무
- 데이터베이스 관리자 직무
- 데이터 사이언티스트 직무
- 개발자 고급 사용자 직무
- 네트워크 관리자 직무
- 읽기 전용 액세스
- 보안 감사자 직무
- 지원 사용자 직무
- 시스템 관리자 직무
- 보기 전용 사용자 직무
예를 들어 네트워크 관리자는 AWS 네트워크 리소스 설정 및 유지 관리를 담당하는 유스 케이스를 가정하고 거기에 일치하는 정책을 준비했습니다.
이 정책은 Auto Scaling, Amazon EC2, AWS Direct Connect, Route 53, Amazon CloudFront, Elastic Load Balancing, AWS Elastic Beanstalk, Amazon SNS, CloudWatch, CloudWatch Logs, Amazon S3, IAM, Amazon Virtual Private Cloud의 네트워크 리소스를 생성하고 유지할 수 있는 권한을 부여합니다. - 정책 설명
고객 관리형 정책
사용자 자신의 AWS 계정에서 관리하도록 생성한 독립적인 정책입니다.
생성한 정책은 AWS 계정에 속한 다수의 자격 증명에 연결할 수 있습니다.
인라인 정책
인라인 정책은 IAM 자격 증명에 포함되는 정책입니다. 즉, 정책은 자격 증명의 고유한 부분입니다. 따라서 인라인 정책은 정책과 자격 증명을 정확히 1대 1 관계로 유지합니다.
자격 증명을 생성하거나 이후에 생성할 때 정책을 생성하여 자격 증명에 삽입할 수 있습니다.
리소스 기반 정책
리소스 기반 정책은 Amazon S3 버킷과 같은 리소스에 연결하는 정책입니다.
리소스 기반 정책은 인라인 정책이며 관리형 리소스 기반 정책은 없습니다.
리소스 기반 정책을 지원하는 다른 서비스를 확인하려면 공식 문서 에서 해당 서비스가 지원하고 있는지를 확인해주세요.
어떤 정책을 사용해야하는가?
이렇게 많은 정책의 종류 중에서 어떤 정책을 써야 할까요?
이를 정리하면 다음과 같습니다.
그럼 각 기준에 대해 확인해보겠습니다.
연결할 대상
정책을 연결하는 대상에 따라 분류합니다.
자격 증명 기반이 우리가 흔히 말하는 IAM 정책입니다. 자격 증명(아이덴티티)에 연결할 수 있고, 연결 대상에 [~~에 대해 ~~할 수 있/없다]의 권한을 부여합니다.
리소스 기반은 말그대로 리소스에 연결하는 정책입니다. S3의 버킷 정책, IAM 역할의 신뢰 관계 정책, VPC 엔드 포인트의 엔드 포인트 정책이 이에 해당합니다. 연결 대상의 리소스에 [~~가 ~~하기 위해 접근하는 것을 허용/거부 한다]의 권한을 부여합니다.
예)로그의 출력(ELB > S3)
예를 들어 ELB의 로그를 S3 버킷에 출력하고 싶은 경우, ELB에 [S3에 대해 오브젝트를 put할 수 있다] 라고 하는 권한을 부여할 수 없습니다.
왜냐하면 IAM 역할은 ELB에 연결할 수 없으므로 자격 증명 기반 정책을 적용할 수 없기 때문입니다. 따라서 S3의 버킷 정책에서 [ELB가 오브젝트를 put하는 것을 허용한다]라는 리소스 기반 정책을 사용할 필요가 있습니다.
예)로그의 출력(RDS > CloudWatch)
RDS 로그를 CloudWatch Logs로 출력하는 경우, RDS에 IAM 역할을 연결할 수 있으므로(Service linked roles) CloudWatch Logs에 대해 로그를 출력할 수 있는 권한을 부여할 수 있습니다.
CloudWatch Logs 측에서는 리소스 기반 정책을 생각할 필요가 없습니다.
독립적으로 사용하는지
독립형인지 연결 대상의 일부분인지에 의해 분류됩니다.
리소스 기반 정책의 경우 항상 인라인 정책이 됩니다. 예를 들어 S3의 버킷 정책은 S3 버킷과 일대일 관계이며 여러 버킷에 동시에 연결할 수 없습니다.
연결 대상 리소스의 매개 변수 중 하나로 직접 포함되며 정책 자체에는 ARN (Amazon Resource Name)이 없습니다.
자격 증명 기반 정책의 경우 인라인 정책 뿐만 아니라 관리형 정책을 선택할 수도 있습니다. 관리형 정책은 독립형 정책으로, 고유한 ARN을 가지며 여러 자격 증명(사용자, 역할, 그룹)에 연결/분리할 수 있습니다.
정책의 내용을 변경할 때는 여러 자격 증명에 일괄적으로 적용할 수 있다는 점과 정책의 버전 관리와 롤백이 가능하다는 점에 장점이 있습니다.
반대로 인라인 정책을 선택하는 이점은 특정 자격 증명에만 적용하고자 하는 정책이며 다른 정책을 공유하여 의도하지 않은 변경이 발생하지 않도록 하는 경우가 있습니다. 보다 상세한 내용은 공식 문서를 참고해주세요.
누가 정책을 관리하는지
관리 정책을 IAM 엔터티에 연결하는 경우 다음 중 하나로 연결할지 여부를 선택할 수 있습니다.
- 권한(Permissions policy)으로 연결
- 권한 경계(Permissions boundary)로 연결
권한으로 연결하는 것이 일반적으로 알고 있는 연결 방법이며 이에 더해 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하기 위해 권한 경계를 설정할 수 있습니다.
권한 경계를 설정하면 Permissions 정책에 부여된 권한 및 AND 조건으로 평가가 수행됩니다.
(출처 : 공식 문서)
'둘 다' 또는 '명시적으로 허용' 상태가 아니면 IAM 엔터티가 작업을 수행할 수 없습니다. '명시적 권한'과 '아무것도 설정하지 않음(암시적 거부)' 조합의 경우에도 거부됩니다. 명시적인 거부가 없어도 거부가 되므로 자격 증명 기반 평가 방법과 리스소 기반의 평가 방법을 혼동하지 않도록 주의할 필요가 있습니다.
IAM에 대한 강한 조작 권한을 정책으로서 부여할 때, 미리 정해진 범위를 벗어나지 않도록 권한 경계를 설정하는 것이 유스 케이스입니다.
참고로 IAM 그룹은 권한 경계를 설정할 수 없습니다.
| 자격 증명 | Permissions policy | Permissions boundary |
|---|---|---|
| IAM 사용자 | O | O |
| IAM 그룹 | O | X |
| IAM 역할 | O | O |
누가 정책을 관리하는지
정책을 누가 관리하는지에 따라 분류합니다. 다음과 같은 상황에서는 고객 관리형 정책을 사용하게 됩니다.
- AWS 관리형 정책은 요구 사항을 충족시키지 못하는 경우
- 보다 세밀하게 제어하고 싶은 경우
- AWS 측의 변경에 의해 의도하지 않은 권한이 증가하는 것을 피하고 싶은 경우
직무 기능을 고려한 정책인가
AWS 관리형 정책을 사용하는 경우에서도 서비스 제한에 사로잡히지 않고 직무에 맞는 폭넓은 권한이 필요한 경우 AWS 직무에 관한 관리형 정책을 사용하게 됩니다.
마치며
IAM 정책의 세세한 부분까지 알아보았습니다.
저도 직무에 관한 관리형 정책이란게 도대체 무엇인가 싶었는데 정리하면서 이미지가 명확해졌네요.
다음 글에서는 ABAC와 RBAC에 대하여 알아보겠습니다.
긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 언제나 환영합니다. must01940 지메일로 연락 주시면 감사합니다!
본 블로그 게시글을 보시고 문의 사항이 있으신 분들은
클래스메소드코리아 (info@classmethod.kr)로 연락 주시면 빠른 시일 내 담당자가 회신 드릴 수 있도록 하겠습니다 !
0
