Este documento descreve como o Oracle TDE permite proteger dados sensíveis criptografando-os ao nível da coluna ou do tablespace. No Oracle 11g é possível criptografar todo o conteúdo de um tablespace usando AES256. Um exemplo mostra como criar um tablespace criptografado e como os dados inseridos nele não podem ser lidos em bruto no ficheiro de dados.

1. Oracle TDE ­ O Básico
No tempo do Oracle 10gR2 foi introduzido o TDE (Transparent Data Encryption), que permite
essencialmente proteger os dados mais sensíveis para que alguém não possa ao nível do
sistema operativo aceder confortavelmente. O problema com isto pretende­se com o facto de
só ser possível encriptação ao nível dacoluna.
No entanto para vos dar um background inicial de como é possível aceder aos dados via
sistema operativo dar­vos­hei um exemplo simples:
Para evitar confusões, criaremos um tablespace pequeno que acomodará o nosso exemplo:
Como SYSDBA:
SQL> CREATE TABLESPACE tl_luis1 DATAFILE
'/home/oracle/app/oracle/oradata/testSID/t1_luis1.dbf' SIZE 256K
2 AUTOEXTEND ON NEXT 64K;
Tablespace created.
Ajustando um user já existente para criar objectos por omissão no tablespace TL_LUIS1:
SQL> ALTER USER lmarques IDENTIFIED BY ****** DEFAULT TABLESPACE TL_LUIS1;
User altered.
Como user lmarques:
SQL> create table la_luis1 (clubes varchar2(50), maior varchar2(1))
TABLESPACE TL_LUIS1;
Table created.
SQL> INSERT INTO la_luis1 (clubes, maior) VALUES('SLB', 'Y');
1 row created.
SQL> INSERT INTO la_luis1 (clubes, maior) VALUES('SCP', 'N');
1 row created.
SQL> commit;
Commit complete.
Para ter a certeza que os dados são escritos para o disco é necessário um FLUSH ao
BUFFER_CACHE:

2.
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;
System altered.
Vamos agora passar um editor HEX em cima do datafile que criámos para o tablespace
TL_LUIS1, para ver o resultado:
[oracle@localhost testSID]$ hexdump t1_luis1.dbf ­C | grep 'S'
00002020 54 45 53 54 53 49 44 00 5e 04 00 00 20 00 00 00
|TESTSID.^... ...|
00002150 08 00 54 4c 5f 4c 55 49 53 31 00 00 00 00 00 00
|..TL_LUIS1......|
0000e000 1e a2 00 00 07 00 80 01 53 20 11 00 00 00 01 04
|........S ......|
0000fff0 00 00 00 00 00 00 00 00 00 00 00 00 01 1e 53 20
|..............S |
0001ffe0 00 00 00 00 00 00 00 00 00 00 2c 01 02 03 53 43
|..........,...SC|
0001fff0 50 01 4e 2c 01 02 03 53 4c 42 01 59 01 06 7b 22
|P.N,...SLB.Y..{"|
Como podem facilmente reparar o hexdum revela­nos todos os dados que inserimos no
tablespace mesmo sendo um ficheiro binário, é obviamente possível ler o ASCII.
Voltando ao Oracle 11g, a limitação que falava no 10g e no TDE prende­se com o facto de a
encriptação ser feita apenas ao nível da coluna que só possibilita encriptar a coluna
individualmente protegendo apenas os dados ai contidos.
Passando para o 11g é possível ter encriptação ao nível do tablespace e consequentemente a
todos os dados (em tabelas) que residam nesse tablespace. Vejamos:
Primeiro é necesário criar uma wallet que deve ter a sua localização definida no sqlnet.ora:
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=/home/oracle/app/oracle/product/11.2.0/dbhome_1/scheduler/
wallet/)))
Depois de adicionar a entrada ao sqlnet.ora temos que dar uma password para a wallet, ou
seja, esta password vai ser necessária
para abrir a wallet.
SQL> ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "slb";

3. System altered.
SQL> !ls
/home/oracle/app/oracle/product/11.2.0/dbhome_1/scheduler/wallet/
ewallet.p12
Após a criação da wallet atribuindo uma chave esta fica automáticamente aberta e não há
necessidade de usar o comando para reabrir.
Para criar um tablespace encriptado usado a cifra AES256:
SQL> CREATE TABLESPACE tl_luis2 DATAFILE
'/home/oracle/app/oracle/oradata/testSID/t1_luis2.dbf' SIZE 256K
2 AUTOEXTEND ON NEXT 64K
3 ENCRYPTION USING 'AES256'
4 DEFAULT STORAGE(ENCRYPT)
Modificamos de novo o user que usámos anteriormente para por omissão criar objectos neste
novo TL_LUIS2 que ao contrário do TL_LUIS1 se encontra encriptado:
SQL> ALTER USER lmarques IDENTIFIED BY ******* DEFAULT TABLESPACE
TL_LUIS2;
SQL> conn lmarques/*******
Connected.
SQL> create table la_luis2 (clubes varchar2(50), maior varchar2(1))
TABLESPACE TL_LUIS2;
Table created.
SQL> INSERT INTO la_luis2 (clubes, maior) VALUES('SLB', 'Y');
1 row created.
SQL> INSERT INTO la_luis2 (clubes, maior) VALUES('SCP', 'N');
1 row created.
SQL> commit;
Commit complete.

4. Mais um vez para garantir que os dados são escritos no disco, repetimos o processo e fazemos
um FLUSH BUFFER_CACHE e de seguida passamos o hexdump em cima do datafile
correspondente ao tablespace TL_LUIS2 que se encontra encriptado com AES 256.
[oracle@localhost testSID]$ hexdump ­C t1_luis2.dbf | grep S
00002020 54 45 53 54 53 49 44 00 6d 04 00 00 20 00 00 00
|TESTSID.m... ...|
00002150 08 00 54 4c 5f 4c 55 49 53 32 00 00 00 00 00 00
|..TL_LUIS2......|
[oracle@localhost testSID]$ hexdump ­C t1_luis2.dbf | grep SLB | wc
­l
0
[oracle@localhost testSID]$ hexdump ­C t1_luis1.dbf | grep SLB | wc
­l
1
As conclusões são simples de tirar, não foi possível no tablespace TL_LUIS2 inferir qualquer
tipo de resultado sobre o conteúdo das tabelas.
Como conclusão, este tipo de funcionalidade é bastante útil no entanto existe como é obvio um
overhead associado ao processo de encriptação/desencriptação que resulta com que as querys
sejam mais lentas, portanto esse factor deve ser tido em conta para calcular a selectividade a
aplicar esta funcionalidade.