소규모 정적 네트워크에 적합 … ‘속도·중복성’ 확인해야 기존 인프라 손 댈 필요 없이 ‘투명하게’
상태바
소규모 정적 네트워크에 적합 … ‘속도·중복성’ 확인해야 기존 인프라 손 댈 필요 없이 ‘투명하게’
  • 데이터넷
  • 승인 2007.11.05 00:00
  • 댓글 0
이 기사를 공유합니다

Rolling Review / 인라인 NAC
소규모 정적 네트워크에 적합 … ‘속도·중복성’ 확인해야 기존 인프라 손 댈 필요 없이 ‘투명하게’

앞으로 몇 개월 동안 우리는 인라인으로 배치돼 악성 트래픽을 주시하는 NAC(Network Access Control Appliance)를 테스트할 계획이다. 이에 앞서 이번 호에는 우선 NAC 아키텍처에 대한 기본 사항들을 소개하기로 한다.

특별한 회사가 아니라면 코드 레드나 코드 그린, SQL 슬래머 같이 급속히 번져가는 웜의 망령들로 무척이나 두려움을 느끼겠지만 그렇다고 인프라에 복잡하고 값비싼 대대적인 업그레이드를 할 정도로 충분히 겁을 먹지는 않을 것이다. 시스코시스템즈가 원래부터 갖고 있는 NAC에 대한 비전은 바로 이 점에 착안한 것이었다. 결국 네트워크로 접속된 모든 장비가 사양에 맞도록 보장하고 바이러스로부터 자유롭게 하기 위한 논리적 장소는 접속 지점이라는 것이다.
이같은 생각에는 확실히 일리가 있긴 하지만 많은 경쟁 업체들은 네트워크를 처음부터 끝까지 철저히 감시하는 데 따르는 엄청난 가격이 없이도 같은 이점을 제공할 수 있는 기회를 포착했다.
오늘날에는 전면적(full-on) 업그레이드에 대한 대안으로 호스트 기반(host-based), 인라인(in-line), 그리고 대역외(out-of-band) NAC 등 크게 세 집단이 경쟁을 벌이고 있다. NAC 이머션 센터에서 보다 심도 깊게 다루겠지만, 각 방안에는 나름의 장단점이 있으며, 제품의 아키텍처와는 별 관련이 없고 업체측의 핵심 경쟁력과 관련이 많은 것들도 있다.
각 집단에서 최고의 제품을 가려내기 위해 앞으로 몇 개월간 본지에서는 대역외와 호스트 기반 시스템에 대한 롤링 리뷰를 실시할 것이며, 우선은 대역내 NAC에 초점을 맞추기로 한다.
우리는 이런 방안들을 독립적으로 테스트하긴 했지만, 어떤 조직들은 다른 영역에서 한 가지 이상의 제품을 사용하고 싶을 수 있다. 네트워크의 같은 부분에는 한 가지 이상의 방법을 쓰지 말기를 바란다. 그렇지 않으면 다중 정책 세트로 인해 사용자가 곤란을 겪음으로써 헬프데스크 호출의 홍수 속에 잠겨버릴지도 모르기 때문이다.

흐름을 방해하지 않도록
그 이름에서 알 수 있듯이 인라인 NAC에서는 어플라이언스가 트래픽 흐름 안에, 언제나 에지와 디스트리뷰션 스위치 사이에 배치돼야 한다. 대신 대역내 어플라이언스는 데이터 센터 전면에 배치될 수 있는데, 이것은 TNT(Trusted Network Technologies) 같은 업체에서 선호하는 방식이다.
제품이 어디에 놓이든 간에 가장 중요하게 고려해야 할 것은 이것이 트래픽 흐름을 방해하지 않도록 하는 것이다. 이 시장에 진출한 대부분의 업체들은 용도에 맞게 제작된 ASIC(Application-Specific Integrated Circuit)을 이용해 최고의 성능을 제공하고 있긴 하지만, 트래픽 흐름을 처리하는 데 대한 규정이 복잡해지면서 ASIC에서 멀티코어의 범용 프로세서로 이러한 작업이 이동하고 있는 것도 사실이다. 선명치 못했던 라우터 전쟁 때와는 달리 인라인 NAC 업체들은 특히 막대한 패킷 프로세싱이 요구될 때 자사 시스템의 성능 한계에 대해 상당히 솔직한 편이다.
하지만 이들은 당신이 물어볼 경우에만 솔직할 뿐이다. 회선 속도로, 혹은 그에 가깝게 패킷을 옮길 수 있는 능력을 인라인 NAC 업체들의 핵심 경쟁력이라고 하기에는 아직 가야 할 길이 멀다.
인라인 NAC가 실용적이 되기 위해서는 고성능 ASIC 디자인에서의 숙련도와 함께, 프로토콜 및 정책 프로세싱용의 멀티코어 엔진이 필요하다. 이러한 디자인의 이점은 모든 트래픽이 흐름별로 정책에 대한 평가를 받을 수 있다는 것이며, 이는 대역외 시스템에서는 불가능한 일이다.
아이러니컬하게도 대역내 NAC 시스템은 고도로 정밀한 수준으로 정책을 이행할 수 있는 능력을 갖고 있지만, 반면에 자신들의 정책 관리 시스템의 사용 편의성과 완전성을 기반으로 스스로를 차별화하고자 하는 곳은 대역외 업체들이다. 이러한 차이가 두 개 집단와 업체들을 어떻게 나누는지에 대해서는 이들 각 제품을 평가할 때 함께 분석해보기로 한다.

