DB 자체 암호화 모듈(TDE)의 보안 문제점

DB에서 제공하는 암호화 방법은 대략 2 가지가 있다.

과거 주로 사용했던 구현방식은 DB에 내장된 암호화 Function 또는 패키지를 이용하는 방법으로서 컬럼 단위로 암호화 되며, 사용을 위해서는 SQL문장을 모두 수정하여야 한다. 또한 암호화 키가 내장되어 노출되고 사용자의 IP주소 및 MAC주소로 접근통제할 수 없는 단점을 가지고 있다.

암호화된 데이터에 대한 접근기능을 제외하고 암호화란 측면에서만 보면, DB의 메모리 영역인 Buffer Cache에 중요 정보의 평문이 존재하지는 않으므로 이 점은 긍정적이다.

최근에는 이러한 내장 암호화 Function 또는 패키지의 문제점을 개선하고 기능을 강조하고 있는 방식이 TDE(Transparent Data Encryption)라는 제품군이 있는데 Oracle사의 11g용 TDE와 MSSQL 2008의 TDE가 대표적이다.

그러나 이 방식들은 파일 단위(MSSQL) 또는 Table Space 단위(Oracle)로 통째로 암호화하는 방식이며 서비스를 위해서는 DB 전용 메모리 영역(SGA)의 Buffer Cache에 평문(Clear Text)으로 복호화한 후 로드하여 사용하므로 예상치 못한 또 다른 심각한 데이터 유출 위험을 안고 있다.

일반적으로 TDE방식은 DB 내부의 커널 레벨에서 암호화를 구현하므로 구축이 용이하고 SQL 문장 수정이 불필요하므로 사용자들은 주로 이 방식에 관심을 가지고 선호하는 경향이 있는데 이 방식이 과연 안전할 수 있는지를 국가 공통평가 기준(국정원 의 암호화 보안 요구사항)을 기준으로 살펴보자.

일반적으로 암호화에서는 암호화 대상 데이터는 Disk 및 메모리에 저장 되는 데이터는 반드시  암호화가 되어 있음을 전제로 하며 3대 보안 요소로 키 기밀성, 알고리즘 및 키 사용 권한 통제 (접근통제)를 꼽는다.

3대 보안 요소 중에서, 먼저 키 기밀성에 대해 알아보자.
사용자 입장에서 직접적으로 관계없는(검증도 불가능한) 키의 생성, 전달 및 폐기 메커니즘에 있어서는 외형적으로 크게 문제점이 없어 보인다.

그러나 암호화에서 핵심 보안 요소인 키의 저장 방식(키 기밀성)에 있어서는 문제가 있으며, 중요한 것은 저장시 암호화 되어 있는지 여부와 사용시 패스워드 입력(관리자에 의한 수동 입력)  또는 다른 키에 의해 복호화 과정을 거치는가 하는 점이다. 다른 키에 의해 복호화하는 경우 그 키는 어떻게 암호화/복호화하여 관리하여 사용이 되는지를 또 분석해야 되며, 궁극적으로는 공개키 교환방식이 아닌 경우라면 패스워드 수동 입력 방식이어야 안전하다.

구 분
내          용
의  미
국정원 기준
모든 암호키는 DB서버 내.외부에 암호화하여 저장해야하며, 키를 암호화하는 핵심보안 매개변수도 안전하게 관리되어야 한다.
 
Oracle TDE(11g)
2-tier의 Key 방식이며, Master Encryption Key와 Tablespace Encryption Key는 Oracle 설치 폴더 아래에 ‘wallet’이라는 파일($ORACLE_BASE/admin/$ORACLE_SID/wallet)에 저장하며 통상 DB를 기동할 때 키 로딩을 위해서는 패스워드를 입력하여 wallet을 오픈 해야 하는데 이 부분을 자동으로 처리하기 위해 스크립트에 패스워드를 넣어 사용하고 있으므로, 별도의 패스워드(핵심보안 매개변수) 입력 없이도 자동으로 풀려서 로딩 됨.
위배됨(파일 백업에 의해 키와 데이터가 함께 유출됨)⑴ .
MSSQL 2008 TDE
MSSQL 설치 폴더 아래의 DATA 폴더 내에 ‘tde.mdf’ 파일에 저장함. 그러나 이 키는 패스워드(핵심보안 매개변수)로 암호화된 마스터키로 사이트 인증서를 만들고 이 인증서가 있어야 사용이 가능하다.
 
△ 표1 - 암·복호키의 저장 방법 및 보안 요건에 대한 기준 및 구현 방식.

⑴ HSM 옵션을 적용하는 경우에는 Master Encryption Key는 안전하다.

또한 DB암호화를 하는 근본적인 이유가 DB계정 중 정당한 사용자 이외의 접근권한을 가진 자(DBA 또는 DBA권한을 가진 일반 사용자)가 임의로 암호화된 정보를 사용하지 못하도록 하는 것이며 이를 위해서는 DB관리자와 보안관리자의 역할 분리가 전제 되어야 한다. 즉, 암호키와 핵심보안매개변수(키를 암호화하는데 사용되는 패스워드)는 보안관리자에 의해서만 생성 및 변경할 수 있어야 한다.

구 분
내          용
의  미
국정원 기준
암호키와 핵심보안 매개변수에 대한 접근 및 변경은 인가된 사용자에게만 허가되어야 한다.
 
Oracle TDE(11g)
DBA에 의해 마스터키 및 모든 키가 생성되고 변경됨.
위배됨⑵.
MSSQL 2008 TDE
DBA에 의해 마스터키, 마스터키의 복호화를 위한 패스워드 및 모든 키가 생성되고 변경됨.
위배됨⑵.

△ 표2 - 암호키와 핵심보안 매개변수 접근 및 변경 기준 및 구현 방식.

