Skip to main content

2/8/2026

AWS Security 관련 문제 및 개념

이번 문서에서는 SAA 시험의 보안 과목 관련 문제와 기본 개념을 정리하는 문서입니다.
SAA 시험에서 보안 과목 Domain 1. Secure Architectures 설계는 30%로 가장 비중이 높습니다.

보안 과목에서 주로 나오는 주제들은 다음과 같습니다.

  1. IAM (최소 권한 원칙)
  2. 네트워크 보안 (VPC)
    • Security Group vs NACL
    • VPC Endpoint
  3. 데이터 보호 및 암호화
    • S3 : SSE-S3, SSE-KMS, SSE-C
      • SSE-S3 : S3가 관리하는 키로 암호화
      • SSE-KMS : KMS가 관리하는 키로 암호화
      • SSE-C : 고객이 관리하는 키로 암호화
    • RDS
    • EBS
    • EFS
  4. 보안 서비스
    • AWS WAF: 웹 애플리케이션 방화벽
    • AWS Shield: DDoS 보호
    • AWS GuardDuty: 위협 탐지
    • AWS Inspector: 취약점 검사
    • AWS Macie: 데이터 보안
    • AWS Secrets Manager: 비밀 관리
    • AWS KMS: 키 관리
    • AWS Certificate Manager: 인증서 관리
    • AWS CloudTrail: 감사
    • AWS Config: 구성 관리
    • AWS Security Hub: 보안 허브
    • AWS Organizations: 조직 관리
    • AWS SSO (IAM Identity Center): SSO
    • AWS RAM (Resource Access Manager): 리소스 공유
    • AWS Resource Groups: 리소스 그룹
    • AWS Trusted Advisor: 신뢰할 수 있는 조언자

AWS에 보안 관련 기능이 많다보니, 문제에서 주어진 상황마다 어떤 서비스를 사용해야하는지 파악하는 것이 중요합니다.

  • ex1: DDoS 공격을 방어하기 위한 서비스는 무엇인가? AWS Shield
  • ex2: 최소 비용과 운영 오버헤드를 충족하면서 웹 애플리케이션의 SQL Injection 공격을 방어하기 위한 서비스는 무엇인가? AWS WAF
  • ex3: 대규모 DDoS 공격으로 인해 CloudFront와 ALB 사용 비용 급증이 우려될 때, 공격 완화와 비용 보호를 함께 제공하는 서비스는 무엇인가?
    • Shield Advanced : 유료 제공, 대규모 공격 대응 및 비용 보호 기능 제공
    • Shield와 Shield Advanced의 차이를 묻는 문제도 종종 출제됩니다.

AWS Security 핵심 개념​

문제를 풀기에 앞서, AWS의 보안 관련 서비스들의 특징을 정리해두는 것이 좋습니다.
개인적으로 AWS SA 시험을 앞두고 덤프 문제를 많이 풀어본 뒤, 이 노트를 작성하며 헷갈렸던 부분들을 정리했습니다.

0. 보안의 기본 원칙​

  • 공동 책임 모델 (Shared Responsibility Model): AWS는 클라우드 자체의 보안 (인프라, 물리적 서버 등)을 책임지고, 고객은 클라우드 내에서의 보안 (데이터, OS 설정, IAM 권한 등)을 책임짐.
  • 최소 권한 원칙 (Principle of Least Privilege): 사용자나 시스템에 꼭 필요한 권한만 부여하여 보안 사고의 영향을 최소화함.

1. 자격 증명 및 액세스 관리 (IAM)​

  • IAM Role (Instance Profile): EC2 인스턴스가 다른 AWS 서비스(S3 등)에 안전하게 접근할 수 있도록 자격 증명을 부여. 액세스 키를 코드에 노출하지 않아 보안상 우수함.
  • AWS Organizations: aws:PrincipalOrgID 전역 조건 키를 S3 버킷 정책 등에 추가하여 특정 조직(Organization) 내의 계정들로만 리소스 접근을 제한할 수 있음.
  • AWS SSO (IAM Identity Center): 온프레미스 Active Directory와 연동하여 중앙 집중식 로그인을 제공하며, 계정 간 권한 관리를 단순화함.

