Transparent Data Encryption(TDE)
|
Index |
TDE 개요
Transparent Data Encryption(TDE)는 Oracle Database 10gR2부터 제공되는 Oracle Advanced Security Option의 기능입니다. TDE는 운영체제의 해킹, 스토리지 및 백업 미디어의 도난으로 인한 데이터 유출을 예방하기 위한 강력한 데이터 암호화 솔루션입니다. TDE를 이용하면 주민등록번호, 신용카드번호와 같은 민감한 개인정보를 암호화된 상태로 저장하여 정보를 안전하게 관리하고 각종 보안규범을 준수할 수 있습니다.
다른 대부분의 암호화 솔루션들과 달리 TDE는 기존 어플리케이션에 완벽하게 투명한 방식으로 동작하므로, 응용프로그램 코드를 수정하거나 따로 트리거 혹은 뷰를 설정할 필요가 없습니다. 데이터는 디스크에 저장되는 과정에서 투명하게 암호화되며, 정상적인 인증 및 권한 할당을 거친 어플리케이션 사용자가 읽기를 시도할 때 역시 투명하게 복호화됩니다. 기존의 데이터베이스 백업 루틴 또한 모두 정상적으로 실행 가능하며 데이터는 백업본에 암호화된 상태로 보존됩니다.
TDE는 두 종류의 데이터 암호화를 제공합니다. 하나는 10gR2부터 제공되는 테이블 레벨 암호화이며 다른 하나는 11g부터 지원되는 테이블스페이스 레벨 암호화입니다. 두 종류 모두 TDE에 포함되는 기능이지만 일반적으로 “Transparent Data Encryption”이라고 하면 초기 TDE의 기능인 컬럼 레벨 암호화를 지칭하며, 테이블스페이스 레벨 암호화는 “Tablespace Encryption”이라고 지칭합니다.
TDE의 암호화 키
TDE는 두 종류의 암호화 키를 사용합니다. 하나는 테이블의 데이터를 암호화하는데 사용되는 “테이블 키”이며, 다른 하나는 이 테이블 키를 암호화하여 저장하기 위해 사용되는 “마스터 키”입니다.
마스터 키
TDE는 테이블 키가 데이터베이스 내에 clear text로 저장되는 것을 방지하기 위해 마스터 키를 이용하여 테이블 키를 암화해서 저장합니다. 마스터 키는 데이터베이스 외부에 Oracle wallet이라는 패스워드 기반 PKCS#12 호환 컨테이너에 저장되어 보호됩니다.
/* PKCS#12는 RSA에 의해 공표된 암호 키 저장 파일 형식입니다. */
11g부터는 마스터 키에 대한 보안 강화를 위해 Hardware Security Module(HSM)에 따로 저장할 수 있는 방법을 제공하고 있습니다.
테이블 키 (또는 컬럼 키)
테이블 키는 테이블 내 하나 이상의 컬럼을 암호화할 때 사용되는 암호화 키입니다. 각 테이블 당 하나씩 할당되며 마스터 키로 암호화하여 Oracle의 데이터 딕셔너리 테이블에 저장됩니다.
Wallet
Oracle wallet은 패스워드 기반의 PKCS#12 컨테이너로서 TDE에서 마스터 키를 안전하게 보관하기 위해 사용됩니다. 해당 패스워드를 통해 wallet이 오픈된 상태일 때만 암호화된 데이터에 접근할 수 있기 때문에, DBA의 권한과 wallet을 오픈할 수 있는 보안 관리자의 역할을 분리하여 각종 보안
법규에서 요구하는 “separation of duties” 조항을 만족시킬 수 있는 방법을 제공합니다.
Hardware Security Module (HSM, 하드웨어 보안 모듈)
11g부터는 Oracle wallet 이외에 Hardware Security Module(HSM) 장치에 마스터 키를 보관할 수 있도록 지원합니다. Hardware Security Module(HSM)이란 암호화 키를 저장하기 위한 secure storage인 물리적 장치를 의미합니다. 또한 HSM은 암호화 복호화 작업을 위한 메모리도 제공하기 때문에
오라클 wallet보다 좀 더 강력한 보안성을 보장합니다.
TDE 기능을 HSM을 이용해서 구현하면, TDE를 위한 마스터 키가 HSM내에 저장되고, 마스터 키를 이용한 암호화/복호화 작업은 모두 HSM내의 메모리 상에서 이루어지기 때문에 마스터 키를 보호되지 않는 메모리 상에 노출시키지 않는다는 장점이 있습니다.
vendor에서 HSM을 제공하고 있으며, 라이브러리를 제공하는 Vendor의 HSM을 사용할 수 있습니다.
TDE 적용 방법 Wallet 및 마스터 키 관리
Wallet 생성 및 마스터 키 관리
TDE에서는 마스터 키를 wallet에 저장하기 때문에 이 기능을 사용하기 위해서는 먼저 wallet을 생성하고 마스터 키를 설정해야 합니다. Wallet은 기본적으로 $ORACLE_BASE/admin/$ORACLE_SID/wallet에 생성됩니다.
마스터 키를 저장할 wallet을 생성하기 위해 $ORACLE_HOME/network/admin 디렉토리에 sqlnet.ora 파일을 열고 다음과 같이 ENCRYPTION_WALLET_LOCATION 파라미터에 wallet이 생성될 위치를 지정합니다.
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/oracle
/app/oracle/admin/ORCL/wallet))
Wallet의 경로를 지정합니다.
▪ $ORACLE_BASE/admin/WALLET
위에서 지정한 디렉토리를 생성한 후 ORACLE 유저에게 읽기/쓰기 권한이 있는지 확인하고, 다음의 SQL 명령어를 이용하여 wallet을 생성합니다.
SQL> Connect / as sysdba
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “<password>”;
위 명령어를 수행할 때, sqlnet.ora 파일에 지정된 wallet 위치에 wallet이 존재하지 않을 경우 ENCRYPTION_WALLET_LOCATION에 지정한 위치에 ewallet.p12라는 이름으로 wallet 파일이 생기면서 wallet은 open 상태가 되고 마스터 키가 생성됩니다.
Wallet Open 및 Close
데이터를 암호화/복호화하기 위해서는 먼저 마스터 키가 저장되어 있는 wallet을 open해야 합니다. wallet을 open하지 않은 상태에서 데이터베이스를 계속 운영할 수 있지만 암호화된 데이터에 접근할 경우 에러가 발생합니다.
데이터베이스 인스턴스를 내렸다가 올렸거나, 이전에 wallet을 닫았을 경우, 다음의 명령어로 wallet을 재오픈할 수 있습니다.
SQL> Connect / as sysdba
SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY “<password>”;
다음의 명령어로 wallet을 닫을 수 있습니다.
SQL> Connect / as sysdba
SQL> ALTER SYSTEM SET WALLET CLOSE;
Wallet이 닫혀있는 상태에서 사용자가 암호화된 컬럼을 접근할 경우 다음과 같은 에러 메시지가 발생합니다.
ORA-28365: wallet is not open
Wallet 상태 확인하기 (V$ENCRYPTION_WALLET)
Oracle Database 10.2.0.4 및 11g 버전에서는 wallet에 대한 정보를 알려주는 뷰를 제공하고 있습니다. 다음 뷰를 통해서 wallet이 열려있는지 여부 및 위치 등을 파악할 수 있습니다.
n V$ENCRYPTION_WALLET
n GV$ENCRYPTION_WALLET
위 두 뷰를 조회하면 다음과 비슷한 결과를 볼 수 있습니다.
SQL> conn / as sysdba
SQL> SELECT * FROM V$ENCRYPTION_WALLET;
WRL_TYPE WRL_PARAMETER STATUS
--------------- ------------------------------ ---------
file /etc/ORACLE/WALLETS/oracle OPEN
SQL> SELECT * FROM GV$ENCRYPTION_WALLET;
INST_ID WRL_TYPE WRL_PARAMETER STATUS
---------- --------------- ------------------------------ ---------
1 file /etc/ORACLE/WALLETS/oracle OPEN
Auto-login Wallet (wallet 자동 오픈 기능) Wallet(‘ewallet.p12’ 파일)은 wallet 패스워드로 암호화되어 마스터 키를 안전하게 보관합니다. 마스터 키를 사용하기 위해서는 wallet이 오픈된 상태에 있어야 하며 관리자가 직접 wallet을 오픈해주어야 합니다. Wallet을 자동으로 오픈해주는 기능을 설정하게 되면 보안 관리자는 매번 데이터베이스 인스턴스를 재시작하는 경우에 wallet을 다시 오픈해 줄 필요가 없게 됩니다. Wallet 자동 오픈 기능은 Oracle Wallet Manager 또는 ‘orapki’ 유틸리티를 이용해서 설정할 수 있습니다.
다음 방법으로 ‘orapki’를 통해 wallet을 자동으로 오픈할 수 있습니다. 명령을 실행하게 되면 auto-open wallet('cwallet.sso')이 생성됩니다.
$ orapki wallet create –wallet <wallet_location> -auto_login
Oracle Database 11.1.0.7부터는 로컬에서만 자동으로 wallet을 오픈할 수 있는 기능을 제공하고 있습니다.
$ orapki wallet create –wallet <wallet_location> -auto_login_local
Wallet 관리를 위한 GUI툴인 Oracle Wallet Manager(OWM)를 이용하여 auto-login 기능을 설정할 수도 있습니다. Wallet Manager를 실행하여 메뉴에서 ‘Wallet’ 항목 아래 ‘Auto Login’을 체크하면 됩니다.
Note: 자동 오픈 기능 설정 시 기존 wallet을 삭제하지 마십시오. 마스터 키를 re-key하기 위해서는 기존
wallet이 필요합니다. 마스터 키가 re-key되면 해당 자동오픈 wallet도 자동으로 업데이트됩니다.
Wallet 비밀번호 변경
Wallet의 비밀번호를 변경하기 위해서는 오라클이 제공하는 wallet관리용 GUI 툴인 Oracle Wallet Manager(OWM)을 이용합니다.
다음의 명령어로 OWM의 GUI 툴을 실행시킵니다.
$ORACLE_HOME/bin/owm
owm의 초기 화면은 다음과 같습니다.
메뉴에서 Change Password 항목을 선택한 후, 변경할 비밀번호를 입력합니다.
변경 후, 반드시 다음과 같이 저장해야 변경내용이 반영됩니다.
참고) 위 화면에서 ‘Auto Login’을 체크하면 wallet 자동오픈 기능이 활성화됩니다. Auto-login 기능을 해제할 경우에는 위 화면에서 이전에 체크한 ‘Auto Login’ 부분을 해제하면 됩니다.
11g R2 부터는 orapki Utility를 이용하여 변경 가능
orapki wallet change_pwd -wallet wallet_location [-oldpwd password ] [-newpwd password]
마스터 키 변경 및 추가
마스터 키를 변경하려면 wallet을 삭제하고 새로 생성하는 방법 뿐입니다. 하지만 wallet을 삭제하면 기존의 마스터 키로 암호화되어 있는 데이터들을 복호화할 수 없게 되므로 주의해야 합니다.
이미 wallet이 생성되어 있는 상태에서 다음 명령어를 수행하면, 기존의 wallet에 마스터 키가 하나 더 추가됩니다. 패스워드는 기존의 wallet의 패스워드를 그대로 사용해야 합니다. Wallet이 존재하지 않은 상태에서 명령어를 수행하게 된다면 「Wallet 생성 및 마스터 키 설정」부분에서 언급했듯이 wallet이 생성되고 open되면서 마스터 키가 생성됩니다.
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “<password>”;
이 때, 기존에 사용하던 마스터 키는 그대로 유지되어 사용되며, 새로 추가된 마스터 키는 이후에 암호화되는 테이블들에 대해서만 적용됩니다. 마스터 키가 추가되면 데이터 딕셔너리에 있던 테이블 키들은 다시 새로 암호화됩니다. 예를 들어 데이터를 새로 마스터 키가 추가되기 전 시점으로 복구해야 할 경우에는 기존에 사용했던 마스터 키가 복호화에 사용됩니다.
마스터 키 추가가 데이터에 대한 보안도를 높이는 방법이 될 수는 없습니다. 보안도를 높이기 위해서는 wallet의 비밀번호를 변경하는 것이 더 좋은 방법입니다.
Note: wallet이 삭제되면 기존에 암호화되어 있는 데이터들을 복호화할 수 있는 방법이 없으므로, wallet은 항상 백업해두고 삭제되지 않도록 주의해야 합니다. 특히, 마스터 키를 새로 추가할 때마다 필히 백업하도록 합니다.
테이블에 대한 컬럼 암호화
TDE로 암호화 가능한 데이터 타입은 다음과 같습니다.
▪ BINARY_DOUBLE
▪ BINARY_FLOAT
▪ CHAR
▪ DATE
▪ INTERVAL DAY TO SECOND
▪ INTERVAL YEAR TO MONTH
▪ NCHAR
▪ NUMBER
▪ NVARCHAR2
▪ RAW
▪ TIMESTAMP (TIMESTAMP WITH TIME ZONE과 TIMESTAMP WITH LOCAL TIME ZONE 포함)
▪ VARCHAR2
암호화된 컬럼을 포함한 테이블 생성
테이블 생성시 다음과 같이 SQL문에 ENCRYPT절을 붙여주면 해당 컬럼을 암호화할 수 있습니다. TDE는 default로 키 길이가 192비트인 AES 암호화 알고리즘 (AES192)을 이용하여 암호화합니다.
CREATE TABLE new_table ( first_name VARCHAR2(128), last_name VARCHAR2(128), empID NUMBER,
salary NUMBER(6) ENCRYPT);
생성 후 테이블을 보면 다음과 같이 암호화된 것을 확인할 수 있습니다.
DESC new_table;
Name Null? Type
----------------------------------------- -------- ---------------------------- FIRST_NAME VARCHAR2(128)
LAST_NAME VARCHAR2(128)
EMPID NUMBER
SALARY NUMBER(6) ENCRYPT
해당 테이블에 데이터를 insert한 후 조회해보면 다음과 같이 실제 데이터 값을 확인할 수 있습니다.
SQL> SELECT * FROM new_table;
|
FIRST_NAME -------------------- Steven |
LAST_NAME -------------------- King |
EMPID ---------- 100 |
SALARY ---------- 24000 |
|
Neena |
Kochhar |
101 |
17000 |
|
Lex |
De Haan |
102 |
17000 |
|
Alexander |
Hunold |
103 |
9000 |
|
Bruce |
Ernst |
104 |
6000 |
|
David |
Austin |
105 |
4800 |
|
Valli |
Pataballa |
106 |
4800 |
|
Diana |
Lorentz |
107 |
4200 |
|
Nancy |
Greenberg |
108 |
12000 |
|
Daniel |
Faviet |
109 |
9000 |
|
10 rows selected. |
|
|
|
기존 테이블의 칼럼 암호화
기존 테이블에 암호화 컬럼을 추가하기 위해서는 ALTER TABLE ADD 명령어를 이용하여 암호화할 컬럼에
ENCRYPT 절을 지정합니다.
SQL> ALTER TABLE <NEW_TABLE> ADD (dept VARCHAR2(30) ENCRYPT);
다음의 SQL 명령어를 이용하여 기존 테이블에 들어있는 데이터를 암호화할 수 있습니다. 우선 기존 테이블에 있는 컬럼 정보를 확인하면 다음과 같습니다.
SQL> DESC emp_table;
Name Null? Type
----------------------------------------- -------- ---------------------------- FIRST_NAME VARCHAR2(128)
LAST_NAME VARCHAR2(128)
EMPID NUMBER
SALARY NUMBER(6)
DEPT VARCHAR2(30)
테이블에 있는 데이터를 암호화하기 위해 ALTER TABLE MODIFY 명령어를 이용하여 암호화할 컬럼에 ENCRYPT절을 지정합니다.
SQL> ALTER TABLE emp_table MODIFY (salary ENCRYPT);
테이블 정보를 다시 확인하면 다음과 같이 암호화가 지정되었다는 것을 확인할 수 있습니다.
SQL> DESC emp_table;
Name Null? Type
----------------------------------------- -------- ---------------------------- FIRST_NAME VARCHAR2(128)
LAST_NAME VARCHAR2(128)
EMPID NUMBER
SALARY NUMBER(6) ENCRYPT
DEPT VARCHAR2(30)
Note: SYS 유저 소유의 테이블은 암호화 할 수 없습니다.
암호화 해제
기존의 컬럼에 암호화를 해제하기 위해서는 ALTER TABLE MODIFY 명령어를 이용하여 암호화를 해제할 컬럼에
DECRYPT절을 지정합니다.
SQL> ALTER TABLE emp_table MODIFY (salary DECRYPT);
암호화 알고리즘 지정 및 변경
TDE에서 지원하는 암호화 알고리즘은 다음과 같습니다.
|
알고리즘 |
키 사이즈 (bits) |
파라미터 명 |
|
AES (Advanced Encryption Standard) |
128 |
AES128 |
|
AES (Advanced Encryption Standard) |
192 |
AES192 |
|
AES (Advanced Encryption Standard) |
256 |
AES256 |
|
3DES (Advanced Encryption Standard) |
168 |
3DES168 |
암호화된 테이블 생성 시에 암호화에 사용할 알고리즘을 직접 지정해줄 수 있습니다.
Default로 AES192 이다.
알고리즘이 사용됩니다. 암호화 알고리즘은 다음과 같이 SQL 명령어의 ENCRYPT절에서 지정해줍니다.
CREATE TABLE new_table ( first_name VARCHAR2(128), last_name VARCHAR2(128), empID NUMBER,
salary NUMBER(6) ENCRYPT USING ‘<알고리즘의 파라미터 명>’;
기존에 존재하는 테이블을 암호화할 때에도 다음과 같이 암호화 알고리즘을 직접 지정해줄 수 있습니다.
SQL> ALTER TABLE emp_table MODIFY (salary ENCRYPT USING ‘<알고리즘의 파라미터 명>’);
테이블 키 재생성
각 테이블은 오직 하나의 테이블 키를 가질 수 있습니다. 테이블 키는 ALTER TABLE 명령어로 재생성할 수 있으며 이때 암호화 알고리즘도 함께 바꿀 수 있습니다. 테이블 키를 재생성하는 경우 그 키를 이용하여 테이블 안의 암호화되어 있는 데이터는 모두 다시 암호화됩니다.
SQL> ALTER TABLE emp_table REKEY;
SQL> ALTER TABLE emp_table REKEY USING ‘<알고리즘의 파라미터 명>’;
암호화 시에 알고리즘을 지정하지 않으면 기존의 테이블이 사용하던 알고리즘이 그대로 이용됩니다.
Note1 : 테이블 키 재생성시 해당하는 모든 데이터를 다시 암호화하는 과정이 수반되기 때문에 데이터의 양에 따라 시간이 많이 소요될 수 있다는 점에 주의해야 합니다.
Note2 : 테이블 키 재생성 전후에 Oracle wallet을 백업해두도록 합니다.
인덱스 생성
컬럼 암호화를 이용할 경우 암호화한 컬럼에 대하여 B-tree 인덱스를 생성할 수 있습니다. 단, 이 경우 컬럼은 NO SALT 옵션으로 암호화가 되어있어야 합니다.
또한 컬럼 암호화에서 각각 테이블마다 고유의 암호화 키를 가지고 있기 때문에 foreign key를 지원하지 않습니다. 이러한 이유로 신용카드번호나 주민등록번호와 같은 민감한 데이터를
primary key로 사용하지 않을 것을 권고하고 있습니다.
암호화된 컬럼에 대하여 생성된 인덱스는 equality search시에만 적용되며 range search에서는 적용이 되지 않습니다. Range search 시에도 인덱스를 타려면 암호화된 텍스트에서도 암호화
되기 전 텍스트의 대·소 관계가 그대로 유지되어야 하는데, 그렇게 되면 암호화 알고리즘의 보안도가 너무 낮아지기 때문입니다.
NO SALT 옵션 설정
TDE를 통해 암호화한 컬럼에 대하여 인덱스를 생성할 경우 암호화 시 NO SALT 옵션을 설정해야 합니다. 원래 SALT 옵션은 보안도를 강화하기 위한 기능으로, 암호화되기 전의 원본 데이
터에서 같은 텍스트가 반복되더라도 암호화된 결과는 각 텍스트가 서로 다른 형태로 암호화되는 기능입니다. 때문에 SALT 옵션은 패턴 매칭 방식으로 암호화된 코드에서 원본 데이터를
역추적하여 해킹하는 것을 방지해줍니다. 그러나 SALT 옵션을 설정하면 같은 데이터라도 다른 형태로 암호화되기 때문에 암호화된 컬럼에 대해 인덱스를 생성할 수 없습니다. 암호화한 컬
럼에 인덱스를 생성할 경우 다음의 명령어를 이용하여 반드시 NO SALT를 설정해야 합니다. NO SALT가 명시되지 않으면 salt가 default로 설정됩니다.
SQL> ALTER TABLE emp_table MODIFY (empid ENCRYPT NO SALT);
Salt를 설정하려면 다음을 명령어를 이용합니다.
SQL> ALTER TABLE emp_table MODIFY (empid ENCRYPT SALT);
Salt가 설정되어 있는 칼럼에 인덱스를 생성하면, 다음과 같은 에러가 발생합니다.
SQL> CREATE UNIQUE INDEX idx_empid ON emp_table(empid); CREATE UNIQUE INDEX idx_empid ON emp_table(empid)
*
ERROR at line 1:
ORA-28338: cannot encrypt indexed column(s) with salt
Import/Export
imp/exp 명령어는 TDE를 통해서 암호화된 테이블을 지원하지 않습니다. 암호화된 테이블을 exp명령어를 이용해서 export하면 다음과 같은 에러가 발생합니다.
$ exp hr/hr file=emp_table.dmp tables=emp_table;
Export: Release 11.1.0.6.0 - Production on Mon Apr 28 19:25:34 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security and Oracle Database Vault options Export done in KO16KSC5601 character set and AL16UTF16 NCHAR character set
About to export specified tables via Conventional Path ...
EXP-00107: Feature (COLUMN ENCRYPTION) of column EMPID in table HR.EMP_TABLE is not supported. The table will not be exported.
Export terminated successfully with warnings.
10g부터 제공되는 Oracle Data Pump를 이용하여 암호화된 테이블을 export할 수 있습니다. 암호화된 테이블은 다음과 같이 expdp 명령어를 통해서 export할 수 있습니다.
$ expdp hr/hr dumpfile=emp_table.dmp tables=emp_table; /* 계정 권한 확인 */
Export: Release 11.1.0.6.0 - Production on Monday, 28 April, 2008 19:38:21 Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security and Oracle Database Vault options
Starting "HR"."SYS_EXPORT_TABLE_01": hr/******** dumpfile=emp_table.dmp tables=emp_table Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 64 KB Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
. . exported "HR"."EMP_TABLE" 6.507 KB 10 rows
ORA-39173: Encrypted data has been stored unencrypted in dump file set. Master table "HR"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
****************************************************************************** Dump file set for HR.SYS_EXPORT_TABLE_01 is:
/oracle/app/oracle/admin/ORCL/dpdump/emp_table.dmp
Job "HR"."SYS_EXPORT_TABLE_01" completed with 1 error(s) at 19:38:57
TDE로 암호화된 테이블을 expdp를 이용해서 export하면 위와 같이 암호화된 칼럼이 암호화되지 않은 상태로 덤프 파일에 저장되었다는 에러가 발생합니다.
데이터베이스 내에 암호화되어 저장되어 있는 테이블을 덤프파일에도 암호화된 상태로 저장하려면, expdp
명령어에 다음과 같이 encryption_password 구문을 추가해서 암호화에 사용될 패스워드를 지정해줍니다.
$ expdp hr/hr dumpfile=emp_table.dmp tables=emp_table encryption_password="welcome1"; Export: Release 11.1.0.6.0 - Production on Monday, 28 April, 2008 19:27:57
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security and Oracle Database Vault options
Starting "HR"."SYS_EXPORT_TABLE_01": hr/******** dumpfile=emp_table.dmp tables=emp_table encryption_password=******** Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 64 KB Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
. . exported "HR"."EMP_TABLE" 6.515 KB 10 rows Master table "HR"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for HR.SYS_EXPORT_TABLE_01 is:
/oracle/app/oracle/admin/ORCL/dpdump/emp_table.dmp
Job "HR"."SYS_EXPORT_TABLE_01" successfully completed at 19:29:59
이렇게 암호화된 데이터가 저장된 덤프파일을 다시 import 시킬 때에는, 다음과 같이 impdp 명령어에
encryption_password 구문을 이용해서 export 시 사용한 패스워드를 넣어줍니다.
$ impdp system/oracle dumpfile=emp_table.dmp remap_schema=hr:system encryption_password="welcome1"; Import: Release 11.1.0.6.0 - Production on Monday, 28 April, 2008 20:05:28
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security and Oracle Database Vault options Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** dumpfile=emp_table.dmp remap_schema=hr:system encryption_password=********
Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "SYSTEM"."EMP_TABLE" 6.515 KB 10 rows Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at 20:06:14
다시 정리하자면, Data Pump를 이용한 데이터 export/import 시 TDE를 이용하여 암호화된 테이블 내의 데이터는 덤프파일에서 clear text로 존재하게 됩니다. 여기서
ENCRYPTION_PASSWORD 파라미터를 통해 패스워드를 지정하게 되면 데이터는 암호화된 상태로 덤프파일에 존재하게 됩니다. 10g에서 ENCRYPTION_PASSWORD 파라미터는 오직 TDE
를 통해 암호화된 컬럼을 export/import시에만 적용할 수 있습니다. 이때 TDE 기능을 사용(활성화 상태)하고 있어야 합니다.
11g Data Pump에서는 ENCRYPTION 파라미터가 새롭게 제공되고 있습니다. 10g에서는 덤프파일 데이터 중 TDE를 통해 암호화한 컬럼에 대해서만 암호화를 제공했습니다. 11g에서는
ENCRYPTION 파라미터를 통해 덤프파일에 있는 데이터 전체를 암호화할 수 있습니다.
11g의 ENCRYPTION 파라미터는 다음과 같은 값을 가질 수 있습니다.
▪ ENCRYPTED_COLUMNS_ONLY : TDE를 통해 암호화된 컬럼만 덤프파일에 암호화된 형태로 저장
▪ DATA_ONLY : 데이터만 덤프파일에 암호화된 형태로 저장
▪ METADATA_ONLY : 메타데이터만 덤프파일에 암호화된 형태로 저장
▪ ALL : 모든 데이터 및 메타데이터가 덤프파일에 암호화된 형태로 저장
11g에서는 ENCRYTION 또는 ENCRYPTION_PASSWORD 파라미터 또는 둘 다 설정이 되어있어야만 암호화가 이루어집니다. ENCRYPTION_PASSWORD만 설정된 경우 ENCRYPTION은 ALL
로 디폴트값이 잡힙니다. ENCRYPTION과 ENCRYPTION_PASSWORD 모두가 설정이 안된 경우 ENCRYPTION은 NONE으로 디폴트값이 잡힙니다.
Note: 10g에서는 ENCRYPTION_PASSWORD 파라미터 설정시 오직 TDE로 암호화한 컬럼만 암호화해서 덤프파일에 저장했습니다. 11g부터는 ENCRYPTION 파라미터가 제공되고
있어 ENCRYPTION_PASSWORD만 설정한 경우 덤프파일로 쓰여진 모든 데이터에 대해서 암호화가 이루어지게 됩니다(ENCRYPTION = ALL와 같은 효과). 그러므로 11g에서는 암
호화된 컬럼에 대해서만 덤프파일로 쓸 때 암호화하려면 ENCRYPTION=ENCRYPTED_COLUMNS_ONLY도 함께 설정해야 합니다.
ENCRYPTION=ENCRYPTED_COLUMNS_ONLY으로 설정한 경우 다음과 같이 export/import 작업을 수행할 수 있습니다.
$ expdp hr/hr tables=emp_tab directory=dpump_dir1 dumpfile=emp_tab.dmp encryption=encrypted_columns_only encryption_password=welcome1
Export: Release 11.1.0.6.0 - Production on Wednesday, 13 August, 2008 10:57:06 Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "HR"."SYS_EXPORT_TABLE_01": hr/******** tables=emp_tab directory=dpump_dir1 dumpfile=emp_tab.dmp encryption=encrypted_columns_only encryption_password=********
Estimate in progress using BLOCKS method... Processing object type TABLE_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 64 KB Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "HR"."EMP_TAB" 22.01 KB 107 rows Master table "HR"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
****************************************************************************** Dump file set for HR.SYS_EXPORT_TABLE_01 is:
/usr/apps/datafiles/emp_tab.dmp
Job "HR"."SYS_EXPORT_TABLE_01" successfully completed at 10:58:36
다음은 import 작업입니다. encryption_password 파라미터에는 반드시 export시 사용한 값을 넣어야 합니다. 만약
encryption_password 파라미터를 포함시키지 않은 경우 다음과 같은 에러가 발생합니다.
$ impdp system/oracle tables=emp_tab directory=dpump_dir1 dumpfile=emp_tab.dmp remap_schema=hr:system Import: Release 11.1.0.6.0 - Production on Wednesday, 13 August, 2008 11:06:10
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39002: invalid operation
ORA-39174: Encryption password must be supplied.
정상적인 import 작업의 수행은 다음과 같습니다.
$ impdp system/oracle tables=emp_tab directory=dpump_dir1 dumpfile=emp_tab.dmp remap_schema=hr:system encryption_password=welcome1
Import: Release 11.1.0.6.0 - Production on Wednesday, 13 August, 2008 11:07:08 Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Master table "SYSTEM"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_TABLE_01": system/******** tables=emp_tab directory=dpump_dir1 dumpfile=emp_tab.dmp remap_schema=hr:system encryption_password=********
Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "SYSTEM"."EMP_TAB" 22.01 KB 107 rows Job "SYSTEM"."SYS_IMPORT_TABLE_01" successfully completed at 11:07:22
컬럼 암호화 관련 딕셔너리 뷰
다음의 딕셔너리 뷰를 통해서 컬럼 암호화를 이용하여 암호화한 알고리즘을 확인할 수 있습니다.
▪ DBA_ENCRYPTED_COLUMNS
▪ ALL_ENCRYPTED_COLUMNS
▪ USER_ENCRYPTED_COLUMNS
다음은 관련 딕셔너리 뷰에 대한 조회결과 예입니다.
SQL> SELECT * FROM user_encrypted_columns;
TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL
-------------------- -------------------- -------------------- ---
|
NEW_TABLE EMP_TABLE |
SALARY EMPID |
AES 192 bits key AES 192 bits key |
YES NO |
|
EMP_TABLE |
SALARY |
AES 192 bits key |
YES |
컬럼 암호화 사용 시 제약사항
컬럼 암호화에서는 각 테이블마다 컬럼을 암호화하는 고유의 테이블 키가 존재하기 때문에 foreign key (외래키)
제약조건이 걸려있는 컬럼은 TDE로 암호화할 수 없습니다.
또한 TDE는 SQL 계층에서 암호화/복호화를 진행하기 때문에 SQL 계층을 거치치 않는 오라클 데이터베이스 기능을 사용할 경우 TDE를 통한 암호화는 지원되지 않습니다. 다음은 11g를 기준으로 TDE가 지원되지 않는 데이터베이스 기능들입니다.
▪ B-tree 이외의 인덱스 타입
▪ 인덱스를 이용한 range scan
▪ BFILE
▪ Materialized view logs
▪ Synchronous Change Data Capture
▪ Transportable Tablespaces
▪ 기존의 Import/Export
Note1: 오라클 10gR2에서는 BLOB과 CLOB과 같은 내부 LOB 데이터타입을 지원하지 않습니다.
TDE에서 지원되는 각 데이터 타입별로 암호화할 수 있는 최대 크기 제한이 있습니다. 암호화할 컬럼의 크기가 다음을 초과하면 암호화할 수 없습니다.
|
데이터 타입 |
최대 사이즈(bytes) |
|
CHAR |
1932 |
|
VARCHAR2 |
3932 |
|
NVARCHAR2 |
1966 |
|
VARCHAR |
966 |
Tablespace Encryption 개요
Tablespace Encryption은 11g에서부터 새롭게 제공되는 기능으로 테이블스페이스 전체를 암호화할 수 있게 해주는 기능입니다. 해당 테이블스페이스 내의 모든 객체들은 자동으로 암호화되어 저장됩니다.
테이블스페이스 암호화 기능은 암호화된 테이블스페이스에 저장되는 모든 데이터를 암호화합니다. 여기서 BLOB나 CLOB와 같은 Large Object (LOBs) 타입도 마찬가지입니다. 하지만 암호화된 테이블스페이스 외부의 데이터에 대해서는 암호화를 지원하지 않으므로 BFILE 데이터가 데이터베이스 외부에 위치하는 경우에는 암호화된 테이블스페이스에 BFILE 컬럼을 포함한 테이블을 생성했다고 해도 이 컬럼은 암호화되지 않습니다.
테이블에 민감한 데이터를 저장하는 경우 테이블스페이스 암호화 기능을 사용하면 유용합니다. 사용자는 테이블의 어떤 컬럼을 암호화해서 저장할지 결정할 필요가 없어지게 됩니다. 또한 하나의 테이블에 여러 행에 걸쳐서 민감한 데이터들이 저장되는 경우나 일부 행이 아닌 전체 테이블을 다 보호하고자 하는 경우에도 유용합니다.
테이블스페이스 암호화에서는 암호화에 따른 추가적인 스토리지 공간을 필요하지 않습니다. 오라클은 데이터를 메모리(SGA)로 읽어올 때 자동으로 복호화해서 메모리에 올리며 다시 파일시스템으로 데이터를 내려쓸 때 암호화합니다. 테이블스페이스 암호화에서는 기존의 인덱스나 foreign key도 암호화되기 이전처럼 그대로 사용할 수 있어 최적의 성능을 낼 수 있도록 해주며 실행계획도 변경되지 않습니다.
암호화된 테이블스페이스 내의 모든 데이터는 디스크에 저장될 때 암호화된 포맷으로 저장되고 접근 권한을 가진 사용자가 데이터를 보거나 수정할 때에 투명하게 복호화되므로 사용자는 데이터가 디스크에 암호화되어 저장되었는지 여부에 대해서 전혀 신경 쓸 필요가 없으며, 데이터 파일이나 백업 미디어 도난 시에는 민감한 데이터 유출을 예방할 수 있습니다.
Tablespace Encryption의 암호화 키
Tablespace Encryption 역시 두 종류의 암호화 키를 이용한다. 각 테이블스페이스 마다 할당되어 테이블스페이스의 데이터를 암호화하는데 사용되는 “테이블스페이스 키”와 테이블스페이스 키를 암호화하여 저장하기 위한 “마스터 키”가 그것이다.
테이블스페이스 암호화는 Transparent Data Encryption(TDE) 아키텍처를 이용합니다. 즉, TDE와 같은 2-tier 구조로 암호화 키를 관리하고 있습니다. 각 테이블스페이스에는 고유의 테이블스페이스 암호화 키가 할당되어 테이블스페이스의 데이터를 암호화/복호화하는데 사용되고 있습니다. 테이블스페이스 키는 해당 테이블스페이스 헤더에 마스터 키로 암호화해서 보관되며 마스터 키는 오라클 wallet에 저장됩니다.
Tablespace Encryption 적용 방법
테이블스페이스 암호화는 Oracle 데이터베이스 11g 이상에서 지원되고 있습니다. 만약 이전 Oracle 버전에서 업그레이드한 경우라면 COMPATIBLE 초기화 파라미터는 11.0.0 또는 그 이상으로 설정되어 있어야 합니다.
Wallet 및 마스터 키 관리
테이블스페이스 암호화는 TDE와 wallet을 공유하기 때문에 관리방식이 동일합니다.
마스터 키 재생성
테이블스페이스 암호화에서는 마스터 키 및 테이블스페이스 키에 대하여 re-key를 지원하지 않습니다. 마스터 키를 재생성해야할 경우 오라클에서는 다음과 같은 방법을 사용할 것을 권장하고 있습니다.
1.) Data Pump 'expdp'를 이용하여 테이블스페이스를 export합니다. 데이터베이스를 백업합니다.
3.) 'dbms_metadata.get_ddl'을 이용하여 암호화된 테이블스페이스를 생성할 때 사용한 DDL을 추출하여 SQL
파일로 따로 저장합니다. (뒤에 스크립트로 이용)
4.) 기존 암호화된 테이블스페이스를 'including contents and datafiles'을 포함하여 drop합니다.
5.) 3번째 단계에서 생성한 스크립트를 이용하여 새로운 암호화 테이블스페이스를 생성합니다. 여기서는 새로운 테이블스페이스 키로 암호화가 됩니다.
6.) Data Pump 'impdp'를 이용하여 테이블스페이스를 import 합니다.
테이블스페이스 암호화 및 테이블스페이스 키 관리
암호화된 테이블스페이스 생성
11g에서는 기존의 CREATE TABLESPACE 명령어에 테이블스페이스 암호화를 설정할 수 있는 ENCRYPTION 절이 추가되었습니다. ENCRYPTION절을 이용하여 암호화 알고리즘을 지정할 수 있습니다. 아울러 스토리지 관련 속성을 지정하는 부분에서 ENCRYPT 키워드를 포함하여 합니다. ENCRYPT 키워드를 통해 실제 암호화가 이루어지게 됩니다.
CREATE TABLESPACE encrypted_ts
DATAFILE '/oracle/app/oracle/oradata/ORCL/tablespace_encryption.dbf' SIZE 150M
ENCRYPTION
DEFAULT STORAGE (ENCRYPT);
Note1: 사용자는 이미 생성된 테이블스페이스에 대해서는 암호화를 할 수 없습니다. 이 경우 암호화 테이블스페이스로 변경하고자 한다면, CREATE TABLE …AS SELECT… 또는 ALTER TABLE…MOVE… 명령어를 이용하여 데이터를 기존의 테이블스페이스에서 암호화된 테이블스페이스로 옮기는 방법을 사용해야 합니다.
Note2: 테이블스페이스 암호화에서는 “NO SALT” 옵션을 사용할 수 없습니다.
Note3: 암호화한 테이블스페이스에 대해서는 암호화를 해제할 수 없습니다. 이 경우 암호화를 지정하지 않은 새로운 테이블스페이스를 생성하여 객체를 모두 재생성해야 합니다.
암호화 알고리즘 지정
테이블스페이스 암호화에서 지원하는 암호화 알고리즘의 종류 및 각 알고리즘의 파라미터 명은 TDE와 동일합니다. (TDE에서 지원하는 암호화 알고리즘 참조)
암호화된 테이블스페이스 생성시 암호화 알고리즘은 다음과 같이 ENCRYPTION절에서 지정합니다.
CREATE TABLESPACE encrypted_ts
DATAFILE '/oracle/app/oracle/oradata/ORCL/tablespace_encryption.dbf' SIZE 150M
ENCRYPTION USING '3DES168' DEFAULT STORAGE (ENCRYPT);
알고리즘을 명시적으로 지정해주지 않으면 AES128이 default로 지정됩니다.
기존 데이터를 암호화된 테이블스페이스로 옮기기
SQL문 중에서는 ALTER TABLESPACE 명령어가 존재하지 않기 때문에 암호화가 안된 테이블스페이스를 바로 암호화 상태로 변경할 수 없습니다. 이런 경우 암호화된 테이블스페이스를 새로 생성하고 기존 데이터를 새로 생성한 테이블스페이스로 옮겨야 합니다.
기존 데이터를 암호화된 테이블스페이스로 옮기는 방법은 다음과 같습니다. 여기서 기존 테이블스페이스명은
original_ts이며 새로 생성한 암호화된 테이블스페이스명은 encrypted_ts입니다..
암호화되지 않은 기존 테이블스페이스를 우선 백업합니다.
그 다음 아래와 같이 암호화된 테이블스페이스를 새로 생성합니다.
CREATE TABLESPACE encrypted_ts
DATAFILE '/oracle/app/oracle/oradata/ORCL/tablespace_encryption.dbf' SIZE 150M
ENCRYPTION
DEFAULT STORAGE (ENCRYPT);
그 후, 기존 테이블스페이스 내의 오브젝트를 새로운 테이블스페이스로 옮깁니다. 필요하면 인덱스 rebuild도 수행합니다.
ALTER TABLE... MOVE를 이용하여 기존 데이터 옮기는 방법
SQL> ALTER TABLE hr.emp_table MOVE TABLESPACE encrypted_ts; Table altered.
SQL> ALTER TABLE hr.dept_table MOVE TABLESPACE encrypted_ts; Table altered.
CREATE TABLE AS SELECT 이용하여 기존 데이터 옮기는 방법
SQL> CREATE TABLE emp_en TABLESPACE encrypted_ts AS SELECT * FROM hr.emp_table; Table created.
SQL> CREATE TABLE dept_en TABLESPACE encrypted_ts AS SELECT * FROM hr.dept_table; Table created.
인덱스 생성
11g에서 제공되는 테이블스페이스 암호화 기능을 이용할 경우 테이블스페이스 내의 데이터는 인덱스 range scan이 가능합니다. 이는 TDE를 이용한 equality search시에만 인덱스를 탈 수 있었던 것과는 대비되는 특징입니다.
테이블스페이스 암호화를 이용하면 테이블스페이스에 해당하는 데이터 블록 전체가 암호화됩니다. 데이터 블록을 읽어 들이는 시점에는 블록 전체가 이미 복호화되어 메모리에 올라오게 됩니다. 따라서 데이터의 대·소 비교가 가능해지므로 인덱스 활용에 제약이 없어지게 됩니다.
다음 예제를 통하여 암호화된 테이블스페이스에 저장된 dept_table 테이블에 접근하는 경우의 실행계획을 조회하여 인덱스 활용여부를 확인해보도록 하겠습니다.
SQL> SELECT table_name,tablespace_name FROM user_tables WHERE table_name='DEPT_TABLE'; TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------ DEPT_TABLE ENCRYPTED_TS
SQL> SELECT tablespace_name, encrypted FROM user_tablespaces
2 WHERE tablespace_name='ENCRYPTED_TS';
TABLESPACE_NAME ENC
------------------------------ --- ENCRYPTED_TS YES
Equality Search 시
SQL> SELECT COUNT(*) FROM dept_table WHERE department_id=200; COUNT(*)
----------
1
SQL> SELECT * FROM table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID g8dhmu9dapbkt, child number 1
-------------------------------------
SELECT COUNT(*) FROM dept_table WHERE department_id=200 Plan hash value: 1887665860
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|
| 0 | SELECT STATEMENT |
| |
| |
| |
| |
1 (100)| |
|
| 1 | SORT AGGREGATE |
| |
| |
1 | |
13 | |
| |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
|* 2 | INDEX UNIQUE SCAN| IDX_ON_DEPT_TABLE | 1 | 13 | 0 (0)|
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
--------------------------------------------------- 2 - access("DEPARTMENT_ID"=200)
19 rows selected.
Range Search
SQL> SELECT COUNT(*) FROM dept_table WHERE department_id>200; COUNT(*)
----------
7
SQL> SELECT * FROM table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID fftcx7bpr252k, child number 0
-------------------------------------
SELECT COUNT(*) FROM dept_table WHERE department_id>200 Plan hash value: 1289497684
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-------
| 0 | SELECT STATEMENT | | | | 1 (100)|
|
| 1 | SORT AGGREGATE | | 1 | 13 | |
|
|* 2 | INDEX RANGE SCAN| IDX_ON_DEPT_TABLE | 7 | 91 | 1 (0)| 00: PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
00:01 |
--------------------------------------------------------------------------------
-------
Predicate Information (identified by operation id):
--------------------------------------------------- 2 - access("DEPARTMENT_ID">200)
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement 23 rows selected.
위와 같이 암호화된 테이블스페이스에 저장된 테이블에 대해서는 equality search하는 경우에도 range search하는 경우에도 모두 인덱스 타는데 제약이 없음을 확인할 수 있습니다.
Tablespace Encryption 관련 딕셔너리 뷰
Tablespace Encryption과 관련된 딕셔너리 뷰는 다음과 같습니다.
n DBA_TABLESPACES
n USER_TABLESPACES
n V$ENCRYPTED_TABLESPACES
각 뷰의 ENCRYPTED 컬럼은 해당 테이블스페이스의 암호화 여부를 보여준다. 다음은 조회 결과이다.
SQL> SELECT tablespace_name, encrypted FROM user_tablespaces WHERE encrypted='YES'; TABLESPACE_NAME ENC
------------------------------ --- ENCRYPTED_TS YES
Tablespace Encryption 사용 시 제약사항
Temporary와 Undo 테이블스페이스는 암호화할 수 없습니다. Bfile와 External 테이블은 암호화할 수 없습니다.
서로 다른 endian을 사용하는 플랫폼간에는 Transportable Tablespace을 통해서 암호화된 테이블스페이스를 이동시킬 수 없습니다.
컬럼 암호화와 테이블스페이스 암호화 비교
컬럼 암호화는 특정 테이블의 특정 컬럼에 대해 암호화를 설정하는 방식이지만, 테이블스페이스 암호화는 해당 테이블스페이스 전체를 암호화하는 블록 레벨 암호화로서 디스크에 기
록되는 시점에 암호화되고 읽히는 시점에 복호화되는 방식입니다. 따라서 컬럼 암호화 방식에서 암호화가 지정된 컬럼에 대해서는 미디어는 물론 메모리에서도 데이터가 암호화된 상
태로 저장 및 관리됩니다. 반면 테이블스페이스 암호화로 암호화 설정된 데이터는 블록이 메모리에 올라올 때 이미 복호화되어 올라오고, 미디어에 내려쓸 때 암호화되어 기록되므로 암
호화로 인한 오버헤드는 I/O 작업 시에만 발생합니다. 이 때문에 컬럼 암호화 방식일 경우에는 인덱스 range scan이 지원되지 않지만 테이블스페이스 암호화에서는 인덱스 range scan이
가능합니다.
컬럼 암호화는 transportable tablespace를 지원하지 않지만 테이블스페이스 암호화에서는 지원됩니다. 소스 플랫폼과 대상 플랫폼의 endian이 동일하고, 동일한 wallet을 사용하는 경우
에는 테이블스페이스 암호화를 이용하여 암호화한 테이블을 transportable tablespace를 이용하여 이동시킬 수 있습니다.
*Note : 컬럼 암호화는 미디어에 저장된 데이터에 대한 보호 솔루션이므로 SGA 메모리 상에 clear text가 남는 것이 보안 정책에 위배된다고 볼 수는 없으며, temporary 테이블스페이스에
기록되는 데이터 또한 보호되는 특징을 통해 이를 정확하게 준수하고 있음을 확인할 수 있습니다.
컬럼 암호화 vs 테이블스페이스 암호화
사용자는 컬럼 암호화와 테이블스페이스 암호화 중 어떤 암호화 방식을 사용할지 고민할 수 있습니다. 다음의 경우에 해당한다면 컬럼 암호화를 사용하도록 권장하고 있습니다.
n 몇 개의 컬럼만을 암호화하는 경우
n Index Range Scan을 별로 사용하지 않는 경우
n 테이블 키와 마스터 키를 쉽게 re-key하고 싶은 경우
그리고 다음의 경우에는 테이블스페이스 암호화 방식을 사용하도록 권장하고 있습니다.
n 모든 민감한 데이터가 무엇인지를 파악하기 어려운 경우
n 많은 양의 데이터를 암호화하는 경우
n range scan 인덱스를 사용해야 할 경우
n 테이블스페이스를 전송해야 할 경우 (transport tablespace)
마스터 키 보관 장소
TDE 마스터 키는 외부 보안 모듈(external security module)에 저장이 되는데 11g부터는 HSM이 지원되므로 보다 안전하게 마스터 키를 보관할 수 있게 되었습니다. 다음 표는 오라클 버전별로 HSM에 대한 지원내역을 보여주고 있습니다.
|
Oracle 버전 |
Master Key for… |
Oracle Wallet |
HSM |
|
Oracle 10gR2 |
컬럼 암호화 |
○ |
X |
|
Oracle 11gR1 (11.1.0.6) |
컬럼 암호화 |
○ |
○ |
|
테이블스페이스 암호화 |
○ |
X | |
|
Oracle 11gR1 (11.1.0.7) |
컬럼 암호화 |
○ |
○ |
|
테이블스페이스 암호화 |
○ |
○ |
키에 대한 Re-Key 지원여부
TDE 컬럼 암호화에서는 마스터 키 및 테이블 키 모두에 대해 re-key가 가능합니다. 마스터 키를 re-key하는 경우에는 애플리케이션의 성능이나 가용성에 아무런 지장을 주지 않습니다. 마스터 키로 암호화한 해당 테이블 키들만 복호화해서 다시 새로 암호화하기 때문입니다. 하지만 테이블 키를 re-key하는 경우에는 해당 데이터를 모두 복호화하고 나서 새로운 테이블 키로 다시 암호화해야 하는 과정을 거쳐야하기 때문에 조금 더 신중히 고려해야 합니다. 이는 곧 테이블에 대한 full update을 수행하는 것과 같습니다.
11g부터 지원되는 테이블스페이스 암호화에서는 다음 표에서 보이듯이 마스터 키 및 테이블스페이스 키에 대한 re-key가 지원되지 않기 때문에 암호화된 테이블스페이스에 대한 re-key 작업이 필요한 경우에는 테이블스페이스 내의 데이터를 모두 새로 암호화된 테이블스페이스로 옮기는 것을 권하고 있습니다.
|
|
TDE 컬럼 암호화 |
TDE 테이블스페이스 암호화 | ||
|
Re-key 지원 |
마스터 키 |
테이블 키 |
마스터 키 |
테이블스페이스 키 |
|
○ |
○ |
X |
X | |
Enterprise Manager (EM)를 이용한 TDE 관리
11g부터는 TDE 기능을 Enterprise Manager Database Control를 통해 설정 및 관리할 수 있게 되었습니다. Wallet의 open/close, 위치 이동 및 새로운 마스터 키 생성 등의 작업은 모두 Enterprise Manager를 통해서도 가능하며 테이블 및 테이블스페이스 생성 과정에서 TDE 관련 옵션을 설정할 수 있는 화면이 제공됩니다.
다음 EM 화면에서 TDE 관련 링크를 확인할 수 있습니다.
EM을 통해서 다음과 같이 암호화를 설정할 수 있습니다.
다음은 암호화 관련 여러 옵션사항을 설정할 수 있는 페이지입니다.
TDE를 적용할 수 있는 여러 Oracle Database 기능들
TDE를 이용해서 암호화된 컬럼의 데이터는 datafile, undo segment, redo log file에 모두 암호화된 형태로 저장됩니다. 때문에 10g까지는 LogMiner를 이용해서 redo log를 확인해보면 암호화된 컬럼의 데이터는 확인할 수 없었습니다.
예를 들어, 다음과 같이 CUST_PAYMENT_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에 저장합니다. 물론 이때는 대상 테이블의 마스터 키가 들어있는 wallet이 open된 상태이어야 합니다.
Note: TDE는 access control을 위한 솔루션이 아닌 파일 레벨에 대한 암호화 솔루션이기 때문에 V$LOGMNR_CONTENTS에 clear text가 저장되는 것이 보안 정책에 위배되는 것이 아님에 주의하십시오.
Data Guard
Physical Standby
TDE는 10gR2부터 Data Guard의 Physical Standby를 지원하고 있습니다. primary에서 secondary로 리두 로그 파일 전송시 데이터는 암호화된 상태로 전송됩니다. 여기서 secondary 사이트가 READ ONLY모드에 있거나 failover가 일어날 때는 primary의 마스터 키가 필요합니다. 단순히 리두 로그를 적용할 때는 마스터 키가 필요하지 않습니다. 오라클에서는 failover시 보다 신속하게 데이터를 가용상태로 전환하기 위해 primary의 wallet을 secondary 사이트로 모두 복사할 것을 권장합니다. 암호화된 데이터를 로그 파일에 암호화된 상태로 있으며 로그 파일을 secondary쪽으로 전송할 시에도 암호화되어 있습니다.
Primary에서 마스터 키를 re-key하는 경우 wallet을 모든 secondary 사이트로 다시 복사해야 합니다. 만약 secondary 사이트에서 기존 wallet이 오픈되어 있는 경우 먼저 닫아서 기존 마스
터 키가 메모리에서 삭제가 되도록 합니다. 그런 후에 새로운 wallet을 오픈하여 새로운 마스터 키가 메모리로 로딩될 수 있도록 합니다.
Logical Standby
Logical Standby는 LogMiner를 이용해서 Redo Log를 SQL문장으로 변환해서 Standby 데이터베이스에 적용하는 SQL Apply를 구현하므로, 11g부터 LogMiner가 TDE 지원하게 되면서 자동적으로 Logical Standby도 TDE를 지원하게 되었습니다.
11g의 Logical Standby에서 TDE 기능을 가능하게 하기 위해서는 반드시 primary와 standby 데이터베이스가 같은 마스터 키를 사용하도록 primary 데이터베이스의 wallet을 standby 데이터
베이스로 복사해서 사용해야 합니다. 여기서 마스터 키가 재생성(추가) 명령어는 replicate되지 않으므로 primary 데이터베이스에서 마스터 키를 재생성할 때마다 반드시 primary에서
standby로 wallet을 다시 복사해 주어야 합니다. Standby 데이터베이스에서는 마스터 키 재생성 명령어를 수행할 수 없습니다.
Standby 데이터베이스에서만 복사해온 wallet의 비밀번호를 변경하거나, standby 데이터베이스의 컬럼 키를
rekey 하는 것은 가능합니다.
Streams
Oracle Database 11g부터 TDE는 Streams도 지원합니다. Streams 엔진이 암호화된 데이터를 복호화하여 데이터 전송 (character sets, database versions, platforms, 등)을 할 수 있도록 하며
다른 데이터베이스로 전송 시 암호화되어 있지 않아 Oracle Advanced Security Network Encryption을 사용하여 트래픽을 암호화하도록 권장하고 있습니다. 데이터를 전송받는 쪽에서 만약
데이터를 못 받게 되서 임시로 데이터를 보관해야할 경우, 기존에 암호화된 데이터는 암호화된 채로 디스크에 저장됩니다.
11g
text 형태로 전송되기 때문에 local wallet이 source wallet 및 master key와 동일할 필요가 없습니다.
Real Application Clusters(RAC)와 TDE
Real Application Clusters (RAC) 환경
오라클 RAC 환경에서 TDE 사용시 다음과 같은 wallet 형태에 마스터 키를 보관할 수 있습니다. 오라클은 wallet을 shared device에 보관하는 것을 지원하지 않습니다.
n Wallet을 로컬에 복사하여 사용하는 형태
n HSM기반 wallet을 사용하는 형태
두 경우 모두 TDE를 사용하기 전에 모든 RAC 인스턴스에 대해서 wallet을 오픈해야합니다.
RAC 환경에서 TDE 사용시 다음과 같은 사항을 주의하십시오.
n 마스터 키를 설정하거나 re-key시 wallet을 열거나 닫는 명령을 수행해서는 안됩니다.
n 마스터 키를 설정하거나 re-key시 TDE 암복호화 작업을 수행해서는 안됩니다.
n RAC에서 wallet을 오픈하기 위해서는 모든 인스턴스에서 wallet이 오픈되어 있어야합니다.
n RAC에서 wallet을 닫기 위해서는 모든 인스턴스에서 wallet을 닫아야 합니다.
RAC 환경에서 TDE를 위한 wallet 설정
RAC 설치 후 다음과 같은 방법으로 wallet 및 마스터 키를 생성하고 설정합니다.
마스터 키 생성 및 설정
n 마스터 키를 wallet에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "wallet_password";
n 마스터 키를 HSM 장치에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "user_ID:HSM_password";
wallet을 나머지 인스턴스로 복사
마스터 키를 wallet에 보관하는 경우에는 생성한 wallet을 나머지 모든 인스턴스에 복사를 해야합니다. 이때는 각 인스턴스의 sqlnet.ora 파일에 있는 wallet 위치에 복사를 합니다. wallet을 복사한 후 모든 인스턴스에 있는 wallet을 오픈하여 각 인스턴스의 메모리에 올라오도록 합니다. HSM 장치에 마스터 키를 보관하는 경우에도 각 인스턴스의 wallet을 오픈합니다.
Wallet을 각 노드로 복사하는 대신 마스터 키를 HSM 장치를 이용하여 마스터 키를 보관할 수 있습니다. 네트워크 드라이브에 스토리지 공유하는 것보다는 HSM 장치를 사용할 것을 권장하고 있습니다. 이유는 HSM 장치에서는 마스터 키를 자동으로 복제해주어 모든 인스턴스에서 사용할 수 있도록 해줍니다.
모든 인스턴스에서 wallet을 오픈
다음 SQL문을 모슨 인스턴스에서 실행하여 wallet을 오픈합니다..
n 마스터 키를 wallet에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "wallet_password";
n 마스터 키를 HSM 장치에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "user_ID:HSM_password";
RAC 환경에서 마스터 키 re-key 방법
마스터 키 re-key하기
n 마스터 키를 wallet에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "wallet_password";
n 마스터 키를 HSM 장치에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "user_ID:HSM_password";
wallet을 나머지 인스턴스로 복사
마스터 키를 wallet에 보관하는 경우에는 위에서 re-key한 인스턴스의 wallet을 나머지 모든 인스턴스에 복사를 합니다. Wallet을 복사한 후 닫았다가 다시 오픈을 수행합니다. 모든 인스턴스에 대해서 wallet을 오픈한 후에야 다시 마스터 키를 re-key할 수 있습니다.
모든 인스턴스에서 wallet 닫기
다음 SQL문을 모든 인스턴스에서 실행하여 RAC 데이터베이스의 wallet을 닫아줍니다.
SQL> ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;
모든 인스턴스에서 wallet을 오픈
다음 SQL문을 모슨 인스턴스에서 실행하여 wallet을 오픈합니다..
n 마스터 키를 wallet에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "wallet_password";
n 마스터 키를 HSM 장치에 보관하는 경우:
SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "user_ID:HSM_password";
Note: 오라클에서는 키를 공유하는 경우 HSM 장치를 사용할 것을 권장합니다. 네트워크 파일 시스템에 shared copy를 두고 사용하는 경우 하나의 인스턴스에서 마스터 키를 re-key하게 되면 마스터 키가 변경되었다는 것을 다른 인스턴스에게 notify하는 방법이 없으므로 다른 인스턴스에서는 이전 마스터
키를 계속 사용할려고 하여 이런 인스턴스에서는 컬럼 키를 더 이상 복호화할 수 없습니다. RAC 환경에서 re-key해야 할 경우 wallet을 나머지 모든 인스턴스로 복사한 후 각각의 wallet을 닫았다가 다시 오픈해야 합니다.
마치며
TDE 암호화 기능을 통하여 미디어에 보관중인 데이터를 보호할 수 있습니다. 사용자는 기존 애플리케이션 코드를 수정할 필요없이 중요한 데이터를 투명하게 암호화할 수 있습니다. 컬럼 레벨 암호화 및 테이블스페이스 레벨 암호화 모두가 지원되므로 사용자의 필요에 따라 적합한 방식을 선택하여 암호화를 적용할 수 있습니다. TDE를 통해 기업의 미디어 레벨의 보안성을 한층 더 높일 수 있기를 기대합니다.
'DB - ORACLE > DB 보안 & 암호화' 카테고리의 다른 글
| ORACLE ASO TDE 설정 방법 - 초기세팅 (0) | 2016.08.29 |
|---|---|
| FGA(Fine Grating Auditing) (0) | 2015.12.30 |
| SQL*PLUS Security(PRODUCT_USER_PROFILE) (0) | 2015.11.23 |
| O7_DICTIONARY_ACCESSIBILITY Parameter 의 중요성 (0) | 2015.11.20 |
| Listener 통해 들어오는 IP 허용 & 차단 (0) | 2015.11.19 |