기준: SAP-C02 시험 가이드오류 제보
Pro 시험에서 도메인 1(복잡한 조직 설계, 26%)의 핵심 4종은 Organizations · SCP · Control Tower · IAM Identity Center다. 한 주 동안 이 4종을 분리해서 봤다면, 오늘은 한 시나리오에서 동시에 작동하는 Pro 문제를 본격적으로 풀어본다.
도메인 1이 어려운 이유는 단일 서비스 지식이 아니라 층(layer)이 겹친 채로 출제되기 때문이다. "리전 제한이 안 먹힌다"는 문제 하나에도 SCP의 NotAction 예외, OU 상속, IDC Permission Set의 인라인 정책, RCP의 외부 Principal 차단이 동시에 얽혀 있을 수 있다. 그래서 오늘은 각 서비스를 다시 설명하기보다, 한 서비스의 결정이 다른 서비스에 어떤 파급(blast radius)을 일으키는지를 본다.
오늘 글의 구조는 1주차 day5와 동일하다.
도메인 1은 SAA에서 거의 다루지 않은 영역이라 학습 ROI가 가장 높다. 4주차까지 이 영역에 집중하고 5주차부터 신규 솔루션·마이그레이션으로 넘어가는 것이 16주 커리큘럼의 의도다.
AWS Organizations가 GA된 것은 2017년 2월이다. 그 전에는 Consolidated Billing(2010)만 있어서 청구만 묶고 권한 거버넌스는 각 계정이 알아서 했다. SCP는 Organizations와 함께 등장했고, 멀티 계정을 "비용 묶음"에서 "거버넌스 단위"로 격상시켰다. 2019년 Control Tower(Landing Zone 자동화), 2018년 AWS SSO(현 IAM Identity Center)가 차례로 나오며 오늘날의 스택이 완성됐다. 즉 도메인 1의 4종은 7~8년에 걸쳐 점진적으로 쌓인 계층이고, Pro 시험은 이 계층이 "함께 동작하는" 그림을 본다.
회사를 하나의 거대한 AWS 계정에서 운영하면 왜 안 되는가. 핵심은 blast radius(폭발 반경) 와 격리 경계(isolation boundary) 다.
분산 시스템 신뢰성 이론에서 fault containment region(FCR) 개념이 있다. 한 결함이 다른 영역으로 전파되지 못하도록 시스템을 경계로 나누는 설계다. AWS 계정은 클라우드에서 가장 강한 FCR이다 — IAM 정책 실수, 리소스 한도(quota), 보안 침해가 계정 경계를 넘지 못한다. VPC나 IAM 경계는 같은 계정 안의 "약한" 경계지만, 계정 경계는 AWS 백본 수준에서 분리된 "강한" 경계다. 이게 "Prod와 Non-Prod는 반드시 계정 분리"의 이론적 근거다.
멀티 계정 설계는 보안의 최소 권한 원칙(Principle of Least Privilege)과 권한 분리(Separation of Duties, SoD)를 구조로 강제한 것이다. SoD는 회계·감사 분야에서 1970년대부터 내려온 통제 원칙으로, NIST SP 800-53 AC-5에 명문화돼 있다. 로그를 적재하는 계정(Log Archive)과 그것을 분석하는 계정(Audit)을 나누는 것, 결제만 하는 Management 계정에 워크로드를 두지 않는 것 모두 SoD의 클라우드 구현이다.
Capital One(2019년 7월) — SSRF 취약점으로 EC2 메타데이터에서 과도한 권한의 IAM Role 자격증명이 탈취되어 1억 600만 명의 데이터가 유출됐다. 직접 원인은 WAF 설정과 과도한 S3 접근 권한이었지만, 사후 분석에서 "데이터 계정과 애플리케이션 계정이 충분히 분리되지 않아 한 Role이 너무 많은 버킷에 접근할 수 있었다"는 점이 지적됐다. 교훈: 계정·Role 경계를 좁게 나누면 한 자격증명이 탈취돼도 blast radius가 제한된다. 이 사고 후 AWS는 IMDSv2(2019)를 출시하고 SRA(Security Reference Architecture)에서 계정 분리를 강하게 권고했다.
Pro 시험은 AWS만 묻지만, 개념을 비교하면 본질이 또렷해진다.
| 개념 | AWS | Azure | GCP |
|---|---|---|---|
| 격리 단위 | Account | Subscription | Project |
| 조직 루트 | Organization | Tenant (Entra ID) | Organization |
| 그룹화 계층 | OU | Management Group | Folder |
| 정책 가드레일 | SCP / RCP | Azure Policy | Org Policy Constraints |
| ID 통합 | IAM Identity Center | Entra ID (네이티브) | Cloud Identity |
| 자동 랜딩존 | Control Tower | Landing Zone (CAF) | Landing Zone (Fabric) |
가장 큰 구조적 차이는 AWS는 계정이 "별도 청구·별도 quota·별도 리소스 네임스페이스"를 가진 1급 격리 경계라는 점이다. Azure의 Subscription도 비슷하지만, Azure는 Entra ID가 테넌트 전체에 걸쳐 ID를 네이티브로 관리해서 IDC 같은 별도 통합 계층이 덜 필요하다. GCP의 Project는 가장 가볍고 만들기 쉬워서 "리소스마다 프로젝트" 패턴이 흔하다. AWS에서 SCP가 "OU에 부착하는 default-deny ceiling"이라면, Azure Policy는 "리소스 속성을 평가하는 audit/deny 규칙"이라 평가 모델 자체가 다르다 — Azure Policy는 SCP보다 Config Rule(Detective)에 가깝다.
CreateAccount API는 비동기. DescribeCreateAccountStatus로 polling 필요.BoolIfExists 사용 (Bool은 키 없을 때 매칭 안 함).AWSReservedSSO_* Role 자동 생성.25번의 SCIM은 RFC 7644(System for Cross-domain Identity Management) 표준이고, 인증 프로토콜인 SAML 2.0은 OASIS 표준, IDC CLI가 쓰는 device authorization grant는 RFC 8628(OAuth 2.0 Device Authorization Grant)이다. 시험에서 "Okta 사용자를 50개 계정에 자동 동기화"라는 표현이 나오면 곧 SCIM(provisioning)이고, "로그인 흐름"은 SAML(authentication)이다. Provisioning(SCIM) ≠ Authentication(SAML) — 이 둘을 분리해서 봐야 보기에서 헷갈리지 않는다.
도메인 1 시나리오를 풀 때 4개 layer 순서대로 점검하면 빠진 요소가 보인다.
┌──────────────────────────────────────────────────┐
│ Layer 1: Org "계정을 어떻게 묶나?" │
│ - OU 설계 (Security/Infra/Workloads/Sandbox) │
│ - Management 계정 격리 │
│ - 신규 계정 자동화 (Account Factory / AFT) │
├──────────────────────────────────────────────────┤
│ Layer 2: SCP "OU 차원 금지 사항은?" │
│ - 리전 제한, root 차단, MFA 강제 │
│ - CloudTrail·GuardDuty 비활성화 차단 │
│ - Sandbox: 고비용 인스턴스 Deny │
│ - RCP: 외부 Principal 접근 차단 │
├──────────────────────────────────────────────────┤
│ Layer 3: Control Tower "가드레일은?" │
│ - Preventive (SCP 자동 부착) │
│ - Detective (Config Rule 자동) │
│ - Proactive (CFN Hook) │
│ - Log Archive Object Lock + Audit Master │
├──────────────────────────────────────────────────┤
│ Layer 4: IDC "직원 접근은?" │
│ - 외부 IdP(Okta/Azure AD) + SCIM │
│ - Permission Set + 세션 길이 │
│ - ABAC (대규모 프로젝트) │
│ - break-glass 패턴 │
└──────────────────────────────────────────────────┘
🔍 더 깊이: 4-layer는 단순한 암기 틀이 아니라 권한 평가의 실제 순서와 일치한다. 요청이 들어오면 AWS는 (1) 모든 상위 OU의 SCP를 위에서 아래로 교집합, (2) RCP(리소스 측), (3) Permission Boundary, (4) Identity Policy + Resource Policy + Session Policy를 종합한다. 이 중 하나라도 명시적 Deny면 즉시 거부, 어디에도 Allow가 없어도 거부(default-deny). Layer 1~2가 "OU 차원 ceiling"을 결정하고, Layer 4의 IDC Permission Set이 "그 ceiling 안에서 직원에게 실제로 무엇을 주나"를 결정한다. 그래서 "SCP는 막지 않는데 직원이 접근 못 한다"면 Permission Set(IDC) 쪽을, "Permission Set은 줬는데도 안 된다"면 상위 SCP를 의심하는 게 디버깅 순서다.
| A | B | 차이 |
|---|---|---|
| SCP vs IAM Policy | OU/계정 ceiling vs Principal 권한 | SCP는 Allow X |
| SCP vs Permission Boundary | OU 차원 vs IAM 차원 ceiling | PB는 한 Role/User에만 |
| SCP vs RCP | Principal 측 vs Resource 측 | 보완 관계 |
| Preventive vs Detective | 사전 차단(SCP) vs 사후 탐지(Config) | 보완 관계 |
| Account Factory vs AFT | 콘솔/베이스 vs Terraform IaC | GitOps는 AFT |
| CfCT vs AFT | CFN 기반 vs Terraform 기반 | IaC 도구 선택 |
| IDC vs Cognito | 직원·관리자 vs 고객 사용자 | 절대 헷갈리지 X |
| Permission Set vs IAM Role | IDC 추상화 vs 실제 Role | PS 매핑이 Role 자동 생성 |
| Log Archive vs Audit | 로그 적재 vs 보안 분석 마스터 | Object Lock S3는 Log Archive |
| Trusted Access vs Delegated Admin | 서비스 활성화 vs 운영 위임 | 둘 다 필요 |
| SCIM vs SAML | 사용자 프로비저닝 | 인증/로그인 |
| CAP 가용성 우선 vs 일관성 우선 | 멀티 리전 거버넌스 데이터 | 아래 박스 참조 |
마지막 행과 관련해 — Organizations의 SCP/정책 메타데이터는 글로벌 컨트롤 플레인에서 관리되고 멤버 계정에 전파(propagate)된다. 이는 CAP 정리에서 가용성(A)을 택한 eventually consistent 시스템이다. SCP를 변경하면 즉시가 아니라 수 초~수 분 안에 모든 계정에 적용된다. PACELC로 표현하면 "분할(P)이 없을 때도 지연(L)보다 가용성(A)을 우선"하는 PA/EL 시스템에 가깝다. 그래서 시험에서 "SCP 변경 직후 일부 계정에 즉시 반영 안 됨"이라는 묘사가 나오면 버그가 아니라 전파 지연으로 이해해야 한다.
⚠️ 함정: 도메인 1 보기에는 "그럴듯하지만 안티패턴"인 선택지가 항상 섞여 있다. 대표적 안티패턴 5종을 외워두면 소거법이 빨라진다.
- OU를 조직도(부서) 그대로 매핑 — OU는 "공통 SCP 단위"지 사람 조직이 아니다. 재무팀·인사팀으로 OU를 나누면 SCP가 의미 없이 쪼개진다.
- Management 계정에 워크로드/IAM User 운영 — 침해 시 SCP 보호가 전혀 없는 계정이 뚫린다.
- 각 계정마다 IAM User를 따로 만들고 수동 관리 — IDC + SCIM이 표준. 계정마다 User를 만들면 50개 계정 = 50배 관리 부담.
- SCP를 권한 부여 수단으로 착각 — SCP에 Allow를 넣어도 IAM 정책이 없으면 권한이 생기지 않는다.
- 거버넌스를 Config Rule(Detective)만으로 구현 — 탐지는 사후. 막아야 하는 규칙(리전 제한, 암호화 강제)은 Preventive(SCP)나 Proactive(CFN Hook)가 맞다.
🎯 시나리오: "한 스타트업이 빠르게 성장해 단일 계정에 Prod·Dev·CI/CD·데이터 분석이 모두 들어 있다. 보안팀이 멀티 계정 전환을 권고한다. 첫 단계로 가장 적절한 것은?" — 답: Control Tower로 Landing Zone을 세우고, 기존 단일 계정을 Workloads OU 아래로 초대(invite)한 뒤, 점진적으로 Prod/Dev/Security/Log Archive/Audit 계정을 분리. 한 번에 모든 걸 옮기려 하면 실패한다. 7R 마이그레이션 관점에서 이는 계정 단위의 "re-platform"에 가깝고, Account Factory로 신규 계정을 표준 베이스라인과 함께 찍어내는 게 핵심이다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
5개 OU·100개 계정. 일부 OU에 비인가 리전 사용 금지. Best?
문제 2
새 OU 생성 후 FullAWSAccess SCP 제거, Allow-list로 EC2만 허용. 그 계정에서 S3 호출은?
문제 3
Okta 사용자 + 50개 AWS 계정 + 콘솔/CLI SSO. 가장 적절한?
문제 4
신규 계정 생성 시 표준 베이스라인(CloudTrail, IAM Role, 태그) 자동 적용. Terraform 사용. Best?
문제 5
회사 정책: 모든 EBS는 KMS 암호화 필수. 배포 시도부터 차단. 어떤 가드레일?
문제 6
100개 계정의 CloudTrail 로그를 변경 불가능하게 한 곳에 모으려면?
문제 7
개발자 그룹이 자유롭게 실험할 OU. 비용 폭주 위험. Best?
문제 8
CFO가 부서별 비용을 분리 청구하려고 함. Best?
문제 9
CloudTrail을 누군가 비활성화하지 못하게 보장. Best?
문제 10
회사가 Org 가입 직후 Landing Zone 빠르게 갖추고 Audit·Log 표준 자동화. Best?
문제 11
한 SaaS가 회사 외부 Principal이 OU 안의 모든 S3 버킷에 접근하지 못하게 하려고 한다. 한 곳에서 정책으로 일괄 차단. Best?
문제 12
한 회사가 100개 프로젝트를 운영. 각 프로젝트마다 분리된 S3 버킷, EC2. 사용자는 자기 프로젝트 리소스에만 접근 가능해야 함. RBAC으로는 100 Role 폭발. 가장 적합한 패턴?
2주차는 도메인 1의 핵심 4종을 깊이 다뤘다. Organizations로 계정을 묶고, SCP로 천장을 정하고, Control Tower로 거버넌스를 자동화하고, IDC로 직원 SSO를 통합 — 이 4종이 멀티 계정 환경의 표준 스택이다. 오늘 추가로 본 것은 (1) 이 스택이 7~8년에 걸쳐 쌓인 계층이라는 역사적 맥락, (2) 계정 경계가 클라우드에서 가장 강한 fault containment region이라는 이론, (3) Capital One·Equifax·S3 public 사고가 왜 계정 분리와 SCP/RCP로 귀결되는가, (4) Azure Management Group·GCP Folder와의 대조다.
다음 주는 고급 네트워킹(Week 3)이다. VPC Peering vs Transit Gateway, Direct Connect 이중화, Site-to-Site VPN, PrivateLink 등 SAA에서 가볍게 본 네트워킹을 Pro 깊이로 다시 본다. 도메인 1·2에서 자주 출제되는 영역이고, "수천 VPC를 어떻게 묶나" 같은 시나리오가 본격 등장한다.
오늘 본 12문항을 다시 풀고, 틀린 문제는 4-layer 사고법(Org → SCP → CT → IDC)을 적용해 어디서 틀렸는지 확인하자. 시험장에서 손이 자동으로 4 layer를 그리는 순간이 도메인 1 합격의 신호다. 특히 "SCP인가 IDC인가", "Preventive인가 Detective인가", "SCIM인가 SAML인가"의 분별점을 손에 익혀두면 보기 소거가 빨라진다.
Week 3: 고급 네트워킹