NAC(Network Access Control), 즉 네트워크 액세스 제어 시장은 범죄 소설보다 더 많은 등장인물과 더 복잡한 구성을 갖고 있다. 시스코와 마이크로소프트가 시장을 지배하기 위해 파트너십을 맺고, TCG(Trusted Computing Group)가 자리를 차지하기 위해 고군분투하고 있다. 이제 본격적인 영웅들의 이야기로 들어가 보자.
모든 음모 이론가들은 한 가지 공통점을 갖고 있는데, 그것은 발 넓은 나쁜 세력들이 사악한 목표를 관철시키기 위해 작당을 해서 사건을 조작하고 있다는 확신이다. 그리고 이것은 바로 NAC 시장을 한 마디로 요약하는 말이기도 하다.
이 음모에 발을 담그고 있는 이들의 수는 몇 년 전 소수에서 출발해 지금은 35곳이 넘는다. 그리고 시스코와 그 경쟁 업체들이 대표적이긴 하지만 이것은 단지 인프라 장비 업체들만의 게임이 아니다. 에어마그네트(AirMagnet), 버니어(Vernier), 마이크로소프트에 이르기까지, 모두가 기업 보안 예산의 한 조각을 노리고 있으며, 이것을 얻기 위해 부끄러움 없이 편리한 동맹을 결성하고 있다.
2008년, 39억 달러 전망
당연한 일이지만, 인포네틱스 리서치(Infonetics Research)에서는 NAC(Network Access Control) 시행 제품에 대한 전세계 제조업체 매출은 지난 2005년 3억2천300만 달러에서 2008년에는 39억 달러까지 늘어날 것으로 전망하고다. 무려 1,100% 이상의 성장이다.
본지(미 네트워크 컴퓨팅)의 한 독자 설문조사에서는 응답자 조직의 절반 이상이 이미 어떤 형태로든 NAC를 배치하고 있었다. 그리고 이들 대부분은 네트워크 액세스를 게스트 사용자, 모바일 랩톱 및 무선 호스트 등으로 제한하는 것과 같은 타깃 영역에서부터 시작하고 있었다.
업체들이 잘만 한다면 이렇듯 간단한 이용 사례는 UFO 집회의 해적판 X-파일 클립들처럼 확산될 것이다.
설문조사에서 높은 수치의 전사적 배치에 대한 우리의 놀라움이 가라앉은 것은 좀 더 깊이 들어가 이런 응답자의 상당수가 정부, 혹은 금융 서비스 부문에 종사하는 사람들이라는 사실을 알고 난 후였다. 이런 곳에서는 규정 준수가 강력한 동력이 된다. 이들 상당수의 IT 조직이 무선, 원격 액세스 및 모바일 랩톱을 중심으로 한정적인 배치부터 시작하는 것은 우리로서나, 혹은 NAC 업체들로서 놀라운 일이 아니다.
이들은 앞으로 있을 큰 계약의 냄새를 맡고 IT를 매우 불안하게 하는 페인 포인트(pain point)에 마케팅 투자와 판촉 활동을 집중시키고 있다. 즉 게스트 계약자나 컨설턴트는 당신의 네트워크로 접속을 할 필요가 있으며, 이것을 하지 않겠다고 말하기란 쉽지 않은 일이기 때문이다.
프레임 짜기
NAC 부문에서 한 가지 큰 소식은 업체측이나 표준화 기구들 모두 프레임워크(framework)를 향해 이동하고 있다는 것이다. 프레임워크는 IT에서 API나 공통 프로토콜 같은 통합 지점을 거쳐 여러 업체의 제품들을 결합시킬 수 있게 해주어야 한다. NAC 제품이 표준화된 프레임워크를 고수하는 게 얼마나 중요할까? 본지 설문조사에서는 매우 중요한 것으로 밝혀졌다. 하지만 어떠한 하나의 특정 프레임워크에 대한 수요는 확실치 않으며, 이는 곧 진정한 리더가 아직 등장하지 않았음을 의미한다.
그렇다고 해서 시도가 없는 것은 아니다. 세 가지 주요 NAC 프레임워크, 즉 시스코시스템즈의 NAC(Network Admission Control), 마이크로소프트의 NAP(Network Access Protection), 그리고 TCG(Trusted Computin Group)의 TNC(Trusted Network Connect)가 주목을 끌기 위해 경쟁을 하고 있으며, ‘위기의 주부들’ 이야기보다도 더 복잡하게 꼬인 줄거리를 만들어 내고 있다.
시스코와 마이크로소프트는 NAC/NAP 상호운용성 아키텍처(Interoperability Architecture)를 이용해 힘을 합쳤다. 마이크로소프트는 TCG에서 정한 사양에 NAP를 맞추기 위해 노력한다고 공식적으로 발표했다. 그리고 시스코는 IETF NEA BoF(IETF Network Endpoint Assessment BoF)에서 주니퍼네트웍스 등 다른 업체들과 협력하고 있다. NEA BoF가 하나의 워크그룹으로 결성된다면 이것은 경쟁 표준을 통합하는 작업을 시도할 것이다.
현재로서는 시스코/마이크로소프트 상호운용성 아키텍처가 단지 두 개의 거대업체가 시장에 미치는 영향력으로 인해 앞서고 있다. 반면 TCG/TNC는 ‘시스코만 빼고 모두(eveyone but Cisco)’의 대표단으로 이 모두에는 양다리를 걸치고 있는 마이크로소프트도 포함돼 있다.
프레임워크 해부
이것을 네트워크 액세스 제어라고 부르던, 네트워크 허가 제어라고 부르던, 네트워크 액세스 허가, 네트워크 노드 검증, 혹은 TNC라고 부르던 전제는 간단하다. 즉 이런 시스템은 호스트 평가, 호스트 및 사용자 인증, 패치 레벨, 로케이션 및 심지어 시간을 기반으로 네트워크 액세스를 허가한다는 것이다.
하지만 기능들은 진보하고 있다. 시만텍에 의해 인수된 사이게이트(Sygate)나 체크포인트소프트웨어가 인수한 존랩스(Zone Labs) 같은 업체의 초창기 NAC 제품에서는 호스트에 있는 에이전트(agent)를 통해 평가 작업이 수행됐다.
지금 NAC 제품들은 안티바이러스 및 안티스팸 상태, 패치 레벨, 방화벽 상태 및 정책 등 보다 다양한 호스트 상황 데이터(host posture data) 지점을 이용해 평가하고 있다. 마찬가지로 인라인 게이트웨이를 통해 처리되던 초기 시행 모델은 인라인, 대역 외 및 호스트 기반 등 일련의 시행 전략들로 변형됐다.
시스코 CNAC
시스코의 NAC 버전인 CNAC(Cisco Network Admission Control)는 네트워크 장비로의 액세스를 제어하고, 어떠한 업체의 인프라 장비든 사용 가능한 시스코의 클린 액세스 NAC 어플라이언스와는 차별화된다.
CNAC는 호스트 평가용으로 시스코 시큐리티 에이전트(Cisco Security Agent)나 시스코 트러스트 에이전트(Cisco Trust Agent)를, 집중식 정책 개발 및 배치용으로 시스코의 시큐어 액세스 컨트롤 서버(Secure Access Control Server)를, 그리고 시행용으로는 다양한 인프라 장비를 사용한다.
CNAC를 이행하기란 기존 인프라를 개장하는 데 막대한 투자를 필요로 하는 만만치 않은 일이다. 시스코도 CNAC보다 클린 액세스를 기업에 팔기가 더 쉽다는 사실을 인정했다. 신랄하게 말하는 사람들은 CNAC가 돌아가게 하려면 모든 시스코 장비가 업그레이드돼야 하며 결과적으로 더욱 록인(lock-in)이 될 것이라고 정확히 지적해 줄 것이다.
시스코 단일 벤더 사이트이고, 별 문제가 없다면 CNAC가 유용할 수 있다. 하지만 여러 업체의 라우터와 스위치 장비를 지원할 경우 CNAC와의 통합은 힘들 것이며, 시스코 이외의 장비는 정책을 시행하지도 못할 것이다. 마이크로소프트와 마찬가지로 시스코도 또한 전반적인 호스트 및 네트워크 보안 제품을 실행하는 보안 업체를 포함하는, 다소 공격적인 파트너 프로그램을 갖고 있다.
CNAC에서는 시스코 시큐리티 에이전트로 서드파티 업체를 이용해 상황 정보를 제공한다. 그러면 이 정보는 시큐어 액세스 컨트롤 서버로 전송되며, 이 서버는 인증, AV 및 패치 관리 시스템과 같은 외부의 평가 권한부여 기관과 통합 된다. 액세스 컨트롤 서버는 상황 정보를 회사에서 정한 정책에 대조해 검증하며, 외부의 권한부여 서버를 이용해 어떤 정책이 호스트에 적용돼야 하는지를 학습할 수 있다. 시행은 스위치, 라우터 및 VPN 컨센트레이터와 같은 시스코 인프라 장비를 통해 이뤄진다.
MS NAP
NAP는 소프트웨어 전용 프레임워크로서 액티브 디렉토리, 네트워크 폴리시서버(Network Policy Server)라는 새로운 서버, 그리고 롱혼, 비스타(Longhorn, Vista)와 함께 윈도 XP SP2에 대한 업그레이드 클라이언트로 출시될 NAP 대행자가 포함돼 있다. 이전의 윈도 버전과 비 윈도 OS는 지원되지 않는다.
NAP는 SHA(System Health Agents)를 규정하는데, 여기에는 데스크톱 방화벽, 안티바이러스 스캐너, 그리고 패치 관리 시스템이 포함된다. 그리고 SoH(Statements of Health)라는 상태 보고서들은 HRA(Health Registration Authority)라는 서버로 SHA에 의해 전송된다.
네트워크 폴리시서버는 안티바이러스 및 패치 관리 서버와 같은 외부 권한부여 기관과 통합돼 기존의 구성 정보를 확보한다. 그런 다음 호스트에는 HRA에 의해 건강 증명서(Health CErtificates)가 발급되거나, 혹은 건강 점검이 실패할 경우 치료를 위해 다이렉팅된다. 건강 증명서는 호스트 상황을 증명하는 네트워크 서버로 제시된다.
제품들이 출시될 때까지는 마이크로소프트가 NAP를 얼마나 잘 이행할지 알 수 있는 방법이 없다. 게스트 액세스가 액티브 디렉토리 도메인에 속해 있지 않는, 관리되지 않는 PC나 컴퓨터용으로 지원되는 방식에서의 차이가 염려된다.
게다가 NAC에 반드시 있어야 할 것들 중 일부가 보이지 않는 것도 문제다. 예를 들어 호스트에서 돌아가는 NAP 클라이언트에 보고를 하는 소프트웨어인 SHA는 NAP 클라이언트로 상태 변화를 통보하는 데서 요구되지 않는다. 이는 곧 호스트가 정책 준수에 실패할 수 있으며, NAP 클라이언트는 다음 평가가 실행될 때까지 알지 못한다는 것을 의미한다.
시스코와 마찬가지로, 마이크로소프트도 소프트웨어 업체뿐만 아니라 알카텔, 엔터라시스네트웍스, 익스트림네트웍스, HP 및 주니퍼 등의 네트워크 인프라 사업자들까지 포함하는 파트너 프로그램을 성공적으로 운영하고 있다.
상호운용성 아키텍처
시스코/마이크로소프트 NAC/NAP 상호운용성 아키텍처는 수년 간의 통합 작업이 가져다 준 성과다. 이 동맹은 계획대로 되기만 한다면 각 프로그램 사이의 갭을 메꿔줄 수 있을 것이다. 즉 시스코는 하드웨어 시행과 비 윈도 OS용 지원을 가져다 주며, 마이크로소프트는 윈도 및 액티브 디렉토리 지원을 내놓는다. 둘 다 버틸 수 있는 각자의 파트너 프로그램을 제공하며, 각 업체의 파트너들은 이론적으로는 양쪽에서 모두 경기를 할 수 있게 허용될 것이다.
통합 지점은 바로 시스코 액세스 컨트롤 서버가 마이크로소프트 NAP와 상호작동하는 방식이다. 클라이언트에 SoH가 없다면 이것은 마이크로소프트의 HRA로부터 하나를 요청해야 할 것이다. 클라이언트가 SoH 리스트를 전송할 경우 액세스 컨트롤 서버는 이것을 네트워크 폴리시 서버로 전달하며, 네트워크 폴리시 서버는 문구를 검증하고 그 결과를 액세스 컨트롤 서버로 돌려 보낸다. 그러면 액세스 컨트롤 서버는 정책을 이행하는 된다는 방식이다.
아직도 혼란스러운가? 이러한 파트너십에는 한 가지 확실한 장점이 있는데, 그것은 바로 비 윈도 OS와 윈도 XP 이전 버전이 무료 시스코 시큐리티 에이전트에 의해 지원된다는 것이다. 하지만 알카텔, 익스트림 및 HP와 같은 NAP 파트너들이 이 그림에 어떻게 맞을지는 확실치 않다.
TCG / TNC
트러스티드 컴퓨팅 그룹(TCG)의 트러스티드 네트워크 커넥트(TNC) 워크그룹은 NAC에 참여하고자 하는 모든 업체로 구성되며, 시스코만 제외된다. TCG/TNC 워크그룹은 하나의 완전한 NAC 시스템을 위한 데이터 포맷과 통신 프로토콜을 규정하는 사양을 발표했지만, 본지의 독자 설문조사와 보안 및 IT 전문가들과의 인터뷰를 통해 여기에는 가시성(visibility) 문제가 있는 것으로 밝혀졌다. 각자 다른 마케팅 예산을 감안하면 놀라운 일도 아니다.
TCG/TNC 사양은 업체 중립적이기 때문에 사양을 쓴 어떤 회사든 다른 어떤 업체의 NAC 제품을 통합시킬 수 있다. 그 초석은 CNAC와 매우 유사해 보이는데, 다음과 같이 진행이 된다. IMC(Integrity Measurement Collector)가 TNC 클라이언트 소프트웨어로 건강 데이터를 전송하면 TNC 클라이언트 소프트웨어는 이것을 PDP(Policy Decision Point)로 보낸다. 이 PDP에서는 IMV(Integrity Measurement Verifier)에 의해 주어진 측정값을 검증한다.
일단 PDP가 결정을 내리면, 액세스 정책이 PEP(Policy Enforcement Point)로 적용이 된다. TNC 클라이언트는 PDP를 공급하는 같은 업체에 의해 공급될 가능성이 가장 높지만, 반드시 그렇지는 않다.
이러한 모델은 이행에 있어 다음과 같은 여러가지 의문을 불러일으킨다. 호스트에 다중 TNC 클라이언트가 있을 경우 어떤 것이 사용돼야 하는가? TNC 클라이언트는 호스트에 어떻게 등록이 되며, 호스트 구성에는 무엇이 포함되는가? 제품 출시가 있을 때까지는 이러한 의문은 해결되지 않을 것이며, 베스트 프랙티스도 만들어지지 못할 것이다.
이 그룹은 바쁘게 시연을 후원하고, 업체들을 멤버로 추가시키고 있다. 발표되지 않은 작업에 대해 어지간해서는 입을 열지 않고 있지만, 이 그룹은 현재 다른 TCG 워크그룹의 작업을 통합한다거나, 다른 네트워크와 보안 장비를 TNC 아키텍처로 통합하기 위해 더 많은 사양을 추가하는 등의 아이디어를 시험해 보고 있다.
이렇게 되면 보다 많은 평가 및 시행 제품들이 나올 수 있을 것이다. 하지만 이 그룹은 어떤 것이든 공개적으로 진행하려 하지는 않는데, 나쁜 생각은 아니지만 TCG/TNC의 가시성 문제에는 전혀 도움이 되지 않는 게 사실이다.
IETF
그리고 이제 IETF가 있다. 현재 시스코의 수잔 톰슨과 주니퍼의 스티븐 한나가 공동 회장을 맡고 있는 NEA BoF는 워크그룹 상태가 되기 위해 노력 중이다. 이 조직의 첫 목표는 NAC 컴포넌트들간의 커뮤니케이션에 필요한 조건을 규정한 다음, 기존의 프로토콜을 통합하거나 새로운 프로토콜을 개발한다는 것이었다.
과연 유효할까
사용 가능한 모든 프레임워크들 가운데 CNAC만이 상호운용성 테스팅 프로그램을 갖고 있다. 우리는 이것이 어떠한 액세스 제어 이니셔티브용으로든 매우 중요한 요소라고 생각하는데, 그 이유는 프로토콜이 일치해야 기본적인 수준의 상호운용성이 보장되기 때문이다. 표준이 만들어지고 그룹들의 합의를 얻으면 다른 그룹들에 의해 이행이 된다.
물론 주어진 표준이 얼마나 전문적으로 만들어지느냐에 관계없이 개발자에게는 많은 해석의 여지가 남게 된다. 두 업체가 표준을 쓰고 이들이 심지어 같은 업계에 종사한다 하더라도, 이들의 제품이 함께 잘 작동한다는 보장은 없다. 따라서 상호운용성 테스팅이 필요하다.
결정의 시간
NAC 시장이 윤곽을 드러내면서 업체들의 과장법에 익숙한 사람들도 놀랄 정도로 엄청난 힘이 자리잡기에 쏟아 부어지고 있다. 중소기업에서 글로벌 기업에 이르기까지 모든 사람을 대상으로 하는 NAC 시스템이 여러 업체들로부터 나오고 있으며, 이들은 각각 폭넓은 평가, 시행 및 통합 옵션들을 제공한다.
그렇다면 지금 뛰어들어야 할까, 아니면 오는 12~24개월 동안 인수, 합병 및 자연 감소로 인해 발생할 불가피한 통합과 표준, 프레임워크 등에서의 지각변동을 좀 더 지켜봐야 할까?
모바일 인력을 두고 있거나, 네트워크로 계약업체나 게스트가 액세스하는 일이 잦은 회사들은 현재 NAC의 혜택을 볼 수 있다. 바로 이 두 가지가 가장 큰 위협을 대표하는 것들이기 때문이다. 하지만 게스트와 모바일 컴퓨터가 대표하는 문제를 해결할 수 있다면(즉 네트워크 분할을 통해) 시장과 표준이 합체되기를 기다리는 게 효과적이다. 순서대로 NAC를 배치할 계획을 세울 수 있는 시간을 벌게 되고, 표준은 그동안 진보할 것이며, 업체들은 제품을 통합하는 쪽으로 갈 확률이 높기 때문이다. 이제 이 기술의 현재 상태를 살펴보기로 하자.
