|
기업 네트워크의 보안 모델 1980년대 이전 까지만 해도 컴퓨터 보안의 최대 문제는 어떻게 하면 안전한 OS를 만들고, 사용자의 인증 및 시스템 자원에 대한 접근 제어를 어떻게 할 것인가에 초점이 맞춰져 있다. 이 시기에 만들어졌던 보안 모델과 표준들도 대부분 이런 것들을 다루고 있는데, 미국에서 만든 TCSEC(Trusted Computer System Evaluation Criteria)의 등급 체계나 유럽의 ITSEC(Information Technology Security Evaluation Criteria)등이 그것이다. 그런데, 1990년대에 들어오면서 실험적 혹은 연구 목적으로 사용되던 인터넷이 급속하게 상용화되면서 보안의 초점이 예전보다 훨씬 광범위해졌다. 이런한 현상은 CERT 등에서 내놓고 있는 보안 취약성의 대부분이 원격 공격에 의한 것임을 통해 알 수 있다. 그렇다면 기업에서 컴퓨터 및 네트워크 시설에 대한 모델을 어떻게 세우고 어떤 곳을 관리해야 보안을 실현할 수 있는지에 대해서 살펴보자.
기업 네트워크 보안 모델 인터넷의 근간을 이루고 있는 TCP/IP가 비록 1980년에 탄생했지만, 국내에서는 1989년에 하나망이 도입되면서 대학과 연구기관 등에서 사용되기 시작했다. 이후 기업에서도 본격적으로 사용되기 시작한 시점은 1993년 정도이고, 1994년에 이르러서야 데이콤이나 아이네트같은 상용 인터넷 서비스제공자들이 나타나게 되었다. 이 시기에 Checkpoint사에서 개발한 Firewall-1을 필두로 여러 방화벽제품들이 소개되었는데, 방화벽의 개념이 어느 정도 정립된 시기였으며 TCP/IP라는 인터넷의 근간을 이루는 구조에 기반하여 여러 형태의 방화벽들이 시장에 나오게 되었다.
1.1. 일반적인 네트워크 계층별 구분 모델 TCP/IP에서의 네트워크 계층별 구분은 다음의 4개의 레이어로 나눌수 있다. [그림 1]에서 보는 네개의 계층 중에 아래의 두개는 물리적 보안에 가까운 측면이 많고, 정작 주목 해야 할 곳은 위쪽의 네트워크 레이어(IP)와 트랜스포트 레이어(TCP/UDP) 이상으로, 눈에는 잘 보이지 않지만 외부에서 얼마든지 접근이 가능하고 데이터 도청도 가능한 곳이다. 네트워크 보안을 위해서는 이들 IP레이어와 TCP레이어에 보안 기능을 삽입해야 하는데, 일반적으로 IP 레이어와 TCP 레이어에서 응용 프로그램으로 올라가기 전에 IP패킷을 보고서 미리 차단하거나, 또는 응용프로그램에서 실제 프로그램이 수행되기 전에 미리 필터링 프로그램 등을 통해 한번 걸러내는 형태의 모델을 따른다.
[그림1] 네트워크 계층별 구분 모델
[표1] 방화벽의 구현 형태 및 장/ 단점
[그림 2]에서 보여주는 전형적인 방화벽의 기본 개념은 어떻게 구현하느냐에 초점이 맞춰졌고 각 구현마다 서로의 장단점이 있었기 때문에 이들은 서로 보완적인 요소로 존재하면서 기업 네트워크 전체 환경이나 트래픽의 형태에 따라 어떤 구현 모델이 적합한지에 의해 구분되었다. 하지만, 이러한 TCP/IP 계층별 구조/구현 모델은 개별적인 호스트나 게이트웨이에 대한 네트워크 기능적인 구조일뿐 전체적인 네트워크의 보안을 기술하는 모델로는 부족한 면이 많다.
[그림 2] 기본적인 게이트웨이 방화벽의 기본 개념
1.2. 다단계 정보 보호 모델 개별적인 구조보다는 전체 네트워크 보안에 대한 구조를 포함하는 모델로는 [그림 3]과 같은 다단계 정보 보호 모델(참고자료[2])이 있을 수 있겠다. 1~5계층까지는 주로 네트워크 구성요소를 기준으로 나누고, 6~7계층은 보안 정책의 접근 제어를 기준으로 나눈다. 아마도 초창기의 인터넷을 사용하던 대부분의 기업, 또는 처음 인터넷을 도입하는 곳은 이러한 다단계 정보 보호 모델과 네트워크 구성도가 동일한 곳이 많을 것이다.
[그림 3] 다단계 정보 보호 모델
앞서 설명한 네트워크 계층별 구분 모델에서의 방화벽들은 다단계 정보 보호 모델의 2계층에 해당하는 것을 알 수 있다. 이런 정보 보호 모델에서 네트워크 보안을 하려면 앞서 설명한 IP레이어에서 막는 모델 중 패킷 필터링의 기능을 가진 방화벽을 사용한다면 기업 내부의 네트워크를 외부로부터 차단할 수 있어 보인다. 하지만, 내/외부에 서비스하는 웹이나 메일서버와 같은 정보 서버, PC에 대한 구분 없이 LAN과 그 외의 경계만을 나타낸 점이나 인트라넷/익스트라넷 및 Mobile Network 등 조금만 진화해도 다단계 정보 보호 모델로는 역시 부족한 점이 많다.
1.3. 제안하는 기업 네트워크 보안 모델 : 매트릭스형 정보 보호 모델 현재 기업 환경에 맞는 새로운 정보 보호 모델을 제안하기 위해 [그림 4]에서는 조금 복잡한 일반적인 기업 네트워크 환경에 대해 표현해 보았다. 다단계 정보 보호 모델에서 좀더 추가된 형태로 단순히 외부 인터넷이라고 표현된 외부 환경에 “로밍 사용자”, “익스트라넷”, “인트라넷”(때에 따라 인트라넷은 내부 네트워크 환경으로 포함시킬 수 도 있을 듯 하다.)으로 구분해 볼 수 있다.
[그림 4] 매트릭스형 정보 보호 모델
여기서는 IP/VPN과 같이 다시 IP패킷을 인코딩해서 주고 받은 형태는 외부 환경으로 취급하고, Frame Relay나 ATM망처럼 IP로 전혀 변환되지 않고 그 이하에서 바로 구현되는 VPN에 대해서는 내부 네트워크 환경의 확장으로 생각하기로 한다)이 추가되었고, 외부 고객들을 위해 서비스 되는 웹서버나 메일 서버와 같은 정보 서버들, 내부 네트워크 환경에서도 내부의 인트라넷 서버, MIS서버 등과 같은 내부 정보 서버들과 PC등 보호해야 할 대상들에 대해 좀더 세부적인 구분을 하여 전체적으로 7개의 정보 보호 대상군으로 나눌 수 있다. 이러한 7개의 정보 보호 대상 구분 이외에 정보 보호 대상별로 어떤 보안 기능을 수행하여야 하느냐에 따라 “개체 관리 (Entity Management)”, “사용자 인증 및 접근 권한 관리 (User/Access Control) ”, “보안 정책 관리(Security Policy Management)” 기능으로 나눌 수 있다. 이렇게 7개의 정보보호 대상 계층과 3개의 정보보호 관리 계층으로 매트릭스 모델을 표현할 수 있다. 이것을 나타낸 것이 [그림 5]이다. 매트릭스형 정보 보호 모델 은 관리의 대상을 보다 명확하게 구분할 수 있다는 장점이 있다. 보안 관리자의 입장에서 는 관리하는 대상과 관리하는 기능을 따로 떼어 생각할 수 없으며, 기업내의 전체적인 정 보 보호를 위해서는 이들 대상과 기능을 통합해서 관리해야 하기 때문이다.
단순하게 생각하면 방화벽의 영역이 External Demark 부분과 Internal Demark만 포함되는 것 같지만 방화벽의 기술이 일반화되면서 모든 요소들을 방화벽이 포함하는 형태로 발전해 나가고 있다. [표2]에서 보는 보안 대상과 보안 기능의 상관관계를 알아보기 위해서는 매트릭스형 정보 보호 모델을염두에 두고 어떻게 방화벽의 기능이나 형태들이 발전해 왔는지 살펴볼 필요가 있다.
[표 2] 매트랙스형 정보 보호 모델의 구성 요소
2. 방화벽의 과거와 현재 기업 네트워크의 대표적인 보안 솔루션인 방화벽(네트워크 침입 차단 시스템)은 외부 네트워크와 내부 네트워크의 경계상에 존재하여 내부와 외부사이에 오고 가는 모든 패킷을 제어할 수 있는 장비나 기능을 총칭한다. 이러한 기본적인 개념 하에 IP주소나 포트번호에 의해 필터링이 가능한 스크린 라우터에서부터 듀얼-홈 게이트웨이, 응용프로그램 게이트웨이, 서킷방식의 게이트웨이 등 다양한 방법의 방화벽이 존재한다. 방화벽의 발전사는 [그림 6]과 같이 간단하게 정리될 수 있다. 먼저 1990년 초에는 TCP/IP가 주로 학교나 연구소에서만 사용되었고, 내부적으로 보안이 중요하다는 필요성이 대두되었다. 처음에는 응용프로그램 수준에서 Tcpwrapper와 같이 시스템을 고치지 않고 실제 프로그램의 동작을 제어하는 간단한 wrapper수준으로 구현/사용되었으나, 시장 자체도 없었기 때문에 기업에서 사용 할 수 있는 상용 제품은 더더욱 없었다. 그러던 것이 1993년쯤에 이르면서 글로벌 인터넷까지 널리 쓰이지는 않더라도 TCP/IP 프로토콜 스택을 구현한 제품들(Chameleon, 트럼펫 윈속, 퓨처 TCP, …)이 나옴으로써 UNIX 에서만 사용하던 것들이 널리 기업의 업무 환경에도 퍼지게 되었다. 또한 이미 오래 전부터 대학교나 연구소에서 필요성을 느껴왔던 사람들에 의해서 프록시 기반의 방화벽(TIS Toolkit, ..)이 주로 UNIX 서버상에서 구현되었으며, 이를 계기로 마케팅적인 측면에서의 방화벽 개념에 대해서도 활발한 논의가 이루어지기 시작하였다. 이러한 분위기가 점차 무르익어 1994년 초에는 UNIX의 커널에 해당하는 IP패킷 처리부분을 수정하여 IP필터링 기반의 방화벽(CheckPoint Firewall-1 등)이 상용화되고 시장에서 빛을 보게 되었으며, 프록시기반의 방화벽 기술에서 한 단계 더 발전하게 된다. 하지만, 아직도 대부분은 UNIX위에서 동작하였고 이들을 조작하기에는 시스템 전문가의 지식이 필요할 정도로 설정 및 관리가 복잡하였다.
1996년 이후 2-3년 동안은 방화벽의 기능 자체가 획기적으로 발전하는 단계라 할 수 있다. Stateful Inpection기능과 Dynamic IP 필터링 기능 등이 일반화되었고, 동작 플랫폼도 UNIX뿐만 아니라 사용자 편의를 위해서 Windows NT 로 포팅된 제품들이 나오게 되었다. 또한, 상용 인터넷이 확고하게 자리를 잡아가는 시점이었기 때문에 전산 관리자들이 네트워크 보안이라는 개념에 대해서도 어느 정도 익숙해진 시기였다. 1998년과 1999년은 방화벽 역사에서 새로운 터닝 포인트라고 할 수 있는데, 이 시기에는 인터넷이 너무도 잘 알려져 있었을 뿐만 아니라, IP 필터링 기술, Stateful 필터링 기능, 프록시 기술 등 모든 기술들이 Free Software형태로 소스까지 공개되면서 대부분의 Linux, FreeBSD, Solaris, … 등에 자유롭게 쓸 수 있을 정도로 일반화되었다. 이때부터 상용 제품들은 단순한 접속의 차단뿐만 아니라 QoS나 VPN 등, 차별화 된 기능과 사용성을 향상시킨 Appliance 형태의 제품(Netscreen사의 제품, Nokia의 IP-xxx 시리즈, Cisco의 PIX 시리즈)들이 쏟아져 나왔다. 2000년 이후 현재 방화벽의 모습은 모든 네트워크 제품에 방화벽의 개념이 포함되는 형태로 진행되고 있다. PC에도 개인용 방화벽이라는 개념이 적용되고 있으며, 심지어 랜카드에도 방화벽 기능이 내장된 형태가 나올 정도이다. 매트릭스형 정보 보호 모델에서 볼 때 대부분의 정보 보호 대상군에 해당하는 것들에 기본적인 방화벽 기능 이상의 네트워크 차단기능이 내장되었거나 추가할 수 있는 제품들이 모두 있다고 해도 과언이 아닐 정도가 되었다. 게이트웨이 방화벽의 기능들도 예전의 일반적인 기능들인 IP 필터링, Stateful 필터링, 프록시 서비스, 네트워크 사용자 인증 등의 기본적인 역할에서 IPSEC를 이용한 VPN기능 및 암호화 통신 제공, QoS 기능, High Availability, Giga-bit 대역폭의 지원 및 Accelerator 카드의 지원 등으로 다양해졌고, 표준이 되는 다른 기술들과도 계속해서 통합작업이 이루어지고 있다. 예를 들어, RADIUS, LDAP, X.509, PKI 등이 그것이다. 이렇듯, 현재 방화벽의 모습은 양적으로나 질적으로 완전한 성숙 단계라 할 수 있겠다. 그렇지만, 방화벽으로 모든 문제를 해결할 수 있는 상황은 아니며, 매트릭스형 정보 보호 모델에 비춰볼 때 여전히 해결할 수 없는 많은 문제들이 존재하다.
3. 게이트웨이형 방화벽의 취약점 방화벽들이 아무리 최신 기능으로 무장을 하고 있더라도 방화벽의 기능들만으로는 해결하기 힘든 문제들이 많은데, 대표적으로 게이트웨이형 방화벽은 아래와 같은 취약점을 가지고 있다. 바이러스 트로이 목마와 같은 데이터화 된 정보로의 공격 관리되지 않은 네트워크 경로로의 침입내부자의 고의적인 해킹 및 자료의 유출 네트워크 프로그램/프로토콜 자체의 결함이나 백도어 새로운 형태의 기법을 활용한 침입 물론, 이런 위협들을 제대로 막기 위해서는 백신 프로그램이나 암호화 프로그램을 사용하는 형태로 보완을 해야겠지만, 이런 프로그램의 사용과 방화벽의 관계에 있어 좀더 심도 있게 관찰해 봐야 할 문제들이 있다. 이들을 몇 개의 케이스로 알아보자.
1) Software failure: 서비스 프로그램의 취약성 서버 프로그램의 취약점에 의한 보안 사고파일의 형태로 전달되는 바이러스, 트로이 목마 프로그램들
2) Management problem: 관리의 문제점 복잡한 네트워크의 보안정책 및 관리의 복잡성 증가 백도어나 방화벽을 통하지 않고 가는 트래픽이나 접속 경로 기하급수적으로 늘어나는 대역폭 및 서버/PC의 댓수
3) Internal risk: 내부자에 의한 해킹 사고 내부자의 의도적인 해킹 내부자의 실수 이들에 대해서 이해를 돕기 위해서 대표적인 몇 개의 예를 들어 보도록 하겠다.
3.1. Case1: 서비스 프로그램의 취약성 네트워크 프로토콜 자체에 취약성이 있는 것이 아니라, 결국은 서버나 PC에서 실행 중이거나 사용하는 프로그램 및 사용방법에 취약점이 있는 것이기 때문에 프로토콜과 IP주소만으로 필터링하는 방화벽으로는 이런 문제를 해결할 수 없는 경우가 많다.
[그림 7] CASE1: 내부 네트워크 보호를 위해 TCP/80 포트를 제외하고 방화벽에서 막은 경우
[그림 7]과 같이 Windows NT웹서버 (IIS Web Server)의 버그를 이용한 침입방법(iishack, http://www.eEye.com) 을 이용하여 IIS 서버를 죽이고 대신 command.com 을 포함하는 trojan을 심는 케이스를 생각해보자. 리자 입장에서는 방화벽에서 외부 정보 서버인 WebSrv 라는 서버의 80포트를 열어놓고 나머지를 닫아놓았다. 원래 의도는 뚫려도 웹서버만 뚫리고 DBSrv나 MailSrv는 안전하겠지라는 생각이었을 것이다. 그러나 인터넷에서 손쉽게 구할 수 있는iishack이라는 해킹 프로그램을 돌리고 난 후에는 출발은 하나의 웹서버라도 해커는 WebSrv를 이용해서 MailSrv, DBSrv 등을 모두 해킹할 수 있게 돼버린다. 나머지 MailSrv, DBSrv 등 내부의 모든 정보 서버들이 게이트웨이 방화벽 하나만 믿고 아무런 보안 장치를 해 놓지 않았다면 그대로 해킹 노출되어 버리는 것이다. (참고자료[4],[5])
3.2. Case2: 복잡한 네트워크 보안 정책으로 인한 관리 문제 캠퍼스 네트워크([그림 8])나 규모가 큰 엔터프라이즈 네트워크에서는 외부로 나가는 네트워크 경로가 여러 개인 경우가 많다. 또한, 부서마다 혹은 학과마다 여러 개의 네트워크 세그먼트가 존재하면 전체에 대한 IP필터링 정책이나 사용자 인증관리가 너무나 복잡하기 때문에 한 두개의 게이트웨이 방화벽을 통해 일관된 정책을 적용하기 어려울 뿐만 아니라 이에 대한 검증 또한 매우 힘들다. 일례로7-8개의 checkpoint Firewall-1의 룰을 관리하는 경우, 몇 개월이 지나서 1500 라인정도의 룰이 만들어지게 되면 나중에는 이에 대한 관리자체가 힘들고 새로운 룰을 추가할 때 네트워크에 어떤 영향을 끼칠지 모르기 때문에 불안할 뿐만 아니라 잘못 실수라도 하게 되면 보안에 구멍이 뚫릴 수 밖에는 없을 것이다. 또한, 이렇게 복잡한 네트워크 환경 내에서는 누군가 서버에 백도어 프로그램을 깔아 놓는 것, 외부에서 쉽게 접속할 목적으로 개인 모뎀들을 PC나 특정서버에 설치, 특정 서비스 포트(23번은 TELNET포트)가 아닌 High Port에 텔넷 서버 데몬을 띄운 놓는 등, 다양한 방법을 통해 게이트웨이 방화벽을 무력화시킨다 해도 이를 찾아내기가 쉽지 않게 된다.
[그림 8] 캠퍼스 네트워크에서의 여러 네트워크 경로
3.3. Case3: 내부자의 해킹에 의한 보안 사고 기본적으로 방화벽은 외부의 침입으로부터 내부의 전산 자원을 보호하고자 하는 것인데, 만약에 내부자의 악의적인 소행이나 (아니면, 내부자의 PC가 해킹을 당한 후 백도어가 심어진 경우) 실수에 의해서 내부 전산 자원이 쉽게 해킹당할 수 있다. 살펴본 몇 개 케이스에서 알 수 있듯이 단순한 게이트웨이 방화벽만으로는 전체 기업네트워크의 보안을 책임질 수 없기 때문에 이를 보완할 수 있는 모델이 마련되어야 한다. 이에 대한 대안으로 분산방화벽이 대두되고 있으며, 이에 대한 자세한 내용은 다음 호에서 알아보도록 하자.
|
