멀티 계정 & 조직 관리

계정이 늘면 계정마다 보안 기준과 감사 방법을 수동으로 맞추기 어렵다. AWS Organizations는 계정 구조를 관리하고, SCP는 최대 권한 경계를 설정하며, Control Tower는 멀티 계정 환경의 초기 구성과 가드레일을 돕는다. 각 도구가 실제 권한을 부여하는지, 제한하거나 관측하는지 구분하는 것이 핵심이다.

---

1. 멀티 계정 전략의 이유

단일 계정 대신 멀티 계정을 사용하는 이유:

보안 격리:     계정 간 완전한 리소스 격리 (VPC 피어링 없으면 통신 불가)
폭발 반경 제한: 한 계정의 보안 사고가 다른 계정에 영향 없음
비용 추적:     계정별 비용 명확히 분리
서비스 한도:   계정별 독립적인 서비스 한도 (한 팀이 한도 소진해도 영향 없음)
규정 준수:     환경별(개발·스테이징·프로덕션) 완전 분리

일반적인 계정 구조

관리 계정 (Management Account)
  ├── 보안 OU
  │     ├── 로그 아카이브 계정
  │     └── 보안 도구 계정 (GuardDuty, Security Hub 중앙)
  ├── 인프라 OU
  │     ├── 공유 서비스 계정 (DNS, Directory)
  │     └── 네트워크 계정 (Transit Gateway, Direct Connect)
  ├── 개발 OU
  │     ├── 개발 계정
  │     └── 스테이징 계정
  └── 프로덕션 OU
        ├── 서비스 A 계정
        └── 서비스 B 계정

---

2. AWS Organizations

핵심 구조

루트 (Root)
  └── 조직 단위 (OU, Organizational Unit)
        └── 계정 (Account)

• 관리 계정: Organizations 생성·관리, 결제 통합, SCP 적용
• 멤버 계정: 실제 워크로드 실행, 관리 계정의 정책 적용
• OU: 계정을 논리적으로 그룹화, SCP를 OU 단위로 적용

주요 기능

통합 결제 (Consolidated Billing)

모든 멤버 계정 비용 → 관리 계정에서 통합 청구
  → 볼륨 할인 통합 (S3, EC2 사용량 합산)
  → RI / Savings Plans 공유 (기본 활성화)
  → 비용 배분 및 분석 용이

RI / Savings Plans 공유

계정 A: 사용하지 않는 RI 보유
계정 B: 온디맨드 EC2 실행 중
  → Organizations 내에서 RI 자동 공유 적용
  → 계정 B가 RI 할인 요금 적용
  → 공유 비활성화도 가능 (계정별 독립 관리)

위임된 관리자 (Delegated Administrator)

특정 서비스의 관리를 멤버 계정에 위임
  → 보안 계정이 GuardDuty, Security Hub 중앙 관리
  → 로그 계정이 CloudTrail, Config 중앙 관리
  → 관리 계정을 직접 사용하는 일 최소화

---

3. SCP (Service Control Policy)

핵심 개념

SCP는 OU 또는 계정에 적용되는 최대 권한 경계다. IAM 정책이 허용해도 SCP가 거부하면 실행 불가.

SCP: EC2 생성 허용
IAM 정책: EC2 생성 허용
→ EC2 생성 가능 ✓

SCP: us-east-1만 허용 (다른 리전 차단)
IAM 정책: 모든 리전 허용
→ us-east-1만 EC2 생성 가능

SCP는 관리 계정에 적용되지 않는다. 멤버 계정에만 적용.

SCP 작동 방식

루트 SCP ← OU SCP ← 계정 SCP ← IAM 정책
  → 모두 허용해야 최종 허용
  → 하나라도 거부하면 거부

기본 SCP (FullAWSAccess)

• Organizations 생성 시 루트에 기본 허용 SCP 자동 적용
• 제거하면 모든 계정에서 모든 권한 차단

SCP 주요 패턴

패턴 1: 리전 제한

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"]
    }
  }
}

패턴 2: 루트 계정 사용 차단

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalArn": "arn:aws:iam::*:root"
    }
  }
}

패턴 3: 특정 서비스 차단

{
  "Effect": "Deny",
  "Action": ["ec2:*", "rds:*"],
  "Resource": "*"
}
→ 개발 OU에서 고비용 서비스 차단

패턴 4: 태그 없는 리소스 생성 차단

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances"],
  "Resource": "*",
  "Condition": {
    "Null": {
      "aws:RequestTag/Environment": "true"
    }
  }
}

패턴 5: GuardDuty 비활성화 차단

{
  "Effect": "Deny",
  "Action": [
    "guardduty:DeleteDetector",
    "guardduty:DisassociateFromMasterAccount"
  ],
  "Resource": "*"
}

SCP vs IAM 정책 vs 권한 경계

