클라우드에서 IAM 권한을 세분화 해 클라우드 내 A 팀에서 생성한 자원은 A 팀에서만 접근/관리가 가능하고 B팀에서 생성한 자원은 B팀만 접근/관리가 가능하도록 C팀에서 생성한 자원은 C팀만이 접근/관리가 가능한 클라우드 보안 정책을 소개하고자 합니다.
위의 그림의 경우 MSA 을 운영한다는 가정하에 IT 인력이 Devops 에 적합하도록 배치되어 있습니다. A 팀은 A 서비스의 모든 것을 관리/운영/개발 하며 B팀은 B 서비스의 모든 것을 관리/운영/개발 하게 되어있습니다. 마찬가지로 클라우드 내 자원의 생성/삭제 역시 각 팀의 팀장 또는 infra 담당이 관리하며 이렇게 생성된 자원은 오직 각팀의 구성원만이 접근이 가능합니다.
우선 클라우드 계정과 제로 트러스트 솔루션을 이용해 AD와의 연동 과정을 보겠습니다. AD와 연동을 하는 이유는 이러한 솔루션 없이는 직접 클라우드 내에서 IAM 사용자 계정을 만들고 그룹에 할당하는 작업이 필요하기 때문입니다. 연동을 통해 인사관리만 하면 되는 것이죠. 게다가 솔루션을 통해 클라우드 계정의 로그인 내역, 작업 내역을 기록 및 모니터링이 가능하다는 장점이 있습니다.
클라우드의 root 계정의 IAM 사용자 그룹은 각 A,B,C 로 나눠지며 자원의 접근만 가능한 Group-Member 그룹과 생성/소멸까지 가능한 Group-Infra 그룹으로 총 6개가 존재합니다.
AD 에서도 똑같은 형태의 그룹들이 존재하게 되며 연동을 통해 각 그룹별로 매치가 됩니다. 예를 들어 김XX 직원의 AD 계정을 AD의 A-Group-Member 에 포함시키면 김XX 직원은 클라우드의 A-Group-Member에 속하게 되는 것입니다.
2번째로 클라우드의 root 계정의 권한을 A,B,C 그룹에 할당하는 과정을 보겠습니다.
각 그룹별로 IAM 정책을 만들어 연결해주면 되는데 자원의 생성/소멸 등의 전반적인 Infra와 관련된 IAM 정책을 만들어 연동하겠습니다. A-Group-Infra 그룹의 사용자라면 필요에 따라 클라우드 자원을 생성/수정/소멸 할 수 있어야 합니다. 그리고 반드시 이렇게 생성된 자원들이 A-Group-Member 들에게만 접근이 허용되게 해야 할 것입니다. A-Group-Member 들에게 다른 서비스의 자원에 대한 접근이 가능해서도 안됩니다.
이를 위해서 생성되는 자원에 태그를 달고 해당태그가 달려진 자원은 특정 그룹에게만 권한을 부여하고자 합니다. 하지만 만약 자원을 생성할 때 태그를 달지 않는 경우는 어떻게 해야할까요? 이런 경우를 대비해 자원을 생성할때 특정 태그에 정해진 key:vaule 를 넣지 않는 경우 자원 생성이 불가능한 정책을 추가하려 합니다.
예를 들어 A 팀에게 A 팀만 접근이 가능한 자원을 생성하고자 할때
1. A팀원들은 Service:A 라는 태그가 달려진 자원에만 접근이 가능하다.
2. A팀의 Infra 담당이 자원을 생성할 때 Service:A 라는 태그를 달지 않으면 자원 생성이 불가능하다.
3. A팀의 Infra 담당이 생성되는 자원에 태그를 달때 Service:B, 또는 Serice:C 를 달아 다른 팀에게 할당이 불가능하다.
위 3가지 조건을 충족시켜는 정책을 만들어 각 사용자그룹에 할당해주겠습니다.
A-Group-Infra 그룹에 1,2,3 에 해당하는 정책을 할당시키고 A-Group-Member 그룹에는 1 정책을 할당시키면 됩니다. 여기서는 ec2와 관련된 작업을 예로 한번 적용해 보겠습니다.
Service:a 라는 태그가 붙은 ec2자원에만 권한을 가지게 됩니다.
2번째로는 Serivce 라는 태그를 달지 않으면 자원이 생성되지 않는 정책을 만들겠습니다.
태그를 달지 않거나 다른 이름의 태그를 달면 자원의 생성이 불가능 하게 됩니다.
3번째로 Service 라는 태그에는 a 외에는 다른 값이 적용되지 못하도록 강제하는 정책을 생성하겠습니다.
b,c 값이 들어가면 자원이 생성되지 못합니다.
이렇게 만든 3개의 정책을 A-Group-Infra 에 할당하고 1번 정책은 A-Group-Member 그룹에 할당하겠습니다.
처음으로 돌아가 작업의 워크플로우를 한번 살펴 보겠습니다. A 팀의 A-Group-Member 에 속하는 김XX의 경우를 예로 들어 보겠습니다.
1. A-Group-Member 에 속하는 김XX 은 자신의 사번/패스워드를 통해 A 서비스의 자원에 들어가 작업을 합니다.
2. 추가 자원이 필요해 A 팀장에게 자원의 생성을 요청합니다.
3. A-Group-Infra 에 속하는 이팀장은 요청받은 자원을 생성하면서 tag:value 에 Service:a 를 붙입니다.
4. 김XX은 새로운 자원에 접근합니다.
김XX 이 C 서비스 팀으로 부서를 옮기게 되었습니다.
1. 김XX의 계정을 AD의 A-Group-Member 그룹에서 제거 한 뒤 C-Group-Member 에 포함시킵니다.
2. 김XX은 더 이상 A 서비스 자원에 대한 모든 권한을 잃게 되며 대신 C 서비스 자원에 대한 접근 권한을 얻었습니다.
3. 이 모든 과정은 기록되며 모니터링 된다.
클라우드의 IAM 을 이용한 제로트러스트 아키텍처 정책을 하나 소개해봤습니다. 위에서 언급된 내용들은 이해를 돕고자 제시된 예제이며 실제 정책은 훨씬 복잡하고 세밀할 것을 참고해 주시기 바랍니다.
'AWS > IAM' 카테고리의 다른 글
| [번역] 기존의 on-premise Active Directory를 클라우드와 연동해 클라우드 계정 로그인 연동, 각종 웹 어플리케이션 SSO를 하는 방법 (0) | 2022.07.20 |
|---|---|
| [번역] IAM 정책 타입들(SCP, IAM, Permission boundary): 언제 어떻게 써야하는 가 (0) | 2022.07.12 |
| 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 |
