Oracle TDE ( oracle 10g )

Transparent Data Encryption

투명한 데이터 암호화 

단 한 줄의 코드도 작성하지 않고 기밀 데이터를 투명하게 암호화합니다. 

누군가가 데이터베이스 백업 테이프를 훔쳐가는 것은 조직에게는 최악의 악몽입니다.
물론 보안 시스템을 구축하고 매우 중요한 기밀 자산은 암호화하고 데이터베이스 서버에 방화벽을 설치했습니다.
그러나 침입자가 쉽게 접근했습니다.
침입자는 백업 테이프를 가져가서 틀림 없이 다른 서버에서 데이터베이스를 복원하여 데이터베이스를 시작하고 느긋하게 데이터를 보고 있습니다.
그러한 침입자로부터 데이터베이스 데이터를 보호하는 것은 훌륭한 업무방식이 아닙니다.
그것은 대부분의 법률,
규정,
지침을 준수하기 위한 요구 사항입니다.
이러한 취약성으로부터 데이터베이스를 어떻게 보호할 수 있겠습니까?

한 해결책은 데이터베이스의 기밀 데이터를 암호화하고 별도의 위치에 암호화 키를 저장하는 것입니다.
암호화 키 없이 훔쳐간 데이터는 쓸모가 없습니다.
그러나 두 상반된 개념 간의 균형을 유지해야 합니다.
그 개념이란 애플리케이션이 암호화 키에 액세스할 수 있는 편리성과 키 절도를 방지하는데 필요한 보안성입니다.
그리고 회사와 연방 정부 규정을 준수하기 위해 복잡한 코딩 없이 즉시 솔루션이 필요합니다. 

Oracle Database 10g Release
2의 새로운 기능을 사용하여 그렇게 할 수 있습니다.
단 한 줄의 코드도 작성하지 않고 열을 암호화됨으로 선언할 수 있습니다.
사용자가 데이터를 삽입할 때 데이터베이스가 투명하게 데이터를 암호화하여 그 열에 저장합니다.
마찬가지로 사용자가 열을 선택할 때 데이터베이스가 데이터를 자동으로 해독합니다.
이러한 모든 프로세스가 투명하게 애플리케이션의 코드를 변경하지 않고 수행되기 때문에 이 기능에는 이에 잘 어울리는 TDE(투명한 데이터 암호화)라는 이름이 붙여졌습니다. 

작동 방식 

전에 Oracle
Magazine 1/2월호 “데이터 자산의 암호화”
에서 암호화 기초에 대해 다루었습니다.
주요 사항을 다시 설명하면,
암호화는 암호화 알고리즘과 암호화 키를 일반 텍스트 입력 데이터에 적용해야 합니다.
그리고 암호화된 값을 성공적으로 해독하려면 동일한 알고리즘과 키 값을 알아야 합니다.

그 기사에서 저는 오라클이 제공하는 암호화 툴을 사용하여 암호화 기반 구조를 구축하는 방법을 설명하였습니다.
그러나 Oracle Database 10g Release
2와 TDE를 사용할 경우 암호화 기반 구조를 구축할 필요가 없습니다.
단지 암호화할 열을 정의하기만 하면Oracle
Database
10g에서 그 열이 포함된 테이블에 대한 암호화 방식의 안전한 암호화 키를 생성하고 지정한 암호화 알고리즘을 사용하여 그 열의 일반 텍스트 데이터를 암호화합니다.
이 테이블 키를 보호하는 것이 매우 중요합니다.
Oracle Database
10g는 지갑이라고 부르는 안전한 위치에 저장되는 마스터 키를 사용하여 데이터를 암호화합니다.
이 마스터 키는 데이터베이스 서버의 파일일 수 있습니다.
암호화된 테이블 키는 데이터 딕셔너리에 저장됩니다.
사용자가 암호화됨으로 정의된 열에 데이터를 입력할 경우 그림 1에서와 같이 Oracle
Database 10g가 지갑에서 마스터 키를 가져와 데이터 딕셔너리의 암호화 키를 해독하고 입력 값에 대해 그 암호화 키를 사용하고 데이터베이스에 암호화된 데이터를 저장합니다.

