AWS Certified Cloud Practitioner (CLF-C02) #4 Domain 2-1 보안: 책임 공유 모델, IAM 기초

#3까지 도메인 1을 마쳤습니다. 이제 시험의 30%를 차지하는 가장 큰 도메인 Security and Compliance로 들어갑니다. 이 도메인은 두 편으로 나눠 다룹니다. 이번 글은 책임 공유 모델과 IAM 기초, 다음 #5는 컴플라이언스와 암호화입니다.

책임 공유 모델 (Shared Responsibility Model) #

CLF-C02에서 가장 자주 출제되는 단일 개념입니다. “AWS가 어디까지 책임지고 어디서부터 고객이 책임지는가"를 한 그림으로 정리한 모델입니다.

            ┌────────────────────────────────┐
            │   Customer responsibility      │
   IN       │   ── SECURITY IN THE CLOUD ──  │
   THE      │   고객 데이터, 플랫폼, 앱      │
   CLOUD    │   IAM 정책, OS 패치, 방화벽    │
            │   네트워크/방화벽 설정         │
            │   클라이언트,서버 측 암호화    │
            └────────────────────────────────┘
            ┌────────────────────────────────┐
            │   AWS responsibility           │
   OF       │   ── SECURITY OF THE CLOUD ──  │
   THE      │   하드웨어, 네트워크, 시설     │
   CLOUD    │   호스트 OS,하이퍼바이저       │
            │   글로벌 인프라(Region/AZ)     │
            │   서비스 자체의 SW             │
            └────────────────────────────────┘

핵심 어휘 두 개:

• Security OF the Cloud. AWS가 책임 (클라우드 자체의 보안)
• Security IN the Cloud. 고객이 책임 (클라우드 위에 올린 것의 보안)

영역별 책임 #

서비스 모델별로 달라지는 책임 #

같은 AWS라도 어떤 서비스를 쓰는가에 따라 고객 책임의 범위가 달라집니다.

요약: 관리형 서비스일수록 AWS가 더 많이 책임지고, IaaS일수록 고객이 더 많이 책임집니다.

항상 고객이 책임지는 것 #

이건 어떤 서비스를 쓰든 고객 몫입니다.

• 데이터 자체 (분류,소유권,접근 권한)
• IAM 사용자/역할/정책 설계
• 자격 증명 관리 (액세스 키 회전, MFA)
• 클라이언트 측 암호화 (선택적이지만 한 적용)

시험 출제 패턴 #

“OS 패치를 자동 적용하는 책임은 누구에게 있는가?” → EC2면 고객 / RDS면 AWS. 보기에 함께 등장하면 서비스 이름을 보고 가른다.

“S3 버킷의 데이터를 암호화하는 책임은?” → 고객 (버킷 정책으로 암호화 강제, 또는 데이터 자체 암호화).

“EC2 인스턴스에서 동작하는 앱의 SQL Injection 방어 책임은?” → 고객.

“AWS 데이터센터의 물리적 보안은?” → AWS.

IAM (Identity and Access Management) #

IAM은 누가(WHO) AWS 자원에 무엇을(WHAT) 할 수 있는지를 관리하는 서비스입니다. 글로벌 서비스이며 무료로 제공됩니다.

실무 트랙 #2에서 콘솔과 CLI로 직접 다뤄 보았습니다. 자격증 관점에서는 개념과 어휘에 집중합니다.

IAM의 네 가지 핵심 #

사용자 (User) #

가입 후 IAM 콘솔에서 만든 사용자입니다. 사람 또는 서비스 계정으로 사용.

{
  "Console Login Password": "콘솔 접속용 비밀번호",
  "Access Key ID + Secret Access Key": "CLI/SDK 용 키 쌍",
  "MFA Device": "추가 인증"
}

그룹 (Group) #

같은 권한을 여러 사용자에게 줄 때 사용합니다. 예: “개발자 그룹"에 EC2 읽기/쓰기 정책을 붙이면 그룹 내 모든 개발자에게 적용.

그룹의 제약:

• 그룹은 사용자만 담을 수 있음. 그룹 안에 그룹은 불가.
• 그룹 자체는 자격증명을 가지지 않음. 로그인할 수 없음.

역할 (Role) #

가장 자주 헷갈리는 객체입니다. 임시 자격증명으로 동작합니다.

Role vs User의 핵심 차이:

• 사용자는 영구 자격증명. 키가 유출되면 폐기,재발급 필요
• 역할은 임시 토큰으로 동작. 보통 1시간 유효, 자동 갱신

시험에서 “EC2에서 S3에 접근하려면 어떻게 자격증명을 관리해야 하는가?“가 나오면 정답은 IAM 역할 부여 (액세스 키를 EC2에 저장하는 게 아니라).

정책 (Policy) #

권한을 정의한 JSON 문서입니다. 시험에서 정책 JSON을 직접 작성할 필요는 없지만 구조와 어휘는 알아야 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

정책의 종류 #

권장: AWS Managed Policy → Customer Managed Policy → Inline Policy 순으로 선호.

최소 권한 (Least Privilege) #

IAM 설계의 가장 중요한 원칙입니다. 필요한 최소한의 권한만 부여합니다.

시험 보기에 자주 등장하는 안티 패턴:

