WAF에서 녹화와 차단의 균형

인포매텍 디지털 » Recursos » WAF에서 녹화와 차단의 균형

웹 애플리케이션 방화벽 (WAF)에서 로깅과 차단 사이의 적절한 균형을 찾는 것은 보안 및 운영 팀의 가장 큰 골칫거리 중 하나가 되었습니다. WAF는 매우 심각한 공격을 막을 수 있지만, 지나치게 공격적으로 설정하면 정상적인 구매, 접속 또는 API 호출을 차단할 수 있습니다. 반대로 너무 느슨하게 설정하면 거의 장식적인 역할만 하게 됩니다. 핵심은 로깅 시점, 트래픽 집계 시점, 허용 시점, 차단 시점을 신중하게 조정하는 것입니다.

이 글에서는 AWS WAF, ModSecurity, 클라우드 기반 WAF 및 온프레미스 솔루션의 구체적인 사례를 통해 최신 WAF 기능(허용 목록, 빈도 기반 규칙, 학습 모드, SIEM 통합, 머신 러닝 등)을 활용하여 이러한 균형을 달성하는 방법을 자세히 살펴보겠습니다. 보호 수준을 낮추지 않고 오탐을 줄이는 방법, 애플리케이션별로 정책을 구성하는 방법, 그리고 로깅을 끊임없이 관리하기 어려운 노이즈의 원천이 아닌 유용한 도구로 활용하는 방법을 알아보겠습니다.

WAF란 무엇이며 등록이 왜 그렇게 중요한가요?

웹 애플리케이션 방화벽(WAF)은 사용자와 서버 사이에 지능형 계층을 형성하여 HTTP/HTTPS 트래픽을 실시간으로 분석합니다. 포트와 IP 주소만 모니터링하는 기존 네트워크 방화벽과 달리, WAF는 URL, 매개변수, 요청 본문, 헤더, 쿠키, HTTP 메서드 등 더 심층적인 분석을 수행합니다.

이 시스템의 목표는 SQL 인젝션, XSS, LFI/RFI, 접근 제어 공격, API 악용, 과도한 스크래핑, 무차별 대입 공격, 그리고 특정 애플리케이션 수준의 DDoS 공격 패턴과 같은 일반적인 레이어 7 공격을 탐지하고 차단하는 것 입니다 . 이를 위해 시스템은 지속적으로 업데이트되는 규칙, 시그니처 및 보안 정책 세트를 활용합니다.

로깅은 동전의 양면과 같습니다. 모든 WAF 결정(허용, 차단 또는 개수만 세기) 에는 로그에 자세한 이벤트가 기록될 수 있습니다 . 이러한 로그를 통해 다음을 수행할 수 있습니다.

• 사건을 조사하다무슨 일이 일어났는지, 그리고 취약점을 악용하려는 시도가 어떻게 이루어졌는지 재구성합니다.
• 조정 규칙WAF가 차단하는 정상적인 요청을 확인하여 오탐을 감지합니다.
• 규정을 준수하다능동적인 통제 조치(PCI DSS, GDPR, 내부 감사 등)가 존재함을 입증하십시오.
• SIEM에 데이터 입력하기애플리케이션 공격을 네트워크, 시스템, 신원 정보 등의 이벤트와 연관시킵니다.

문제는 제대로 설정되지 않은 WAF(웹 방화벽)가 수천 건의 불필요한 이벤트 로 로그를 가득 채워 중요한 것을 찾기 어렵게 만들고, 심지어 정상적인 트래픽까지 불필요하게 차단하는 결과를 초래할 수 있다는 점입니다. 바로 이 지점에서 로깅, 카운팅, 차단 모드를 적절히 조정하는 기술이 중요해집니다.

WAF의 보안 모델: 차단 목록, 허용 목록 및 하이브리드 접근 방식

대부분의 최신 WAF는 여러 필터링 방식을 결합하여 사용하며, 이는 요청 기록 및 차단 방식에 직접적인 영향을 미칩니다 . 크게 두 가지 고전적인 방식과 매우 일반적인 하이브리드 모델을 구분할 수 있습니다.

