정답 · 해설

해설

【핵심 용어】 ▸ Macie Automated Discovery — 샘플링으로 민감한 데이터 보유 버킷 식별 ▸ Full Scan — 특정 버킷의 전체 객체 스캔 ▸ Sampling — 통계 기반으로 민감 데이터 여부 추측 【정답 포인트】 ▸ 최소 관리 오버헤드 = 자동 디스커버리 활용 ▸ Automated Discovery = 주기적 샘플링으로 리스크 버킷 식별 ▸ 선택적 스캔 = 민감 데이터 있는 버킷만 전체 스캔 ▸ 비용 최적화 = 모든 버킷 스캔 불필요 ▸ 자동화 = 수동 개입 최소 【오답 체크】 (A) CRR 구성은 복잡하고, 복제 비용 증가 (B) Lambda + 이벤트 트리거는 객체 단위 스캔으로 비용 높음 (D) 스캔 결과 집계는 자동화 부족, 수동 쿼리 필요 【시험 포인트】 ▸ 대규모 S3 환경 = Macie Automated Discovery 필수 ▸ 샘플링 → 전체 스캔 = 2단계 접근으로 효율적 ▸ 관리 오버헤드 최소 = 자동 디스커버리가 최고 ▸ Macie 고급 기능 = Automated Discovery로 스캔 최적화

해설

【핵심 용어】 ▸ Cross-Account KMS Sharing — KMS 키 정책으로 다른 계정에 권한 부여 ▸ Customer Managed Key — 고객이 생성하고 관리하는 KMS 키 ▸ AWS Managed Key — AWS가 관리하는 기본 키 (공유 불가) 【정답 포인트】 ▸ 고객 관리형 키 = 다른 계정과 공유 가능 ▸ 기본 KMS 키 = 다른 계정과 공유 불가능 ▸ 키 정책에 다른 계정의 IAM principal 추가 ▸ Lambda 함수로 키 복사 = KMS API 불가능 ▸ 키 정책 기반 공유 = 가장 직관적 【오답 체크】 (A) 기본 KMS 키는 공유 불가, Lambda로 키 복사 불가 (B) 고객 관리형 키는 import 불가 (복사/export도 불가) (C) 기본 KMS 키는 공유 불가능 【시험 포인트】 ▸ 교차 계정 KMS = Customer Managed Key 필수 ▸ KMS 키 공유 = 키 정책에 principal 추가 ▸ Lambda로 키 복사/import = 불가능한 작업 ▸ RDS 스냅샷 암호화 = KMS 키 복호화 권한 필수

해설

【핵심 용어】 ▸ require_secure_transport — Aurora 데이터베이스 클러스터 매개변수로, SSL/TLS를 통한 보안 연결만 허용 ▸ Data in transit encryption — 전송 중 암호화를 강제하는 메커니즘 【정답 포인트】 ▸ require_secure_transport = ON 설정 → 모든 클라이언트 연결이 TLS/SSL을 사용해야 함 ▸ Aurora의 기본 제공 기능으로 추가 구성 요소 없이 즉시 적용 가능 ▸ DB 클러스터 파라미터 그룹에서 직접 구성하여 규정 준수 요구사항 충족 【오답 체크】 (B) AWS Directory Service — 인증 메커니즘이지만, 전송 암호화 강제와 무관 (C) ACM 인증서 — Aurora는 AWS 관리 인증서를 자동으로 사용하므로 별도 구성 불필요 (D) RDS Proxy — 연결 풀링 기능이지만, 전송 암호화를 직접 강제하지 않음 【시험 포인트】 ▸ Aurora 보안 파라미터: require_secure_transport, require_authentication 등 ▸ 전송 암호화(in-transit) vs 저장 암호화(at-rest) 구분 ▸ 최소 권한 원칙으로 필요한 연결만 허용하도록 설정

해설

