웹방화벽(WAF) 선택 체크리스트
🛡️ 웹방화벽(WAF) SaaS 선택 체크리스트
웹방화벽은 더 이상 단순한 HTTP 요청 차단 장비가 아닙니다.
현대 공격은
- 크리덴셜 스터핑
- JWT/세션 기반 인증 우회
- 웹쉘 업로드
- API 오용
- 데이터 유출
처럼 애플리케이션 + 계정 + 서버 내부 행위까지 확장됩니다.
따라서 WAF 선택의 기준은
단순 차단율이 아니라,
탐지 + 분석 + 대응 가능성이어야 합니다.
특히 SaaS 기반 WAF는
단순한 경계 장비가 아니라,
전수 로그 수집과 실시간 분석의 출발점이 되어야 합니다.
이 체크리스트는 특정 제품이 아니라
어떤 WAF를 선택하든 적용 가능한 일반 기준을 기준으로 작성했습니다.
✅ 필수 체크리스트 (핵심 10)
1️⃣ 공격 “차단”이 아니라 “탐지·분석·대응” 중심인가
단순히 룰에 맞는 요청을 차단하는 장비인지,
아니면 공격 행위 전체를 분석하고 대응까지 연결할 수 있는 구조인지 확인해야 합니다.
왜 중요한가
- 오늘날 공격은 단일 요청 한 번으로 끝나지 않습니다.
- 로그인 시도 → 세션 탈취 → 내부 API 호출 → 데이터 반출처럼 이어지는 경우가 많습니다.
어떻게 확인할까
- 벤더에게 “차단된 공격 사례”가 아니라
탐지 → 분석 → 대응 흐름을 보여 달라고 요청합니다. - 단일 이벤트 경고만 있는지, 사건 단위 스토리라인이 있는지 봅니다.
좋은 신호
- 공격 흐름 타임라인 제공
- 차단 후 근거 로그와 후속 대응 연결 가능
위험 신호
- 룰 카운트와 차단율만 강조
- “막았습니다”는 있는데 “왜 막았는지” 설명이 약함
2️⃣ 요청 본문(Post-body)까지 수집·분석 가능한가
Access Log 수준이 아니라
HTTP Request Body를 포함한 전체 로그 분석이 가능한지 봐야 합니다.
왜 중요한가
- SQL Injection
- 웹쉘 업로드
- API abuse
- JSON/XML 파라미터 기반 공격
은 대부분 본문을 봐야 판단할 수 있습니다.
어떻게 확인할까
- POST JSON 요청, multipart 업로드, XML 본문을 실제로 수집·조회할 수 있는지 시연 요청
- 샘플링인지 전수 수집인지 확인
예시
/login요청에서 패스워드 대입 패턴/upload요청에서 악성 스크립트 삽입/api/orderJSON 본문에서 비정상 필드 조작
핵심: 보이지 않으면 탐지도 없습니다.
3️⃣ 크리덴셜 스터핑 탐지가 가능한가
로그인 시도 패턴을
IP, 계정, 실패율, 속도, 분산 정도 기준으로 분석할 수 있어야 합니다.
왜 중요한가
- 크리덴셜 스터핑은 더 이상 단일 IP 무차별 대입이 아닙니다.
- 다수 IP, 정상 User-Agent, 저속 분산 시도 형태로 나타납니다.
어떻게 확인할까
- 동일 계정 대상 다수 IP 실패 시나리오 탐지 여부 확인
- 정상 사용자와 공격자 구분 로직이 있는지 확인
- CAPTCHA, 세션 보호, 계정 보호와 연계 가능한지 확인
좋은 신호
- 로그인 흐름 전용 탐지 시나리오
- 계정 보호 액션 연계 가능
위험 신호
- 단순 실패 횟수 초과 알림만 있음
- 정상 사용자와 공격자 구분 기준이 없음
4️⃣ JWT/세션 기반 인증 우회 공격을 탐지할 수 있는가
JWT는 단순 토큰 문자열이 아니라
인증 구조 전체의 신뢰 문제입니다.
왜 중요한가
- 서명 키 유출
- 비정상 claim 사용
- 만료/재사용 문제
- 토큰 위변조 같은 공격은 일반적인 URL 차단만으로는 보이지 않습니다.
어떻게 확인할까
- 비정상 JWT 패턴 시나리오를 어떻게 다루는지 질문
- 토큰 재사용, 해외 IP, 대량 API 호출과 결합 분석 가능한지 확인
예시
- 정상 로그인 없이 토큰만으로 대량 조회
- 동일 토큰으로 여러 지역에서 반복 호출
- 비정상 claim 조합 사용
5️⃣ 제로데이 대응 구조가 있는가
제로데이는 “룰이 없으니 못 막는다”로 끝나면 안 됩니다.
행위 기반 탐지와 사후 재분석 가능성이 있어야 합니다.
왜 중요한가
- 알려진 패턴 없는 공격은 언제나 나옵니다.
- 결국 남는 것은 행위와 기록입니다.
어떻게 확인할까
- 시그니처 없는 공격을 어떻게 탐지하는지 질문
- 나중에라도 재분석할 수 있도록 로그가 남는지 확인
- 비정상 흐름 기반 시나리오가 있는지 확인
좋은 신호
- 행위 기반 분석
- 사후 재탐지 가능한 전체 로그 저장
위험 신호
- “제로데이도 막습니다”라고 하지만 근거가 룰 업데이트뿐임
6️⃣ 데이터 유출(Exfiltration) 탐지가 가능한가
WAF는 들어오는 공격만이 아니라
나가는 데이터의 이상성도 봐야 합니다.
왜 중요한가
- 정상 200 OK 응답처럼 보이는 유출이 많습니다.
- 내부 API 오용, 대량 응답, 개인정보 패턴 유출은 응답까지 봐야 드러납니다.
어떻게 확인할까
- 응답 크기, 민감정보 패턴, 반복 호출 조합 탐지 가능한지 확인
- 특정 API의 대량 응답 이상징후 탐지 여부 확인
예시
- 동일 API에서 장시간 반복되는 개인정보 조회
- 해외 IP + 대량 응답 + 정상 상태코드 조합
- 평소보다 큰 응답 본문이 지속되는 경우
7️⃣ 웹쉘 탐지 및 서버 내부 연계 대응이 가능한가
단순 웹 요청만 보고 끝나면
침해 이후 단계는 놓치게 됩니다.
왜 중요한가
- 웹쉘은 보통 침입 후 설치됩니다.
- 이후에는 파일 생성, 프로세스 실행, 외부 연결이 뒤따릅니다.
확인할 항목
- 파일 생성/변경 감시
- 웹 프로세스의 자식 프로세스 실행 추적
- 웹루트 변경 알림
- 서버 측 보안 도구(EDR/XDR)와 연계 가능 여부
예시
w3wp→cmd.exephp-fpm→sh- 웹루트 내 신규
.php/.jsp파일 생성
핵심: WAF 단독보다, 서버 행위와 연결된 탐지가 훨씬 강합니다.
8️⃣ 전수 로그 분석(Full Logging)이 가능한가
샘플링 로그가 아니라
100% 전체 로그 수집과 재분석이 가능해야 합니다.
왜 중요한가
- 지금 못 잡은 공격도 나중에 다시 찾아야 할 수 있습니다.
- 제로데이는 “지금 탐지”보다 “반드시 다시 탐지 가능”이 더 중요할 때가 많습니다.
어떻게 확인할까
- 샘플링 비율이 있는지 확인
- 저장 기간, 압축, 검색, 재분석 기능 확인
- 원문 로그 조회 가능 여부 확인
핵심 논리:
제로데이는 “지금 탐지”가 아니라
“나중에라도 반드시 탐지”할 수 있어야 합니다.
9️⃣ 실시간 탐지 및 대응 자동화가 가능한가
탐지는 늦으면 의미가 줄어듭니다.
실시간 경보와 자동 대응 연결이 중요합니다.
확인할 항목
- 자동 차단
- 세션 종료
- 계정 보호
- 관리자 알림
- 티켓 발행
- SOAR/IR 절차 연계
좋은 신호
- 탐지 후 대응 액션 선택 가능
- 자동/수동 대응 기준이 분명함
위험 신호
- 경보만 발생하고 후속 조치가 전부 수동
🔟 통합 분석 플랫폼(XDR/EDR/SIEM) 및 Forensic과 연계 가능한가
WAF 단독만으로는
전체 공격 흐름을 보기 어렵습니다.
현대 공격은
- 웹 요청
- 계정 행위
- 서버 내부 프로세스
- 파일 변경
- 네트워크 연결
- 그리고 사후 포렌식 분석
까지 함께 연결되어야
비로소 실제 침해가 보입니다.
왜 중요한가
웹방화벽이 공격의 “입구”를 보더라도,
실제 침해 여부는 그 이후의 행위와 증거를 함께 봐야 판단할 수 있습니다.
즉,
- WAF가 수상한 요청을 봤고
- 서버에서 비정상 파일 생성이 있었으며
- 프로세스 실행과 외부 연결이 이어졌고
- 이후 어떤 데이터가 반출되었는지
를 하나의 사건으로 묶어야 합니다.
여기서 끝이 아닙니다.
실제 사고 대응에서는 반드시 Forensic 연계가 가능해야 합니다.
예를 들어:
- 해당 시점의 원본 요청/응답 로그 확보
- 관련 파일 해시, 생성/수정 시간 확인
- 웹루트 변경 이력 추적
- 관련 프로세스 트리와 명령행 복원
- 계정 사용 이력과 세션 흐름 확인
- 추가 침해 흔적(웹쉘, 백도어, 권한 상승) 조사
- 사고 타임라인 재구성
- 재발 방지용 증적 보존
이런 과정이 가능해야
WAF 경보가 단순한 “알림”이 아니라
조사 가능한 사건이 됩니다.
어떻게 확인할까
- 서버, 계정, 네트워크 로그와 상관 분석 가능한지 확인
- API, Webhook, Syslog, 데이터 내보내기 기능 확인
- 포렌식 조사에 필요한 원본 로그와 증적을 보존할 수 있는지 확인
- 사고 발생 후 타임라인 재구성이 가능한지 확인
- WAF 탐지 이벤트를 EDR/XDR/SIEM/Forensic 분석 흐름으로 넘길 수 있는지 확인
좋은 신호
- 웹 ↔ 서버 ↔ 계정 ↔ 네트워크 흐름 연계 가능
- WAF 이벤트를 기준으로 관련 증적 자동 수집 가능
- 사고 타임라인과 원인 분석 리포트 생성 가능
- Forensic 조사에 필요한 원본 데이터 보존 가능
위험 신호
- WAF 안에서만 보이고, 그 밖과는 단절됨
- 경보는 울리지만 실제 조사에 필요한 데이터가 없음
- 원본 요청/응답, 파일 변경, 프로세스 흔적을 연결할 수 없음
- 사고 후 “의심은 되지만 증명은 못 하는” 구조
⚠️ SaaS WAF에서 반드시 걸러야 할 제품
❌ 1. 룰 기반 차단만 강조하는 제품
- OWASP Top 10 대응만 전면에 내세움
- 알려진 공격 차단만 강조
문제점
- 우회와 변형 공격에 약함
- 운영자가 “막았다”고 착각하기 쉬움
❌ 2. Access Log 수준만 보는 제품
- 요청 본문 미수집
- 응답 본문 미분석
- payload 자체 확인 불가
문제점
- 공격의 실체를 설명하지 못함
- API abuse, 웹쉘 업로드, 데이터 유출 탐지가 제한됨
❌ 3. 샘플링 로그 중심 제품
- 일부 로그만 저장
- 저장량 제한이 심함
- 전체 재분석이 어려움
문제점
- 사후 포렌식과 제로데이 재탐지에 매우 취약함
❌ 4. 서버 내부 행위를 전혀 못 보는 제품
- 웹쉘 탐지 불가
- 파일/프로세스 추적 불가
- 웹루트 변경 감시 불가
문제점
- 침해 이후 단계에서 사실상 무방비
❌ 5. 단일 기능만 있는 제품
- WAF만 존재
- EDR/XDR/SIEM/IR과 단절
- 전체 공격 흐름 설명 불가
문제점
- 차단은 했어도, 실제 사건은 이해하지 못함
📊 핵심 평가 기준 요약표
| No | 항목 | 필수 여부 | 확인 방법 | 핵심 포인트 |
|---|---|---|---|---|
| 1 | 요청 본문 분석 | 필수 | POST/JSON/XML 시연 | 공격 payload 가시성 |
| 2 | 크리덴셜 스터핑 탐지 | 필수 | 로그인 분산 공격 시나리오 질문 | 계정 탈취 대응 |
| 3 | JWT/세션 공격 탐지 | 필수 | 토큰 재사용/우회 시나리오 확인 | 인증 우회 방지 |
| 4 | 제로데이 대응 | 필수 | 시그니처 없는 공격 대응 질문 | 행위 기반 분석 |
| 5 | 데이터 유출 탐지 | 필수 | 응답 본문·대량 조회 탐지 여부 | 내부 정보 보호 |
| 6 | 웹쉘/서버 연계 | 필수 | 웹루트 변경·자식 프로세스 감시 확인 | 침해 이후 대응 |
| 7 | 전수 로그 저장 | 필수 | 샘플링 여부·보관 기간 확인 | 사후 재분석 |
| 8 | 실시간 대응 | 필수 | 자동 차단/세션 종료 가능 여부 | 공격 차단 |
| 9 | 통합 분석 연계 | 필수 | API/Webhook/SIEM/EDR/XDR 연동 확인 | 전체 공격 흐름 분석 |
| 10 | 포렌식(Forensic) 연계 | 필수 | 원본 로그·파일 해시·프로세스 트리·타임라인 재구성 가능 여부 확인 | 사고 조사 및 증적 확보 |
📌 결론
웹방화벽 선택의 기준은 이제 분명합니다.
“얼마나 잘 막느냐”만이 아니라,
얼마나 잘 기록하고, 얼마나 잘 분석하고, 얼마나 빨리 대응할 수 있느냐”
이 질문에 답하지 못하면
그 제품은 강한 보안 플랫폼이라기보다
좋은 필터에 머물 가능성이 큽니다.
최종 메시지
보안은 차단이 아니라
기록 → 분석 → 대응의 문제입니다.
그리고 그 출발점은 늘 같습니다.
“전수 로그 수집과 실제 공격 가시성”