Overview

Oracle Advanced Security의 Transparent Data Encryption (TDE)은 운영체제의 해킹 또는 하드웨어, 백업 미디어의 도난으로 인한 데이터 유출을 방지하기 위한 강력한 암호화 솔루션임.
TDE를 이용하여 주민등록번호, 신용카드번호와 같은 민감한 개인 정보들을 보호하고 regulation을 준수할 수 있음.

• 다른 대부분의 데이터베이스 암호화 솔루션과는 달리, TDE는 기존 애플리케이션에 완벽하게 투명하게 적용되므로 트리거, 뷰 또는 애플리케이션을 전혀 변경할 필요가 없음.
• 데이터는 디스크에 저장되는 과정에서 투명하게 암호화되며, 정상적인 인증 및 권한 할당을 거친 애플리케이션 사용자가 읽기를 시도할 때 역시 투명하게 복호화 됨.
• 기존의 데이터베이스 백업 루틴 또한 모두 정상적으로 실행 가능하며 데이터는 백업본에 암호화된 상태로 보존.
  

그림 1 Transparent Data Encryption 개요

11g에서 TDE에 새롭게 도입된 기능들을 간단하게 정리

• Tablespace Encryption
• Managing TDE with Enterprise Manager
• New Database Features in TDE
  1. LogMiner
  2. Logical Standby
• Streams
• Hardware Security Module

Tablespace Encryption

11g부터 소개된 테이블스페이스 암호화는 테이블스페이스 전체를 암호화할 수 있게 해주는 기능임

암호화된 테이블스페이스 내에 생성되는 모든 객체들은 자동으로 암호화되어 저장함
테이블스페이스 암호화 기능을 이용하면 각 테이블의 어떤 칼럼을 암호화해서 저장할지 결정할 필요가 없어짐
하나의 테이블에 여러 행에 걸쳐서 민감한 데이터들이 저장되는 경우나 일부 행이 아닌 전체 테이블을다 보호하고자 하는 경우 테이블스페이스 암호화 기능을 이용하면 유용함

테이블스페이스 암호화 기능은 암호화된 테이블스페이스에 저장되는 모든 데이터를 암호화하며, BLOB이나 CLOB같은 Large Object(LOBs) 타입도 마찬가지임
암호화된 테이블스페이스 외부의 데이터에 대해서는 암호화를 지원하지 않으므로
BFILE 데이터가 데이터베이스 외부에 위치하는 경우에는 암호화된 테이블스페이스에 BFILE칼럼을 포함한 테이블을 생성했다고 해도 이 칼럼은 암호화되지 않음

테이블스페이스 암호화에 이용될 마스터 키도 TDE 마스터 키가 저장되는 오라클 wallet에 저장됨
이 마스터 키는 테이블스페이스를 암호화/복호화 하는데 사용되는 테이블스페이스 암호화 키를 암호화하는데 사용됨.

암호화된 데이터는 JOIN이나 SORT 작업 시에도 보호됨.

• 즉, JOIN이나 SORT 작업 시 temporary 테이블스페이스에 데이터를 내려쓰는 경우에도 암호화되어 저장됨
• undo와 redo log에도 암호화되어 저장됨

테이블스페이스 암호화를 지원하기 위해서 테이블스페이스를 생성하는 CRAETE TABLESPACE 명령어 뒤에 ENCRYPTION 절이 추가되었음.

Temporary 테이블스페이스와 Undo 테이블스페이스는 암호화할 수 없으며, 테이블스페이스 암호화의 경우는 암호화 키를 변경할 수 없으므로 키를 변경하고자 하는 경우에는 새로운 테이블스페이스를 생성한 후 객체들을 이동시켜야 함.

Transparent Data Encryption(TDE)의 column-level encryption과 다른 점

테이블스페이스 암호화 기능은 기존의 어떤 테이블의 특정 칼럼만을 암호화하는 기능(TDE)과는 달리 블록 전체를 암호화하는 블록 레벨 암호화로서 디스크에 기록되는 시점에 암호화되고 읽히는 시점에 복호화되는 방식임.
그러므로 칼럼 레벨 암호화는 SGA 메모리 상의 데이터도 암호화된 상태로 남아있었던 데 반해 테이블스페이스 암호화는 SGA 메모리 상의 데이터는 clear text 상태로 남아있게 되며, 암호화로 인한 오버헤드는 I/O 작업 시에만 발생함

TDE는 transportable tablespace를 지원하지 않지만 테이블스페이스 암호화에서는 지원됨

• 소스 플랫폼과 대상 플랫폼의 endian이 동일하고, 동일한 wallet을 사용하는 경우에는 테이블스페이스 암호화를 이용하여 암호화한 테이블을 transportable tablespace를 이용하여 이동시킬 수 있음.

지원되는 데이터타입

모든 데이터타입을 지원한다.

지원되는 암호화 알고리즘

• 3DES168
• AES128 (default)
• AES192
• AES256

제약사항들

Temporary와 Undo 테이블스페이스는 암호화할 수 없음.
Bfile와 External 테이블은 암호화할 수 없음.
서로 다른 endian을 사용하는 플랫폼간에는 Transportable Tablespace을 통해서 암호화된 테이블스페이스를 이동시킬 수 없음.

