hi.pe.kr 날으는물고기·´″°³о♡

개인정보보호의 필요성에 따라 데이터베이스 보안 구축이 중요한 과제로 인식되면서 관련 제품 도입이 활발히 이루어지고 있다. 하지만, 현재까지 많은 도입 사례에도 불구하고 실제 안정적으로 적용되어 운영되는 사례는 놀랍게도 드물다. 여기에는 어떠한 문제점이 있는지 살펴보고, 오라클 데이터베이스 보안 솔루션은 이를 어떻게 극복할 수 있는지에 대해 설명하고자 한다.

개인정보보호와 관련된 흐름

2008년부터 2010년 최근까지 국내에서 발생한 주요 개인정보 유출 사고의 내용을 <표 1>을 통해 확인할 수 있다. 해외의 경우와 마찬가지로 국내에서도 대규모개인정보 유출 사고를 겪으면서 기업들에게 보안 강화 조치를 의무화할 수 있는규제준수 법안(Compliance)의 필요성이 대두하였다.

그 결과로 2009년 1월 28일[정보통신망 이용 촉진 및 정보보호 등에 관한 법률(정보통신망법)]이 개인정보 보호와 관련된 강화 조치를 주요 내용으로 하는 형태로 개정되고, 올해 1월 28일부터는 본격적으로 시행되어 대부분의 기업이 적용받게 되었다. 최근에는 이법률에 근거하여 고객정보 유출 사고에 책임이 있는 기업의 대표이사가 처음으로 형사 입건되는 사례도 발생하였다. 이처럼 정보통신망법의 개정 및 시행을 통해 최소한의 제도적인 장치는 마련되었다고 볼 수 있다.

하지만, 국내의 개인정보 유출 사고는 피해 규모가 해외 사례보다 상당히 심각하기 때문에 보다 강력한 규제준수 법안의 도입이 진행되고 있다. 미국의 Sarbanes-Oxley(SOX)법안처럼 모든 산업 부문의 기업들에게 보안 강화를 의무화하고 강력한 처벌을 할 수 있는 내용을 담고 있는 국내의 “개인정보보호법”이 국회에 제출되어 있다.

또한, 해외의 HIPAA, PCI/DSS, Gramm-Leach-Bliley 등과 같이 국내에서도 산업 부문별로 별도의 보안 관련 법안들이 준비중에 있다.

이처럼 개인정보보호를 위한 기업 규제준수 요구 수준은 갈수록 더욱 강화될 것임이 틀림없다.

<표 1> 국내 보안 유출 사고 사례(2008년부터 2010년 초까지)

데이터베이스 보안의 중요성

대규모 개인정보가 유출된 사고가 발생한 시스템의 운영 상황을 점검해 보면, 네트워크 및 서버 보안 등의 기존 보안 조치만으로는 이러한 사고를 막을 수 없다는 결론을 얻을 수 있다. 통계적으로 보더라도 이들 사고의 70% 이상이 방화벽 내부에서 발생하였고, 그중에서 90%가량이 정당한 권한을 가지고 있는 내부자에 의한 소행이었기 때문이다. 따라서 이러한 상황에서 데이터를 실제 저장 및 관리하는 데이터베이스 서버에 대한 별도의 보안 조치는 시급하고 중요한 문제이다.

개인정보보호를 위한 규제준수 법안에 기술되어 있는 조치 내용도 대부분 암호화, 접근제어, 감사와 같은 데이터베이스 보안 강화와 관련된 내용이다.

데이터베이스 보안 제품의 문제점

데이터베이스 보안 시스템을 구축하기 위해서는 먼저, 많은 제품을 검토하고 그 가운데에서 적합한 제품을 선정하는 일이 중요하다.

하지만, 현재 대다수의 고객이 이 과정을 올바르게 수행하지 못하고 있다. 따라서 본 기사를 통해 그동안 고객들에게 정확하게 전달되지 못했던 데이터베이스 보안 제품의 문제점들을 파악할 기회를 제공하고자 한다.

암호화

타사 암호화 제품의 문제점을 분석하기 위해서 암호화 수행 방식을 살펴보자. 먼저, <그림 1>과 같이 암복호화 API를 응용 프로그램 소스 코드에 적용하는 API 방식이 있다. 이 방식을 위해서는 먼저 암호화된 내용을 수용하기 위해 더 긴 길이의 컬럼으로 구조를 변경해야 한다. 그리고 일부 SQL문장의 로직과 성능에 문제가 발생할 수도 있기 때문에 응용 프로그램에서 사용하고 있는 모든 SQL문장을 사전에 조사해야 되고 그 결과로 SQL수정 등의 작업이 발생하기도 한다.

