CT Basic - Account & OU

Account

Account 종류

• Root Account: 처음 가입할때 만드는 12자리 Account (카드 정보 넣고 생성하는 그거!)
• IAM USER: 보통 Root를 사용하지 않고 보안상의 이유로 서로 다른 권한이 부여된 IAM 유저를 사용함

Multi Accounts

일반적으로 테스트 환경 말고 엔터프라이즈/커머셜 환경에서는 여러개의 Account를 사용함 그 목적은 아래와 같음

• 빌링 구분: 각 어플리케이션별로 발생하는 비용을 모니터링하기 위해서 계정을 분리함 이때, vpc 레벨에서 어플리케이션별 분리도 가능하기는 한데, 일부 비용들이 vpc 레벨단위로 모니터링하기가 힘듦 (네트워크 트래픽 비용 등)

• 보안성 향상: 최소 권한의 법칙을 따라야함! 그렇기 때문에 역할별로 Account 레벨에서 부터 분리하는 것이 가장 접근제어와 보안성 향상을 위한 계정 관리 방법. 사실, VPC만 으로도 어느 정도 컨트롤이 가능하기는한대, VPC 레벨 서비스가 아닌 리전 레벨 서비스들도 존재하기에 한계점이 있음 (s3등) 또한,IAM 만으로 역할별 접근 제어를 하려면 복잡도가 많이 높아지기에 다중 계정 환경을 추천함

• ACCOUNT LIMIT: AWS 리소스에는 계정별 Limit이 있는 것들이 있음 만약 Account 분리를 한다면, 이런 Limit 이슈를 마주치는 번거로움이 없어짐. 사실 어느정도는 클레임하면 풀어주는 소프트 리밋이지만, 일부 하드리밋도 존재하고 클레임 거는게 많이 번거로움

• 관리 편의성: 역할별로 Account별로 분리하는게 전반적인 관리에 가장 적합함. 만약에 s3 버킷을 사용한다 가정해보고 dev/stg/prd 모든 리소스가 한번에 보인다면 무척 혼란스럽고 헷갈림

AWS Organizations

• 모든 AWS 계정을 중앙 집중식으로 관리해주는 서비스
• Organizations에 등록된 AWS 계정의 통합 비용을 관리 할 수 있음
• SCP (Service Control Policy)를 활용해 계정에 대한 권한을 제어할 수 있음

AWS ControlTower

개념: 이런 다중 계정 환경을 편리하게 관리하기위한 AWS 솔루션

Management 계정(Master 계정, Payer 계정) (필수)

Control Tower를 관리하기 위해 있는 필수 계정으로 Control Tower의 구성 및 운영 관리를 위해 있음 주요 목적은 Organizaions Unit 관리, SCP 관리, 통합 빌링 정보 확인, Account Factory를 실행한 AWS 계정 생성임 또한 Management 계정에는 필수인원만 제한적으로 접근해야하고 해당 계정에는 CT 이외의 타 리소스를 최소화로 해야함

Log Archive 계정 (필수)

보안 로그의 중앙 적재소로 S3 버킷에 Cloud Trail 로그가 적재됨 마찬가지로 필수 인원만 접근하며 로그 관련 툴을 설치하거나 실행하기 위한 계정은 아님 Landing zone 모든 계정에서 API 활동 및 리소스 구성 Log 의 Repository 로 사용됨

Audit 계정 (필수)

보안 관련 AWS 서비스 및 툴이 위치하는 계정으로 GuardDuty master, Security Notifications, 3rd party 보안 모니터링 툴 등이 위치하며 보안 담당자가 해당 계정에 제한적으로 접근함

Shared Services (추가)

전사 공용 인프라가 위치 하는 계정으로 전사 공용 서비스 용도 (개별 애플리케이션 공통 컴포넌트를 위한 용도는 아님) 공용 서비스 중 VPC 기반으로 구현되는 컴포넌트들을 위한 VPC인 Shared Services VPC, AWS 콘솔에 대한 SSO를 Microsoft AD 통해 구성될 경우 관련 리소스 위치함, Hybrid DNS에 필요한 리소스가 위치 배포 관련 공용 서비스가 구성될 경우 관련 리소스가 위치 (Golden AMI, 전사 CI/CD 파이프라인), 필요시 IDC와 연결

Network Services (추가)

전사적 네트워크 연결성을 제공하기 위한 계정으로 전사적 연결성 제공 (North-South, East-West)함 Network Account 안에 다양한 VPC가 있는데 외부에서 들어오는 North 트래픽이거치는 VPC인 Secure VPC, Shared VPC – (Optional)서비스/어플리케이션 Account로 Subnet을 Share하는 VPC임 이 밖에 AWS VPC간 연결성을 제공하는 Transit Gateway, On-prem 과 IDC를 오고가는 South 트래픽에 대한 보안성을 갖춘 연결을 제공

개별 워크로드용 Account

기본 원칙: DEV,STG,PRD를 AWS account 레벨에서 분리, PRD는 최소 인원만 제한적으로 접근, Network 계정을 통해 WAN 및 on-prem DC와 연결하며 워크로드 별로 DEV,STG,PRD가 공유하는 컴포넌트가 있을 경우 이를 공용 계정(Shared Services)으로 분리함 (전사 공용 아니고 워크로드 별)

Sandbox 계정 (개발자별 Account)

필요시 개발자가 사용하는 AWS 계정도 별도로 관리 (테스트/학습용)

OU

Core OU

Root, Security, Sandbox OU는 기본 구성되며, Infrastructure OU 추가 가능

Root OU

Management 계정만 있음

Security OU

Log Archive 계정, Audit 계정 S3 관련 가드레일과 SCP가 많음

Infrastructure OU

Shared Services 계정과 Network 계정에 적용될 SCP를 연결하기 위함으로, Security OU만큼의 가드레일이 필요하지는 않으나 이 두 계정 내에 생성될 리소스가 많으므로 별도의 SCP가 필요할 수 있음

Application OU

워크로드별로 DEV/STG/PRD를 고려해서 OU 분리

ETC

AWS Single-Sign-On (SSO) : 중앙 클라우드 관리자와 최종 사용자가 여러 AWS 계정 및 비즈니스 애플리케이션에 대한 액세스 관리를 지원하는 서비스입니다 원리: AWS Service Catalog 를 사용해 생성된 계정에 대한 액세스를 설정하고 관리합니다

예시