DB암호화는 가장 강력하고 근본적인 보안 방법이지만, 솔루션 선정에는 신중해야 한다.
 
보안을 농구 경기에 비교한다면 공격수는 수비수를 따돌리기 위해 다양한 루트를 이용해 바스켓에 공을 넣으려 한다. 보안에서는 공을 넣는 대신 자료를 빼가려 한
다는 것만 다를 뿐, 나머지는 똑 같다고 볼 수 있다.
 
즉 공격자는 수비를 따돌리는 새로운 방법을 계속 연구해내고 방어를 하는 수비자는 이에 대응하는 방어방법을 만들어야 한다.(항상 공격자는 먼저 새로운 테크닉을 생각하고 수비자는 항상 나중에 대처방법을 생각한다.)
이것을 보안에 적용하면 해커는 항상 보안 툴이 가진 새로운 보안 취약성을 알고 있기 때문에 이런 방어체계를 뚫고 DB에 접근할 수 있다. 더구나 아군이 자살 골을 넣으려 한다면 이런 방어체계 자체가 아무런 소용이 없다. 하지만, 외부 침입자는 물론 내부자가 DB전체를 들고 나간다 하더라도 권한이 없으면 암호화된 데이터는 영원히 볼 수 없다. DB암호화를 하는 이유가 바로 이것 때문이다. 가장 확실하고 강력한 보안 수단이기 때문이다.
 
                

                                 그림. DB암호화 구조도

 
사례를 통해 본 데이터 유출 사고의 심각성
데이터 유출사고는 국민적 지탄은 물론, 기업의 존립 자체가 위협을 받는 아주 심각한 상황을 초래한다.  많이 알고 있는 이야기지만 내부자에 의한 데이터 유출은 발생 빈도는 높지 않지만 일단 발생하게 되면 그 피해액은 이루 말할 수 없을 정도로 크다. 한국산업기술진흥원의 조사 자료에 의하면 자료유출의 약 70%가 내부자에 의한 소행이다. 더구나 최근에는 우리나라 여권이 아주 많은 나라와 비자면제 협정이 되어 있는 점 때문에 중국의 해커들로부터 여권위조 등의 목적으로 개인정보 유출 시도가 끊이지 않고 있는 실정이다. 게다가 첨예한 경쟁상황에 처해 있는 제조업의 경우 도면 등의 기술자료 유출사고도 내부자에 의해 빈번히 발생하고 있다.
주지하다시피 옥션의 고객정보 DB유출 사고로 인한 법정 소송이 본격화 되었으며 이로 인한 기업의 피해액은 리니지 사고 때의 예로 비추어 보건 데 1인당 50만원씩 배상하게 되면 수 조원에 육박하게 될 것으로 전망된다. 만일 DB의 개인정보를 암호화해 놓았다면 당사자들 모두 지금처럼 심각한 상황에 처하지는 않았을 것이다. 비밀번호만 암호화해 놓는 것은 이 같은 사고에서는 도움이 안 된다. 비밀번호야 바꾸면 되지만 그 사람들의 목적은 유출된 주민번호 등의 개인정보로 2차 범죄에 이용할 것으로 예상되기 때문이다.
또 얼마 전에 일어난 모 조선 회사의 도면 유출로 인한 피해액이 5천억원으로 예상 된다고 한다. 게다가 최근 한 LCD 제조사의 생산공장 배치도 유출도 내부자에 의해 저질러진 전형적인 피해 사례이며 이런 유출 사고로 인한 피해는 그 액수도 크고 민감한 자료의 유출로 인해 기업 경쟁력이 사라질 수 있다는데 더 큰 문제가 있다. 즉 엄청난 국민적 지탄에 직면하게 되고 기업의 존립 자체가 위협받게 된다.
 
   
                       표. DB보안 솔루션의 필수 기능
 
