프록시 기반 웹 애플리케이션 방화벽(WAF)은 애플리케이션 보호에 필수적인 구성 요소입니다. WAF는 PCI-DSS 준수를 위한 필수 요건일 뿐만 아니라 OWASP Top 10 위협을 방어하는 데도 매우 효과적입니다. 또한 시그니처 업데이트를 신속하게 배포하거나, 경우에 따라 장기적인 해결책을 적용하는 동안 프로그래밍 기능을 사용해 애플리케이션에 가상 패치를 적용함으로써 제로데이 취약점에 대응하는 대표적인 솔루션이기도 합니다.
문제는 이러한 보호 기능을 어디에 배치하느냐입니다.
물론 선택지는 여러 가지입니다. 데이터 경로에는 WAF를 배포할 수 있는 지점이 여러 곳 있습니다. 하지만 모든 지점이 적합한 것은 아닙니다. 어떤 지점은 다른 지점보다 효율성이 떨어지고, 어떤 지점은 용납할 수 없는 장애 지점을 만들며, 또 어떤 지점은 시간이 지날수록 막대한 대가를 치르게 되는 아키텍처 부채를 초래합니다.
이상적으로는 WAF를 로드 밸런싱 계층 뒤에 배포하는 것이 좋습니다. 이렇게 하면 리소스 활용도, 성능 및 안정성을 최적화하는 동시에 모든 애플리케이션, 특히 인터넷에 노출된 애플리케이션에 필요한 보호 기능을 제공할 수 있습니다.
활용
부하 분산 결정을 내리는 데 필요한 리소스(CPU 등)는 매우 적습니다. 일반적으로 LB가 수백만 명의 사용자를 동시에 지원할 수 있는 반면 WAF에는 더 많은 리소스가 필요한 이유는, WAF가 전체 페이로드를 검사하고 서명 및 정책과 대조하여 요청이 유효하고 안전한지 판단하기 때문입니다.
현대적인 데이터 센터 모델은 클라우드와 사용량 기반 비용 구조를 상당 부분 차용합니다. 이에 따라 활용률은 운영 비용을 좌우하는 핵심 요소가 됩니다. 활용률이 높아지면 추가 리소스가 필요해져 예산이 소모됩니다. 따라서 활용률을 최적화하는 것은 데이터 센터와 퍼블릭 클라우드 환경 모두에서 비용을 억제하기 위한 효과적인 전략입니다.
안정성
WAF를 수평 확장하는 것은 일반적인 방식입니다. 즉, LB를 사용하여 WAF를 확장합니다. 이러한 아키텍처 결정은 리소스 활용률과 직접적인 관련이 있습니다. 많은 WAF가 원활하게 확장되지만, 갑작스러운 트래픽이나 공격으로 인해 과부하가 발생할 수 있습니다. WAF가 LB 앞에 배치된 경우, WAF를 별도로 확장하려면 또 다른 LB 계층이 필요하며, 그렇지 않으면 성능과 가용성에 영향을 줄 위험이 있습니다.
성능
성능은 애플리케이션 경제에서 핵심적인 고려 사항입니다. 데이터가 데이터 경로를 통과하는 동안 수많은 변수와 시스템이 데이터와 상호 작용하므로, 정확히 어느 지점에서 성능 저하가 발생하는지 파악하기도 어렵고 다른 요소에 영향을 주지 않으면서 각 요소를 조정하기는 더욱 어렵습니다. 앞서 여러 차례 언급했듯이 시스템 부하가 증가하면 성능은 저하됩니다. 이는 사용률을 최적화하지 않을 때 발생하는 의도치 않은 결과 중 하나이며, 숙련된 네트워크 아키텍트가 네트워크 장치의 사용률 임계값을 60%로 설정하는 주된 이유이기도 합니다.
LB 계층 뒤에 WAF를 배포하면 업스트림에 별도의 WAF 부하 분산 계층을 둘 필요가 없어져 네트워크 계층 하나를 통째로 제거할 수 있습니다. 단축되는 처리 시간이 별것 아닌 것처럼 보일 수 있지만, 연결을 관리하고 WAF 서비스를 확장한 다음 대상 앱 인스턴스/서버를 선택하기 위해 같은 작업을 다시 수행하는 데 소요되는 소중한 마이크로초는 매우 중요합니다. LB 계층 뒤에 WAF를 배포하여 이 계층을 제거하면 소중한 마이크로초를 되찾을 수 있으며, 오늘날의 사용자들은 이를 체감할 뿐만 아니라 높이 평가할 것입니다.
가시성
가시성은 데이터 경로에 배치되는 보안 솔루션의 핵심 요구 사항입니다. 페이로드를 포함한 전체 트래픽 흐름을 검사할 수 없다면 WAF의 보안 기능 대부분은 무용지물이 됩니다. 결국 대부분의 악성 코드는 프로토콜 헤더가 아니라 페이로드 내에서 발견됩니다. WAF를 LB 계층 뒤에 배치하면 트래픽이 검사를 위해 WAF로 전달되기 전에 SSL/TLS를 복호화할 수 있습니다. 요청을 올바르게 라우팅하려면 로드 밸런서도 보안 트래픽을 확인할 수 있어야 할 가능성이 높으므로, 이 방식이 더 바람직한 아키텍처입니다.
그렇기는 하지만 WAF는 원하는 거의 모든 위치의 데이터 경로에 배치할 수 있습니다. WAF는 네트워크 경로의 중간 지점에 배포되는 L7 프록시 기반 보안 서비스입니다. 원한다면 네트워크 에지에 배치할 수도 있습니다. 하지만 성능, 안정성, 활용도를 동시에 고려해 아키텍처를 최적화하려면 WAF를 로드 밸런싱 계층 뒤쪽, 즉 보호 대상 애플리케이션에 더 가까운 위치에 배치하는 것이 가장 좋습니다.
적절한 도구를 사용해 WAF를 포괄적으로 적용하면 위협 노출과 운영 비용을 크게 줄일 수 있습니다. F5의 온디맨드 웨비나를 통해 OWASP Top 10 및 기타 위협으로부터 애플리케이션을 보호하는 방법을 자세히 알아보고, F5의 클라우드 기반 Silverline WAF 관리형 서비스를 비롯해 F5 WAF 기능을 배포할 수 있는 다양한 방법을 살펴보세요.
F5 보안 아키텍트 Brian McHenry와 수석 위협 연구 에반젤리스트 David Holmes가 이 글에 기여했습니다. 2019년 8월에 일부 내용을 수정했습니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.