【핵심 용어】 ▸ AWS WAF rate limiting — IP별 요청 빈도를 제한하는 보안 정책 ▸ CloudWatch-based rule — 시간 범위 내 요청 횟수를 추적하는 WAF 규칙 【정답 포인트】 ▸ WAF는 ALB 계층에서 요청을 필터링하여 애플리케이션 부하 감소 ▸ Rate limiting 규칙 → 5분 윈도우에서 IP당 3개 요청만 허용 ▸ 추가 인프라 구성 없이 WAF의 기본 기능으로 즉시 구현 가능 ▸ DDoS/rate-based 공격 방어의 표준 패턴 【오답 체크】 (B) Lambda + CloudWatch — 복잡한 구현이 필요하고 운영 오버헤드가 큼 (C) EC2 애플리케이션 수정 — 모든 인스턴스에 코드 배포 필요, 유지보수 어려움 (D) DynamoDB TTL — 읽기 제한과 관계없고, 용량 조정이 목적이 아님 【시험 포인트】 ▸ WAF rate-based rules: 시간 기반 요청 횟수 제한 문제의 최적 솔루션 ▸ 가장 적은 노력(least effort) → 기존 기능 활용이 정답 ▸ ALB + WAF 조합으로 애플리케이션 변경 없이 보안 강화

해설

【핵심 용어】 ▸ Network ACL — VPC 서브넷 수준 상태 비저장 방화벽 (인바운드/아웃바운드 분리) ▸ Ephemeral ports (1024-65535) — 클라이언트가 응답을 수신하는 임시 포트 범위 ▸ Rule priority — 낮은 번호부터 순서대로 평가, 일치하면 처리 【정답 포인트】 ▸ 인바운드 규칙 100 → MySQL(3306) 거부 (명시적 차단) ▸ 인바운드 규칙 200 → 임시 포트 범위 허용 (HTTPS 응답 받기) - TLS 클라이언트는 포트 443으로 요청하고 1024-65535에서 응답 수신 ▸ 아웃바운드 규칙 100 → 포트 443 허용 (외부 서비스 접근) ▸ 규칙 번호 순서가 중요 → 100이 200보다 먼저 평가됨 【오답 체크】 (A) 임시 포트를 허용하지 않음 → 서버 응답 수신 불가 (C) 규칙 순서 역전 → 포트 1024-65535를 먼저 허용하면 3306 거부 규칙이 의미 없음 (D) 임시 포트 범위 미포함 → 클라이언트가 응답을 받을 수 없음 【시험 포인트】 ▸ Network ACL 설계: 방향성(inbound/outbound) 분리 필수 ▸ 임시 포트 개념: 클라이언트-서버 양방향 통신을 위한 필수 규칙 ▸ 규칙 번호가 낮을수록 우선순위 높음 → 명시적 거부를 먼저 배치

해설

【핵심 용어】 ▸ AWS Secrets Manager — 암호 자동 회전, 감사 로깅, 액세스 제어 지원 ▸ AWS Systems Manager Parameter Store — 단순 KV 저장소, 회전 기능 제한적 ▸ IAM role vs inline policy — 역할(권장)은 재사용 가능, 인라인은 사용자/역할에만 적용 【정답 포인트】 ▸ Secrets Manager → 자동 회전 기능, 감시 및 로깅, 규정 준수 지원 ▸ IAM role (task role) → ECS 컨테이너가 시작 시 임시 자격증명 획득 ▸ 최소 권한 + 감사 추적: DB 관리자가 평문으로 접근 불가능 ▸ 인라인 정책보다 역할 사용 → 정책 재사용 및 관리 용이 【오답 체크】 (A) Parameter Store — 회전 기능 없음, 단순 저장소 역할 (B) Secrets Manager 선택은 맞으나, 인라인 정책 → 관리 오버헤드 증가 (C) Parameter Store + 역할 → 자동 회전 기능 부족 【시험 포인트】 ▸ 자동 회전이 필요하면 → Secrets Manager 필수 ▸ ECS 보안: task role 활용으로 임시 자격증명 관리 ▸ 규정 준수 시나리오에서 Secrets Manager 선택이 일반적 패턴

