.png){kind=small}
안녕하세요. 웹 서비스를 운영하다 보면 SQL Injection이나 XSS 같은 공격, 혹은 의미 없는 트래픽으로 서버를 괴롭히는 봇(Bot)들 때문에 골머리를 앓게 됩니다.
이때 가장 먼저 도입하는 것이 AWS WAF입니다. 하지만 콘솔에 들어가 보면 수많은 규칙들 앞에서 막막해지죠. "AWS가 주는 거 다 켜면 되나? 그럼 내 서비스 느려지나?"
오늘은 AWS WAF의 핵심인 Web ACL 규칙 설계 전략을 실무 관점에서 정리해 드립니다.
1. WAF 규칙의 두 가지 기둥
AWS WAF 규칙은 크게 두 가지로 나뉩니다. 이 둘을 적절히 섞어 쓰는 것이 핵심입니다.
① AWS Managed Rules (관리형 규칙)
AWS 보안 팀이나 보안 전문 업체(Fortinet 등)가 미리 만들어둔 **"종합 선물 세트"**입니다.
장점: 최신 공격 패턴(CVE 등)이 나오면 알아서 업데이트됩니다. SQL Injection, XSS 같은 복잡한 패턴을 직접 짤 필요가 없습니다.
단점: 범용적이라서 우리 서비스 정상 트래픽을 공격으로 오해하는 **오탐(False Positive)**이 발생할 수 있습니다.
필수 추천: AWSManagedRulesCommonRuleSet (OWASP Top 10 방어)
② Custom Rules (사용자 지정 규칙)
내가 직접 만드는 **"맞춤형 규칙"**입니다.
장점: 우리 서비스 특성에 딱 맞는 정교한 제어가 가능합니다. (예: 특정 URL은 한국에서만 접속 허용)
단점: 직접 유지보수해야 합니다.
2. 규칙 배치 순서 (Priority) 전략 : "깔대기 이론"
WAF는 규칙을 위에서부터 아래로 순서대로(Priority) 검사합니다. 앞에서 Block이나 Allow로 결정나면 뒤에 있는 규칙은 쳐다보지도 않습니다. 따라서 순서가 성능과 비용을 좌우합니다.
가장 권장하는 순서는 다음과 같습니다.
Step 1. 화이트리스트 (Allow List) - "VIP 프리패스"
가장 먼저, 무조건 통과시켜야 할 대상을 검사합니다.
예시: 사무실 공인 IP, 모니터링 서버 IP, 개발자 VPN IP.
이유: 우리 직원이 SQL 문법이 들어간 테스트를 하다가 차단당하면 안 되니까요. 그리고 뒤에 있는 무거운 규칙들을 거치지 않게 해서 WAF 비용(WCU)을 아낄 수 있습니다.
Step 2. 블랙리스트 & 지역 차단 (Block List) - "입구 컷"
명확하게 나쁜 놈들은 입구에서 바로 돌려보냅니다.
예시: 서비스하지 않는 국가(Geo-blocking), 악성 봇 IP 대역, 토르(Tor) 노드 IP.
효과: 불필요한 트래픽이 애플리케이션까지 도달하지 않게 하여 서버 부하를 줄입니다.
Step 3. 속도 제한 (Rate-based Rules) - "도배 금지"
특정 IP가 짧은 시간 동안 너무 많은 요청을 보내면 차단합니다. (DDoS 방어의 핵심)
설정 예시: "5분 동안 500회 이상 요청 시 해당 IP 5분간 차단"
팁: 로그인 페이지(/login) 같은 곳은 기준을 더 엄격하게(5분에 20회) 잡아서 무차별 대입 공격(Brute Force)을 막습니다.
Step 4. 관리형 규칙 (Managed Rules) - "정밀 검사"
위 단계를 모두 통과한 트래픽에 대해, 실제 해킹 시도인지 패턴을 검사합니다.
Core Rule Set (CRS): 일반적인 웹 공격 차단.
SQL database: SQL Injection 차단.
Linux/Unix: OS 명령어 주입 차단.
3. 실전 꿀팁: 오탐(False Positive) 줄이는 법
WAF를 처음 도입할 때 가장 무서운 건 **"멀쩡한 고객을 차단하는 것"**입니다. 이를 방지하기 위한 안전장치 2가지를 소개합니다.
① 처음엔 'Count Mode'로 시작하라
규칙을 추가할 때 Action을 Block이 아니라 **Count**로 설정하세요.
기능: 차단은 안 하고, "이거 차단될 뻔했음" 하고 로그만 남깁니다.
운영법: 일주일 정도 Count로 돌려보고, 로그를 분석해서 정상 유저가 걸리는지 확인한 뒤 Block으로 전환합니다.
② Scope-down Statement (예외 처리) 활용
Managed Rule이 너무 강력해서 정상 요청까지 막는다면? 규칙 전체를 끄지 말고 예외를 두세요.
상황: 게시판에 글을 쓰는데 HTML 태그(<br>)를 넣었더니 XSS 공격이라고 차단함.
해결: "XSS 규칙을 적용하되, URL이 /board/write 인 경우엔 Body 검사는 하지 마라"는 식으로 조건을 좁힐(Scope-down) 수 있습니다.
4. WCU (Web ACL Capacity Units) 관리
WAF 규칙은 공짜가 아닙니다. 규칙마다 WCU라는 비용(가중치)이 있습니다.
기본 한도: 1,500 WCU (요청 시 5,000까지 증설 가능)
사용 예시:
간단한 IP 차단 규칙: 1 WCU
AWS Core Rule Set: 700 WCU (엄청 무거움)
따라서 무작정 Managed Rule을 다 켜면 WCU 한도가 꽉 차서 정작 필요한 Custom Rule을 못 넣을 수 있습니다. 꼭 필요한 규칙만 선별해서 담는 것이 중요합니다.
마치며
"WAF는 방패입니다. 하지만 너무 무거운 방패는 기사를 지치게 합니다."
화이트리스트 → 블랙리스트 → Rate Limit → Managed Rule 순서를 기억하세요.
처음엔 Count Mode로 간을 보세요.
WCU를 고려해서 꼭 필요한 규칙만 활성화하세요.
이 세 가지만 지켜도 보안은 튼튼해지고, 오탐으로 인한 장애는 획기적으로 줄어들 것입니다.
