Por: Fabiano Lira
Segurança de dados é um assunto que está em alta. A atual pandemia criou um marco importante com relação ao trabalho home-office, ou “teletrabalho” (que palavra feia, convenhamos).
Visando resguardar a saúde dos seus colaboradores, muitas empresas não tiveram opção a não ser abrir mão da atuação presencial. Com essa multidão de pessoas trabalhando de suas casas, companhias que não tinham uma política bem definida de compliance e segurança para esse tipo de trabalho, viram-se obrigadas a implementá-las com uma certa urgência, para atender essa demanda.
Quem teve esse tipo de preocupação saiu na frente. Empresas que não tinham, ou não se preocuparam com essa questão, estão contando com a sorte quando já não sofreram as consequências.
Devido à atual conjuntura, ataques cibernéticos aumentaram 900% durante a pandemia.
Paralelo a este cenário pandêmico, temos os avanços da GDPR (ou LGPD) que fazem as companhias se moldarem às regulações impostas pela mesma. No artigo 32, parágrafo 2, que dispõe sobre a segurança no processamento de dados temos o seguinte:
Na avaliação do nível adequado de segurança, serão levados em consideração, em particular, os riscos apresentados no processamento […] ou acesso adados pessoais transmitidos, armazenados ou processados de outra forma.
Povos antigos já utilizavam criptografia: cifra de César, cifra de Vigenère, entre outras.
Na história recente temos o exemplo da máquina Enigma, utilizada na Segunda Guerra Mundial. Então dá pra notar que a criptografia não é um assunto novo, ela apenas foi trazida para o mundo da computação e agora podemos utilizá-la sob sistemas computacionais que trazem mais segurança realizando cálculos muito mais complexos que os de antigamente.
Neste artigo pretendo mostrar, de forma breve, alguns recursos de criptografia para você, que utiliza SQL Server, possa proteger um pouco mais seu ambiente de banco de dados. Gostaria de lembrar que a criptografia vai te proteger para quando o estrago já estiver feito e alguém já tiver acesso ao seu ambiente, tornando os dados inúteis para o invasor. Por isso é importante ter outras políticas, principalmente de controle de acesso aos dados.
Em trânsito ou em repouso?
Dizemos que os dados estão em trânsito se estão trafegando de uma ponta a outra em alguma rede. Quando um invasor se posiciona entre as partes que estão tentando se comunicar, temos um tipo de ataque chamado man-in-the-middle. Acontece com certa frequência em redes wi-fi públicas, onde o hacker intercepta os pacotes enviados e recebidos pela vítima. Depois de interceptar esses dados, ele pode realizar transferências bancárias, elaborar golpes via engenharia social, entre outros. Já os dados em repouso estão guardados, “repousando” em algum banco de dados ou algum disco esperando serem requisitados.
Neste artigo, vou abordar de forma breve dois recursos: um para criptografia de dados em repouso e outro para criptografia de dados em trânsito que são excelentes e podem ser aplicados em praticamente qualquer instância SQL Server.
Adianto que não abordarei o Always Encrypted, lançado no SQL Server 2016. Esse é um excelente recurso, porém não é recomendado para criptografar o banco de dados inteiro e também depende que a aplicação possua as bibliotecas .NET mais recentes. Caso você possua em seus bancos de dados apenas algumas colunas que contém dados sensíveis, vale a pena dar uma olhada mais a fundo neste recurso que criptografa os dados tanto em trânsito quanto em repouso.
Transparent Data Encryption (TDE)
Na categoria de criptografia de dados em repouso, temos o TDE. Esse recurso criptografa os arquivos físicos do banco de dados, sejam datafiles (MDF) ou logfiles (LDF). Foi introduzido no SQL Server 2008 e até hoje é um excelente recurso. Pode ser utilizado inclusive em plataformas cloud como Azure SQL Database e Amazon RDS.
Sua implantação é bastante simples, basta criar algumas chaves, um certificado e habilitar a criptografia no banco em questão.
Primeiro criamos a Database Master Key (que protegerá o certificado), depois um certificado que protegerá a DEK (Database Encryption Key) e por fim a DEK.
USE [master];
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MinhaSenhaForte@123’;
GO
CREATE CERTIFICATE CertOne WITH SUBJECT = ‘Certificado da DEK’;
GO
USE [MyDB];
GO
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE CertOne;
GO
ALTER DATABASE MyDB SET ENCRYPTION ON;
GO
É importante lembrar que caso o TDE seja habilitado para um banco de dados, a tempdb da instância será criptografada automaticamente. Isso pode ocasionar impacto de performance para outros bancos de dados da instância, mesmo que estes não estejam utilizando criptografia.
Outro ponto importante é que logo após habilitar o TDE você deve fazer um backup do certificado com a chave associada e guardá-los em um local seguro. Sem isso você pode perder seu banco de dados pois sem esse certificado você não consegue restaurá-lo.
Criptografia de conexão com TLS (Transport Layer Security)
Essa é uma forma de criptografar os dados enquanto eles estão em trânsito, evitando que alguém intercepte a comunicação e consiga interpretar as informações que estão trafegando entre os canais. Em Janeiro de 2016, a Microsoft anunciou suporte ao TLS 1.2 para todas as versões a partir do SQL Server 2008. Antigamente utilizava-se muito o SSL (Secure Sockets Layer), que é basicamente a mesma coisa que o TLS, porém menos seguro e com mais vulnerabilidades conhecidas. No SQL Server 2016 o SSL foi descontinuado e devemos utilizar o TLS.
É importante salientar que este tipo de criptografia pode ocasionar impacto de performance, por isso é importante testar a criptografia durante um certo tempo para termos certeza de que o throughput de rede não aumentou demais e está sendo um gargalo, o que não ocorre na maioria dos casos. A implantação do TLS também é bastante simples mas você precisará de um certificado gerado por uma autoridade certificadora (ou Certification Authority, a.k.a. CA), que pode ser interna ou terceira. Para fins de teste, você pode gerar um certificado auto assinado (self-signed), que não é tão seguro e está suscetível a ataques man-in-the-middle.
Este certificado deve ser instalado no servidor de banco de dados de forma que quando o cliente requisitar a conexão criptografada, o servidor apresentará este certificado e o cliente aprovará ou não a conexão. Para isto o cliente também precisará de uma cópia do certificado. Uma analogia: você vai à Polícia Federal fazer um passaporte, mas para isso o agente precisa ver seu RG, conferir se esse RG foi emitido por uma entidade confiável (ou seja, não é falso) e depois confirmar se os dados do seu RG batem com o que está no sistema deles. Após todo esse trâmite é que inicia-se o processo.
Depois de instalar este certificado no sistema operacional do servidor, associaremos este certificado à instância SQL Server onde você pretende ter as conexões criptografadas. É como se falássemos à instância: “Ei, quando alguém solicitar uma conexão criptografada use este certificado aqui.”. Isto é feito de forma fácil pelo próprio SQL Server Configuration Manager.
Muita gente costuma marcar a opção “Force Encryption” na aba de protocolos do Configuration Manager. Esta opção faz com que a instância não aceite conexões que não sejam criptografadas.
Depois de reiniciar a instância, ela estará pronta para receber conexões criptografadas. Na connection string adicionaremos: Encrypt=True;
Você saberá que funcionou consultando a coluna encrypt_option na DMV sys.dm_exec_connections:
SELECT s.session_id
, s.host_name
, s.client_interface_name
, c.encrypt_option
FROM sys.dm_exec_connections c
JOIN sys.dm_exec_sessions s ON s.session_id = c.session_id
Gostou do conteúdo? Acompanhe nosso blog para mais assuntos técnicos.