필요한 기능의 제품 선택과 부작용 확인은 필수 NAC(Network Access Control)는 태동한지 5년의 시간이 지나면서 제품의 구현 복잡성, 기존 솔루션과의 중복 문제 및 상대적 고비용 투자, 투자 대비 효과 문제(실효성), 설치의 복잡성, 표준화 난항, 구축기간 과다 등의 시장의 한계 상황을 차츰 차츰 극복해오며 진화하고 있다. 최근 다양해지는 네트워크 보안 위협에 대비해 조금 더 효율적으로 NAC 제품을 선택하고 구축할 수 방법은 무엇일까?

2003년 1월 25일, 새해부터 대한민국의 네트워크 전체를 마비시켜 버렸던 추억들을 독자들은 기억할 것이라 믿는다. SQL-Overflow Worm은 MS SQL 서버의 취약점을 이용하여 전파되었으며 1월 25일 14시 10분경 미국, 호주 등을 통해 국내로 유입되어 14시 25분 몇몇 회선의 과부하 현상이 발생됐고 16시경 각 ISP는 웜이 유입되는 UDP 1434번을 차단하면서 진정되기 시작됐다.
이 1.25 대란은 경계선 보안제품(Perimeter Security)의 한계성 표출과 Contents Security로 시장이 넘어가는 시금석이 되었고 이로 인한 제품들이 탄생했는데 그것이 L7 스위치, PMS(Patch Management System), NAC(Network Access Control) 등이다. NAC 시장은 NAC가 태동한지 5년의 시간이 흐르면서 제품의 구현 복잡성, 기존 솔루션과의 중복 문제 및 상대적 고비용 투자, 투자 대비 효과 문제(실효성), 설치의 복잡성, 표준화 난항, 구축기간 과다 등의 시장한계상황을 차츰 차츰 극복하면서 현재까지 흘러오고 있다. 여기서는 NAC 제품이 가지는 제품의 모순(제공기능과 구현방법)를 알아보고 어떻게 하면 효율적인 NAC 구축과 선택이 가능한지를 짚어보겠다.
그렇다면 현재 NAC 시장은 어떤가? NAC은 너무 포괄적인 의미를 갖기 때문에 이를 재해석하자면 Network Security로 보아야 한다는 것이 필자의 생각이다. 1.25 대란 이후의 패러다임(Paradigm)의 변화는 경계선 보안제품에서 네트워크보안(PC, 네트워크)로 보안개념이 컨텐츠쪽으로 내려왔다는 뜻이기도 하다. 이는 NAC라는 커다란 우산아래에서 각 벤더마다 각양각색의 솔루션을 제공하고 또한 각 제품마다 다양한 형태의 Security Layers 서비스를 제공하는 것이다.

◆ Security Layers
● 사용자 인증(Authentification)
● 침입탐지 및 차단(Intrusion Prevention)
● IT 자원 접근 제어(Resource Access Control)
● 단말 무결성 확보(Endpoint Security)

또한 지니네트웍스가 보유한 80여개 고객사에서 당사 제품 Genian NAC를 사용하는 패턴과 기능은 정말 제각각이다. 이를 당사 엔지니어의 방문을 통해서 설문조사를 해 본 결과, 이는 고객사마다 적용되는 정책의 다양성, 특정 솔루션 정책과 중복되지 않는 기능 구현, 다양한 보안 세부 기능들을 어떻게 구현하고 강력한 보안정책을 구현하면서도 사용자 편이성이라는 두 마리 토끼를 잡아야 할지를 고민하고 있기 때문이며 결국 적당한 사용자, 그렇지 않은 사용자가 관리되거나, 관리되지 않은 장비를 통해서 행해지는 네트워크 공격과 위험을 방어하기 위한 솔루션을 고객들은 원했던 것으로 분석이 됐다.
결국 각각의 NAC솔루션들이 제공하는 기능과 서비스는 다양하지만 관리자는 Acceptable한 Cost(적정투자비용) 내에서 IT비즈니스 환경에 필요·적합한 요소를 결정해야 하는 것이다.
고객 자신이 처한 현실을 정확하게 파악하고(보안 위협 분석) 이를 통해 어떤 제품·기능이 자사 현실에 적합한 것인지를 판단하면서도 구현의 복잡성, 장애요소 내포, 투자의 적정성까지를 판단해야 하는 시장 제품인 것이다.