구분	적용 대상	목적
SCP	계정·OU	계정 전체의 최대 권한 제한
IAM 정책	사용자·역할·그룹	특정 주체의 권한 부여
권한 경계 (Permission Boundary)	IAM 역할·사용자	특정 주체의 최대 권한 제한

---

4. AWS Control Tower

핵심 개념

Control Tower는 멀티 계정 환경을 빠르게 안전하게 구축하는 서비스다. AWS 모범 사례 기반의 **랜딩 존(Landing Zone)**을 자동으로 설정한다.

Control Tower 활성화
  → 자동 생성:
      관리 계정
      로그 아카이브 계정 (CloudTrail, Config 중앙 저장)
      감사 계정 (보안 알림, 감사)
      Core OU, Custom OU
  → 자동 적용:
      기본 SCP 세트
      필수 가드레일
      AWS SSO (IAM Identity Center) 설정

가드레일 (Guardrail)

가드레일은 계정에 자동으로 적용되는 규칙이다.

유형	구현 방식	예시
예방적 (Preventive)	SCP	루트 계정 사용 차단
탐지적 (Detective)	AWS Config 규칙	MFA 미설정 계정 탐지

필수 가드레일 (Mandatory): 비활성화 불가

• CloudTrail 비활성화 차단
• Config 비활성화 차단
• 로그 아카이브 계정 보호

강력 권고 가드레일 (Strongly Recommended): 활성화 권고

• MFA 없는 루트 계정 접근 탐지
• 공개 S3 버킷 탐지

선택적 가드레일 (Elective): 필요 시 활성화

• 특정 리전만 허용
• EC2 인스턴스 유형 제한

Account Factory

신규 계정 요청 → Account Factory
  → 미리 정의된 템플릿으로 계정 자동 생성
  → 올바른 OU에 배치
  → 가드레일 자동 적용
  → SSO 설정 자동 구성
  → VPC 기본 설정 적용

Account Factory for Terraform (AFT)

Terraform 코드로 계정 생성 자동화
  → GitOps 방식으로 계정 프로비저닝 관리
  → 계정 커스터마이징 자동 적용

---

5. AWS Config

핵심 개념

AWS Config는 AWS 리소스의 설정 변경을 지속적으로 기록하고 규정 준수 여부를 평가한다.

리소스 설정 변경 → Config가 자동 기록
  → Configuration Item (스냅샷)
  → S3에 저장 (장기 보존)
  → Config 규칙으로 평가
    → 규정 준수 / 미준수 판정
      → 자동 수정 (Remediation)

Config 규칙

AWS 관리형 규칙 (사전 정의)

s3-bucket-public-read-prohibited  — S3 공개 읽기 차단 여부
ec2-instance-no-public-ip         — EC2 공인 IP 없음 여부
mfa-enabled-for-iam-console-access — MFA 활성화 여부
rds-instance-public-access-check  — RDS 공개 접근 차단 여부
encrypted-volumes                 — EBS 암호화 여부

커스텀 규칙

Lambda 함수로 직접 평가 로직 작성
  → 특정 태그 필수 여부
  → 커스텀 네이밍 규칙 준수 여부

자동 수정 (Remediation)

Config 규칙 위반 탐지
  → Remediation Action 자동 실행
    → SSM Automation Runbook 실행
      예: S3 공개 접근 차단 자동 적용
          EC2 태그 자동 추가
          보안 그룹 규칙 자동 수정

Config Aggregator

멀티 계정·멀티 리전 Config 데이터 중앙 집계
  → 조직 전체 규정 준수 현황 한눈에 파악
  → 계정별·리전별·규칙별 준수율 대시보드

CloudTrail vs Config 차이

항목	CloudTrail	Config
기록 대상	API 호출 (누가 무엇을 했는가)	리소스 설정 상태 (지금 어떤 상태인가)
목적	감사, 보안 조사	규정 준수, 설정 변경 추적
질문	"누가 이 설정을 바꿨는가?"	"이 리소스가 규정을 준수하는가?"

두 서비스를 함께 사용: Config로 규정 위반 탐지 → CloudTrail로 누가 변경했는지 추적

---

6. IAM Identity Center (구 AWS SSO)

핵심 개념

IAM Identity Center는 여러 AWS 계정에 대한 중앙 집중식 접근 관리를 제공한다. 한 번 로그인으로 여러 계정에 역할 기반으로 접근한다.

사용자
  → IAM Identity Center (SSO 포털)
    → 계정 A (개발자 역할)
    → 계정 B (읽기 전용 역할)
    → 계정 C (관리자 역할)

자격 증명 소스

• Identity Center 자체 디렉터리
• Active Directory (AWS Managed AD or 온프레미스 AD)
• 외부 IdP (Okta, Azure AD 등, SAML 2.0)

권한 세트 (Permission Set)

권한 세트 "개발자" = AdministratorAccess (개발 계정)
권한 세트 "읽기전용" = ViewOnlyAccess (프로덕션 계정)