이처럼 API방식의 암호화는 응용 프로그램 소스 코드에서의 작업을 필요로 하기 때문에 많은 시간이 소요된다.(6개월에 걸쳐 4,000여 개의 프로그램을 수정하면서 20억의 예산이 소요된 사례가 있음) 이번에는 트리거(Trigger)가 암복호화 API를 호출해 자동 암호화를 수행하는<그림 2>와 같은 Plug-in방식이 있다.

데이터베이스 서버에 암복호화 API와 트리거를 생성하기 때문에 이를 Plug-in방식이라 부른다. 이 방식은 트리거를 이용해 자동 암호화를 하도록 설계되어 있지만, 트리거는 실제 INSERT, DELETE, UPDATE에 대해서만 동작한다. 따라서, SELECT에 대해서는 이미 암복호화 작업이 포함된 정의의 뷰(View)를 도입해야 된다.

결국, 최초 원본 테이블 대비 많은 구조 변경이 발생한다. 이러한 구조 변경은SQL기능 제약을 유발하는 문제점이 있다. 또한, 대량의 데이터 작업 시에 레코드 단위로 암호화를 위한 트리거가 동작하기 때문에 심각한 성능 저하가 발생한다. Plug-in제품들은 이와 같은 기능 제약과 성능 저하 문제를 위해 SQL 재작성, 수정 및 튜닝등의 과정을 필수적으로 수행한다. SQL문장이 응용 프로그램 소스 코드에 대부분 포함되어 있기 때문에, SQL문장에 대한 작업은 곧 응용 프로그램 수정을 의미한다.

그럼에도 불구하고, Plug-in제품이 응용 프로그램 수정을 유발하지 않는다고 주장하는 것은 잘못된 것인 만큼 고객들의 주의가 필요하다.

타사 암호화 제품이 제공하는 이러한 두 가지 방식은 많은 문제점들을 안고 있다. 각각의 내용을 살펴보자.

<그림 1> API 방식의 암호화

<그림 2> Plug-in방식의 암호화

심각한 성능 저하

트리거에 의존하는 Plug-in방식의 경우, 특정 암호화 벤치마크테스트(BMT) 과정에서 최대 850%의 오버헤드를 유발하는 것으로 측정된 바 있다. 예를 들어, 1시간이 걸리던 배치 업무가 8시간 반이 소요된다는 의미이다. 이 같은 심각한 성능 저하는 일 별 배치 처리와 같은 자동화 업무의 근간을 흔드는 것이다. 따라서, 반드시 검토 대상인 암호화 제품의 성능 오버헤드를 사전에 측정해 보아야 한다.

기능 제약 발생

타사 암호화 제품은 Update가 가능한 뷰를 사용하고 Domain Index라는 기능을 이용해 비표준 전용 인덱스를 구현해 사용하고 있는데, 이럴 경우 <표 2>와 같은
기능 및 성능상의 제약이 발생한다.

응용 프로그램 변경 필요

응용 프로그램 변경이 발생하는지의 여부는 암호화 적용을 위한 중요한 사전 고려 사항이다. 앞서 타사 암호화 제품의 두 가지 방식은 모두 응응 프로그램 변경이 반드시 필요함을 설명한 바 있다. 하지만 많은 고객은 응용 프로그램 수정이 전혀 불가능한 상황임에도 불구하고 이러한 상황을 지원하지 못하는 API방식 혹은 Plug-in방식을 검토하는 경우가 있다. <그림 3>을 통해 자세히 설명해 보자. 그림에서 X 축은 프로젝트의 단계를 나타내고, Y축은 도입의 형태를 나타낸다.

이때, 암호화 적용을 고민하고 있는 고객 응용 프로그램 유형은 대부분 C1혹은 C2에 해당하는 경우가 많다. 다시 말해, 외주 개발을 한 뒤 유지 보수가 만료되어 사소한 수정이 필요하더라도 재계약을 통해 다시 아웃소싱을 해야 되는 상황(C1), 자체 개발을 하였지만 최초 개발자의 투입이 불가능한 상황(C2)이 가장 많이 볼 수 있는 유형이다. 거듭 강조하지만 이런 경우의 고객들은 API방식 혹은 Plug-in방식의 암호화 제품을 검토해서는 안된다. 결론적으로 오직 커널 방식의 자동화된 암호화 방식만이 응용 프로그램 변경이 필요 없는 해결책임을 말하고 싶다.

인덱스 암호화 방식의 안정성 문제

