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
„ LogMiner
„ Logical Standby
„ Streams
„ Hardware Security Module
각 항목 별로 그 특징을 살펴보고, 테스트 과정을 소개하겠다.
Tablespace Encryption
11g부터 소개된 테이블스페이스 암호화는 테이블스페이스 전체를 암호화할 수 있게 해주는 기능이다.
암호화된 테이블스페이스 내에 생성되는 모든 객체들은 자동으로 암호화되어 저장된다. 테이블에 민감한 데이터를 저장하는 경우 테이블스페이스 암호화 기능을 사용하면 유용하다.
테이블스페이스 암호화 기능을 이용하면 각 테이블의 어떤 칼럼을 암호화해서 저장할지 결정할 필요가 없어진다.
하나의 테이블에 여러 행에 걸쳐서 민감한 데이터들이 저장되는 경우나 일부 행이 아닌 전체 테이블을 다 보호하고자 하는 경우 테이블스페이스 암호화 기능을 이용하면 유용하다.
테이블스페이스 암호화 기능은 암호화된 테이블스페이스에 저장되는 모든 데이터를 암호화한다. BLOB이나 CLOB같은 Large Object(LOBs) 타입도 마찬가지이다.
암호화된 테이블스페이스 외부의 데이터에 대해서는 암호화를 지원하지 않으므로 BFILE 데이터가 데이터베이스 외부에 위치하는 경우에는 암호화된 테이블스페이스에 BFILE칼럼을 포함한 테이블을 생성했다고 해도 이 칼럼은 암호화되지 않는다.
암호화된 테이블스페이스 내의 모든 데이터는 디스크에 저장될 때 암호화된 포맷으로 저장되고, 접근 권한을 가진 유저가 데이터를 보거나 수정할 때에 투명하게 복호화되므로 유저는 데이터가 디스크에 암호화되어
저장되었는지 여부에 대해서 전혀 신경 쓸 필요가 없으며, 데이터파일이나 백업 미디어 도난 시에는 민감한 데이터 유출을 예방할 수 있다.
테이블스페이스 암호화는 Transparent Data Encryption(TDE) architecture를 이용한다. 테이블스페이스 암호화에 이용될 마스터 키도 TDE 마스터 키가 저장되는 오라클 wallet에 저장된다.
이 마스터 키는 테이블스페이스를 암호화/복호화 하는데 사용되는 테이블스페이스 암호화 키를 암호화하는데 사용된다.
암호화된 데이터는 JOIN이나 SORT 작업 시에도 보호된다. 즉, JOIN이나 SORT 작업 시 temporary 테이블스페이스에 데이터를 내려쓰는 경우에도 암호화되어 저장된다.
또한 undo와 redo log 에도 암호화되어 저장된다.
테이블스페이스 암호화를 지원하기 위해서 테이블스페이스를 생성하는 CRAETE TABLESPACE 명령어 뒤에 ENCRYPTION 절이 추가되었다.
ENCRYPTION 절에 암호화 관련 속성들을 기술하면 된다. 자세한 명령어와 속성들에 대해서는 테스트 부분에서 알아보도록 하겠다.
Temporary 테이블스페이스와 Undo 테이블스페이스는 암호화할 수 없으며, 테이블스페이스 암호화의 경우는 암호화 키를 변경할 수 없으므로 키를 변경하고자 하는 경우에는 새로운 테이블스페이스를 생성한 후 객체들을 이동시켜야 한다.
Transparent Data Encryption(TDE)의 column-level encryption과 다른 점
테이블스페이스 암호화 기능은 기존의 어떤 테이블의 특정 칼럼만을 암호화하는 기능(TDE)과는 달리 블록 전체를 암호화하는 블록 레벨 암호화로서 디스크에 기록되는 시점에 암호화되고 읽히는 시점에 복호화되는 방식이다.
그러므로 칼럼 레벨 암호화는 SGA 메모리 상의 데이터도 암호화된 상태로 남아있었던 데 반해 테이블스페이스 암호화는 SGA 메모리 상의 데이터는 clear text 상태로 남아있게 되며, 암호화로 인한 오버헤드는 I/O 작업 시에만 발생한다.
TDE는 transportable tablespace를 지원하지 않지만 테이블스페이스 암호화에서는 지원된다.
소스 플랫폼과 대상 플랫폼의 endian이 동일하고, 동일한 wallet을 사용하는 경우에는 테이블스페이스 암호화를 이용하여 암호화한 테이블을 transportable tablespace를 이용하여 이동시킬 수 있다.
Note : TDE는 미디어에 저장된 데이터에 대한 보호 솔루션이므로 SGA 메모리 상에 clear text가 남는 것이 보안 정책에 위배된다고 볼 수는 없으며, temporary 테이블스페이스에 기록되는 데이터 또한 보호되는 특징을 통해 이를 정확하게 준수하고 있음을 확인할 수 있다.
지원되는 데이터타입
모든 데이터타입을 지원한다.
지원되는 암호화 알고리즘
3DES168
AES128 (default)
AES192
AES256
제약사항들
Temporary와 Undo 테이블스페이스는 암호화할 수 없다.
Bfile와 External 테이블은 암호화할 수 없다.
서로 다른 endian을 사용하는 플랫폼간에는 Transportable Tablespace을 통해서 암호화된 테이블스페이스를 이동시킬 수 없다.
Managing TDE with Enterprise Manager
11g TDE의 가장 큰 특징 중의 하나는 Enterprise Manager를 통해 설정 및 관리를 할 수 있게 되었다는 점이다.
wallet의 오픈/클로즈, 위치 이동 및 새로운 마스터키 생성 등의 작업을 Enterprise Manager를 통해 할 수 있으며 테이블 및 테이블스페이스 생성 과정에서 TDE관련 옵션을 설정을 할 수 있는 화면이 제공된다.
New Database Features in TDE
11g부터는 좀 더 다양한 데이터베이스 기능들에 TDE를 적용할 수 있게 되었다.
LogMiner
TDE를 이용해서 암호화 칼럼의 데이터는 Data File, Undo Segment, Redo Log File에 모두 암호화된 상태로 저장된다. 때문에 10g까지는 LogMiner를 이용해서 Redo log를 확인해보면 암호화된 칼럼의 데이터는 확인할 수 없었다.
예를 들어, 다음과 같이 CUST_PAYMNET_INFO테이블의 CREDIT_CARD_NUMBER 칼럼이 암호화되어있는 경우, 10g에서 LogMiner를 이용해서 로그를 확인해보면 암호화된 칼럼에는 다음과 같이 Unsupported Type이라는 메시지를 확인할 수 있었다.
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’);
insert into “OE”.”CUST_PAYMENT_INFO”(“FIRST_NAME”,”LAST_NAME”,”ORDER_NUMBER”,”CR EDIT_CARD_NUMBER”,”ACTIVE_CARD”) values (‘Chris’,’White’,’10002′,Unsupported Ty pe,’YES’);
[10g LogMiner 예]
하지만 11g부터 LogMiner는 TDE를 지원한다. 11g에서 LogMiner를 이용해서 로그를 확인해 보면 다음과 같이 암호화된 칼럼도 그 값을 확인할 수 있다.
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’);
insert into “OE”.”CUST_PAYMENT_INFO”(“FIRST_NAME”,”LAST_NAME”,”ORDER_NUMBER”,”CR EDIT_CARD_NUMBER”,”ACTIVE_CARD”) values (‘Chris’,’White’,’10002′,’51223580460825 60′,’YES’);
[11g LogMiner 예]
위의 예에서처럼 11g부터 LogMiner는 DML 문장에 포함되어있는 암호화된 칼럼의 데이터를 clear text 형태로 V$LOGMNR_CONTENTS에 저장한다. LogMiner가 데이터를 복호화해서 V$LOGMNR_CONTENTS에 저장하기 위해서는 물론 대상 테이블의 마스터키가 들어있는 wallet이 오픈되어 있는 상태이어야만 한다.
Note : TDE는 access control을 위한 솔루션이 아닌 파일 레벨에 대한 암호화 솔루션이기 때문에 V$LOGMNR_CONTENTS에 clear text가 저장되는 것이 보안 정책에 위배되는 것이 아님에 주의한다.
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 데이터베이스에서는 마스터 키 re-generation 명령어를 수행할 수 없다.
Standby 데이터베이스에서만 copy해온 wallet의 비밀번호를 변경하거나, standby 데이터베이스의 칼럼 키를 rekey 하는 것은 가능하다.
Streams
11g부터는 Streams도 TDE를 지원한다.
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내의 메모리 상에서 이루어지기 때문에 마스터 키를 보호되지 않는 메모리 상에 노출시키지 않는다는 장점이 있다.
여러 vendor에서 HSM을 제공하고 있으며, 라이브러리를 제공하는 Vendor의 HSM을 사용할 수 있다.
Hardware Security Module
Database Server Encrypted Data
그림 2 Hardware Security Module 개요
테스트
Quick Implementation of Tablespace Encryption 1.) Wallet 생성 위치 지정
Wallet을 생성하기 위해서는 $ORACLE_HOME/network/admin 디렉토리에 있는 sqlnet.ora 파일 내에 파라미터 ENCRYPTION_WALLET_LOCATION을 지정해야 한다.
Wallet이 생성될 위치를 지시하는 파라미터로서 설정되어있지 않으면 디폴트로 /etc/ORACLE/WALLETS/<Oracle software owner OS user name> 을 wallet 생성 위치로 사용한다.
oracle@obe11g.us.oracle.com:/home/oracle>
$ cd $ORACLE_HOME/network/admin
oracle@obe11g.us.oracle.com:/u01/app/oracle/product/11.1.0/db_1/network/admin>
$ vi sqlnet.ora
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/u01/app/oracle/product/11.1.0/db_1)))
2.) Wallet 생성
다음 명령어를 통해 wallet에 비밀번호를 지정하고 TDE에 사용할 마스터 키를 생성한다.
SQL> connect / as sysdba
Connected.
SQL> alter system set encryption key identified by “welcome1”;
Note : 위 명령어는 wallet에 TDE용 마스터 키를 생성하는 명령어이다. Wallet에 이미 마스터 키가 생성되어 있다면 새로운 마스터 키를 추가한다.
새로운 키를 추가하지 않고, 데이터베이스 shutdown 등의 이유로 close되었던 wallet을 다시 오픈만 하고 싶다면 다음의 명령어를 사용한다.
Alter system set wallet open identified by “welcome1”;
23.) CLEAN_TABLE 생성
위에서 생성한 CLEAN 테이블스페이스에 아래와 같이 테이블을 생성한다.
SQL> connect oe/oe;
Connected.
SQL> CREATE TABLE oe.clean_table TABLESPACE clean AS SELECT * FROM oe.customers;
Table created.
24.) TDE_TABLE 생성
위에서 생성한 암호화된 테이블스페이스인 TDE에 아래와 같이 테이블을 생성한다.
SQL> CREATE TABLE oe.tde_table TABLESPACE tde AS SELECT * FROM oe.customers;
Table created.
25.) 데이터파일을 열어보면, 다음과 같이 TDE 테이블스페이스에는 데이터가 암호화되어 저장되고, CLEAN 테이블스페이스에는 clean text가 저장된 것을 확인할 수 있다.
<clean 데이터 파일>
<tde 데이터 파일>
26.) 암호화된 테이블스페이스에 생성한 TDE_TABLE의 date_of_birth 칼럼에 인덱스를 생성한 후 쿼리해서 실행계획을 확인해 보자.
TDE를 이용한 칼럼 레벨 암호화는 range scan은 불가능한데 반해, 테이블스페이스 암호화의 경우 range scan이 되는 것을 확인할 수 있다.
SQL> CREATE INDEX idx_on_tde_table ON oe.tde_table(date_of_birth);
Index created.
SQL> connect / as sysdba;
Connected.
SQL> SELECT cust_last_name, date_of_birth FROM tde_table WHERE date_of_birth BETWEEN ’04-FEB-59′ AND ’06-FEB-59′;
CUST_LAST_NAME DATE_OF_B
——————– ———
Pacino 05-FEB-59
SQL> SELECT cust_last_name, date_of_birth FROM oe.tde_table WHERE date_of_birth BETWEEN ’04-FEB-59′ AND ’06-FEB-59′;
CUST_LAST_NAME DATE_OF_B
——————– ———
Pacino 05-FEB-59
SQL> select * from table (dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
——————————————————————————–
SQL_ID 4dj2brkpf9jp5, child number 0
————————————-
SELECT cust_last_name, date_of_birth FROM oe.tde_table WHERE
date_of_birth BETWEEN ’04-FEB-59′ AND ’06-FEB-59′
Plan hash value: 3331872405
————————————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (PLAN_TABLE_OUTPUT %CPU)| Time |
————————————————————————————————-
| 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | FILTER | | | | | |
PLAN_TABLE_OUTPUT
——————————————————————————–
| 2 | TABLE ACCESS BY INDEX ROWID| TDE_TABLE | 1 | 21 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | IDX_ON_TDE_TABLE | 1 | | 1 (0)| 00:00:01 |
————————————————————————————————-
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
———————————————————————————————————————————–
1 – filter(TO_DATE(’04-FEB-59′)<=TO_DATE(’06-FEB-59′))
3 – access(“DATE_OF_BIRTH”>=’04-FEB-59′ AND “DATE_OF_BIRTH”<=’06-FEB-59′)
Note
—–
– dynamic sampling used for this statement
26 rows selected.
결론 및 활용 방안
11g TDE 기능이 이전 버전에 비해 달라진 점은 다음의 한 가지로 요약된다.
„ Tablespace level encryption 기능 제공
Tablespace level encryption 기능 제공은 추가적으로 고려해야 할 사항이 있다. Tablespace encryption은 메모리에 올라오는 순간 복호화가 되므로 종래의 컬럼 레벨 암호화에 비해 보안성은 다소 떨어지는 감이 있다.
그러나 오라클의 보안 솔루션이 암호화와 접근 제어의 두 분야를 뚜렷이 구분하고 있는 만큼, 중요한 것은 고객에게 어떤 메시지를 전달하느냐일 것이다. 다시 말해 암호화 기능은 미디어 보호를 위한 기능이라는 점에 충실한다면 고객에게 모순되지 않은 일관된 메시지를 전달할 수 있는 것이다. 한편 메모리 내에서의 자동 복호화는 index range scan을 가능하게 한다는 순기능을 또한 제공함을 강조할 수 있어야 할 것이다.