성공적인 DB암호화를 위한 솔루션의 필수 기능
DB암호화 솔루션은 나무와 같다고 생각하면 쉽게 이해될 수 있다. 즉 줄기와 뿌리로 이루어진다는 말이다. 줄기에 해당하는 부분은 실제로 이용 되어지는 기능, 즉 보안기능 영역에 해당 한다. 뿌리에 해당하는 부분은 드러나지는 않지만 부실할 경우 나무가 제대로 자랄 수 없다. 이 부분이 바로 DB운영성 영역에 해당되며 성공과 실패를 판가름 짓는 근간이 되는 부분이다.
성공적인 구축과 운영을 위해 위의 큰 두 가지 영역인 보안성과 DB운영성은 너무나도 중요하다. 지금까지의 실패 사례의 원인은 대부분 줄기에 해당하는 보안 부분만 검토하고 DB운영성 부분의 필수 기능을 검토하지 않았기 때문으로 분석된다. 그럼, 반드시 필요한 기능요소들은 어떤 것 들이 있는지 살펴 보자.

·강화된 국정원 보안적합성검증기준을 만족하는 보안성
DB암호화에서 줄기에 해당하는 부분은 바로 안전한 알고리즘과 안전한 키관리 체계이다. DB보안 솔루션의 주 목적은 중요한 정보를 안전한 알고리즘으로 암호화하고 이 데이터를 암·복호화할 수 있는 키를 기준에 맞도록 안전한 관리체계를 제공 해야 한다는 것이다. 나머지 보안 기능들은 모두 잔 가지에 해당 된다. 이를 위해서는 반드시 개정된 보안적합성 검증기준에서 요구하는 ‘암호모듈검증 기준’을 만족 해야 한다.
·DB운영을 불가능하게 하는 제약사항과 성능저하가 최소일 것
뿌리가 부실하면 나무가 곧 죽게 되는 것처럼 DB암호화 솔루션으로 말미암아 원래 운영하던 바 대로 시스템 운영을 하는데 심각한 제약이 오게 되면 곧 도입 실패로 이어진다. 결국 차와 포를 떼고 나면 검색할 가능성이 없는 비밀번호만 암호화하던가 그도 아니면 처박아 놓고 있는 것이 작금의 딱한 현실이다. 최소한 법규에서 정한 보안성을 지킴은 물론, 개인정보(또는 중요 기업정보)를 암호화 하고도 DB를 큰 문제없이 운영 하려면 표 1과 같은 요소들이 필수적이다.
 
DB암호화 솔루션으로 적용 가능한 업무 분야
■ 암호화대상 선정의 기본 방향
·법규 충족 : 암호화의 대상의 증가는 곧 DB성능 저하와 직결 되므로 법규를 확대 해석하여 적용하기에 앞서, 명시된 대상(주민번호, 패스워드)을 우선적으로 반드시 암호화 한다.
·DB운영성 고려 : 성능저하와 DB제약사항을 고려하여 추가로 암호화가 필요한 대상을 선정 한다.

■ 암호화 구축작업의 기본 절차
·영향 분석 : 암호화로 인한 기존 애플리케이션의 운영에 어떤 영향이 있을 것 인지를 사전에 면밀히 분석 한다. 방법으로는 월말 배치 작업이 있다면 이 기간을 포함하여 약 1주간 모니터링하고 DB서버에 요청하는 쿼리문장을 분석해 본 후 영향을 줄 수 있는 문제 쿼리를 찾아낸다.
·대책 수립 : 문제 쿼리가 만일 배치작업의 쿼리이고 Tuning 차원의 수정이 가능한 상태라면 쿼리문장의 Optimizing을 실시한다.
·환경 체크 : 작업에 필요한 여분의 Temporary Disk 공간은 있는지, 기타 DB의 환경변수들은 적절한지, 필요한 패키지나 패치 레벨 등이 적절히 설치되어 있는지 등을 체크 한다.
·작업 시작 : 전체 예상 작업시간 중 업무에 지장이 없도록 작업 대상 테이블의 순서와 작업 시간대를 조정한다. 서버의 성능을 고려하여 비 업무시간대일 경우 가능한 한 Parallel 처리를 하여 짧은 시간내에 마치도록 한다. 이 작업을 하는 동안 서비스를 계속할 수 있는 무 중단 구축의 필요성과 효과를 절감할 수 있을 것이다.
·완료 후 테스트 : 작업이 완료되고 나면 필요에 따라 암호화한 데이터가 정확히 변환 되었는지 정합성 체크를 실시한다. 애플리케이션을 수행하여 문제가 있지는 않은지 성능저하는 어느 정도인지를 확인 한다.