NAC 구현의 다양한 형태들
● Enforcement Type별 구현 형태
보안기능 강제화를 네트워크 어느 포인트에서 하느냐를 Enforcement라고 하는데 이 위치가 어디냐에 따라서 상기와 같이 분류한다.
또한 문제는 접근통제의 대상은 각각의 단말(Endpoint)이며 관리하는 단말, 보안 정책이 위배된 단말 등에 대한 접근통제, 단말 무결성 검증 이후 무결성에 만족하지 않은 단말에 대한 처리 방법 등에 대해서는 주로 단말기 평가를 어떠한 형태로 구현하는 가에 따라서 아래와 같은 구현 방법이 있다.
● 단말기 평가에 관련된 구분
Persistent Agent : 기 설치된 Agent에서 단말 평가 수행 Dissolvable Agent : Java나 Active-X 로 만들어지며 단말 평가 필요시만 수행되는 형태 Remote Procedure Call : 원격서버에서 RPC를 이용하여 단말 안정성 평가 Vulnerability Scan : 네트워크 스캔을 통해서 OS와 Service, 취약점 평가수행 Passive Monitoring : 네트워크 모니터링 및 행위로 이상행위 탐지 특정 벤더는 하나의 Agent 형태만 제공하는 경우도 있고 두 가지 이상의 방법을 사용하는 경우도 있어서 각각의 장단점 부분도 꼼꼼히 검토를 해봐야 한다.

표준화의 부재, 끝없는 기술 논쟁
● 802.1x Vs non 802.1x
원래 802.1x 기술은 Port Based Authentication을 구현한 기술로 표준화된 Protocol이고 또한 네트워크단의 최종 말단 스위치(End Point와 접속되는) 및 무선 AP(Access Point)에서 사용자 인증을 통해 접근을 제어하는 기술이다. 이는 사용자 인증(신분확인)을 목적으로 구현된 프로토콜로서 다른 Enforcement 타입과 혼용해서 사용할 수 있으며 타 인증 솔루션 혹은 접근 보안 기술보다는 상당히 Secure하고 물리적 전기적인 통제가 강하다는 것이 강점이기도 하다.
다만 단말에 Supplicant(인증프로그램)이 반드시 설치되어야 하고 인증을 받은 후에만 비로써 IP 통신을 할 수 있다는 문제로 신규접속 사용자의 Supplicant 배포 문제(없는 경우 통신자체가 안됨), 지원되지 않는 단말에 대한 통제 문제, 하나의 특정포트를 막는 것이 그 포트 하단의 Non 802.1x 스위치 전체를 차단하게 되는 Multi Authentication이 넘어야 할 숙제이기도 하다.
따라서 이 기술구현에서는 아래와 같은 사항들을 고려해 구축 및 선택해야 한다.

네트워크 스위치와 End Point 단말 전체가 802.1x를 지원하는가? Heterogeneous Network인가? Multiple Network Vendor 사용시 적용성 문제(각각의 벤더마다 지원하는 Scope 및 기능에 아직까지는 차이가 있음) IP Phone 사용 계획이 있는 경우 무선 단말기들이 많이 존재하는가?(Blackberry Phone, IP Phone, PDA 등) ● Agent vs Agentless 선택의 문제인가, 기능의 문제인가
그림 4의 기능 비교에서도 나타나듯이 Agent 설치시 강력한 기능을 확보할 수는 있으나 단말의 장애 요소를 내포(Kernel 충돌로 인한 Blue Screen 문제, 장애시 반드시 On Site 해야 하는 Cost 문제)하고 있으며 Agentless의 경우는 상세한 평가에 대한 한계성과 PC 방화벽으로 인해 정확하게 판단하지 못하는 문제가 있다.
여기서의 고려사항은 Agent에 대한 동작 부분 및 그 실효성에 대한 이해이다. Agent의 다양한 형태에 대해서는 단말기 평가에 따른 분류에서 설명을 하였지만 조금 더 정리를 해보자면 다음과 같다. 이러한 부분들이 적용 전에 반드시 고려할 요소 중에 하나이다.

