Day 1 - 공동 책임 모델과 SCS-C03 6개 도메인: 보안 엔지니어의 큰 그림

보안 자격증을 처음 준비하는 사람의 절반은 "AWS 보안 = IAM 정책 잘 쓰기"라고 생각한다. 그렇게 들어가면 SCS-C03의 시나리오 문제 앞에서 무너진다. 이 시험이 측정하는 것은 정책 문법이 아니라 **"이 위협을 어느 계층에서, 누가 책임지고, 어떤 통제로 막는가"**라는 사고의 틀이다. 그 틀의 두 기둥이 공동 책임 모델(Shared Responsibility Model)과 6개 시험 도메인이다.

오늘은 도구 하나도 깊이 파지 않는다. 대신 앞으로 12주 동안 만날 모든 서비스가 어디에 놓이는지를 가늠하는 지도를 그린다. GuardDuty, KMS, IAM, WAF, Macie, Config — 이 이름들이 각각 "어떤 책임 경계의 어떤 통제 유형"인지가 머리에 자리잡으면, 시나리오 문제에서 정답 보기와 함정 보기가 자연스럽게 갈라진다.

공동 책임 모델: "of the cloud" vs "in the cloud"

AWS의 공동 책임 모델은 한 문장으로 요약된다. AWS는 "클라우드 자체(of the cloud)"의 보안을, 고객은 "클라우드 안(in the cloud)"의 보안을 책임진다. 추상적으로 들리지만 경계선은 의외로 칼같다.

핵심 통찰은 이 경계가 서비스 유형에 따라 움직인다는 점이다. 같은 "패치"라는 단어도 EC2에서는 고객의 일이고 Fargate에서는 AWS의 일이다. 그래서 공동 책임 모델은 통째로 외우는 표가 아니라 경계선을 직접 그어 보는 연습으로 익혀야 한다. 아래 그림에서 굵은 이중선이 서비스 유형에 따라 어떻게 위아래로 움직이는지를 보라.

[ 책임 경계선은 서비스 유형에 따라 위아래로 움직인다 ]

  스택 층              EC2(IaaS)   RDS·ECS on EC2   Lambda·Fargate   S3·DynamoDB
 ───────────────────────────────────────────────────────────────────────────────
  데이터 분류·소유       고객          고객              고객             고객
  암호화 사용 여부 결정   고객          고객              고객             고객
  IAM · 접근제어         고객          고객              고객             고객
 ═══════════════════════════════════════════════════════════════════════════════
  애플리케이션 코드      고객          고객              고객              —
 ───────────────────────────────────────────────────────────────────────────────
  런타임 · 라이브러리    고객          고객           고객(레이어)         AWS
 ───────────────────────────────────────────────────────────────────────────────
  미들웨어 · DB 엔진     고객          AWS               AWS              AWS
 ───────────────────────────────────────────────────────────────────────────────
  게스트 OS · OS 패치    고객          AWS               AWS              AWS
 ───────────────────────────────────────────────────────────────────────────────
  하이퍼바이저 · 가상화   AWS          AWS               AWS              AWS
  물리 서버 · 스토리지    AWS          AWS               AWS              AWS
  데이터센터 · 출입통제   AWS          AWS               AWS              AWS

  ▲ 이중선 위 세 줄(데이터·암호화 결정·접근제어)은 **어떤 서비스에서도 고객 책임**이다.
    경계선이 아무리 아래로 내려가도 이 세 줄만은 AWS로 넘어가지 않는다.
    이중선 아래는 서비스를 오른쪽으로 옮길수록 AWS 쪽으로 밀려 내려간다.