여기까지 문제가 없다면 성공한 것이다.

■ 암호화 가능한 데이터 및 적용 업무
DB암호화 솔루션으로 암호화 구축이 가능한 업무 및 데이터 종류는 대체적으로 다음과 같다. (* 표시는 CubeOne의 기능임.)
·적용 가능 업무 : 고객DB(개인정보, 본인 확인용 스캔문서), 인사DB(개인정보, 고과/연봉 정보), 기술DB(도면, 기술문서)*, 기타DB(CCTV영상-사건 조사기록 등)*
·암호화 가능 데이터 : CHAR, VARCHAR, VARCHAR2, DATE, INT, NUMBER, FLOAT, LONG,LOB(도면,동영상)

DB암호화를 둘러싼 오해와 진실

■ 부하에 관하 오해와 진실
오해 : 암호화를 하면 암·복호 작업이 전체 부하의 전부이다? 따라서 DB바깥에서 이를 수행하면 부하가 없다.(그럴듯한 이야기임에 틀림 없다.)
진실 : 이 경우 DB자체에 암·복호 부하가 없어지는 것은 사실이지만 암호화된 데이터만 가지고는 색인검색이 불가능해지기 때문에 Full Table Scan이 발생하게 되므로 결과적으로 DB는 이전에 없던 엄청난 부하를 지게 된다. 또한 Application형태로 DB외부에 설치하여 여기에서 암·복호를 수행하는 경우 이 Appliance에 얼마나 많고 빠른 CPU를 장착할 수 있을까? 원가 때문에 많이 넣지 못할 것이다.
암·복호는 거의 CPU 사이클에 의존한다. 최근 수 십 개의 4GHz를 넘어가는 Clock을 가진 CPU가 장착되는 서버들이 대부분 이다. 4GHz로 동작하는 20개의 CPU를 가진 서버가 있다고 가정하자. 가용한 총 CPU 사이클은 80GHz/초당 이다. 반면에 Appliance에 통상 장착되는 CPU들은 이 보다 낮은 2GHz 대의 CPU가 4개 정도 장착 된다. 그러면 가용 사이클은 약 8GHz 정도가 된다. 과연 어느 쪽이 빠를까?
 
          
                   그림. 암호화로 인한 Query의 변화 - 오버헤드의 이해
 
■ DB접근제어 및 감사 제품 과 DB암호화 솔루션과의 관계
오해 : 접근제어를 도입하면 DB암호화는 안 해도 된다?
진실 : 법규를 아무리 살펴봐도 그런 얘기는 없다. ‘중요한 개인정보에 대한 접근제어와 감사를 실시하고 이를 저장할 때에는 암호화하여 저장 하라’고 되어 있다. 이 문제는 우선순위의 문제일 뿐, 양자택일의 문제는 아니다. 즉, 투자비 지출계획에 의한 도입 순서의 문제라는 것이다. 법규만 충족하기 위해 ‘중요한 개인정보(즉 주민번호, 패스워드)는 암호화 하고 이 데이터에 대한 접근제어와 감사를 실시한다’라는 명제가 성립되며 이 명제만 본다면 DB암호화 솔루션이 가진 접근제어와 감사기능만으로도 충분하다. 하지만, 내부적인 이유에서 암호화까지는 필요 없지만 접근제어와 감사가 필요한 경우도 많으므로 결국 두 가지 솔루션을 병행하여 구축하여 서로 보완 관계가 되도록 해야 한다.