⑵ DBA또는 DBA권한을 가진 일반사용자가 데이터를 볼 수 있음을 의미함.

이제 키 사용 권한통제를 살펴 보자.
DB암호화 제품에 있어 키 사용 권한통제(통상 접근제어라고도 표현되나 암호문에 대해 암·복호키 사용을 통제하기 위한 목적이므로 네트워크 구간에 설치하는 DB접근제어 제품의 그것과는 구분 된다)는 DB계정과 요청하는 서버 및 접근에 사용된 애플리케이션이름 등에 대해 통제한다.

TDE 뿐만 아니라 DB자체 내장 함수 방식 또한 권한 통제에 있어서는 동일한 문제점을 안고 있다.

즉, DB의 전통적인 접근통제 방법(Access Control)에만 의존하게 되므로 GRANT 등으로 권한을 가진 일반 사용자뿐 아니라 DBA는 아무런 통제 없이 복호화하여 데이터를 볼 수 있다.

더욱이 정당한 사용자를 식별하고 접근 및 복호화 권한을 최소화하기 위해서는 사용자의 IP주소 및 MAC주소로 접근통제하여야 하는데 현재 TDE에서는 아직까지 지원하지 않고 있다.

구 분
내          용
의  미
국정원 기준
암호문.암호키.핵심보안 매개변수 등의 중요 데이터에 대한 접근통제는 사용자(DB사용자 또는 제품 사용자) 권한, 접속자 IP⑶, 어플리케이션, 접속시간.시간.요일등의 조건별로 제한할 수 있어야 한다. 접근통제 정책은 인가된 사용자⑸만이 접근 및 수정할 수 있어야 한다.
 
Oracle TDE(11g)
통제기능 없음(특정한 데이터에 대해 Data Vault를 적용하여 DBA계정에 대한  통제는 가능함).
위배됨⑷.
MSSQL 2008 TDE
통제기능 없음.
위배됨⑷.

△ 표3 - 접근통제 기준 및 구현방식.

⑶ 접속자 IP주소는 DB서버에 직접 접속하는 대상의 IP 주소를 의미함. 예를 들어, 사용자가 웹 응용프로그램을 이용하여 DB서버에 접근할 경우, 접속자 IP는 웹 응용프로그램이 위치한 WAS서버 IP 주소임(국정원 자료).
⑷ 암호화된 테이블에 접근 권한을 가진 DBA및 일반사용자에 의해 암호문이 복호화 될 수 있음을 의미함.
⑸ 보안관리자를 의미함.

세번째 중요 요소인 알고리즘에 대해 알아보자.
우선 국가 또는 공공기관은 국정원에서 검증된 암호모듈이 탑재된 제품만을 사용토록 의무화하고있다. 국정원 의 암호모듈 검증 시 필수 알고리즘은 ARIA(KSX-1213, 국가기관 표준)이다. 따라서 AES만을 지원하는 TDE 제품은 국가 또는 공공기관이 사용하는데 문제점이 있다.

또 하나의 기준은 정보통신망법의 시행규칙과 가이드라인인데, 블록 알고리즘은 키길이 128bit 이상의 AES, ARIA, SEED 또는 TDES 등을 사용할 수 있으며, DB에 저장된 패스워드 또는 바이오 정보에 대해서는 일방향 알고리즘인 SHA-256/384/512를 사용하도록 되어 있다.

TDE 제품들은 AES만을 혹은 TDES 만을 지원하며 SHA를 지원하지 않는다. 그리고 AES 알고리즘을 이용해 테이블을 통째로 암호화했기 때문에 법규정을 충족하기 위해서는 패스워드만 별도로 SHA알고리즘을 구해서 어플리케이션에 넣어야 한다.

구 분
내          용
의  미
국정원, 정보통신망법 및 개인정보보호법 기준
개인정보는 비밀키 방식(공공기관: ARIA, 민간: AES/TDES/SEED)의 알고리즘을 사용하며 2011년 이후에는 2060년까지 사용 가능한 키길이 128/192/256 bit의 키로 암호화해야 하며, 비밀번호, 바이오정보 등은 일방향 알고리즘인 SHA-256/384/512를 적용한다.
본인 인증에 필요한 패스워드 또는 바이오정보는 복호화할 수 없도록 규정함.
Oracle TDE(11g)
AES(128/192/256), TDES(192) 만 지원, SHA-256/384/512는 지원하지 않으며, 테이블스페이스 단위로 암호화하므로 패스워드도 복호화 가능한 AES/TDES로 암호화 됨.
위배됨.
MSSQL 2008 TDE
AES(128/192/256)만 지원, SHA-256/384/512는 지원하지 않으며, 테이블 단위로 암호화하므로 패스워드도 복호화 가능한 AES/TDES로 암호화 됨.
위배됨.


지금까지 각종 법령 또는 기준에 근거하여 TDE들의 문제점을 살펴 보았다.

그럼, 전제 조건인 Disk나 메모리에 저장될 때 암호화돼야 하는 요건을 살펴 보자.
먼저 MSSQL 2008의 TDE에 대한 MS사의 문서에 메모리에 복호화(Clear Text) 되어 로딩된다고 명시하고 있다(출처 : “Database Encryption in SQL Server 2008 Enterprise Edition”-SQL Server Technical Article, MSDN).
 


 
Oracle 11g의 TDE 역시 Oracle사의 문서에 마찬가지로 복호화(Clear Text) 로딩한다고 명시하고 있다(출처: Transparent Data Encryption (TDE) Frequently Asked Questions, Oracle사).
 


 
이제, 실제 검증을 통해 이 같은 문제점들을 다음 글을 통해 확인해 보자.
[글_조돈섭 이글로벌시스템 이사(alex@cubeone.co.kr)]

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