암호화의 기본 원리 중 하나는 ‘암호화 전의 값이 가지고 있던 대소 관계까지도 없어진다.’는 것이다. 이 사실 때문에 암호화 컬럼 값에 인덱스가 생성되어 있어도 범위 검색(Range Scan) Query에 대해서는 인덱스를 이용하지 못하고 부득이 전체 검색(Full Scan)하는 문제가 있었다.(인덱스 검색을 위해서는 대소 비교가 가능해야 한다.) 이 부분을 극복하고자 일부 암호화 제품들은별도의 인덱스 방안을 고안해 냈다.(자세한 내용은 관련 제품의 특허 출원 내용을 특허청 홈페이지를 통해 다운로드 받아 확인할 수 있다.)

하지만, 문제는 이들 제품이 인덱스 생성 과정에서 재 암호화라는 단계를 통해 기존의 암호화 방식이 아니라 새롭게 고안해 낸암호화 알고리즘을 적용해 대소비교가 가능하도록 했다는 점이다. 그러나, 암호화의 원리를 떠올린다면 대소비교가 가능한 암호화 결과라는 것은 모순이다. 상식적인 얘기지만 대소비교를 통해 정보가 역으로 추론될 수 있는 위험성이 존재한다. 또한, 이러한 암호화 알고리즘은 국내외에서 전혀 검증되지 않았다는 점을 분명히 밝히고 싶다. 데이터 파일에 적용되는 암호화 알고리즘뿐만 아니라 인덱스에 적용하는 알고리즘 모두 객관적으로 검증된 것이 사용되어야 한다. 그렇지 않다면 안전한 암호화 알고리즘을 사용하도록 한 정보통신망법의 규정에 심각한 결격사유가 된다.

<표 2> 타사 암호화 제품의 기능 및 성능 제약

<그림 3> 응용 프로그램 유형별 적용 가능한 암호화 방식

접근제어방식

타사 접근제어 제품의 문제점을 분석하기 위해서 이들이 제공하는 접근제어 방식을 살펴보아야 한다. 먼저, <그림 4>에 나타난 것과 같이 스니핑(Sniffing) 방식이 있다. 데이터베이스 서버로 전달되는 SQL트래픽을 별도의 보안 서버에서 모니터링하면서 문제가 되는 SQL작업이 있으면 Kill Session 등의 수단으로 해당 세션을 강제 종료하는 방법으로 접근제어 기능을 수행한다. 하지만, 이러한 접근제어가 결국 SQL레벨이 아니라 세션 레벨로 동작한다는 점과 모니터링을 위해 별도의 네트워크 Tap장비가 필요한 단점이 있다. 무엇보다 현재 시장에서 요구하는 접근제어의 많은 기능이 스니핑 방식만으로는 불가하다는 한계를 가지고 있다.

스니핑 방식 이후, 보다 적극적인 접근제어 동작을 위해 게이트웨이(Gateway) 방식이 도입되었다. <그림 5>와 같이 별도의 보안서버로 모든 SQL트래픽을 전달받아 분석한 뒤에 문제가 없을 경우에만 데이터베이스 서버로 전달하는 방식이다. 이 방식을 통해 문제가 되는 SQL작업이 원천적으로 데이터베이스 서버로 전달되지 않도록 할 수 있지만, 게이트웨이 방식을 지원하는 대부분의 제품은 모든 SQL트래픽을 받아 처리하면서 발생하는 부하를 제대로 감당하지 못하는 문제가 있었다.

마지막으로, 스니핑과 게이트웨이 방식의 문제점을 극복하기 위해 두 가지 방식을 혼합한 <그림 6>과 같은 하이브리드(Hybrid) 방식이 현재 접근제어 방식의 주류를 이루고 있다. 응용 프로그램으로부터 전달되는 SQL트래픽은 일단 데이터베이스 서버로 전달하고 관련 내역은 스니핑을 통해 보안 서버에서 감사만 수행하고, 일반 사용자들의 데이터베이스 접속과 SQL요청 작업은 모두 보안서버에서 검사한 뒤에 문제가 없을 경우에만 전달하는 방식이다. 이를 통해 주로 문제가 되는 일반 사용자들의 세션에 대한 접근제어 기능은 강화하고 과부하는 줄이는 효과를 얻을 수 있다.

타사의 접근제어 제품들은 대부분 스니핑 방식에서 출발하여 게이트웨이 방식을 지원하기 시작했고, 나중에는 하이브리드 방식을 표방하는 순서로 옮겨왔다. 이제까지 살펴본 접근제어 방식들은 나름의 노력에도 불구하고 여전히 치명적인문제점을 안고 있다. 그 내용을 지금부터 하나하나 설명하고자 한다.

우회 접근을 통한 정보 유출의 위험성 존재