테이블의 모든 열을 암호화할 수 있습니다.
그림 1과 같이 테이블에 열이 4개 있고 열 2와 3을 암호화할 경우 Oracle
Database 10g는 테이블에 대하여 하나의 암호화된 테이블 키를 생성하고 그 키를 사용하여 두 열을 암호화합니다.
디스크에 열 1과 열 4의 값을 일반 텍스트로 저장하고 다른 두 열의 값은 암호화된 형식으로 저장됩니다.
데이터가 암호화되어 저장되기 때문에 백업과 아카이브된 로그 등 모든 다운스트림 구성 요소는 암호화된 형식을 갖습니다.

사용자가 암호화된 열을 선택할 경우 Oracle
Database 10g는 투명하게 데이터 딕셔너리에서 암호화된 테이블 키를 검색하고 지갑에서 마스터 키를 인출한 다음 테이블 키를 해독합니다.
그런 다음 데이터베이스가 디스크의 암호화된 데이터를 해독하여 일반 텍스트로 사용자에게 반환합니다.

이 암호화된 데이터를 사용할 경우 디스크의 데이터가 도난되어도 훔친 데이터의 일부가 아니라 지갑에 저장되어 있는 마스터 키 없이 데이터를 검색할 수 없습니다.
지갑을 도난 당할 경우에도 지갑 암호 없이 마스터 키를 검색할 수 없습니다.
그러므로 그 침입자는 디스크를 훔치거나 데이터 파일을 복사하더라도 데이터를 해독할 수 없습니다.
이것은 여러 규정과 행정 명령(directive)에 대한 준수 요구 사항을 충족합니다.
그리고 이러한 모든 프로세스가 애플리케이션의 변경이나 복잡한 암호화 작성,
키 관리 시스템 없이 수행됩니다.
그러면 지금부터 TDE를 설정하고 사용하는 방법에 대해 설명하겠습니다.

단 한번의 설정 

처음 TDE를 사용할 경우 지갑 위치를 지정하고 지갑 암호를 설정하고 지갑을 열어야 합니다. 

1. 지갑 위치를 지정합니다.
처음 TDE를 설정할 경우 마스터 키를 저장할 지갑을 생성해야 합니다.
기본적으로 지갑은 디렉토리 $ORACLE_BASE/admin/$ORACLE_SID/wallet에서 생성됩니다.
그러므로 $ORACLE_BASE is /u01/app/oracle
및 $ORACLE_SID가 SWBT4일 경우 지갑은 디렉토리 /u01/app/oracle/admin/SWBT4/wallet에 저장됩니다.
$ORACLE_HOME/network/admin
디렉토리에 저장되는 sqlnet.ora
파일에서 디렉토리를 지정하여 다른 디렉토리를 선택할 수 있습니다.
예를 들어 지갑을 /orawall
디렉토리에 저장하려면 sqlnet.ora
파일에 다음 행을 추가합니다.

ENCRYPTION_WALLET_LOCATION =

(SOURCE=

   (METHOD=file)

     (METHOD_DATA=

       (DIRECTORY=/orawall)))

이 예제에서는 기본 위치가 선택된 것으로 가정합니다.
또한 지갑 위치를 정기적 백업에 포함시켜야 합니다.

2. 지갑을 생성합니다.
이제 지갑을 생성하고 지갑에 액세스하기 위한 암호를 설정합니다.
이 작업을 하려면 ALTER
SYSTEM 권한을 가진 사용자로서 다음 명령을 실행합니다. 

alter system set encryption key

authenticated by “remnant”;

이 명령은 다음을 수행합니다. 

· 단계 1에서 지정한 위치에 지갑을 생성합니다. 

· 지갑의 암호를 “remnant”로 설정합니다. 

· 마스터 키를 저장하고 검색할 TDE에 대한 지갑을 엽니다. 

암호는 대소문자를 구분하며 큰 따옴표로 묶어야 합니다.
암호 “remnant”는 어느 동적 성능 뷰나 로그에도 일반 텍스트로 표시되지 않습니다.

지갑 열기 

지갑은 한 번만 생성되기 때문에 앞의 두 단계는 한 번만 수행해야 합니다.
그러나 데이터베이스 인스턴스가 시작된 후에 지갑을 명시적으로 열어야 합니다.
지갑을 생성할 때(앞의 단계 2)
사용할 지갑을 열어야 합니다.
지갑을 생성하고 암호를 설정한 후 데이터베이스를 열 때마다 동일한 암호를 사용하여 다음과 같이 지갑을 열어야 합니다. 