해설

【핵심 용어】 ▸ VPC Endpoint for KMS — AWS 네트워크 내 전용 경로로 KMS 접근 ▸ Private DNS — VPC 엔드포인트 사용 시 자동으로 KMS API 호출 라우팅 ▸ aws:sourceVpce — KMS 키 정책에서 특정 VPC 엔드포인트만 허용하는 조건 【정답 포인트】 ▸ (A) aws:sourceVpce 조건 → KMS 키 정책에서 특정 VPC 엔드포인트만 허용 ▸ (C) VPC Endpoint + Private DNS → KMS API 호출이 공개 인터넷을 거치지 않음 ▸ 두 조치 조합으로 AWS 네트워크 내 완전한 격리 달성 - 엔드포인트 생성 (C) → 전용 경로 설정 - 정책 조건 추가 (A) → 특정 엔드포인트만 허용 【오답 체크】 (B) IGW 제거 — KMS 접근과 무관, 일반 인터넷 연결 제어일 뿐 (D) Import Key — KMS 키 생성 방식이지, VPC 내 통신 경로와 무관 (E) SourceIp 조건 — VPC CIDR을 정책에 추가하면, 공개 IP 경로 사용 시에도 통과 가능 【시험 포인트】 ▸ Private link 기반 VPC 엔드포인트: AWS 서비스 격리의 표준 방법 ▸ Private DNS 활성화: 애플리케이션 코드 변경 없이 엔드포인트로 라우팅 ▸ 키 정책 조건화: sourceVpce로 특정 엔드포인트만 승인, 일반 API 호출 차단

해설

【핵심 용어】 ▸ InstanceCredentialExfiltration — EC2 인스턴스 프로필의 임시 자격증명이 유출되어 외부 사용 ▸ IAM session revoke — IAM 사용자/역할의 모든 활성 세션을 즉시 무효화 ▸ Credential compromise — 악의적 행위자가 탈취한 자격증명의 즉시 차단 【정답 포인트】 ▸ GuardDuty 발견 → EC2 인스턴스의 임시 자격증명이 외국에서 사용 중 ▸ 즉시 취할 조치 → 인스턴스 프로필의 모든 IAM 세션 취소 (D) ▸ 자격증명이 이미 탈취되었으므로, 보안 그룹/네트워크 제어는 효과 없음 ▸ 취소 후 새 임시 자격증명 발급으로 악의적 행위자의 액세스 차단 【오답 체크】 (A) 보안 그룹 변경 — 이미 탈취된 API 키 사용을 막을 수 없음 (B) Systems Manager Agent — 인스턴스 인벤토리와 무관, 악의적 사용 차단 불가 (C) Inspector Agent — 취약점 스캔이지, 활성 악의적 사용을 차단하지 못함 【시험 포인트】 ▸ 자격증명 유출(exfiltration): 네트워크 제어가 아닌 IAM 레벨 대응 필요 ▸ "첫 번째 단계" → 피해 확대 방지를 위한 즉시 액션 (세션 취소) ▸ GuardDuty 이벤트 대응: credential revocation이 최우선

해설

