[AWS] 7. 보안 서비스 WAF, GuardDuty 이해

클라우드는 인터넷에 연결된 환경이다.
보안 설정은 AWS가 아니라 내가 해야 한다.
이번 주차에서는 Shared Responsibility Model, WAF, GuardDuty를 다뤘다.

---

1. 클라우드 보안 책임 공유 모델

Shared Responsibility Model이란?

"클라우드에서는 모든 걸 AWS가 알아서 해주지 않나요?"

아니다. AWS와 고객이 각각 다른 보안 책임을 진다.

• AWS 책임 — "클라우드 자체의 보안" (Security of the Cloud)
  • 물리적 인프라 보안 (데이터 센터, 서버, 스토리지, 네트워크)
  • 하이퍼바이저, 하드웨어, AWS 관리 콘솔의 보안
• 고객 책임 — "클라우드 내의 보안" (Security in the Cloud)
  • 데이터 암호화, 네트워크 구성, IAM 설정, OS 패치 관리
  • 애플리케이션 보안, 포트 설정, 방화벽, 키 관리 등

온프레미스에서는 모든 보안 요소를 직접 관리해야 하지만, 클라우드에서는 인프라 레이어를 AWS가 맡고, 그 위의 설정·데이터는 고객이 맡는 구조다.

책임 분리 예시

항목	AWS 책임	고객 책임
물리적 서버 보안	✅	❌
S3 버킷 접근 권한 설정	❌	✅
인스턴스 OS 보안 패치	❌	✅
데이터 암호화 키 관리	❌ (기본 옵션 제공)	✅ (KMS 설정 필수)

사고 사례로 보는 책임 분리

시나리오 A: 설정 실수로 S3 버킷이 퍼블릭으로 열림 → 고객 데이터 노출
→ 책임 주체: 고객. S3 접근 권한 설정은 고객 영역이다.

시나리오 B: AWS가 데이터 센터 보안 실패 → 내부 침입 발생
→ 책임 주체: AWS. 물리적 인프라 보안은 AWS 영역이다.

상황	책임 주체
EC2 포트 22 열려 있음	고객
RDS 비밀번호 노출	고객
VPC 라우팅 설정 오류	고객
AWS 내부 하드웨어 결함	AWS

핵심은 간단하다. 내가 설정한 건 내 책임, AWS 인프라 자체 문제는 AWS 책임.

💡 느낀 점

• Shared Responsibility Model을 모르면, 사고가 났을 때 "AWS가 알아서 해주는 거 아니었어?" 하고 당할 수 있다. 실제로 2023년 영국 Capita 사건처럼 S3 설정 오류로 민감 데이터가 공개된 사례가 있다.
• 이전에 회사에서 GeoServer RCE 취약점으로 서버가 해킹당한 경험이 있는데, 그때도 결국 OS 패치와 방화벽 설정이 미흡했던 것이 원인이었다. 클라우드든 온프레미스든 "내가 관리하는 영역"을 명확히 인식하는 게 보안의 출발점이다.

---

2. 기본 보안 구성 요소 (Review)

IAM (Identity and Access Management)

AWS 리소스에 대한 접근 권한을 제어하는 서비스다. 구성 요소:

• User: 개별 로그인 계정
• Group: 사용자 모음
• Role: 임시 권한 위임
• Policy: 허용/거부되는 액션을 JSON으로 정의

VPC (Virtual Private Cloud)

AWS 상에 격리된 가상 네트워크 공간이다. 주요 구성 요소:

• Subnet: 내부 네트워크 단위 (퍼블릭 / 프라이빗)
• 라우팅 테이블: 트래픽 흐름 제어
• Internet Gateway (IGW): 인터넷 연결
• NAT Gateway: 프라이빗 서브넷에서만 외부 인터넷 접근 가능

웹 서버는 퍼블릭 서브넷에, DB 서버는 프라이빗 서브넷에 배치하는 것이 기본 패턴이다.

Security Group (보안 그룹)

EC2 등 인스턴스에 적용되는 가상 방화벽이다.

