Tablespace Encryption

Ontem estive a ver (não muito atentamente) um webcast com o Tom Kyte sobre segurança com o título “Oracle Database 11g Security and Compliance Solutions”. No entanto e não é habitual, achar aborrecido ouvir o Tom Kyte, mas a falta de exemplos práticos deixou-me aborrecido.
Assim hoje vou vos falar sobre encriptação ao nível no tablespace no Oracle 11g.

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:


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";

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.

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.
Um dia poderei escrever algo sobre a Performance associada a este processo, que é algo que agora não me assiste 🙂

 

– Artigo originalmente escrito para o thewiseadvise.com – 

Advertisements

One thought on “Tablespace Encryption

  1. muito bom!ficam duas perguntas…- no teu teste apenas verificas a (in)existência de uma string que sabes estar armazenada em “clear text”. será que não é possível deduzir alguma coisa sobre os conteúdos que estão cifrados? ex.: tamanho, número de rows/colunas, …certamente que cada coluna depois de cifrada não terá o tamanho máximo permitido para uma coluna em Oracle por razões de performance..- era interessante perceber qual é o impacto na performance de se usar tablespace encryption e já agora o que é seria possível fazer para o minimizar. Será que os novos CPUs Intel com suporte em hardware para AES podem melhorar alguma coisa?hugz

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s