A LGPD ou LGPDP, Lei Geral de Proteção de Dados Pessoais (13.709/2018) está em vigor desde setembro de 2020. Com isso, a forma com que as instituições coletam, armazenam e disponibilizam os dados dos usuários precisou se adaptar. A lei define o que são dados pessoais (qualquer dado que permita identificar certo indivíduo) e explica que alguns deles estão sujeitos a cuidados ainda mais específicos, como os dados pessoais sensíveis (raça, etnia, religião, sexualidade, saúde, etc…) e dados pessoais sobre crianças e adolescentes. O vazamento dessas informações pode gerar multa de até 2% do faturamento anual da organização, limitado a 50 milhões por infração. Em razão disso, os setores do TI precisaram rever questões em relação à segurança desses dados, garantindo que as informações dos usuários não fiquem expostas a qualquer pessoa.

No que se refere ao banco de dados especificamente, há algumas maneiras de restringir o acesso dessas informações. No SQL Server, dois recursos nativos podem ser úteis nessa questão de segurança dos dados: TDE (Transparent Data Encryption) e Always Encrypted.

TDE – Transparent Data Encryption

O TDE garante a segurança do dado, quando algum terceiro mal-intencionado tem acesso às mídias físicas do banco de dados (arquivos, logs e backups). Ele não criptografa o dado em si, permanecendo na sua forma original nas tabelas do banco de dados. O que é garantido é que não seja possível utilizar esses dados, anexando ou restaurando um backup, sem o certificado e a master key. Essa feature é ligada por padrão nos bancos do SQL Azure:

use [master]
go

create master key encryption by password = 'My!C0mpl3x?P@ssword';
go

create certificate TDE_Certificate with subject = 'Certificado do TDE';
go

use [AdventureWorks2019]
go

create database encryption key with algorithm = AES_256 
encryption by server certificate TDE_Certificate
go

alter database [AdventureWorks2019] set encryption on
go

A consulta abaixo serve para verificar o estado ou o andamento da criptografia:

select
          D.name,
          D.is_master_key_encrypted_by_server,
          D.is_encrypted,
          case DEK.encryption_state
                       when 0 then 'Nenhuma chave de criptografia de banco de dados presente, nenhuma criptografia'
                       when 1 then 'Sem-criptografia'
                       when 2 then 'Criptografia em andamento'
                       when 3 then 'Criptografado'
                       when 4 then 'Alteração de chave em andamento'
                       when 5 then 'Alteração de proteção em andamento'
          end as encryption_state,
          DEK.percent_complete -- Percentual concluído da alteração de estado da criptografia do banco de dados
from sys.databases as D
left outer join sys.dm_database_encryption_keys as dek
  on dek.database_id = D.database_id

Uma vez habilitada a TDE, se faz necessário salvar um backup do certificado e da key, pois caso seja necessário restaurar o backup do banco de dados em outro servidor, não será possível sem eles. O script abaixo faz o backup desses artefatos:

use [master]
go

backup certificate TDE_Certificate 
to file = 'C:\Backups\CertificadoTDE.cer'
with private key
(
file = 'C:\Backups\MasterKey.pvk', 
encryption by passwork = 'My!C0mpl3x?P@ssword'
)
go

Always Encrypted

Uma das maneiras de garantir, numa eventual ocorrência de vazamento de dados, que esses dados não sejam visualizados de forma indevida, é criptografá-los na origem, ou seja, no próprio banco de dados. Isso garante que o acesso ao dado na sua forma original, somente seja possível com as devidas chaves de criptografia. O dado fica criptografado até mesmo para quem gerencia o banco de dados (e que também não deveria ter acesso à informação), garantindo apenas que as aplicações clientes autorizadas possam visualizar o conteúdo descriptografado.

Diferentemente do TDE que é aplicado a todo banco de dados, o Always Encrypted permite definir quais as colunas de determinada(s) tabela(s) deverão ser criptografadas. A criptografia pode ser de duas formas:

• Determinística: na qual sempre gera o mesmo valor, para o mesmo texto;
• Aleatória: na qual para o mesmo texto, o valor criptografado difere.

Não é possível criptografar os dados de uma tabela existente via código T-SQL, entretanto, podemos utilizar o Management Studio para essa tarefa, conforme o passo a passo abaixo, extraído da documentação da Microsoft:

1. Conecte a um banco de dados existente que contém as tabelas com as colunas que você deseja criptografar usando o Object Explorer do Management Studio ou crie um novo banco de dados, crie uma ou mais tabelas com colunas para criptografar e conecte-se a elas.
2. Clique com o botão direito do mouse no banco de dados, aponte para Tarefas e clique em Criptografar Colunas… para abrir o Assistente do Always Encrypted.
3. Examine a página Introdução e, em seguida, clique em Avançar.
4. Na página Seleção de Coluna, expanda as tabelas e selecione as colunas que você deseja criptografar.
5. Para cada coluna selecionada para criptografia, defina o Tipo de Criptografia como Determinística ou Aleatória.
6. Para cada coluna selecionada para criptografia, selecione uma Chave de Criptografia. Se você ainda não criou nenhuma chave de criptografia para esse banco de dados, selecione a opção padrão de uma nova chave gerada automaticamente e clique em Avançar.
7. Na página Configuração da Chave Mestra, selecione um local para armazenar a nova chave e uma fonte de chave mestra e clique em Avançar.
8. Na página Validação , escolha se deseja executar o script imediatamente ou criar um script do PowerShell e, em seguida, clique em Avançar.
9. Na página Resumo, examine as opções que você selecionou e clique em Concluir. Feche o assistente após a conclusão.