• IaaS (EC2): 고객 책임이 가장 크다. 게스트 OS 패치, 미들웨어, 호스트 방화벽까지 전부 고객 몫. AWS는 하이퍼바이저 아래만 책임진다.
• PaaS (RDS, ECS on EC2): AWS가 엔진·OS 패치를 맡고, 고객은 데이터·접근제어·암호화 설정과 유지보수 윈도우 승인을 책임진다.
• 서버리스 (Lambda, Fargate): 실행 환경 OS·런타임 패치까지 AWS가 맡는다. 고객에게 남는 것은 코드, 함수의 IAM 실행 역할, 그리고 함수가 만지는 데이터다.
• SaaS 성격 (S3, DynamoDB): AWS가 인프라 거의 전부를 맡고, 고객은 데이터 분류와 접근제어만 책임진다. 그래도 데이터 책임은 절대 AWS로 넘어가지 않는다.

서비스별로 자주 헷갈리는 항목만 따로 뽑으면 다음과 같다. 시험에서 "누구의 책임인가"를 묻는 문항은 거의 이 표 안에서 나온다.

🔍 더 깊이: 공동 책임 모델에는 표에 잘 안 나오는 세 번째 칸이 있다. AWS가 "제어(control)를 공유한다"고 부르는 영역으로, 패치 관리·구성 관리·인식 교육 같은 항목이 여기 속한다. 예를 들어 패치 관리는 AWS가 인프라를 패치하고 고객이 게스트 OS·애플리케이션을 패치하는 양쪽 다 있는 항목이다. 구성 관리도 AWS가 인프라 구성 표준을 유지하고 고객이 자기 리소스 구성을 책임진다. 시험에서 "AWS와 고객이 함께 책임지는 영역"이라는 표현이 보기에 등장하면 이 세 항목 중 하나를 가리킬 가능성이 높다.

⚠️ 함정: "AWS가 관리형 서비스를 쓰면 규정 준수도 대신 해 준다"는 서술은 항상 오답이다. AWS는 자기 인프라에 대한 감사 보고서(SOC, ISO, PCI 등)를 AWS Artifact로 제공할 뿐이다. 고객 워크로드가 PCI DSS를 만족하는지는 고객이 증명해야 한다. AWS Artifact는 "AWS 쪽 증거를 내려받는 창구"이지 "우리 시스템이 준수한다는 증서"가 아니다. 이 구분이 도메인 6(거버넌스)에서 반복해 나온다.

💡 관련 이론: 이것을 "shifting line of responsibility"라고 부른다. 같은 "패치"라도 EC2의 OS 패치는 고객 책임이지만 Fargate의 OS 패치는 AWS 책임이다. 시험에서 "누구의 책임인가"를 묻는 문제는 거의 항상 서비스가 IaaS/PaaS/SaaS 중 무엇인지를 먼저 판정하면 풀린다. "Lambda 함수의 OS를 패치하라"는 보기는 함정이다 — Lambda 런타임 OS는 AWS가 패치한다.

⚠️ 함정: S3 데이터 유출 사고에서 "AWS가 책임진다"는 보기는 항상 오답이다. S3의 내구성·가용성은 AWS 책임이지만, 버킷을 public으로 열어둔 설정(접근제어)은 100% 고객 책임이다. Capital One 사고(2019)도 S3 자체가 뚫린 게 아니라 고객 측 IAM·WAF 설정 오류였다.

통제의 3가지 유형: 예방·탐지·대응

보안 엔지니어는 모든 통제를 세 범주로 분류하는 습관을 들여야 한다. SCS-C03의 도메인 구조 자체가 이 분류를 따라간다.

🔍 더 깊이: 성숙한 보안 아키텍처는 세 유형을 계층적으로(defense in depth) 쌓는다. 예방이 뚫려도 탐지가 잡고, 탐지가 늦어도 대응이 피해를 줄인다. 시험에서 "이 위협을 막을 가장 좋은 방법"을 물을 때, 단일 통제만 고른 보기보다 "예방 + 탐지 + 자동 대응"을 조합한 보기가 정답인 경우가 많다. 단, "가장 먼저(first/immediate)"를 물으면 보통 예방 통제(SCP, 키 정책)가 답이다.

