Cloudflare WAF란 무엇이고, 무엇을 막지 못하는가

“WAF는 켜 두셨습니까.” 보안 점검 결과지나 고객사 보안 문진표에서 이 질문을 받으면, 대개 켰는지 여부보다 그것이 무엇을 해 주는 장치인지가 더 궁금해집니다. 제품 설명은 검색으로 금방 나오지만, 켠 다음에 무엇이 남는가는 대개 답을 찾지 못한 채 넘어갑니다.

이 글은 웹 방화벽의 기능 소개가 아니라 경계선에 무게를 둡니다. 도입을 판단할 때 실제로 필요한 것은 무엇을 걸러 주는가보다, 걸러진 다음에도 그대로 남는 것이 무엇인가이기 때문입니다.

WAF는 무엇을 검사하는 장치인가

WAF(Web Application Firewall, 웹 방화벽)는 웹 요청의 내용을 읽고 통과 여부를 판단하는 장치입니다. 통신을 열어 줄지 말지를 주소와 포트로 정하는 장치와는 보는 대상이 다릅니다.

구체적으로 WAF가 읽는 것은 요청 한 건을 이루는 재료들입니다.

• 요청 경로와 질의 문자열 — 어떤 주소로 무슨 값을 붙여 들어왔는지
• 요청 헤더 — 어떤 클라이언트를 자처하는지, 어떤 쿠키와 토큰을 들고 있는지
• 요청 본문 — 폼 입력과 API 페이로드에 무엇이 담겼는지
• 출처 정보 — 어느 IP·지역·네트워크에서 왔는지

층위로 보면 차이가 분명해집니다.

같은 문을 지키더라도 하나는 문을 열지 말지를 정하고, 다른 하나는 들어온 사람이 들고 있는 물건을 봅니다. 그래서 둘은 대체 관계가 아니라 나란히 놓이는 관계입니다. 웹 서비스에서 443 포트는 어차피 열어 둘 수밖에 없고, 열린 문으로 들어오는 요청의 내용을 보는 자리가 비어 있는 것이 WAF가 채우는 자리입니다.

Cloudflare WAF는 어디에서 동작하는가

Cloudflare WAF는 오리진(요청을 실제로 처리하는 원본 서버)이 아니라 Cloudflare의 엣지 네트워크에서 요청을 검사합니다. 도메인의 트래픽이 Cloudflare를 거쳐 들어오도록 구성돼 있을 때, 검사는 요청이 오리진에 닿기 전에 끝납니다. 차단된 요청은 오리진의 애플리케이션 로그에 남지 않습니다.

검사 규칙은 성격이 다른 세 갈래로 나뉩니다. Cloudflare의 WAF 문서가 이 구분을 그대로 쓰고 있습니다.

• 관리형 룰셋(Managed Rules) — Cloudflare가 만들어 유지하는 규칙 묶음입니다. 알려진 공격 기법과 새로 발견된 취약점을 다루며, 위협 상황에 맞춰 지속적으로 갱신됩니다. 사용자는 켜고 끄거나 동작을 조정합니다.
• 사용자 지정 규칙(Custom Rules) — 우리 서비스의 사정을 반영해 직접 쓰는 조건식입니다. 특정 경로를 특정 조건에서만 허용하는 식의 규칙이 여기에 들어갑니다.
• 속도 제한 규칙(Rate Limiting Rules) — 같은 클라이언트가 정해진 기간에 보내는 요청 수를 세어 임계를 넘으면 조치합니다. 로그인 시도를 반복하는 무차별 대입이나 API 남용이 주 대상입니다.

규칙이 걸렸을 때 무엇을 할지도 선택 사항입니다. 요청을 거절하는 차단, 사람인지 확인하는 챌린지, 그리고 실제 조치 없이 기록만 남기는 검증용 동작(Enterprise 요금제에서 제공)이 별도의 액션으로 정의돼 있습니다. 이 선택이 뒤에서 다룰 착시의 출발점입니다.

웹 방화벽이 실제로 막아 주는 요청

웹 방화벽이 잘 걸러 내는 것은 모양으로 판별되는 공격입니다. 요청 안에 남는 흔적이 알려진 형태를 띠는 부류입니다.

• 주입 계열 공격 — SQL 구문이나 스크립트 조각, 시스템 명령을 입력값에 섞어 보내는 시도입니다. 문자열 자체에 특징이 남아 패턴으로 잡힙니다.
• 알려진 취약점을 노린 요청 — 특정 프레임워크나 플러그인의 공개된 취약점을 겨냥한 요청은 경로와 파라미터의 조합이 정형화돼 있습니다.
• 자동화 스캔 — 취약점 스캐너는 존재하지 않는 관리자 경로와 백업 파일 이름을 순서대로 두드립니다. 사람의 이용과 뚜렷이 구분되는 행동입니다.
• 자격증명 대입 — 유출된 계정 목록을 로그인 화면에 밀어 넣는 시도는 속도 제한 규칙이 다루는 영역입니다.

