Oracle: Criptografia Bancos Enterprise

Conforme já relatado na versão Standard temos algumas limitações para o uso de criptografia, resumindo: temos que alterar os códigos de SELECT, INSERT e UPDATE. Na versão Enterprise os recursos são bem mais avançados e um dos mais usados é o TDE (Transparent Data Encryption).

Vantagens:  É transparente para o usuário se estiver dentro da aplicação. Exige alterações mínimas por parte do desenvolvedor. Quase todo o restante dos ajustes são feitos pelo DBA.

Desvantagens: Funciona só na versão Enterprise (mais cara) e além disso a empresa tem que adquirir uma option chamada Database Advanced Security.

Funciona da seguinte forma:

1) Cria-se uma chave mestra no banco com o comando ‘ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY “Teste123“;

2)  Cria-se a tabela com atributo de encrypt na coluna e insere-se os registros normalmente:

3) Dentro da aplicação (ou no SQL PLUS se for fazer um teste, deve-se habilitar o Wallet criado com a senha correta:

ALTER SESSION SET WALLET OPEN IDENTIFIED BY “Teste123”; – O Desenvolvedor deve saber qual a chave do wallet. Pode-se também acessar os dados por SQL*PLUS desde se saiba a senha do Wallet.

4) Pode-se fazer normalmente o select na coluna que, se a senha inserida for a correta o Oracle faz automaticamente a criptografia ou de-criptografia da coluna. Caso o usuário não saiba a senha correta se fizer select na coluna envolvida receberá uma mensagem de erro.

Observação:  Existem opções para limitação de acesso de dados de alguma coluna de acordo com o usuário. Este recurso (DBMS_RLS que faz parte do Virtual Private Database) é para o banco Enterprise também. Porém, ele não faz criptografia. Apenas mostra dados das colunas ‘embaralhados’ APENAS para quem não tem acesso àqueles dados. Por exemplo, neste caso, em uma tabela de pedidos caso seja aplicadas as políticas do DBMS_RLS para as colunas de VALOR e QTDE. Se o vendedor conectado com o usuário JOÃO tentar fazer um select, ele vai visualizar apenas dados das vendas que ele fez. Para vendas que ele não tenha feito, nas colunas  VALOR e QTDE ele vai visualizar NULO ou então um outro valor qualquer dependendo da política implementada. O  vendedor João só vai enxergar valores nestas colunas caso faça select nas vendas que ELE fez (ou a equipe dele se ele for um GERENTE REGIONAL).

Resumindo:

1)      Criptografia é uma opção de segurança que protege os dados de determinadas colunas, porém, à partir do momento que a aplicação tiver a senha para liberar, eu não restrinjo o uso destes dados para terminados usuários. Quem não tiver a chave de criptografia não consegue visualizar nada. Mas quem tem a chave consegue visualizar tudo.

2) Virtual Private Database, por outro lado é um recurso que não precisa criptografar dado algum. Porém, permite aplicar políticas de limitação do acesso dependendo do usuário conectado. Neste caso, alguns usuários enxergariam todas as informações de determinadas tabelas. Outros estariam limitados à condições de WHERE presentes à política. E aí, dependendo desta política aplicada é possível inclusive filtrar as informações para determinados usuários, ou caso não queira filtrar é possível mostrar a coluna porém, dependendo do perfil do usuário a coluna pode ser exibida com valores nulos. Para os usuários qu e teriam acesso sem restrição a mesma coluna chegaria com valores corretos.

Dúvidas? silverio@siltechconsult.com.br