'접근제어' 태그의 글 목록

728x90

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

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

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요소들과의 호흡을 중요하게 고려하지 못하고, 별도의 새로운 단일 제품만으 로 모든 문제를 해결할 수 있다고 접근하는 제품과 회사를 경계해야 할 것이다.

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