타사의 접근제어 제품은 데이터베이스 서버 외부에서 접근제어 기능을 수행한다. 결국, 접근 차단 대상 테이블 정보를 데이터베이스 서버 외부에서 목록으로 관리하면서 SQL을 검사할 때 살펴보는 방식이다. 하지만, <그림 7>에 나타난 상황과 같이 아무리 접근 차단 대상 테이블을 관리해도 데이터베이스 서버에서 해당 테이블에 대한 뷰(View), 동의어(Synonym), PL/SQL, Dynamic SQL 등의 우회적인 수단을 만든 뒤 접근을 시도하면 외부 접근제어 제품은 차단 대상 목록에 포함되어 있지 않기 때문에 이들 접근을 통제하지 못하고 모두 통과시킨다. 이처럼 간단한 유출 시도로 무력화될 수 있는 치명적인 단점이 존재하는 것이다.

로컬 접근에 대한 통제 불가

또한 Telnet으로 데이터베이스 서버에 먼저 접속한 이후에 SQLPLUS를 실행하는 등의 로컬 접속을 기본적으로 통제하지 못한다. 이러한 문제 때문에 SQLPLUS실행 파일을 래핑(Wrapping)한 모듈을 제공해 실제 사용자들은 모르고 동일한 SQLPLUS프로그램을 실행한 것처럼 사용하지만 래핑 모듈에 추가된 감사 기능을 통해 작업 내용을 기록할 수 있다. 결국 <그림 8>과 같이 로컬 접근 시에는 접근제어 기능을 수행하는 것이 아니라 감사기능으로 대응하고 있는 것이다. 로컬 접근을 통한 정보 유출이 빈번히 발생하는것을 감안하면 이 역시 심각한 문제라고 할 수 있다.

이중화로 인한 추가 비용 발생

타사의 접근제어 제품은 시스템 구성상 보안 서버가 설치될 별도의 하드웨어와 네트워크 Tap 장비 등이 필요하다. 소프트웨어 초기 도입 비용이 비교적 저렴하기 때문에 이러한 추가적인 하드웨어 비용을 감수하는 경우가 있으나 <그림 9> 에서 보듯이 모든 시스템 구성 요소들이 이중화되어야 되는 상황을 감안하면 비용은 예상외로 상당히 증가할 수 있다.

여기까지 타사 데이터베이스 보안 제품의 주요 문제점을 살펴보았다. 이제는 <표 3>과 같이 신문 등을 통해 접할 수 있는 고객들의 도입 피해 사례를 보고 구체적으로 어떤 문제점들이 발생하였을지 짐작할 수 있는 정보가 생겼을 것으로 기대한다.

<그림 4> 스니핑 방식의 접근 제어

<그림 5> 게이트웨이 방식의 접근 제어

<그림 6> 하이브리드 방식의 접근 제어

오라클 데이터베이스 보안 솔루션

이번에는 이러한 많은 문제점을 오라클 데이터베이스 보안 솔루션을 통해 어떻게 해결할 수 있는지를 설명할 순서이다. 결론적으로 타사 제품들의 문제점은 데이터베이스 내부에서 보안 기능을 수행하지 못하기 때문에 발생한 것이다. 따라서, 데이터베이스 내부, 즉 커널에서 보안 기능을 수행함으로써 지금까지 언급된 모든 문제를 극복할 수 있다. 그러므로 오라클이 데이터베이스 보안과 관련해 고객에게 전달하고 싶은 메시지는 ‘데이터를 커널에서 안전히 보호하라(Secure Data at the Source)’이다.

그럼, 오라클이 제공하는 커널 방식의 암호화를 살펴보자. <그림 10>에서 볼 수 있듯이, 디스크에 있는 물리적인 데이터파일과 작업 메모리 공간(SGA) 사이에서 입출력을 담당하는 백그라운드 프로세스(서버 프로세스, DBWR)들이 자동으로 암복호화를 담당한다. 응용 프로그램은 기존과 동일한 테이블 규격에 접근하는 것이다. 그러므로 응용 프로그램 변경은 전혀 불필요하다. 오직 커널 방식을 통해서만 응용 프로그램 변경이 없는 암호화가 가능하다. 그리고, 암복호화 과정이 내부 동작에 포함되어 있어 성능 오버헤드를 최소화할 수 있다. 많은 성능 벤치마크 테스트 과정에서 비교할 수 없는 차이로 가장 안정적인 성능을 나타내는 것으로 이미 입증되었다. 또한, 오라클의 암호화 방식은 일체의 기능 제약을 발생시키지 않는다. 10g 암호화로 인해 발생하였던 일부 제약도 11g에서는 모두해결되어 현재는 암호화로 인한 기능 제약이 전혀 없다.

<그림 7> 하이브리드 방식의 접근 제어

<그림 8> 로컬 접근에 대한 통제 불가

