ORACLE Transparent Data Encryption [TDE] Overview

Transparent Data Encryption

사 용자들은 암호화의 효용성에 대해 엇갈린 반응을 보이곤 합니다. 암호화는 필요한 기술이지만, 키 관리의 복잡성으로 인해 올바르게 설정되지 않은 경우 효율적이지 못한 결과를 초래할 수도 있습니다. 또 대부분의 애플리케이션 설계자들은 키 값의 암호화 및 해독 과정에서 수반되는 성능 오버헤드를 우려합니다. 이러한 이유로 암호화를 적용하지 않는 대신 패스워드, 인증 메커니즘 등의 변경 보안(perimeter protection)을 강화하는 쪽을 선택하는 경우가 많습니다. 하지만, 서버(또는 디스크)를 통째로 훔쳐, 동일한 운영체제에 서버를 마운트하고 데이터에 접근하는 경우를 가정해 볼 수 있습니다. 또는 내부사용자가 업무 수행 과정에서 DBA의 권한으로 데이터베이스에 접근하여 중요한 정보를 빼내는 경우를 생각해 볼 수 있습니다. 미 캘리포니아주에서는, 이와 같은 상황이 발생한 경우, 영향 범위에 있는 모든 고객들에게 보안 침해 사실을 통보하도록 법적으로 규정하고 있습니다 (다른 주에서도 이와 유사한 법안이 발의될 예정입니다). (흔히 경험할 수 있는 것은 아니지만 결코 무시할 수 없는) 이러한 사고에서는, 인증 메커니즘이 아무런 효과를 갖지 못합니다. 보안이 각별히 중시되는 환경에서 TDE(transparent data encryption)이 중요한 기능으로 활용되고 있는 것도 바로 이 때문입니다. TDE는 복잡한 키 관리 업무를 데이터베이스 엔진 내부에서 수행하는 암호화 기술입니다. 또 DBA는 데이터베이스 테이블의 관리에 필요한 모든 권한을 갖지만, 반면 모든 데이터를 직접 조회할 수는 없도록 통제 가능합니다. Oracle Database 10g Release 2의 TDE는, 특정 테이블의 하나 또는 그 이상의 컬럼을 쉽게 암호화할 수 있는 기능을 제공합니다. 관리자는 코드를 전혀 작성하지 않고도 컬럼을 암호화 대상으로 정의할 수 있습니다. 암호화는 기본적으로 입력 값을 암호화하기 위한 키(key)와 알고리즘을 필요로 합니다. TDE는 암호화를 위한 키를 자동으로 생성합니다. 이러한 방식은 키 관리를 단순화해 준다는 장점이 있지만 유출의 가능성이 더 높아진다는 단점도 뒤따릅니다. 이러한 문제를 보완하기 위해 또 다른 키(master key)가 데이터베이스 레벨에서 설정됩니다. 테이블 키는 마스터 키와 함께 암호화되며, 따라서 특정 컬럼을 해독하기 위해서는 테이블 키와 마스터 키가 함께 필요합니다. (암호화 기술 및 오라클의 암호화 패키지 구현방식에 대한 자세한 정보는 필자가 기고한 오라클 매거진 기사 ?"Encrypt Your Data Assets- 를 참고하시기 바랍니다.) 마스터 키는 “wallet”이라고 부르는 데이터베이스 외부의 별도 저장소에 저장됩니다. (wallet의 디폴트 위치는 “$ORACLE_BASE/admin/$ORACLE_SID/wallet”으로 정의됩니다.) 그 개념적인 구조가 아래 그림과 같습니다.

TDE가 설정되고 나면 (좀 더 정확히 말해 wallet과 마스터 키가 설정되고 나면), 이 설정을 이용하여 데이터를 보호할 수 있습니다. 테이블의 컬럼을 암호화하려면 아래와 같은 SQL 구문을 사용해야 합니다:

create table accounts ( acc_no number not null, first_name varchar2(30) not null, last_name varchar2(30) not null, SSN varchar2(9) ENCRYPT USING 'AES128', acc_type varchar2(1) not null, folio_id number ENCRYPT USING 'AES128', sub_acc_type varchar2(30), acc_open_dt date not null, acc_mod_dt date, acc_mgr_id number )

위 구문에서는 SSN 컬럼과 FOLIO_ID 컬럼에 TDE를 적용하여 두 컬럼의 데이터를 암호화하였습니다. 하지만 사용자가 테이블을 조회하면, 데이터가 인출되는 과정에서 자동으로 해독 작업이 수행되기 때문에 데이터는 일반 텍스트의 형태로 보여지게 됩니다. 하지만 디스크가 도난 당한 경우에는, 테이블 세그먼트에 저장된 정보가 암호화된 상태로 유지되며, 이 값을 해독하기 위해서는 테이블 키가 무엇인지 알아야 합니다. 테이블 키를 얻으려면 마스터 키가 필요하지만, 이 키는 데이터베이스 외부에 존재하므로 해독이 불가능하게 됩니다. SSN 컬럼과 FOLIO_ID 컬럼에 대한 정의에서 128-비트 AES(Advanced Encryption Standard)를 이용한 ENCRYPT 옵션이 적용되었음을 주목하시기 바랍니다. 데이터베이스의 wallet은 사전 설정되어 있습니다. 이 wallet의 암호를 설정하기 위해서는 아래와 같은 명령을 사용합니다:

alter system set encryption key authenticated BY "topSecret";

이 명령은 기존에 wallet이 존재하지 않는 경우 wallet을 자동생성하고, 암호를 “topSecret”로 설정합니다 (암호는 대소문자를 구별합니다). 이와 같이 설정한 후 테이블의 생성/수정 과정에서 컬럼 별로 암호화 여부를 결정할 수 있습니다.

External Table의 암호화

위 예에서는, 컬럼의 암호화를 위해 해시 테이블(hash table)을 사용했습니다. External table에 대해 TDE를 적용하는 것 또한 가능합니다. 예를 들어 ACCOUNTS 테이블의 데이터를 다른 위치에 덤프하고자 하는 경우, 다음과 같은 간단한 ENCRYPT 구문을 적용하면 됩니다.

create table account_ext organization external ( type oracle_datapump default directory dump_dir location ('accounts_1_ext.dmp', 'accounts_2_ext.dmp', 'accounts_3_ext.dmp', 'accounts_4_ext.dmp') ) parallel 4 as select ACC_NO, FIRST_NAME, LAST_NAME, SSN ENCRYPT IDENTIFIED BY "topSecret", ACC_TYPE, FOLIO_ID ENCRYPT IDENTIFIED BY "topSecret", SUB_ACC_TYPE, ACC_OPEN_DT, ACC_MOD_DT from accounts;

accounts_*_ext.dmp 파일의 SSN 컬럼 및 FOLIO_ID 컬럼은 암호화된 형태로 저장됩니다. 이 파일을 external table로 활용하고자 하는 경우, 파일을 읽기 위한 패스워드(topSecret)를 제시해야 합니다. 지금까지 설명한 것처럼 TDE는 매우 유용한 액세스 컨트롤 메커니즘으로 활용이 가능합니다. http://iclickyou.com/1353 - 참고자료 - http://www.oracle.com/technology/global/kr/products/database/oracle11g/pdf/advanced-security-11g-datasheet_kor.pdf

Overview of Transparent Data Encryption The Oracle database provides security in the form of authentication, authorization, and auditing. Authentication ensures that only legitimate users gain access to the system. Authorization ensures that those users only have access to resources they are permitted to access. Auditing ensures accountability when users access protected resources. Although these security mechanisms effectively protect data in the database, they do not prevent access to the operating system files where the data is stored. Transparent data encryption enables encryption of sensitive data in database columns as it is stored in the operating system files. In addition, it provides for secure storage and management of encryption keys in a security module external to the database. Using an external security module separates ordinary program functions from those that pertain to security, such as encryption. Consequently, it is possible to divide administration duties between DBAs and security administrators, a strategy that enhances security because no administrator is granted comprehensive access to data. External security modules generate encryption keys, perform encryption and decryption, and securely store keys outside of the database. Transparent data encryption is a key-based access control system that enforces authorization by encrypting data with a key that is kept secret. There can be only one key for each database table that contains encrypted columns regardless of the number of encrypted columns in a given table. Each table's column encryption key is, in turn, encrypted with the database server's master key. No keys are stored in the database. Instead, they are stored in an Oracle wallet, which is part of the external security module. Before you can encrypt any database columns, you must generate or set a master key. This master key is used to encrypt the column encryption key which is generated automatically when you issue a SQL command with the ENCRYPT clause on a database column.

See Also: Oracle Database Advanced Security Administrator's Guide for details about using transparent data encryption