Organizations·SCP·다중 계정 거버넌스 실전 가이드
_Category: Governance_
클라우드 환경이 성숙해지면 단일 AWS 계정으로 운영하는 방식의 한계가 드러납니다. 개발팀·운영팀·보안팀이 하나의 계정을 공유하면 권한 경계가 모호해지고, 한 환경의 실수가 전체 서비스에 영향을 줍니다. 다중 계정 전략은 선택이 아니라, 엔터프라이즈 수준의 클라우드 운영에서는 기본 전제입니다. 이 글에서는 AWS Organizations, SCP, Control Tower, RAM을 중심으로 다중 계정 거버넌스의 전체 그림을 실무 관점에서 정리합니다.
---
왜 다중 계정인가: 격리 경계로서의 AWS 계정
AWS 계정은 단순한 청구 단위가 아닙니다. 계정은 IAM 정책·보안 그룹·VPC·서비스 한도(Service Quota)가 모두 독립적으로 적용되는 강력한 격리 경계입니다. 서로 다른 계정의 리소스는 명시적인 교차 계정 정책 없이는 접근할 수 없습니다.
다중 계정 전략의 이유는 네 가지입니다. 보안 격리(한 계정 침해가 다른 계정에 전파되지 않음), 규정 준수 경계(PCI-DSS 워크로드를 별도 계정에 격리), 비용 가시성(팀·프로젝트별 비용 귀속 명확화), 서비스 한도 분리(한 팀의 한도 소진이 다른 팀에 영향 없음)입니다. 다중 계정은 관리 복잡도를 높이므로, AWS Organizations와 Control Tower가 이를 해결합니다.
---
AWS Organizations와 OU 설계 패턴
AWS Organizations는 여러 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 서비스입니다. 조직 안에서 계정은 OU(Organizational Unit)라는 트리 구조로 분류됩니다. OU를 회사의 부서 트리라고 생각하면 이해하기 쉽습니다. 본사(루트) 아래에 사업부(OU)가 있고, 그 아래에 팀별 계정이 존재하는 구조입니다.
대부분의 엔터프라이즈에서 권장하는 OU 설계 패턴은 아래와 같습니다.
| OU | 포함 계정 | 목적 | |---|---|---| | Security OU | Log Archive, Security Tooling | 중앙 로그 수집, 보안 도구(Security Hub 위임 관리자 등) | | Infrastructure OU | Shared Services, Network | 공유 VPC, Transit Gateway, DNS | | Sandbox OU | 개발자 실험 계정 | 운영 정책에서 완화된 실험 환경 | | Workloads OU | Dev, Staging, Prod | 실제 서비스 워크로드 | | Suspended OU | 비활성 계정 | 종료 전 격리 |
Log Archive 계정은 모든 계정의 CloudTrail·Config 로그를 수집하는 전용 계정으로, 타 계정에서 로그를 삭제·변조할 수 없도록 격리합니다. Security Tooling 계정은 Security Hub·GuardDuty의 위임 관리자를 맡아 전 계정 보안 경보를 중앙 집중화합니다.
---
SCP의 정확한 의미: 허용이 아닌 최대 한계
SCP(Service Control Policy)는 Organizations에서 가장 자주 오해되는 개념입니다. SCP는 권한을 부여하지 않습니다. SCP는 해당 계정·OU에서 허용될 수 있는 최대 권한의 경계를 정의합니다. 회사 전체 행동 강령(Code of Conduct)과 같습니다. 강령이 허용하는 범위 안에서만 개인(IAM 정책)이 행동할 수 있습니다.
SCP와 IAM 정책의 차이를 명확히 이해하는 것이 시험의 핵심입니다.
| 구분 | SCP | IAM 정책 | |---|---|---| | 적용 대상 | 계정·OU 전체 (루트 포함) | 개별 사용자·역할·그룹 | | 부여 가능 여부 | 권한 부여 불가 (경계만 설정) | 권한 직접 부여 가능 | | 재정의 가능 여부 | 계정 관리자가 해제 불가 | 관리자가 수정·삭제 가능 | | 적용 범위 | 멤버 계정 내 모든 IAM 엔티티 | 연결된 엔티티에만 적용 | | 관리 계정 적용 | 적용되지 않음 | 적용됨 |
SCP 평가는 루트 → 상위 OU → 하위 OU → 계정 순으로 중첩 적용됩니다. 모든 계층 SCP와 IAM 정책이 모두 허용해야 최종 허용이 됩니다. 하나라도 명시적 거부(Deny)가 있으면 차단됩니다.
실무에서 자주 쓰이는 SCP 패턴은 리전 제한(aws:RequestedRegion 조건), 루트 계정 보호, 보안 서비스 비활성화 방지 세 가지입니다. 리전 제한 시 IAM·CloudFront·Route 53 등 글로벌 서비스는 NotAction으로 예외 처리해야 합니다.
---
Control Tower와 Landing Zone: 거버넌스 자동화
Control Tower는 신규 지사 개설 매뉴얼과 같습니다. 다중 계정 환경을 처음 구축하는 팀에게 모범 사례 기반의 기본 구조(Landing Zone)를 자동으로 설정해 줍니다. 수동으로 OU를 만들고 SCP를 연결하고 계정을 생성하는 반복 작업을 자동화합니다.
Control Tower가 자동 설정하는 Landing Zone의 핵심 구성 요소는 다음과 같습니다.
| 구성 요소 | 설명 | |---|---| | Root OU | 조직 최상위, Management 계정 위치 | | Security OU | Log Archive 계정 + Audit 계정 자동 생성 | | Sandbox OU | 실험용 계정 격리 | | Guardrails (Controls) | 예방형·탐지형 거버넌스 규칙 자동 적용 | | Account Factory | 신규 계정을 표준 설정으로 자동 프로비저닝 | | Dashboard | 전체 계정 규정 준수 상태 한눈에 확인 |
Guardrail은 두 종류입니다. 예방형(Preventive) Guardrail은 SCP로 구현되어 규칙 위반 리소스 생성 자체를 차단합니다. 탐지형(Detective) Guardrail은 AWS Config 규칙으로 구현되어 위반 상태를 감지하고 알림을 보냅니다.
Account Factory는 Service Catalog 기반으로 동작합니다. 새 계정 요청이 들어오면 미리 정의된 템플릿(VPC 설정, IAM 역할, 태그, 로그 연결 등)을 자동 적용해 표준 계정을 생성합니다. Account Factory for Terraform(AFT)을 사용하면 Terraform으로 계정 생명주기를 IaC로 관리할 수 있습니다.
Organizations 정책 유형도 정리해 둡니다. Tag Policy는 조직 수준에서 태그 표준을 강제합니다. AI Services Opt-out Policy는 Amazon Rekognition·Comprehend 등 AI 서비스가 사용자 데이터를 모델 학습에 사용하지 않도록 일괄 적용합니다. Backup Policy는 AWS Backup 계획을 중앙에서 강제합니다.
---
Org-wide 보안 서비스: Security Hub·GuardDuty·Config·Macie의 조직 통합
다중 계정 환경에서 보안 서비스를 계정마다 개별 활성화하면 관리 부담이 급격히 늘어납니다. AWS는 각 보안 서비스에 Organizations 통합 기능을 제공하여 한 번의 설정으로 전 계정에 자동 활성화하고, 단일 계정에서 중앙 집중적으로 관리할 수 있게 합니다. 이때 중앙 관리를 맡는 계정이 위임 관리자(Delegated Administrator)입니다.
Org-wide 보안 서비스를 활성화하는 올바른 순서가 중요합니다. 먼저 AWS Config를 활성화해야 합니다. Security Hub는 Config가 사전 활성화된 상태에서만 동작합니다. Security Hub의 보안 표준(CIS, AWS Foundational)이 Config 규칙 평가 결과를 직접 사용하기 때문입니다. 이후 GuardDuty를 조직 전체 자동 활성화로 설정하고, Security Hub를 켜면 GuardDuty finding이 EventBridge 없이 자동으로 Security Hub에 집계됩니다. Macie도 동일한 패턴으로 위임 관리자 계정에서 일괄 활성화합니다.
위임 관리자(Delegated Administrator) 계정은 Security Tooling 계정을 사용합니다. Management 계정에서 직접 보안을 운영하지 않고 전문 계정에 위임함으로써 Management 계정의 권한 노출을 최소화합니다.
보안 서비스별 Org 통합 요약은 아래와 같습니다.
| 서비스 | 위임 관리자 지원 | 자동 활성화 | 중앙 집계 | |---|---|---|---| | Security Hub | 지원 | 지원 | Aggregation Region으로 모든 Region finding 집계 | | GuardDuty | 지원 | 지원 | 관리 계정에서 멤버 finding 조회 | | AWS Config | 지원 | 별도 설정 필요 | Config Aggregator로 다계정 집계 | | Amazon Macie | 지원 | 지원 | 관리 계정에서 멤버 finding 조회 | | IAM Access Analyzer | 지원 | 지원 | 조직 범위 분석기 생성 |
---
Resource Access Manager와 교차 계정 리소스 공유
Resource Access Manager(RAM)는 AWS 리소스를 다른 계정 또는 Organizations 전체와 공유할 수 있게 해 주는 서비스입니다. 각 계정이 동일한 리소스를 개별적으로 만드는 것보다 하나를 공유하는 방식이 비용과 관리 측면에서 유리한 경우에 사용합니다.
RAM으로 공유할 수 있는 주요 리소스는 VPC 서브넷, Transit Gateway, Route 53 Resolver 규칙, License Manager 라이선스 등입니다. VPC 서브넷 공유가 가장 일반적입니다. 중앙 네트워킹 계정에서 공유 VPC를 생성하고 각 워크로드 계정에서 해당 서브넷에 EC2를 배포하면, 각 계정이 독립적인 IAM·보안 경계를 유지하면서 공통 네트워크 인프라를 사용할 수 있습니다.
Organizations 내부에서 RAM 공유 시 수신자가 초대를 수락할 필요 없이 자동 적용됩니다. 조직 외부 계정과 공유할 경우 명시적 수락이 필요합니다.
교차 계정 권한 모델의 또 다른 핵심은 IAM Identity Center(구 SSO)입니다. Organizations와 통합하여 단일 로그인으로 여러 계정에 접근하고, 권한 세트(Permission Set)를 중앙에서 관리합니다. 각 계정에 개별 IAM 사용자를 생성하는 대신 Identity Center 사용자·그룹에 권한 세트를 매핑하는 방식이 모범 사례입니다.
---
시험에서 헷갈리는 거버넌스 시나리오
실제 시험 문제에서 반복적으로 등장하는 함정 시나리오를 정리합니다.
시나리오 1: "조직 전체에서 특정 리전 외 리소스 생성을 차단하고, 각 계정 관리자가 해제할 수 없어야 한다."
정답은 SCP + aws:RequestedRegion 조건입니다. IAM 권한 경계(Permission Boundary)는 개별 IAM 사용자·역할 단위로 적용되며 계정 관리자가 해제할 수 있어 다릅니다. 조직 전체 강제 + 해제 불가 조건이 나오면 SCP를 선택하세요. 글로벌 서비스(IAM, CloudFront, Route 53, STS)는 NotAction으로 예외 처리해야 합니다.
시나리오 2: "EC2 인스턴스가 S3 게이트웨이 엔드포인트를 통해 조직 외부 S3 버킷에 접근하지 못하도록 예방적으로 차단하고 싶다."
정답은 VPC 엔드포인트 정책에 aws:ResourceOrgID 조건 추가입니다. PrincipalOrgID는 요청자(주체)가 조직 소속인지 검사하고, ResourceOrgID는 대상 리소스(버킷)가 조직 소속인지 검사합니다. 외부 버킷 차단 목적에는 ResourceOrgID가 적합합니다.
시나리오 3: "Security Hub를 도입하려고 한다. 사전에 어떤 서비스를 활성화해야 하는가?"
Security Hub의 필수 사전 서비스는 AWS Config이지 CloudTrail이 아닙니다. GuardDuty finding은 Security Hub 활성화 시 자동으로 집계되며 별도 설정이 필요하지 않습니다.
시나리오 4: "IAM 액세스 키가 90일 이상 교체되지 않은 경우를 스크립트 없이 자동 탐지하고 싶다."
정답은 AWS Config 관리형 규칙 access-keys-rotated입니다. IAM credential report + Lambda 방식은 별도 스크립트 개발과 주기적 폴링이 필요합니다. Config 관리형 규칙은 활성화만 하면 자동 평가되며, 위반 시 EventBridge → SNS로 알림을 보낼 수 있습니다.
시나리오 5: "GuardDuty가 EC2 인스턴스 침해를 탐지했을 때 해당 인스턴스만 자동 격리하고 싶다."