Persistent Agent with Self Enforcement : PC 방화벽 혹은 IDS에 탑재되어 동작되는 경우 Dissolvable Agent : 필요시에만 단말에 설치되어 무결성 및 단말 평가를 수행하고 네트워크 스위치나 Out-of-band Appliance, 방화벽, 인라인 제품에서 Enforcement를 하는 경우 비 Windows 계열의 Endpoint가 다수를 차지하는 경우의 적용성(충돌, 추가 개발 등)의 문제 PC Client의 Credential한 정보를 중앙의 AD(Active Diretory)나 LDAP(Lightweight Directory Access Protocol)에 설치하고 이를 통해서 정보를 받아오는 경우는 어떤 Agent를 사용해야 하는지Guest 등의 외부 방문객이 빈번히 접속되는 네트워크에서 Agent의 배포·삭제 등에 대한 문제를 어떻게 해결할 것인지 ● In-Line VS Out-of-Band 
Enforcement 포인트를 어디냐 두느냐에 대한 논란은 현재도 미래도 끊임없이 이어질 것으로 보이며 그 중에서 보면 In Line 기반의 NAC인가, Out of Band의 NAC인가는 정말 양날의 칼이라 할 수 있다.
In Line NAC의 경우는 주로 네트워크 Edge 스위치와 Distribution Layer 사이에 주로 배치하며 Traffic Flow에 위치하기 때문에 장비의 고속 패킷 처리 능력이 상당히 중요한 기능으로 검토 되어야 하고 비정상 트래픽 탐지 즉 Post Connect에 유리한 구성이다.
반면에 Out of Band NAC의 경우는 네트웍의 구성 변경이 없이 스위치의 일반 Port 혹은 Mirroring Port를 통해서 NAC 제품을 연결하는 구성으로서 MAC 주소를 이용한 제어, DHCP, VLAN steering 등 각 벤더마다 동작하는 방법이 고유하다. 주로 Backbone 스위치에 한 대를 연결해서 구성하는 경우가 대부분이며 지니네트웍스의 지니안 NAC와 같이 Distribution Layer에서 제어하는 방식도 존재하고 있다.
따라서 네트워크 구성이 3-Tier 구조인지 2Tier 구조 인지, NAC Appliance의 설치 대수와 환경에 따라 투자비용이 상당히 증가하는 경우가 발생하며 배치위치에 따라 고려해야 할 성능과 제어범위의 차이가 발생하고 제품의 장애시 발생되는 파급효과 및 대비책도 반드시 점검해야 한다.

NAC 도입전 고려사항
이제 여러 가지 NAC 제품의 동작 구조 및 구현 환경에 대한 이해가 끝났다면, NAC 제품 도입을 위한 절차를 알아보자. 제일 먼저 해야 할 일은 지피(知皮)를 했으니 지기(知己)를 해야 한다.
Wished List의 작성이 첫 번째 프로젝트의 시작이다. NAC 제품은 앞에서 보았듯이 매우 다양한 레이어에서 다양한 형태의 기능을 제공한다. 이런 모든 기능을 사용하고 적용하는 것이 최선은 아니다. 여러분 자신과 IT 운영팀, 보안팀의 네트워크 위험을 줄이기 위해서라도 반드시 정의해야 할 부분이 여러분이 필요로 하는 NAC의 기능이다. 또한 분명히 여러분이 만든 Wished List와 다양한 제품의 기능을 비교해보면 분명히 100%는 아니지만 90% 이상의 요구사항을 만족하는 솔루션이 반드시 있을 것이다. 분명 명심해야 할 것은 MUST HAVE가 많아지면 비용과 복잡도가 증가한다는 사실을 명심하길 바란다.
다음 내용은 Wished List의 일례를 들어 설명한 것이다.
두 번째는 투자비용 대비 보안기능 확보 문제를 검토해야 한다. 
먼저 투자비용이라고 하는 부분에서 우리가 이해해야 할 것은 도입비용 이외에도 운영비용, Help Desk 비용 등을 모두 고려하는 것이 순서라 생각된다. 통상적으로 NAC 솔루션은 단일 보안 솔루션에 비해 고가이다. 또한 Enforcement 형태에 따라 네트워크를 재구성 혹은 Upgrade해야 하는 비용도 발생하며 제조사에 따라서는 Option 품목들이 많이 있는 부분이 있다.
예를 들어 보면 In Line NAC 제품의 경우는 Edge쪽으로 내려갈수록 구매해야 하는 수량이 증가하여 도입 비용이 증가하지만 반대로 Security의 강도는 또 그만큼 강해지는 Trade Off가 있기 때문이다.
운영비용 및 사용자 교육비용 측면에서 검토해보면 도입(구축)비용에 비해 산술적으로 측정하기 어려운 항목이지만 (투입인력 및 기간에 대한 산정이 어려움) 반드시 산정해보고 고려해봐야 할 항목이다. 또한 전사적인 보안 정책 적용을 위해서 사용자 교육 비용 및 사용자 보안정책 적용으로 인한 업무 생산성 하강 문제 등도 판단해 보아야 할 내용이기도 하다.
또한 Enforcement 형태 중에서 Network Infra NAC의 경우는 교육과 Help Desk 비용이 적게 소요되는 반면에 Host based NAC의 경우 구축비용은 상대적으로 적고 교육과 Help Desk 비용이 많이 소요되며 이는 보안정책강제화(Compliance Check)와 정책의 세밀함에 따라서도 운영비용이 차이가 날 수 있다. 또한 제품별로 위반시에 사용자 안내 방법에 따라서 전체 단말 3,000개의 사용자가 전화가 끊임없이 오는 경우라면 Help Desk 비용도 증가한다고 보아야 할 것이다.
세 번째는 제품 시현이다.

