검수요청.png검수요청.png

"웹방화벽"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
90번째 줄: 90번째 줄:
  
 
* '''탐지(모니터링)/차단 일정 수립'''
 
* '''탐지(모니터링)/차단 일정 수립'''
웹방화벽은 탐지 기간을 갖는다. 포지티브 정책을 만들고 그에 따른 오탐에 대한 예외조치를 하기 위해서다. 가장 이상적인 것이 대부분의 벤더가 지원하는 자동학습이나 실 사이트 환경에서 쓰기기 힘든 부분이 많다. 지속적으로 변하는 사이트를 학습하기란 이론적으로 불가능하고 정적인 사이트라 하더라도 학습한 결과에 대해 다시 보안담당자가 점검해야 하는 번거로움이 발생한다. 이에 포지티브 정책을 수동으로 설정하는 것이 현실적이다. 그리고 보안정책을 건 상태에서 혹시 모를 장애상황이나 오탐들을 예외 처리하여 실 보안 서비스(차단)에 들어가서 정상적인 업무 프로세스가 차단되는 것을 미연에 방지하는 과정이다.
+
:웹방화벽은 탐지 기간을 갖는다. 포지티브 정책을 만들고 그에 따른 오탐에 대한 예외조치를 하기 위해서다. 가장 이상적인 것이 대부분의 벤더가 지원하는 자동학습이나 실 사이트 환경에서 쓰기기 힘든 부분이 많다. 지속적으로 변하는 사이트를 학습하기란 이론적으로 불가능하고 정적인 사이트라 하더라도 학습한 결과에 대해 다시 보안담당자가 점검해야 하는 번거로움이 발생한다. 이에 포지티브 정책을 수동으로 설정하는 것이 현실적이다. 그리고 보안정책을 건 상태에서 혹시 모를 장애상황이나 오탐들을 예외 처리하여 실 보안 서비스(차단)에 들어가서 정상적인 업무 프로세스가 차단되는 것을 미연에 방지하는 과정이다.
  
 
* '''웹앱에 맞는 보안정책 설정 및 기존 취약점 보안 권고'''
 
* '''웹앱에 맞는 보안정책 설정 및 기존 취약점 보안 권고'''
탐지기간을 갖고 예외처리를 진행 하다 보면 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅 하면서 빠른 시간 내에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.
+
:탐지기간을 갖고 예외처리를 진행 하다 보면 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅 하면서 빠른 시간 내에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.<ref name="뉴딜코리아"></ref>
  
 
=== 운영 시 ===
 
=== 운영 시 ===
 +
* 웹방화벽에 대한 보안 담당자의 이해
 +
:웹방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 어플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 발생한다. 가장 좋은 상황은 동일 부서에서 웹 서비스와 보안관리를 같이 운영할 때 이다. 그러나 이것이 여의치 않거나 웹 서비스와 보안부서가 분리되어 있는 기관이라면 트러블은 각오해야 해야 한다. 웹 서비스 운영 팀에서는 무조건 서비스를 오픈 하라고 요청하고 보안 팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응방법을 찾은 후 웹 서비스를 오픈 하려고 하기 때문이다. 이는 두 부서간에 사전조율 후 웹방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서간의 싸움으로 번지는 사태를 예방 할 수 있다.
 +
 +
* 새로운 보안 문제에 대한 웹방화벽 패치
 +
:보안 컨설팅을 하면서 생각하는 주 적은 해커이다. 또한 그들은 가장 고마운 친구이기도 하다. 그들은 매번 새로운 공격기법을 만들어 보안 컨설턴트들을 긴장하게 만들고 보안 엔지니어가 사회에서 꼭 필요한 사람이라는걸 알게 해준다. 따라서 새로운 공격기법이 나올 때 마다 간단하게는 룰셋을 업데이트하거나 새로운 공격 패러다임이 나오게 되면 웹방화벽의 일부 모듈을 패치해야 하는 상황이 발생하기도 한다. 보안 담당자는 웹방화벽 벤더의 패치를 잘 이해하고 수행해야 한다.
 +
 +
* 추가되는 웹앱에 맞는 보안정책 설정
 +
