Introdução
A LGPD regula as atividades de processamento de dados pessoais por cidadãos, empresas e órgãos públicos no Brasil, estabelecendo direitos, exigências e procedimentos relacionados à coleta e ao processamento de dados pessoais. A Lei obriga organizações a seguirem uma série de itens quanto à coleta, ao tratamento e à proteção dos dados pessoais, tendo como foco proteger direitos fundamentais de liberdade e privacidade dos indivíduos, complementando regulamentações previamente existentes na Convenção Europeia de Direitos Humanos e impondo maiores obrigações aos agentes privados detentores de dados pessoais. A lei brasileira foi aprovada em 2018 entrando em vigor em agosto deste ano foi baseada em uma legislação similar, a GDPR (General Data Protection Regulation, na sigla em inglês), que entrou em vigor na Europa em maio de 2018.
A LGPD se aplica às empresas que realizam a operação de tratamento de dados em território brasileiro, independentemente do país sede da companhia ou de onde estejam localizados os dados, desde que as atividades de processamento sejam realizadas no Brasil, o objetivo das atividades de processamento seja oferecer bens ou serviços no Brasil ou para indivíduos localizados no Brasil ou os dados pessoais sejam coletados no Brasil.
A maioria das organizações armazena os dados pessoais coletados dos clientes em Sistemas de Gerenciamento de Banco de Dados (SGBD). Dessa forma, é necessário saber como e o quanto as empresas detentoras dos principais SGBDs comerciais estão preparadas para dar suporte à implantação de estratégias da LGPD de forma eficaz e eficiente. Os SGBDs dos principais fornecedores de mercado dispõem de recursos para prover segurança da informação em seus produtos. Mais recentemente, no entanto, este aspecto vem se ampliando para tratar da privacidade, também motivado por este cenário recente em que a LGPD se insere.
Neste sentido, a Oracle disponibiliza uma série de pacotes para aumentar a segurança dos dados armazenados, tais como: Oracle Advanced Security, Oracle Key Vault, Oracle Data Masking and Subsetting etc. Tais pacotes oferecem suporte à: criptografia de dados transparente; gerenciamento de chave de criptografia, controle de acesso multifatores e usuários com privilégios, classificação e descoberta de dados; monitoramento e bloqueio de atividades de banco de dados, auditoria e relatórios consolidados e mascaramento de dados. Já a Microsoft disponibilizou um guia de conformidade com o LGPD, mencionando como ferramentas do SGBD SQL Server 2017 podem auxiliar neste sentido, visando auxiliar estratégias de implantação da LGPD. Nesse artigo iremos destacar:
ORACLE ADVANCED SECURITY ENCRYPTION
O Oracle Advanced Security Transparent Data Encryption (TDE), é a solução de criptografia mais avançada no setor. Lançada no Oracle Database 10g, a TDE usa algoritmos de criptografia padrão no setor e um gerenciamento de chaves integrado para fornecer uma criptografia transparente de dados de aplicativos confidenciais. Diferente das opções disponíveis de criptografia em bancos de dados de 3°s, não são necessários triggers de banco de dados, visualizações nem outras alterações de aplicativos. A TDE criptografa os dados automaticamente antes deles serem gravados em disco e decodifica os dados antes deles serem retornados ao aplicativo. O processo de criptografia e decodificação é completamente transparente a aplicativos e usuários.
A TDE permite proteger em nível de atributo individual ou em nível de toda a tabela. Exemplos de atributos individuais incluem itens como números de cartão de crédito e CPF. Esses tipos de atributos geralmente são difundidos por muitos aplicativos comerciais de uso comum.
No Oracle Database 11g pode se optar por ignorar o processo de identificar quais atributos codificar e simplesmente utilizar a nova funcionalidade de criptografia de tablespace da TDE para proteger integralmente os aplicativos. Todos os objetos de banco de dados criados no novo tablespace serão codificados automaticamente.
Usar a criptografia de tablespace da TDE para codificar todas as tabelas do aplicativo proporciona ainda mais transparência e economia de custos. A necessidade de identificar atributos individuais que necessitam de criptografia é completamente eliminada. Além disso, a criptografia de tablespace da TDE proporciona ainda mais transparência pois todos os tipos de dados são suportados e não há custos de desempenho associados com varreduras complexas de intervalos de índices em dados criptografados.
Quando ocorre o backup do banco de dados, os arquivos codificados permanecem criptografados nas mídias de destino, protegendo as informações mesmo se mídias forem perdidas ou furtadas. Os clientes que simplesmente desejam criptografar seus backups podem obter a proteção usando o Oracle RMAN em conjunto com o Oracle Advanced Security. Criptografar backups protege os dados se as mídias de backup caírem em mãos erradas ou forem perdidas em trânsito. Os backups codificados são decodificados automaticamente durante operações de restauração e recuperação, desde que as chaves de decodificação exigidas estejam disponíveis.
A Oracle recomenda fazer do Oracle Advanced Security Wallet em mídias separadas, e armazenar as chaves em vários locais protegidos,o que permite que você implante rapidamente criptografia e outras soluções de segurança gerenciando centralmente chaves de criptografia, carteiras Oracle, keystores Java (JKS), keystores Java Cryptography Extension (JCEKS) e arquivos de credenciais. O Oracle Key Vault é otimizado para gerenciar as chaves mestras do Oracle Advanced Security Transparent Data Encryption (TDE).
Ativando a Transparent Data Encryption para o banco de dados Oracle
O Transparent Data Encryption possui dois níveis de Encryption Key.
Master Encryption Key: É uma chave de criptografia externa ( Oracle Wallet ou HSM ) ao banco de dados, essa chave será integrada ao hash de criptografia do dicionário de dados do oracle.
Tables e/ou Tablespaces Encryption Keys: São chaves de criptografia armazenadas no dicionário de dados do oracle, durante o processo de encriptação dos dados em colunas ou tablespace, algoritimos de criptografia devem ser informados ex: AES128 e AES256, complementando com a Master Key, é gerado um algoritimo único para aquela tabela ou tablespace.
Assim, a ideia apresentada acima pode ser resumida nessa imagem:
Master Encryption Key pode ser armazenado em:
Oracle Wallet: Método baseado em arquivo de senhas criptografada, armazenado fora do ambiente oracle database.
Hardware Security Modulo(HSM): Um dispositivo de segurança de chaves que realiza operações de criptografia utilizando certificados.
Como configurar:
1. Defina Manualmente um diretório , nesse caso definiremos:
/u01/app/oracle/admin/WINT/wallet
2. Adicione o conteúdo a seguir ao arquivo sqlnet.ora para criar o arquivo do repositório de chaves de carteira da criptografia no diretório especificado. Vá até o local do arquivo sqlnet.ora.
# vim sqlnet.ora ENCRYPTION_WALLET_LOCATION (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /u01/app/oracle/admin/WINT/wallet )SQLNET.AUTHENTICATION_SERVICES = (NTS)
3. Defina uma senha no arquivo Oracle Wallet
alter system set encryption key identified by oracle; 4. Verifique o status da carteira que você criou executando o seguinte comando: - execute o seguinte comando:
SQL > select * from v$encryption_wallet;
5. Caso o status da carteira seja CLOSE, abra-a executando o seguinte comando:
SQL> alter system set wallet open identified by ;
6. Crie uma tablespace MDB_DATA_TEST DATAFILE criptografado executando o seguinte comando:
create tablespace MDB_DATA_TEST DATAFILE '/u01/oradata/WINT/MDB_DATA_TEST.DBF' SIZE 100M autoextend on next 100M ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
7. Da mesma forma, crie um índice para a tablespace criada anteriormente MDB_INDEX_TEST DATAFILE criptografado executando o seguinte comando:
create tablespace MDB_INDEX_TEST DATAFILE '/u01/oradata/WINT/MDB_INDEX_TEST.DBF' SIZE 100M autoextend on next 100M ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
8. Crie um usuário para o nome do tablespace que você criou na etapa 6.
create user tdeteste identified by oracle default tablespace MDB_DATA_TEST;
9. Altere um usuário para o índice da tablespace que você criou na etapa 8:
alter user tdeteste identified by oracle default tablespace MDB_INDEX_TEST;
10. Altere os usuários com cota ilimitada de tablespace.
alter user tdeteste quota unlimited on MDB_DATA_TEST;
11. Altere os usuários com cota ilimitada de índice.
alter user tdeteste quota unlimited on MDB_INDEX_TEST;
12. Agora, conceda os privilégios necessários ao usuário.
grant CREATE PROCEDURE to tdeteste; grant CREATE SEQUENCE to tdeteste;
grant CREATE SESSION to tdeteste; grant CREATE TABLE to tdeteste; grant CREATE TRIGGER to tdeteste; grant CREATE VIEW to tdeteste; grant CONNECT to tdeteste; grant RESOURCE to tdeteste;
13. Confirme as alterações.
Commit;
Verifique se a Transparent Data Encryption está ativada
Verifique se a tablespace está ativado para TDE. Execute o comando abaixo para confirmar e verificar se o status da criptografia do banco de dados está ativado ou não para TDE:
SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET; SELECT * FROM V$ENCRYPTED_TABLESPACES; O resultado mostra a lista dos tablespace com criptografia em que é possível confirmar se o tablespace criado por você está criptografado ou não.
Vamos analisar o comportamento dos dados armazenados no datafile sem qualquer tipo de criptografia.
create user tdeteste2 identified by oracle default tablespace NOENCRYPTEDCOL create table tdeteste2.tab_cpf ( nome varchar(30), cpf varchar(11) ) tablespace NOENCRYPTEDCOL; CREATE TABLESPACE NOENCRYPTEDCOL DATAFILE '/u01/oradata/WINT/NOENCRYPTEDCOL.DBF' SIZE 100M autoextend on next 100M; create table tdeteste2.tab_cpf ( nome varchar(30), cpf varchar(11) ) tablespace NOENCRYPTEDCOL; insert into tdeteste2.tab_cpf values ( 'Jose','33344455545'); insert into tdeteste2.tab_cpf values ( 'Maria','88844411147'); insert into tdeteste2.tab_cpf values ( 'Manoel','88844411147'); strings /u01/oradata/WINT/NOENCRYPTEDCOL.DBF
Em outro caso vamos analisar o comportamento dos dados armazenados no datafile, após criar uma tabela apenas com um campo com criptografia.
create user tdeteste2 identified by oracle default tablespace NOENCRYPTEDCOL create table tdeteste2.tab_cpf ( nome varchar(30), cpf varchar(11) ) tablespace NOENCRYPTEDCOL; CREATE TABLESPACE NOENCRYPTEDCOL DATAFILE '/u01/oradata/WINT/NOENCRYPTEDCOL.DBF' SIZE 100M autoextend on next 100M; create table tdeteste2.tab_cpf ( nome varchar(30), cpf varchar(11) ) tablespace NOENCRYPTEDCOL; insert into tdeteste2.tab_cpf values ( 'Jose','33344455545'); insert into tdeteste2.tab_cpf values ( 'Maria','88844411147'); insert into tdeteste2.tab_cpf values ( 'Manoel','88844411147');
Referências
https://sol.sbc.org.br/livros/index.php/sbc/catalog/download/39/163/333-1?inline=1
https://www.oracle.com/br/cloud/lgpd/
https://www.oracle.com/br/database/technologies/security/data-masking-subsetting.html
https://docs.oracle.com/database/121/DMKSB/intro.htm#DMKSB-GUID-24B241AF-F77F-46ED-BEAE-3919BF1BBD80