【핵심 용어】 ▸ Duty separation — 운영팀과 보안팀의 권한 분리로 단일 팀의 오류 영향 최소화 ▸ SSE-KMS (customer managed) — 별도의 KMS 키 정책으로 완전한 접근 제어 ▸ Key policy vs Bucket policy — 키 정책과 버킷 정책의 독립적 관리 【정답 포인트】 ▸ SSE-KMS (고객 관리) → 운영팀과 보안팀이 독립적으로 제어 가능 ▸ 버킷 정책 (운영팀) → KMS 암호화 사용 강제 ▸ 키 정책 (보안팀) → 실제 키 사용 권한 제어 ▸ 두 정책 모두 필요 → AND 조건: 버킷 접근 권한 + 키 사용 권한 ▸ 한 팀의 실수만으로는 평문 데이터 노출 불가능 【오답 체크】 (A) SSE-S3 — AWS 관리 키이므로 키 정책 제어 불가능, 운영팀 오류 시 보안 취약 (C) SSE-S3 + IAM — AWS 관리 키는 IAM 정책으로 제어 불가능, 직무 분리 불가 (D) SSE-C — 고객이 직접 키 관리하므로 AWS 중앙 통제 불가능, 관리 복잡도 증가 【시험 포인트】 ▸ 직무 분리는 KMS 고객 관리 키가 필수: 키 정책과 버킷 정책 분리 ▸ AWS 관리 키(SSE-S3)는 IAM 정책 제어 불가능 ▸ SSE-C는 개별 키 관리로 중앙 통제 및 감시 어려움

해설

【핵심 용어】 ▸ AWS Organizations — 다중 계정 관리 및 통합 정책 적용 ▸ AWS Security Hub — 멀티 계정 보안 발견사항 통합 대시보드 ▸ Amazon Macie — 민감한 데이터 발견 및 분류 서비스 ▸ Cross-account access — 보안 계정에서 다른 계정의 리소스 접근 【정답 포인트】 ▸ Macie 사용 → 민감한 데이터(PII, PCI 등) 자동 발견 ▸ 보안 계정에서 활성화 → 한 위치에서 모든 발견사항 확인 ▸ Organizations 통합 → 모든 계정의 리소스 스캔 가능 ▸ 중앙 집계 → 보안 팀이 단일 대시보드에서 통합 관리 【오답 체크】 (A) S3 액세스 로그 — 데이터 분류 기능 없음, 민감 데이터 식별 어려움 (B) CloudTrail — API 활동만 추적, 데이터 콘텐츠 분석 불가능 (D) Config — 리소스 구성 추적만 가능, 데이터 콘텐츠 스캔 불가능 【시험 포인트】 ▸ Macie는 데이터 발견 및 분류 전문 서비스 ▸ 멀티 계정: Organizations 권장 계정에서 수행 ▸ 보안 계정 중심 집계로 통합 관리 효율성 증대

해설

【핵심 용어】 ▸ Cross-account access — 다른 AWS 계정의 리소스 접근 권한 ▸ IAM role assume — 임시 보안 자격증명으로 권한 위임 ▸ External ID — 역할 가정 시 추가 인증 레이어로 신원 확인 ▸ Trust policy — 역할을 가정할 수 있는 주체 정의 【정답 포인트】 ▸ IAM role 생성 (외부 파트너 계정용) → 권한 포함 ▸ Trust policy에 파트너 계정 ARN 추가 → 가정 권한 부여 ▸ External ID 필수 포함 → 권한 남용 방지 ▸ MFA 조건 추가 가능 → 추가 보안 강화 ▸ 임시 자격증명 기반 → 장기 키 관리 불필요 【오답 체크】 (A) IAM 사용자 + 액세스 키 — 장기 자격증명, External ID 제어 불가능 (C) Cognito Identity Pools — 모바일/웹 앱용, 엔터프라이즈 크로스 계정 용도 아님 (D) 버킷 정책 직접 설정 — S3만 가능, 다른 AWS 서비스 통제 불가능 【시험 포인트】 ▸ 외부 계정 접근은 반드시 역할(role)과 External ID 사용 ▸ 트러스트 정책: 파트너 계정 ARN + External ID 필수 ▸ 임시 자격증명으로 감시 및 감사(CloudTrail) 용이

해설