2. 데이터 보호 및 비밀 관리​

  • AWS Secrets Manager: RDS 등 데이터베이스 자격 증명의 **자동 회전(Rotation)**을 지원함. (SSM Parameter Store와 가장 큰 차이점)
  • AWS KMS (Key Management Service): 데이터 암호화 키 관리 서비스. Multi-Region Keys를 사용하면 여러 리전에서 동일한 키 ID와 키 아티팩트를 사용하여 데이터를 암호화/복호화할 수 있어 데이터 재복제 시 용이함.
  • S3 보안: MFA Delete(우발적 삭제 방지), Versioning(버전 관리)을 통해 데이터 불변성 유지. Amazon Macie를 통해 S3에 저장된 **PII(개인 식별 정보)**를 감시 및 추적 가능.

3. 네트워크 보안 및 트래픽 검사​

  • Network Firewall: VPC 경계에서 상태 저장(Stateful) 트래픽 필터링 및 정밀 패킷 검사(DPI) 수행.
  • Gateway Load Balancer (GWLB): 타사 보안 어플라이언스(방화벽 등)를 투입하여 트래픽 검사 아키텍처를 구축할 때 사용.
  • GuardDuty: 지능형 위협 탐지 서비스로 머신러닝을 통해 악성 IP 통신이나 비정상적 활동을 감시.

4. WAF, Shield 및 규정 준수​

  • AWS WAF: SQL Injection, XSS 등** 애플리케이션 계층(L7) 공격 방어**. ALB, CloudFront, API Gateway에 배포.
  • AWS Shield: L3/L4 DDoS 보호. Standard는 무료 제공, Advanced는 대규모 공격 대응 및 비용 보호 기능을 제공.
  • AWS Config: 리소스 구성 변경 사항을 추적하고 규정 준수 여부를 확인 (예: S3 퍼블릭 오픈 여부 감시).
  • AWS CloudTrail: 계정 내 모든 API 호출을 기록하여 감사를 지원.
  • AWS Artifact: AWS의 규정 준수 보고서(ISO, PCI, SOC 등)를 다운로드할 수 있는 포털.

5. 외부 및 교차 계정 액세스 (SAA 단골 주제)​

  • 교차 계정 액세스 (Cross-account Access): 타사(3rd party) 공급업체가 고객 계정에 접근할 때 사용.
    • IAM Role을 생성하고 타사 계정 ID를 신뢰 관계에 추가함. 보안 강화를 위해 External ID를 필수로 요구함 (Confused Deputy 문제 방어).
  • VPC Endpoint (PrivateLink): IGW나 NAT 없이 AWS 서비스(또는 타사 SaaS)에 비공개로 연결.
    • Interface Endpoint: 대부분의 서비스 지원. ENI를 통해 사설 IP 부여.
    • Gateway Endpoint: S3와 DynamoDB만 지원하며 라우팅 테이블에 경로 추가 (성능/비용 우수).
  • AWS Cognito: 앱 사용자 인증 서비스.
    • User Pool: 로그인/가입 기능 (인증).
    • Identity Pool: 사용자가 임시 AWS 자격 증명을 받아 S3 등에 직접 접근하게 함 (인가).

6. 거버넌스 및 리소스 공유​

  • SCP (Service Control Policy): AWS Organizations 내 계정들의 최대 가능 권한을 제한. (예: 특정 리전 사용 금지, root 사용자도 제한 가능).
  • Permission Boundary: 개별 IAM 사용자/역할이 가질 수 있는 최대 권한 한계 설정.
  • AWS RAM (Resource Access Manager): VPC Subnet, Transit Gateway, License Manager 등을 다른 계정과 공유하여 불필요한 리소스 중복 생성 방지.
  • CloudFront OAC (Origin Access Control): S3 버킷 접근을 CloudFront로만 한정할 때 사용 (기존 OAI 대체).

