Azure WAF는 Application Gateway와 Front Door에 정책으로 붙어 SQL 인젝션, XSS 같은 웹 공격을 막습니다. 요청이 들어오면 사용자 지정 규칙을 먼저 평가하고, 다음으로 관리 규칙(DRS 2.2)이 이상 점수를 매겨 5점 이상이면 차단합니다. 처음에는 감지 모드로 로그를 보며 오탐을 제외한 뒤 방지 모드로 바꾸는 순서가 가장 안전합니다.
1. Azure WAF가 붙는 곳
Azure Firewall, NSG, WAF 역할 정리에서 WAF가 L7에서 요청 내용을 검사한다는 큰 그림을 봤습니다. 이번 글은 그 WAF를 실제로 어떻게 설정하고 운영하는지에 집중합니다. Azure WAF는 독립 리소스가 아니라 WAF 정책으로 만들어 Application Gateway나 Front Door에 연결합니다.
| 비교 항목 | Application Gateway WAF | Front Door WAF |
| 검사 위치 | 리전, VNet 입구 | 전 세계 엣지 |
| 필요한 SKU | WAF_v2 | 관리 규칙은 Premium Standard는 사용자 지정 규칙만 |
| 정책 적용 범위 | 게이트웨이 전체, 리스너(사이트)별, 경로(URI)별 | 도메인별(보안 정책) |
| 관리 규칙 | DRS 2.2 기본 권장 | DRS 2.2 |
| 봇 보호 | Bot Manager 1.0, 1.1 | Bot Manager 1.0, 1.1(Premium) |
2. 규칙 평가 순서

사용자 지정 규칙을 먼저 평가하고, 관리 규칙의 이상 점수가 5점 이상이면 방지 모드에서 차단하는 흐름
사용자 지정 규칙은 우선순위 숫자가 작은 것부터 평가하고, Allow나 Block에 걸리면 그 자리에서 판단이 끝나 관리 규칙까지 가지 않습니다. 사용자 지정 규칙을 통과한 요청은 관리 규칙에서 검사하는데, DRS 2.x는 규칙 하나에 걸렸다고 바로 막지 않고 심각도별 점수를 더해 합계로 판단합니다.
| 규칙 심각도 | 이상 점수 |
| Critical | 5 |
| Error | 4 |
| Warning | 3 |
| Notice | 2 |
합계가 5점 이상이면 방지 모드에서 차단합니다. Critical 규칙 하나면 바로 5점이라 차단되고, Warning 하나(3점)는 통과하지만 Warning 두 개가 겹치면 6점이 되어 차단됩니다. 감지 모드에서는 같은 판단을 하되 로그만 남기고 요청은 통과시킵니다.
3. 관리 규칙 집합
| 규칙 집합 | 기반 | 비고 |
| DRS 2.2 | OWASP CRS 3.3.4 | 새 정책 기본 권장. Java 인젝션, RCE 탐지 강화 |
| DRS 2.1 | OWASP CRS 3.3.2 | 기존 정책은 2.2로 올리는 것을 권장 |
| CRS 3.2 이하 | OWASP CRS | 레거시. 새로 쓰지 않음 |
| Bot Manager 1.0, 1.1 | Microsoft 위협 인텔리전스 | 나쁜 봇, 좋은 봇, 알 수 없는 봇 분류 |
DRS는 Paranoia Level 1(PL1)이 기본이라 오탐이 적은 규칙만 켜져 있습니다. 탐지를 더 넓히려고 PL2 규칙을 켜면 오탐도 함께 늘어나므로 충분히 튜닝할 수 있을 때만 켭니다. 포털에서 규칙 집합 버전을 올리면 개별 규칙 재정의가 초기화되므로, 재정의가 많다면 CLI나 API로 올리는 편이 안전합니다.
4. 사용자 지정 규칙
사용자 지정 규칙은 정책당 최대 100개, 우선순위 1~100으로 만듭니다. 한 규칙 안의 조건은 AND, 서로 다른 규칙은 OR로 동작합니다. 출발지 IP, 국가(GeoMatch), 요청 메서드, URI, 헤더, 쿠키, 쿼리 문자열, 본문을 조건으로 쓸 수 있고, 동작은 Allow, Block, Log 중 하나입니다.
| 예시 | 조건 | 동작 |
| 관리자 페이지 보호 | RequestUri가 /admin으로 시작 AND 출발지 IP가 사내 대역이 아님 |
Block |
| 국가 제한 | GeoMatch가 KR이 아님 | Block |
| 모니터링 도구 허용 | 출발지 IP가 모니터링 서버 | Allow |
| 의심 요청 관찰 | User-Agent에 특정 문자열 포함 | Log |
Allow는 관리 규칙까지 건너뛰므로 범위를 최대한 좁게 잡아야 합니다. Front Door WAF는 여기에 속도 제한(Rate limit) 규칙과 리디렉션 동작을 추가로 지원해, 특정 경로에 분당 요청 수를 넘는 IP를 막는 데 씁니다.
5. 어디에 둘까