세 유형을 고르는 기준은 문항의 동사에 숨어 있다. 시험 문장에서 다음 표현을 보면 답의 방향이 거의 정해진다.

예방 통제는 대개 정책 문서 한 장으로 표현된다. 아래는 오늘 이후 계속 만나게 될 두 가지 형태의 예방 통제 실물이다. 하나는 조직 전체에 거는 SCP(계정 단위 상한), 다른 하나는 리소스 자신에 붙이는 버킷 정책이다. 둘 다 "금지"를 표현하므로 Deny로 쓴다.

// ① SCP — 조직 차원의 예방 통제: 누구도 CloudTrail을 끄지 못한다
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectAuditTrail",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "cloudtrail:UpdateTrail"
    ],
    "Resource": "*"
  }]
}

// ② S3 버킷 정책 — 리소스 자신에 붙는 예방 통제: 평문 전송 금지
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyInsecureTransport",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::audit-evidence",
      "arn:aws:s3:::audit-evidence/*"
    ],
    "Condition": {
      "Bool": { "aws:SecureTransport": "false" }
    }
  }]
}

두 문서의 차이를 지금 눈으로 익혀 두자. ①에는 Principal이 없고 ②에는 있다. 정책이 "주체 쪽"에 붙으면 주체를 적을 필요가 없고, "리소스 쪽"에 붙으면 누가 오는지를 반드시 적어야 한다. 이 대칭이 Day 2·3에서 다룰 Identity 정책 대 Resource 정책 구분의 뿌리다.

⚠️ 함정: 통제 유형을 섞어 놓은 보기가 시험의 단골 오답이다. "GuardDuty로 미암호화 업로드를 차단한다", "Config 규칙으로 퍼블릭 버킷을 막는다" 같은 문장은 서비스 이름은 맞지만 동사가 틀렸다. GuardDuty와 Config는 탐지·평가 도구이지 요청을 막는 도구가 아니다. Config는 규칙 위반을 "NON_COMPLIANT"로 표시할 뿐이고, 실제로 되돌리려면 remediation 액션(SSM Automation)을 붙여야 한다 — 그리고 그 순간 그것은 예방이 아니라 대응이다. 서비스 이름이 아니라 "요청 시점에 막는가, 사후에 알아채는가"로 판정하라.

SCS-C03이 측정하는 6개 도메인

2024년 개정된 SCS-C03은 65문항, 170분, 750/1000점 합격 기준이다. 시험 청사진(exam guide)은 6개 도메인과 가중치를 명시한다.

가중치를 보면 **도메인 3(인프라 20%) + 도메인 2(로깅 18%) + 도메인 5(데이터 18%)**가 시험의 절반 이상이다. 하지만 도메인 4(IAM 16%)는 다른 모든 도메인의 전제다. KMS 키 정책도 IAM 평가 로직 위에서 동작하고, cross-account 로깅도 AssumeRole 위에서 동작한다. 그래서 Week 1을 IAM에 통째로 할당하는 것이다.

💡 관련 이론: 도메인은 따로 외우는 6개의 과목이 아니라 하나의 사고 흐름이다. 위협이 들어온다(D1 탐지) → 그게 보이려면 로그가 있어야 하고(D2) → 들어오는 길목은 네트워크(D3) → 그 안에서 권한은 IAM(D4) → 보호 대상은 데이터(D5) → 이 모든 걸 조직 차원에서 강제(D6). 시나리오 문제는 보통 2-3개 도메인을 한 묶음으로 엮는다.

도메인마다 "이 도메인이면 이 서비스"라는 앵커가 있다. 12주 학습의 지도 역할을 하는 표이니, 지금 완벽히 이해할 필요는 없고 이름과 소속만 눈에 익혀 두면 된다. 각 주차가 진행되면서 이 칸들이 하나씩 채워진다.