:침해사고는 기존에 잘 정돈된 어플리케이션 보다는 새로 개편되거나 추가되는 웹 페이지들에서 발생한다. 웹방화벽도 다르지 않다. 새로 추가되는 어플리케이션에 대한 보안정책을 잘 세우지 않으면 지금까지 잘 운영해 왔던 공이 허수로 돌아가는 불상사가 생길 수 있으므로 새로 개설되어 추가되는 사이트에 대해서도 좀더 철저한 분석을 통해 잘 정의된 보안 정책을 설정할 필요가 있다.
 +
 +
* 침해 사고 발생시 대응
 +
:아무리 잘 구축된 보안장비와 잘 훈련된 보안 엔지니어가 있다고 해도 침해사고에서 자유로울 수는 없다. 먼저 사이트가 변조되던가 하는 공격의 흔적이 있다면 계약된 웹 보안 업체에 알려 추가공격에 대비하고 해당 공격을 분석하여 새로운 보안정책을 세워야 할 것이다. 침해 사고 시 당황하지 않고 절차에 의해 분석과 대응을 한다면 반복되는 침해사고를 막을 수 있고 경영진의 문책을 조금이라도 약화 시킬 수 있을 것이다.<ref name="뉴딜코리아"></ref>
  
  

2020년 8월 3일 (월) 16:36 판

웹방화벽(WAF, Web Application Firewall)은 일반적인 네트워크 방화벽(Firewall)과는 다르게 웹 애플리케이션 보안에 특화되어 개발된 제품이다. 웹방화벽의 기본 역할은 SQL Injection, Cross-Site Scripting(XSS)등과 같은 웹 공격을 탐지하고 차단하는 것인데, 직접적인 웹 공격 대응 이 외에도, 정보유출방지솔루션, 부정로그인방지솔루션, 웹사이트위변조방지솔루션 등으로 활용이 가능하다. 정보유출방지솔루션의 경우, 개인정보가 웹 게시판에 게시되거나 개인 정보가 포함된 파일 등이 웹을 통해 업로드 및 다운로드 되는 경우에 대해서 탐지하고 대응하는 것이 가능하다. 부정로그인방지솔루션의 경우, 추정 가능한 모든 경우의 수를 대입하여 웹사이트에 로그인을 시도하는 경우와 같은 비정상적인 접근에 대한 접근 제어 기능을 한다. 웹사이트위변조방지솔루션의 경우, 해커가 해킹을 한 후에 과시하는 것이 목적인 웹사이트 위변조가 발생했을 경우, 이에 대해 탐지하고 대응한다. 즉, 웹방화벽의 역할은 집(애플리케이션)을 지키는 울타리 역할이라고 볼 수 있다.[1]

개요

웹앱(Web Application)은 인터넷을 통해서 사용하는 홈페이지 대부분의 서비스를 의미한다. 웹 공격의 대부분은 웹앱을 구축할 때 생겨나는 취약점을 이용해서 웹 서버를 공격하거나 데이터베이스 내용을 악용하는 방법으로, 공격자는 HTTP 요청에 특정 공격 코드 또는 특정 웹앱만이 가지고 있는 취약점을 우회하는 코드를 삽입하여 웹앱에 전송하게 된다. 웹방화벽의 역할은 이러한 웹 서버 쪽으로 전송되는 모든 HTTP 요청 패킷을 검사하여 웹앱에 의도하지 않은 내용이 전송되지 못하게 막는 역할을 한다. 또, 웹 서버에서 통과하는 HTTP 응답 내용을 감시하여 특정 정보의 유출을 막는 역할도 한다.