투명한 설치
정밀한 정책 시행과 함께, 인라인 NAC는 투명에 가까운 설치를 제공한다. 기존 스위치를 교체하든, 혹은 새로운 레이어의 스위칭을 제공하든 관계없이 인라인 NAC 시스템은 네트워크에 단지 다른 또 하나의 스위치로 보여진다. 이와 대조적으로 다른 NAC 대안들은 802.1x 같은 네트워크 프로토콜이나 DHCP(Dynamic Host Configuration Protocol) 관리, 혹은 가상랜 조종 기법을 이용하며, 이들은 모두 기존 네트워크 작동에의 변경을 필요로 한다. 그리고 이러한 시행 메커니즘들은 흐름당 기반이 아니고 전체 트래픽에 적용되는 둔감한 방식이기 때문에, 대역외 시스템들은 전반적으로 액세스를 허용, 혹은 거부하거나, 치료나 재평가를 강행하는 것까지 제한이 된다.
일부 인라인 제품들은 애플리케이션 레이어까지 도달하는 정책 시행을 주장하고 있다. 사용자의 액세스를 이들에게 사용이 허가된 시스템과 서비스까지로 제한하고자 하는 조직을 위해, 인라인 NAC는 이러한 보안 상태를 시행하는 데 필요한 메커니즘을 제공한다. 이러한 정책의 이점들은 너무도 확실한데, 이는 사용자나 호스트가 기능을 할 수 있는 데 필요한 네트워크 서비스로만 액세스를 허용하고, 다른 모든 액세스를 거부함으로써, 악의적 사용자나 감염된 컴퓨터로 인해 손해를 볼 가능성이 크게 줄어든다는 것이다.

똑똑한 방화벽
인라인 NAC 어플라이언스를 방화벽이라고 부르는 것은 아인슈타인을 땜장이라고 하는 것과 같다. 즉 본질적으로는 맞는 말일지 모르지만 엄청나게 과소평가된 말이다. NAC 어플라이언스는 아주 똑똑한 방화벽이다. 예를 들어 이들은 침입 탐지 시스템으로 작동하면서 변칙적 행동 탐지와, 정책 시행을 보강하고 알리는 다른 모니터링 기능들을 제공할 수 있다. 이와 대조적으로 일부 대역외 NAC 제품들은 네트워크 행동을 모니터링할 수 없기 때문에 공격을 전혀 탐지할 수 없다.
하지만 호스트를 액세스하는 프로세스는 여러 NAC 이행에서 문제의 지점이다. 보통 이 평가에는 시스템을 점검하고 이들의 상황에 대해 다시 보고해 주는 에이전트 설치가 필요하지만 인라인 구성에서는 에이전트가 불필요할 수 있다.
NAC 어플라이언스는 네트워크 트래픽을 모니터링하고, 인증된 사용자를 IP와 MAC 어드레스에 대조시키기 때문에, 좋은 데스크톱 관리 프랙티스가 있는 조직에서는 액세스를 제어하는 데 충분하다. 게다가 보너스로 인라인 기술은 프린터같이 에이전트를 돌릴 수 없는 시스템을 평가하는 데 사용될 수도 있다.
몰론 이 같은 모든 좋은 점은 인라인 어플라이언스를 어디에 배치해야 하는지에 대해 제대로 된 아키텍처적인 의사결정을 내리는 데 내포가 된다. 적절한 성능이 있다는 전제 하에 인라인 아키텍처는 네트워크 코어에 더 가깝게 사용되는 어플라이언스 수가 적을수록 더 간단하고 저렴해진다. 하지만 어플라이언스가 네트워크 에지에서 멀어지면 공격에 노출될 시스템 수도 늘어난다. 어플라이언스는 실제로 이것을 통과하는 트래픽을 제어할 수 있을 뿐이다. 악성이라 하더라도 세그먼트간 트래픽은 방해를 받지 않는다는 얘기다.
그리고 이러한 첫 수비는 전쟁의 절반에 지나지 않는다. 사용자나 시스템이 일단 네트워크로의 액세스를 허가받으면, 공격을 막기 위해 지속적인 모니터링이 필요하다. 인라인 시스템은 침입이나 네트워크 비정상 활동 탐지 및 감사 활동을 제공함으로써 이러한 문제에 대응한다.
예를 들어 문제가 없어 보이는 사용자에게 ERP 웹 서버로의 액세스가 주어졌는데, 일단 액세스를 한 이 사용자가 공격을 시작할 수도 있다. 결국 PC에서 허가 테스트를 통과했다고 해서 그 소유자가 악의적 행동을 도모하지 않는다는 의미는 아니라는 얘기다.
침입 및 이상 활동 탐지 기능은 공격자를 발견하거나 비정상적 행동에 경보를 보낼 수 있지만, 이것은 단 이런 시스템이 포함된 트래픽을 실질적으로 볼 경우에 한단다. 이런 모니터링이 목표라면 인라인 어플라이언스를 가능한 한 에지 스위치에 가깝게 배치하는 게 확실히 바람직하다. 게다가 규제가 심한 특정 업계에서는 네트워크 활동의 로깅 및 감사가 필요하며, 인라인 NAC 시스템은 리뷰용으로 포괄적인 로그 데이터를 제공할 수 있다.