가중치를 보면 **도메인 3(인프라 20%) + 도메인 2(로깅 18%) + 도메인 5(데이터 18%)**가 시험의 절반 이상이다. 하지만 도메인 4(IAM 16%)는 다른 모든 도메인의 전제다. 이 구조를 그림으로 그리면 IAM이 왜 첫 주인지가 분명해진다.

[ 6개 도메인은 층이 아니라 사슬이다 ]

        D6 관리·거버넌스 (조직 전체에 강제)
   ┌──────────────────────────────────────────────┐
   │   D1 위협 탐지  ◀── 신호 ──  D2 로깅·모니터링 │
   │        │                          ▲          │
   │      대응                       기록          │
   │        ▼                          │          │
   │   D3 인프라 보안 ── 통과 요청 ──▶ D4 IAM      │
   │   (어디로 들어오나)              (누구인가)   │
   │                                    │          │
   │                                  판정          │
   │                                    ▼          │
   │                            D5 데이터 보호      │
   │                            (무엇을 지키나)     │
   └──────────────────────────────────────────────┘

   D4는 다른 다섯 도메인 전부의 "판정 엔진"이다.
   · KMS 키 정책(D5)도 IAM 평가 위에서 동작
   · 교차 계정 로그 수집(D2)도 AssumeRole 위에서 동작
   · SCP 가드레일(D6)도 IAM 평가의 한 층
   · GuardDuty 위임 관리자(D1)도 IAM 신뢰 관계 위에서 동작

그래서 Week 1을 IAM에 통째로 할당한다. IAM을 대충 넘기면 나머지 11주 내내 "왜 이 접근이 막히는지"를 매번 새로 배우게 된다.

시험의 형태를 미리 알아 두기

시험은 65문항 170분, 750/1000점이 합격선이다. 산술적으로 한 문항에 약 2분 36초가 주어지는데, SCS-C03의 문항은 지문이 길다. 대여섯 줄짜리 상황 설명과 네 개의 긴 보기를 읽는 것만으로 1분이 지나간다. 그래서 이 시험은 "아는가"만큼이나 **"빨리 판정할 수 있는가"**를 묻는다.

빠른 판정의 요령은 지문을 처음부터 정독하지 않는 것이다. 먼저 **마지막 문장(무엇을 묻는가)**을 읽고, 그 다음 보기를 훑어 축을 잡은 뒤, 지문에서 그 축에 해당하는 단서만 찾는다. 예를 들어 마지막 문장이 "prevent"로 끝나면 탐지 서비스가 든 보기 두 개는 지문을 읽기 전에 이미 후보에서 내려간다.

⚠️ 함정: "가장 안전한 방법"과 "가장 운영 부담이 적은 방법"이 다른 보기를 가리키는 문항이 자주 나온다. 이때 정답은 문항이 명시한 기준 쪽이다. 보안 시험이라고 무조건 가장 엄격한 보기를 고르면 "least operational overhead" 문항에서 틀린다. 반대로 편의 위주로 고르면 "most secure" 문항에서 틀린다. 문항 마지막 줄의 형용사가 채점 기준이라는 것을 잊지 말아야 한다.

데이터 분류와 최소 권한: 보안 사고의 두 출발점

실무에서 보안 사고의 근본 원인을 추적하면 거의 항상 두 가지로 귀결된다. 하나는 데이터를 분류하지 않아서 무엇을 얼마나 보호해야 하는지 몰랐던 것, 다른 하나는 과도한 권한이다.

데이터 분류(data classification)는 보호 통제의 출발점이다. PII·결제 정보·헬스 데이터는 어디에 있는가? Amazon Macie가 S3의 민감 데이터를 ML로 자동 분류하는 이유가 여기 있다. 분류 없이는 "이 버킷에 KMS 암호화가 필요한가"라는 질문에 답할 수 없다.

