13주차 - AWS Cloud 보안 위협

 

- 클라우드 보안 위협 유형

위협 유형	원인	대응
계정 도용 (Account Hijacking)	피싱, Credential stuffing, 약한 비밀번호, Access Key 깃허브 업로드	MFA 필수화, 최소 권한 원칙, Access Key 주기적 회전·삭제
구성 오류 (Misconfiguration)	복잡한 보안 설정, 사람 실수, 퍼블릭 스토리지 접근 권한 오류	AWS Config, Security Hub, 자동 규정 준수 검사
데이터 유출 (Data Leakage/Breach)	내부자 실수, 시스템 취약점, 외부 공격, 퍼블릭 S3 버킷	S3 Block Public Access, 암호화(SSE), IAM 정책 점검
악의적인 내부자 (Malicious Insiders)	권한 있는 직원의 의도적·비의도적 데이터 손상	CloudTrail 로그 감시, GuardDuty 탐지, EventBridge + Lambda 자동 대응
서비스 거부 공격 (DoS/DDoS)	대규모 트래픽 유입으로 정상 서비스 불가	AWS Shield (Standard: 무료, Advanced: 유료), WAF Rate-based Rule, ALB 분산
안전하지 않은 인터페이스/API	인증·인가 불충분, 입력 검증 없음, 암호화 미적용, Rate Limiting 미비	IAM 최소 권한, HTTPS/TLS 필수, WAF·Lambda Authorizer, API Gateway Throttling, CloudTrail 로깅

- 기본 보안 대응 전략

클라우드 보안의 3대 원칙

원칙	내용	주요 서비스
예방 (Prevent)	설정 오류 방지, 취약점 제거	IAM, S3 Block Public Access, AWS Config
탐지 (Detect)	비정상 행위 및 위협 조기 발견	GuardDuty, CloudTrail, CloudWatch
대응 (Respond)	자동화된 조치 및 복구 계획	EventBridge + Lambda, Security Hub

접근 제어 측면:  IAM Root User 액세스 키를 삭제하고, 일상 작업에는 사용하지 않음. MFA 필수. IAM 사용자·그룹·역할(Role) 구조를 활용하고, 콘솔·CLI/API 접근 모두 인증을 강화해야 한다.

최소 권한 원칙(Least Privilege): IAM 정책을 기본 거부(Deny) 기반으로 설계하고, 업무 수행에 필요한 최소한의 권한만 부여함. Access Key는 불필요하면 삭제하고 주기적으로 회전시켜야 함. 키 하나가 유출돼도 과도한 권한이 있으면 피해가 매우 커질 수 있다.

로깅 및 모니터링:  AWS CloudTrail(API 호출 이력 추적), AWS CloudWatch(지표·로그 모니터링), GuardDuty(위협 탐지)를 사용, 로그는 중앙화해 저장하고 장기 보관해야 한다. 

보안 자동화와 규정 준수: AWS Config로 리소스 변경 추적 및 규정 준수 검사, Security Hub로 보안 현황 중앙 관리, EventBridge + Lambda로 자동 대응(예: 비정상 접근 시 보안 그룹 수정)을 구성




- AWS 기본 보안 서비스 소개

서비스	역할	특징
IAM	인증·권한 관리 (출입 통제)	사용자·그룹·역할(Role) 구성, JSON 정책 기반 권한 부여
Amazon GuardDuty	머신러닝 기반 위협 탐지	VPC Flow Logs, CloudTrail, DNS Logs 분석. 내부에서 이상 행위 탐지
AWS CloudTrail	모든 API 호출 로그 기록 (CCTV)	Event History, S3 저장, CloudWatch Logs 연동
AWS WAF	웹 애플리케이션 방화벽	HTTP/HTTPS 트래픽 모니터링, SQL Injection·XSS·HTTP Flood 등 룰로 보호
AWS Shield	DDoS 방어 서비스	Standard(무료)·Advanced(유료), WAF와 함께 사용해 웹 보안 강화
AWS Config	리소스 구성 변경 기록 및 규정 준수 검사	Managed Rules와 Custom Rules 제공. S3 퍼블릭이면 알림 발생
AWS Security Hub	통합 보안 대시보드	GuardDuty·Inspector(취약점 관리)·Macie(민감 데이터 보호) 등과 연계, 보안 점검 결과 기반 대응 계획 수립

이 서비스들은 각각 따로 존재하는 게 아니라 서로 연계되어 보안 레이어를 구성


- AWS Config 규칙 활용

리소스의 현재 상태와 변경 이력을 추적하고, 규칙(Rule)으로 자동으로 준수 여부를 판단한다.

평가 트리거 방식:
· Change-triggered: 리소스 설정이 바뀔 때마다 평가 (예: 보안 그룹 수정 시 즉시 점검)
· Periodic: 주기적으로 평가 (예: 24시간 간격)
· 일부 규칙은 두 가지 모두 지원

- AWS Config 실습: 정책 위반 탐지 자동화 데모

1. AWS Config 활성화
· AWS 관리 콘솔 → Config 서비스로 이동
· 서울 리전 선택 (Config는 리전 수준 서비스임)
· 원클릭 설정 클릭 → 확인

aws config는 리전 수준이므로 서울 리전 선택 확인

2. Managed Rule 추가
· Config 좌측 메뉴 → Rules → Add Rule 클릭
· s3-bucket-public-read-prohibited 선택 (S3 버킷 퍼블릭 액세스 등 검사)
· 저장 후 규칙 실행

3. 테스트용 S3 버킷 생성 (규정 위반 상태 만들기)
· S3 서비스로 이동 → 버킷 생성
· 주의: Config를 서울 리전에 활성화했다면 버킷도 서울 리전에 생성해야 함
· 버킷 이름은 중복 방지를 위해 뒤에 숫자 등을 붙여서 고유하게 설정
· 권한 설정에서 "모든 퍼블릭 액세스 차단" 해제 → 위험 인지 체크 후 버킷 생성

 

4. 버킷 정책으로 퍼블릭 Read 권한 추가
· 생성한 버킷 클릭 → 권한 탭 → 버킷 정책 → 편집
· 새 문장 추가: Principal = * (누구나), Action = s3:GetObject, Resource = 버킷ARN/*
· 저장

5. 규정 위반 확인
· Config 대시보드로 이동
· 약 30초~1분 후 새로고침
· 미준수 리소스 클릭 → 해당 버킷이 Noncompliant로 표시되는지 확인

미준수 리소스가 1로 바뀐 것을 확인할 수 있다.

6. 위반 상태 해제 (정상 복구)
· S3 버킷 → 권한 탭 → 버킷 정책 편집 → 퍼블릭 정책 삭제 후 저장
· 퍼블릭 액세스 차단 → 편집 → 모든 퍼블릭 액세스 차단 체크 → 변경 사항 저장 → 확인

7. 준수 상태 확인
· Config 대시보드로 이동 → 새로고침
· 미준수 리소스 0개로 변경되는지 확인
· 규칙 목록에서 해당 규칙이 Compliant로 표시되는지 확인

미준수 리소스가 1로 바뀐 것을 확인할 수 있다.

실습 주의사항: Config와 S3 버킷 모두 동일한 리전(서울)에서 생성해야 탐지가 정상적으로 동작한다.