[09/23] Expert Oracle Database 16장 데이터 암호화

암호화의 유형

 

데이터가 네트워크를 통해 이동할 때 적용되는 동적 암호화 기법

오라클 데이터 파일 내의 데이터를 위한 정적 암호화 기법

 

동적 데이터

 

동적 데이터는 암호화 요구사항이 구체적이여서 파일 시스템 상의 파일을 단순하게 암호화 하길 원하는 사람의 암호화 요구사항과 다르다 DB로부터 나오는 정보의 변화하는 스트림을 연속적으로 암호화해야 하고 클라이언트 도착 시 복호화해야 한다

 

부인 방지 데이터 : 전송받은 패킷이 신뢰할 수 있는 상대방에서 전송된 것을 확신하게 함

데이터 정확도 보호 : 조작되지 않은 데이터를 받을 수 있도록 서버/클라이언트 모든 패킷 검증

데이터 재생 방지 : 네트워크 스트림 재전송 x CLI/SEV 실시간 데이터 송수신 해야 함

 

이것이 동적 데이터 암호화고 사용하지 않는다면 데이터 스트림 파괴는 매우 쉽다 은행계좌에서 입출금할 경우 통신간에 패킷을 유입한다면 클라이언트 계정의 돈을 자신의 계정으로 전송 요청하는 데이터 스트림의 패킷을 SQL*Net 규약을 준수한 형태로 유입할 수 있을 것이다 부인방지 기능은 제 3자에 의한 스트림내의 패킷 유입을 허용하지 않는다

 

제3자가 중간에 패킷을 가로채 숫자를 변경할 경우에도 데이터 정확도 보호는 데이터 패킷 검증 기능이 있어 이런일이 발생하지 않게 한다 중간에서 전송되는 패킷을 가로채 재전송할 수 있다 재전송된 패킷은 클라이언트로부터 전송되었고 패킷이 조작되지도 않았으므로 부인방지로도 데이터 정확도 보호로도 감지할 수 없다 그러나 패킷을 최대 한 번만 전송하는 데이터 재생 방지는 재전송 문제 발생을 감지할 수 있다

 

 

 

정적 데이터

 

데이터 파일 내의 데이터를 암호화하는 방식으로 이 유형은 오로지 데이터를 절취하는 행위로부터 데이터베이스를 보호하기 위해 사용된다 또는 데이터 센터의 서버에 누군가 침입할 시 데이터 파일을 절취할 수도 있다 절취된 데이터를 보호하는데 데이터를 암호화할 경우 데이터 도용은 불가능하다 절취자는 SYSDBA 권한으로도 랜덤 비트 이외에는 얻을 것이 없다

 

SYS@orcl>create tablespace in_the_clear   2  datafile '/tmp/in_the_clear.dbf' size 1m   3  /   Tablespace created.   SYS@orcl>create table t ( id      varchar2(30) primary key,   ssn     varchar2(11),   address varchar2(80),   credit_card varchar2(30) ) tablespace in_the_clear;   Table created.   SYS@orcl>insert into t(id, ssn, address, credit_card)   2  values ( 'Lock for me', '123-45-6789',   3           '123 Main Street', ' 1234-5678-9876-5432');   1 row created.   SYS@orcl>commit;   Commit complete.

 

 

 

SYS@orcl>alter system checkpoint;   System altered.   SYS@orcl>!strings -a /tmp/in_the_clear.dbf | egrep '(Look for me|123)' 123-45-6789 123 Main Street  1234-5678-9876-5432

 

버퍼 캐시의 데이터를 강제로 디스크에 쓰게 하고 누군가가 파일에 접근했다면 다른 어떠한 오라클 S/W 없이도 많은 데이터를 얻을 수 있다 Strings 명령을 통해서 본 데이터

 

삭제하더라도 데이터는 여전히 존재하며 다른 데이터로 덮어 써질때까지 데이터 파일 내에 남아 있게 된다 절취자가 데이터 파일에 접근하지 못하더라도 온라인 리두 로그 파일 / 아카이브 리두 로그 파일을 구하면 정보에 접근할 수 있다