데이터 분류는 보통 3~4단계로 나눈다. 단계 이름은 조직마다 다르지만, 중요한 것은 각 단계에 어떤 통제가 자동으로 따라붙는가를 미리 정해 두는 것이다. 분류가 통제를 결정해야지, 담당자의 판단이 매번 통제를 결정하면 일관성이 깨진다.

이 표가 있으면 "이 버킷에 KMS가 필요한가"라는 질문이 판단이 아니라 조회가 된다. Amazon Macie가 S3의 민감 데이터를 자동으로 찾아 분류하는 이유도 여기에 있다 — 사람이 수천 개 버킷을 분류할 수는 없기 때문이다.

최소 권한(least privilege)은 도메인 4의 심장이지만 모든 도메인에 스며 있다. KMS 키 정책의 최소 권한, S3 버킷 정책의 최소 권한, SCP의 최소 권한. **"권한을 줄 때는 명시적으로, 회수할 때는 기본값으로"**가 IAM 평가 로직의 철학이다(이건 Day 2에서 깊이 본다).

💡 관련 이론: 데이터 분류와 최소 권한은 사실 같은 원칙의 양면이다. 분류는 "이 자산이 얼마나 중요한가"를 정하고, 최소 권한은 "그 중요도에 비례해 접근을 좁힌다"를 실행한다. 보안 공학에서는 이 짝을 자산 중심 위험 관리라고 부른다. 위협 목록에서 출발하면 끝이 없지만(공격 기법은 무한하다), 자산 목록에서 출발하면 유한하다. SCS-C03의 시나리오가 거의 항상 "무엇이 유출됐다/유출될 수 있다"로 시작하는 것도 같은 이유다 — 자산을 먼저 특정해야 통제를 고를 수 있다.

🎯 시나리오: "감사팀이 '우리 조직 전체에서 신용카드 번호가 어느 S3 버킷에 있는지 목록을 달라'고 요구했다. 계정은 40개, 버킷은 2,000개가 넘는다." → 사람이 훑는 방법을 고른 보기는 전부 탈락이다. 정답 방향은 Macie를 조직 단위로 활성화하고(Security Tooling 계정을 위임 관리자로 지정) 민감 데이터 검색 작업을 돌려 발견 사항을 Security Hub로 모으는 것이다. 여기서 도메인 5(데이터)·도메인 2(가시성)·도메인 6(조직 차원 위임)이 한 문항 안에서 만난다. 도메인이 사슬이라는 말이 이런 뜻이다.

📚 사례: 2017년 다수의 기업이 S3 버킷을 public-read로 열어둔 채 PII를 저장해 대형 유출이 잇따랐다(Verizon, Accenture 등). AWS는 이 패턴을 막으려 2018년 S3 Block Public Access를 도입했고, 2023년부터는 신규 버킷에 기본 활성화했다. 이것이 "예방 통제를 플랫폼 기본값으로 강제"하는 거버넌스(도메인 6)의 전형이다.

멀티 계정과 거버넌스: 보안의 blast radius

보안 엔지니어가 단일 계정 사고방식에서 벗어나야 하는 이유는 폭발 반경(blast radius) 때문이다. 한 계정이 뚫려도 다른 환경으로 번지지 않게 하려면 계정을 경계로 써야 한다.

표준 멀티 계정 보안 구조는 다음과 같다.

[ AWS Organizations 보안 기준 구조 ]

  Management 계정 (billing + SCP 관리, 워크로드 금지)
        |
   +----+----+----------------+--------------+
   |         |                |              |
 Security OU  Infrastructure  Workloads OU   Sandbox OU
   |              OU            (Prod/NonProd)
   +-- Log Archive 계정 (CloudTrail/Config 로그 불변 저장)
   +-- Audit/Security Tooling 계정 (GuardDuty·SecurityHub 위임 관리자)