패킷을 검사하는 원리는 프록시 서버의 원리에서 가져온 것이다. 프록시 서버의 역할은 클라이언트와 서버 간의 통신을 중계하고 응답하는 것이다. 웹방화벽의 원리는 웹 서버로 들어오고 나가는 모든 패킷을 프록시 서버의 원리를 적용하여 패킷의 내용을 검사하고 차단하는 것이다.[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의 요청/응답 메시지 내용을 분석, 포지티브 정책과 네거티브 정책을 혼용하여 탐지 기능을 수행한다. 요청 메시지의 가장 큰 특징은 URL 단위의 탐지 기능이다. 해당 사이트는 서비스를 제공할 URL을 포지티브 정책으로 설정하면, 등록된 URL 외의 다른 URL을 사용자가 요청할 경우 탐지하여 요청 거부 메시지를 보낸다. 이러한 경우 악의적인 사용자가 정상적인 URL 외의 다른 URL로 접근하는 것을 막을 수 있다. 네거티브 정책에서는 정상적인 URL에서 악의적인 공격 패턴 XSS,SQL Injection, OS Command Injection 등을 검출해 내는 문자열 비교 정책을 추가할 수 있다. 요청 메소드(GET, POST, OPTION)까지도 포지티브 정책에 설정할 수 있다. 특정 URL에서만 사용하는 쿠키/히든 필드나 파라미터 값들을 설정하여 정교한 탐지 기능을 제공한다. 파일 업로드 제어 기능과 파일 검사 기능을 지원한다. 사용자가 웹 서버로 업로드하는 파일에 대해 파일의 종류에 따라 업로드를 허용, 차단 여부를 지정할 수 있다. 업로드 파일의 내용을 검사하여 악의적인 공격 형태의 파일들은 파일 필터를 통해 업로드가 차단되어 웹 사이트를 악용하는 사용자로부터 안전하게 보호하는 역할을 한다.

응답 메시지의 대표적인 기능은 웹 서버의 에러 또는 오류 정보를 차단하여, 악의적인 사용자가 웹 서버에 대한 정보를 알 수 없게 하는 것이다. 요즘은 주요 정보를 차단하는데 많이 사용 되고 있다. 사용자의 주민등록번호, 휴대폰 번호, 집 주소, 이메일 주소, 카드번호 등의 개인 정보들이 다른 사용자들에게 노출 되는 것을 방지하는 것이다.부가적으로 웹 가속기능이나, SSL 가속기능, Cache 기능들을 지원한다. 웹 방화벽 탐지기술의 장점은 HTTP 프로토콜 속성값의 작은 단위까지도 정책설정이 가능하다. 웹 서비스 개발 시점에 신경쓰지 못했던 보안상의 문제점들을 보완할 수 있어 웹 서비스를 보다 안전하게 사용자들에게 제공할 수 있다.[2]

기본 보안 기능 설명
SQL Injection SQL 쿼리 삽입 공격을 모니터링 및 차단한다.
Command Injection, Command Execution 원격 커맨드 실행, 커맨드 삽입 공격을 모니터링 및 차단한다.
Cross site Scripting 웹 스크립트 삽입 공격을 모니터링 및 차단
Encoding URL 등과 같은 다른 인코딩 방식으로 우회 공격하는 것을 모니터링 및 차단한다.
Denial of service GET Flooding, Cache-Control 공격을 차단한다.
HTTP Method PUT, Delete, Trace, option, head 등을 모니터링 및 차단한다.
Probing 알려진 스캔성 공격들을 모니터링 및 차단한다.
Path Traversal 디렉터리 접근 공격을 모니터링 및 차단한다.
File Upload 확장자 기반 업로드를 차단한다.
관리자 URL 접근 제어 관리자 페이지와 같은 중요 페이지에 대한 접근 가능 IP 및 대역을 설정한다.
업무 시간 지정 업무 시간 외 접근을 차단한다.
휴일 지정 휴일로 지정한 일에는 접근을 차단한다.
국가별 차단 관리자가 지정한 국가 IP 접속을 차단한다.
[4]

종류

웹방화벽은 세 가지 방법 중 하나로 구현될 수 있다.

  • 네트워크 기반 웹방화벽은 일반적으로 하드웨어에 기반한다. 네트워크 기반 웹방화벽은 로컬에 설치되기 때문에 대기 시간을 최소화하지만, 가장 비용이 많이 드는 옵션이며 실제 장비를 보관하고 유지 관리해야 한다.[5]
  • 호스트 기반 웹방화벽은 애플리케이션의 소프트웨어에 완전히 통합될 수 있다. 이 솔루션은 네트워크 기반 웹방화벽보다 비용이 저렴하고 더 많은 사용자 지정 기능을 제공한다. 호스트 기반 웹방화벽의 단점은 로컬 서버 리소스의 소모, 구현 복잡성, 유지 보수 비용이다. 일반적으로 이러한 구성 요소는 엔지니어링 시간을 필요로 하며 비용이 많이 들 수 있다.[5]
  • 클라우드 기반 웹방화벽은 매우 쉽게 구현할 수 있는 합리적인 가격을 제공한다. 클라우드 기반 웹방화벽은 일반적으로 트래픽을 리디렉션하기 위해 DNS에서 변경하는 것만큼이나 간단한 턴키 설치를 제공한다. 또 클라우드 기반 웹방화벽은 사용자가 서비스로서의 보안에 대해 매월 또는 매년 비용을 지불하기 때문에 초기 비용이 최소화된다. 클라우드 기반 웹방화벽은 최종 사용자의 추가 작업이나 비용 없이 최신 위협을 방어하기 위해 지속적으로 업데이트되는 솔루션을 제공할 수 있다. 클라우드 기반 웹방화벽의 단점은 사용자가 책임을 제3자에게 떠넘긴다는 점이다. 그러므로 웹방화벽의 일부 기능은 블랙박스가 될 수 있다.[5]

필요성

스마트폰, 태블릿 PC등의 사용이 급증하면서 웹 대중화 시대가 오게 되었다. 그러면서 웹 위협에 대한 노출 가능성도 증가하였지만 많은 사용자들이 보안의 필요성에 대해서 인식하지 못하고 있다. 4차 산업혁명의 기술 중 하나인 사물인터넷(IOT, Internet Of Things)은 각종 사물에 센서와 통신 기능을 내장하여 인터넷에 연결하는 기술이다. 사물인터넷에는 모든 사물이 웹 해킹의 대상이 될 수도 있어 사물인터넷을 위한 웹보안이 반드시 필요하다. 웹 사용률 증가와 더불어 웹을 통해 이루어지는 통신을 암호화하여 보호하는 SSL 사용률이 증가하고 있다. 하지만 SSL 트래픽을 이용하여 웹 공격을 하는 것 또한 가능하기 때문에 임시방편에 불과하다. 대량의 개인 정보 유출을 했던 사이버 공격들도 모두 웹을 통한 공격이었다. 금융감독원에서 대량 개인정보 유출 사고 관련하여 동일 사건 재발생 방지를 위한 목적으로 2014년 1월 27일 [고객 정보 보호 실태 점검 요청] 공문을 시행, 해당 자료에서 웹방화벽을 언급하며 침입 차단 시스템으로서의 운용 필요성을 언급하고 있다.[6]

고려 사항

도입 시

  • 웹방화벽 보호 대상 서버 선정
고객사의 웹 보안을 컨설팅 하다 보면 모든 웹 서버에 보안 서비스를 걸기를 원한다. 그 중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포탈 서버까지 다양하다. 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹 방화벽 도입 사업을 진행하는 것이다. 보안팀에서 웹방화벽을 도입하려 한다고 웹 서비스 담당자들이 전부 선호하는 것은 아니다. 침해사고를 경험한 담당자는 선호할 것이고 그렇지 않으면 해야할 일이 많아지고 귀찮다며 선호하지 않을 것이다.
  • 웹방화벽 트래픽 용량 산정
보호 대상 웹 서버를 선정했다면 해당 웹 서버의 트래픽 용량을 산정해야햐는데 여기서 문제가 발생한다. 용량을 어떻게 선정할 것인가에 대해 네트워크 관점으로 접근해버리면 단순 트레픽의 대역폭 만을 고려하게 되는데 웹에서의 부하는 네트워크에서 접근하는 것과는 조금 다른 웹 서비스 관점에서 접근하는 것이 옳다. 얼마나 많은 대역폭을 점유하느냐는 절대적인 수치에서 보면 중요하지 않다. 1Gbps 전용선 라인을 쓰더라도 웹 서비스의 접속량이 미미하다면 작은 사양의 웹 방화벽 장비로도 충분할 것이다. 반면에 대역폭은 2~300Mbps 남짓 되더라도 엄청나게 많은 사용자들이 동일시간에 접속하는 서비스라고 하면 웹에서 보면 엄청난 처리 과정이 될 수 있다. 웹 방화벽을 도입하기 전에 웹 서비스에 시간당 최대 부하율을 알고서 용량을 산정한다면 장비를 공급하는 업체에서도 적정 용량을 산정하기가 쉽다.
  • 웹방화벽 설치 구간 선정
보호대상 웹 서버도 선정하였고 해당 웹 서버의 트래픽에 의거한 웹 방화벽 용량도 산정하였다면 웹 방화벽의 설치구간을 정해야 된다. 초기 웹방화벽은 웹 서버 하나를 막기에도 역부족일 정도로 성능이 부족했지만, 현재는 여러 벤더의 경쟁과 하드웨어의 발전으로 웹방화벽 하나가 적게는 몇 개, 많게는 백 여대 정도의 웹 서버까지 보호 할 수 있게 되었다. 그래서 웹 방화벽 설치구간이 좀더 다양해지게 되었다. 웹방화벽을 설치하는 데에는 크게 호스트 방식, 리버스 프록시 방식, 인-라인 방식으로 나뉜다. 최근에는 편리성 때문에 인-라인 방식을 선호한다. 각 기관의 예산이나 보안정책에 따라 단수 웹방화벽을 도입할 것인가 이중화를 위해 복수의 웹방화벽을 구축할 것인지 정해진다. 단수이든 복수이든 웹방화벽은 웹 서버 바로 앞에 설치되는 것이 가장 좋다. 다른 구간의 서비스 이슈에 영향을 최소화 하고 장애 포인트를 줄여 웹 방화벽 운영 담당자로 하여금 여러 가지 스트레스 상황을 줄여줄 수 있다. 그러나 웹 서버가 여러 구간에 분산 설치되어 있다고 하면 이것도 쉽지 않은 선택이다. 단수 웹방화벽은 DMZ 구간과 같이 웹방화벽 하나가 모인 구간에 웹방화벽을 설치하고 하단에 L2 스위치를 추가하여 웹 서버 이외의 서비스에 대한 영향을 최소화 하는 것이 최선의 선택이라 본다. 복수 웹방화벽은 이중화 방식에 따라 Active-Active / Active-Standby로 달라진다. 최근에는 몇몇 선두 업체들을 중심으로 이중화된 장비간 정책동기화와 세션동기화가 완성되어 장비간 Async Path(Request와 Response가 다른 경로를 경유)도 지원하고 있어 L4 스위치 없이 Active-Active 구간에 설치가 가능해졌다. 이런 장비를 도입한다면 네트워크 앞 단의 Back-bone 망에 설치가 용이 하다.[2]

구축 시

  • 장애상황 발생 시
웹방화벽을 소프트웨어 방식이 아닌 네트워크 구간에 설치 시 장애에 대한 다양한 대비책을 세워야 한다. 초기 하드웨어 웹방화벽은 리버스 프록시 형태로 설치되었고 이때는 L4에서 웹 방화벽의 서비스 포트를 Health check 하여 장애상황이라 판단되면 바로 웹 서버로 넘길 수 있도록 하였다. 최근에는 인-라인 형태로 설정되기 때문에 장비자체에 하드웨어 바이패스 모듈이 설치되고, 내부에는 소프트 바이패스 기능을 넣어 웹방화벽의 내부 기능에 문제가 생겨도 바이패스 될 수 있도록 하고 있다.
  • 탐지(모니터링)/차단 일정 수립
웹방화벽은 탐지 기간을 갖는다. 포지티브 정책을 만들고 그에 따른 오탐에 대한 예외조치를 하기 위해서다. 가장 이상적인 것이 대부분의 벤더가 지원하는 자동학습이나 실 사이트 환경에서 쓰기기 힘든 부분이 많다. 지속적으로 변하는 사이트를 학습하기란 이론적으로 불가능하고 정적인 사이트라 하더라도 학습한 결과에 대해 다시 보안담당자가 점검해야 하는 번거로움이 발생한다. 이에 포지티브 정책을 수동으로 설정하는 것이 현실적이다. 그리고 보안정책을 건 상태에서 혹시 모를 장애상황이나 오탐들을 예외 처리하여 실 보안 서비스(차단)에 들어가서 정상적인 업무 프로세스가 차단되는 것을 미연에 방지하는 과정이다.
  • 웹앱에 맞는 보안정책 설정 및 기존 취약점 보안 권고
탐지기간을 갖고 예외처리를 진행 하다 보면 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅 하면서 빠른 시간 내에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.[2]

운영 시

  • 웹방화벽에 대한 보안 담당자의 이해
웹방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 어플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 발생한다. 가장 좋은 상황은 동일 부서에서 웹 서비스와 보안관리를 같이 운영할 때 이다. 그러나 이것이 여의치 않거나 웹 서비스와 보안부서가 분리되어 있는 기관이라면 트러블은 각오해야 해야 한다. 웹 서비스 운영 팀에서는 무조건 서비스를 오픈 하라고 요청하고 보안 팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응방법을 찾은 후 웹 서비스를 오픈 하려고 하기 때문이다. 이는 두 부서간에 사전조율 후 웹방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서간의 싸움으로 번지는 사태를 예방 할 수 있다.
  • 새로운 보안 문제에 대한 웹방화벽 패치
보안 컨설팅을 하면서 생각하는 주 적은 해커이다. 또한 그들은 가장 고마운 친구이기도 하다. 그들은 매번 새로운 공격기법을 만들어 보안 컨설턴트들을 긴장하게 만들고 보안 엔지니어가 사회에서 꼭 필요한 사람이라는걸 알게 해준다. 따라서 새로운 공격기법이 나올 때 마다 간단하게는 룰셋을 업데이트하거나 새로운 공격 패러다임이 나오게 되면 웹방화벽의 일부 모듈을 패치해야 하는 상황이 발생하기도 한다. 보안 담당자는 웹방화벽 벤더의 패치를 잘 이해하고 수행해야 한다.
  • 추가되는 웹앱에 맞는 보안정책 설정
침해사고는 기존에 잘 정돈된 어플리케이션 보다는 새로 개편되거나 추가되는 웹 페이지들에서 발생한다. 웹방화벽도 다르지 않다. 새로 추가되는 어플리케이션에 대한 보안정책을 잘 세우지 않으면 지금까지 잘 운영해 왔던 공이 허수로 돌아가는 불상사가 생길 수 있으므로 새로 개설되어 추가되는 사이트에 대해서도 좀더 철저한 분석을 통해 잘 정의된 보안 정책을 설정할 필요가 있다.
  • 침해 사고 발생시 대응
아무리 잘 구축된 보안장비와 잘 훈련된 보안 엔지니어가 있다고 해도 침해사고에서 자유로울 수는 없다. 먼저 사이트가 변조되던가 하는 공격의 흔적이 있다면 계약된 웹 보안 업체에 알려 추가공격에 대비하고 해당 공격을 분석하여 새로운 보안정책을 세워야 할 것이다. 침해 사고 시 당황하지 않고 절차에 의해 분석과 대응을 한다면 반복되는 침해사고를 막을 수 있고 경영진의 문책을 조금이라도 약화 시킬 수 있을 것이다.[2]


각주

  1. 웹방화벽 위키백과 - https://ko.wikipedia.org/wiki/%EC%9B%B9%EB%B0%A9%ED%99%94%EB%B2%BD
  2. 2.0 2.1 2.2 2.3 2.4 뉴딜코리아, 〈웹 방화벽의 개념과 원리〉, 《네이버 블로그》, 2016-05-29
  3. 김덕수 펜타시큐리티시스템 CTO, 〈제대로 알고 쓰는 웹 해킹 차단 시스템〉, 《지디넷코리아》, 2014-02-26
  4. 글로벌호스트, 〈웹방화벽(WAF)의 역할과 숨겨져 있는 기능에 대해〉, 《티스토리》, 2017-08-22
  5. 5.0 5.1 5.2 WAF란? | 웹 애플리케이션 방화벽 설명 클라우드 플레어 - https://www.cloudflare.com/ko-kr/learning/ddos/glossary/web-application-firewall-waf/
  6. 펜타시큐리티시스템㈜, 〈WAPPLES 제품소개서〉, 《펜타시큐리티시스템㈜》, 2016

참고 자료

같이 보기


  검수요청.png검수요청.png 이 웹방화벽 문서는 하드웨어에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.