alter system set encryption wallet open authenticated
by “remnant”;

지갑을 닫으려면 다음 명령을 실행합니다. 

alter system set encryption wallet
close;

TDE를 사용하려면 지갑을 열어야 합니다.
지갑이 닫혀 있는 경우 암호화되지 않은 열에 액세스할 수 있으나 암호화된 열에는 액세스할 수 없습니다. 

열 암호화 

TDE를 사용하여 열을 암호화하려면 단지 열 정의에 간단한 절, ENCRYPT를 추가하기만 하면 됩니다.
그러나 추가하기 전에 사용할 암호화 유형과 키 길이를 선택해야 합니다.
이 문제에 대한 자세한 설명은 위에서 언급한 “데이터 자산의 암호화”
기사를 참조하십시오.

정규 스키마에서 다음의 계정 소유자의 테이블이 있다고 가정합시다. 

ACC_NO      NUMBER

ACC_NAME    VARCHAR2(30)

SSN         VARCHAR2(9)

현재 테이블의 모든 데이터는 일반 텍스트입니다.
주민등록번호가 저장된 열 SSN을 변환하여 암호화됨으로 저장하려고 합니다.
다음 명령을 실행할 수 있습니다. 

alter table accounts modify (ssn
encrypt);

이 명령문은 다음 두 작업을 수행합니다. 

· 테이블에 대한 암호화 키를 생성합니다.
암호화된 형식을 사용하여 동일한 테이블의 다른 열을 변경할 경우 동일한 테이블 키가 사용됩니다. 

· 열의 모든 값을 암호화된 형식으로 변환합니다. 

이 명령은 열의 데이터 유형이나 크기를 변경하지 않으며 트리거 또는 뷰를 생성하지 않습니다.

기본적으로 192비트 키를 사용하는 알고리즘 AES가 암호화에 사용됩니다.
명령에 해당 절을 추가적으로 지정하여 다른 알고리즘을 선택할 수 있습니다.
예를 들어 128비트 AES
암호화를 사용하려면 다음과 같은 명령을 사용합니다. 

alter table accounts modify (ssn encrypt using
‘AES128’);

AES128, AES192, AES256 또는 3DES168(168비트 Triple DES
알고리즘)을 절로서 사용할 수 있습니다.
이 값은 설명할 필요 없이 자명합니다.
예를 들어AES256은 256비트 키를 사용하는 AES(Advanced
Encryption Standard)
알고리즘을 의미합니다.

열을 암호화한 후 테이블을 설명할 때 다음이 나타납니다. 

SQL> desc accounts

Name       Null?      Type

————   ————   ————————————————–

ACC_NO              NUMBER

ACC_NAME      VARCHAR2(30)

SSN              VARCHAR2(9)
ENCRYPT

데이터 유형 다음의 ENCRYPT 키워드에 주의하십시오.
데이터베이스에서 암호화된 열을 찾으려면 데이터 딕셔너리 뷰 DBA_ENCRYPTED_COLUMNS를 검색할 수 있습니다.
(SYS
소유 테이블에 대해 TDE를 사용할 수 없습니다.) 

성능 고려 사항 

암호화와 해독은 CPU
주기를 소비하기 때문에 성능에 대한 영향을 고려해야 합니다.
테이블의 암호화되지 않은 열에 액세스할 때 성능은 TDE가 없는 테이블과 다르지 않습니다.
그러나 암호화된 열에 액세스할 때 selects
시 해독하는 동안과 inserts
시 암호화하는 동안 작은 성능 오버헤드가 발생하며 따라서 열을 선택적으로 암호화해야 합니다.
열을 암호화할 필요가 없을 경우 다음을 사용하여 TDE를 해제할 수 있습니다.

alter table account modify (ssn
decrypt);

또한 인덱스 사용을 고려하십시오.
위 예에서 열 SSN에 in_accounts_ssn이라는 이름의 인덱스가 있다고 가정합시다. ACCOUNTS 테이블에 대한 질의에 다음과 같이 동등 술어가 있을 경우 

select * from accounts

where ssn = ‘123456789’;

