Cloudflare WAF와 AWS WAF는 무엇이 다릅니까

웹 방화벽을 도입하기로 하면 곧바로 어느 제품을 고를지의 문제가 됩니다. 그런데 기능 목록을 나란히 놓고 비교하면 답이 잘 나오지 않습니다. 두 제품이 하는 일은 거의 같기 때문입니다.

실제로 갈리는 것은 기능이 아니라 요청의 경로에서 어디에 서 있느냐입니다. 이 글은 그 자리 차이가 무엇을 바꾸는지, 그리고 우리 구성에서는 어느 쪽이 맞는지를 판단하는 순서로 정리합니다.

같은 일을 합니다

두 제품 모두 요청 하나하나의 내용, 즉 경로와 질의 문자열, 헤더, 본문을 읽어 알려진 공격 패턴인지 판정하는 애플리케이션 계층 장치입니다. 주입 계열 시도, 공개된 취약점을 노린 정형화된 요청, 자동화된 스캔처럼 요청 한 건에 특징이 남는 공격을 걸러 냅니다.

양쪽 다 제공사가 관리하는 규칙 묶음을 켜고 시작할 수 있고, 직접 만든 규칙과 속도 제한을 함께 둘 수 있습니다. 웹 방화벽이 무엇을 걸러 내고 무엇을 걸러 내지 못하는지는 Cloudflare WAF가 막는 것과 막지 못하는 것에서 다뤘고, 트래픽의 양을 보는 방어와 어떻게 다른지는 DDoS 방어와 WAF는 무엇이 다릅니까에 있습니다.

갈리는 것은 서는 자리입니다

이 표의 마지막 두 행이 실무에서 가장 자주 문제가 됩니다.

적용 단위가 다릅니다

엣지 방식은 도메인 단위로 걸리므로 그 도메인으로 오는 트래픽을 한 지점에서 다룹니다. AWS WAF는 리소스 단위라, 같은 서비스라도 경로가 여러 리소스로 나뉘어 있으면 각각에 적용했는지 따로 확인해야 합니다. 리소스가 늘어날 때 적용이 자동으로 따라붙지 않는다는 뜻이기도 합니다.

걸러진 트래픽이 어디까지 오는가

엣지에서 막으면 그 요청은 원본 서버까지 오지 않습니다. AWS WAF는 AWS 경계 안에서 판정하므로, 막히더라도 그 지점까지는 도달합니다. 보안 판정 자체는 같지만 트래픽이 어디까지 들어왔는가가 달라지고, 이는 대량 트래픽 상황에서 특히 의미가 있습니다.

로그가 나뉘면 조사도 나뉩니다

사고를 조사할 때는 방화벽 로그와 애플리케이션 로그를 함께 놓고 봐야 합니다. 방어를 엣지에 두면 그 기록은 엣지 쪽에 남고, AWS 안에 두면 나머지 AWS 로그와 같은 자리에 남습니다. 어느 쪽이 옳다기보다, 평소 조사를 어디서 하는지와 맞추는 편이 사고 당일에 시간을 아낍니다.

겹쳐 두면 생기는 일

둘 다 켜면 더 안전할 것 같지만, 먼저 오는 것은 운영 비용입니다.

같은 성격의 규칙을 두 계층에 두면 정상 요청이 차단됐을 때 어느 쪽이 막았는지 가리는 일부터 시작해야 합니다. 규칙을 고칠 때도 양쪽을 함께 확인해야 하고, 한쪽만 고치면 그 차이가 조용히 남습니다. 시간이 지나면 두 벌의 규칙이 서로 다른 상태가 되는데, 그 사실은 평소에는 드러나지 않습니다.

그래서 두 곳을 다 쓰더라도 역할을 나누는 편이 낫습니다. 공통 규칙은 한쪽에서 관리하고, 다른 쪽은 그 계층에서만 판단할 수 있는 것을 맡기는 식입니다. 규칙의 관리 지점을 한 곳으로 정하는 것이 이 구성의 출발점입니다.

어느 쪽인지 정하는 순서

1. 트래픽 경로를 전부 적습니다. 웹 브라우저로 오는 것뿐 아니라 모바일 앱, 파트너 연동, 내부 도구가 부르는 엔드포인트까지 포함합니다.
2. 각 경로가 엣지를 거치는지 표시합니다. 거치지 않는 경로가 있다면 그 앞은 엣지 방화벽의 관할이 아닙니다.
3. 우회 경로가 남아 있는지 확인합니다. 원본 서버의 주소가 외부에 그대로 열려 있으면, 앞단을 아무리 잘 구성해도 그 주소로 오는 요청은 검사를 받지 않습니다.
4. 규칙을 관리할 자리를 한 곳으로 정합니다. 두 곳을 다 쓰는 경우에도 이 단계는 필요합니다.
5. 기록만 남기는 모드로 먼저 돌립니다. 어떤 정상 요청이 걸리는지 확인한 뒤 차단으로 올립니다.

3번이 이 판단에서 가장 자주 빠집니다. AWS 앞에 엣지를 두는 구성에서 경로와 클라이언트 주소가 어떻게 어긋나는지는 AWS와 Cloudflare를 함께 쓸 때 깨지는 자리에서 구체적으로 짚었습니다.

빌드업웍스의 운영 경험에서는, 어느 제품을 골랐는지보다 앞단을 우회하는 경로가 닫혀 있는지와 관리형 규칙을 켠 뒤 정상 요청이 걸리는지 확인했는지가 결과를 더 많이 가릅니다. 켜 두었다는 사실이 곧 막고 있다는 뜻이 되지는 않습니다.

둘 중 무엇을 골라도 남는 것

두 제품 모두 요청의 모양으로 판정하는 장치라, 형식상 완전히 정상인 요청으로 이뤄지는 공격은 어느 쪽도 판단할 근거가 없습니다. 권한이 있는 계정이 정상 절차로 남의 데이터를 조회하거나, 각 요청은 유효한데 순서와 조합이 의도를 벗어나는 경우가 여기에 해당합니다. 이 영역은 애플리케이션이 스스로 다뤄야 하며 OWASP Top 10이 상위 위험으로 다루는 자리이기도 합니다.

또 하나, 웹 방화벽은 취약점 점검의 대체물이 아닙니다. 방화벽은 알려진 공격 형태를 막아 시간을 벌어 주지만 코드에 남아 있는 결함을 없애지는 못합니다. 참고로 빌드업웍스는 모의해킹과 웹 취약점 점검을 직접 수행하지 않습니다.

다음 단계

지금 구성에서 어느 경로가 방화벽을 지나고 어느 경로가 지나지 않는지부터 확인하시는 것이 순서상 먼저입니다. 보안 진단에는 네트워크 보안 항목이 있어, 이 글에서 나눈 기준을 자신의 환경에 대입해 무엇이 비어 있는지 짚어 보실 수 있습니다. 연락처 없이 결과를 바로 보실 수 있습니다.

밖에서 보이는 설정부터 빠르게 확인하고 싶으시면 웹사이트 기술 · 보안 상태 확인에서 도메인만 입력해 점검해 보실 수 있습니다. 방어 계층을 어떻게 나눌지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Cloudflare Docs — WAF 개요
• Cloudflare Docs — Managed rules
• AWS WAF 개발자 안내서
• AWS WAF — 관리형 규칙 그룹
• OWASP Top 10