사용자/그룹 → 권한 세트 → 계정 매핑
  → 개발팀 그룹 → 개발자 권한 세트 → 개발 계정
  → 개발팀 그룹 → 읽기전용 권한 세트 → 프로덕션 계정

---

7. Service Catalog

핵심 개념

Service Catalog는 조직이 승인한 IT 서비스 목록을 사용자가 셀프 서비스로 배포하게 한다.

관리자 (포트폴리오 구성)
  → CloudFormation 템플릿 등록
  → 승인된 EC2, RDS, VPC 구성 정의
  → 사용자 그룹에 포트폴리오 공유

사용자 (셀프 서비스)
  → Service Catalog 포털
    → 승인된 제품 목록 조회
    → 선택 → 자동 배포
    → IAM 권한 없이도 승인된 리소스만 생성 가능

핵심 장점

• 거버넌스: 승인된 구성만 배포 가능 (임의 리소스 생성 방지)
• 표준화: 모든 팀이 동일한 검증된 구성 사용
• 속도: 셀프 서비스로 대기 없이 즉시 배포

---

8. 거버넌스 아키텍처 패턴

패턴 1: 중앙 집중식 보안 모니터링

각 멤버 계정
  ├── GuardDuty → 위협 탐지
  ├── Security Hub → 보안 점수
  └── Config → 규정 준수

위임된 관리자 (보안 계정)
  ├── GuardDuty 중앙 관리자 (전체 계정 위협 통합)
  ├── Security Hub 중앙 (전체 계정 보안 점수 통합)
  └── Config Aggregator (전체 계정 규정 준수 현황)

패턴 2: 중앙 로깅

각 멤버 계정
  ├── CloudTrail → S3 (로그 아카이브 계정)
  └── Config → S3 (로그 아카이브 계정)

로그 아카이브 계정
  └── S3 (볼트 잠금, 삭제 방지)
        → Athena로 중앙 분석

패턴 3: 네트워크 중앙화

네트워크 계정
  ├── Transit Gateway (모든 VPC 허브)
  ├── Direct Connect (온프레미스 연결)
  └── 공유 VPC (Shared VPC)

각 멤버 계정
  → RAM (Resource Access Manager)으로 공유 VPC 서브넷 사용
  → 자체 VPC 없이 중앙 네트워크 사용

패턴 4: 신규 계정 자동 거버넌스

Control Tower Account Factory → 신규 계정 생성
  → 자동 적용:
      ├── SCP (리전 제한, 보안 정책)
      ├── Config 규칙 (기본 규정 준수)
      ├── CloudTrail (중앙 로그 전송)
      ├── GuardDuty (위협 탐지 활성화)
      └── IAM Identity Center (SSO 접근)

패턴 5: 비용 거버넌스

Organizations 통합 결제
  → Cost Explorer (계정별 비용 분석)
  → Budgets (계정별 예산 설정, 초과 시 SCP로 차단)
  → 태그 정책 (필수 태그 강제)
    → 태그 없는 리소스 생성 차단 (SCP)

---

9. 핵심 암기 포인트

키워드	선택
계정 전체 최대 권한 제한	SCP
SCP vs IAM	SCP는 계정 경계, IAM은 주체 권한
SCP 적용 안 되는 계정	관리 계정 (Management Account)
멀티 계정 랜딩 존 자동 구성	Control Tower
계정 내 보안 정책 (예방적)	SCP (가드레일)
계정 내 규정 준수 탐지 (탐지적)	Config 규칙 (가드레일)
리소스 설정 변경 기록·준수 평가	AWS Config
API 호출 감사 로그	CloudTrail
멀티 계정 Config 중앙 집계	Config Aggregator
여러 계정 싱글 사인온	IAM Identity Center (SSO)
승인된 리소스만 셀프 서비스 배포	Service Catalog
신규 계정 자동 프로비저닝	Account Factory (Control Tower)
계정 간 비용 통합·RI 공유	Organizations 통합 결제
VPC·TGW·서브넷 계정 간 공유	Resource Access Manager (RAM)
GuardDuty 전체 계정 중앙 관리	위임된 관리자 (보안 계정)

---

핵심 내용을 다시 정리하면

• Organizations: 계정을 OU로 그룹화, 통합 결제·RI 공유, 위임된 관리자
• SCP: 계정의 최대 권한 경계, 관리 계정에는 미적용, IAM 정책보다 우선
• Control Tower: 랜딩 존 자동 구성, 가드레일(예방적=SCP, 탐지적=Config), Account Factory
• Config: 리소스 설정 기록·준수 평가·자동 수정, Aggregator로 중앙 집계
• IAM Identity Center: 멀티 계정 SSO, 권한 세트로 역할 기반 접근
• Service Catalog: 승인된 서비스만 셀프 배포, 거버넌스 + 속도 동시 확보

이어 읽기: 18. 데이터 분석 파이프라인과 서비스 선택