개인이 AWS 계정을 사용하는 사용하는 경우에는 사실 AWS Organization을 이용해 다른 AWS 계정들을 연동시키거나 개발계, 검증계, 운영계 등과 같은 OU를 따로 생성할 경우는 드물 것입니다. 하지만 엔터프라이즈급 기업의 경우는 다를 것입니다. 여러 가지 이유로 인해 AWS Organization을 통해 다수의 AWS 계정을 활용하며 OU를 생성해 기업의 구조와 흡사한 형태로 관리해야 할 것입니다. 이번 포스팅에서는 SCP, OU에 대해 알아보고 이들이 여태껏 봐왔던 IAM Policy 와는 어떻게 차이가 나는지 알아보고자 합니다.
위 그림의 경우 AWS Organization 에서 OU을 생성한 뒤 OU에 맞게 SCP를 적용한 후 AWS 계정을 OU에 포함시킨 후 IAM 사용자들의 Policy을 적용시킨 것입니다. 개별 사용자들이 사용하는 IAM 계정의 윗단에는 OU와 AWS Organzation 이 있게 됩니다.
그럼 우선적으로 SCP, OU, AWS management account, Boundary, Policy, IAM users 등에 대해 간단히 알아보겠습니다.
SCP (Serive Control Policy)
- SCP는 OU 또는 AWS account 를 대상으로 적용이 가능하다.
- SCP는 하위 OU에 상속이 된다.
- SCP는 OU들에 다르게 적용 가능하다.
Permission Boundary & Policy
- 정책과 경계는 IAM User 대상으로 적용이 가능하다.
- SCP와 중첩되어야만 정책이 적용된다.
OU (Organization Unit)
- OU는 AWS Account 들의 그룹 단위이다.
- OU는 하위 OU를 가질 수 있다. 회사 구조를 반영할 수 있다.
- 하나의 AWS 계정은 오직 하나의 OU에 속할 수 있다. 다른 OU에는 속할 수 없다.
- OU는 5단계 계증척 구조를 가질 수 있다.
management Account
- OU를 생성한 계정이다.
- 다른 AWS Account를 초대하거나 OU에서 포함시키거나 제거할 수 있다.
- 오직 하나의 마스터/루트 계정만이 존재한다.
- 이 계정은 SCP 의 영향을 받지 않는다.
Account
- OU에 초대받은 AWS 계정들이다.
- 신규 AWS 계정들은 OU에 생성되자마자 초대 가능하다.
- 기존에 존재하는 AWS 계정들도 OU에 초대받을 수 있다.
IAM Users
- AWS Account 에 속하는 IAM 사용자를 의미한다.
- Permission boundary 와 policy에 직접 영향을 받는다.
이번에는 AWS Organization 을 이용하는 데 있어 장점에 대해 알아보겠습니다.
중앙관리와 거번넌스의 일관성
- 다수의 AWS 계정들을 일관성 있게 관리할 수 있다. 그룹 또는 OU을 구성한 뒤 적절한 SCP를 연결해 다수의 계정들을 사용에 맞게 일관적으로 관리 가능하다.
- 다른 계정들의 다른 서버, 스토리지, 및 클라우드 리소스를 효과적으로 관리할 수 있다.
- AWS 계정 구조를 기업의 구조에 맞게 구성할 수 있다.
접근제어의 단순화
- 계정 그룹을 만든 다음 그룹에 SCP를 연결하여 계정 전체에 적절한 정책이 적용되도록 할 수 있습니다.
- 개별 AWS 서비스를 구체적으로 허용 또는 거부할 수 있습니다.
OU 또는 AWS 계정에 적절한 SCP 를 연결할 수 있습니다. 예를 들어 운영계 OU에는 ap-northeast-2 리전 외 다른 리전에는 서비스를 생성할 수 없습니다. 하지만 개발계 OU의 경우에는 여러 테스트를 위해 다른 리전에서 서비스를 사용할 수 있도록 SCP를 구성하였습니다. 이제 AWS 계정들을 개발계 또는 운영계 OU에 포함시켜주기만 하면 해당 SCP를 적용받을 수 있습니다.
통합 결제
- AWS Organizations를 사용하면 통합 결제를 통해 조직의 모든 AWS 계정에 대해 단일 결제 방법을 설정할 수 있습니다.
- 모든 계정에서 발생한 요금의 통합 보기를 볼 수 있습니다.또한 개별적으로 계정을 추적할 수 있으며 비용 데이터는 별도의 파일로 다운로드할 수 있습니다.
- 하나의 대시보드에서 모든 계정의 비용을 관리하고 감사할 수 있습니다.
만약에 10개 정도의 AWS 계정들을 가지고 있다고 가정해 보겠습니다. 매월 결제일이 되면 10개의 계정에서 비용이 얼마나 나올지 어떤 서비스를 사용했는지 내역을 보기 위해서는 10개의 계정들에서 일일이 확인해봐야 할 것입니다. 하지만 AWS Organization으로 통합할 경우 통합적으로 비용을 관리하고 결제할 수 있습니다.
중앙 집중식 보안 및 감사
- AWS CloudTrail을 사용하여 계정의 모든 이벤트를 감사할 수 있습니다.
- 권장 구성 기준을 중앙에서 정의할 수 있습니다.
- 리소스, AWS 리전 및 AWS Config가 있는 계정 전반에 걸쳐 AWS Control Tower를 사용하여 교차 계정 보안 감사를 설정하거나 계정 전체에 적용된 정책을 관리하고 볼 수 있습니다.
- GuardDuty, Firewall Manager, IAM Access Analyzer 등과 같은 보안 서비스를 중앙에서 관리하여 리소스를 보호할 수 있습니다.
비용결제와 함께 AWS Organization을 쓰는 가장 큰 이유라고 생각합니다. AWS에서는 통합 보안 툴로써 Security Hub 서비스를 제공하고 있습니다. 이는 각종 보안 툴로부터 통일화된 양식의 finding을 제공받아 중앙 집중식으로 관리하게 됩니다. 각종 보안 툴뿐만 아니라 member로 속해있는 AWS 계정들의 finding 역시 중앙 집중식으로 관리가 가능합니다.
그 외 AWS 계정의 추가에 있어 필요한 역할을 가진 OU내에서 생성하기만 하면 연결된 SCP를 그대로 적용받을 수 있다는 장점이 있습니다.
클라우드 이전에 있어 가장 중요한 측면 중의 하나가 클라우드가 기업의 조직도를 그대로 반영할 수 있을까라고 생각합니다. AWS Organization, OU, SCP, 를 활용해 기업의 조직도를 클라우드로 녹여내는 것 역시 클라우드 보안에서 중요한 요소라고 생각합니다.
해당 글은 아래의 링크를 참조해 작성했습니다.
'AWS > IAM' 카테고리의 다른 글
| [번역] 기존의 on-premise Active Directory를 클라우드와 연동해 클라우드 계정 로그인 연동, 각종 웹 어플리케이션 SSO를 하는 방법 (0) | 2022.07.20 |
|---|---|
| [번역] IAM 정책 타입들(SCP, IAM, Permission boundary): 언제 어떻게 써야하는 가 (0) | 2022.07.12 |
| AWS IAM 정책(policy) 과 역할(role) 의 차이 (0) | 2022.04.05 |
| AWS IAM Identity base 와 resource base policy 의 차이 (1) | 2022.04.04 |
| 제로 트러스트 아키텍처 Cloud IAM 기반 태그별 권한 할당 (0) | 2022.03.10 |