<그림 9> 이중화로 인한 추가 비용 발생

<표 3> 데이터베이스 보안 제품 도입 피해 사례

<그림 10> 커널 방식의 암호화

오라클이 제공하는 접근제어는 <그림 11>에서 보듯이 커널에서 기존 SQL처리 과정의 구문분석 단계에서 추가로 기능이 수행되는 방식이다. 데이터베이스 외부에서 별도의 구분된 과정으로 접근제어 기능이 수행되는 방식에 비해 상당히 오버헤드를 낮출 수 있다. 그리고 오라클 접근제어 솔루션이 제공하는 중요한 점은 특정 객체를 접근제어 대상으로 설정했을 때에는 어떠한 우회접근 수단을 만들어 유출을 시도해도 동일하게 차단할 수 있다는 것이다. 객체 간의 관계를 모두 분석해서 의미상으로 차단하고 있기 때문에 가능한 것이다. 또한 원격 접근, 로컬 접근의 구분 없이 모든 접근에 대해 동일한 접근제어 기능이 적용된다. 그리고 데이터베이스 내부 커널에 추가적으로 설치되어 운영되는 방식이므로 별도의 하드웨어 자체가 불필요하다.

지금 고객에게 필요한 것은 올바른 데이터베이스 보안 제품을 선택하기 위한 명확한 판단 기준이다. 본 기사를 통해 제시한 타사 제품들의 문제점을 심각하게 받아들이고 이를 판단 기준으로 삼기를 바란다.(이러한 문제점들을 알고도 잘못 도입하는 우를 범해서는 안된다.) 그리고 타사 제품의 문제점들이 데이터베이스 내부에서 보안 기능을 수행하지 못해 발생한 것들임을 알게 되었다면, 커널 방식으로 동작하는 데이터베이스 보안 솔루션의 접근 방법이 유일한 해결 방안임도 잊지 말아야 한다.

오라클이 제시하는 데이터베이스 보안 기술이 얼마나 체계적이고 합리적인 방안인가를 설명하기 위해, Forrester에서 발표한 [2010 엔터프라이즈 데이터베이스 보안 전략]을 인용하고자 한다. <그림 12>에서와 같이 이상적인 데이터베이스 보안 구축을 위해서는 본 기사의 서두에서도 주로 다루었지만 하단부에 나타나 있는 규제준수 법안(Compliance) 이슈를 잘 이해해야 한다. 그리고 사전 차단을 위한 Preventive한 수단을 갖추어야 하고, 사후 검증을 위한 Detection메커니즘을 확보해야 한다. 오라클은 Preventive한 수단으로 암호화(Advanced Security, Data Masking, Secure Backup), 접근제어(Database Vault, Label Security) 관련 제품들을 제공하고 있고, Detection수단으로 감사(Audit Vault, Total Recall, Configuration Management) 제품들을 제공하고 있다. <그림 13>에 나타나 있듯이, 각각의 이슈에 대해 통찰력 있는 제품들로 오라클 데이터베이스 보안 솔루 션은 구성되어 있다. Forrester보고서에서 마지막으로 중요하게 언급하고 싶은 부분은 바로 좌측 상단의 Foundation요소이다. 이것이야말로 데이터베이스 보안의 근간을 이루는 기본적인 인프라 요소일 것이다. 우리는 그것이 오라클 데이터베이스에서 제공하는 기본적인 계정 및 권한 관리, 역할 체계, 지속적인 패치 서비스 제공 등의 형태일 것으로 본다. 이러한 Foundation요소와 함께 추가적인 제품 도입을 통해 보강되어야 할 Preventive, Detection요소들이 조화롭게 운영 되어야만 이상적인 데이터베이스 보안 구축이 가능하다는 것이 Forrester보고서의 핵심 내용이다. 자칫 데이터베이스 보안이 이슈가 되는 최근의 상황에서 이러한 Foundation요소들과의 호흡을 중요하게 고려하지 못하고, 별도의 새로운 단일 제품만으 로 모든 문제를 해결할 수 있다고 접근하는 제품과 회사를 경계해야 할 것이다.

본 기사에서 제시한 타사의 문제점들과 피해 사례들은 모두 직접 고객들로부터 전해 듣거나 신문을 통해 확인한 객관적인 사실들이었다. 이 내용을 전달하는 목적은 고객의 올바른 선택을 위한 정보를 주기 위함이었다. 데이터베이스 보안 구축이라는 당면 과제로 고민에 빠져 있는 많은 고객에게 도움이 되었기를 바란다.

<그림 11> 커널 방식의 접근제어

<그림 12> 엔터프라이즈 데이터베이스 보안 시스템 구축 전략

<그림 13> 오라클 데이터베이스 보안 솔루션 구성