차단 목록 기반 WAF는 부정적 보안 모델을 따릅니다. 핵심 원칙은 "악성 공격으로 판명된 것을 제외한 모든 것을 허용한다"는 것입니다. 이 모델은 알려진 공격(SQL 인젝션, XSS, 봇 패턴 등)의 특징과 의심스러운 공격으로 간주되는 것을 정의하는 규칙을 사용하여 작동합니다. 초기 배포는 간편하지만, 이 모델에만 의존하면 새로운 공격 벡터나 변종이 탐지되지 않고 침투할 위험이 있습니다.

허용 목록을 사용하는 WAF는 정반대로 작동합니다. 즉, "명시적으로 허용된 트래픽을 제외한 모든 트래픽을 차단"합니다. 이는 긍정적 보안 모델에 기반합니다. 정의된 합법적인 동작(경로, 메서드, 매개변수, 형식, 크기 등)에 맞는 트래픽만 허용됩니다. 훨씬 더 안전하지만, 상당한 세밀한 조정이 필요하며, 제대로 준비되지 않으면 초기에는 오탐이 발생할 수 있습니다.

각 접근 방식의 장단점 때문에 허용 목록과 차단 목록을 결합한 하이브리드 모델이 점점 더 보편화되고 있습니다 . 이 시나리오에서는 예상되는 트래픽 프로필(예: 정상적인 로그인 또는 결제 요청)이 정의되고, 서명과 휴리스틱이 동시에 적용되어 전형적인 악성 패턴을 탐지합니다. 로깅 측면에서 이 하이브리드 접근 방식은 다음과 같은 이점을 제공합니다.

• 마르카르 코모 고위험 이벤트 허용 품목 목록을 위반하는 것.
• 다음과 같이 취급하십시오 중/낮은 우선순위 알림 일반적인 차단 목록 패턴.
• 차단 기능을 활성화하기 전에 어떤 행동이 규칙을 위반하는지 확인하려면 "카운트" 모드를 사용하세요.

네트워크, 호스트 및 클라우드 환경에서의 WAF: 로깅 및 잠금에 미치는 영향

WAF 배포 모델은 트래픽 로깅 및 차단 처리 방식에 큰 영향을 미칩니다. 네트워크 장치에서 요청을 로깅하는 것과 서버 내 에이전트 또는 관리형 클라우드 서비스에서 로깅하는 것은 서로 다릅니다.

네트워크 기반 WAF는 일반적으로 인터넷과 애플리케이션 사이에 물리적 또는 가상 어플라이언스 형태로 인프라 내에 배포됩니다. 이는 F5와 같은 제조업체에서 사용하는 대표적인 방식입니다. 네트워크 기반 WAF는 고성능과 세밀한 제어 기능을 제공 하지만, 구성 및 관리가 복잡할 수 있습니다. 로그는 일반적으로 syslog 또는 중앙 SIEM으로 전송되며, 저장 공간 및 분석 도구의 과부하를 방지하고 IP 및 DNS 네트워크 문제를 진단하기 위해 저장되는 로그를 신중하게 필터링하는 것이 중요합니다.

호스트 기반 WAF는 애플리케이션이 있는 동일한 서버(또는 컨테이너)에서 실행되며, 일반적으로 모듈이나 에이전트 형태로 제공됩니다(예: Nginx 또는 Apache에 통합된 ModSecurity, SELinux를 사용한 Linux 보안 강화 와 결합 시 보안 수준 향상). 이 모델은 애플리케이션 컨텍스트를 더 잘 활용 하고 서비스별로 매우 구체적인 규칙을 적용할 수 있도록 하지만, 로컬 리소스를 많이 사용하고 분산된 로그 관리가 필요하다는 단점이 있습니다. 로그는 로컬 파일에 저장한 후 전달하거나 중앙 집중식 로깅 서비스와 통합할 수 있습니다.

클라우드 기반 WAF (Cloudflare, Akamai, Imperva Cloud, AWS WAF 등)는 로드 밸런서, CDN 또는 가상 네트워크와 통합됩니다. 공급업체는 일반적으로 대시보드를 제공하고 S3, BigQuery, 원격 시스템 로그 또는 SIEM으로 로그를 내보낼 수 있도록 지원합니다. 설정이 비교적 간편하지만, 이벤트 유형, 보존 기간, 심각도 필터 등 로깅 정책을 해당 공급업체의 모델에 맞게 조정해야 합니다.

