Oracle: criptografando tabelas com o TDE

Pessoal,

Neste artigo apresentarei o recurso de segurança do Oracle Database (existente a partir da versão 10G release 2) chamado Transparent Data Encryption (TDE). Este recurso permite proteger dados confidenciais de colunas e índices de tabelas, criptografando os dados e armazenando-os de modo seguro (criptografados) nos arquivos de dados do Sistema Operacional. Aos consultar estes dados (criptografados), eles são decriptografados antes de serem apresentados para o usuário final. A criptografia e decriptografia dos dados ocorre de forma transparente, sem necessidade de linhas de código adicionais na aplicação ou no banco de dados.

Com TDE, ao criptografar os dados de uma coluna de uma tabela, é gerada uma chave de criptografia para a tabela, que é armazenada no Dicionário de Dados (D.D.) para posterior decriptografia. Por sua vez, a chave de criptografia da tabela também é criptografada por outra chave, que é chamada chave mestra e que é armazenada fora do Banco de Dados, em um local seguro chamado Oracle Wallet.

Quando um usuário do Banco de Dados altera ou inclui dados (dados de entrada) em uma coluna criptografada, o Oracle Database recupera a chave mestra do Wallet, decriptografa a chave da tabela (recuperada no D.D.) e usa esta chave para criptografar os dados de entrada, antes de armazená-los no Banco de Dados. Nos dados, antes da criptografia, são adicionadas palavras extras chamadas SALT, que alteram os dados originais e que ajudam a dificultar “ataques hackers” de decriptografia. SALT é adicionado por padrão no TDE e pode ser utilizado somente ao criptografar tabelas. Índices não podem conter SALT.
Com TDE os dados podem ser criptografados utilizando um dos quatro seguintes algoritmos de criptografia: 3DES168, AES128, AES192 e AES256. AES192 é o algoritmo padrão.

É importante ressaltar que ao utilizar TDE nas tabelas, há um custo de performance para criptografar e decriptografar as colunas. Em testes do artigo Transparent Data Encryption (TDE) in Oracle 10g Database Release 2 (http://www.oracle-base.com/articles/10g/TransparentDataEncryption_10gR2.php), o tempo de execução das instruções SQL para atualizações e consultas em uma tabela (que possui o total de 2 colunas e somente 1 coluna criptografada) aumentou aproximadamente 40%.

Para utilizar TDE, no Oracle Database 10G Enterprise Edition (versão do Oracle mais utilizada), é necessário obter licensiamento da option Oracle Advanced Security (ver http://download.oracle.com/docs/cd/B19306_01/license.102/b14199/options.htm#CIHJHABF)

Para demonstrar a utilização de TDE, seguiremos os passos abaixo:
————————————————————————–
Para iniciar o passo-a-passo abaixo, é necessário conectar-se previamente no Banco de Dados desejado, através do SQL Plus, com um usuário com privilégios administrativos (usuário contendo a role DBA ou o privilégio de sistema SYSDBA), que não seja o SYS, pois se o passo 2 for executado pelo SYS ele irá falhar (o Oracle Database não permite utilizar TDE em objetos do schema SYS).
————————————————————————–

PASSO 1: Criando e referenciando o Wallet

a) Acrescente no arquivo sqlnet.ora da pasta network/admin do Oracle Home o seguinte bloco:

ENCRYPTION_WALLET_LOCATION =
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=ORACLE_BASEadminORACLE_SIDwallet)))

O parâmetro DIRECTORY do bloco de código acima indica o caminho do arquivo Wallet que será criado no item “b)” deste passo e está redigido de acordo com os padrões do sistema de arquivos do Windows. Neste item, substitua os valores:
– ORACLE_BASE: pelo diretório correspondente ao Oracle Base em sua instalação de BD.
– ORACLE_SID: pelo nome da instância de BD.

Obs.: Se o diretório wallet não existir, crie-o dentro da pasta ORACLE_BASEadminORACLE_SID. A pasta “ORACLE_BASEadminORACLE_SIDwallet” é o caminho padrão de criação de Wallets.

b) Crie o Wallet e defina a chave mestra na instância de Banco de Dados (BD) em execução:
No prompt do SQL digite:
ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY “Teste123“;

