NAC 기술의 흐름을 설명하기에에 앞서, 현재의 NAC 제품의 모습이 진정 앞으로 나아가야 할 모습인지를 알기위해 제조사도, 고객도 지나온 방향을 돌아볼 필요가 있다. 현재의 NAC 솔루션의 모습은 NAC에 대해 너무 개념적인 접근을 시도해 나타나는 부작용이 적지 않게 발생하고 있다. 대표적으로 가장 심각한 문제가 타 솔루션에 명확한 역할과 기능이 존재하는 이 기능 저 기능을 갖다 붙이고, 더 요구함으로써 나타나는 NAC 솔루션 자체의 정체성 문제다.
NAC라는 것은 결국 단말을 더 잘 보호하기 위한 인프라로, 네트워크에 대한 접근제어 기술을 이용하는 솔루션이다. 네트워크 접근제어 기술 측면을 크게 3가지로 분류하자면 ▲사용자 인증 측면 ▲사용자/그룹/사용자 유형별로 허용된 네트워크 접근만을 강제하는 인허가 관리 측면 ▲단말 보안정책의 검증 후 정책 위배 단말에 대한 조치로써의 차단/격리/치료/업데이트/네트워크 자동 복원 유도에 대한 정책 집행 측면으로 구분될 수 있다. 이 세가지 측면의 네트워크 접근제어에는 초기 시스코가 말했던, 또 가트너가 정의했던 NAC에 대한 근본이 모두 포함돼 있다.
무언가가 더 필요하다고 붙인 액세서리로 인해 근본을 잊어서도 안 되고(혹자는 NAC를 또 다른 통합PC보안 SW냐고 질문하고, 혹자는 신규 보안 이슈가 나오면 이를 모두 NAC에서 해결하려 한다), 흐리게 만들어서는 더욱 안 될 것(다른 NAC의 다른 보안솔루션의 특정 핵심기능 구현에 대한 요구)이다.
싸리나무 울타리에 CCTV(?)
싸리나무 울타리에 CCTV를 달고, 창호지문에 지문인식을 도입한다면 우스운 일이다. 도둑을 근본적으로 막고자 한다면, 첫 관문인 울타리부터 높다란 철대문으로 먼저 교체하는 것이 올바른 접근 방법이 될 것이다. CCTV나 지문인식이 필요없다는 것이 아니라 올바른 구현을 위해서는 우선순위가 있는 것이다.
NAC 구축도 마찬가지다. 우선 사용자 인증 기반 네트워크 접근제어 기술에 대한 진정성이 필요하다. NAC의 근본을 잊고, 사용자 인증 측면의 접근제어를 소홀히 한다면 해커 등 비인가자에 대한 통제는 요원할 수밖에 없다.
최근 군 내 NAC 사업에서는 해커의 IP/MAC 도용에 대한 근본적인 대안으로 IEEE802.1x 사용자 인증을 지목했다. ARP table 조작기법 및 포트 미러링 등의 OoB(Out-of-Band) 구축 모델로는 해커의 패킷 도감청(sniffing)으로 인증된 단말의 IP/MAC 주소 수집을 통한 인증 단말 도용을 근본적으로는 막을 수 없기 때문이다. 하지만 NAC 제품 중에는 IEEE802.1x 보안 표준과 무선, DHCP IP주소 할당 환경 등을 전혀 지원하지 못하는 제품이 존재한다. 이러한 다양한 네트워크 환경에서 사용자 인증 접근제어를 통합 인터페이스로 중앙관리할 수 있어야만 철대문으로의 교체 효과를 충분히 볼 수 있지 않을까 한다.
한가지 더 첨언할 사항은 802.1x 사용자 인증을 지원하는 제품이라고 해서 모두 무선랜 최상위 보안표준인 WPA1/2를 지원하는 것은 아니라는 사실이다. 무선인증서버를 NAC 제품 내에 서브시스템으로 포함하지 않는 한 해당 기능 구현 및 사용자 인증과 유기적 연관성이 존재하는 암호화와의 통합관리는 거리가 먼 얘기이므로 주의가 요구된다.
NAC에 있어 에이전트는 항상 뜨거운 감자였지만 이젠 더 이상 에이전트 문제는 고민거리가 되지 못하고 있다. NAC에 있어서의 에이전트 도입은 이미 2009년 초반부터의 대세기 때문이다. ▲국내 NAC 제품이 CC 인증을 모두 에이전트를 포함해 인증을 받았을 뿐 아니라 ▲에이전트를 설치하지 않으면 소개된 많은 기능을 사용하지 못한다는 점은 주지의 사실이다. 또한 ▲바이러스 백신 API를 타이트하게 연동하려면 에이전트가 필수이며 ▲드라이버 통한 장치 인터페이스/패킷 통제가 비 드라이버(non-driver) 방식 에이전트보다 더 뛰어날 수 밖에 없다는 사실은 이제 고객에게 굳이 부연하지 않아도 되는 시기가 됐다.
혹자는 NAC 시장에서 에이전트리스(agent-less) 제품의 약진을 말하는 이도 있다. 하지만 5년이라는 세월이 지나 수백개 사이트에 NAC가 구축되는 동안 진정한 에이전트리스로 구현된 사이트는 불과 몇 개 되지 않는다라는 점과 에이전트리스 외산 제품도 보안제품 연동 등을 위해서는 API라도 단말에 설치해야 한다는 사실은 잊지 말아야 할 부분이다. 나아가 장애가 치명적인 제1금융권, 세 차례에 걸친 행안부/KISA ‘공무원 PC해킹 탐지·차단 시스템 구축’ 사업으로 40여개의 주요 국가 행정기관과 광역·기초 자치단체가 모두 드라이버 에이전트 기반 NAC 제품이 납품됐다는 점도 시장의 선택을 방증하는 사례다.
NAC 액세서리, 필수인가? 필요악인가?
NAC의 가장 중요한 구축 목적이자 기능은 바로 사용자 인증, 단말검증/집행이다. 이 외에 기능은 NAC에 있어서는 부가기능이라 할 수 있다. 최근 기술 동향을 고객 RFP로 분석하면 유해트래픽 탐지/차단 기능, IP주소 관리 기능, 패치관리, 비 드라이버 기반의 매체제어, 자산분류 및 관리 기능 등이 주요 부가 기능으로 인식되고 있는 추세이다.
주로 언급되는 3가지 부가기능에 대해서만 언급해 보면, 우선 유해트래픽 탐지/차단 기능은 2009년 모 기관 RFP에서 3단계 NAC 통제체계로 소개된 운영 개념으로 사용자 인증, 단말 검증, 트래픽 검증이라는 3단계 NAC 통제 체계를 NAC의 기본 골격이라 보는 견해다. 트래픽 검증을 단말 보안성 강화가 지상목표인 NAC의 기본 기능이라 여기는 것은 크게 이상한 일은 아니지만, 기존 IDS나 IPS, 혹은 H-IPS나 PC보안 소프트웨어의 많은 부분의 기능을 NAC에서 구현할 것을 요구하고 있어 업체간 희비가 엇갈리게 했다.
담당자들도 NAC 제품이 여러 기술 연원으로 개념적으로 완성된 제품이 많다라는 것을 알고 있다면, RFP에서는 어느 한 기술 연원의 제품군으로 스펙을 편향 공통화시키거나, 아예 어느 제품이라도 들어올 수 있도록 일반화된 공통 스펙으로 RFP를 내보내야 한다. 하지만, 국내 담당자는 여러 제품의 좋은 기능을 발췌하고 사이트의 특성과 담당자의 견해를 보탬으로써 NAC 시스템 구축 사업을 보안SI 사업 정도로 만들어 가고 있는 것이다.
다음으로 IP주소 관리 기능은 실질적으로 IPMS 제품을 가진 업체가 NAC 제품 제조 및 공급을 천명하고, 기존 IPMS를 가지고 있지 않은 중소기업 위주로 NAC 도입 시 동시에 구축하려는 경향이 일부 발생하고 있다. 이러한 경향은 ARP 테이블 조작 기법을 가진 국내외 제품과 시장에서의 충돌을 예상하게 한다.
마지막으로 패치관리와 매체제어를 도입하고 싶다면, 그 기능과 효과 범위를 명확하게 하는 것이 좋을 듯 싶다. 소규모라면 어느 정도 만족하겠지만 그 이상의 성과를 요구한다면 WSUS의 PMS로의 한계성이나 비 드라이버 기반의 매체제어 기능이 제공할 수 있는 세밀한 R/W 제어기능은 포기해야 한다는 사실은 명확하게 인지하고 기능 적용에 대한 부분을 논의해야만 한다.
NAC은 이미테이션 액세서리로 치장할 만큼의 사치품이 아닌 생활 필수품이 돼야 한다. 위 부가 기능들이 NAC으로서의 기본 기능을 충실한 상태에서 얹어진다면 두말할 나위가 없겠지만, 그렇지 않다면 기본에 충실한 제품을 선택하는 현명한 선택이 될 것이다.
NAC의 3가지 접근제어 기술은 향후 OS, 네트워크/보안 장비 등에 기본 기능으로 점진적으로 흡수될 것이다. 그렇게 되면 각종 보안솔루션 및 보안설정 등은 NAC 표준 프레임이 요구하는 사항을 준수하기만 하면 담당자가 손쉽게 중앙정책으로 컨트롤(마치 NAP가 AD에서 일부 관리될 수 있는 것처럼)할 수 있는 시대가 될 것이다. 그러기 위해서는 IEEE 802.1x, TCG TNC, IETF NEA 작업반 등에서 발전한 보다 완성도 높은 표준안의 확정과 주요 OS나 장비에서의 확정된 표준 기술의 빠른 적용 등이 반드시 선행돼야 한다. 표준 환경 및 기술 위에서 동작하는 NAC 체계의 완성으로 더 이상 NAC에 대한 정의, 기술 연원 및 구축모델로 기인한 제품 기능의 다양성, SI성 커스터마이징 등에 대해 갑론을박이 없는 미래를 기대한다.