• Log Archive 계정: 모든 계정의 CloudTrail·Config 로그를 중앙 집중, S3 Object Lock으로 변조 방지. 사람이 거의 로그인하지 않는다.
• Security Tooling 계정: GuardDuty·Security Hub·Detective의 delegated administrator(위임 관리자). 조직 전체의 보안 신호를 한곳에서 본다.
• SCP: 권한을 주는 게 아니라 **상한선(guardrail)**을 deny로 긋는다. root에도 적용된다(management 계정 root 예외).

🔍 더 깊이: GuardDuty·Security Hub·Macie·Config 모두 "delegated administrator" 패턴을 지원한다. management 계정에서 직접 운영하지 않고 Security Tooling 계정에 위임하는 것이 모범 사례다. 이유는 최소 권한 — management 계정은 billing·조직 관리만 하고, 보안 운영 권한까지 거기 몰아넣으면 그 계정이 뚫렸을 때 조직 전체가 무너진다.

이 구조에서 실제로 데이터가 어떻게 흐르는지를 한 장으로 보면, 왜 계정을 이렇게 나누는지가 훨씬 선명해진다.

[ 로그와 보안 신호의 흐름 — 방향이 한쪽으로만 흐른다 ]

  Workloads OU                Security OU
  ┌──────────────┐
  │ Prod 계정 A  │──CloudTrail──┐
  │  · CloudTrail│──Config──────┤
  │  · Config    │──VPC Flow────┤
  │  · GuardDuty │──Findings──┐ │
  └──────────────┘            │ │
  ┌──────────────┐            │ │      ┌────────────────────────┐
  │ Prod 계정 B  │──로그──────┼─┼─────▶│ Log Archive 계정        │
  │  ...         │            │ │      │  S3 + Object Lock       │
  └──────────────┘            │ │      │  KMS 키는 이 계정 소유   │
  ┌──────────────┐            │ │      │  사람 로그인 거의 없음   │
  │ Dev 계정 C   │──로그──────┼─┴─────▶│  쓰기 전용 · 삭제 불가   │
  └──────────────┘            │        └────────────────────────┘
                              │
                              │        ┌────────────────────────┐
                              └───────▶│ Security Tooling 계정   │
                                       │  GuardDuty 위임 관리자   │
                                       │  Security Hub 집계       │
                                       │  Macie · Detective       │
                                       │  사고 대응 롤 여기서 발급 │
                                       └────────────────────────┘

  핵심 성질 세 가지
  ① 흐름이 **단방향**이다. 워크로드 계정은 로그를 쓸 수만 있고 읽거나 지울 수 없다.
  ② 로그 저장 계정과 분석 계정을 **분리**한다. 분석 도구가 뚫려도 증거는 남는다.
  ③ 로그 버킷의 KMS 키를 **Log Archive 계정이 소유**한다.
     워크로드 계정 관리자가 키를 지워 증거를 무력화하는 경로를 막는다.

이 그림의 세 성질은 전부 하나의 가정에서 나온다 — 워크로드 계정은 언젠가 뚫린다. 침해된 계정의 관리자 권한을 공격자가 쥐었을 때도 증거가 남아 있어야 조사가 가능하다. 그래서 로그는 "다른 계정에, 쓰기 전용으로, 지울 수 없게" 보관한다. 이것이 도메인 2와 도메인 6이 만나는 지점이고, Week 후반에 CloudTrail 조직 트레일과 S3 Object Lock으로 다시 만난다.

현재 계정이 조직 안에서 어디에 있는지는 CLI로 바로 확인할 수 있다. 보안 작업의 첫 줄은 언제나 "내가 지금 어느 계정, 어느 신원인가"다.

# ① 지금 나는 누구인가 — 모든 디버깅의 출발점
aws sts get-caller-identity
# {
#   "UserId":  "AROAEXAMPLEID:alice@example.com",
#   "Account": "111122223333",
#   "Arn":     "arn:aws:sts::111122223333:assumed-role/SecurityAudit/alice@example.com"
# }
 
# ② 이 계정이 속한 조직 정보 (관리 계정 ID·기능 집합 확인)
aws organizations describe-organization
 