■DB암호화 솔루션과 접근제어 제품이 겹치는 기능의 차이점
오해 : DB암호화 솔루션의 접근제어 및 감사 기능으로 DB전체를 Cover 할 수 있다?
진실 : 기술적으로는 가능할 수도 있다. 하지만 DB내부에 설치되는 암호화 솔루션으로 암호화하지 않은 데이터 까지 모두 제어·기록하게 되면 엄청난 DB부하를 수반하게 되므로 현실적이지 못하다. 접근제어 제품은 그 대상을 접근제어 및 감사 대상을 DB전체로 하지만 일부 hole(콘솔 접속 및 WAS와 같은 미들웨어에서 XA세션을 통한 접속시)이 존재하는 한편, DB암호화 제품은 암호화된 칼럼만을 대상으로 하지만 hole은 없다. 이것은 솔루션이 설치되는 위치에 기인한 문제이며, 이 같은 속성을 잘 알고 필요 하다면 두 가지 제품을 함께 구축하여 서로 보완이 되도록 하는 것이 보다 완벽한 방안이다.

■ 어떤 형태의 DB암호화 제품이 좋은지
오해 : 암호화 제품은 다 똑 같다?
진실 : 그렇지 않다. 현재 DB용 암호화 제품은 크게 3종류가 있으며 각각의 특성은 다음과 같다.
API 방식의 제품 - AP서버에 설치, 애플리케이션을 수정 해야 하며, 암.복호 부하는 AP서버에 생기고 색인검색이 불가능함.(주로 비밀번호 암호화 용도로 쓰임)
Appliance 제품 - AP서버와 DB서버 사이에 설치, 애플리케이션을 수정 해야 하며, 암.복호 부하는 Appliance에 생김. 색인검색은 불가능함.(주로 비밀번호 암호화 용도로 쓰임)
Plug-In 제품 - DB서버에 설치, 애플리케이션의 수정이 불필요하며 암.복호 부하는 DB서버에 생김. 색인검색이 가능(제품별로 암호화된 인덱스를 통한 검색을 모두 지원 하지는 못함)

■ DBMS별 특성
오해 : 모든 DBMS에서 암호화된 인덱스를 통한 색인검색이 가능하다?
진실 : 그렇지 않다. 현재 Oracle은 지원되고 있고, 조사해본 바에 의하면 Informix 정도만이 가능한 것으로 보인다. 그 이유는 암호화된 인덱스를 통한 색인검색이 가능하도록 하는 기술은 생각보다 매우 까다롭다. 또한 DBMS에서 제공되어야 하는 몇 가지 특별한 기능을 필요로 하는데, 현재 이 기능을 제공하고 있는 DBMS가 별로 없기 때문이다. 결국 국내에서 많이 사용하고 있는 DBMS들 중 Oracle을 제외하고는 색인검색이 필요 없는 데이터(비밀번호 정도)는 암호화 할 수 있지만 주민번호는 암호화할 수 없다는 현실적 결론에 도달하게 된다.

실제 환경에서 테스트가 중요
DB암호화는 이제까지의 보안 제품들과는 달리 상당히 복잡한 측면이 있다. 또 한 번 구축하고 나면 되돌리기도 만만치 않다. 따라서 처음 선정할 때 반드시 테스트를 해 보는 것이 좋다. 테스트용 데이터 말고 개발 서버를 이용하여 실제 환경에서 테스트 해 보아야 한다. 그리고 레퍼런스 정보를 요구만 하고 실제 잘 쓰이고 있는지에 대한 확인은 하지 않는 고객들이 대다수인데 이 분야의 제품이야말로 ‘도입 레퍼런스 실적’이 아닌 ‘운영 레퍼런스 실적’을 살펴보아야 한다. 그것도 어떤 데이터들을 암호화 하였고 색인은 어떻게 되어 있는지(암호화 하였는지 여부) 등에 이르기까지 세밀한 검토가 필요 하다. 이러한 시각에서 제품선정을 한다면 아마도 원하는 제품을 선택할 수 있을 것이다.
<글: 조돈섭 이글로벌시스템 이사(alex@eglobalsys.co.kr)>
[김태형 기자(boan2@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>