여기서 실무적으로 큰 이득은 공개된 취약점과 패치 사이의 시간을 버는 데 있습니다. 취약점이 공개되면 그것을 노리는 자동화 요청은 곧바로 늘어나는데, 애플리케이션이나 라이브러리를 올리는 일정은 그 속도를 따라가지 못하는 경우가 많습니다. 관리형 룰셋이 앞단에서 해당 패턴을 걸러 주는 동안 패치를 준비할 여유가 생깁니다. 다만 이것은 시간을 버는 조치이지 패치를 대신하는 조치가 아닙니다.

웹 방화벽이 막지 못하는 것

웹 방화벽이 다루지 못하는 것은 형식상 완전히 정상인 요청으로 이뤄지는 공격입니다. 이 글에서 가장 중요한 부분이고, 도입 판단이 갈리는 지점도 여기입니다.

• 접근 통제 결함 — 로그인한 사용자가 주소창의 식별자를 남의 것으로 바꿔 조회하는 경우입니다. 요청의 모양은 그 사용자가 평소 보내는 것과 똑같고, 다른 점은 그 자원을 볼 권한이 있느냐뿐입니다. 권한은 애플리케이션만 압니다. 애플리케이션 보안 자료를 공개하는 비영리 재단 OWASP가 접근 통제 실패를 상위 위험으로 두고, API 영역에서도 객체 수준 인가 실패를 첫 항목으로 두는 이유입니다.
• 인증 설계 결함 — 비밀번호 재설정 절차의 허점, 만료되지 않는 토큰, 다단계 인증을 건너뛰는 경로 같은 문제입니다. 공격자가 보내는 요청 자체는 정상 절차를 따릅니다.
• 비즈니스 로직 오류 — 할인 쿠폰을 중복 적용하거나 결제 확정 전에 배송을 확정시키는 식으로, 각 요청은 유효한데 순서와 조합이 의도를 벗어나는 경우입니다. 무엇이 옳은 순서인지는 그 서비스의 규칙에만 적혀 있습니다.
• 유출된 정상 자격증명 — 실제 계정으로 로그인해 정상 권한 안에서 데이터를 가져가는 행위는 방화벽이 구분할 근거가 없습니다.
• 오리진으로 오는 직접 요청 — 엣지를 거치지 않고 서버 주소로 바로 오는 요청은 검사를 받지 않습니다. 이 통로가 열려 있으면 규칙을 아무리 촘촘히 만들어도 우회됩니다.
• 내부에서 시작되는 문제 — 권한이 과도한 운영 계정, 오래된 의존성 라이브러리, 관리 콘솔의 접근 통제는 웹 요청의 바깥에 있는 문제입니다.

정리하면 이렇습니다. WAF는 요청의 모양을 보고, 요청의 권한과 의도는 애플리케이션만 압니다. 그래서 웹 방화벽은 들어오는 공격의 양을 크게 줄이지만, 남아 있는 위험의 성격을 바꾸지는 못합니다. 애플리케이션 코드의 취약점은 방화벽으로 대신 막을 수 없습니다.

“켜져 있다”가 “막고 있다”는 뜻은 아닙니다

웹 방화벽이 활성화된 상태와 실제로 요청을 막고 있는 상태는 같지 않습니다. 도입 후 점검에서 어긋나기 쉬운 부분이고, 콘솔에서 확인 가능한 항목이기도 합니다.

어긋나는 자리는 대체로 넷입니다.

1. 규칙이 차단이 아닌 동작으로 설정된 경우 — 검증용 기록 동작(Enterprise)이거나, 오탐 때문에 비활성화하거나 챌린지로 낮춰 둔 채 그대로 남는 경우입니다. 기록은 쌓이는데 요청은 전부 통과합니다.
2. 예외가 쌓여 사실상 통로가 생긴 경우 — 오탐이 날 때마다 넓은 조건으로 예외를 만들면, 그 조건에 맞춘 요청은 검사를 건너뜁니다. 예외는 설정 재정의보다 우선해 적용되므로, 재정의(override)로는 예외를 되돌릴 수 없습니다.
3. 예외를 만든 층과 규칙이 있는 층이 다른 경우 — 설정은 도메인 하나(존)에 걸 수도 있고 계정 전체에 걸 수도 있습니다. 이 둘은 서로의 예외를 인정하지 않습니다. 계정 단위 예외는 계정 단위 규칙에만, 존 단위 예외는 존 단위 규칙에만 적용됩니다. 존에서 예외를 만들었는데 규칙이 계정 쪽에 있으면 예외가 동작하지 않고, 반대 상황도 생깁니다.
4. 검사 범위 밖으로 나간 경우 — 관리형 규칙이 요청 본문을 검사하는 크기에는 상한이 있고, 그 값은 사용 중인 요금제에 따라 다릅니다. 큰 파일이나 큰 페이로드를 다루는 엔드포인트라면 검사 범위를 확인해 두는 편이 좋습니다. 속도 제한 역시 정확한 요청 수를 보장하도록 설계된 기능이 아니며, 집계 지연 때문에 초과분 일부가 오리진에 닿을 수 있습니다.

