웹방화벽
웹방화벽(WAF, Web Application Firewall)은 일반적인 네트워크 방화벽과는 다르게 웹 애플리케이션 보안에 특화되어 개발된 제품이다. 기본 역할은 SQL 인젝션(injection), 크로스사이드스크립팅(XSS) 등과 같은 웹 공격을 탐지하고 차단하는 것이다. 기존의 웹방화벽은 웹공격 대응 기능만을 제공했지만 최근에는 정보유출방지, 부정접근방지, 위변조 방지 등의 기능까지 제공하는 웹방화벽도 등장하였다.
개요[편집]
웹방화벽은 일반적인 네트워크 방화벽과는 다르게 웹 애플리케이션 보안에 특화되어 개발된 제품이다. 웹방화벽의 기본 역할은 SQL 인젝션, 크로스사이드스크립팅 등과 같은 웹 공격을 탐지하고 차단하는 것인데, 직접적인 웹 공격 대응 이외에도, 정보 유출방지 솔루션, 부정 로그인 방지 솔루션, 웹사이트 위변조방지 솔루션 등으로 활용할 수 있다. 정보 유출방지 솔루션의 경우, 개인정보가 웹 게시판에 게시되거나 개인정보가 포함된 파일 등이 웹을 통해 업로드 및 다운로드될 때에 탐지하고 대응하는 것이 가능하고, 부정 로그인 방지 솔루션의 경우, 추정 가능한 모든 경우의 수를 대입하여 웹사이트에 로그인을 시도하는 경우와 같은 비정상적인 접근에 대한 접근제어 기능을 하며, 웹사이트 위변조방지 솔루션의 경우, 해커가 해킹한 후에 과시하는 것이 목적인 웹사이트 위변조가 발생했을 경우, 이에 대해 탐지하고 대응한다.
웹앱(Web Application)은 인터넷을 통해서 사용하는 홈페이지 대부분의 서비스를 의미한다. 웹 공격의 대부분은 웹앱을 구축할 때 생겨나는 취약점을 이용해서 웹 서버를 공격하거나 데이터베이스 내용을 악용하는 방법으로, 공격자는 HTTP 요청에 특정 공격 코드 또는 특정 웹앱만이 가지고 있는 취약점을 우회하는 코드를 삽입하여 웹앱에 전송하게 된다. 웹방화벽의 역할은 이러한 웹 서버 쪽으로 전송되는 모든 HTTP 요청 패킷을 검사하여 웹앱에 의도하지 않은 내용이 전송되지 못하게 막는 역할을 한다. 또, 웹 서버에서 통과하는 HTTP 응답 내용을 감시하여 특정 정보의 유출을 막는 역할도 한다. 웹방화벽은, 패킷을 검사하는 원리는 프록시 서버의 원리에서 가져온 것이다. 프록시 서버의 역할은 클라이언트와 서버 간의 통신을 중계하고 응답하는 것이다. 웹방화벽의 원리는 웹 서버로 들어오고 나가는 모든 패킷을 프록시 서버의 원리를 적용하여 패킷의 내용을 검사하고 차단하는 것이다.[1]
스마트폰, 태블릿 PC 등의 사용이 급증하면서 웹 대중화 시대가 오게 되었다. 그러면서 웹 위협에 대한 노출 가능성도 증가하였지만 많은 사용자가 보안의 필요성에 대해서 인식하지 못하고 있다. 4차 산업혁명의 기술 중 하나인 사물인터넷(IOT, Internet Of Things)은 각종 사물에 센서와 통신 기능을 내장하여 인터넷에 연결하는 기술이다. 사물인터넷에는 모든 사물이 웹 해킹의 대상이 될 수도 있어 사물인터넷을 위한 웹보안이 필요하다. 웹 사용률 증가와 더불어 웹을 통해 이루어지는 통신을 암호화하여 보호하는 SSL 사용률이 증가하고 있다. 하지만 SSL 트래픽을 이용하여 웹 공격을 하는 것 또한 가능하기 때문에 임시방편에 불과하다. 대량의 개인정보 유출을 했던 사이버 공격들도 모두 웹을 통한 공격이었다. 금융감독원에서 대량 개인정보 유출 사고 관련하여 동일 사건 재발생 방지를 위한 목적으로 2014년 1월 27일 '고객 정보 보호 실태 점검 요청' 공문을 시행, 해당 자료에서 웹방화벽을 언급하며 침입 차단 시스템으로서의 운용 필요성을 언급하고 있다.[2]
역사[편집]
웹방화벽이 등장하기 전에는 방화벽, 침입탐지시스템(IDS, Intrusion Detection System), 침입방지시스템(IPS, Intrusion Prevention system)이 네트워크 보안을 책임지고 있었다. 방화벽은 네트워크 패킷 중 네트워크 프로토콜의 TCP/IP 레이어에서 아이피(IP)와 포트 정보를 가지고 방어를 한다. 침입 탐지시스템, 침입 방지 시스템은 네트워크 프로토콜에서 애플리케이션 프로토콜의 패킷 내용을 문자열 비교에 의해 침입 시도를 감시하고 차단하는 역할을 한다. 하지만 네트워크 보안제품의 한계로 각종 침해사고가 발생하여 웹 해킹을 전담으로 하는 웹방화벽이 화제가 되었고 초기의 웹방화벽은 이 세 개의 시스템에 영향을 받아 웹 트래픽을 공격 구문과 비교하여 검사하는 방식인 블랙리스트 기반 탐지 방식을 채택하였다. 이와 같은 동작 방식의 세분화를 통해 웹방화벽의 세대를 구분할 수 있다.
1세대 웹방화벽은 블랙리스트 방식과 안전한 접근에 대한 허용 리스트인 화이트리스트를 병행하는 방식을 사용하였다. 자동으로 온라인 업데이트되는 블랙리스트와는 다르게 화이트리스트는 클라이언트의 환경에 따라 다르게 적용되기 때문에 관리자가 직접 생성 및 관리를 해야 해서 관리자에게 큰 부담이 되었고 다양한 공격에 대한 분석 없이 대응하여 다량의 긍정 오류이 발생했다. 공격 유형의 다양화에 따른 등록된 시그니처 수 증가에 의한 성능 저하가 발생했다. 이러한 1세대 웹방화벽의 문제점을 극복하기 위해 2세대 웹방화벽에서는 자동으로 온라인 업데이트되는 블랙리스트와 몇 주간의 모니터링 결과를 기반으로 화이트리스트 생성을 자동으로 처리해주었다. 하지만 2세대 웹방화벽 또한 화이트리스트의 적용을 위한 검토 및 관리가 필요했기 때문에 관리자의 부담이 컸다. 1세대, 2세대의 웹방화벽 탐지 방식은 웹 보안 환경과 어울리지 않아 많은 성능 저하 및 긍정 오류을 일으켰다. 그렇게 해서 등장하게 된 것이 3세대 지능형 웹방화벽이다.
3세대 웹방화벽은 웹 공격 유형별로 블랙리스트, 화이트리스트를 탐지, 웹 트래픽 콘텐츠 분석 등의 기법들을 결합하여 공격을 탐지하는 방식을 사용한다. 웹 공격 유형별 로직에 따라 웹 트래픽 콘텐츠를 검사하여 해당 종류의 공격인지 아닌지 사실 여부를 판단하기 때문에 1세대, 2세대 웹방화벽 대비 긍정 오류률이 낮다. 또 특정 공격 유형의 새로운 변종 공격이 발생할 경우, 새로운 시그니처를 등록해야 하거나, 많은 관리 부담에도 불구하고 화이트리스트를 잘 설계해서 적용해야 했던 1세대, 2세대 웹방화벽과는 다르게 시그니처 기반 탐지가 아닌 공격 로직 분석을 통한 탐지를 수행하기 때문에 신종 변종 공격에 대해서도 즉각적 대응이 가능하다. 최소한의 신규 시그니처 추가만으로 변종 공격 방어가 가능해서 성능 저하 이슈 발생률도 줄어들었고 1세대, 2세대 공통적인 문제점이었던 관리자의 시그니처 관리 부담이 사라져 효율적인 보안 관리가 가능해졌다.[3]
특징[편집]
기능[편집]
웹방화벽은 HTTP/HTTPS의 요청/응답 메시지 내용을 분석, 포지티브 정책과 네거티브 정책을 혼용하여 탐지 기능을 수행한다. 요청 메시지의 가장 큰 특징은 URL 단위의 탐지 기능이다. 해당 사이트는 서비스를 제공할 URL을 포지티브 정책으로 설정하면, 등록된 URL 외의 다른 URL을 사용자가 요청할 경우 탐지하여 요청 거부 메시지를 보낸다. 이러면 악의적인 사용자가 정상적인 URL 외의 다른 URL로 접근하는 것을 막을 수 있다. 네거티브 정책에서는 정상적인 URL에서 악의적인 공격 패턴 크로스사이드스크립팅, SQL 인젝션, 운영체제 명령어 삽입 공격(OS Command Injection) 등을 검출해 내는 문자열 비교 정책을 추가할 수 있다. 요청 메소드(GET, POST, OPTION)까지도 포지티브 정책에 설정할 수 있다. 특정 URL에서만 사용하는 쿠키/숨은 필드나 파라미터값들을 설정하여 정교한 탐지 기능을 제공한다. 파일 업로드 제어 기능과 파일 검사 기능을 지원한다. 사용자가 웹 서버로 올리는 파일에 대해 파일의 종류에 따라 업로드를 허용, 차단 여부를 지정할 수 있다. 업로드 파일의 내용을 검사하여 악의적인 공격 형태의 파일들은 파일 필터를 통해 업로드가 차단되어 웹 사이트를 악용하는 사용자로부터 안전하게 보호하는 역할을 한다.
응답 메시지의 대표적인 기능은 웹 서버의 에러 또는 오류 정보를 차단하여, 악의적인 사용자가 웹 서버에 대한 정보를 알 수 없게 하는 것이다. 요즘은 주요 정보를 차단하는 데 많이 사용되고 있다. 사용자의 주민등록번호, 휴대폰 번호, 집 주소, 이메일 주소, 카드번호 등의 개인 정보들이 다른 사용자들에게 노출되는 것을 방지하는 것이다. 부가적으로 웹 가속 기능이나, SSL 가속 기능, 캐시 기능들을 지원한다. 웹방화벽 탐지기술의 장점은 HTTP 프로토콜 속성값의 작은 단위까지도 정책설정이 가능하다. 웹 서비스 개발 시점에 신경 쓰지 못했던 보안상의 문제점들을 보완할 수 있어 웹 서비스를 보다 안전하게 사용자들에게 제공할 수 있다.
웹방화벽은 웹에 특화된 L7(Application Layer)방화벽이라고 할 수 있다. 웹 서비스 취약점을 이용한 공격을 탐지/차단하는 보안시스템이다. 10대 웹 애플리케이션의 취약점을 기반으로 적용된 차단 룰을 바탕으로 방어한다. 차세대 방화벽, IPS 등에서도 웹 취약점들에 대해 탐지가 가능하지만 엄청나게 비싸기 때문에 상대적으로 저렴하면서 주된 공격인 웹 애플리케이션 공격을 막고 또한 SSL 통신을 탐지하는 것이 가능하기 때문에 웹화벽을 사용하는 것이다. 주로 사용되는 웹방화벽에는 펜타시큐리티의 와플(Wapples), 아리엘(Ariel) 사의 웹인사이트(Web insight), 바라쿠다(Barracuda)의 바라쿠다 웹방화벽 등이 있다. 국내에서는 펜타시큐리티의 와플을 많이 사용한다. 거의 90% 이상이 사용된다고 한다.[1][4]
[5]기본 보안 기능 설명 SQL 인젝션 SQL 쿼리 삽입 공격을 모니터링 및 차단한다. 명령어 삽입
명령어 실행원격 커맨드 실행, 커맨드 삽입 공격을 모니터링 및 차단한다. 크로스사이트스크립팅
(XXS)웹 스크립트 삽입 공격을 모니터링 및 차단 인코딩
(Encoding)URL 등과 같은 다른 인코딩 방식으로 우회 공격하는 것을 모니터링 및 차단한다. 도스
(DoS)GET Flooding, 캐시 제어(Cache-Control) 공격을 차단한다. HTTP Method PUT, Delete, Trace, option, head 등을 모니터링 및 차단한다. 프로빙
(Probing)알려진 스캔성 공격들을 모니터링 및 차단한다. 경로 조작
(Path Traversal)디렉터리 접근 공격을 모니터링 및 차단한다. 파일 업로드 확장자 기반 업로드를 차단한다. 관리자 URL 접근 제어 관리자 페이지와 같은 중요 페이지에 대한 접근 가능 IP 및 대역을 설정한다. 업무 시간 지정 업무 시간 외 접근을 차단한다. 휴일 지정 휴일로 지정한 일에는 접근을 차단한다. 국가별 차단 관리자가 지정한 국가 IP 접속을 차단한다.
종류[편집]
네트워크 기반 웹방화벽은 일반적으로 하드웨어에 기반한다. 네트워크 기반 웹방화벽은 로컬에 설치되기 때문에 대기 시간을 최소화하고 단일 장비로 다수의 웹 서버에 대한 보안과 해킹 시도를 차단할 수 있다. 가장 비용이 많이 드는 옵션이며 실제 장비를 보관하고 유지 관리해야 한다. 웹서버 바로 앞단에 어플라이언스 장비를 두고 웹페이지에 대한 방어를 하는 장비다. 호스트 기반 웹방화벽은 애플리케이션의 소프트웨어에 완전히 통합될 수 있다. 이 솔루션은 네트워크 기반 웹방화벽보다 비용이 저렴하고 더 많은 사용자 지정 기능을 제공한다. 호스트 기반 웹방화벽의 단점은 로컬 서버 자원의 소모, 구현 복잡성, 유지 보수 비용이다. 일반적으로 이러한 구성 요소는 엔지니어링 시간이 필요하며 비용이 많이 들 수 있다. 클라우드 기반 웹방화벽은 매우 쉽게 구현할 수 있는 합리적인 가격을 제공한다. 클라우드 기반 웹방화벽은 일반적으로 전송량을 리 디렉션 하기 위해 DNS에서 변경하는 것만큼이나 간단한 턴키 설치를 제공한다. 또 클라우드 기반 웹방화벽은 사용자가 서비스로서의 보안에 대해 매월 또는 매년 비용을 지불하기 때문에 초기 비용이 최소화된다. 클라우드 기반 웹방화벽은 최종 사용자의 추가 작업이나 비용 없이 최신 위협을 방어하기 위해 지속해서 업데이트되는 솔루션을 제공할 수 있다. 클라우드 기반 웹방화벽의 단점은 사용자가 책임을 제삼자에게 떠넘긴다는 점이다. 그러므로 웹방화벽의 일부 기능은 블랙박스가 될 수 있다. 리버스 프록시형은 하드웨어형 웹방호벽을 이용하여 웹서버를 보호하지만 개별적인 장비의 설치가 불필요하며 적용이 간단한 솔루션이다.[6][7]
고려 사항[편집]
도입[편집]
- 웹방화벽 보호 대상 서버 선정 : 고객사의 웹 보안을 컨설팅하다 보면 모든 웹 서버에 보안 서비스를 걸기를 원한다. 그중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포탈 서버까지 다양하다. 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹방화벽 도입 사업을 진행하는 것이다. 보안팀에서 웹방화벽을 도입하려 한다고 웹 서비스 담당자들이 전부 선호하는 것은 아니다. 침해사고를 경험한 담당자는 선호할 것이고 그렇지 않으면 해야 할 일이 많아지고 귀찮다며 선호하지 않을 것이다.
- 웹방화벽 트래픽 용량 산정 : 보호 대상 웹 서버를 선정했다면 해당 웹 서버의 트래픽 용량을 산정해야 하는데 여기서 문제가 발생한다. 용량을 어떻게 선정할 것인가에 대해 네트워크 관점으로 접근해버리면 단순 전송량의 대역폭만을 고려하게 되는데 웹에서의 부하는 네트워크에서 접근하는 것과는 조금 다른 웹 서비스 관점에서 접근하는 것이 옳다. 얼마나 많은 대역폭을 점유하느냐는 절대적인 수치에서 보면 중요하지 않다. 1Gbps 전용선 라인을 쓰더라도 웹 서비스의 접속량이 미미하다면 작은 사양의 웹방화벽 장비로도 충분할 것이다. 반면에 대역폭은 2~300Mbps 남짓 되더라도 엄청나게 많은 사용자가 동일 시간에 접속하는 서비스라고 하면 웹에서 보면 엄청난 처리 과정이 될 수 있다. 웹방화벽을 도입하기 전에 웹 서비스에 시간당 최대 부하율을 알고서 용량을 산정한다면 장비를 공급하는 업체에서도 적정 용량을 산정하기가 쉽다.
- 웹방화벽 설치 구간 선정 : 보호 대상 웹 서버도 선정하였고 해당 웹 서버의 트래픽에 따른 웹방화벽 용량도 산정하였다면 웹방화벽의 설치구간을 정해야 한다. 초기 웹방화벽은 웹 서버 하나를 막기에도 역부족일 정도로 성능이 부족했지만, 현재는 여러 벤더의 경쟁과 하드웨어의 발전으로 웹방화벽 하나가 적게는 몇 개, 많게는 백여 대 정도의 웹 서버까지 보호 할 수 있게 되었다. 그래서 웹방화벽 설치구간이 좀 더 다양해지게 되었다. 웹방화벽을 설치하는 데에는 크게 호스트 방식, 리버스 프락시 방식, 인-라인 방식으로 나뉜다. 최근에는 편리성 때문에 인-라인 방식을 선호한다. 각 기관의 예산이나 보안정책에 따라 단수 웹방화벽을 도입할 것인가 이중화를 위해 복수의 웹방화벽을 구축할 것인지 정해진다. 단수이든 복수이든 웹방화벽은 웹 서버 바로 앞에 설치되는 것이 가장 좋다. 다른 구간의 서비스 이슈에 영향을 최소화하고 장애 포인트를 줄여 웹방화벽 운영 담당자에게 여러 가지 스트레스 상황을 줄여줄 수 있다. 그러나 웹 서버가 여러 구간에 분산 설치되어 있다고 하면 이것도 쉽지 않은 선택이다. 단수 웹방화벽은 DMZ 구간과 같이 웹방화벽 하나가 모인 구간에 웹방화벽을 설치하고 하단에 L2 스위치를 추가하여 웹 서버 이외의 서비스에 대한 영향을 최소화하는 것이 최선의 선택이라 본다. 복수 웹방화벽은 이중화 방식에 따라 액티브-액티브(Active-Active)/액티브-스탠바이(Active-Standby)로 달라진다. 최근에는 몇몇 선두 업체들을 중심으로 이중화된 장비 간 정책 동기화와 세션 동기화가 완성되어 장비 간 Async Path(Request와 Response가 다른 경로를 경유)도 지원하고 있어 L4 스위치 없이 액티브-액티브 구간에 설치가 가능해졌다. 이런 장비를 도입한다면 네트워크 앞 단의 백본 망에 설치가 쉽다.[1]
구축[편집]
- 장애 상황 발생 시 : 웹방화벽을 소프트웨어 방식이 아닌 네트워크 구간에 설치 시 장애에 대한 다양한 대비책을 세워야 한다. 초기 하드웨어 웹방화벽은 리버스 프락시 형태로 설치되었고 이때는 L4에서 웹방화벽의 서비스 포트를 자체 검사(Health check) 하여 장애 상황이라 판단되면 바로 웹 서버로 넘길 수 있도록 하였다. 최근에는 인-라인 형태로 설정되기 때문에 장비 자체에 하드웨어 바이패스 모듈이 설치되고, 내부에는 소프트 바이패스 기능을 넣어 웹방화벽의 내부 기능에 문제가 생겨도 바이패스될 수 있도록 하고 있다.
- 탐지(모니터링)/차단 일정 수립 : 웹방화벽은 탐지 기간을 갖는다. 포지티브 정책을 만들고 그에 따른 긍정 오류에 대한 예외조치를 하기 위해서다. 가장 이상적인 것이 대부분의 벤더가 지원하는 자동학습이나 실 사이트 환경에서 쓰기가 힘든 부분이 많다. 지속적 해서 변하는 사이트를 학습하기란 이론적으로 불가능하고 정적인 사이트라 하더라도 학습한 결과에 대해 다시 보안담당자가 점검해야 하는 번거로움이 발생한다. 이에 포지티브 정책을 수동으로 설정하는 것이 현실적이다. 그리고 보안정책을 건 상태에서 혹시 모를 장애 상황이나 긍정 오류들을 예외 처리하여 실 보안 서비스(차단)에 들어가서 정상적인 업무 프로세스가 차단되는 것을 미연에 방지하는 과정이다.
- 웹앱에 맞는 보안정책 설정 및 기존 취약점 보안 권고 : 탐지 기간을 갖고 예외처리를 진행하다 보면 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅하면서 이른 시일 안에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.[1]
운영[편집]
- 웹방화벽에 대한 보안 담당자의 이해 : 웹방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 애플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 발생한다. 가장 좋은 상황은 동일 부서에서 웹 서비스와 보안 관리를 같이 운영할 때이다. 그러나 이것이 여의치 않거나 웹 서비스와 보안부서가 분리된 기관이라면 트러블은 각오해야 해야 한다. 웹 서비스 운영팀에서는 무조건 서비스를 오픈하라고 요청하고 보안 팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응 방법을 찾은 후 웹 서비스를 오픈하려고 하기 때문이다. 이는 두 부서 간에 사전조율 후 웹방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서 간의 싸움으로 번지는 사태를 예방 할 수 있다.
- 새로운 보안 문제에 대한 웹방화벽 패치 : 보안 컨설팅을 하면서 생각하는 주 적은 해커이다. 또한 그들은 가장 고마운 친구이기도 하다. 그들은 매번 새로운 공격기법을 만들어 보안 컨설턴트들을 긴장하게 만들고 보안 엔지니어가 사회에서 꼭 필요한 사람이라는 걸 알게 해준다. 따라서 새로운 공격기법이 나올 때마다 간단하게는 룰셋을 업데이트하거나 새로운 공격 패러다임이 나오게 되면 웹방화벽의 일부 모듈을 패치를 해야 하는 상황이 발생하기도 한다. 보안 담당자는 웹방화벽 벤더의 패치를 잘 이해하고 수행해야 한다.
- 추가되는 웹앱에 맞는 보안정책 설정 : 침해사고는 기존에 잘 정돈된 애플리케이션보다는 새로 개편되거나 추가되는 웹 페이지들에서 발생한다. 웹방화벽도 다르지 않다. 새로 추가되는 애플리케이션에 대한 보안정책을 잘 세우지 않으면 지금까지 잘 운영해 왔던 공이 허수로 돌아가는 불상사가 생길 수 있음으로 새로 개설되어 추가되는 사이트에 대해서도 좀 더 철저한 분석을 통해 잘 정의된 보안 정책을 설정할 필요가 있다.
- 침해 사고 발생 시 대응 : 아무리 잘 구축된 보안장비와 잘 훈련된 보안 엔지니어가 있다고 해도 침해사고에서 벗어날 수는 없다. 먼저 사이트가 변조되던가 하는 공격의 흔적이 있다면 계약된 웹보안 업체에 알려 추가 공격에 대비하고 해당 공격을 분석하여 새로운 보안정책을 세워야 할 것이다. 침해 사고 시 당황하지 않고 절차에 의해 분석과 대응을 한다면 반복되는 침해사고를 막을 수 있고 경영진의 문책을 조금이라도 약화할 수 있을 것이다.[1]
전망[편집]
국내 웹방화벽 시장은 2000년 이후 점차 웹서비스 활용도가 높아지며 이와 관련된 보안이 필요하다는 인식이 생기면서 형성되기 시작하였다. 초기에 ㈜파이오링크 등에서 관련 제품이 출시되어 대기업 중심으로 웹방화벽이 도입되었다. 2007년경 국내 시장은 100억 원 정도에 이르렀으며, 이후 2008년에 조달 품목에 웹방화벽이 포함되어 컴플라이언스 대응 방안으로 주목받으면서 급성장을 이루게 된다. 생소한 이름과는 달리 국내 시장에서는 15년가량의 역사를 가진 제품이다. 그러나 대기업과 공공기관 위주로 컴플라이언스 대응을 위해 도입된 웹방화벽은 다른 분야로 영역을 확대하지 못하였으며, 긍정 오류, 미탐 등 성능 문제가 지속해서 제기되면서 시장은 침체기에 접어들었다. 실제로 업계 관계자들이 '시장 초기 웹방화벽 장비는 컴플라이언스 때문에 도입했지만, 성능 등의 문제로 웹 서비스에 상시 적용하지 않는 경우가 많았다'는 평을 내렸다. 그 외에 비싼 제품 가격, 전문가 부족 등도 문제점으로 지적되었다. 그에 따라 과거의 웹방화벽은 잦은 긍정 오류와 장애, 운영의 복잡성 등이 문제로 제기됐으며 미러링 모드로 구성해 웹 트래픽을 모니터링하다 사고 발생 시에만 분석하는 제한적인 용도로 사용하는 경우가 많았다. 그러다 2015년부터 시장에 변화가 나타나기 시작한다. 웹 공격, 개인정보 유출 사고가 점점 늘어나고, 개인정보 유출 시 막대한 과징금 또는 대규모 소송에 휘말릴 수 있다는 점이 부각되면서 웹방화벽에 대한 수요가 늘기 시작한 것이다. 더불어 머신러닝 등 새로운 기술이 접목돼 성능상의 이슈를 보완한 차세대 웹방화벽과, 클라우드 환경에서 사용할 수 있는 서비스형 보안(SECaaS) 형태의 솔루션이 등장하면서 시장이 확대되었다.
초기와는 다르게 2017년에 한국인터넷진흥원(KISA)에서 조사한 결과, 웹방화벽의 업종별 매출 비중은 일반기업이 49%로 가장 큰 비중을 보였고, 공공(33%), 금융(18%) 분야가 그 뒤를 이었다. 국내 대표적인 웹방화벽 공급업체는 펜타시큐리티시스템㈜, ㈜모니터랩, ㈜파이오링크 등이 있으며, 국내 시장에 들어온 글로벌 기업으로는 F5 네트웍스(F5 Networks), 포티넷(Fortinet), 임퍼바(Imperva), 아카마이(Akamai), 라임라이트네트웍스(Limelight Networks) 등이 있다. 국내 시장에서는 국내 기업이 시장을 장악하고 있는 편인데, 업계 관계자들의 말을 종합하면 국내 기업의 점유율은 약 90%로 추정된다. 이와 같이 국산 솔루션의 점유율이 높은 이유는 사용 환경에 맞춘 커스터마이징을 지원하고, 국내 기업에 맞는 보고 기능을 제공하기 때문이라고 추측된다. 프로스트&설리번에서 2015년에 발표한 아시아 태평양의 웹방화벽 시장에 관한 자료에서 국내 기업 중 펜타시큐리티㈜가 유일하게 마이크로소프트와 성장률이 우수한 업체로 등재되었다. 또한 가트너(Gartner)가 몇몇 특정한 기술 산업에 대해 1-2년마다 새롭게 갱신하는 매직 쿼드런트 보고서 2017에 따르면, 웹방화벽의 리더 업체로는 임퍼바, F5 네트웍스, 아카마이가 있으며, 국내 기업으로는 펜타시큐리티㈜가 유일하게 등재되어 있다. 시장의 성장률에 대해서는, 글로벌 시장의 연평균 성장률은 20%에 달하는 것으로 보인다. 아시아 시장은 연평균 27%로 글로벌 시장 대비 빠르게 성장하고 있으며, 그중에서도 일본 시장은 30%의 성장률을 보인다.[8]
각주[편집]
- ↑ 1.0 1.1 1.2 1.3 1.4 뉴딜코리아, 〈웹 방화벽의 개념과 원리〉, 《네이버 블로그》, 2016-05-29
- ↑ 〈WAPPLES 제품소개서〉, 《펜타시큐리티시스템㈜》, 2016
- ↑ 김덕수 펜타시큐리티시스템 CTO, 〈제대로 알고 쓰는 웹 해킹 차단 시스템〉, 《지디넷코리아》, 2014-02-26
- ↑ 우동 , 〈WAF (Web Application Firewall)〉, 《네이버 블로그》, 2016-04-10
- ↑ 글로벌호스트, 〈웹방화벽(WAF)의 역할과 숨겨져 있는 기능에 대해〉, 《티스토리》, 2017-08-22
- ↑ 〈WAF란? | 웹 애플리케이션 방화벽 설명〉, 《클라우드 플레어》
- ↑ 〈웹방화벽 쉽게 비교하기〉, 《가비아 라이브러리》
- ↑ 이진석, 〈클라우드형 웹 방화벽〉, 《티스토리》, 2020-01-15
참고자료[편집]
- 웹방화벽 위키백과 - https://ko.wikipedia.org/wiki/%EC%9B%B9%EB%B0%A9%ED%99%94%EB%B2%BD
- 〈웹방화벽 쉽게 비교하기〉, 《가비아 라이브러리》
- 〈WAF란? | 웹 애플리케이션 방화벽 설명〉, 《클라우드 플레어》
- 김덕수 펜타시큐리티시스템 CTO, 〈제대로 알고 쓰는 웹 해킹 차단 시스템〉, 《지디넷코리아》, 2014-02-26
- 〈WAPPLES 제품소개서〉, 《펜타시큐리티시스템㈜》, 2016
- 우동 , 〈WAF (Web Application Firewall)〉, 《네이버 블로그》, 2016-04-10
- 뉴딜코리아, 〈웹 방화벽의 개념과 원리〉, 《네이버 블로그》, 2016-05-29
- 글로벌호스트, 〈웹방화벽(WAF)의 역할과 숨겨져 있는 기능에 대해〉, 《티스토리》, 2017-08-22
- 이진석, 〈클라우드형 웹 방화벽〉, 《티스토리》, 2020-01-15
같이 보기[편집]