7. 애플리케이션 보안 및 인증서​

  • AWS Certificate Manager (ACM): SSL/TLS 인증서 관리. ALB, CloudFront에 적용하여 HTTPS 통신 구현. CloudFront에 적용할 때는 반드시 us-east-1(버지니아 북부) 리전에 인증서가 있어야 함.
  • IAM Identity Center (SSO) vs Cognito:
    • IAM Identity Center: 직원(Internal)들이 여러 AWS 계정이나 비즈니스 앱에 로그인할 때 사용.
    • Cognito: 일반 사용자(External/Customer)들이 웹/모바일 앱에 로그인할 때 사용.
  • AWS KMS Key Policy: KMS 키는 자격 증명 정책(Identity-based)뿐만 아니라 **키 정책(Key Policy)**이 반드시 해당 사용자를 허용해야 접근 가능함.

보안 과목 주요 문제 패턴​

문제를 풀면서 반복되는 출제 패턴을 정리했습니다.
어느정도 덤프를 풀다보면 보기가 비슷비슷하게 나오는 경향이 있습니다.

1. AWS 계정 접근 vs 애플리케이션 사용자 인증 (단골 함정)​

핵심 구분:

  • AWS 계정/리소스 접근: IAM (사용자, 역할, 정책)
  • 애플리케이션 사용자(고객) 인증: Cognito (User Pool, Identity Pool)
  • 직원들의 다중 계정/앱 로그인: IAM Identity Center (AWS SSO)

문제 패턴:

  • "외부 공급업체가 우리 AWS 계정의 리소스에 접근" → IAM Role + Cross-account Access + External ID
  • "웹앱 사용자가 S3에 파일 업로드" → Cognito Identity Pool (임시 자격 증명)
  • "직원이 여러 AWS 계정에 로그인" → IAM Identity Center (SSO)

2. 비밀 관리: Secrets Manager vs Parameter Store​

항목Secrets ManagerParameter Store
자동 회전✅ RDS 자격 증명 자동 회전 지원❌ 수동 관리 필요
비용유료무료 (Standard), 유료 (Advanced)
용도데이터베이스 암호 등 민감 정보구성 데이터, 일반 파라미터
교차 계정 공유✅ 지원제한적

선택 기준:

  • 운영 오버헤드 최소화 + 자동 회전 필요 → Secrets Manager
  • 단순 구성 저장 + 비용 절감 → Parameter Store

3. S3 암호화 옵션 선택​

암호화 방식키 관리 주체키 회전감사(CloudTrail)비용
SSE-S3AWS 자동 관리자동❌무료
SSE-KMSKMS (고객 관리형 키)수동/자동✅유료
SSE-C고객이 직접 제공고객 책임❌무료

선택 기준:

  • 키 사용 감사 필요 + 세밀한 권한 제어 → SSE-KMS
  • 간단한 암호화만 필요 → SSE-S3
  • 완전한 키 통제권 → SSE-C (운영 복잡도 높음)

4. EC2 인스턴스 원격 접근 방법​

방법보안운영 복잡도감사비용
Session Manager✅ IAM 기반낮음✅ CloudTrail무료
SSH + Bastion Host△ 키 관리 필요높음제한적EC2 비용
EC2 Instance Connect✅ 임시 키낮음✅무료

Session Manager 장점:

  • 인바운드 포트(22) 열 필요 없음
  • SSH 키 관리 불필요
  • 세션 로그 자동 기록 (S3, CloudWatch Logs)

5. 권한 제어 계층 (헷갈리기 쉬운 개념)​

제한 범위가 다름:

  1. SCP (Service Control Policy): 조직(Organization) 내 계정 전체의 최대 권한 한계
  2. Permission Boundary: 특정 IAM 사용자/역할의 최대 권한 한계
  3. IAM Policy: 실제 부여되는 권한