확인은 추측이 아니라 화면에서 합니다. Cloudflare 대시보드의 Security Events는 조치되거나 표시된 요청을 이벤트 단위로 보여 주고, 어떤 기능이 어떤 동작을 적용했는지를 함께 남깁니다. 대시보드 세대에 따라 Analytics 페이지의 Events 탭 또는 Security > Events 위치에 있습니다. 여기서 동작 기준으로 필터를 걸어 차단이 실제로 일어나고 있는지 보고, 개별 이벤트를 펼치면 어떤 규칙이 걸렸는지 확인할 수 있습니다. 보관 기간과 사용 가능한 화면은 요금제에 따라 다르므로, 조사가 필요한 사건은 기간이 지나기 전에 내려받아 두시는 편이 낫습니다.

응답 쪽에서도 단서가 남습니다. 대부분의 보안 기능이 차단할 때는 403이, 속도 제한이 걸릴 때는 429가 돌아옵니다. 사용자가 “갑자기 화면이 안 열린다”고 알려 왔을 때 어느 쪽 코드였는지만 확인해도 찾아볼 자리가 좁혀집니다.

문진표에 적을 것은 대개 넷입니다 — 어떤 규칙 묶음을 켰는지, 그 동작이 차단인지 기록인지, 예외가 몇 개이고 사유가 남아 있는지, 마지막으로 규칙을 검토한 날짜가 언제인지. 이 넷을 적을 수 있으면 “켜 두었다”가 아니라 “운용하고 있다”가 됩니다.

오탐은 왜 생기고 어떻게 다루는가

오탐은 정상 업무 요청이 공격 패턴과 닮았을 때 생깁니다. 결함이라기보다 패턴으로 판단하는 방식의 성질에 가깝습니다.

Cloudflare가 제공하는 OWASP Core Ruleset은 이 성질을 점수로 다룹니다. 규칙 하나하나에 점수가 있고, 한 요청에 걸린 규칙들의 점수가 쌓여 정해진 임계값을 넘을 때 조치가 실행됩니다. 여기에 규칙의 공격성을 단계로 나눈 설정이 함께 있어서, 단계를 올리면 방어 범위가 넓어지는 대신 정상 요청이 걸릴 여지도 함께 늘어납니다. 즉 오탐과 미탐(공격인데 통과시키는 것)은 한쪽을 줄이면 다른 쪽이 늘어나는 관계에 있고, 그 균형점은 서비스마다 다릅니다.

본문에 코드나 특수문자가 들어가는 게시판, 파일 업로드 화면, 파라미터가 긴 조회 화면은 정상 요청이 공격 패턴과 닮기 쉬운 자리입니다.

다룰 때의 원칙은 하나입니다. 끄는 것이 아니라 좁히는 것입니다.

• 룰셋 전체나 상위 규칙군을 끄지 말고, 걸린 규칙을 특정해 그 규칙만 조정합니다.
• 예외는 조건을 좁게 씁니다. 경로 하나와 요청 방식 하나로 한정할 수 있으면 그렇게 하고, IP 대역 전체나 경로 전체를 여는 형태는 마지막 수단으로 둡니다.
• 예외마다 사유와 만든 날짜를 남깁니다. 남기지 않으면 몇 달 뒤에 그 예외를 지워도 되는지 판단할 근거가 없어집니다.

빌드업웍스의 운영 경험에서는, 예외를 만드는 일보다 만든 예외를 되돌아보는 절차가 없는 쪽을 더 무겁게 봅니다. 임시로 넓게 열어 둔 조건이 임시라는 사실을 아무도 기억하지 못한 채 남습니다.

한 번 켜고 끝나지 않는 이유

웹 방화벽 설정은 서비스가 바뀌면 함께 바뀌어야 합니다. 규칙이 판단하는 기준은 정상 요청이 어떤 모양인가인데, 그 모양은 서비스가 바뀔 때마다 달라지기 때문입니다.

