Esse artigo faz parte da revista SQL Magazine edição 57. Clique aqui para ler todos os artigos desta edição
-bidi-font-weight: normal; mso-no-proof: yes; mso-fareast-font-family: Times; mso-fareast-language: EN-US">Oracle TDE - Transparent Data Encryption
Mais segurança para seus clientes
Segurança da informação é um tema que tira o sono de muitas empresas, principalmente as de e-commerce que guardam números de cartão de crédito de seus clientes. Você faria suas compras em um site se não se sentisse seguro para passar seu número de cartão de crédito? Pois é, nem eu.
Por isso é imprescindível para o negócio que os clientes tenham a segurança de que seus dados não irão parar em mãos erradas.
Para garantir a segurança, muitas empresas têm a preocupação de proteger seus bancos de dados restringindo o acesso remoto a um grupo seleto de usuários previamente registrados e munidos de senhas. Armazenam os computadores em áreas restritas de prédios com alta segurança. Algumas chegam a montar verdadeiros esquemas mirabolantes de segurança, mas se esquecem de que existe uma maneira muito simples de deixar vazar informação: uma fita de backup que saia desse prédio, por exemplo. Uma única fita de backup pode conter, por exemplo, números de cartões de crédito de milhões de clientes.
Para solucionar esse tipo de furo de segurança e alguns outros é que surgiu a ferramenta Transparent Data Encryption (TDE) do Oracle 10g.
A procura pelo TDE tem crescido nos Estados Unidos em várias empresas, como as de telefonia, onde o número de clientes representa uma parcela significativa da população do país. Essas empresas buscam no TDE uma forma de proteger dados de cartões de crédito e SSN (Social Security Number – Número do seguro social dos EUA) de seus clientes, e de atender a normas de segurança do governo norte americano, o SOX (Nota DevMan 1).
DevMan 1. SOX - Sarbanes-Oxley Act.
Sarbanes-Oxley Act ou Lei Sarbanes-Oxley é uma lei dos EUA assinada em 30 de julho de 2002 pelo senador Paul Sarbanes (Democrata de Maryland) e pelo deputado Michael Oxley (Republicano de Ohio).
Motivada por escândalos financeiros coorporativos (dentre eles o da Enron, que acabou por afetar drasticamente a empresa de auditoria Arthur Andersen), essa lei foi redigida com o objetivo de evitar o esvaziamento dos investimentos financeiros e a fuga dos investidores causada pela aparente insegurança a respeito da governança adequada das empresas.
A lei Sarbanes-Oxley, como foi chamada, foi apelidada carinhosamente de Sarbox ou ainda de SOX. Seu conjunto busca garantir a criação de mecanismos de auditoria e segurança confiáveis nas empresas, incluindo ainda regras para a criação de comitês e comissões encarregados de supervisionar suas atividades e operações de modo a mitigar riscos aos negócios, evitar a ocorrência de fraudes ou ter meios de identificar quando elas ocorrem, garantindo a transparência na gestão das empresas.
Atualmente grandes empresas com operações financeiras no exterior seguem a lei Sarbanes-Oxley.
A lei Sarbannes-Oxley afeta dezenas de empresas brasileiras que mantém ADRs (American Depositary Receipts) negociadas na NYSE, como a Petrobrás, a Sabesp, a TAM Linhas Aéreas, a Brasil Telecom, Ultrapar (Ultragaz), a Companhia Brasileira de Distribuição (Grupo Pão de Açúcar) e a Telemig Celular.
O TDE permite armazenar colunas de uma tabela de forma criptografada. O mais interessante é que, do ponto vista da aplicação, nada, absolutamente nada precisa ser alterado. Nem uma linha sequer de código adicional precisa ser escrita. Daí vem o nome Transparent Data Encryption (Criptografia de Dados Transparente).
A forma de acesso das consultas às colunas criptografadas continua exatamente a mesma, e as permissões dos usuários que acessam essas colunas também não precisam mudar. Eles continuam enxergando os dados decriptografados como sempre o fizeram.
A única pessoa que precisa efetuar mudanças é o próprio DBA. Para os demais, tudo continua como antes. É um ganho de segurança que ocorre realmente de forma transparente!
O que é preciso para usar o TDE?
Para usar o Transparent Data Encryption (TDE) é preciso ter a opção ASO (Advanced Security Option) do Oracle 10g instalada e a versão do banco precisa ser 10.2.0.1 ou superior.
Com relação a privilégios, basta possuir o privilégio de CREATE TABLE para que você consiga criar colunas com criptografia.
Como funciona
Os dados são armazenados criptografados nos datafiles, ou seja, mesmo que pessoas que não tenham acesso ao banco tentem ver seu conteúdo usando ferramentas do sistema operacional, ele lhes será incompreensível.
Os dados também são armazenados criptografados nos backups e logs de auditoria.
O DBA cria uma senha de wallet (veremos mais adiante) e, mesmo que o backup da fita seja restaurado em um outro computador as colunas criptografadas não podem ser vistas sem essa senha.
Uma coluna criptografada só pode ser exportada mediante uso de senha de criptografia, e importada por quem souber essa mesma senha.
A Figura 1 mostra um esquema geral do funcionamento do TDE. Veremos mais adiante em detalhes cada passo dessa criptografia mas, como um sumário, elas nos mostra que, quando escolhemos colunas para criptografar na base, essas colunas são armazenadas com criptografia usando uma chave de tabela, chamada “table key”.
O dicionário de dados armazena as table keys de forma criptografada. Para criptografá-las/decriptografá-las ele utiliza-se de outra chave, a master key, que fica armazenada fora do banco, na wallet.
Figura 1. Funcionamento do TDE, por Arup Nanda.
Chaves de Criptografia
O TDE usa um mecanismo de chaves de criptografia em dois níveis:
· Nível 1: Ao criptografar uma coluna, uma chave de criptografia é gerada para a tabela. Essa é a TABLE KEY.
· Nível 2: As TABLE KEYs de todas as tabelas que usam TDE são armazenadas no dicionário de dados de forma criptografada usando uma mesma chave comum, chamada MASTER KEY, que fica armazenada na wallet.
Tanto as TABLE KEYs quanto a MASTER KEY podem ser alteradas de forma independente. A Oracle recomenda o backup da wallet após mudar qualquer uma delas.
As colunas não são re-criptografadas após a mudança da master key, apenas na mudança de table keys. A wallet guarda um histórico das últimas master keys utilizadas.
A mudança das table keys é interessante sempre que se suspeita que ela foi descoberta.
Por fim, é importante informar que alterar a senha de wallet não altera a master key. Elas são independentes.
Mão na Massa
Vamos a um exemplo prático. Suponha as tabelas CLIENTES e CARTOES da Listagem 1.
Listagem 1. Estrutura das tabelas CLIENTES e CARTOES.
SQL> desc clientes
Name Null? Type
-------------------------- -------- ----------------------------
NOME VARCHAR2(30)
SOBRENOME VARCHAR2(30)
SQL> desc cartoes
Name ...