어떤 모델을 선택할지는 단순히 기술적인 결정일 뿐만 아니라 로깅과 잠금 사이의 균형을 어떻게 맞출 것인지에 대한 문제이기도 합니다. 클라우드 관리형 서비스는 여러 측면을 간소화하지만, 규정 준수 또는 기밀 유지 정책으로 인해 로그 저장 위치를 ​​완벽하게 제어 해야 하는 경우 온프레미스 또는 하이브리드 모델을 고려해야 할 수 있습니다.

약관, 규칙 및 웹 ACL: WAF가 차단, 허용 또는 등록만 할지 여부를 결정하는 방법

제조사와 관계없이 모든 최신 WAF(웹 방화벽)는 액세스 조건, 규칙 및 정책 이라는 개념을 기반으로 합니다 . 이를 이해하는 것은 운영 환경에서 카운팅, 로깅 및 잠금 모드를 성공적으로 사용하는 데 핵심입니다.

조건은 요청 의 어떤 부분을 검사할지 정의합니다. 예를 들어 소스 IP, 특정 HTTP 헤더(Host, User-Agent, Accept, Content-Type 등), 쿼리 매개변수, 요청 본문, 쿠키, HTTP 메서드, 국가 등을 검사 대상으로 지정할 수 있습니다. AWS WAF Classic에서는 최대 10.000개의 주소 또는 IP 범위로 IP 조건을 정의하거나 URL의 일부에 대한 문자열 일치 조건을 정의할 수 있습니다.

규칙은 하나 이상의 조건을 조합하고 허용, 차단 또는 개수 세기와 같은 의도를 지정합니다. 규칙에 여러 조건이 있는 경우 일반적으로 논리 AND 로 평가됩니다 . 즉, 규칙이 활성화되려면 모든 조건이 충족되어야 합니다. 조건이 없는 일반 규칙은 실제로 아무것도 일치하지 않으므로 해당 동작은 절대 실행되지 않습니다.

AWS WAF를 포함한 많은 WAF(웹 방화벽)에는 속도 기반 규칙이 있습니다 . 이러한 규칙은 특정 IP 주소(또는 특정 조건을 충족하는 IP 주소 집합)에서 일정 시간(예: 5분) 동안 도착하는 요청 수를 계산합니다. 임계값(예: 5분 동안 1.000개 요청)을 초과하면 규칙이 적용되어 요청을 차단하거나 단순히 횟수를 계산합니다. 이는 다음과 같은 경우에 매우 유용합니다.

• 제어 로그인 양식에 대한 무차별 대입 공격.
• 공격적인 스크래핑이나 무례한 봇을 제한하세요.
• 애플리케이션 수준에서 특정 유형의 DDoS 공격을 완화하는 방법.

다음 단계는 웹 ACL(접근 제어 목록) 입니다 . 여기서는 규칙들이 그룹화되고, 평가 순서와 기본 동작(허용 또는 차단)이 정의됩니다. 요청은 순서대로 규칙을 통과하며, 규칙 중 하나와 일치하면 해당 규칙의 동작이 적용되고 나머지 규칙에 대한 평가는 중단됩니다. 일치하는 규칙이 없으면 ACL에 정의된 기본 동작이 적용됩니다.

로깅과 차단 사이의 균형을 맞추는 측면에서, ACL은 시스템을 기본적으로 관대하게(특정 규칙에 따라서만 차단하고 허용) 설정할지, 아니면 매우 엄격하게(예외적인 경우를 제외하고 차단) 설정할지를 결정하는 곳입니다. 또한, 많은 솔루션에서 ACL 내에 "카운트" 모드로 규칙을 설정할 수 있도록 지원하므로, 일치하는 항목은 로깅하지만 트래픽은 차단하지 않아 튜닝 단계에 적합합니다.

화이트리스트 및 로그 노이즈 감소

허용 목록은 로그에서 오탐과 노이즈를 줄이는 데 필수적인 도구입니다 . 원리는 간단합니다. 특정 상황에서 WAF(웹 방화벽)에게 이미 신뢰할 수 있는 트래픽으로 분류했거나 일반적인 트래픽이 아니지만 합법적인 트래픽에 대해 특정 지침이나 규칙 집합을 적용하지 않도록 지시하는 것입니다.

예를 들어 AWS WAF에서는 특정 IP 주소 또는 IP 범위 로부터 요청이 들어 오거나 알려진 URL 패턴 및 HTTP 메서드와 일치하는 경우 특정 서명 검사가 적용되지 않도록 허용 목록 규칙을 생성할 수 있습니다. 이는 다음과 같은 이점을 제공합니다.