NAC 도입이후 운영에 관련 조언
아울러서 도입이후 운영에 대한 Tip이 있다면 목표는 높게 진행은 주의 깊게해야 한다.
NAC는 궁극적으로 도입한 보안 솔루션 중 가장 강력한 도구가 될 것이다. 그러나 NAC는 솔루션 특성상 사용자의 환경변화를 유도한다. 현재 대부분의 NAC 제품의 제기되고 있는 문제점중의 하나는 관리자에게는 즐거운 NAC(낙, 樂)이지만 사용자에게는 정책위반시 네트워크를 차단하는 고통을 주는 문제로 사용자에게 내가 어떤 정책으로 위반되었는지를 보여줄 수 있는 User Friendly 정책이 필요하며 또한 처음 정책 적용시는 낮은 수준의 보안정책 준수부터 단계적으로 시행 하는 것이 좋다. 이는 일반 사용자들이 보안 환경에 적용할 수 있는 시간(Lead Time) 과 경험이 제일 먼저 필요하기 때문이다.
또한 보안 정책 가이드 부분에서도 줄 수 있는 Tip은 다음과 같다.

초기에는 쉽게 점점 더 강력하게(Keep security policies simple) : 초기에는 사용자와 관리자 모두 NAC 환경에 대한 경험이 필요하다. 최소한의 인증이나 Device의 행위를 감시할 수 있는 정도의 보안수준, 여기에 Guest에 대한 차단을 어떻게 하면 쉽게 할 수 있는지 등을 강구하는 것이 우선이다. Walk-before-run : 초기 운영시에는 ‘모니터링’에 중점을 두고 정책 적용대상은 한 두 곳에 적용해서 사용자들의 반응을 체크한다. 이런 Feedback을 이용하여 점자 적용범위, 보안 수준을 넓혀간다. 중요한 사항 위반시에만 Block하라 : 다양한 보안위반 사항 확인이 가능 하지만 사소한 위반행위를 차단해서 사용자들의 반발에 직면하면 안된다. 격리나 제한은 가급적으로 Critical한 사항에 대해서만 수행하고 나머지는 시스템에서 자동 또는 수동으로 교정할 수 있도록 안내한다. 사용자 예상 시니리오를 작성하라 : 가급적 온라인으로 통신할 수 있는 최소한의 통로를 오픈하거나 사용자가 교정할 수 있도록 유도해야 하여야 한다. 문제는 사용자가 네트워크에서 완전 격리된 이후에 할 수 있는 행위는 오로지 Help Desk로 전화하는 일인 것이다. 지금까지의 NAC 시장은 초창기 시장에서 시작되어 Main Stream, Mass Product화로 전이되고 있다고 보아도 과언이 아니다. 이는 혼재된 제품 구현 기능, 각양 각색의 동작방법, 그에 따라 제공되는 기능리스트의 확인, 이를 이해하지 못한다면 NAC 구축 및 도입 프로젝트는 분명히 산으로 갈 것이다. 반드시 자기가 원하는 NAC 기능과 그에 맞는 제품의 선택 그리고 동작확인, 그에 따른 부작용에 대한 확인 등을 통해서만이 올바른 NAC를 구축할 수 있다.
<글 : 허광진 지니네트웍스 인프라보안사업부 이사(Kevin@geninetworks.com)>

[월간 정보보호21c 통권 제102호 (info@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무전재-재배포금지>