인덱스 in_accounts_ssn이 사용됩니다.
질의에서 다음과 같이 LIKE 술어를 사용할 경우 

select * from accounts

where ssn like ‘123%’;

인덱스가 무시되고 전체 테이블 스캔이 사용됩니다.
그 이유는 간단합니다.
인덱스의 B
트리 구조에서 앞 몇 문자가 동일한 값(“fraternal”,
“fraternity”
등)은 물리적으로 서로 가까이 있습니다. LIKE 술어를 처리할 때 Oracle
Database 10g는 패턴 일치를 사용하여 인덱스 항목을 검색하고 물리적 근접성이 인덱스 검색 속도를 증가시키므로 전체 테이블 스캔보다 좋습니다.

그러나 열을 암호화할 경우 인덱스의 실제 값이 암호화되었기 때문에 크게 다르고 따라서 인덱스 전역에 흩어져 있습니다.
그렇기 때문에 전체 테이블 스캔보다 인덱스 스캔이 더 많은 리소스를 사용합니다.
그래서 이 LIKE 술어 질의 예제에서 Oracle
Database 10g는 인덱스를 무시하고 전체 테이블 스캔을 선택합니다.
동등 술어의 경우 패턴을 따르는 여러 값 대신에 특정 인덱스 항목이 검색됩니다.
그래서 인덱스를 사용한 실행 경로가 전체 테이블 스캔보다 속도가 빠르며 최적기가 인덱스 사용을 선택합니다.
암호화할 열을 결정할 때 암호화가 인덱스에 얼마나 영향을 주는지 고려하고 암호화 열을 포함하는 특정 질의를 재작성해야 하는 경우가 있으니 주의하십시오.

키와 암호 관리 

누군가가 테이블 키를 알고 있거나 암호화된 테이블 키를 해독했을지도 모른다는 의심이 들 때에는 어떻게 할까요?
간단하게 테이블에 대한 새 키를 생성할 수 있고 간단한 명령을 실행하여 새로운 테이블 키를 사용하여 암호화된 열 값을 다시 생성할 수 있습니다.
또한 이 작업을 할 때 AES256 등 다른 암호화 알고리즘을 선택할 수도 있습니다.
다음 명령을 수행하여 두 작업을 수행할 수 있습니다. 

alter table accounts rekey using
‘aes256’;

누군가가 지갑 암호를 알고 있을 경우 어떻게 할까요?
Oracle Wallet
Manager를 사용하여 암호를 변경할 수 있습니다.
이 그래픽 툴을 호출하려면 명령줄에 OWM을 입력합니다(그림 2
참조).
상단 메뉴에서 지갑 ->
열기를 선택하고 지정한 지갑 위치를 선택한 다음 지갑 암호를 입력합니다.
그런 다음 지갑 ->
암호 변경을 선택하여 암호를 변경합니다.
지갑 암호를 변경하여도 키는 변경되지 않습니다.

암호화와 함께 “Salt”를 원하십니까?

암호화는 완전히 데이터를 숨기지만 때때로 데이터의 원본 일반 텍스트 값에 반복되는 값이 있을 경우 암호화된 데이터 값을 쉽게 추측할 수 있습니다.
예를 들어 급여 정보 테이블에 반복되는 값이 포함될 수 있습니다.
이 경우에 암호화된 값도 동일하며 침입자가 동일한 급여 항목을 판별할 수 있습니다.
그러한 경우를 방지하기 위해 입력 데이터가 같더라도 암호화된 값이 다르도록 데이터에 “salt”를 추가합니다.
기본적으로 TDE는 salt를 적용합니다.
암호화된 열에 대한 인덱스를 생성할 경우 인덱스에 salt를 포함시킬 수 없습니다.
예를 들어 SSN 열에서 salt를 제거하려면 다음을 실행합니다. 

alter table accounts modify

(ssn encrypt no salt);

salt를 사용하여 암호화된 열에 대한 인덱스를 생성할 경우 다음 예에서와 같이 오류가 발생합니다. 

SQL> create index in_acc_01

on accounts (ssn);

ORA-28338: cannot encrypt indexed column(s) with
salt