출처 : ORACLE KOREA / DBguide.net

UP02060613_NACOverview.pdf

모든 네트워크가 지켜야 할 경계선이죠!

IT 분야는 물론 물리적 보안 시스템까지 네트워크 기반으로 급격히 변화하면서 네트워크를 통한 침입과 정보유출이 심각해지고 있다. 이에 대응하기 위해 NAC(Network Access Control)라는 개념이 등장했고, 최근 들어 IT 보안 분야의 주요 이슈로 부상하고 있다.  

네트워크 가용성

‘Maximize Network Uptime?’ 새롭게 출시되는 네트워크 장비의 홍보 브로셔를 검토하다 보면 흔히 접하게 되는 문구이다. 대부분의 벤더들이 자사의 장비를 도입하는 것이 네트워크의 가용성을 증진시키는데 효과가 있다고 강조하고 있다. 네트워크의 가용성 증대는 네트워크 및 보안담당자들이 최고로 신봉하는 개념이다.

지금까지 수많은 제품들이 네트워크의 가용성을 높이기 위하여 개발·출시됐다. 그리고 IT 관련 기술들이 날로 발전하면서 기존의 솔루션들로는 네트워크의 가용성을 더 이상 확보할 수 없게 되면서 새로운 솔루션들은 지금도 개발이 되고 있다. NAC(Network Access Control)는 이런 과정 즉, 가용성 확보를 위하여 지속적으로 새로운 솔루션을 개발하는 과정에서 생성된 솔루션이다.

경계선 붕괴 및 경계선 보안의 한계

예전의 네트워크 환경에서는 소위 경계선이라는 것이 있었다. 물론 지금도 네트워크에 경계선(내부 네트워크와 외부 네트워크의 접점)이 존재하지만, 경계선의 종류와 수가 증가하면서 특별하게 이곳만 보호하면 된다고 하는 의미의 경계선은 없어졌다.

현재의 네트워크 환경에서 외부 사용자 혹은 외부 데이터(유해데이터, 바이러스, 웜 등)가 내부로 들어올 수 있는 경로는 많다. 무선의 사용이 증가했고, 노트북 이용자가 늘었다. 여기에 이동형 저장장치(USB 등) 사용과 IP를 가진 단말기의 종류가 증가했다.

네트워크를 보호하기 위하여 인터넷과 연결된 접점을 지키고 있는데, 어느 날 외부직원이 작업을 위하여 내방했다. 이 외부직원은 회의실에 나와 있는 네트워크 포트에 노트북을 연결하고 작업을 수행한다. 그 과정에서 외부직원의 노트북에 존재하고 있던 웜은 네트워크 연결과 동시에 내부 네트워크로 번져나간다. 그리고 네트워크 담당자는 네트워크에 문제가 생겼다는 것을 감지하게 된다. 하지만 어떤 경로로 문제 인자가 내부로 유입되었는지는 확인할 수 없다.

예전에는 경계선 보안 제품만 있으면, 모든 침입을 방어할 수 있을 것이라 생각했다. 하지만 지금은 대부분의 사용자들이 경계선 보안 솔루션이 반드시 있어야 하는 제품으로 인식하고 있지만 만능이라고 생각하지는 않는다. 경계선을 침입할 수 있는 새로운 기술들이 개발되고 있으며, 소위 Day-zero(신종)라고 하는 것들이 지금도 자유롭게 경계선을 넘나들고 있다. 세관에 허가되지 않은 물건을 밀수하는 새로운 방법들이 늘어나고 있는 것과 마찬가지의 상황이 온라인상에서도 일어나고 있다.

인증

NAC(Network Access Control)를 우리말로 번역하면 네트워크 접근제어이다. NAC가 접근제어를 위하여 사용하는 방법은 인증이다. 사용자에 대한 인증, 단말에 대한 인증, 트래픽에 대한 인증을 NAC가 수행하게 된다.

앞에서 경계선의 붕괴에 대해 이야기했다. NAC는 모든 네트워크를 경계선으로 본다. 어떤 사용자가 어떠한 경로를 통하여 들어오든지, 사용자 및 단말은 검사를 통과해야 내부 네트워크로 진입할 수 있다. 앞에서 이야기한 내방한 외부직원이 NAC가 설치되어 있는 네트워크에 접근했다고 하면, 네트워크를 사용하기에 앞서 사용자에 대한 인증을 받아야 하며, 사용하는 노트북을 네트워크에 연결해도 안전하다는 검사를 받아야 한다. 또한, 네트워크를 사용하면서 조금이라도 이상한 통신(Traffic)을 수행한다면 이는 바로 NAC에 의하여 감지되어 외부직원의 노트북은 네트워크로부터 격리된다.
 