SYS@orcl>delete from t where id = 'Lock for me';   1 row deleted.   SYS@orcl>commit;   Commit complete.   SYS@orcl>alter system checkpoint;   System altered.   SYS@orcl>!strings -a /tmp/in_the_clear.dbf | egrep '(Look for me|123)' 123-45-6789 123 Main Street  1234-5678-9876-5432

 

 

 

 

방금 처리한 데이터의 트레이스가 온라인 리두 로그 파일에 남아 있기 때문에 현재 온라인 리두 로그 파일을 찾을 것이다

 

SYS@orcl>column member new_val redo SYS@orcl>select a.member   2  from v$logfile a, v$log b   3  where a.group# = b.group#   4  and b.status = 'CURRENT'   5  and rownum = 1;   MEMBER ---------------------------------------------------------------------------------------------------- /u01/app/oracle/oradata/orcl/redo02.dbf   SYS@orcl>!strings -a &REDO | egrep '(Lock for me|123)' Lock for men123-45-6789 123 Main Street  1234-5678-9876-5432 Lock for me Lock for me 1Lock for me 123-45-6789 123 Main Street  1234-5678-9 Lock for me

 

리두에서 민감한 데이터를 모두 볼 수 있고 한 단계 더 나아가 리두 스트림의 원인이 되는 언두 테이블스페이스에도 존재한다 값은 많은 곳에 기록되고 찾고자 하는 것이 한 파일에서 찾을 수 없다면 다른 파일에서 찾으면 된다

 

이것 이외에도 써드 파티 툴로도 블록의 내용을 읽을 수 있는데 이것은 최후의 리커버리 방법으로 설계되었으나 누구나 목적에 상관없이 데이터 파일을 받는데 사용할 수 있다 리두 로그의 내용을 검사하는데 오라클 툴(log miner)을 사용할 수 있다.

 

 

데이터 절취로부터 데이터를 보호하기 위한 세 가지 방법

 

수작업 애플리케이션 암호화

Transparent 컬럼 레벨 암호화

Transparent 테이블스페이스 암호화

 

수작업 애플리케이션 암호화는 애플리케이션 개발자가 애플리케이션에서 데이터를 수정하는 동안에 트리커를 사용하거나 저장 프로시저, 클라이언트 애플리케이션에서 데이터를 조회하는 동안 사용자 정의 함수를 통해 수작업으로 암호화와 복호화를 할 수 있다 수작업 암호화 및 복호화를 수행하려면 애플리케이션에 프로그램이 코딩되어 있어야 한다

 

이런 방식으로 개발할 경우 높은 비용이 발생한 뿐더러 암복호화를 위한 API가 문서로 이루어져 있어 어렵지 않으나 암호화된 데이터의 키를 관리하는 것이 어렵다 키를 어디에 저장하느냐와 주기적으로 키를 재설정하는 문제도 고려해야 한다 결국 개발 비용 + 키 관리 비용 문제가 겹치는 방식이고 이것은 이미 오라클에서 제공하는 TDE(Transparent Data Encryption)가 있기 때문에 있는 것을 다시 만드는 낭비가 발생하게 되는 방식이 된다

 

오라클 Wallet

 

오라클에서 어떻게 키 관리 문제와 구현 방식을 해결하는 지를 보자

 

Wallet의 이해

오라클 센터가 선택한 키 관리방법으로 암호화 키가 암호화되어 저장된 단순한 파일이고 데이터베이스를 위해 암호화 키를 유지하거나 다른 오라클 컴포넌트를 위해 일부 정보를 유지한다 모든 것을 하나의 wallet을 사용하는 것 보다는 여러 개의 wallet을 사용하는 것을 권장한다

 

Wallet는 데이터베이스 외부에 저장되며 wallet도 함께 절취해야 데이터를 얻을 수 있다 그리고 월렛까지 취하더라도 비밀번호가 있어야 사용이 가능하다 은행 출금 카드처럼 소유(카드)하고 알아야(PIN) 절취가 가능하다

월렛을 사용하는 다른 방법은 자동 로그인 월렛이다 이것은 자동로그인 기능이 설정될 때 데이터베이스와 월렛이 있는 물리적 장비에서만 작동하도록 설계된다 즉 다른 환경에서는 자동 로그인 기능이 활용될 수 없다

 

