웹방화벽 편집하기

=== 고려 사항 ===

=== 고려 사항 ===

* '''웹방화벽 보호 대상 서버 선정''' : 고객사의 웹 보안을 컨설팅하다 보면 모든 웹 서버에 보안 서비스를 걸기를 원한다. 그중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포탈 서버까지 다양하다. 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹방화벽 도입 사업을 진행하는 것이다. 보안팀에서 웹방화벽을 도입하려 한다고 웹 서비스 담당자들이 전부 선호하는 것은 아니다. 침해사고를 경험한 담당자는 선호할 것이고 그렇지 않으면 해야 할 일이 많아지고 귀찮다며 선호하지 않을 것이다.

* '''웹방화벽 보호 대상 서버 선정''' : 고객사의 웹 보안을 컨설팅하다 보면 모든 웹 서버에 보안 서비스를 걸기를 원한다. 그중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포탈 서버까지 다양하다. 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹방화벽 도입 사업을 진행하는 것이다. 보안팀에서 웹방화벽을 도입하려 한다고 웹 서비스 담당자들이 전부 선호하는 것은 아니다. 침해사고를 경험한 담당자는 선호할 것이고 그렇지 않으면 해야 할 일이 많아지고 귀찮다며 선호하지 않을 것이다.

* '''웹방화벽 설치 구간 선정''' : 보호 대상 웹 서버도 선정하였고 해당 웹 서버의 트래픽에 따른 웹방화벽 용량도 산정하였다면 웹방화벽의 설치구간을 정해야 한다. 초기 웹방화벽은 웹 서버 하나를 막기에도 역부족일 정도로 성능이 부족했지만, 현재는 여러 벤더의 경쟁과 하드웨어의 발전으로 웹방화벽 하나가 적게는 몇 개, 많게는 백여 대 정도의 웹 서버까지 보호 할 수 있게 되었다. 그래서 웹방화벽 설치구간이 좀 더 다양해지게 되었다. 웹방화벽을 설치하는 데에는 크게 호스트 방식, 리버스 프락시 방식, 인-라인 방식으로 나뉜다. 최근에는 편리성 때문에 인-라인 방식을 선호한다. 각 기관의 예산이나 보안정책에 따라 단수 웹방화벽을 도입할 것인가 이중화를 위해 복수의 웹방화벽을 구축할 것인지 정해진다. 단수이든 복수이든 웹방화벽은 웹 서버 바로 앞에 설치되는 것이 가장 좋다. 다른 구간의 서비스 이슈에 영향을 최소화하고 장애 포인트를 줄여 웹방화벽 운영 담당자에게 여러 가지 스트레스 상황을 줄여줄 수 있다. 그러나 웹 서버가 여러 구간에 분산 설치되어 있다고 하면 이것도 쉽지 않은 선택이다. 단수 웹방화벽은 DMZ 구간과 같이 웹방화벽 하나가 모인 구간에 웹방화벽을 설치하고 하단에 L2 스위치를 추가하여 웹 서버 이외의 서비스에 대한 영향을 최소화하는 것이 최선의 선택이라 본다. 복수 웹방화벽은 이중화 방식에 따라 액티브-액티브(Active-Active)/액티브-스탠바이(Active-Standby)로 달라진다. 최근에는 몇몇 선두 업체들을 중심으로 이중화된 장비 간 정책 동기화와 세션 동기화가 완성되어 장비 간 Async Path(Request와 Response가 다른 경로를 경유)도 지원하고 있어 L4 스위치 없이 액티브-액티브 구간에 설치가 가능해졌다. 이런 장비를 도입한다면 네트워크 앞 단의 [[백본]] 망에 설치가 쉽다.<ref name="뉴딜코리아"></ref>