Como alternativa, pode ser utilizado o seguinte script PowerShell:

# Import the SqlServer module.
Import-Module "SqlServer"

# Connect to your database.
$serverName = "<server name>"
$databaseName = "<database name>"
# Change the authentication method in the connection string, if needed.
$connStr = "Server = " + $serverName + "; Database = " + $databaseName + "; Integrated Security = True"
$database = Get-SqlDatabase -ConnectionString $connStr

# Encrypt the selected columns (or re-encrypt, if they are already encrypted using keys/encrypt types, different than the specified keys/types.
$ces = @()
$ces += New-SqlColumnEncryptionSettings -ColumnName "Person.PersonAE.MiddleName" -EncryptionType "Deterministic" -EncryptionKey "CEK1"
$ces += New-SqlColumnEncryptionSettings -ColumnName "Person.PersonAE.LastName" -EncryptionType "Randomized" -EncryptionKey "CEK1"
Set-SqlColumnEncryption -InputObject $database -ColumnEncryptionSettings $ces -UseOnlineApproach -MaxDowntimeInSeconds 180 -LogFileDirectory .

A imagem abaixo mostra o resultado da criptografia aplicado às colunas MiddleName e LastName da tabela PersonAE no banco AdventureWorks 2019:

Infelizmente, existem alguns contras em relação a criptografia das colunas com o Always Encrypted:

• Necessita de mais storage para armazenar a mesma informação. Em média é necessário cerca de 3x mais espaço por coluna no disco;
• Existe uma perda aceitável de performance na leitura do dado, porém a operação de escrita pode ter um acréscimo de cerca de 40% na sua duração.

Conceitos de anonimização segundo a Lei 13.709/2018

O Artigo 12 da LGPD versa especificamente sobre anonimização e assim dispõe:

“Os dados anonimizados não serão considerados dados pessoais para os fins desta Lei, salvo quando o processo de anonimização ao qual foram submetidos for revertido, utilizando exclusivamente meios próprios, ou quando, com esforços razoáveis, puder ser revertido”

Em uma análise com olhar técnico, tanto o TDE quanto o Always Encrypted tornam os dados “ilegíveis”, não sendo possível a sua identificação à primeira vista. Ainda assim, de posse das chaves criptográficas é possível executarmos a leitura e identificação dos dados. Esse processo é nomeado como pseudoanonimização e é assim definido no parágrafo 4° do artigo 13 da LGPD:

“… a pseudonimização é o tratamento por meio do qual um dado perde a possibilidade de associação, direta ou indireta, a um indivíduo, senão pelo uso de informação adicional mantida separadamente pelo controlador em ambiente controlado e seguro.”

Uma anonimização completa de dados pessoais não é reversível de maneira alguma e é empregada com sucesso em bases de dados destinadas a estudos estatísticos e pesquisas científicas. Um exemplo simples disso é ter cadastrado em um banco de dados números de celulares no formato (999) 99999-9999. Suponhamos que essa base de dados de números telefônicos será usada para análise de volume de vendas por cidade (dado o fato de que o titular do dado autorizou este estudo). Para usarmos o dado anonimizado, pode-se simplesmente remover todos os números de telefone mantendo apenas o DDD (Ex. (11) 90987-1234 passa a figurar como (11)XXXXX-XXXX).

A pseudoanonimização, como exemplificada usando o TDE e o Always Encrypted e empregada usando as devidas medidas de segurança das chaves criptográficas, é o método que permite o uso do dado em produção e adiciona uma camada bastante robusta de criptografia para evitar um vazamento em caso de exfiltração de dados.

Como demonstrado no artigo acima, podem ser utilizados recursos nativos do próprio SQL Server para garantir que o ambiente do banco de dados esteja em conformidade com o que é previsto na LGPD. O uso da criptografia do dado, garante a segurança de que a informação não seja exposta de forma indevida, entretanto se faz necessário analisar qual será o impacto que poderá ter em relação à performance e armazenamento.

Como a EximiaCo pode lhe ajudar

Nossa consultoria e assessoria em Arquitetura de Dados atua na análise e implantação de otimização de bancos de dados melhorando significativamente a performance de sistemas e geralmente reduzindo custos. Além disso, revisamos todas as configurações dos servidores do banco de dados, levando em conta as melhores práticas de configuração e segurança necessárias para a estabilidade, performance e continuidade do seu negócio.

Se sua empresa quer promover a autonomia de seu time nas melhores práticas de performance e segurança de banco de dados, conheça nossas capacitações in company SQL na Velocidade da Luz, onde são apresentadas técnicas avançadas para a modelagem e otimização de performance e Melhores Práticas de Configuração do SQL Server, que apresenta rotinas otimizadas para manutenção, backup e monitoramento da saúde do banco de dados.