• "특이한" 패턴을 사용하는 내부 API를 방지하세요. 지속적으로 오탐을 생성합니다..
• 이미 신뢰할 수 있다고 판단되는 트래픽에 대한 심층 검사로 인해 발생하는 지연 시간을 줄이세요.
• WAF 로그에서 불필요한 기록의 양을 줄이십시오.

ModSecurity와 같은 플랫폼에서는 표준 규칙(예: OWASP 핵심 규칙 세트)을 수정하는 대신, 특정 매개변수, 경로 또는 사용자에 대해 규칙 ID별로 특정 제외 규칙을 생성하는 것이 좋습니다 . 이렇게 하면 사이트 전체의 규칙을 비활성화하여 심각한 취약점을 만들지 않고도 전반적인 보안을 유지할 수 있습니다.

핵심은 허용 목록을 일괄적으로 적용하는 것이 아니라, 세부적으로 관리하는 것입니다. 규칙 X를 전역적으로 비활성화하는 것보다 특정 조합(예: URL Z에서 규칙 X와 매개변수 Y의 조합)을 제외하는 것이 훨씬 효과적입니다. 이렇게 하면 로깅이 유용하게 유지되고 불필요한 사각지대가 생기지 않습니다.

프로토콜 규칙 및 제한 사항: 차단 시점과 경고 시점

많은 웹 방화벽(WAF)에는 형식이 잘못되었거나 의심스러운 트래픽을 걸러내는 1차 필터 역할을 하는 HTTP 프로토콜 검증 규칙이 포함되어 있습니다 . 이러한 규칙은 필수 헤더, 메서드, 인자 크기 등을 검사하며, 제대로 이해하지 못하면 효과적인 보호 기능을 제공하기도 하지만 오탐을 유발하는 원인이 되기도 합니다.

매우 흔한 몇 가지 예는 다음과 같습니다.

• Accept 헤더가 누락되었습니다 (Accept 헤더 누락): 이는 엄밀히 말하면 RFC 위반은 아니지만, 이 헤더가 없는 요청은 자동화 도구나 제대로 작성되지 않은 스크립트에서 발생하는 경우가 많습니다. Accept 헤더를 전송하지 않는 사용자 지정 API나 클라이언트에 영향을 미칠 수 있습니다. 많은 환경에서 직접적인 차단보다는 로깅 및 카운팅이 더 효과적입니다.
• 호스트 헤더가 누락되었습니다HTTP/1.1 표준에 따르면 Host 헤더는 필수입니다. WAF(웹 방화벽) 또한 적용할 정책을 결정하기 위해 Host 헤더가 필요합니다. 일반적으로 이를 차단하는 것이 적절하지만, 테스트 중이나 내부 트래픽 구성 오류로 인해 오탐이 발생할 수 있으므로 엄격한 차단을 활성화하기 전에 로그를 모니터링하는 것이 좋습니다.
• User-Agent 헤더가 누락되었습니다.이 규칙은 기본적인 봇과 식별되지 않은 트래픽을 억제하기 위한 것입니다. 문제는 많은 합법적인 API가 사용자 에이전트를 전송하지 않을 수 있다는 점입니다. 일반적으로 가장 합리적인 접근 방식은 로그를 기록하고, 일관되고 합법적인 API가 감지되면 이를 차단하는 것입니다. 해당 IP 주소 또는 패턴을 허용 목록에 추가하세요.
• 본문을 사용한 GET/HEAD 유효성 검사RFC에서는 GET 또는 HEAD 요청과 함께 본문을 전송하는 것을 엄격하게 금지하지는 않지만, 이는 일반적인 관행이 아니며 회피 시도로 간주될 수 있습니다. 따라서 대부분의 경우, 이러한 모든 요청을 기록하고 의심스러운 이상 징후로 판단되면 차단하는 것이 첫 번째 단계입니다.
• 본문에 Content-Type이 누락되었습니다.본문은 있지만 콘텐츠 유형이 없는 경우, 이는 프로토콜을 잘못 사용했거나 분석을 회피하려는 시도임을 명확히 나타냅니다. 이러한 경우에는 특히 인터넷에 노출된 환경에서 더욱 강력한 차단 방식을 적용하는 것이 효과적일 수 있습니다.