# ③ 조직의 계정 목록과 OU 구조
aws organizations list-accounts
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-exam
 
# ④ 이 계정에 실제로 적용 중인 SCP 확인
aws organizations list-policies-for-target \
  --target-id 111122223333 \
  --filter SERVICE_CONTROL_POLICY
 
# ⑤ 보안 서비스의 위임 관리자가 누구인지 확인
aws organizations list-delegated-administrators

⚠️ 함정: aws sts get-caller-identity의 출력에서 Arn이 assumed-role/... 형태이면 역할을 맡은 상태이고, user/... 형태이면 IAM 사용자 장기 자격 증명이다. 실무 사고의 상당수가 "당연히 역할로 접근 중이라고 믿었는데 실은 오래된 액세스 키였다"에서 시작한다. 그리고 describe-organization은 조직에 속한 계정에서만 성공한다 — 이 명령이 실패한다면 그 계정은 Organizations 멤버가 아니고, 따라서 SCP가 아예 적용되지 않는다. "SCP를 걸었는데 안 먹는다"의 첫 번째 확인 사항이다.

통제를 도메인·유형으로 매핑하는 연습

오늘 배운 두 축(통제 유형 × 책임 경계)으로 주요 서비스를 분류해보자. 이 표가 머리에 있으면 시나리오 문제의 보기를 빠르게 거를 수 있다.

🎯 시나리오: "S3 버킷에 PII가 암호화 없이 저장돼 있다는 사실을 사후에 알게 됐다. 재발을 막을 통제 조합은?" 단일 답이 아니다. 탐지(Macie로 민감 데이터 발견 + Config rule s3-bucket-server-side-encryption-enabled) + 예방(SCP로 미암호화 PutObject 차단, S3 Block Public Access) + 대응(EventBridge → Lambda로 자동 암호화/격리). 세 유형을 한 번에 떠올리는 게 SCS-C03의 사고법이다.

위협을 통제로 번역하는 연습

지도만 그려 놓고 끝내면 시험장에서 쓰이지 않는다. 오늘의 두 축(책임 경계 × 통제 유형)을 실제 위협에 대보는 연습을 한 번 해 두자. 아래는 SCS-C03에서 반복해 등장하는 위협 다섯 가지를 두 축으로 분해한 것이다. 각 행을 왼쪽에서 오른쪽으로 읽으면 그것이 곧 답안의 뼈대가 된다.

이 표의 오른쪽 세 칸이 대부분 비어 있는 조직이 실제로 매우 많다. 예방만 걸어 두고 탐지·대응을 만들지 않으면, 예방이 뚫린 순간부터 사고는 아무도 모르는 채로 진행된다. 시험에서 "이미 사고가 발생했다"는 지문이 나오면 예방 통제만 나열한 보기는 대개 오답이다 — 이미 일어난 일에는 탐지와 대응이 필요하다.

🎯 시나리오: "한 계정에서 평소 쓰지 않던 리전에 EC2 인스턴스 수십 대가 갑자기 생성됐다는 청구서를 보고 알게 됐다. 재발 방지 대책은?" → 청구서로 알게 됐다는 문장이 핵심 단서다. 탐지 계층이 아예 없었다는 뜻이다. 그러니 답은 세 겹이어야 한다. 예방으로 승인 리전 외 사용을 SCP로 막고, 탐지로 GuardDuty와 CloudTrail 기반 경보를 붙이고, 대응으로 EventBridge에서 자동 격리·알림을 건다. 여기에 근본 원인(어떻게 자격 증명이 유출됐는가)까지 짚어야 완성이다. 단일 통제만 고른 보기는 "재발 방지"라는 요구를 만족하지 못한다.

정리하며 — 앞으로의 지도