또한 외부 HSM(Hardware security module)를 활용하는 것인데 11gR1에서 가능하고 데이터베이스 외부의 external 하드웨어 일부에 키를 저장할 수 있도록 한다 이것은 파일시스템에 웰렛을 저장하는 것보다 더 안전한 키 저장 메커니즘을 제공한다 게다가 하드웨어 장치 내에 안전하게 외부 키를 저장할 수 있다 암복호화 처리는 데이터베이스 서버 하드웨어 자체에서 처리된다

 

오라클 Wallet 설정

웰렛 설정 방법은 SQLNET.ORA 환경설정 파일 수정하는 것과 ALTER SYSTEM 명령어로 웰렛을 생성하기만 하면 된다.

 

[oracle@lnx04 admin]$ vi sqlnet.ora   #wallet configure ENCRYPTION_WALLET_LOCATION =    (SOURCE=(METHOD=FILE)        (METHOD_DATA=            (DIRECTORY=/u01/app/oracle/product/11.2.0/db_1/network/admin/)        )    )

 

SQLNET>ORA에 월렛이 있어야 할 곳을 명시해야 한다

 

 

 

 

 

 

가장 간단한 형태의 ALTER SYSTEM 명령어 수행

SYS@orcl>alter system set encryption key identified by foobar;   System altered.   SYS@orcl>!ls -l $ORACLE_HOME/network/admin total 28 -rw-r--r-- 1 oracle oinstall 1573 Sep 23 11:26 ewallet.p12   SYS@orcl>alter system set encryption wallet open identified by foobar;   System altered.   SYS@orcl>alter system set encryption wallet close identified by foobar;   System altered.

 

이제 암호화된 데이터에 읽기 쓰기가 모두 불가능해졌고 새로운 암호화 정보를 생성할 수 없다

 

Transparent 컬럼 레벨 암호화

 

TDE의 일부인 컬럼 레벨 암호화는 10gR2에서 도입 누군가 블록의 데이터를 접근할 때마다 투명하게 복호화되고 블록의 데이터를 수정할 때마다 투명하게 암호화되는 컬럼을 가진 테이블을 생성할 수 있다 그리고 이 컬럼과 연관된 모든 리두, 언두, 템프 데이터 또한 암호화된다

 

SYSTEM@orcl>create tablespace tde_test   2  datafile '/tmp/tde_test1.dbf' size 1m;   Tablespace created.   SYSTEM@orcl>create table t   2  ( c1 varchar2(30),   3    c2 varchar2(30) encrypt   4  )   5  tablespace tde_test   6  / create table t * ERROR at line 1: ORA-28365: wallet is not open   SYS@orcl>alter system set encryption wallet open identified by foobar;   System altered.     SYSTEM@orcl>/   Table created. SYSTEM@orcl>ed Wrote file afiedt.buf     1  insert into t values   2  ('this_is_NOT_encrypted',   3*  'this_is_encrypted' ) SYSTEM@orcl>/   1 row created.   SYSTEM@orcl>select * from t;   C1                                    C2 ------------------------------ ------------------------------ this_is_NOT_encrypted            this_is_encrypted

 

컬럼 C1은 일반 컬럼, 컬럼 C2는 정의 부분에 ENCRYPT가 있다는 것이 다르다 이 컬럼에 저장되는 모든 데이터는 투명하게 암호화(모든 REDO, UNDO 뿐 아니라 컬럼에 생성된 것 등) 될 것이다

 

Encrypt 키워드의 작용을 위해 wallet를 close하고 암호화된 데이터를 수정 / 조회할 것이다

 

SYSTEM@orcl>insert into t values   2  ( 'this_is_NOT_encrypted',   3    'this_is_enrypted'); insert into t values             * ERROR at line 1: ORA-28365: wallet is not open     SYSTEM@orcl>insert into t values   2  ( 'this_is_NOT_encrypted', null);   1 row created.   SYSTEM@orcl>select c1 from t;   C1 ------------------------------ this_is_NOT_encrypted this_is_NOT_encrypted   SYSTEM@orcl>select c2 from t; select c2 from t                * ERROR at line 1: ORA-28365: wallet is not open

 