이러한 프로토콜 규칙 외에도, 애플리케이션 수준의 트래픽 폭주 및 DoS 공격을 방지하기 위해 인자 제한이 종종 사용됩니다. 예를 들면 다음과 같습니다.

• 요청당 최대 인자 개수(일부 WAF에서는 기본값이 255개입니다).
• 개별 인수의 최대 길이(예: 400자).
• 모든 인수의 총 크기(예: 64.000바이트).

이러한 값은 대부분의 애플리케이션에 적합하지만, 복잡한 양식 업로드, 고급 필터, 대용량 JSON 로드와 같은 경우에는 오탐이 발생할 수 있습니다. 이러한 시나리오에서는 먼저 로그를 기록하고 사용량을 계산하여 제한을 초과하는 엔드포인트를 확인하고, 전체 사이트의 모든 제한을 해제하는 대신 해당 경로에 대해서만 조정하는 것이 가장 현명한 접근 방식입니다.

오탐지: 이를 탐지하고 실패하지 않는 방법

오탐은 정상적인 요청을 WAF(웹 방화벽)가 악성으로 오인하여 차단하거나 공격으로 표시하는 현상입니다. 특히 OWASP CRS와 같은 포괄적인 규칙 세트를 사용하는 경우 오탐은 불가피하지만, 전문가의 도움을 받으면 일상적인 골칫거리가 되지 않도록 관리할 수 있습니다.

오탐을 탐지하는 작업은 로그를 꼼꼼히 검토하는 것에서 시작됩니다 . 여기에는 어떤 요청이 차단되었는지, 어떤 규칙이 해당 요청을 트리거했는지, 그리고 어떤 컨텍스트(URL, 매개변수, 사용자, 출처 등)에서 발생했는지를 살펴보는 것이 포함됩니다. 시각화 도구와 대시보드를 활용하면 403 오류의 급증이나 비정상적인 패턴을 파악하는 데 도움이 될 수 있습니다.

클라우드 제공업체와 ModSecurity 커뮤니티 모두에서 강력히 권장하는 접근 방식은 시뮬레이션 또는 카운트 모드를 사용하는 것입니다 . 이 모드에서는 테스트하려는 규칙이 각 일치 항목을 기록하지만 차단하지는 않습니다. 이를 통해 예를 들어 새로운 SQLi 규칙을 프로덕션 환경에 적용하기 전에 해당 규칙이 얼마나 많은 정상적인 요청을 차단하는지 확인할 수 있습니다.

실제 트래픽이나 모의 트래픽을 수신하는 스테이징 또는 사전 프로덕션 환경 에서 규칙을 테스트하는 것도 좋은 방법입니다 . OWASP ZAP이나 트래픽 재생 스크립트와 같은 도구를 사용하면 정상적인 패턴과 알려진 공격을 시뮬레이션하여 WAF의 동작을 테스트할 수 있습니다.

또한, 오탐이 운영 및 평판에 미치는 영향을 고려하는 것이 중요합니다. 결제 중단, 사용자 등록 실패, 설명 없이 실패하는 중요 API 호출 등은 모두 매출 손실과 브랜드 이미지 손상으로 이어질 수 있습니다. 과도한 오탐은 보안팀에 실질적인 가치가 없는 경고를 쏟아내어 실제 사고를 식별하기 어렵게 만듭니다.

규칙 조정 전략 및 레지스트리의 지능적 활용

오탐 관리란 "모든 것이 제대로 작동할 때까지" 규칙을 끄는 것이 아니라, 외과 수술처럼 정밀하게 WAF(아동 승인 기준)를 미세 조정하는 것입니다 . 바로 이 부분에서 다음과 같은 모범 사례가 중요한 역할을 합니다.

첫째, 규칙을 전역적으로 비활성화하는 것은 피하십시오. 특정 경로, 특정 매개변수 또는 내부 트래픽에 대해서만 규칙 ID를 제외하는 등 매우 구체적인 예외를 생성하는 것이 좋습니다 . 이렇게 하면 애플리케이션의 나머지 부분은 보호되고 유용한 로그를 유지할 수 있습니다.