구입에 앞서
호스트 평가 및 시행과 함께, 살펴봐야 할 몇 가지 핵심 요소들이 있어 짚어 보기로 한다.

>> 인라인으로 배치되는 어플라이언스는 어떤 것이든 네트워크 설계자에게 공포심을 주는 경향이 있다. 이것은 오류 지점이 될 가능성이 높고, 병목의 가능성도 많기 때문이다. 따라서 인라인 어플라이언스는 스위치들간에 종종 기가비트 업링크를 이용해 데이터 속도를 지원할 뿐만 아니라, 대기시간이나 지터 추가가 거의, 혹은 전혀 없이 회선 속도로 지원하는 게 중요하다.
앞서 언급한 것처럼 대부분의 NAC 어플라이언스는 패킷 처리용으로 고안된 특수 용도의 하드웨어를 사용하지만, 마케팅 자료에 있는 성능 주장들은 조심해야 한다. 이러한 수치들은 NAC 기능성 감소를 전제로 하거나, 혹은 실제의 네트워크 상황을 반영하지 않은 최적의 트래픽 조합을 기반으로 하는 경우가 많기 때문이다. 인라인 NAC 어플라이언스 대금을 지불하기 이전에, 이것을 라이브 네트워크에 배치해 보고 페이스 유지할 수 있을지 확인해야 한다.

>> 하드웨어 오류시 네트워크가 접속을 유지하도록 보장하는 데 있어 중복성은 필수다. 어플라이언스는 핫스왑이 가능한 N+1개의 팬과 전원공급기가 있어야 하며, 그렇지 않을 경우 최소한 오류시 패킷 흐름을 중단시키는 게 아니라 트래픽을 통과시킬 수 있도록 페일 오픈(fail open)에 대한 옵션이 있어야 한다. 물론 보호되지 않는 상태로 사용자의 생산성을 유지하는 게 나은지, 아니면 어플라이언스가 고쳐질 때까지 이들을 단절시키는 게 나은지를 결정해야 할 필요도 있 을 것이다.