사용자 인증 및 단말 인증(Pre-Admission)

NAC 솔루션은 항시 네트워크를 감시하고 있다. 이 과정에서 무언가 새로운 단말이 네트워크로 진입하게 되면 이를 감지하고 우선적으로 사용을 차단하게 된다. 그리고는 접근하려는 사용자에게 인증을 요청한다. 인증을 수행하는 방법은 주로 내부에 존재하는 인증 DB와 연동하여 인증을 수행하게 된다. 가령 인사 DB와 연동했다고 하면 사용자는 인사 DB에 있는 사번과 해당 비밀번호를 입력해야 한다.

다음으로 NAC는 단말에 대한 인증을 수행하게 된다. Health Check(상태점검)라는 과정을 통하여 단말의 상태를 점검하게 되는데, 어디까지 검사할 것인지는 네트워크 관리자가 정하게 된다. 주로 확인하는 항목은 단말의 OS(Windows)가 최신 패치인지, 단말에 백신프로그램(Anti-Virus)이 구동되고 있고 최신 업데이트인지, 단말에 최신 업데이트가 된 스파이웨어 프로그램(Anti-Spyware)이 구동되는지, 단말에 Windows 방화벽이 설치되어 있는지 등이다.

앞에서 언급한 주로 확인하는 항목 외에 준수해야 하는 보안정책들이 늘어나면서 진입과정에서 점검해야 하는 단말 점검 목록들은 늘어나고 있다. Windows 화면 보호기가 구동되고 있는지, PC명이 회사의 규칙에 따라 설정되어 있는지, 비밀번호를 단말이 사용하고 있는지, 회사에서 설치를 요구하는 필수 소프트웨어들이 설치되어 있는지, 불필요한 소프트웨어가 설치되어 있는지 등도 점검하게 된다.

이런 단말의 상태점검을 위해서는 단말에 특별한 소프트웨어(Agent)를 설치해야 하는데, 이 Agent의 설치유무에 따라 NAC 제품은 Agent-less와 Agent-base로 구분할 수 있다. 이 Agent는 상태점검 외에 여러 가지 부가기능들을 수행하게 되는데, 제품의 종류에 따라 IP 관리 기능, 매체제어 기능(USB 사용금지, Wibro 사용금지) 등을 수행할 수 있다.
 

네트워크 사용 모니터링(Post-Admission)

사용자 및 단말 인증을 거쳐 네트워크 접속한 단말은 이제 네트워크를 이용할 수 있다. 하지만 자신에게 허용된 범위 내에서만 사용이 가능하다. 사용할 수 있는 범위는 사용자 인증 과정에서 미리 정해질 수도 있으며, 진입한 후에 정해질 수도 있다. 가령 사용자가 네트워크 진입과정에서 외부 협력업체 직원으로 인증을 받았다고 하면, 그 사용자는 내부 네트워크는 사용할 수 없고 인터넷만 사용이 가능하게 사용범위가 제한될 수 있다.

전체 네트워크를 사용할 수 있는 사용자라고 하더라도 정책에 위반되는 통신 또는 유해 트래픽을 발생시킨다고 하면 NAC는 그 단말을 검출하여 네트워크로부터 격리시키는 작업을 수행하게 된다. 이를 위하여 NAC는 내부 네트워크에서 통신되는 모든 트래픽을 감시하는 기능을 가지고 있다. 제품의 종류에 따라 간단한 정책위반을 검사할 수도 있고, 어떤 제품은 단말에 Backdoor가 설치되어 내부의 데이터를 외부로 유출하려는 시도까지도 검출이 가능하다.

또한, 종류에 따라서는 네트워크에서 사용하지 않는 IP 주소를 활용하여 가상의 단말(Decoy : 미끼)을 생성하고, 이 가상의 미끼들이 보안에 취약한 허점들을 공개해 웜 등의 공격을 자신에게 유도하면서 네트워크를 보호하고 웜 등을 발생시킨 단말을 검출하여 격리하는 기능도 가지고 있다.

그림 1에서처럼 NAC는 단말 및 사용자가 네트워크에 진입하는 순간부터 사용을 종료하는 모든 과정에 관여하여 허가된 사용자와 단말만 진입을 허용하고, 허가된 트래픽만 사용을 허가하게 되는 과정을 반복하게 된다.
 

NAC의 종류

현재 국내에서 판매되는 NAC 제품은 외산, 국산을 포함하여 대략 15개 정도의 제품이 있다. 판매되는 제품의 수량이 많은 것도 제품을 선택하는 데 어려움을 주지만 판매되는 제품의 종류(구현 방식)가 많은 것도 담당자가 제품을 선택하는 데 고민이 된다.

