wyzz.log

03-AWS-DAY1

16 min read

Q1. MFA 강제 정책 후 CLI 사용 불가

정답: B — aws sts get-session-token에 --serial-number, --token-code 전달

문제의 정책

{
  "Sid": "BlockAnyAccessUnlessSignedInWithMFA",
  "Effect": "Deny",
  "Action": "ec2:*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": { "aws:MultiFactorAuthPresent": false }
  }
}

원인 분석

  • BoolIfExists + false → 키가 false일 때 + 키가 아예 없을 때 모두 매치 → Deny
  • aws:MultiFactorAuthPresent는 STS 임시 자격 증명에만 존재하는 컨텍스트 키
  • CLI에서 장기 액세스 키(AKIA...) 사용 → 키 자체가 없음 → IfExists에 걸려 Deny
접근 방식키 상태결과
콘솔 MFA 로그인true허용
CLI + 장기 액세스 키키 없음Deny
CLI + get-session-token 임시 자격 증명true허용

해결 명령

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/user \
  --token-code 123456

반환된 AccessKeyId / SecretAccessKey / SessionToken 3개를 환경변수·프로파일에 설정

오답

  • A — aws:MultiFactorAuthPresent는 AWS가 채우는 글로벌 컨텍스트 키. 정책에서 값 변경 불가
  • C — SAML 페더레이션은 IdP 구축 필요. “최소 변경 해결”에 과함
  • D — 같은 Statement에 Action/NotAction 공존 불가(문법 오류). Deny 대상이 ec2:*라 sts:AssumeRole은 원래 안 막힘

Q2. 리전 제한 SCP

정답: C

{
  "Sid": "DenyNonDefaultRegions",
  "Effect": "Deny",
  "NotAction": [ "<Desired Global Services>" ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["eu-west-1"] }
  }
}

해석

글로벌 서비스를 제외한 모든 액션에 대해, 요청 리전이 eu-west-1이 아니면 Deny

NotAction이 필요한 이유

IAM, CloudFront, Route 53, WAF, Organizations, Support 등 글로벌 서비스는 aws:RequestedRegion이 us-east-1로 잡힘 → NotAction 없이 "Action": "*"로 짜면 IAM 사용자 생성조차 불가한 계정이 됨

리전 제한 문제 판별 기준 2개

  1. Deny + StringNotEquals인가? (Allow + StringEquals는 오답 — 다른 정책으로 우회 가능)
  2. 글로벌 서비스 예외(NotAction)가 있는가?

Q3. IAM Identity Center 외부 IdP 연동 순서

정답 순서

  1. Obtain the SAML metadata from the external IdP
  2. Configure the external IdP as the identity source in IAM Identity Center
  3. Enable automatic provisioning in IAM Identity Center settings

외울 공식 메타데이터 받기 → ID 소스 설정 → 프로비저닝(SCIM) 활성화 = 누군지 믿을 준비 → 신뢰 연결 → 사용자 명단 동기화

오답

  • Create an IAM role with trust policy — IAM Identity Center를 안 쓰는 직접 SAML 페더레이션 방식. Identity Center는 Permission Set이 역할을 자동 생성/관리
  • Enable automatic provisioning in the external IdP — Identity Center에서 먼저 켜야 SCIM 엔드포인트 URL·토큰이 발급됨. 순서상 Identity Center가 먼저

Q4. KMS 키 정책 + kms:ViaService

정답: C — Principal이 ExampleRole이고 지정 리전의 WorkMail/SES에서 온 요청일 때만 사용 가능

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/ExampleRole" },
  "Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey*","kms:CreateGrant","kms:ListGrants"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": ["workmail.us-west-2.amazonaws.com","ses.us-west-2.amazonaws.com"]
    }
  }
}

핵심 오해 교정

WorkMail/SES는 권한을 받은 게 아님 Principal = 권한 받는 주체(ExampleRole) / Condition = 제약 조건(경유 서비스) ViaService는 권한을 나눠주는 게 아니라 깎아내는 장치

✅ ExampleRole → SES → KMS       (ViaService = ses.us-west-2)
❌ ExampleRole → KMS 직접 호출   (ViaService 키 없음 → StringEquals 불일치 → Allow 미발동)
Condition 없을 때Condition 있을 때
CLI로 직접 Decrypt가능차단
SES 통해 사용가능가능
Lambda 통해 사용가능차단

오답

  • A — 권한 부여 방향이 반대
  • B — “ExampleRole과 AWS 간 이메일 교환 암호화”라는 개념 자체가 없음
  • D — 키 정책의 Resource: "*"는 “계정의 모든 키”가 아니라 “이 키 하나”

Q5. 페더레이션 사용자 S3 접근 차단

정답: B

{
  "Principal": { "AWS": "arn:aws:sts::account-id:federated-user/Bob" },
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
}

판별 3요소

요구사항대응
”차단하라”Explicit Deny (Allow 미부여로는 부족)
“페더레이션 사용자”sts::...:federated-user/ ARN
”다른 권한은 유지”버킷 정책(리소스 기반) 으로 이 버킷에서만 차단

오답

  • A — ARN 형식은 맞지만 Allow라 요구사항과 정반대
  • C — iam::...:user/Bob은 IAM 사용자 ARN. Bob은 IAM 사용자가 아니라 매칭 안 됨
  • D — assumed-role/Bob/session은 AssumeRole 방식이고, Bob이 역할 이름 자리에 들어간 잘못된 구조

Q6. 모니터링 전략 매칭

전략시나리오
VPC Flow Logs + CloudWatch Logs InsightsE — 근무 시간 외 외부 IP 대용량 전송
CloudWatch 메트릭 필터 (소스 IP별 인증 실패율)D — 1시간 내 50회 이상 인증 실패
CloudTrail Insights (API 호출률 기준선)C — 권한 사용자의 비정상적 대량 삭제
Security Hub + EventBridge + LambdaA — 멀웨어 확인 시 EC2 자동 격리
(Detective)B — 다단계 공격 상관분석

판별 기준

  • 고정 임계값(“50회”) → 메트릭 필터 + 알람
  • “비정상적으로”, “평소와 다른” → 기준선 학습 필요 → CloudTrail Insights / GuardDuty
  • “자동으로 격리/차단/대응” → EventBridge + Lambda 반드시 포함
  • 다단계 공격 연결고리 추적 → Detective

Q7. S3 영구 삭제 방지 + DR

정답: B — 기본 리전에서 규정 준수(Compliance) 모드로 S3 객체 잠금 + S3 복제

Governance vs Compliance

모드해제/삭제 가능 여부
Governances3:BypassGovernanceRetention 권한자가 우회 가능
Compliance아무도 불가. 루트 계정도, AWS도 불가

문제 요구: “관리자 권한이 있는 사용자가 영구 삭제할 수 없어야” → Compliance만 정답

기본 리전에만 걸어도 되는 이유

S3 Replication이 Object Lock 보존 설정까지 함께 복제

  • 전제: 양쪽 버킷 모두 버전 관리 + Object Lock 활성화

오답

  • A — Backup Vault Lock은 유효하나 거버넌스 모드라 관리자 우회 가능 (모드 단어만 바꾼 함정)
  • C — s3:ReplicateDelete는 삭제 마커 전파만 통제. 보조 리전에서 직접 DeleteObjectVersion 호출은 못 막음
  • D — 버전 관리는 실수 복구용. 버전 지정 삭제는 영구 삭제됨

Q8. 침해 사고 KMS 키 삭제

정답: B — 다른 리전 확인 후 7일 뒤 키 삭제 예약

상황 해석

  • “어제 삭제 예약됐지만 여전히 활성” → 문제가 아니라 정상 동작 (PendingDeletion 상태)
  • KMS 삭제 대기 기간: 7~30일 (기본 30일), 대기 중 사용 불가, CancelKeyDeletion으로 취소 가능
  • “여러 리전에 분산된 워크로드” → 다른 리전 키 확인이 핵심 단서

오답

  • A — 키 정책이 이미 kms:* 허용 중이라 루트 불필요. 이미 PendingDeletion이면 재제출 불가
  • C — 지문이 이미 권한 허용 명시 → 불필요한 조작
  • D — 비활성화는 삭제가 아님(언제든 재활성화 가능). 30일은 최대치라 사고 대응에 부적절

Q9. EC2 + 온프레미스 SSH 대체

정답: B — AWS Systems Manager Session Manager

요구사항 4개 대응

요구사항Session Manager의 해결
EC2 + 온프레미스하이브리드 활성화(mi- 관리형 인스턴스)
작업 시간 외 완전 격리인바운드 포트 0개 — 에이전트가 아웃바운드 443으로 먼저 나감
SSH 키 관리 불필요IAM 기반 인증
연결 시간만큼만 과금상시 인프라 없음, 추가 요금 없음

동작 구조

        ┌─────────────────────┐
        │  SSM 서비스 (AWS)    │  ← 중립 지대(만남의 장소)
        └─────────────────────┘
           ▲               ▲
    아웃바운드 443     아웃바운드 443
           │               │
      [타겟 서버]      [관리자]
  • 양쪽 다 밖으로 나와서 만남 → 관리자가 타겟 안으로 들어가지 않음
  • 명령 실행은 타겟 서버 내부에서 발생, 중간 지점은 입출력을 나르는 터널
  • 감사: CloudTrail(접속 이력) + S3/CloudWatch Logs(명령어 전문)

배스천과의 차이

배스천Session Manager
중간 지점 소유내가 만든 EC2AWS 관리 서비스
인바운드 포트필요불필요
인증SSH 키 × 2회 (관리자→배스천, 배스천→타겟)IAM 1회
유휴 비용발생없음

오답

  • A — 배스천은 상시 과금 + 인바운드 개방 + SSH 키 관리 → 요구사항 4개 중 3개 위반
  • C — CloudShell은 AWS API를 호출하는 CLI 환경. 서버 접속 도구 아님
  • D — VPC 엔드포인트는 경로만 제공하는 부품. 단독으로 접속 수단 아니고, AZ당 시간 과금 + 온프렘 커버 불가
    • 단, 프라이빗 서브넷 + NAT 없이 Session Manager 구성 시 ssm/ssmmessages/ec2messages 3종 필요 → 그때는 정답의 일부

Q10. EKS 위협 탐지

정답: C — GuardDuty 활성화 + EKS 보호 및 런타임 모니터링 + SNS + EventBridge

GuardDuty의 EKS 2계층

기능데이터 소스지문 대응
EKS ProtectionEKS 감사 로그”EKS 감사 로그 모니터링”
Runtime MonitoringeBPF 에이전트”운영 체제, 네트워킹, 파일 이벤트”

오답

  • A — Security Hub는 집계·규정 준수 점검용. 스스로 탐지 안 함. 보안 표준은 설정 상태만 봄
  • B — Inspector(이미지 CVE 스캔) + Detective(사후 조사) + Lambda → 위협을 판단하는 주체가 없음
  • D — 감사 로그만 수집(OS/네트워크/파일 미커버). “로그 생성 시 알림”은 정상 활동에도 알림 폭탄

Q11. IoT Core 클라이언트 ID 위장

정답: A, E

  • A — 애플리케이션에서 IoT 사물 이름을 클라이언트 ID로 사용
  • E — 리소스를 client/${iot:Connection.Thing.ThingName}으로 설정하고 iot:Connect 허용

공격 원리

MQTT 클라이언트 ID는 클라이언트가 CONNECT 패킷에 스스로 신고하는 값 → 트로이 목마 앱이 임의 조작 가능

정상: clientId = "device-001"    → client/device-001
공격: clientId = "device-*"      → 와일드카드로 범위 확장
      clientId = "device-001/#"  → 하위 토픽 전체 접근

정책 변수 신뢰도

변수출처검증
${iot:ClientId}클라이언트가 보낸 값❌ 검증 없음
${iot:Connection.Thing.ThingName}IoT 레지스트리✅ 인증서-사물 연결 검증

A와 E가 세트인 이유

Thing 정책 변수 동작 전제 = 클라이언트 ID = 사물 이름 → E만 적용하면 정상 기기도 불일치로 연결 실패. A가 전제 조건을 맞춤

오답

  • B — 클라이언트 측 검증. 앱이 이미 변조된 상황이라 무의미
  • C — Principal이 아니라 Resource. AWSIoTWirelessDataAccess는 LoRaWAN/Sidewalk용
  • D — ${iot:ClientId}는 자기가 보낸 값끼리 비교 → 제약이 전혀 안 걸림

Q12. 구성 변경 추적 + 규정 준수

정답: B — AWS Config

CloudTrail과의 차이 (핵심)

CloudTrailConfig
기록 단위개별 API 호출리소스 구성 상태
답하는 질문누가 언제 무엇을 호출지금 어떤 상태인가
규정 준수 평가없음Config Rules 내장

최근 API ≠ 최신 구성 

t1: 22번 추가 / t2: 3389번 추가 / t3: 22번 제거
→ 최근 API는 "22번 제거"
→ 실제 구성은 "3389번이 열려 있음"

전체 이력을 재생해야 현재 상태를 알 수 있음 → 운영 효율 위반

Config는 연속적 변경 시 안정화된 최종 구성을 하나의 Configuration Item으로 기록 → 지문의 “최신 구성만 기록” 요구와 일치

오답

  • A, C — CloudTrail/CloudWatch는 API 호출 기반. 누적 결과를 직접 재구성해야 함 + 규정 준수 평가 기능 없음
  • D — Cloud Map은 서비스 디스커버리 도구(마이크로서비스 엔드포인트 탐색). Config와 이름만 비슷

Q13. CloudHSM 사용자 지정 키 저장소

정답: D — 키 생성: KMS + CloudHSM 사용자 지정 키 저장소 / 감사: CloudTrail

선지 구조 (2축 채점)

선지키 생성감사
A✅Athena ❌
BS3 ❌✅
C✅GuardDuty ❌
D✅✅

Custom Key Store 구조

KMS API  →  내 CloudHSM 클러스터 (단독 점유, FIPS 140-2 Level 3)
↑ 인터페이스는 KMS 그대로 (S3/EBS/RDS 통합 유지)
↑ 키 자료는 내 HSM에 격리

봉투 암호화 (Envelope Encryption)

  1. GenerateDataKey 호출
  2. KMS가 평문 데이터 키 + 암호화된 데이터 키 반환
  3. 앱이 평문 키로 로컬 암호화 → 즉시 메모리 폐기
  4. 암호화된 데이터 키는 데이터 옆에 저장

오답

  • A — Athena는 감사 데이터를 생성하지 않음. CloudTrail 로그가 S3에 쌓인 뒤 분석하는 후속 도구
  • B — S3는 객체 스토리지, 키 생성 기능 없음
  • C — GuardDuty는 탐지(이상 행위 판단)이지 감사(전체 기록의 완전성) 아님

관련 노트

Backlinks