• Stateful: 인바운드가 허용되면 아웃바운드도 자동 허용
• Allow만 설정 가능 (Deny 불가)
• 포트, 프로토콜, IP 범위 단위로 제어

예시: 웹서버 보안 그룹은 80, 443 포트만 열고, SSH 접속을 위한 22 포트는 본인 IP로 제한.

---

3. 보안 서비스 도입이 중요한 이유

클라우드 보안 위협이 증가하는 이유

• 클라우드는 인터넷과 연결된 환경 → 무한한 접근 가능성
• 사용자가 늘어나고 설정도 복잡해짐
• 멀티 클라우드 & 하이브리드 환경의 복잡성 → 보안 사각지대 발생

대표적 클라우드 보안 위협 유형

• 잘못된 권한 설정: 가장 흔한 위협
• 계정 및 자격 증명 탈취
• 내부자 위협: 합법적인 접근 권한을 가진 사람의 악의적 행동
• 서비스 거부 공격 (DDoS)
• Cryptojacking: 해킹한 클라우드 리소스로 암호화폐 채굴

실무 사례

사례 1: S3 퍼블릭 공개 사고
S3 퍼블릭 액세스를 활성화한 채 데이터를 업로드 → 민감한 고객 정보 수천 건 유출. 설정은 고객 책임 (Shared Responsibility Model).

사례 2: 계정 키 탈취 → 채굴 공격
개발자가 GitHub에 AWS Access Key를 실수로 업로드 → 1시간 내 공격자 접근 → EC2 인스턴스를 수십 개 실행하여 암호화폐 채굴 → 월 5,000달러 요금 폭탄.

보안 실패 시 손실 유형: 비용 손실, 브랜드 신뢰 하락, 법적 책임 발생 가능성.

AWS 주요 보안 서비스 소개

서비스	기능	목적	특징
AWS WAF	웹 공격 필터링 (XSS, SQLi 등)	웹 보안	규칙 기반 제어
GuardDuty	지능형 위협 탐지	이상 행동 탐지	머신러닝 기반
Shield	DDoS 방어	서비스 가용성 보장	기본형 무료 제공
CloudTrail	API 호출 기록	행동 감사 및 추적	보안 사고 분석
AWS Config	리소스 설정 변경 추적	규정 준수 및 감시	지속적인 감사

💡 느낀 점

• GitHub에 AWS Access Key 올리는 건 정말 많이 발생하는 사고다. git-secrets나 .gitignore 설정을 습관화해야 한다. AWS에서도 자동으로 유출된 키를 탐지해서 경고 메일을 보내주긴 하지만, 이미 늦을 수 있다.
• 보안 서비스 표에서 WAF는 "예방", GuardDuty는 "탐지" 역할이라는 구분이 명확하다. 하나만 쓰는 게 아니라 보안 사이클(예방→탐지→대응→분석) 전체를 커버해야 한다.

---

4. 클라우드 보안 사이클

보안은 일회성이 아니라 순환 구조로 운영해야 한다.

1단계: 예방 (Prevent)

보안 사고가 아예 발생하지 않도록 사전에 막는 단계다. 사고의 80% 이상은 이 단계에서 막을 수 있다.

• IAM 최소 권한 원칙 (Least Privilege), S3 버킷 Public Access Block 활성화
• 보안 그룹 인바운드 제한, 데이터 암호화 (EBS, RDS, S3 서버사이드 암호화)
• WAF는 공격 요청(SQL Injection, XSS, 악성 봇 등)이 애플리케이션에 도달하기 전에 걸러내고 차단

2단계: 탐지 (Detect)

예방 조치를 해도 공격은 발생할 수 있다. 비정상적 행위나 위협을 빠르게 식별하는 게 중요하다.

• Amazon GuardDuty → 비정상 API 호출, 악성 IP 통신 탐지
• AWS CloudTrail → 계정/API 활동 로그 기록
• AWS Config → 리소스 보안 설정 변화를 지속적으로 모니터링

탐지 속도가 곧 피해 최소화로 이어진다.

3단계: 대응 (Respond)