NAC의 종류는 Agent의 유무에 따라 크게 Agent-base와 Agent-less로 구분할 수 있으며, 제품을 생산하는 벤더에 따라 Software Vendor의 제품, Switch Vendor의 제품, NAC 전문 Vendor의 제품 등으로 구분할 수 있다. 하지만 이렇게 구분을 한다고 하더라도, 동일한 구분 하에 위치한 제품들의 성격도 조금씩 틀린 경우가 많다. 가령 Agent-base의 NAC 전문 Vendor 제품으로 구분되는 2가지 제품의 특성 및 강점이 모두 다른 경우가 있어 같은 기준으로 평가하기 힘든 경우가 대부분이다.

여기서는 모든 종류의 특성들을 다루기는 어려운 부분이 있어 크게 Agent-base와 Agent-less 제품의 특성 및 구현 방식에 대해서만 설명하도록 한다.
 

Agent-less와 Agent-base

Agent-base의 제품은 말 그대로 단말에 특별한 기능을 가진 프로그램(Agent)을 설치하는 형태의 제품이다. 앞에서 언급했듯이 이 Agent들은 단말에 설치되어 단말의 상태를 점검하게 된다. Symantec의 제품이 대표적이다. Agent-less 제품은 이 프로그램을 설치하지 않으며, MirageNAC가 대표적인 제품이다.

Agent를 설치하는 제품의 경우 단말의 상태 점검에 강점을 가지고 있으며, Agent-less 제품의 경우 Post-Admission(트래픽 모니터링)에 강점을 가지고 있다. Agent를 설치하고 설치하지 않고의 선택은 네트워크 상황과 함께 현재 네트워크 상에서 필요로 하는 기능이 무엇이냐에 따라 결정하게 된다.

우선 상황을 검토하게 되는데, 기존 단말에 설치되어 있는 Agent들의 종류 및 기능을 확인하게 된다. 기존에 설치되어 있는 Agent의 수량이 너무 많고, 설치되어 있는 Agent들이 단말의 상태점검 기능을 가지고 있다고 하면 Agent-less 제품을 사용하는 것이 설치 및 유지보수적인 측면에서 효과적이다. 물론 도입하려는 Agent-less 제품과 기존에 설치되어 있는 Agent와의 연동에 문제가 없는지를 확인해야 한다. 하지만 설치되어 있는 Agent가 별로 없고 기능이 중복되지 않는다면 Agent-base 제품의 사용이 효과적일 수 있다.

기능적인 측면에서 보면 Agent-base의 제품은 단말 상태 점검에 강점이 있고, Agent-less은 유해 트래픽 탐지를 포함한 트래픽 모니터링에 강점이 있다. 이로 인해 네트워크가 최근에 유행하고 있는 스푸핑(Spoofing) 공격 및 각종 유해 트래픽으로 인해 문제가 된다고 한다면 Agent-less 제품의 도입을 권장하지만 상태점검이 우선시 되는 조직의 경우 Agent-base의 제품 도입이 좀더 효과적이다.
 

NAC 도입을 결정하기 전에

Agent-base 제품이던 Agent-less 제품이던 완벽한 제품은 없다. 하지만 완벽성을 높일 수는 있다. 제품의 완벽성을 높이기 위해서는 제품도입을 결정하기 전 현재 네트워크 환경과 필요에 부합되는 제품을 도입하고, 기존 솔루션들과의 적절한 연동을 수행하는 방법을 강구해야 한다. 보안 솔루션 및 네트워크 솔루션들이 다양화되면서 이러한 통합의 중요성이 더욱더 커지고 있다. 사실 NAC 솔루션은 단독으로 동작할 때보다 적절하게 통합될 때 더욱 효과적인 솔루션이라고 할 수 있다. 가령 NAC는 단말을 네트워크로부터 격리하는 기술을 가지고 있다. 이 기능을 다른 솔루션들과 통합하는 경우 IPS는 물론 NMS, SMS와 통합이 가능하다, 이를 통하여 IPS가 모니터링 하는 과정에서 내부에서 외부로 이상한 트래픽을 발생시키는 단말이 있다고 하면 IPS는 이를 NAC에 통보하여 차단이 가능하게 된다. NMS와 연동하면 NMS로 장애 로그가 발생한 단말을 NAC가 차단할 수 있다.

모든 제품이 마찬가지지만 NAC가 목적으로 하는 것은 정책기반의 네트워크 구현을 통한 네트워크 가용성 확보에 있다. 현재까지의 구현사례들은 NAC가 그 목적에 부합되는 제품이라는 것을 증명하고 있다. 이로 인해 2009년에는 더욱 많은 기업들이 NAC를 도입할 것으로 보인다.