둘째, 차단하기 전에 카운팅 모드를 활용하세요 . 새 규칙을 처음에는 로깅 모드에서만 활성화하면 영향을 받는 정상적인 요청 수를 측정할 수 있습니다. SIEM에서 알림 기능을 추가하면 규칙으로 인해 비정상적으로 많은 일치 항목이 발생하는 경우 신속하게 감지할 수 있습니다.

셋째, WAF를 SIEM 또는 중앙 집중식 로깅 플랫폼 과 통합하십시오 . 이렇게 하면 WAF 이벤트를 비정상적인 시스템 활동, 대량 인증 실패, 의심스러운 구성 변경 등과 같은 다른 지표와 연관 짓기가 더 쉬워집니다. 또한 이벤트의 심각도와 빈도를 기준으로 어떤 규칙을 먼저 조정해야 할지 우선순위를 정하는 데 도움이 됩니다.

넷째, 모든 변경 사항을 문서화하십시오. 어떤 규칙이 어떤 엔드포인트에 대해 어떤 근거로, 어떤 증거를 바탕으로 세부 조정되었는지 기록해야 합니다. 서버 설명서를 참조하면 도움이 될 수 있습니다. 이러한 문서는 내부 통제를 유지하는 데 도움이 될 뿐만 아니라, 보안 감사 및 검토 시 통제가 쉽게 해제되지 않았음을 입증하는 데 매우 중요합니다.

WAF에서의 자동화, 머신러닝 및 적응형 규칙

애플리케이션이 성장하고 트래픽이 복잡해짐에 따라 WAF를 수동으로 관리하는 것은 비현실적입니다. 바로 이 지점에서 자동화, 고급 로그 분석, 그리고 경우에 따라 머신 러닝이 중요한 역할을 합니다.

첫째, SIEM과의 통합을 통해 상관관계 규칙과 자동화된 대응을 구축할 수 있습니다 . 예를 들어, 특정 IP 주소 집합이 반복적으로 인젝션 공격이나 XSS 공격 규칙을 트리거하는 경우, 해당 IP 주소를 임시 차단 목록에 추가하거나 검사 수준을 강화하는 자동 조치를 생성할 수 있습니다.

둘째로, 일부 WAF(웹 방화벽)는 특정 기간 동안 정상적인 트래픽을 관찰하는 머신 러닝 모드를 통합하고 있습니다 . 이 데이터를 기반으로 정상적인 동작에 대한 임계값, 패턴 및 프로필을 제안하거나 조정합니다. 이는 규칙이 차단 모드로 전환될 때 오탐을 줄이고 이후 트래픽 편차를 감지하는 데 도움이 됩니다.

연구 및 실험실 환경에서 지도 학습 기법은 정상 트래픽과 악성 트래픽을 구분하는 모델을 훈련하는 데 사용되어 왔으며, 이를 통해 개선된 정책은 실제 운영 환경에 적용됩니다. 이 접근 방식이 만능 해결책은 아니지만, 기존의 시그니처 기반 규칙으로는 쉽게 감지할 수 없는 미묘한 패턴을 찾아내는 데 도움이 될 수 있습니다.

마지막으로, OWASP ZAP과 같은 도구, 사용자 지정 스크립트 또는 CI/CD 파이프라인을 활용한 지속적인 자동화 테스트를 통해 WAF 변경 사항이 핵심 기능을 손상시키거나 명백한 취약점을 남기지 않는지 검증할 수 있습니다. 이러한 테스트를 배포 주기에 통합하면 보안이 개발 흐름의 자연스러운 일부가 되어, 마지막 순간에 추가하는 패치가 아닌 필수적인 요소가 됩니다.

애플리케이션별 정책 설계 및 서비스별 블랙리스트

호스팅 제공업체나 ISP와 같은 복잡한 환경에서는 특히 섀도우 IT가 관련된 경우 단일 WAF 정책만으로는 충분하지 않습니다 . 여러 도메인이나 애플리케이션이 동일한 로드 밸런싱 장치 뒤에 연결되어 있고, 각각 다른 보안 요구 사항과 트래픽 프로필을 갖는 경우가 흔합니다 . 이러한 상황에서 서비스별 정책 및 목록을 설계하는 것이 필수적입니다.