• “모든 사용자에게 AdministratorAccess를 부여”. 항상 오답
• “편의를 위해 모든 IAM 사용자가 같은 정책 사용”. 오답
• “한 사용자에게 모든 권한을 부여하고 필요 시 사용”. 오답

정답이 되는 패턴:

• 역할(Role)을 정의하고 필요한 사람에게 부여
• 그룹별로 정책 분리 (개발자,읽기 전용,관리자)
• 정기적인 권한 감사 (IAM Access Analyzer)

MFA (Multi-Factor Authentication) #

비밀번호에 더해 두 번째 인증 수단을 요구하는 보안 강화 메커니즘입니다.

MFA 종류 #

누구에게 MFA를 강제하는가 #

• root 사용자. 무조건 MFA (시험 출제 빈도 최상위)
• IAM 관리자급 사용자. 강력 권장
• 콘솔 로그인 가능한 모든 사용자. 정책으로 강제 가능

시험에 “AWS 계정 보안을 강화하기 위한 첫 단계는?” → root 사용자에 MFA 적용 + IAM 사용자 만들기.

Root 사용자 가이드 #

가입 직후 받는 계정에는 root 사용자가 있습니다. 모든 권한을 가지므로 가장 보호받아야 하는 자격증명입니다.

Root로만 할 수 있는 작업 (시험에 자주 나옴) #

Root 사용 원칙 #

• 일상 작업 절대 금지. IAM 사용자로
• MFA 필수. Hardware MFA 권장
• 액세스 키 만들지 않기. 이미 있다면 즉시 삭제
• 비밀번호는 강력하게. 매우 복잡하게 + 안전한 곳에 보관

액세스 키 (Access Key) 운영 #

CLI/SDK에서 사용하는 키 쌍입니다.

Access Key ID:     AKIAIOSFODNN7EXAMPLE
Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

운영 원칙 #

• 코드에 하드코딩 금지. git에 푸시되면 몇 분 내 봇이 발견
• EC2에서는 액세스 키 대신 IAM 역할 사용
• 정기적인 키 회전 (Access Key Rotation)
• 사용하지 않는 키 비활성화
• 두 개를 동시에 둘 수 있음. 회전 시 새 키 생성 → 코드 갱신 → 이전 키 비활성화 → 폐기

IAM Identity Center (구 AWS SSO) #

여러 AWS 계정과 외부 SaaS 앱에 하나의 자격증명으로 로그인하는 서비스입니다. 실무 트랙 #5에서 다뤘습니다.

시험 관점에서는:

• 여러 AWS 계정을 쓰는 조직에 권장
• 외부 IdP 연동 가능 (Okta,Azure AD 등)
• IAM 사용자 대신 임시 자격증명 사용

자주 만나는 함정 #

1) “root는 항상 안전하므로 일상 작업도 OK” #

가장 자주 출제되는 함정입니다. root로 일상 작업은 절대 금지. IAM 사용자를 만들고 그것으로 작업.

2) “최대 권한을 부여하고 나중에 줄인다” #

이것도 흔한 안티 패턴 보기입니다. 정답은 최소 권한으로 시작하고 필요 시 추가.

3) IAM은 글로벌 서비스가 아닌 리전 서비스 #

IAM은 글로벌 서비스입니다. 콘솔에서 IAM을 열면 리전 선택기가 “Global"로 바뀝니다.

4) 그룹 안에 그룹 #

그룹은 사용자만 담습니다. 그룹 안에 그룹은 불가.

5) “EC2에서 코드가 S3에 접근하려면 액세스 키를 EC2에 저장” #

이건 안티 패턴입니다. 정답은 IAM 역할을 EC2에 부여.

6) MFA를 옵션으로 두기 #

root MFA는 옵션이 아닙니다. 반드시 적용.

7) Inline Policy의 남용 #

재사용성이 없어 관리가 어렵습니다. Customer Managed Policy로 만들어 여러 객체에 붙이는 편이 낫습니다.

정리 #

이번 글에서 잡은 것:

• 책임 공유 모델. Security OF the Cloud(AWS) vs Security IN the Cloud(고객)
• 서비스 모델에 따라 책임 경계가 달라짐. IaaS일수록 고객 책임 큼
• 데이터,IAM,자격증명은 항상 고객 책임
• IAM 네 가지 핵심. User / Group / Role / Policy
• 사용자는 영구 자격증명, 역할은 임시 자격증명 (EC2,Lambda,교차 계정)
• 정책은 JSON 문서. Effect / Action / Resource / Condition
• 최소 권한 원칙. 필요한 최소한만 부여
• MFA. root에 필수, 콘솔 사용자에 강력 권장
• Root 사용자는 일상 작업 금지. MFA 필수. 액세스 키 만들지 않기
• 함정. root 일상 사용 / 최대 권한 부여 / IAM은 리전 서비스라는 오해 / 그룹 안에 그룹 / EC2에 액세스 키 저장 / MFA 옵션 처리

다음: Domain 2-2 컴플라이언스와 암호화 #

#5 Domain 2-2 컴플라이언스: 거버넌스, AWS Artifact, GDPR/HIPAA에서는 AWS의 컴플라이언스 인증 종류와 그 의미, AWS Artifact를 통한 인증 문서 접근, 거버넌스 도구(CloudTrail,Config), 그리고 데이터 암호화(저장 중,전송 중)와 KMS의 역할을 정리하겠습니다.