【핵심 용어】 ▸ VPC Flow Logs — 네트워크 인터페이스 트래픽 로그 ▸ CloudWatch Logs — 로그 저장 및 분석 서비스 ▸ AWS Lambda — 자동화된 트래픽 분석 및 대응 ▸ Insights — 로그 검색 및 패턴 분석 기능 【정답 포인트】 ▸ VPC Flow Logs → CloudWatch Logs로 전송 ▸ CloudWatch Logs Insights → 쿼리로 비정상 트래픽 검사 ▸ Lambda 함수 구성 → 임계값 초과 시 자동 알림 ▸ 메트릭 필터 + 알람 → 실시간 탐지 및 대응 ▸ 중앙 로깅 → 모든 VPC 트래픽 가시성 【오답 체크】 (A) CloudTrail — API 활동만 추적, 네트워크 흐름 기록 안 함 (B) Config — 리소스 구성 변화 추적만 가능, 트래픽 분석 안 함 (D) GuardDuty — 위협 탐지 서비스, VPC 트래픽 상세 분석 기능 제한적 【시험 포인트】 ▸ VPC Flow Logs는 네트워크 수준 트래픽 분석 기본 도구 ▸ CloudWatch Logs + Insights: 로그 검색 및 실시간 쿼리 ▸ Lambda 자동화로 수동 모니터링 제거

해설

【핵심 용어】 ▸ Default encryption — 모든 객체 암호화 자동 적용 ▸ SSE-KMS — AWS Key Management Service 기반 암호화 ▸ Bucket policy — 버킷 수준 접근 제어 정책 ▸ PutObject 권한 제어 — 암호화되지 않은 객체 업로드 차단 【정답 포인트】 ▸ 기본 암호화 설정 (SSE-KMS) → 모든 신규 객체 자동 암호화 ▸ 버킷 정책에 x-amz-server-side-encryption 조건 추가 → 암호화 강제 ▸ Effect: Deny + 암호화 헤더 미포함 검사 → 평문 업로드 차단 ▸ 기존 객체는 별도 배치 작업 필요 → Batch Operations 활용 ▸ 키 정책으로 권한 제어 → 특정 역할만 사용 가능 【오답 체크】 (A) 수동 설정만 — 자동화 없이 운영 오류 위험 높음 (C) 암호화만 설정 — 업로드 제어 없으면 우회 가능 (D) 정책 중복 확인 — 초기 요구사항 충족하나 지속성 부족 【시험 포인트】 ▸ 기본 암호화 + 버킷 정책 조합이 가장 안전 ▸ Deny 규칙: 암호화 헤더 검증 필수 ▸ 기존 객체 마이그레이션은 별도 전략 필요

해설

【핵심 용어】 ▸ CloudTrail — API 활동 로깅 및 감시 ▸ AWS Organizations trails — 조직 전체 로깅 ▸ 중앙 S3 버킷 — 모든 계정 로그 통합 저장 ▸ MFA Delete — 로그 삭제 보호 메커니즘 【정답 포인트】 ▸ Organizations trail 생성 → 모든 멤버 계정 포함 ▸ 중앙 보안 계정 S3 버킷 → 로그 수집 및 보관 ▸ 버킷 버전 관리 + MFA Delete → 로그 무결성 보호 ▸ CloudTrail 로그 파일 검증 → 조작 탐지 ▸ 장기 보존을 위해 S3 Glacier로 수명 주기 설정 ▸ 교차 계정 S3 버킷 정책 → 쓰기 권한 제어 【오답 체크】 (A) 각 계정별 로그 — 중앙화 불가능, 관리 복잡도 높음 (C) CloudWatch Logs만 — 로그 저장 기간 제한, 실시간만 가능 (D) 감시 없음 — 요구사항 미충족, 규정 준수 불가능 【시험 포인트】 ▸ Organizations trail이 멀티 계정 감시 표준 ▸ 중앙 S3 버킷: 로그 무결성과 장기 보존 동시 달성 ▸ MFA Delete: 실수나 악의적 삭제로부터 보호