오늘 그린 그림 세 가지를 새기자. 첫째, 공동 책임 모델은 서비스 유형(IaaS/PaaS/SaaS)에 따라 책임선이 움직이며, 데이터와 접근제어는 어떤 경우에도 고객 책임이다. 둘째, 모든 통제는 예방·탐지·대응 세 유형으로 분류되고, 성숙한 아키텍처는 셋을 계층으로 쌓는다. 셋째, 6개 도메인은 따로 외우는 과목이 아니라 위협 → 가시성 → 네트워크 → 신원 → 데이터 → 거버넌스로 흐르는 하나의 사고 사슬이다.

📚 사례: 2019년 공개된 Capital One 침해는 오늘 배운 두 축이 실제 사고에서 어떻게 맞물리는지를 보여 준다. 공격자는 잘못 구성된 웹 애플리케이션 방화벽을 통해 SSRF로 EC2 인스턴스 메타데이터에 접근했고, 그 인스턴스 역할의 임시 자격 증명을 얻어 S3 버킷의 데이터를 내려받았다. 미국·캐나다 신용카드 신청자 약 1억 명 규모의 정보가 영향을 받았다. 여기서 공동 책임 모델의 어느 쪽이 뚫렸는지 보라 — 전부 고객 책임 영역이었다. S3 인프라도, 하이퍼바이저도, 물리 보안도 뚫리지 않았다. 뚫린 것은 애플리케이션 구성(WAF), 인스턴스 메타데이터 설정(IMDS), 그리고 인스턴스 역할의 권한 범위였다. "관리형 서비스를 쓰면 안전하다"는 통념이 왜 위험한지를 이 사건 하나가 요약한다.

📚 사례: 2017년 다수 기업이 S3 버킷을 공개 설정으로 둔 채 개인정보를 저장해 대형 유출이 잇따랐다. AWS의 대응은 개별 고객을 교육하는 것이 아니라 플랫폼 기본값을 바꾸는 것이었다 — S3 Block Public Access 기능을 도입하고, 이후 신규 버킷에 기본 활성화했으며, 콘솔에 경고 배지를 노출했다. 이것이 거버넌스(도메인 6)의 본질이다. 통제는 "사람이 잘하도록 요청하는 것"이 아니라 **"잘못하기 어렵게 만드는 것"**이다. 시험에서 조직 차원 통제를 묻는 문항의 정답이 거의 항상 SCP·Control Tower·기본값 강제 쪽인 이유가 여기 있다.

내일부터는 그 사슬의 척추인 IAM으로 들어간다. 사용자·그룹·역할·정책이 무엇이고, AWS가 한 요청을 허용할지 거부할지 결정하는 평가 로직이 정확히 어떻게 돌아가는지를 파면, 나머지 모든 도메인이 그 위에 얹히는 구조라는 것이 보이기 시작할 것이다.

한 줄 요약

공동 책임 모델은 고정된 표가 아니라 서비스 유형에 따라 위아래로 움직이는 경계선이며, 데이터 분류·암호화 결정·접근제어 세 줄만은 IaaS든 SaaS든 언제나 고객 책임이다. 모든 통제는 예방·탐지·대응 세 유형으로 분류되고, 문항의 동사("prevent/detect/respond")가 어느 유형을 요구하는지 알려 준다 — GuardDuty로 "차단"한다거나 Config로 "막는다"는 보기는 서비스는 맞고 동사가 틀린 대표적 오답이다. SCS-C03의 6개 도메인은 위협 → 가시성 → 네트워크 → 신원 → 데이터 → 거버넌스로 흐르는 하나의 사슬이고, 그 판정 엔진이 **도메인 4(IAM)**이라 첫 주를 여기에 쓴다. 멀티 계정 구조에서 로그는 Log Archive 계정으로 단방향·삭제 불가하게 흐르고, 보안 도구는 관리 계정이 아니라 Security Tooling 계정에 위임한다. 마지막으로 문항 끝의 형용사(most secure / least operational overhead)가 곧 채점 기준이라는 것을 잊지 않는다.