검증 3 : 키 기밀성 유지에 관한 취약성 검증
DB암호화 제품에서 키의 기밀성 확보는 대단히 중요하다. 아무리 견고한 알고리즘과 키 사용 권한 통제 체계를 갖추었다 하더라도 키 기밀성이 부실하면 키와 데이터가 함께 유출 될 경우 고스란히 중요 정보가 복호화 되기 때문이다.

원칙적으로 암·복호에 사용되는 키는 저장장치에 저장할 때는 패스워드를 키로 이용하여 암호화시켜 저장해야 하며, 사용을 위해 메모리에 로딩할 때 조차도 평문 상태로 로딩하지 않아야 하는 것이 국정원의 ‘DB암호제품의 보안 요건’에서 요구하고 있고, 2009년 6월 1일 시행 이후에 검증 신청을 하여 국가용 암호제품으로 검증된 제품들은 모두 이 기준을 충족하고 있다.

하지만 외산 DBMS Vendor의 TDE 제품들은 그 자체로는 이 같은 기준을 전혀 만족하지 못하고 있다. Oracle의 경우는 TDE를 사용할 때 HSM(Hardware Security module)을 옵션으로 채택할 수 있어 Master Key만이라도 안전한 HSM에 저장할 수 있으므로 이를 사용하여 보호하여야 한다. 하지만 대부분의 사용자들은 현실적으로 HSM을 구축하고 운영하는 것을 고려하지 않는다.

키 기밀성이 국정원 기준대로 정확히 지켜진다면, 어떤 서버(가령 A 서버)의 TDE로 암호화된 테이블(또는 테이블 스페이스)이 백업(DB백업 또는 파일 백업)을 통해 다른 서버(가령 B 서버)로 옮겨지고, 이와 더불어 키를 저장하고 있는 사설 인증서 파일 (Oracle의 ‘wallet’ 또는 MSSQL의 ‘tde.mdf’ & ‘tde_log.ldf’)까지도 함께 옮겨 졌을 때라도 쉽게 복호화 되지 않아야 한다.

Oracle 11g TDE의 경우는 서버 인증 기능이 없으므로 파일백업으로 다른 서버로 가져 갔을 때 wallet 파일을 액세스하여Open만 할 수 있으면 사용이 가능하다.

그러나 MSSQL 2008 TDE의 경우는 서버 인증서라는 것이 있어서 Oracle과 같은 결과가 나오지는 않기를 기대 하는데, 다른 자료들에 보면 제약 없이 사용 가능 상태가 된다고 한다(자료:‘SQL Server 2008의 New Feature_2탄_TDE_2’, WWW.SQLER.COM의 SQL 사용자 Tip & 강좌).

과연 정말 그러한 지, 보안서 기준 충족이 가능하여 데이터를 안전하게 지킬 수 있는지를 검증해 보자.

기준 : 키는 암호화 되어 저장되어야 하며 사용을 위해 복호화 할 경우, 복호키인 패스워드를 수동 입력하여야 한다. 스크립트 등으로 자동화 할 경우라 할지라도 별도의 인증 없이 사용될 수 있어서는 안된다.

검증 방법 : TDE로 암호화된 테이블과 키 저장파일, 자동화 스크립트가 있는 경우 해당 스크립트까지 다른 서버로 복사한 후 가동하였을 때 TDE가 작동하여 복호화 된 테이블로 서비스 되는지를 확인한다.

[MSSQL 2008의 TDE]
A 서버의 TDE로 암호화된 테이블(‘TEST_TDE’)과 키 관련 파일들을 복사하여 B 서버로 가져다 저장한 후 B 서버에서 활성화 되도록 한 후 TDE로 암호화한 테이블이 아무런 제약 없이 사용될 수 있는지(복호화 되는지)를 확인한다. 만일 된다면 심각한 유출 위험을 안고 있는 것이다.

서버 인증서가 어떤 효과를 발휘하는지를 살펴보자.

① 먼저 TDE로 암호화된 테이블과 키 관련 파일을 백업한다.


 
② 다른 서버로 백업한 파일을 복사한 후 키와 인증서를 생성한다.


 
③ A 서버에서 복사해 온 ¡°TEST_TDE¡±를 B 서버에 복원한다.


 


자, 이제 사용할 준비가 되었다.
 
④ 복사해 온 'TEST_TDE'테이블의 내용을 조회해 보자.


마치 원래 자기 DB의 테이블인 것처럼 평문으로 조회가 된다. 이후에 메모리 덤프도 해 보았으며 그 결과는 당연한 결과이지만 평문으로 로딩되어 있었다.

[ 결과 ] MSSQL 2008의 TDE는 인증서 및 키 파일과 함께 데이터 파일이 유출 되는 경우, 다른 서버에서도 제약 없이 조회가 가능하다.

[Oracle 11g의 TDE]
Oracle을 비롯한 대부분의 DBMS는 데이터 백업 및 복구가 가능하며, 복구는 원래의 서버 뿐 아니라 다른 서버에도 가능하다. 마땅히 그래야만 신규 서버로 Migration이 가능하기 때문이다.

그것이 가능한 이유는 데이터베이스는 실행 환경만 정확히 맞으면 작동하기 때문이다.

Oracle 11g의 TDE도 이러한 DBMS의 기본적인 백업 및 복구 메커니즘에서 벗어나지 않는다.

새로운 서버로 데이터를 가져 갔을 때 반드시 wallet 파일로 복사하여 가져가야 하며, wallet 파일을 open 하기 위한 패스워드도 알고 있어야 사용이 가능하다.

보안 메커니즘만을 보면 특별히 문제는 없어 보인다. 하지만 국가 암호화 기준을 따르지 않기 때문에 권한분리(SOD Separate of Duty)구조로 되어 있지 않으며 키 사용을 허가하는 과정이 보안 관리자가 할 수 없도록 되어 있고 모든 운영과 통제를DB관리자 계정(‘SYS’)이 하도록 되어 있기 때문에 내부자의 악의적 행위로 인한 데이터 유출 발생의 위험이 있다.

즉, TDE를 사용하는 대부분의 DBA들은 DB가 Restart 했을 때 wallet파일이 open되지 않아서 서비스가 불가능한 상태에 빠지지 않도록 wallet 파일 open이 자동으로 실행되도록 script를 만들어 놓기 때문에 DBMS를 full backup 받던가 또는 TDE 관련한 파일들을 OS 명령을 이용하여 백업해서 가지고 간 경우 이 script에 의해 wallet 파일이 자동 open되는 문제점이 있을 수 있다.

아래는 TDE 자동 open Scrip의 예 이다.


Wallet open을 위한 라인에 패스워드(‘oracle’)가 노출되어 있다. Manual로 Interactive하게 wallet을 open 할 때도, 화면에 패스워드가 노출된다.

[ 결과 ] Oracle 11g의 TDE는 wallet파일과 wallet open script가 함께 데이터 파일과 유출 되는 경우, 다른 서버에서도 제약 없이 조회가 가능하다.
[글_조돈섭 이글로벌시스템 이사(alex@cubeone.co.kr)]

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