인라인 NAC 롤링 리뷰
초대 : 롤링 리뷰에서는 액세스 레이어와 디스트리뷰션 레이어 스위치들간에 설치되어 NAC 정책을 평가하고 시행도 할 수 있는 NAC 제품에 초점을 둘 것이다. 우리는 대중에게 개방된 회의실, 관리되는 컴퓨터가 들어 있는 내부 네트워크 세그먼트, 그리고 원격 근로자 등과 같이 몇 가지 일반적인 상황들을 테스트할 계획이다.
테스트를 받는 대역내 NAC 제품은 802.1x, 가상랜(VLAN) 조종, DHCP 제어, ARP 제어, 혹은 인라인 차단 및 기타 적절한 메커니즘 등 어떠한 방안을 이용해서든 정책을 시행하게 된다.
회사들은 NAC를 내부 자원을 공격으로부터 보호하면서 동시에 사용자와 호스트가 네트워크에 수행할 수 있는 행동을 제한하기 위한 하나의 방편으로 보고 있다. 호스트의 상황을 기반으로 ‘온’이나 ‘오프’를 선택하는 바이너리 정책은 충분히 효과를 발휘할 수 있을 만큼 강력하지 못한 경우가 많다. 이보다도 정책은 사용자와 장비가 네트워크에서 상호작동할 수 있게 허용하면서 동시에 수용 가능한 호스트 상태를 유지할 수 있게 해주는 액세스 규정을 적용시킬 필요가 있다. 테스트에서 우리가 만드는 정책과 목표는 이러한 원칙을 반영하게 될 것이며, 우리는 제품이 지켜야 할 수용 가능한 상태를 지정할 것이다.
마찬가지로 시행 결정이 언제나 ‘허가’나 ‘거부’인 것은 아니다. 사용자에게 경고보내기, 백그라운드에서 업데이트 시작하기, 특정 자원으로의 액세스 제한하기, 혹은 호스트 검역하기 등 시행에 있어 다양한 선택이 가능할 것이다. 그리고 우리는 각각의 참가 제품이 얼마나 큰 유연성을 제공하는지 평가해 볼 생각이다.

참가 업체 : 우리는 컨센트리네트웍스(ConSentry Networks), 엔터라시스네트웍스(Entrasys Networks), 네비스네트웍스(Nevis Networks), 티핑포인트테크놀로지즈(TippingPoint Technologies), 트러스티드네트워크테크놀로지스(Trusted Network Technologies), 버니어네트웍스(Vernier Networks) 등 다섯 개 업체들에게 대역 내 NAC 제품을 보내달라고 요청했다.

테스트베드 : 우리는 윈도 XP, 비스타 및 맥 OS X 워크스테이션을 이용해 테스트를 할 계획이다. 회의실 액세스 스위치와 원격 사용자에게 연결된 것들을 제외한 모든 워크스테이션은 관리가 되며 우리 액티브 디렉토리 도메인에 속하게 된다. 회의실 액세스 스위치에 연결된 워크스테이션들은 게스트 컴퓨터가 될 것이다. 네트워크에는 또한 리눅스 서버와 다른 ‘관리 불가능한’ 장비들도 놓이게 된다.
우리는 전체 네트워크에서 802.1Q 가상랜을 사용할 것이며, 가상랜들간의 트래픽은 라우팅된다. 액세스 스위치는 디스트리뷰션 스위치로 802.1Q 업링크 트렁크를 이용해 연결된다.
액티브 디렉토리 서버에서는 AD, 래디우스(IAS), DNS 및 DHCP 서비스를 제공할 것이다. 그리고 시스템과 애플리케이션 업데이트용의 업데이트 서버도 둘 생각이다. 테스트베드는 대체로 자급자족형으로 할 생각이다. 네트워크의 기능성을 최대한으로 살리고 제품들을 기존의 네트워크로 통합시킬 것이며 액세스 스위치를 교체하지는 않을 생각이다.
클라이언트 소프트웨어는 AD 도메인에 있는 컴퓨터에 두겠지만 게스트 컴퓨터에 영구 에이전트를 두지는 않을 것이다. 여러 가지 시행 유형을 테스트해 보고 싶으며, 회의실에서 802.1x를 사용하지는 않을 것인데, 그 이유는 클라이언트가 적절히 서플리컨트(supplicant)를 구성했다고 가정할 수가 없기 때문이다. 하지만 802.1x는 관리되는 유무선 네트워크에서 수용 가능할 것이다.
우리는 워크스테이션 그룹으로 이행하고자 하는 구성 지침과 목표를 정할 것이다. 어떤 호스트는 적합할 것이며, 어떤 것은 그렇지 못할 것이다. 게다가 어떤 호스트들은 알려진 악성 소프트웨어로 감염이 될 것이며, 어떤 것들은 악의적 행동의 징후를 보일 것이다. 그리고 우리는 처음 및 진행 중 평가와, 우리 정책을 위반하는 호스트에 대한 대응 행동을 검토해 볼 생각이다.

약속 : 인포메이션위크 랩의 롤링 리뷰는 유망 기술 부문에 대해 포괄적으로 다루며, 시장 분석에서 시작해 우리가 발견한 것들을 간략히 정리하는 것으로 마무리된다. 여기서 다루는 폭넓은 테스팅 범위 덕분에 우리는 오늘날의 가속화되는 개정 사이클을 수용하고 개별적인 제품에 대해 초점을 견지하면서, 동시에 테스트베드를 일관성 있게 관리할 수 있을 것이다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.