암호화 컬럼에 값을 입력하거나 암호화된 데이터를 조회하면 같은 오류가 발생한다 이 오류는 이 데이터에 접근할 수 없다는 뜻이 아니고 이 오류는 미안하지만 이 데이터에 접근할 수 있도록 서비스 할 수 없다는 뜻이다

 

데이터를 보호한다는 사실에서 이것은 중요한 차이가 있는데 이것은 소프트웨어로 데이터에 액세스를 제한하는 접근 제어를 의미하는 것이 아닌 데이터베이스가 데이터를 처리할 수 없는 물리적인 제약이라 할 수 있다 단지 암호화된 raw 데이터가 있는 것이며 raw 데이터의 암호화되지 않은 버전을 생성할 수 없다

 

SYS@orcl>alter system set encryption wallet open identified by foobar;   System altered.   SYSTEM@orcl>select * from t;   C1                                    C2 ------------------------------ ------------------------------ this_is_NOT_encrypted            this_is_encrypted this_is_NOT_encrypted

 

두번째로 봐야할건 정적 데이터인 데이터 파일의 내용이다

 

SYSTEM@orcl>alter system checkpoint;   System altered.   SYSTEM@orcl>column file_name new_val f SYSTEM@orcl>select file_name   2  from dba_data_files   3  where tablespace_name = 'TDE_TEST';   FILE_NAME ---------------------------------------------------------------------------------------------------- /tmp/tde_test1.dbf   SYSTEM@orcl> !strings -a /tmp/tde_test1.dbf|egrep this this_is_NOT_encrypted, this_is_NOT_encryptedD

 

데이터가 디스크에 일반 텍스트 파일로 저장되어 있지 않음을 알 수 있다 암호화 데이터는 디스크상에 일반 텍스트 파일로 저장되지 않으며 암호화되지 않은 데이터는 오라클 소프트웨어가 있든 없든 알아보기 쉽게 저장된다는 것이다

 

 

Transparent 테이블 스페이스 암호화

 

11gR1에서 도입됬고 컬럼 레벨 암호화가 각 컬럼별로 암호화하는 반면 TBS암호화는 전체 TBS의 내용을 암호화한다 저장된 모든 블록을 암호화하고 모든 블록의 모든 바이트를 암호화하므로 암호화 TBS에서 테이블을 만든다면 테이블 내의 모든 컬럼이 암호화된다 생성한 모든 세그먼트는 암호화 포맷(INDEX,LOBSEGMENT, TABLE PARTITION)으로 디스크에 저장될 것이고 암호화된 TBS에 저장되는 한 어떠한 디스크에 암호화되어 저장될 것이다

 

Wallet로 쉽게 구현이 되는데 적용하기 위해서는 CREATE TABLESPACE 명령어에 ENCRYPTION절 을 사용해야 한다

SYSTEM@orcl>create tablespace clear     datafile '/tmp/clear.dbf' size 1m;   Tablespace created.   SYSTEM@orcl>create tablespace encrypted     datafile '/tmp/encrypted.dbf' size 1m     encryption default storage ( encrypt );   Tablespace created.

 

clear라는 이름을 가진 TBS에 테이블과 인덱스를 생성

 

SYSTEM@orcl>create table t     tablespace clear     as select *     from all_users     /   Table created.   SYSTEM@orcl>create index t_idx     on t(lower(username))     tablespace clear;   Index created.   쉽게 읽을 수 있는 포맷으로 디스크에 저장된 데이터를 분명히 볼 수 있다     SYSTEM@orcl>!strings /tmp/clear.dbf | grep -i system SYSTEM system

 

테이블 안에 저장된 데이터인 SYSTEM과 인덱스에 저장된 소문자 데이터를 분명히 볼 수 있다 이 테이블이 중요한 데이터를 가진다면 TBS 암호화로 이 데이터를 옮겨야만 한다 사용자가 원한다면 컬럼을 수정하기 위해 ALTER TABLE 명령어를 사용해서 컬럼 단위로 암호화할 수는 있으나 컬럼 레벨 암호화는 몇 가지 제약 조건이 있고 함수 기반 인덱스의 사용이 불가능하다

 

SYSTEM@orcl>alter table t   2  modify username encrypt; modify username encrypt        * ERROR at line 2: ORA-28348: index defined on the specified column cannot be encrypted

 