* '''웹방화벽 설치 구간 선정''' : 보호 대상 웹 서버도 선정하였고 해당 웹 서버의 트래픽에 따른 웹방화벽 용량도 산정하였다면 웹방화벽의 설치구간을 정해야 한다. 초기 웹방화벽은 웹 서버 하나를 막기에도 역부족일 정도로 성능이 부족했지만, 현재는 여러 벤더의 경쟁과 하드웨어의 발전으로 웹방화벽 하나가 적게는 몇 개, 많게는 백여 대 정도의 웹 서버까지 보호 할 수 있게 되었다. 그래서 웹방화벽 설치구간이 좀 더 다양해지게 되었다. 웹방화벽을 설치하는 데에는 크게 호스트 방식, 리버스 프락시 방식, 인-라인 방식으로 나뉜다. 최근에는 편리성 때문에 인-라인 방식을 선호한다. 각 기관의 예산이나 보안정책에 따라 단수 웹방화벽을 도입할 것인가 이중화를 위해 복수의 웹방화벽을 구축할 것인지 정해진다. 단수이든 복수이든 웹방화벽은 웹 서버 바로 앞에 설치되는 것이 가장 좋다. 다른 구간의 서비스 이슈에 영향을 최소화하고 장애 포인트를 줄여 웹방화벽 운영 담당자에게 여러 가지 스트레스 상황을 줄여줄 수 있다. 그러나 웹 서버가 여러 구간에 분산 설치되어 있다고 하면 이것도 쉽지 않은 선택이다. 단수 웹방화벽은 DMZ 구간과 같이 웹방화벽 하나가 모인 구간에 웹방화벽을 설치하고 하단에 L2 스위치를 추가하여 웹 서버 이외의 서비스에 대한 영향을 최소화하는 것이 최선의 선택이라 본다. 복수 웹방화벽은 이중화 방식에 따라 액티브-액티브(Active-Active)/액티브-스탠바이(Active-Standby)로 달라진다. 최근에는 몇몇 선두 업체들을 중심으로 이중화된 장비 간 정책 동기화와 세션 동기화가 완성되어 장비 간 Async Path(Request와 Response가 다른 경로를 경유)도 지원하고 있어 L4 스위치 없이 액티브-액티브 구간에 설치가 가능해졌다. 이런 장비를 도입한다면 네트워크 앞 단의 [[백본]] 망에 설치가 쉽다.<ref name="뉴딜코리아"></ref>

* '''장애 상황 발생 시''' : 웹방화벽을 소프트웨어 방식이 아닌 네트워크 구간에 설치 시 장애에 대한 다양한 대비책을 세워야 한다. 초기 하드웨어 웹방화벽은 리버스 프락시 형태로 설치되었고 이때는 L4에서 웹방화벽의 서비스 포트를 자체 검사(Health check) 하여 장애 상황이라 판단되면 바로 웹 서버로 넘길 수 있도록 하였다. 최근에는 인-라인 형태로 설정되기 때문에 장비 자체에 하드웨어 바이패스 모듈이 설치되고, 내부에는 소프트 바이패스 기능을 넣어 웹방화벽의 내부 기능에 문제가 생겨도 바이패스될 수 있도록 하고 있다.

* '''장애 상황 발생 시''' : 웹방화벽을 소프트웨어 방식이 아닌 네트워크 구간에 설치 시 장애에 대한 다양한 대비책을 세워야 한다. 초기 하드웨어 웹방화벽은 리버스 프락시 형태로 설치되었고 이때는 L4에서 웹방화벽의 서비스 포트를 자체 검사(Health check) 하여 장애 상황이라 판단되면 바로 웹 서버로 넘길 수 있도록 하였다. 최근에는 인-라인 형태로 설정되기 때문에 장비 자체에 하드웨어 바이패스 모듈이 설치되고, 내부에는 소프트 바이패스 기능을 넣어 웹방화벽의 내부 기능에 문제가 생겨도 바이패스될 수 있도록 하고 있다.

* '''웹앱에 맞는 보안정책 설정 및 기존 취약점 보안 권고''' : 탐지 기간을 갖고 예외처리를 진행하다 보면 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅하면서 이른 시일 안에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.<ref name="뉴딜코리아"></ref>

* '''웹앱에 맞는 보안정책 설정 및 기존 취약점 보안 권고''' : 탐지 기간을 갖고 예외처리를 진행하다 보면 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅하면서 이른 시일 안에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.<ref name="뉴딜코리아"></ref>

* '''웹방화벽에 대한 보안 담당자의 이해''' : 웹방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 애플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 발생한다. 가장 좋은 상황은 동일 부서에서 웹 서비스와 보안 관리를 같이 운영할 때이다. 그러나 이것이 여의치 않거나 웹 서비스와 보안부서가 분리된 기관이라면 트러블은 각오해야 해야 한다. 웹 서비스 운영팀에서는 무조건 서비스를 오픈하라고 요청하고 보안 팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응 방법을 찾은 후 웹 서비스를 오픈하려고 하기 때문이다. 이는 두 부서 간에 사전조율 후 웹방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서 간의 싸움으로 번지는 사태를 예방 할 수 있다.

* '''웹방화벽에 대한 보안 담당자의 이해''' : 웹방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 애플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 발생한다. 가장 좋은 상황은 동일 부서에서 웹 서비스와 보안 관리를 같이 운영할 때이다. 그러나 이것이 여의치 않거나 웹 서비스와 보안부서가 분리된 기관이라면 트러블은 각오해야 해야 한다. 웹 서비스 운영팀에서는 무조건 서비스를 오픈하라고 요청하고 보안 팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응 방법을 찾은 후 웹 서비스를 오픈하려고 하기 때문이다. 이는 두 부서 간에 사전조율 후 웹방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서 간의 싸움으로 번지는 사태를 예방 할 수 있다.