실제 권한 = SCP ∩ Permission Boundary ∩ IAM Policy (교집합)

문제 패턴:

  • "특정 리전만 사용하도록 제한" → SCP
  • "개발자가 생성하는 모든 역할의 최대 권한 제한" → Permission Boundary

6. 교차 계정 액세스 (Cross-account Access)​

필수 요소:

  1. 역할 생성: 리소스가 있는 계정(A)에서 IAM Role 생성
  2. 신뢰 관계: Role의 Trust Policy에 접근할 계정(B)의 ID 추가
  3. External ID: 타사가 접근할 때 보안 강화 (Confused Deputy 문제 방어)
  4. 권한 부여: 계정 B의 사용자에게 sts:AssumeRole 권한 부여
  • 공급업체 액세스 예시: "공급업체의 IAM 역할에 대한 액세스 권한을 위임하려면 회사 계정에서 IAM 역할을 생성"

7. Stateful vs Stateless​

구분Stateful (상태 저장)Stateless (상태 비저장)
네트워크 ACL✅ 인바운드/아웃바운드 규칙 별도 설정 필요❌ 인바운드/아웃바운드 규칙 별도 설정 필요
보안 그룹✅ 인바운드/아웃바운드 규칙 별도 설정 필요❌ 인바운드/아웃바운드 규칙 별도 설정 필요
  • Stateful: 인바운드 트래픽을 허용하면 아웃바운드 트래픽은 자동으로 허용됨 (응답 트래픽 자동 허용)
  • Stateless: 인바운드 트래픽과 아웃바운드 트래픽을 별도로 설정해야 함

Security 관련 문제​

C03 덤프 문제에서 Security 관련 주요 문제들을 정리했습니다.

Q1: 조직 내 S3 액세스 제한​

회사는 AWS Organizations 를 사용하여 여러 부서의 여러 AWS 계정을 관리합니다. 관리 계정에는 프로젝트 보고서가 포함된 Amazon S3 버킷이 있습니다. 회사는 이 S3 버킷에 대한 액세스를 AWS Organizations의 조직 내 계정 사용자로만 제한하려고 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

정답: A

  • A. 조직 ID 에 대한 참조와 함께 aws:PrincipalOrgID 전역 조건 키를 S3 버킷 정책에 추가합니다.
  • B. 각 부서에 대한 조직 단위(OU)를 만듭니다. aws:PrincipalOrgPaths 전역 조건 키를 S3 버킷 정책에 추가합니다.
  • C. AWS CloudTrail 을 사용하여 특정 이벤트를 모니터링하고 S3 버킷 정책을 업데이트합니다.
  • D. 사용자에 태그를 지정하고 aws:PrincipalTag 전역 조건 키를 사용합니다.

Q2: 데이터베이스 자격 증명 관리​

회사에 Amazon EC2 인스턴스에서 실행되고 Amazon Aurora 데이터베이스를 사용하는 애플리케이션이 있습니다. EC2 인스턴스는 파일에 로컬로 저장된 사용자 이름과 암호를 사용하여 데이터베이스에 연결합니다. 회사는 자격 증명 관리의 운영 오버헤드를 최소화하려고 합니다. 솔루션 설계자는 이 목표를 달성하기 위해 무엇을 해야 합니까?

정답: A

  • A. AWS Secrets Manager를 사용합니다. 자동 회전을 켭니다.
  • B. AWS Systems Manager Parameter Store를 사용합니다. 자동 회전을 켭니다.
  • C. S3 버킷에 자격 증명 파일을 저장하고 KMS로 암호화합니다.
  • D. 암호화된 EBS 볼륨에 자격 증명 파일을 저장합니다.

Note: Secrets Manager는 RDS 자격 증명의 자동 회전(Rotation) 기능을 기본적으로 지원하지만, SSM Parameter Store는 자동 회전 기능이 내장되어 있지 않습니다.

Q3: VPC 트래픽 검사 및 필터링​