탐지된 위협에 대해 즉각적으로 대응하여 피해 확산을 막는 단계다.

• AWS WAF → 악성 IP를 차단하는 규칙 자동 배포
• AWS Lambda + CloudWatch Events → 자동 격리 (예: 해킹된 EC2를 보안 그룹에서 차단)
• 수동 대응보다 자동화된 대응(Auto-Remediation)이 점점 중요해지고 있다

4단계: 분석 및 개선 (Analyze/Recover)

사고가 발생했다면, 원인을 분석하고 재발 방지 대책을 마련하는 단계다.

목표: 사실관계 복원(타임라인) → 근본 원인 규명 → 재발 방지 대책 설계 → 개선 배포

카테고리	권장 조치 예시
신원/접근	MFA 100%, 최소 권한 원칙, 액세스 키 만료 정책
데이터	기본 암호화(KMS) 강제
네트워크	프라이빗 서브넷 기본, VPC L7 보호(WAF/ALB)
가시성/로그	CloudTrail, 표준화된 로그 수집 파이프라인
거버넌스	Security Hub(자동 보안 규정 준수 여부)

💡 느낀 점

• 보안 사이클을 4단계로 나눠서 보니, 대부분의 실무 환경은 "예방"에만 집중하고 "탐지"와 "분석/개선"은 소홀한 경우가 많다. 특히 소규모 팀에서는 사고가 터져야 뒤늦게 CloudTrail을 뒤지는 패턴이 반복된다.
• 증거 보존 원칙에서 "로그를 격리 계정에 저장"하라는 부분이 인상적이었다. 공격자가 침투 후 로그를 삭제하는 것도 흔한 패턴이니, CloudTrail 로그를 별도 S3 버킷(다른 계정)에 복제해두는 것이 안전하다.

---

5. AWS WAF (Web Application Firewall)

WAF란?

AWS WAF는 웹 애플리케이션을 일반적인 웹 기반 공격으로부터 보호하는 보안 서비스다. HTTP/HTTPS 트래픽을 모니터링하고 악성 공격으로부터 보호하는 역할을 한다.

주요 웹 응용 공격 유형

SQL Injection

공격자가 웹 입력 필드에 SQL 구문을 삽입하여 데이터베이스를 조작하는 방식이다.

-- 정상적인 쿼리
SELECT * FROM users WHERE key = '2302342342034'

-- SQL Injection 후 쿼리
SELECT * FROM users WHERE key = '2302342342034' or '1'='1' ;

or '1'='1'이 항상 참이므로 모든 사용자 데이터가 반환된다. 피해 사례: 사용자 정보 유출, DB 변경.

XSS (Cross-Site Scripting)

악성 스크립트를 삽입해 사용자의 브라우저에서 실행시키는 공격이다.

<script>alert('해킹');</script>

피해 사례: 세션 탈취, 피싱.

HTTP Flood / Rate-based Attack

웹 서버에 짧은 시간 동안 과도한 요청을 보내 서비스 불능을 유도한다. WAF의 속도 기반 룰(Rate-based rule)로 완화 가능.

WAF의 주요 구성 요소

룰(Rule)

특정 조건을 정의하는 보안 필터다. 규칙 = "조건" + "행동"

• 조건(Condition): 어떤 요청을 필터링할지 정의
• 행동(Action): 허용(Allow) / 차단(Block) / 카운트(Count)

예: 요청 본문에 SQL 패턴이 있으면 차단.

룰 그룹(Rule Group)

여러 개의 룰을 모아 놓은 집합이다. AWS 관리형 룰 그룹과 사용자 정의 룰 그룹이 있다.

예: AWSManagedRulesCommonRuleSet (일반 공격 차단)

웹 ACL (Web Access Control List)

룰 또는 룰 그룹을 적용하는 정책 단위다. 특정 리소스(CloudFront, ALB 등)에 연결한다.

WAF 작동 흐름

[요청] → [WAF - Web ACL] → [Rule Group (여러 Rule)] → [허용 / 차단 / count만 기록]

WAF 구성 예시 시나리오

• Rule1: 특정 IP 차단
• Rule2: SQL Injection 차단
• Rule3: 요청 수가 1분에 100건 초과 시 차단
  → 모두 Web ACL에 포함시켜 ALB에 적용

WAF 적용 대상

적용 대상	설명
Amazon CloudFront	글로벌 CDN에 대한 웹 공격 방어
Application Load Balancer (ALB)	EC2 기반 웹 애플리케이션의 트래픽 제어
Amazon API Gateway	API 호출에 대한 필터링 가능

CloudFront에는 Global Web ACL, 리전별 리소스(ALB, API Gateway, AppSync, Cognito, App Runner 등)에는 Regional Web ACL을 적용한다.

WAF 로그 분석 파이프라인 (구성 예시)

1. 애플리케이션 사용자가 요청
2. AWS WAF가 요청 정보를 캡처하여 Kinesis Data Firehose로 전송
3. Kinesis Data Firehose가 S3 버킷으로 로그 저장
4. 운영 팀이 Amazon Athena로 SQL 쿼리 분석
5. 분석 결과를 바탕으로 WAF 속도 기반 규칙 결정

💡 느낀 점

• WAF의 Count 모드가 실무에서 유용하다. 새 룰을 바로 Block으로 넣으면 정상 트래픽까지 차단할 수 있으므로, 먼저 Count로 설정해서 어떤 요청이 걸리는지 모니터링한 후 Block으로 전환하는 것이 안전하다.
• AWSManagedRulesCommonRuleSet 같은 관리형 룰 그룹은 AWS가 자동으로 업데이트해주므로, 최신 공격 패턴에 대한 대응이 빠르다. 직접 룰을 다 만들 필요 없이 관리형 룰을 기본으로 깔고, 필요한 커스텀 룰만 추가하는 전략이 효율적이다.
• WAF는 L7(HTTP/HTTPS) 레벨 방어이고, Security Group은 L3/L4(IP/Port) 레벨 방어다. 둘은 역할이 다르므로 함께 사용해야 한다.

---

6. Amazon GuardDuty

GuardDuty란?

Amazon GuardDuty는 AWS 계정 및 리소스에서 발생하는 이상 징후를 자동으로 탐지하는 위협 탐지 서비스다.

GuardDuty 역할

• 관리형 ML 기반 탐지 모델
• 지속적인 보안 이벤트 감시
• 계정 탈취, 악성 활동, 내부자 위협 등의 이상 행위 탐지
• 탐지 결과를 보안 팀에 자동 알림

기존 보안 접근의 한계: CloudTrail, VPC Flow Logs 등의 로그를 직접 분석하기 어렵고, 보안팀 인력이 부족한 경우 실시간 분석은 사실상 불가능하다.

GuardDuty 기본 작동 방식

GuardDuty는 다음 데이터 소스를 자동 분석한다:

• VPC Flow Logs (네트워크 트래픽 로그)
• AWS CloudTrail (API 호출 기록)
• DNS Logs (DNS 요청 로그)

탐지 방식:

• 머신러닝 기반
• AWS 자체적으로 알려진 악성 IP, 도메인, 공격 패턴 DB를 계속 업데이트

 

대표적인 탐지 유형

비정상 API 호출

• 일반적인 지역/시간대와 다른 IP에서 루트 계정 접근 시도
• 예: 새벽 3시에 러시아에서 IAM ListUsers 호출

비인가 인프라 접근

1. 공격자가 IAM 키를 탈취해 비인가 접근 시도
   • 예: 짧은 시간에 여러 지역(서울, 미국, 유럽)에서 root 계정 로그인 시도
2. 인스턴스에서 외부 비정상 포트로 연결
   • 정상적인 웹 서버라면 80, 443 같은 포트만 외부로 통신해야 하는데, 비정상 포트(6667, 1337, 8088 등)로 외부 연결을 시도
3. 악성 C2 서버(Command & Control Server)와의 통신 시도
   • 봇넷, 랜섬웨어, 암호화폐 채굴 악성코드가 이런 방식으로 동작

암호화폐 채굴 의심

• 인스턴스에서 채굴 도구 설치 또는 채굴 풀과의 연결 시도 탐지
• CPU 사용률 이상 + 악성 풀 서버 연결을 탐지

DNS 터널링 시도

• DNS 요청을 통해 내부 데이터를 외부로 빼내려는 시도

GuardDuty 경고 확인 방법

AWS Management Console > GuardDuty > Findings(결과)에서 확인한다.
→ 탐지 시간, 공격 유형, 공격 대상, 심각도(High/Medium/Low) 확인 가능.

GuardDuty 통합 알림 및 자동화 연동

도구	설명
Amazon CloudWatch Events	탐지 이벤트를 실시간 전달
AWS Lambda	자동 대응 스크립트 실행 (예: IAM 비활성화, 보안 그룹 차단 등)
SNS	관리자에게 알림 메일 또는 문자 전송

GuardDuty 통합 알림 데모 절차

Step 1. SNS 주제 생성

1. AWS 콘솔 → SNS 서비스
2. Topics → Create topic (Type: Standard, Name: GuardDutyFindingsTopic)
3. 구독(Subscription) 추가 → 프로토콜 선택 (Email, SMS 등)
   • Email 입력 시, 확인 메일을 수신 후 Confirm 클릭해야 정상 동작

SNS 구독 확인

Step 2. EventBridge 규칙 생성

1. AWS 콘솔 → EventBridge
2. Rules → Create rule (Name: GuardDutyFindingsRule, Event source: AWS services)
3. Service: GuardDuty
4. Event type: GuardDuty Finding
5. Target으로 SNS topic 선택 (GuardDutyFindingsTopic 지정)

Step 3. GuardDuty Findings 발생 테스트

1. AWS 콘솔 → GuardDuty → Settings
2. Generate sample findings 클릭
3. 몇 분 뒤 EventBridge가 이벤트를 트리거 → SNS 알림 발송

GuardDuty는 프리플랜에 속한 서비스가 아니어서 실제로 샘플을 테스트해볼 수는 없었다...

하지만 아래와 같은 예시처럼 이메일이 도착한다

이메일 도착

💡 느낀 점

• GuardDuty는 활성화만 하면 별도 에이전트 설치 없이 바로 작동한다. "켜기만 하면 되는" 서비스라서 도입 장벽이 낮다. 30일 무료 체험이 있으므로 일단 켜보고 어떤 Findings가 나오는지 확인해보는 것을 권장한다.
• EventBridge + SNS + Lambda 조합으로 "탐지 → 알림 → 자동 대응"까지 파이프라인을 구축할 수 있다는 점이 인상적이었다. 예를 들어, High severity finding이 뜨면 Lambda가 자동으로 해당 IAM 키를 비활성화하는 식의 자동화가 가능하다.
• WAF가 "문 앞의 경비원"이라면, GuardDuty는 "건물 안의 CCTV"에 해당한다. WAF는 들어오는 요청을 필터링하고, GuardDuty는 이미 들어온 후의 이상 행동을 탐지한다. 역할이 다르므로 둘 다 사용해야 한다.

---

학습 정리

• AWS에서 물리적 인프라는 AWS가 책임지고, 데이터와 접근 제어는 고객이 책임진다 (Shared Responsibility Model)
• 클라우드 보안 사이클은 예방 → 탐지 → 대응 → 분석/개선의 순환 구조다
• AWS WAF는 웹 애플리케이션 앞단에서 SQL Injection, XSS, HTTP Flood 등을 실시간으로 차단하는 L7 보안 필터다
• WAF의 핵심 구성: 룰(Rule) → 룰 그룹(Rule Group) → 웹 ACL(Web ACL) → 리소스에 연결
• Amazon GuardDuty는 VPC Flow Logs, CloudTrail, DNS Logs를 ML 기반으로 분석하여 이상 징후를 자동 탐지한다
• GuardDuty + EventBridge + SNS/Lambda 조합으로 탐지 → 알림 → 자동 대응 파이프라인을 구축할 수 있다