한 가지 예시로 , 단일 가상 IP 주소 뒤에 있는 여러 사이트 (예: www.company1.com 및 www.company2.com)에 대한 리버스 프록시 역할을 하는 HTTP/S 로드 밸런서를 들 수 있습니다. 이 시나리오에서 WAF는 요청이 로드 밸런싱 모듈에 도달하기 전, 요청이 도착하는 즉시 호스트 헤더와 소스 IP 주소를 평가하도록 구성할 수 있습니다.

로직은 대략 다음과 같습니다. WAF는 SERVER_NAME(호스트)과 클라이언트 IP 의 조합이 사이트별 블랙리스트와 일치하는지 확인합니다. 만약 해당 IP가 www.company2.com에 대해서는 차단되었지만 www.company1.com에 대해서는 차단되지 않은 경우, 첫 번째 경우에만 403 Forbidden 응답이 전송됩니다. 이렇게 "정상"으로 판정된 트래픽은 로드 밸런싱 모듈로 전달되어 어떤 백엔드 서버가 요청을 처리할지 결정합니다.

이를 통해 전체 액세스 포인트에 대한 단일 전역 목록 대신 도메인별 블랙리스트를 유지 관리할 수 있습니다 . 로깅 수준에서 각 거부는 규칙 ID, 일치 조건, URL, 호스트 및 클라이언트의 IP 주소와 같은 세부 정보와 함께 syslog에 기록되므로 후속 분석 및 목록 확장 또는 디버깅이 용이합니다.

이 이야기의 교훈은 정책을 애플리케이션, 환경, 사용자 유형별로 세분화할수록 로깅과 차단 사이의 균형을 더욱 세밀하게 맞출 수 있다는 것입니다. 예를 들어 관리 포털에서는 매우 엄격하게 적용하고 정보 제공 웹사이트에서는 다소 유연하게 적용할 수 있으며, 각 결정이 내려진 이유에 대한 증거는 항상 로그에 기록해야 합니다.

기존 WAF를 뛰어넘는 WAAP 및 API 보호

위협 환경은 끊임없이 변화해 왔습니다. 오늘날 많은 애플리케이션은 클라우드 네이티브 방식으로 개발되고, 마이크로서비스 아키텍처를 사용하며, 공개 및 비공개 API를 노출하여 공격자들의 주요 표적이 되고 있습니다. 기존의 웹 방화벽(WAF)은 WAAP(웹 애플리케이션 및 API 보호) 또는 WAAS(웹 애플리케이션 및 API 보안)와 같은 더욱 포괄적인 플랫폼으로 발전했습니다.

이러한 솔루션은 웹 애플리케이션을 자동으로 검색할 뿐만 아니라 API 엔드포인트를 식별하고 , OpenAPI 또는 Swagger와 같은 명세를 수용하며, 해당 정의를 사용하여 요청의 규정 준수 여부(예상 데이터 유형, 허용 매개변수, 크기 제한 등)를 확인합니다. 엔드포인트의 특성(예: 매우 민감한 데이터를 처리하는 엔드포인트)에 따라 훨씬 더 높은 수준의 검사 및 차단 기능을 적용할 수 있습니다.

WAAP는 로깅 수준에서 공격받은 API 엔드포인트, 실행된 작업(GET, POST, PUT 등), 관련 사용자 또는 토큰, 위반된 API 사양 등과 같은 풍부한 컨텍스트 정보를 담은 이벤트를 생성하는 경향이 있습니다. 이를 통해 일반적인 페이로드 패턴에만 의존하는 것이 아니라 더욱 정확한 차단 결정을 내릴 수 있습니다.

또한, 많은 WAAP 도구에는 애플리케이션 및 API별 DoS 공격 방지, 지리적 위치 필터링, IP 평판 관리, 봇 및 스크래핑 탐지, 서비스별 알림 수준 맞춤 설정 옵션 등이 포함되어 있습니다. 핵심은 강력한 접근 방식을 원하는 부분과 원활한 운영을 우선시하는 부분을 유연하게 선택할 수 있으면서도 , 모든 사고 조사를 위한 견고한 로그 데이터베이스를 유지할 수 있다는 점입니다.

종합적으로 볼 때, 기존 WAF든, WAAP 기반이든, 클라우드 생태계에 통합된 WAF든, 잘 조정된 WAF는 상세한 로깅, 지능형 차단, 그리고 변화하는 위협 환경에 대한 지속적인 적응성을 결합하여 현대적인 애플리케이션 및 API 방어에 필수적인 요소가 됩니다.