최근에 AWS 로 마이그레이션한 회사가 프로덕션 VPC 로 들어오고 나가는 트래픽을 보호하는 솔루션을 구현하려고 합니다. 이 회사는 이전에 온프레미스에서 검사 서버를 통해 트래픽 흐름 검사 및 필터링을 수행했습니다. 동일한 기능을 AWS에서 구현하기 위한 솔루션은?

정답: C

  • A. 프로덕션 VPC에서 Amazon GuardDuty를 사용합니다.
  • B. 트래픽 미러링을 사용하여 트래픽을 미러링합니다.
  • C. AWS 네트워크 방화벽(Network Firewall)을 사용하여 필요한 규칙을 생성합니다.
  • D. AWS Firewall Manager를 사용하여 규칙을 생성합니다.

Q4: S3 구성 변경 모니터링​

회사는 Amazon S3 버킷에 무단 구성 변경이 없는지 확인해야 합니다. 솔루션 설계자는 이 목표를 달성하기 위해 무엇을 해야 합니까?

정답: A

  • A. 적절한 규칙으로 AWS Config를 켭니다.
  • B. AWS Trusted Advisor를 켭니다.
  • C. Amazon Inspector를 켭니다.
  • D. S3 서버 액세스 로깅을 켭니다.

Q5: 대규모 DDoS 공격 보호​

아키텍처는 Elastic Load Balancer(ELB) 뒤의 EC2 인스턴스로 구성됩니다. DNS에는 타사 서비스가 사용됩니다. 회사는 대규모 DDoS 공격을 감지하고 보호하기 위한 솔루션이 필요합니다.

정답: D

  • A. Amazon GuardDuty를 활성화합니다.
  • B. Amazon Inspector를 활성화합니다.
  • C. AWS Shield를 활성화하고 Route 53을 할당합니다.
  • D. AWS Shield Advanced를 활성화하고 ELB를 할당합니다.

Q6: S3 데이터 내 PII(개인 식별 정보) 탐지​

회사는 S3 버킷에 업로드된 파일 중에 개인 식별 정보(PII)가 포함된 경우 관리자에게 알림을 보내고 문제 해결을 자동화하려고 합니다. 최소한의 개발 노력으로 가능한 솔루션은?

정답: B

  • A. Amazon Inspector를 사용하여 버킷의 객체를 스캔합니다.
  • B. Amazon Macie를 사용하여 버킷의 객체를 스캔하고 알림을 트리거합니다.
  • C. S3 수명 주기 정책을 사용하여 PII를 제거합니다.
  • D. CloudWatch Logs를 사용하여 PII를 탐지합니다.

Q7: S3 버킷에 대한 액세스 제한​

회사는 AWS Organizations 를 사용하여 여러 부서의 여러 AWS 계정을 관리합니다. 관리 계정에는 프로젝트 보고서가 포함된 Amazon S3 버킷이 있습니다. 회사는 이 S3 버킷에 대한 액세스를 AWS Organizations의 조직 내 계정 사용자로만 제한하려고 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

정답: A

  • A. 조직 ID 에 대한 참조와 함께 aws:PrincipalOrgID 전역 조건 키를 S3 버킷 정책에 추가합니다.
  • B. 각 부서에 대한 조직 단위(OU)를 만듭니다. aws:PrincipalOrgPaths 전역 조건 키를 S3 버킷 정책에 추가합니다.
  • C. AWS CloudTrail 을 사용하여 특정 이벤트를 모니터링하고 S3 버킷 정책을 업데이트합니다.
  • D. 사용자에 태그를 지정하고 aws:PrincipalTag 전역 조건 키를 사용합니다.

Q9: 외부 공급 업체와 웹 서버 접속​

회사에는 탄력적 IP 주소가 있는 퍼블릭 서브넷의 Amazon EC2 인스턴스에서 실행되는 웹 서버가 있습니다. 기본 보안 그룹은 EC2 인스턴스에 할당됩니다. 모든 트래픽을 차단하도록 기본 네트워크 ACL 이 수정되었습니다. 솔루션 설계자는 포트 443 을 통해 어디에서나 웹 서버에 액세스할 수 있도록 해야 합니다.
이 작업을 수행할 단계 조합은 무엇입니까? (2개 선택)

