WAF(Azure Web Application Firewall)는 SQL 삽입, XSS(교차 사이트 스크립팅) 및 경로 통과와 같은 일반적인 HTTP 계층 공격으로부터 웹 애플리케이션을 보호합니다. 네트워크 수준 위협에 대해 계층 3에서 7까지의 트래픽을 검사하는 Azure Firewall 달리 WAF는 계층 7에서만 작동하며 요청 헤더, 쿼리 문자열, 요청 본문 및 쿠키를 포함한 HTTP 의미 체계를 이해합니다. WAF를 Azure Application Gateway(지역) 또는 Azure Front Door(전역 에지)에 연결된 정책으로 배포하여 보호 범위를 애플리케이션 아키텍처와 일치합니다. Web Application Firewall은 Azure Firewall 및 Azure DDoS Protection과 함께 세 가지 핵심 Azure 네트워크 보안 서비스 중 하나입니다.
이 문서에서 다루는 내용
이 문서에서는 Azure Web Application Firewall 사용하여 HTTP 계층 보호에 대해 설명합니다. 다음 항목에 대해 알아봅니다.
- Application Gateway v2의 WAF와 Azure Front Door WAF 간의 플랫폼 비교
- DRS(기본 규칙 집합) 및 CRS(핵심 규칙 집합)를 포함한 OWASP 기반 규칙 집합입니다.
- 탐지 모드와 방지 모드 및 각각을 언제 사용해야 하는지
- WAF 정책 범위 옵션: 전역, 사이트별, 수신기별 연결.
- 속도 제한, 지역 필터링 및 애플리케이션별 논리에 대한 사용자 지정 규칙입니다.
- WAF(계층 7 HTTP)와 Azure Firewall(계층 3-7 네트워크) 간의 차이점입니다.
이 문서가 필요한 사람
워크로드가 다음 조건 중 하나 이상을 충족하는 경우 WAF를 배포합니다.
- 공용 웹 애플리케이션: 애플리케이션은 인터넷에서 인바운드 HTTP/HTTPS 트래픽을 허용하여 삽입 공격, 깨진 인증 남용 및 중요한 데이터 노출 시도를 포함하여 OWASP 상위 10개 취약성에 노출합니다.
- 규정 준수 요구 사항: PCI DSS(Payment Card Industry Data Security Standard)와 같은 규제 프레임워크는 결제 카드 데이터를 처리하는 애플리케이션 앞에 웹 애플리케이션 방화벽을 요구합니다.
- API 보호: API는 공개적으로 액세스할 수 있으며 네트워크 방화벽에서 검사하지 않는 요청 밀수, 대형 페이로드 및 프로토콜 수준 공격 방지가 필요합니다.
- 봇 완화: 합법적인 크롤러 및 모니터링 서비스를 허용하면서 악성 봇을 차단하면서 자동화된 트래픽을 분류하고 제어해야 합니다.
HTTP 요청 검사 없이 네트워크 수준 트래픽 필터링(IP, 포트 및 프로토콜)만 필요한 조직은 대신 Azure Firewall 또는 NSG를 사용해야 합니다.
리프트 앤 시프트 포커스: 다시 호스팅된 많은 내부 앱에는 인터넷 수신이 없으며 WAF가 필요하지 않습니다. 마이그레이션 중 또는 마이그레이션 후에 웹앱을 인터넷에 노출하는 경우에만 WAF를 추가합니다.
현대화 초점: 글로벌 앱의 경우 Azure Front Door의 WAF를, 단일 지역 앱의 경우 Application Gateway를 고객 대면 웹앱의 프런트 엔드로 사용하고, Front Door와 Traffic Manager 중 선택한 전달 방식에 맞춰 정렬합니다.
클라우드 간 포커스: 마이그레이션된 퍼블릭 웹앱에 대한 스포크에서 Application Gateway에 계층 7 WAF를 배치하고 다른 클라우드의 웹 보호(예: Google Cloud Armor)를 Azure WAF에 매핑합니다.
Azure WAF 플랫폼 비교
Azure WAF는 두 플랫폼에서 사용할 수 있습니다. 각 플랫폼은 WAF 검사를 트래픽 흐름의 다른 지점에 통합합니다.
| Capability | Application Gateway v2의 WAF | Azure Front Door에 설치된 WAF |
|---|---|---|
| 배포 범위 | 지역(단일 Azure 지역) | 글로벌(전 세계에 192개 이상의 에지 PoP 보유) |
| 검사 지점 | 트래픽이 귀하의 리전에 도달한 후 | 에지 PoP에서 트래픽이 원본에 도달하기 전 |
| 지원되는 규칙 집합 | DRS 2.2, DRS 2.1, CRS 3.2 | DRS 2.2, DRS 2.1, DRS 2.0 |
| 사용자 지정 규칙 | ✔ | ✔ |
| 봇 보호 | ✔ | ✔ (프리미엄 계층에만 해당) |
| 속도 제한 | ✔ | ✔ |
| Geo-filtering | ✔ | ✔ |
| 사이트별 정책 | ✔(수신기당, 경로별) | ✔ (엔드포인트당) |
| 관리되는 규칙 집합 | ✔ | ✔ (프리미엄 계층만 해당; 표준은 사용자 지정 규칙만 지원합니다.) |
| 요청 본문 검사 | 최대 128KB(구성 가능) | 최대 128KB(구성 가능) |
| Private Link 원본 지원 | N/A (App Gateway와 함께 인라인으로) | ✔ (프라이빗 원본 연결) |
| 적합한 대상 | 단일 지역 앱, L7 부하 분산 + WAF | Multiregion 앱, 글로벌 가속 + WAF |
메모
Azure Front Door 표준 및 프리미엄의 두 계층이 있습니다. 관리되는 규칙 집합(DRS 및 봇 보호 포함)은 Front Door Premium에서만 사용할 수 있습니다. Front Door 표준은 사용자 지정 규칙만 지원합니다. Front Door(클래식)는 DRS 1.1 이하만 지원합니다.
WAF 플랫폼을 선택하는 방법
다음 의사 결정 조건을 사용합니다.
- 애플리케이션이 단일 지역에 배포되고 이미 계층 7 부하 분산, TLS 종료 또는 경로 기반 라우팅에 Application Gateway를 사용하는 경우 Application Gateway에서 WAF를 선택합니다. WAF는 추가 서비스 홉을 도입하지 않고 인라인으로 HTTP 검사를 추가합니다.
- 애플리케이션이 여러 지역에 걸쳐 있거나, 전역 부하 분산이 필요하거나, CDN(콘텐츠 배달 네트워크) 가속의 이점이 있는 경우 Azure Front Door WAF를 선택합니다. Front Door WAF는 가장 가까운 에지 접속 지점(PoP)에서 트래픽을 검사합니다. 이 서비스는 악의적인 요청이 Azure 백본을 거쳐 원본에 도달하기 전에 차단합니다. 이 접근 방식은 공격 표면의 노출을 줄이고 엣지에서 대용량 레이어 7 공격을 흡수합니다.
- Front Door에서 제공하는 다중 리전 애플리케이션에 각 백 엔드마다 다른 지역 WAF 정책이 필요한 경우 둘 다(계층화)를 선택합니다. Front Door는 일선 전역 보호를 제공하는 반면 Application Gateway WAF는 워크로드에 가까운 지역별 사용자 지정 규칙을 적용합니다.
디자인 고려 사항
리프트 앤 시프트 WAF 디자인 포커스
- 인바운드 인터넷 경로가 없는 내부 전용 재호스팅 워크로드의 경우 WAF를 적용하지 마세요. 앱을 인터넷에 게시할 때 다시 검토하세요.
- 웹 앱을 외부에 공개해야 한다면 먼저 WAF를 탐지 모드로 운영해 트래픽 기준선을 파악한 다음, 오탐을 줄이도록 튜닝한 후 차단 모드로 전환하세요.
- 계층 7 라우팅을 위해 이미 Application Gateway를 프런트엔드로 사용하고 있는 단일 지역 리호스팅 웹앱에는 Application Gateway WAF를 사용하세요.
- 온-프레미스 웹 보호 규칙(예: OWASP 검사)의 의도를 시작 정책으로 다시 사용합니다.
WAF 디자인 포커스 현대화
- 고객 관련 앱에 대한 처음부터 방지 모드에서 WAF를 실행하고, 검사에서 새 OWASP 위협을 자동으로 추적하도록 최신 관리형 규칙 집합을 채택합니다.
- 봇 관리를 활성화하여 공개 앱을 대상으로 하는 합법적인 크롤러와 악의적인 자동화를 구분하세요.
- 배포 파이프라인을 통해 활성-활성 지역 백 엔드가 동기화되도록 WAF 정책을 코드로 관리합니다.
- 심층 방어를 위해 허브 방화벽과 에지 WAF를 페어링하고 VNet에서 DDoS 네트워크 보호를 켜서 Application Gateway WAF 청구 할인을 사용하도록 설정합니다.
클라우드 간 WAF 설계 중점 사항
- 공용 IP를 가상 머신에 직접 연결하지 않고 공용 웹 트래픽을 검사하도록 스포크 VNet에서 Application Gateway에서 계층 7 WAF를 호스트합니다.
- 다른 클라우드(예: AWS WAF 또는 Google Cloud Armor)의 기존 웹 보호를 Azure WAF 관리형 규칙 집합에 매핑하여 보호 범위가 그대로 유지되도록 합니다.
- WAF를 통해 공용 통신을 검사하고 Virtual WAN 허브 방화벽에서 동서 및 클라우드 간 전송 검사를 유지합니다.
- 컷오버 중에는 먼저 WAF를 탐지(학습) 모드로 실행한 다음, 정상적인 트래픽 패턴이 확인되면 차단 모드로 전환합니다.
사전 요구 사항
Azure Web Application Firewall 배포하기 전에 다음이 있는지 확인합니다.
- Application Gateway v2 또는 Azure Front Door 리소스: WAF는 이러한 플랫폼 중 하나에 연결된 정책으로 배포합니다. WAF 정책을 만들고 연결하기 전에 기존 Application Gateway v2 인스턴스 또는 Azure Front Door 프로필이 프로비전되어 있어야 합니다.
- 공용 HTTP/HTTPS 워크로드: 애플리케이션은 인바운드 HTTP/HTTPS 트래픽을 수신해야 합니다. WAF는 요청 수준 의미 체계를 검사하고 비 HTTP 워크로드 또는 순수 내부 서비스에 대한 이점을 제공하지 않습니다.
- HTTP 트래픽 패턴 이해: 애플리케이션의 일반적인 요청 패턴(헤더, 쿼리 매개 변수 및 본문 콘텐츠)을 잘 알고 있으면 검색-방지 모드 전환 중에 가양성을 최소화하도록 제외를 구성하고 규칙을 조정할 수 있습니다.
규칙 집합 및 규칙 처리
WAF는 규칙 집합을 사용하여 HTTP 요청에서 악의적인 패턴을 검색합니다. 규칙 계층 구조 및 처리 순서를 이해하면 특정 애플리케이션에 대한 WAF를 튜닝하는 데 도움이 됩니다.
관리되는 규칙 집합
Microsoft OWASP CRS(핵심 규칙 집합) 패턴을 기반으로 관리되는 규칙 집합을 유지 관리합니다. 새 배포에 권장되는 규칙 집합은 DRS 2.2 (기본 규칙 집합)입니다. DRS 2.2는 OWASP CRS 3.3.4를 기반으로 하며 Microsoft 위협 인텔리전스 서명을 추가합니다.
| 규칙 집합 | 기준 | 플랫폼 지원 | 권장 사항 |
|---|---|---|---|
| DRS 2.2 | OWASP CRS 3.3.4 + Microsoft Threat Intel | App Gateway v2, Front Door Premium | 새 배포에 권장 |
| DRS 2.1 | OWASP CRS 3.3 | App Gateway v2, Front Door Premium | 이전 세대; 두 플랫폼에서 모두 지원됨 |
| DRS 2.0 | OWASP CRS 3.2 | Front Door Premium 전용 | 지원됨; Front Door N-2 버전 |
| CRS 3.2 | OWASP CRS 3.2 | App Gateway v2 전용 | 지원; 새 배포에 DRS 2.2 사용 |
DRS 및 CRS 규칙 집합은 변칙 채점을 사용합니다. 각 일치 규칙은 요청을 즉시 차단하는 대신 점수를 제공합니다. 누적 변칙 점수가 구성 가능한 임계값을 초과하면 WAF는 작업(블록 또는 로그)을 수행합니다. 이 접근 방식은 신뢰도가 낮은 단일 일치만으로는 차단이 시행되지 않으므로, 개별 규칙 차단에 비해 가양성이 줄어듭니다.
사용자 지정 규칙
사용자 지정 규칙은 관리되는 규칙 전에 실행되고 우선 순위 번호를 사용하여 평가 순서를 제어합니다(낮은 숫자 = 더 높은 우선 순위). 사용자 지정 규칙을 사용하여 다음을 수행합니다.
- 속도 제한: 자격 증명 스터핑 및 무차별 암호 대입 공격을 완화하기 위해 시간 범위 내에서 각 클라이언트 IP에 대한 요청을 제한합니다.
- 지역 필터링: 클라이언트의 국가 또는 원본 지역에 따라 트래픽을 허용하거나 거부합니다.
- IP 허용 목록 및 거부 목록: 관리되는 규칙이 평가되기 전에 알려진 파트너 IP를 허용하거나 알려진 잘못된 행위자를 차단합니다.
- 요청 헤더 검사: 필수 API 키 또는 예상 콘텐츠 형식과 같은 애플리케이션별 요구 사항을 적용합니다.
봇 보호 규칙 세트
두 플랫폼 모두 자동화된 트래픽을 좋은 봇(확인된 검색 엔진), 잘못된 봇(알려진 악성 스캐너) 및 알 수 없는 봇으로 분류하는 봇 보호 규칙 집합을 제공합니다. 각 범주에 대한 작업 구성: 좋은 봇을 허용하고, 잘못된 봇을 차단하고, 속도 제한 또는 CAPTCHA를 사용하여 알 수 없는 봇에 도전합니다.
탐지 모드 vs. 예방 모드
WAF 정책은 시스템이 일치하는 요청을 처리하는 방법을 결정하는 두 가지 모드 중 하나로 작동합니다.
| 모드 | 작동 방식 | 사용 사례 |
|---|---|---|
| 감지 | 로그가 일치하는 요청을 기록하지만 차단하지는 않습니다. 요청은 백 엔드로 계속됩니다. | 초기 배포 및 규칙 튜닝. 프로덕션 트래픽에 영향을 주지 않고 트리거되는 규칙을 모니터링합니다. |
| 방지 | 일치하는 요청을 차단하고 403 응답을 반환합니다. 차단된 요청을 기록합니다. | 규칙 튜닝이 완료된 후의 프로덕션 워크로드입니다. 공격에 대한 활성 보호. |
권장되는 튜닝 워크플로
- 검색 모드에서 배포: 검색 모드에서 선택한 규칙 집합으로 WAF를 사용하도록 설정합니다. WAF를 통해 프로덕션 트래픽을 라우팅합니다.
- 로그 분석: WAF 로그를 검토하여 오탐을 식별합니다. 정상적인 애플리케이션 트래픽에 적용되는 규칙을 결정합니다.
- 제외 생성: 오탐을 발생시키는 규칙의 경우 특정 규칙에 대해 건너뛸 요청 필드(헤더, 쿠키, 쿼리 매개변수)를 지정하는 제외를 정의합니다.
- 방지 모드로 전환: 1~2주 동안 탐지 로그가 깨끗하게 유지되고 오탐률도 허용 가능한 수준이면 실제 차단을 위해 방지 모드로 전환합니다.
- 지속적인 모니터링: 방지 모드로 전환한 후 로그 모니터링을 계속합니다. 새 애플리케이션 기능이나 API 변경으로 인해 새로운 오탐 패턴이 발생할 수 있습니다.
Important
항상 방지 모드에서 프로덕션 워크로드를 실행합니다. 검색 모드는 보호를 제공하지 않습니다. 잠재적인 공격만 기록합니다. 감지 모드는 초기 튜닝 단계에서 또는 특정 가양성 문제를 해결할 때만 사용합니다.
WAF 정책 범위 및 연결
WAF 정책은 모드 선택, 규칙 집합 구성, 사용자 지정 규칙 및 제외를 포함하는 독립 실행형 Azure 리소스입니다. 정책을 하나 이상의 대상과 연결하여 보호 범위를 제어합니다.
Application Gateway WAF 정책 범위
Application Gateway에서 세 가지 세분성 수준에서 WAF 정책을 연결합니다.
- 전역(게이트웨이 전체): 이 정책은 Application Gateway의 모든 수신기 및 경로 규칙에 적용됩니다. 게이트웨이 뒤의 모든 애플리케이션이 동일한 보호 요구 사항을 공유하는 경우 전역 범위를 사용합니다.
- 수신기 수준: 다른 WAF 정책은 특정 수신기(호스트 이름 및 포트 조합)에 적용됩니다. 여러 애플리케이션이 게이트웨이를 공유하지만 다른 규칙 튜닝 또는 제외가 필요한 경우 수신기 수준 범위를 사용합니다.
- 경로 규칙 수준: WAF 정책은 수신기 내의 특정 URL 경로 규칙에 적용됩니다. 다양한 백 엔드 민감도의 애플리케이션에 대한 세분화된 제어를 위해 경로 규칙 범위를 사용합니다.
단일 요청에 여러 범위가 적용되는 경우 가장 구체적인 정책이 우선 적용됩니다. 즉, path-rule이 listener-level보다 우선하고, listener-level은 global보다 우선합니다.
Front Door WAF 정책 범위
Front Door에서 WAF 정책은 엔드포인트 또는 경로 수준에서 연결됩니다. 각 Front Door 엔드포인트에는 자체 WAF 정책이 있을 수 있습니다. 이 방법을 사용하면 단일 Front Door 인스턴스 내에서 애플리케이션별 보호 프로필을 사용할 수 있습니다.
리소스 간에 정책 공유
여러 Application Gateway 인스턴스 또는 Front Door 엔드포인트에서 단일 WAF 정책을 공유합니다. Azure Firewall Manager 플랫폼에 관계없이 모든 WAF 정책에서 중앙 집중식 가시성 및 관리를 제공합니다. 관리를 간소화하고 일관된 보안 상태를 유지하기 위해 여러 리소스에 동일한 보호가 필요한 경우 공유 정책을 사용합니다.
Azure Firewall 구별
WAF 및 Azure Firewall 네트워크 스택의 여러 계층을 보호하고 상호 보완적인 역할을 수행합니다. 심층 방어를 위해 둘 다 배포합니다.
| Attribute | 웹 애플리케이션 방화벽 (Web Application Firewall) | Azure Firewall |
|---|---|---|
| OSI 계층 | 계층 7(HTTP/HTTPS만 해당) | 계층 3-7(네트워크 및 애플리케이션) |
| 트래픽 유형 | 웹 애플리케이션에 대한 인바운드 HTTP/HTTPS 요청 | 모든 교통 방향(남북, 동서) |
| 검사 중점 | HTTP 의미 체계: 헤더, 본문, 쿠키, URI | IP 주소, 포트, 프로토콜, FQDN, URL |
| 규칙 엔진 | OWASP 기반 패턴 일치 + 변칙 점수 매기기 | 네트워크 규칙, 애플리케이션 규칙, NAT 규칙 |
| 배포 모델 | App Gateway 또는 Front Door와 통합 | UDR 라우팅을 사용하는 허브 서브넷의 독립 실행형 |
| 차단된 일반적인 공격 | SQL 삽입, XSS, CSRF, 경로 순회 | 포트 스캔, C2 콜백, DNS 정보 유출 |
중앙 집중식 네트워크 트래픽 검사를 위해 HTTP 애플리케이션 보호 및 Azure Firewall WAF를 사용합니다. 허브-스포크 아키텍처에서 인터넷에서 웹 애플리케이션으로의 트래픽은 일반적으로 Azure Firewall(DNAT 및 네트워크 수준 검사용)을 통과한 다음 WAF(HTTP 계층 검사용)를 통해 Application Gateway를 통해 전달됩니다. 네트워크 수준 구성 요소에 대한 Azure Firewall 및 트래픽 검사를 참조하세요.
보안 고려 사항
다음 보안 사례를 통해 WAF로부터 가장 많은 보호를 받을 수 있습니다.
- 프로덕션용 방지 모드: 프로덕션 워크로드를 탐지 모드로 두지 마세요. 검색 모드는 가시성을 제공하지만 적용은 제공하지 않으며 애플리케이션은 공격에 노출됩니다.
- 규칙 튜닝이 진행 중입니다. 애플리케이션이 진화합니다. 새 API 엔드포인트, 매개변수 및 콘텐츠 형식은 기존 규칙 세트에서 오탐을 유발할 수 있습니다. 배포 후 WAF 로그를 정기적으로 검토합니다.
- Log Analytics 통합: WAF 진단 로그를 Log Analytics 작업 영역으로 보냅니다. WAF 통합 문서를 사용하여 차단된 요청, 트리거된 규칙 및 변칙 점수 분포를 시각화합니다.
- DDoS 및 WAF 함께: WAF는 계층 7 애플리케이션 공격으로부터 보호하지만 볼륨이 많은 네트워크 계층 DDoS 공격을 완화하지는 않습니다. 전체 스택 검사를 위해 WAF를 Azure DDoS Protection과 페어링합니다.
- 원본 잠금: Front Door WAF를 사용하는 경우 Front Door 서비스 태그의 트래픽만 허용하도록 원본을 구성합니다. 원본 잠금이 없으면 공격자는 Front Door를 우회하고 요청을 원본 IP 주소로 직접 보낼 수 있습니다.
- 중요한 데이터 보호: WAF 로그에는 요청 데이터가 포함될 수 있습니다. WAF 진단 로그에서 중요한 필드(권한 부여 헤더, 쿠키 또는 본문 콘텐츠)를 마스킹하도록 로그 스크러빙 규칙을 구성합니다.
관련된 문서
다음 문서에서는 관련 네트워킹 보안 항목을 다룹니다.
- 인터넷 수신 및 트래픽 라우팅: 공용 애플리케이션에 대한 수신 패턴입니다.
- 애플리케이션 배달 서비스: Application Gateway 및 Front Door를 배달 플랫폼으로 사용합니다.
- Azure Firewall 및 트래픽 검사: WAF 계층 7 보호를 보완하는 네트워크 수준 검사입니다.
- DDoS 보호: 공용 IP 주소에 대한 볼륨 공격 보호입니다.
- Azure 네트워크 보안이란 무엇인가요?: Azure Firewall, DDoS Protection, Web Application Firewall을 비교하는 개요 허브입니다.
자세히 알아보기
- Azure Web Application Firewall 개요
- Application Gateway의 WAF
- WAF on Azure Front Door
- WAF 정책 개요
- 웹 애플리케이션 방화벽 CRS 규칙 그룹 및 규칙
- Azure Front Door용 웹 애플리케이션 방화벽 조정
다음 단계
팁 (조언)
직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.
리프트 앤 시프트 과정의 다음 단계:
마이그레이션된 네트워크에 대한 모니터링 설정: 웹 애플리케이션 방화벽을 구성한 후 연결 및 성능의 유효성을 검사합니다.
현대화 과정의 다음 단계:
퍼블릭 엔드포인트에 DDoS 보호 사용: 분산 서비스 거부 공격으로부터 공용 IP 리소스를 보호합니다.
멀티클라우드 여정의 다음 단계:
마이그레이션한 애플리케이션 제공: 클라우드 간 워크로드용으로 AWS 및 Google Cloud의 로드 밸런서를 Azure의 해당 서비스에 매핑합니다.