함수 기반 인덱스가 생성된 컬럼에는 암호화를 적용할 수 없다 T 테이블 데이터와 함수 기반 인덱스를 포함한 이 테이블이 모든 인덱스 데이터를 암호화하길 원한다면( 데이터를 암호화할 때 인덱스를 포함한 찾을 수 있는 모든 데이터를 암호화하는 것이 낫다) 암호화 테이블스페이스로 데이터를 옮겨야 한다

 

SYSTEM@orcl>alter table t move   2  tablespace encrypted;   Table altered.   SYSTEM@orcl>alter index t_idx rebuild   2  tablespace encrypted;   Index altered.   SYSTEM@orcl>alter system checkpoint;   System altered.   SYSTEM@orcl>!strings /tmp/encrypted.dbf | grep -i system   SYSTEM@orcl>!strings /tmp/encrypted.dbf | head }|{z TORCL ENCRYPTED ;qN?Q            sO$ o>Rj +;%3 u':x i+?|U0 y+*:g

 

더 이상 데이터 파일에서 어떠한 데이터도 발견할 수 없다 파일에서 모든 문자를 덤프하면 읽을 수 있는 문자라고는 TORCL과 ENRYPTED 두개 뿐이다 데이터 파일 내의 헤더를 제외한 다른 모든 데이터베이스 블록은 암호화된다 데이터는 어디에도 찾을 수 없다 암호화 이전 데이터 파일을 체크하면 여전히 찾을 수는 있다

 

SYSTEM@orcl>!strings /tmp/clear.dbf | grep -i system SYSTEM system

 

데이터를 move할 때 데이터를 복사하고 난 후 복사본과 원본이 여전히 존재하고 지금 /tmp/clear.율 파일을 훔친다면 데이터 파일의 블록을 덤프함으로써 전체 테이블을 재생성할 수 있다 move 처리는 이전 데이터를 삭제하지 않으면 언두 테이블스페이스에 있던 예전 정보(CLEAR 테이블스페이스에 있던 테이블에서 생성된 언두) 리두 스트림, 아카이브 로그 백업 데이터를 정확히 지울 수 없으며 대량 정렬 때문에 발생한 레코드가 템프에 있어도 제거할 수 없다

 

암호화 적용시 첫 번째 단계는 move하기 전 남은 복사본을 데이터의 안전을 위해 체크하는 것이다

 

암호화와 관련 없는 것

 

접근 제어를 위해 암호화를 사용하는 것이 아닌 데이터가 도난 분실 되었을 때 데이터베이스의 데이터를 보호하기 위해서 오라클 정적 데이터 암호화를 구현하는 것이다

 

접근 제어 규칙이란 GRANT REVOKE같은 DCL이나 로우 레벨 보안 컬럼 레벨 보안 같은 접근을 제어시사용되는 것이고 암호화는 접근 제어선이 무너졌을 때 데이터를 보호하기 위해 사용된다 암호화가 접근 제어처럼 작동된다면 SYSDBA같은 모든 접근 제어를 무시하는 계정에는 대응할수가 없다

테이블 스페이스 암호화 구현

 

데이터베이스 내 모든 테이블 스페이스에 있는 블록을 암호화된 포맷으로 저장할 수 있는 기능이고 모든 세그먼트는 테이블스페이스 내에 암호화되어 저장된다 모든 테이블 내의 모든 컬럼이 디스크 상에서 암호화되어 테이블 스페이스에 저장된다

 

테이블스페이스 암호화 사용법

 

Create table tablespace_name

Datafile …

Encryption

Using ‘algorithm’ (optional)

Default storage ( encrypt );

 

오라클 wallet 설정을 하면 되고 알고리즘은 사용할 암호화 형태를 지정하는 것으로 3DES168, AES128, AES192, AES256 중에 하나를 선택할 수 있다 (default는 AES128) 알고리즘은 선택사항이고 지정하지 않을 경우에는 기본값을 설정되나 암호화 테이블스페이스를 생성하기 위해서는 encrypt가 포함된 두 부분이 필요하다

 

이미 존재하는 암호화되지 않은 TBS는 암호화할 수 없다 암호화모드로 TBS를 생성해야만 한다 존재하는 TBS를 효율적으로 암호화하기 위해서는 새로운 암호화 TBS를 만들고 새로운 TBS에 기존 TBS의 세그먼트를 이동해야 한다 기존 TBS DROP하고 새로운 TBS 명을 기존 TBS 명으로 Rename한다

 

암호화 TBS에 세그먼트를 생성해서 데이터 파일에 데이터가 저장될 때 투명하게 암호화되고 다시 데이터를 읽을 때 투명하게 복호화된다

 

TBS 암호화가 적용된 데이터 저장

 

암호화로 인한 데이터 조회와 수정의 영향도 뿐아니라 저장 부하 상황을 고려할것이다

디스크에 저장

 

테이블 스페이스 압축에 대한 스토리지 부하는 없다 이미 모든 데이터베이스 블록이 16바이트의 배수로 되어 있기 때문에 16바이트의 배수로 데이터를 추가 변환할 필요가 없다 데이터베이스 블록은 고정 길이 데이터 요소고 암호화가 고정 길이의 결과를 발생시킨다는 사실은 관련이 없다 마지막으로 각 데이터베이스 블록은 유일한 실체며 이미 데이터가 유일하기 때문에 SALT 데이터가 존재할 필요가 없다 컬럼 레벨 암호화에서 했던 것처럼 데이터베이스 블록에 데이터 프로브(PROBE) 문제를 피하고자 데이터를 유일하게 만들기 위해 어떠한 것도 추가할 필요가 없다.

 

만약 암호화되지 않은 테이블스페이스가 디스크를 5GB 차지한다면 암호화된 테이블 스페이스에 저장된 같은 데이터는 같은 5GB를 활용한다 데이터 파일에서 데이터 파일 헤더 자체에 암호화되지 않은 상태로(그래서 데이터베이스는 wallet 없이 파일을 인식하고 파일을 액세스할 수 있다) 저장되나 데이터베이스 인스턴스 내에 wallet이 오픈되지 않았을 때는 암호화되어 저장된 모든 데이터베이스 블록에 누구도 접근할 수 없다

 

SGA에 저장

 

암호화되지 않은 상태로 SGA에 저장된다 이것이 두 방법의 가장 큰 차이고 데이터베이스 블록이 디스크에서 버퍼캐시로 읽혀질 때 데이터베이스 블록은 복호화되어 버퍼 캐시에 저장된다 그러므로 데이터베이스 블록이 캐시에서 읽혀질 때 복호화가 발생하지 않는다 나중에 일반적으로 데이터가 SGA에서 추출되어 디스크에 저장되기 전에 DBWR이 블록을 암호화해서 디스크에 저장한다

 

블록이 SGA로 읽혀질 때 dedicated 또는 shared 서버 프로세스가 복호화한다 체크포인트 또는 다른 조치로 디스크를 플러시할 때 이전에 쓰여진 것들은 다시 암호화된다

 

암호화되지 않은 상태로 SGA에 데이터를 저장하는 이 방법은 두 가지 중요한 영향요소가 존재한다 첫 번째는 성능에 관한 것이고 데이터가 암호화되지 않고 캐시에 저장된다면 캐시의 데이터를 액세스할 때 (물리 I/O의 수행이 발생하지 않는 경우) 이 암호화된 TBS에 대한 부하는 거의 없다 데이터는 이미 복호화되어 있기 때문에 모든 액세스에 대해 복호화가 필요 없다 그러므로 캐시에서 블록을 얻기 위해 물리 I/O를 한 번 수행하고 난 후 캐시된 블록에 대해 논리 I/O(캐시에서 읽는다) 가 1,000,000번을 수행한다면 복호화는 1,000,000번이 아닌 단지 한 번만 수행된다 물론 언두와 리두가 암호화되어 생성되어야만 하기 때문에 부하가 전혀 없는 것은 아니지만 I/O 효율화 측면에서 보면 대단한 효과가 있다고 할 수 있다.

 

암호화된 데이터에 템퍼러리 데이터 역시 암호화되어 디스크에 저장된다 읽어들인 데이터를 저장할 PGA의 크기가 결과 집합을 유지하기에 충분하지 않다면 암호화 적용에 따른 부하가 발생

 

또 다른 영향 요소는 데이터가 암호화되지 않은 상태로 SGA에 저장되는 것이다 누군가 데이터 파일을 절취하기 위해 물리 서버에 액세스할 수 있다면 인스턴스의 공유 메모리에 액세스할 수 있고 버퍼캐시를 볼 가능성이 있다 SGA에 암호화되지 않은 버퍼 캐시를 조심해야 한다면 테이블스페이스 레벨 암호화 적용 여부를 결정해야만 한다 대부분의 경우 공격자가 SGA에 붙어 그 내용을 볼 수 있다면 공격자는 아마도 일반적으로 SGA에 접근할 수 있고 OS에서 승인될 수 있는 SYSDBA 롤을 가진 SYSDBA 계정을 사용할 것이다 데이터 암호화의 목적은 데이터 파일 내의 정적 데이터를 보호하기 위한 것이고 암호화되지 않은 SGA 내의 데이터베이스 블록은 결코 불리한 요소가 아닌 하나의 특징이라 할 수 있다

 

테이블 스페이스 암호화의 성능 영향도 측정

 

`

SYS@orcl>create tablespace encrypted   2  datafile '/tmp/encrypted.dbf' size 1m   3  autoextend on next 1m   4  ENCRYPTION   5  default storage ( ENCRYPT );   Tablespace created.   create tablespace clear datafile '/tmp/clear.dbf' size 1m   3  autoextend on next 1m;   Tablespace created.   create table stage as select *   from all_objects   5  /   Table created.

 

Nonecrypted 테이블과 기본 키 인덱스를 생성

 

create table nonencrypted tablespace clear as select *   from stage  where 1=0   7  /   Table created.   alter table nonencrypted add constraint nonencrypted_pk primary key(object_id) using index (create index nonencrypted_pk  on nonencrypted(object_id)   7   tablespace clear );   Table altered.   create table encrypted tablespace encrypted as select *   from stage  where 1=0   7  /   Table created.   alter table encrypted add constraint encrypted_pk primary key(object_id) using index (create index encrypted_pk  on encrypted(object_id)   7   tablespace encrypted );   Table altered.

 

컬럼 레벨 암호화는 일반적으로 인덱스 대상이 아니며 참조키 정의를 고려하지 않아도 되는 속성으로 자주 액세스되지 않는 신용카드 번호와 같은 데이터 속성에 적합하다 컬럼을 자주 액세스하면 자원낭비로 인한 컬럼 암호화 비용이 올라간다 속성에 액세스할 때마다 복호화(수정의 경우에는 암호화) 처리가 수행될 것이다 컬럼에 더 많이 액세스할수록 컬럼 암호화 비용은 더 올라간다 컬럼 레벨 암호화의 가장 큰 효과는 매우 정교하게 암호화를 할 수 있다는 것이다 테이블스페이스 암호화처럼 양자택일(all-or-nothing) 방법이 아니다 방대한 데이터를 이동하지 않고 컬럼을 암호화된 상태로 변경할 수 있다 기존 암호화되지 않은 테이블스페이스에 암호화된 컬럼이 있는 새로운 테이블을 생성할 수 있다

현재 있는 암호화되지 않은 테이블스페이스에서 새로운 암호화된 테이블스페이스로 민감한 정보의 테이블과 인덱스를 포함한 모든 데이터를 옮기려 한다면 대부분의 경우에는 테이블스페이스 암호화가 적합하다 아마도 결점은 테이블스페이스를 암호화하기 때문에 기존 테이블스페이스에 일부만을 적용할 수 없다는 것이다 암호화 테이블스페이스를 적용하려면 새로운 테이블스페이스를 생성해야 하고 이 테이블스페이스에 데이터를 이동시켜야 하므로 대량의 데이터가 있는 애플리케이션에는 적합하지 않을 것이다 앞으로 민감함 정보를 암호화해야 할 필요가 있는 데이터 집합을 새롭게 생성한다면 성슨에 미치는 영향이 적고 전체적으로 투명한 암호화 테이블스페이스를 필자는 다른 암호화기술에 우선해 선택할 것이다 컬럼 레벨 암호화에서처럼 테이블스페이스 암호화에서는 인덱스, 참조 키 및 크기를 고려할 필요가 없다