[클라우드 보안 실무 #2] AWS WAF, 실무자들이 자주 저지르는 실수 5가지

 

 

AWS WAF는 기본적인 Web Application 방어에 유용한 도구지만, 실무에서 잘못 설정하거나 운영 전략 없이 사용하면 보안 효과가 반감되거나 오히려 리스크를 유발할 수 있습니다. 다양한 산업군에서 WAF를 설계하고 운영하면서 겪은 실제 사례를 기반으로, 실무에서 흔히 발생하는 WAF 설정 실수들을 정리합니다.

✨ 본문 핵심 요약

• 우선순위 설계 오류
• 과도한 차단 우선주의
• Count/Label 전략 미활용
• 로그인 경로 보호 누락
• Managed Rule 과신

---

🔹 1. 우선순위(Priority) 설계가 충돌난다

WAF의 룰은 숫자가 낮을수록 먼저 평가되며, 충돌 시 우선순위가 높은 룰만 적용됩니다. 실무에서는 비슷한 패턴을 다룰 룰을 중복 적용하거나, 특정 필터가 먼저 실행되어 후속 룰이 무력화되는 경우가 많습니다.

🔧 실무 팁:

• 100, 200, 300 단위로 그룹핑해 우선순위를 명확히 관리하세요.
• 룰 이름에 역할과 그룹을 함께 명시해 추후 분석을 쉽게 합니다. (예: 200_UA_SQLi_Block)

 

🔹 2. 모든 룰을 Block으로만 구성한다 (Count/Label 미사용)

신규 룰을 곧바로 Block 모드로 설정하면 오탐 발생 시 서비스에 직접적인 영향이 생깁니다. 특히 비즈니스 경로에 대한 룰을 신중하게 운영해야 합니다.

🔧 실무 팁:

• 신규 룰은 반드시 Count 모드로 먼저 운영하며 트래픽 패턴을 수집하세요.
• 라벨을 부여해 탐지 로그를 분류하고, 일정 기간 관찰 후 차단으로 전환합니다.

 

🔹 3. 로그인 경로 보호를 간과한다

많은 구성에서 “/admin”, “/login” 경로에 별도 룰이 없는 경우가 많습니다. 이는 Credential Stuffing, Bot 로그인 공격에 취약하게 만듭니다.

🔧 실무 팁:

• 로그인 경로에 대해서는 Bot Control, CAPTCHA, UA 필터링 등을 따로 구성하세요.
• 내부 사용자 접근이 필요한 경로는 Geo/IP 기반 화이트리스트를 병행하세요.

 

🔹 4. Managed Rule Set만 믿고 방치한다

AWS에서 제공하는 Managed Rule Set은 출발점일 뿐, 실제 환경에 맞게 수정/제외 처리가 필요합니다. 특정 룰셋에서 정상 요청을 반복 차단하는 사례가 많습니다.

🔧 실무 팁:

• Managed Rule은 Count 모드로 먼저 적용하고 분석하세요.
• 반복 오탐 룰은 Disable하거나 라벨링 후 경고만 발생시키는 방식으로 운영하세요.

 

🔹 5. 로그를 쌓기만 하고, 활용하지 않는다

WAF 로그는 보안 운영의 가장 중요한 데이터 자산입니다. 하지만 실무에서는 대부분 S3에 저장만 하고, 분석이나 연계 작업은 이루어지지 않는 경우가 많습니다.

🔧 실무 팁:

• WAF → Kinesis → Lambda → Slack/Email 알림 구조를 구성하세요.
• 이상 징후가 발생하면 즉시 알림과 함께 탐지 근거를 대시보드로 시각화하는 구조가 필요합니다.

 

---

📃 마무리하며

WAF는 단순한 룰 설정 도구가 아닌, 클라우드 보안 운영의 핵심 도구입니다. 실무에서는 서비스 성격에 맞는 운영 전략, 탐지와 대응의 균형, 그리고 데이터 기반의 개선 루틴이 필요합니다.

 

 

✨ 이 글이 도움이 되셨다면 댓글에 의견을 남겨주세요. 더 나은 실무 노하우를 공유하는 데 큰 힘이 됩니다.