Obs.: Substitua Teste123 pela senha desejada. Este item define uma senha mestra e automaticamente cria o Wallet na pasta padrão referenciada no item “a)”.

PASSO 2: Criando e inserindo dados em uma tabela com uma coluna criptografada

Execute no SQL Plus os comandos abaixo:
CREATE TABLE table_tde_test (
ID NUMBER,
DATA1 VARCHAR2(40),
DATA2 VARCHAR2(40) ENCRYPT);

INSERT INTO table_tde_test (ID, DATA1, DATA2)
VALUES (1, ‘Dados NÃO criptogrados na coluna DATA1!’,’Dados criptogrados na coluna DATA2!’);

COMMIT;

ALTER SYSTEM FLUSH BUFFER_CACHE; –> força atualização dos dados no arquivo de dados da tabela

PASSO 3: Testando o TDE no nível da tabela

a) Execute um SELECT na tabela criada no passo anterior:
SELECT * FROM table_tde_test;

Resultado:
Todos os dados da tabela serão retornados, inclusive os dados da coluna DATA2, que estão criptografados, pois o Wallet foi criado e está aberto desde o passo 1.

b) Feche o Wallet:
ALTER SYSTEM SET WALLET CLOSE;

Resultado:
Wallet fechado.

c) Execute novamente o SELECT do item “a)“:
SELECT * FROM table_tde_test;

Resultado:
O SELECT irá disparar o erro ORA-28365, pois com o Wallet fechado não é possível recuperar a senha de criptografia da tabela e decriptografar os dados.

d) Execute um novo SELECT sem retornar os dados da coluna criptografada (DATA2):
SELECT ID, DATA1 FROM table_tde_test;

Resultado:
A instrução SELECT irá retornar com sucesso pois sem a incluir a coluna DATA2, não é necessário consultar o Wallet.

PASSO 4: Testando o TDE no nível do arquivo de dados

a) Localize o arquivo de dados em que a tabela foi criada. A query abaixo poderá ser executada para descobrir o caminho completo do arquivo de dados se o usuário conectado tiver privilégios administrativos ou tiver privilégios de SELECT nas visões DBA_TABLES e DBA_DATA_FILES:

SELECT            F.FILE_NAME
FROM              DBA_TABLES T
INNER JOIN   DBA_DATA_FILES F
ON         T.TABLESPACE_NAME = F.TABLESPACE_NAME
WHERE           T.TABLE_NAME = ‘TABLE_TDE_TEST’;

b) Entre na pasta localizada no item anterior:

– Se estiver usando SO Linux digite no prompt de comandos:
strings FILE.DBF | grep “criptogrados na coluna DATA”

Obs.: Substitua FILE.DBF pelo nome do arquivo de dados identificado no item anterior.

– Se estiver usando SO Windows, abra o arquivo identificado no item anterior em um editor de texto qualquer e faça uma pesquisa (CTRL + F) pela seguinte frase: criptogrados na coluna DATA

Resultado:

Você encontrará no arquivo DBF o valor “criptogrados na coluna DATA” apenas 1 vez, pois este é o valor da coluna DATA1. Se os dados da coluna DATA2 não estivessem criptografados, a pesquisa encontraria 2 vezes a frase pesquisada dentro do arquivo.

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

CONCLUSÃO

Apesar de degradar a performance da tabela, utilizar TDE para criptografar e decriptografar dados transparentemente é um ótimo recurso para proteger dados confidenciais, tais como salários ou números de cartões de crédito, pois eles só serão acessados por usuários ou aplicações que conheçam previamente a senha do Wallet.

Além de proteger os dados no nível lógico (conectado no banco de dados), TDE também protege os dados no nível físico, pois nos testes do Passo 4 podemos verificar que os dados aparecem em “texto limpo” no arquivo de dados do sistema operacional e podem ser lidos claramente por qualquer usuário que tenha acesso a ele.

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

Comandos e instruções SQL úteis:

Para consultar tabelas que possuem colunas criptografadas com TDE:
select * from DBA_ENCRYPTED_COLUMNS;
Para somente abrir o Wallet:
ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY “Password”; –> substituir Password pela senha master do Wallet.

Referências: