네트워크 보안의 계층과 실무 판단 기준
이 에피소드는 애플리케이션 보안과 VPC 격리만으로 막기 어려운 공격을 WAF, Shield, Security Group, NACL, TLS 계층으로 나누어 설명한다. 특히 Managed Rules의 오탐, Shield Standard의 한계, HTTPS 종단과 실무 장애 포인트를 함께 짚는다.
Script Companion
오디오와 함께 스크립트 보기
- 01
네트워크 보안은 애플리케이션 코드 바깥에서 시작되는 공격을 다룬다. XSS나 SQL Injection을 코드 레벨에서 막아도, 악의적인 IP가 포트 스캔으로 취약점을 찾거나 대규모 DDoS로 서버 자원을 고갈시키면 애플리케이션 방어 로직이 실행되기 전에 인프라가 먼저 흔들릴 수 있다. 문서의 비유처럼 네트워크 보안은 성벽이고, 앱 보안은 문지기에 가깝다. 성벽이 없으면 문지기가 아무리 뛰어나도 일할 기회 자체를 잃는다. 실제로 Physics Wallah는 AWS WAF와 Shield 도입 뒤 3개월간 3억 1,500만 건의 악성 요청을 차단했고, DDoS 이벤트 35건을 방어했으며, 대응 속도를 400% 개선했다.
- 02
이 토픽이 필요한 이유는 선행 보안 계층의 한계에서 더 분명해진다. L1 웹 보안의 XSS, CSRF, SQL Injection 대책은 요청이 애플리케이션 코드에 도달한 뒤 동작한다. 그런데 Cloudflare 2025 Q3 DDoS Threat Report 기준으로 분기 8.3M건의 DDoS 중 약 29%, 즉 2.4M건이 L7 HTTP Flood였고, 일부 캠페인은 200M rps를 초과했다. 이런 규모에서는 Node.js 이벤트 루프나 RDS connection pool이 먼저 마비될 수 있다. 반대로 L3 VPC, 서브넷, Security Group, NACL은 IP와 포트 중심의 5-tuple까지만 본다. 정상 포트 443으로 악성 HTTP 페이로드가 들어오면 내용 자체는 검사하지 못한다.
- 03
그래서 이 문서의 핵심 메커니즘은 세 계층으로 나뉜다. 첫째, Shield Standard가 SYN Cookie와 패킷 검증으로 SYN Flood 같은 L3와 L4 대용량 공격을 자동 완화한다. 둘째, WAF가 Web ACL을 통해 본문, 헤더, URL을 OWASP 패턴과 비교해 SQL Injection이나 XSS 같은 HTTP 내용 기반 공격을 검사한다. 셋째, ACM과 ALB가 HTTPS 종단을 맡아 전송 구간 암호화를 강제한다. 이 셋 중 하나가 빠지면 정상 IP와 정상 포트로 들어온 악성 페이로드, 또는 애플리케이션 앞에서 발생하는 대용량 공격 중 일부가 빈틈으로 남는다.
- 04
Security Group과 NACL은 비슷해 보이지만 책임 범위가 다르다. Security Group은 EC2, RDS, Lambda 같은 리소스 앞에 붙는 건물 경비에 가깝고, 한 번 허용된 연결의 응답 트래픽은 자동으로 허용되는 Stateful 방식이다. NACL은 서브넷 입구의 검문소처럼 동작하며, 들어오는 방향과 나가는 방향을 각각 따로 검사하는 Stateless 방식이다. 실무에서는 대부분 Security Group으로 포트와 프로토콜 기반 허용을 관리하고, NACL은 침해 사고 때 특정 IP 범위를 서브넷 전체에서 즉시 차단하는 용도로 활용한다. 즉 기본 운영은 리소스 단위의 최소 허용이고, 비상 차단은 서브넷 단위의 명시적 deny에 가깝다.
- 05
WAF는 IP나 포트가 아니라 HTTP 요청의 내용을 보는 계층이다. 문서의 비유로 말하면 Security Group과 NACL이 비행기 탑승구 입구를 보는 장치라면, WAF는 짐을 열어 보는 공항 보안 검색대다. WAF의 구조는 Web ACL, Rule Group, Rule, Statement로 이어지고, 규칙은 Priority가 낮은 숫자부터 평가된다. AWS Managed Rules는 AWSManagedRulesCommonRuleSet과 AWSManagedRulesSQLiRuleSet 같은 규칙 묶음으로 OWASP Top 10의 80%를 커버하고, 나머지 20%는 커스텀 규칙으로 보완하는 방식이다. 모든 공격 패턴을 직접 쓰는 대신, 관리형 규칙을 기본 방어선으로 두고 서비스별 예외를 얹는 구조다.
- 06
다만 WAF Managed Rules는 보수적으로 작성된다는 점이 중요하다. 공격을 놓치기보다 정상 트래픽을 차단하는 쪽으로 기울어 있기 때문에, 새로 도입하면서 바로 Block 모드로 켜면 정상 요청이 막힐 수 있다. 예를 들어 SizeRestrictions_Body는 큰 body를 보내는 파일 업로드 API나 원격 실행 요청을 막을 수 있고, CrossSiteScripting_BODY는 Quill이나 TipTap 같은 WYSIWYG 에디터의 HTML 본문, Shopify webhook 페이로드와 충돌할 수 있다. GenericRFI_BODY는 Jenkins CI/CD pipeline이 JSON config를 보낼 때 URL-like 필드를 문제로 볼 수 있고, AWSManagedRulesAnonymousIpList는 VPN, Tor, 일부 모바일 캐리어 NAT 출구를 차단할 수 있다.
- 07
WAF 도입 절차는 그래서 관찰을 먼저 두는 쪽이 안전하다. 신규 도입 시 Count 모드로 최소 2주 동안 운영하고, Sampled Requests로 어떤 규칙이 어떤 정상 트래픽에 매칭되는지 확인한다. 문제가 되는 정상 요청이 있으면 특정 URI에 Scope-down을 적용하거나, 해당 규칙의 OverrideAction을 Count로 두고 나머지만 Block 모드로 전환한다. 비용 판단도 함께 필요하다. Web ACL은 월 5달러, 규칙은 개당 월 1달러, 요청 처리는 백만 건당 0.60달러, Managed Rule Group은 그룹당 월 1달러에서 10달러다. 문서의 예시에서는 10억 req/월일 때 WAF 소계가 620달러이고, Shield Advanced를 포함하면 3,620달러가 된다.
- 08
Shield는 DDoS 방어를 맡지만 Standard와 Advanced의 기대 역할은 다르다. Shield Standard는 모든 계정에 무료로 기본 적용되며 L3와 L4 DDoS를 자동 완화한다. 패킷 검증으로 IP, TCP, UDP, ICMP, DNS, NTP 형식 위반 패킷을 차단하고, TCP SYN Proxy는 SYN Cookie로 실제 클라이언트인지 확인한 뒤 연결을 허용한다. 특정 IP에서 비정상적으로 많은 패킷이 오면 속도 제한도 걸 수 있다. 반면 L7 HTTP Flood는 Standard가 직접 완화하지 않으므로 WAF의 Rate-based Rule 같은 별도 설계가 필요하다. Shield Advanced는 월 3,000달러에 L7 DDoS 자동 대응, 비용 보호, 24/7 DRT 지원, 상세 공격 보고서를 제공한다.
- 09
Shield Standard만으로 부족한 경우도 문서가 정량적으로 짚는다. Standard는 AWS 백본 전체 기준으로 비정상이라고 판단되는 정적 임계값에 기대기 때문에, 5 Gbit/s SYN Flood가 AWS 기준으로 small로 취급되어 자동 완화가 트리거되지 않을 수 있다. 단일 ALB나 EC2 입장에서는 충분히 장애가 날 규모라도 글로벌 임계값을 넘지 않으면 통과할 수 있는 것이다. 또 Standard는 대시보드, CloudWatch 메트릭, 공격 후 리포트를 제공하지 않아 공격이 있었는지조차 모르는 silent failure가 생길 수 있다. 평시 1k rps 서비스가 100k rps burst를 받으면 5xx가 나는 상황, SLA 99.95% 이상, 1시간 공격 시 NAT나 데이터 전송 비용 5,000달러 이상, 24시간 응답 팀 부재 중 하나라도 해당되면 Advanced나 대안을 검토한다.
- 10
TLS 종단은 암호화된 HTTPS 트래픽을 어디에서 풀 것인가의 문제다. 문서에서는 ALB가 클라이언트의 HTTPS 요청을 받아 복호화한 뒤 백엔드에는 HTTP로 전달하는 구조를 TLS Termination으로 설명한다. 이 방식은 백엔드가 암호화 작업을 하지 않아 부하가 낮고, 인증서도 ALB만 관리하면 된다. ACM으로 무료 인증서를 발급해 ALB에 붙이는 일반 웹 서비스에 잘 맞는다. 반대로 End-to-End 암호화는 백엔드까지 암호화를 유지하므로 VPC 내부도 암호화되지만, 모든 인스턴스의 인증서 관리가 필요하고 부하도 커진다. 금융, 의료처럼 규정 준수가 필요한 경우에는 이 쪽이 더 적합할 수 있다.
- 11
프론트엔드와 플랫폼 업무가 만나는 지점도 여기에 있다. HTTPS 페이지에서 HTTP 리소스나 HTTP API를 호출하면 브라우저는 Mixed Content 에러로 차단한다. 프론트 코드에서 fetch가 실패해도 원인이 단순히 코드에만 있지 않을 수 있고, ALB의 HTTP에서 HTTPS 리다이렉트나 인프라 설정이 빠진 문제일 수 있다. 또 API 호출에서 갑자기 403이 오면 CORS로 보이지만 실제로는 WAF 규칙이 차단한 경우도 있다. WYSIWYG 에디터가 HTML 콘텐츠를 보내면서 script 태그나 onerror 패턴이 포함되면 XSS 규칙에 걸릴 수 있다. 이때는 프론트와 플랫폼이 함께 WAF 로그와 Sampled Requests를 보고 예외 규칙 범위를 좁혀야 한다.
- 12
트러블슈팅에서는 증상과 계층을 분리해서 보는 습관이 중요하다. 정상 API 요청이 403으로 막히고 CloudWatch에서 WAF 차단 메트릭이 증가한다면, Managed Rules가 Body, 헤더, URL 파라미터를 SQL Injection이나 XSS로 오탐지했을 가능성을 먼저 본다. VPC Flow Logs에서 내부 서비스 10.0.0.100이 RDS 10.0.1.45:5432로 가는 요청까지 REJECT된다면, Security Group과 NACL 중 어느 쪽이 차단하는지 순서대로 확인해야 한다. ALB의 ACM 인증서가 만료되어 NET::ERR_CERT_DATE_INVALID가 보이면, DNS 검증용 CNAME 레코드가 삭제되었거나 외부 DNS에서 수동 갱신이 누락된 상황을 의심한다. ALB Target Group이 unhealthy이고 502가 난다면 Health Check 포트를 Security Group이 허용하는지도 확인한다.
- 13
정리하면, 네트워크 보안은 Security Group, NACL, WAF, Shield, TLS가 서로 다른 층에서 다른 질문에 답하는 구조다. Security Group과 NACL은 누가 어느 포트로 들어오는가를 보고, WAF는 HTTP 내용에 SQL Injection이나 XSS 같은 패턴이 있는지 본다. Shield는 SYN Flood, UDP Flood, HTTP Flood 같은 DDoS 대응의 범위와 가시성을 나누고, TLS 종단은 암호화 책임을 ALB에서 끝낼지 백엔드까지 가져갈지 결정한다. 실무 기본 조합은 Security Group과 ALB 앞단 WAF이며, Managed Rules는 Count 모드 관찰 후 Block으로 전환한다. 2025년 AWS WAF Bot Control 고급 모드는 AI 기반 봇 탐지 정확도가 향상되었지만, 기본 요금 10달러 백만 요청보다 추가 비용이 발생하므로 비용 분석 뒤 도입해야 한다.
같은 레이어