해설

【핵심 용어】 ▸ Instance profile — EC2 인스턴스에 IAM 역할 연결 ▸ Assume role — EC2가 역할 가정으로 임시 자격증명 획득 ▸ IMDSv2 — 메타데이터 토큰 기반 보안 액세스 ▸ Permission boundary — 역할 권한의 최대 범위 제한 【정답 포인트】 ▸ Instance profile + IAM role → EC2 인스턴스에 권한 부여 ▸ S3 버킷 액세스 정책 포함 → 특정 버킷만 허용 ▸ IMDSv2 필수 설정 → 메타데이터 접근 보안 강화 ▸ 임시 자격증명 자동 갱신 → 장기 키 관리 불필요 ▸ STS AssumeRole로 권한 위임 → 감사 추적 가능 【오답 체크】 (A) IAM 사용자 + 액세스 키 — EC2에 하드코딩 위험, 회전 관리 복잡 (B) 루트 계정 자격증명 — 보안 위험 극대화, 감사 불가능 (D) 정책 없음 — 권한 부족으로 서비스 작동 불가능 【시험 포인트】 ▸ Instance profile이 EC2 권한 부여의 표준 방식 ▸ IMDSv2 필수: SSRF 공격으로부터 메타데이터 보호 ▸ 최소 권한 원칙: 필요한 버킷만 명시

해설

【핵심 용어】 ▸ IAM policy 평가 논리 — Explicit Deny > Explicit Allow > Default Deny ▸ 권한 경계(permission boundary) — 역할 권한의 최대 상한선 ▸ 리소스 기반 정책 — S3 버킷 정책, KMS 키 정책 등 ▸ 트러스트 정책 — 역할을 가정할 수 있는 주체 정의 【정답 포인트】 ▸ 서비스가 권한 있으려면 Allow 정책 필수 → Explicit Deny 우선 ▸ 권한 경계 설정 → 역할 권한 상한선 제어 ▸ 리소스 정책도 동시에 Allow 필요 → S3 버킷 정책 확인 ▸ Default는 Deny → 명시적 Allow 없으면 거부 ▸ 최소 권한 원칙 적용 → 필요한 것만 허용 【오답 체크】 (A) 트러스트 정책만 — 역할 가정만 가능, 실제 권한 없음 (B) 권한 경계만 — 상한선만 정의, Allow는 별도 정책 필요 (D) 정책 없음 — 권한 부족으로 서비스 거부 【시험 포인트】 ▸ Allow 정책 필수 + Deny 정책으로 예외 처리 ▸ 권한 경계는 보안 강화 도구, 필수 아님 ▸ 정책 평가: 트러스트 → 권한 경계 → 권한 정책 순서

해설

【핵심 용어】 ▸ AWS Secrets Manager — 암호, API 키 등 민감 정보 관리 ▸ Secret rotation — 자동 암호 주기적 변경 ▸ Lambda function — 회전 로직 실행 ▸ 데이터베이스 연결 — 암호 변경 시 즉시 적용 【정답 포인트】 ▸ Secrets Manager에 암호 저장 → 암호화된 저장소 ▸ 회전 설정 (90일 예: TTL) → 자동 주기 순환 ▸ Lambda 함수 구성 → 암호 변경 로직 실행 ▸ 데이터베이스 인증 정보 업데이트 → 동기화 ▸ 감시 로그 → CloudTrail로 접근 기록 추적 ▸ 재해 복구 — 이전 암호 버전 보관 【오답 체크】 (A) 수동 관리 — 운영 오류 위험, 규정 준수 어려움 (C) Parameter Store — 일반 설정용, 회전 기능 제한적 (D) 감시 없음 — 무단 접근 탐지 불가능 【시험 포인트】 ▸ Secrets Manager: 자동 회전이 핵심 기능 ▸ Lambda: 회전 로직 커스터마이징 가능 ▸ 감시: CloudTrail로 접근 제어 및 감시

해설

【핵심 용어】 ▸ AWS Shield Standard — 기본 DDoS 보호 (무료) ▸ AWS Shield Advanced — 고급 DDoS 보호 (고비용) ▸ AWS WAF — 웹 애플리케이션 방화벽 ▸ CloudFront — CDN 및 DDoS 완화 【정답 포인트】 ▸ Shield Advanced 구독 → 전용 DDoS 대응팀 ▸ CloudFront + WAF 조합 → 애플리케이션 계층 보호 ▸ 트래픽 분산 → 대역폭 공격 완화 ▸ 비용 보호 → Shield Advanced에서 스케일 공격 비용 지원 ▸ 실시간 모니터링 → 공격 탐지 및 대응 자동화 【오답 체크】 (A) Shield Standard만 — 기본 보호만 가능, 대규모 공격 대응 불가능 (B) WAF만 — 네트워크 계층 공격 방어 불가능 (D) 보호 없음 — 요구사항 미충족 【시험 포인트】 ▸ Shield Advanced: 대규모 DDoS 공격 대비 필수 ▸ CloudFront + WAF: 애플리케이션 보호 강화 ▸ 계층화 방어: 네트워크 + 애플리케이션 동시 보호

해설

【핵심 용어】 ▸ Multi-region KMS key — 여러 지역에서 사용 가능한 암호화 키 ▸ Primary key — 기본 키 생성 및 관리 지역 ▸ Replica key — 다른 지역의 읽기 전용 복제 키 ▸ Key policy — KMS 키 접근 제어 정책 【정답 포인트】 ▸ Multi-region primary key 생성 → 주 지역에서 생성 ▸ Replica keys 추가 → 다른 지역에서 사용 가능 ▸ 자동 동기화 → 키 자료 복제 및 유지 ▸ 재해 복구 — Replica key를 primary로 승격 가능 ▸ 규정 준수 — 데이터 상주 요구사항 충족 ▸ 성능 개선 — 로컬 지역 암호화로 지연 감소 【오답 체크】 (A) 지역별 키 생성 — 다중 키 관리 복잡, 정책 동기화 어려움 (B) 중앙 키만 사용 — 다른 지역에서 성능 저하 (C) 키 복사 — 독립적 키 관리로 정책 일관성 어려움 【시험 포인트】 ▸ Multi-region key가 글로벌 애플리케이션 표준 ▸ Replica key는 읽기 전용, 교체 시 승격 가능 ▸ 자동 동기화로 관리 부담 감소

해설

【핵심 용어】 ▸ Security group — 인스턴스 수준의 상태 저장 방화벽 ▸ Ingress rule — 인바운드 트래픽 제어 ▸ Egress rule — 아웃바운드 트래픽 제어 ▸ 최소 권한 원칙 — 필요한 포트/프로토콜만 허용 【정답 포인트】 ▸ Ingress: HTTP(80)/HTTPS(443) → 특정 CIDR만 허용 ▸ Egress: 아웃바운드 필요 서비스만 허용 → 기본 모두 거부 ▸ 0.0.0.0/0 피하기 → 특정 IP/보안 그룹 사용 ▸ 세그멘테이션 — 애플리케이션별 독립 그룹 ▸ VPC Flow Logs — 트래픽 모니터링 ▸ 정기 감시 — 사용하지 않는 규칙 제거 【오답 체크】 (A) 모든 포트 허용 — 0.0.0.0/0은 보안 위험 (B) Egress 제한 없음 — 데이터 유출 위험 (D) 감시 없음 — 비정상 트래픽 탐지 불가능 【시험 포인트】 ▸ 기본 설정: 모든 인바운드 거부, 필요한 것만 Allow ▸ Egress: 필요한 것만 허용으로 데이터 유출 방지 ▸ 정기 감사: CloudTrail 및 VPC Flow Logs 활용