Front Door WAF는 엣지에서, Application Gateway WAF는 VNet 입구에서 요청을 검사하는 위치 차이
인터넷에 공개하는 서비스라면 Front Door WAF가 기본입니다. 공격 트래픽을 사용자와 가까운 엣지에서 걸러 원본까지 오지 않게 하고, 속도 제한과 봇 보호도 엣지에서 처리합니다. 사내 전용 서비스나 한 리전에만 있는 서비스, 또는 사이트나 경로별로 서로 다른 정책을 세밀하게 걸어야 할 때는 Application Gateway WAF가 맞습니다.
둘 다 쓰는 구성이라면 공통 규칙은 Front Door에 두고, Application Gateway에는 리전 안에서만 필요한 규칙만 둡니다. 같은 규칙을 양쪽에 모두 켜면 오탐을 두 번 튜닝해야 하고, 로그도 두 곳으로 나뉩니다.
6. 감지 모드에서 방지 모드로
WAF를 처음 붙일 때는 감지 모드로 1~2주 정도 운영하면서 정상 요청이 어떤 규칙에 걸리는지 봅니다. 게시판 본문의 HTML, 검색어의 따옴표, JSON 본문의 특수 문자가 대표적인 오탐 원인입니다. 오탐이 확인되면 규칙 전체를 끄기보다 해당 규칙에서 특정 파라미터만 빼는 규칙별 제외(per-rule exclusion)를 우선 씁니다.
// Application Gateway WAF 로그: 가장 많이 걸린 규칙
AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where action_s in ("Matched", "Detected", "Blocked")
| summarize count() by ruleId_s, Message
| order by count_ desc
위 쿼리로 많이 걸린 규칙부터 요청 URI와 파라미터를 확인하고, 정상 요청이라면 제외를 추가합니다. 오탐이 거의 사라지면 방지 모드로 바꾸고, 바꾼 뒤에도 차단 로그를 한동안 매일 확인합니다.
7. Azure CLI로 만들어 보기
7.1 WAF 정책 만들기와 연결
RG=rg-web
# DRS 2.2 관리 규칙을 쓰는 정책
az network application-gateway waf-policy create --resource-group $RG \
--name wafpol-web --type Microsoft_DefaultRuleSet --version 2.2
# 처음에는 감지 모드
az network application-gateway waf-policy policy-setting update \
--resource-group $RG --policy-name wafpol-web \
--state Enabled --mode Detection --request-body-check true
# Application Gateway(WAF_v2)에 연결
POLICY_ID=$(az network application-gateway waf-policy show \
--resource-group $RG --name wafpol-web --query id -o tsv)
az network application-gateway update --resource-group $RG --name agw-web \
--set firewallPolicy.id=$POLICY_ID
7.2 사용자 지정 규칙: 국가 제한
WP="--resource-group $RG --policy-name wafpol-web"
az network application-gateway waf-policy custom-rule create $WP \
--name BlockNonKR --priority 10 --rule-type MatchRule --action Block
# 출발지 국가가 KR이 아니면(negate) 차단
az network application-gateway waf-policy custom-rule match-condition add $WP \
--name BlockNonKR --match-variables RemoteAddr --operator GeoMatch \
--values KR --negate true
# 튜닝이 끝나면 방지 모드로
az network application-gateway waf-policy policy-setting update $WP \
--state Enabled --mode Prevention
방지 모드로 바꾼 뒤 해외 IP나 테스트용 공격 문자열(예: ?id=1' OR '1'='1)로 요청해 403이 돌아오는지, 로그에 Blocked로 남는지 확인합니다.
8. 운영 시 주의점
| 항목 | 확인할 것 |
| 처음부터 방지 모드 | 정상 요청이 막혀 장애처럼 보일 수 있습니다. 감지 모드로 시작합니다. |
| 규칙 전체 끄기 | 오탐은 규칙별 제외로 해결하고, 규칙이나 그룹 전체를 끄는 것은 마지막 수단으로 둡니다. |
| Allow 규칙 범위 | Allow는 관리 규칙을 건너뛰므로 IP나 경로를 최대한 좁게 지정합니다. |
| 요청 본문 크기 | 대용량 업로드가 있으면 최대 요청 본문 크기와 파일 업로드 한도를 서비스에 맞게 조정합니다. |
| 리디렉션 규칙 | Application Gateway의 리디렉션 규칙으로 처리되는 요청에는 사용자 지정 규칙이 적용되지 않습니다. |
| 중복 WAF | Front Door와 Application Gateway에 같은 규칙을 모두 켜면 튜닝과 로그가 두 배가 됩니다. |
9. 정리
- Azure WAF는 정책으로 만들어 Application Gateway(WAF_v2)나 Front Door에 연결하고, 관리 규칙은 DRS 2.2를 기본으로 씁니다.
- 사용자 지정 규칙을 먼저 평가하고, 관리 규칙은 심각도 점수 합계가 5점 이상이면 차단합니다.
- 감지 모드로 시작해 규칙별 제외로 오탐을 정리한 뒤 방지 모드로 바꾸고, 공개 서비스는 Front Door WAF를 기본으로 둡니다.
참고
'Cloud > Azure' 카테고리의 다른 글
| [Azure] Azure 부하 분산 서비스 비교 (0) | 2026.09.25 |
|---|---|
| [Azure] Front Door와 Application Gateway 연동 정리 (0) | 2026.09.25 |
| [Azure] Traffic Manager 정리 (0) | 2026.09.25 |
| [Azure] Azure Front Door 정리 (0) | 2026.09.25 |
| [Azure] Application Gateway 정리 (0) | 2026.09.25 |