salt를 사용하여 인덱스된 열을 암호화할 경우에도 동일한 오류가 발생합니다.
마찬가지로 암시적 인덱스 생성이 있을 경우,
즉 열이 기본 키의 일부이거나 unique로 정의된 경우 salt를 사용할 수 없습니다.
또한 열이 외래 키의 일부인 경우에도 salt를 사용할 수 없습니다. 

TDE와 Data Pump
사용 

기본적으로 Data Pump
엑스포트 유틸리티(EXPDP)를 사용하여 암호화된 열이 있는 테이블의 데이터를 엑스포트할 경우 생성되는 덤프 파일의 데이터는 일반 텍스트입니다(암호화된 열 데이터의 경우에도 마찬가지).
다음 명령은 ACCOUNTS 테이블(암호화된 열이 있음)을 엑스포트하고 

$ expdp arup/arup
tables=accounts

ORA-39173: Encrypted data has been stored unencrypted
in dump file set.

이 메시지는 단지 경고이고 오류가 아니며 행이 엑스포트됩니다..

Data Pump 덤프 파일의 암호화된 열 데이터를 보호하려면 테이블을 엑스포트할 때 덤프 파일을 암호로 보호할 수 있습니다.
EXPDP 명령에서 ENCRYPTION_PASSWORD 매개변수로 지정되는 이 암호는 이 엑스포트 프로세스에만 적용됩니다.
이것은 지갑 암호가 아닙니다.
목록 1은 암호 “pooh”를 사용하여 실행한 EXPDP
명령입니다.
목록 1의 명령에 대한 출력이 어떤 방식으로 암호 “pooh”를 표시하지 않는지 주목하십시오.
암호는 별표(*)
문자열로 숨겨집니다.
생성되는 덤프 파일에는 TDE로 암호화된 열의 일반 텍스트 데이터가 보이지 않습니다.

코드 목록 1: 암호로 보호된 덤프 파일의 엑스포트 

$ expdp arup/arup ENCRYPTION_PASSWORD=pooh
tables=accounts

Export: Release 10.2.0.0.0 – Beta on Friday, 01 July,
2005 16:14:06

Copyright (c) 2003, 2005, Oracle.  All rights
reserved.

Connected to: Oracle Database
10g Enterprise Edition Release 10.2.0.0.0 –
Beta

With the Partitioning, OLAP and Data Mining
options

Starting “ARUP”.”SYS_EXPORT_TABLE_01″:  arup/******** ENCRYPTION_PASSWORD=********* tables=accounts

Estimate in progress using BLOCKS
method…

Processing …

이 암호화된 덤프 파일을 임포트할 때 목록 2에서와 같이 엑스포트 시 사용한 동일한 암호를 지정해야 합니다. 

코드 목록 2: 암호로 보호된 덤프 파일의 임포트 

$ impdp arup/arup ENCRYPTION_PASSWORD=pooh
tables=accounts table_exists_action=replace

Import: Release 10.2.0.0.0 – Beta on Friday, 01 July,
2005 16:04:20

Copyright (c) 2003, 2005, Oracle.  All rights
reserved.

Connected to: Oracle Database
10g Enterprise Edition Release 10.2.0.0.0 –
Beta

With the Partitioning, OLAP and Data Mining
options

Master table “ARUP”.”SYS_IMPORT_TABLE_01″ successfully
loaded/unloaded

Starting “ARUP”.”SYS_IMPORT_TABLE_01″:  arup/******** ENCRYPTION_PASSWORD=********* table_exists_action=replace

Processing …

다음은 임포트 시 ENCRYPTION_PASSWORD 매개변수를 지정하지 않은 경우의 결과입니다. 

$ impdp arup/arup
tables=accounts

ORA-39174: Encryption password must

be supplied.

다음은 틀린 암호를 지정한 경우의 결과입니다. 

$ impdp arup/arup
ENCRYPTION_PASSWORD

=piglet tables=accounts

ORA-39176: Encryption password is

incorrect.

원본 엑스포트 유틸리티(EXP)는 암호화된 열이 있는 테이블을 엑스포트할 수 없습니다..

결론 

공격으로부터 데이터를 보호하고 기업에 적용되는 많은 법률을 준수하는 일은 간단한 작업이 아닙니다.
TDE를 사용하면 코딩이나 키 관리 복잡성 없이 데이터 암호화와 준수를 모두 수행할 수 있으므로 더 전략적 활동에 주력할 수 있습니다.