Managing TDE with Enterprise Manager

11g TDE의 가장 큰 특징 중의 하나는 Enterprise Manager를 통해 설정 및 관리를 할 수 있게 되었다는
점이다.

New Database Features in TDE

11g부터는 좀 더 다양한 데이터베이스 기능들에 TDE를 적용할 수 있게 되었다.

1. LogMiner

TDE를 이용해서 암호화 칼럼의 데이터는 Data File, Undo Segment, Redo Log File에 모두 암호화된 상태로 저장.
10g까지는 LogMiner를 이용해서 Redo log를 확인해보면 암호화된 칼럼의데이터는 확인할 수 없음

SQL> select * from user_encrypted_columns;
TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL
------------------------------ ------------------------------ ----------------------------- ---
CUST_PAYMENT_INFO CREDIT_CARD_NUMBER AES 192 bits key NO  

SQL> select sql_redo from v$logmnr_contents where table_name = 'CUST_PAYMENT_INFO' and
operation='INSERT';
SQL_REDO
--------------------------------------------------------------------------------
insert into "OE"."CUST_PAYMENT_INFO"("FIRST_NAME","LAST_NAME","ORDER_NUMBER","CR
EDIT_CARD_NUMBER","ACTIVE_CARD") values ('Jon','Oldfield','10001',Unsupported Ty
pe,'YES');

SQL> select * from user_encrypted_columns;
TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL
------------------------------ ------------------------------ ----------------------------- ---
CUST_PAYMENT_INFO CREDIT_CARD_NUMBER AES 192 bits key NO

SQL> select sql_redo from v$logmnr_contents where table_name = 'CUST_PAYMENT_INFO' and
operation='INSERT';
SQL_REDO
--------------------------------------------------------------------------------
insert into "OE"."CUST_PAYMENT_INFO"("FIRST_NAME","LAST_NAME","ORDER_NUMBER","CR
EDIT_CARD_NUMBER","ACTIVE_CARD") values ('Jon','Oldfield','10001','5446959708812
985','YES');

11g에서 LogMiner가 데이터를 복호화해서 V$LOGMNR_CONTENTS에 저장하기 위해서는 물론 대상 테이블의 마스터키가 들어있는 wallet이 오픈되어 있는 상태이어야만 함.

2. Logical Standby

Logical Standby는 LogMiner를 이용해서 Redo Log를 SQL문장으로 변환해서 Standby 데이터베이스에 적용하는 SQL Apply를 구현하므로, 11g부터 LogMiner가 TDE 지원하게 되면서
자동적으로 Logical Standby도 TDE를 지원함

• Primary와 standby 데이터베이스가 같은 마스터 키를 사용하도록, 반드시 primary 데이터베이스의 wallet을 standby 데이터베이스에 copy해서 사용해야 함
• 마스터키 re-generation 명령어는 replicate되지 않으므로 primary 데이터베이스에서 마스터 키를 re-generation할 때 마다 반드시 wallet을 standby 데이터베이스에 다시 copy해 주어야 함
• Standby 데이터베이스에서만 copy해온 wallet의 비밀번호를 변경하거나, standby 데이터베이스의 칼럼 키를 rekey 하는 것은 가능

Streams

TDE로 암호화된 칼럼의 데이터는 투명하게 복호화되어 Streams의 Filtering과 기타 과정을 거침
Apply 데이터베이스가 TDE를 사용한다면, 적용될 데이터는 로컬의 암호화 키를 사용하여 투명하게 다시 암호화되어 적용
Source 데이터베이스의 일부 칼럼이 암호화되어 있는데 apply 데이터베이스의 해당 칼럼들은 암호화되어 있지 않다면 적용 과정에서 에러가 발생
ENFORCE_ENCRYPTION이 FALSE로 설정되어 있는 경우에만 에러가 발생하지 않음

Hardware Security Module

Hardware Security Module(HSM)이란 암호화 키를 저장하기 위한 secure storage인 물리적 장치를 의미
HSM은 암호화 복호화 작업을 위한 메모리도 제공하기 때문에 오라클 wallet보다 좀 더 강력한 보안성을 보장

TDE 기능을 HSM을 이용해서 구현하면, TDE를 위한 마스터 키가 HSM내에 저장되고, 마스터 키를 이용한 암호화/복호화 작업은 모두 HSM내의 메모리 상에서 이루어지기 때문에 마스터 키를 보호되지 않는 메모리 상에 노출시키지 않는다는 장점

그림 2 Hardware Security Module 개요

예제: http://blog.naver.com/biztec

테스트

교제 참조

결론 및 활용 방안

11g TDE 기능이 이전 버전에 비해 달라진 점은 다음의 두 가지로 요약

• Tablespace level encryption 기능 제공
• EM 등을 통한 TDE의 usability 향상

Tablespace encryption은 메모리에 올라오는 순간 복호화가 되므로 종래의 컬럼 레벨 암호화에 비해 보안성은 다소 떨어지는 감이 있음
그러나, 메모리 내에서의 자동 복호화는 index range scan을 가능하게 한다는 순기능을 또한 제공함을 강조