A. 소스 0.0.0.0/0에서 TCP 포트 443 을 허용하는 규칙으로 보안 그룹을 생성합니다. B. 대상 0.0.0.0/0에 대한 TCP 포트 443 을 허용하는 규칙으로 보안 그룹을 생성합니다. C. 소스 0.0.0.0/0에서 TCP 포트 443 을 허용하도록 네트워크 ACL을 업데이트합니다. D. 소스 0.0.0.0/0 에서 대상 0.0.0.0/0 으로 인바운드/아웃바운드 TCP 포트 443 을 허용하도록 네트워크 ACL을 업데이트합니다. E. 소스 0.0.0.0/0 에서 인바운드 TCP 포트 443 을 허용하고 대상 0.0.0.0/0 으로 아웃바운드 TCP 포트 32768 - 65535 를 허용하도록 네트워크 ACL을 업데이트합니다.

정답: A, E

이 문제를 시험장에서 본다면 당황할 것 같아서 추가로 노트를 작성하고 공부했습니다.

Note: 이 문제의 핵심은 보안 그룹(Security Group) 과 네트워크 ACL(Network ACL) 의 동작 방식 차이를 정확히 이해하는 것입니다.

1. 보안 그룹(Security Group)​

  • 보안 그룹은 Stateful 하다.
  • 인바운드 트래픽이 허용되면, 해당 트래픽에 대한 응답 아웃바운드 트래픽은 자동으로 허용된다.
  • 요구사항은 “어디에서나(0.0.0.0/0) 포트 443(HTTPS)로 웹 서버 접근 허용”이다.

A가 정답인 이유

  • 소스 0.0.0.0/0에서 TCP 포트 443 인바운드를 허용하면,
  • 외부에서 EC2 웹 서버로 HTTPS 접근이 가능해진다.
  • 보안 그룹에서는 추가적인 아웃바운드 규칙이 필요 없음.

2. 네트워크 ACL(Network ACL)​

  • 네트워크 ACL은 Stateless 하다.
  • 인바운드와 아웃바운드 규칙을 각각 명시적으로 허용해야 한다.
  • 문제에서 기본 네트워크 ACL이 “모든 트래픽 차단” 상태이므로 반드시 수정이 필요하다.

HTTPS 통신 흐름:

  • 인바운드: 클라이언트 → EC2, TCP 포트 443
  • 아웃바운드: EC2 → 클라이언트, Ephemeral Port (32768–65535)

E가 정답인 이유

  • 인바운드 규칙: 0.0.0.0/0 → TCP 포트 443 허용
  • 아웃바운드 규칙: 0.0.0.0/0 → TCP 포트 32768–65535 허용
  • Stateless 특성상 응답 트래픽까지 고려한 올바른 설정이다.

오답 정리​

B

  • 보안 그룹의 인바운드 규칙은 Source 기준으로 설정한다.
  • Destination 기준 규칙은 이 시나리오에 맞지 않는다.

C

  • 네트워크 ACL에서 인바운드 443만 허용했다.
  • Stateless 특성상 아웃바운드 응답 트래픽이 차단되어 통신이 실패한다.

D

  • 아웃바운드 트래픽을 443만 허용했다.
  • HTTPS 응답 트래픽은 Ephemeral Port를 사용하므로 잘못된 설정이다.

핵심

  • Security Group: Stateful → 인바운드만 열면 응답 트래픽 자동 허용
  • Network ACL: Stateless → 인바운드 + 아웃바운드 모두 명시적 허용
  • HTTPS 응답 트래픽은 TCP 포트 32768-65535 사용

관련 글​

TECHUP 사이버보안 이론 과정에서 공부했던 내용이 많아 도움이 되었습니다.