바뀌는 쪽은 양방향입니다. 우리 쪽에서는 새 API 엔드포인트가 생기고, 폼에 필드가 추가되고, 외부 연동이 붙고, 관리자 화면이 늘어납니다. 바깥에서는 새 취약점이 공개되고 그것을 노리는 요청이 곧바로 나타납니다. 관리형 룰셋은 후자를 Cloudflare가 갱신해 주지만, 전자는 서비스를 아는 사람만 반영할 수 있습니다.

그래서 운용의 실질은 정기적인 확인 습관입니다. 차단 기록을 주기적으로 열어 정상 요청이 섞여 있지 않은지 보고, 배포로 요청의 모양이 달라졌다면 그에 맞춰 규칙을 손보고, 오래된 예외를 정리하는 일입니다. 제품 선택보다 이 습관의 유무가 결과를 더 크게 가릅니다.

WAF 다음에 무엇을 볼 것인가

웹 방화벽으로 줄지 않는 위험은 별도의 수단으로 다뤄야 합니다. 방화벽이 막지 못하는 항목의 목록이 그대로 다음 과제의 목록이 됩니다.

• 권한 설계 점검 — 사용자가 자기 것이 아닌 자원을 요청했을 때 애플리케이션이 거절하는지, 화면이 아니라 서버에서 확인합니다.
• 의존성 관리 — 사용 중인 라이브러리와 프레임워크의 버전, 그리고 알려진 취약점 여부를 주기적으로 확인합니다.
• 오리진 접근 통제 — 엣지를 거치지 않고 서버로 직접 오는 경로가 열려 있는지 확인합니다. 확인은 어렵지 않습니다 — 도메인이 아니라 서버 주소로 직접 요청을 보내 정상 응답이 오는지 보면 됩니다. 응답이 그대로 돌아오면 그 경로는 검사를 받지 않고 있는 것입니다. AWS 앞단에 Cloudflare를 두는 구성에서 이 부분이 어떻게 어긋나는지와 구체적인 확인 절차는 AWS와 Cloudflare를 함께 쓸 때 깨지는 자리에서 따로 다룹니다.
• 관리 접근 통제 — 관리자 화면과 내부 도구에 누가 어떤 경로로 접근하는지 정리합니다. 이 문제를 VPN이 아닌 방식으로 다루는 접근은 Zero Trust와 VPN의 차이에서 비교했습니다.

여기서 한 가지 덧붙이면, 탐지 규칙을 구성하는 일과 24시간 사람이 화면을 지켜보는 상시 관제는 서로 다른 일입니다. 규칙 구성과 자동 탐지·알림은 계약 범위 안에서 다루지만, 상시 관제는 그것을 전업으로 하는 전문 업체를 함께 붙이며 별도 비용이 발생합니다. 어디까지가 누구의 몫인지를 계약 전에 나눠 적어 두는 편이 나중에 인식 차이를 줄입니다.

다음 단계

지금 무엇이 부족한지 아직 정리되지 않았다면, 웹 방화벽만 떼어 보기보다 보안 상태 전체를 한 번 훑어 보시는 편이 순서상 앞섭니다. 보안 자가진단은 접근통제·인증, 네트워크 보안, 데이터 보호, 로깅·탐지·대응, 컴플라이언스, Zero Trust 성숙도를 나눠 점검하고, 연락처를 남기지 않아도 결과와 우선 과제를 바로 보여 드립니다. 이 글에서 다룬 내용은 그중 네트워크 보안 항목의 배경에 해당합니다.

방어 계층이 실제로 어떻게 나뉘는지 먼저 보고 싶으시면 통합 보안 서비스 범위를 보십시오. 엣지·네트워크·데이터·탐지 네 층이 각각 무엇을 맡는지 확인하실 수 있습니다. 탐지 규칙과 알림을 어떻게 구성하는지는 보안 관제·위협 탐지 구성에 정리돼 있습니다. 우리 서비스 기준으로는 어디부터 손봐야 하는지 함께 보고 싶으시면 상담 신청으로 알려 주십시오.

참고 자료

• Cloudflare Docs — WAF 개요
• Cloudflare Docs — Managed Rules
• Cloudflare Docs — OWASP Core Ruleset 개념(점수·임계값)
• Cloudflare Docs — 관리형 룰셋 예외 만들기
• Cloudflare Docs — Rate limiting rules
• Cloudflare Docs — Security Events
• Cloudflare Docs — Rules language: Actions
• OWASP Top 10
• OWASP API Security Top 10 — Broken Object Level Authorization