SQL Server 2016 – Como criptografar seus dados utilizando Always Encrypted

Fala galera!
Prontos para mais um artigo ?

Introduction

Com o advento do GDPR, a preocupação das empresas com segurança de dados vem crescendo cada vez mais, e uma área que antes era por vezes deixada de lado, está em evidência mais do que nunca agora. Em decorrência disso, os profissionais de TI, em especial os DBAs, vem procurando formas de reduzir os riscos de exposição de dados e uma das formas de se fazer isso, é criptografando os dados para evitar acesso não autorizado por terceiros.

A minha ideia nesse artigo é demonstrar uma solução do SQL Server que permite criptografar os dados, que é o Always Encrypted, disponível a partir do SQL Server 2016 nas edições Express, Standard, Enterprise e Developer (Express e Standard a partir do 2016 SP1).

Não deixe de conferir o meu post SQL Server 2008 – Como criptografar seus dados utilizando Transparent Data Encryption (TDE), outra solução de criptografia de dados do SQL Server.

Para os exemplos abaixo, vou utilizar o seguinte script para geração da base:

O que é o Always Encrypted

O Always Encrypted é um recurso criado para proteger dados confidenciais, disponível a partir do SQL Server 2016, como números de cartão de crédito ou de identificação nacional (por exemplo, números de previdência social dos EUA), armazenados em bancos de dados do Banco de dados SQL do Azure ou SQL Server. O Always Encrypted permite que os clientes criptografem os dados confidenciais em aplicativos de cliente e nunca revelem as chaves de criptografia para o Mecanismo de Banco de Dados. Como resultado, o Always Encrypted fornece uma separação entre aqueles que possuem os dados (e podem exibi-lo) e aqueles que gerenciam os dados (mas que não devem ter acesso).

Uma das maiores vantagens do Always Encrypted é que apenas os usuários e aplicações que possuem a chave mestra de criptografia tem acesso aos dados originais. Nem mesmo os DBAs e outros usuários sysadmin conseguem visualizar os dados originais. Isso garante uma segurança aos dados e informações num nível raramente visto em outras soluções. Outra grande vantagem dessa solução, é que os dados são criptografados e também os logs, os backups e os dados trafegados pela rede, garantindo total segurança em todos os meios de comunicação, mesmo que alguém intercepte pacotes durante a transmissão dos mesmos. Em vista disso, a perda da chave mestra pode ser fatal para os seus dados, pois a recuperação dos mesmos não é mais possível, uma vez que um backup realizado em um database com Always Encrypted só pode ser restaurado em outra instância caso a chave mestra seja restaurada antes.

O Always Encrypted torna a criptografia quase transparente para os aplicativos. Um driver habilitado para Always Encrypted instalado no computador cliente realiza isso automaticamente criptografando e descriptografando dados confidenciais no aplicativo cliente. O driver criptografa as colunas de dados confidenciais antes de passar os dados para o Mecanismo de Banco de Dadose reconfigura automaticamente as consultas para que a semântica do aplicativo seja preservada. Da mesma forma, o driver descriptografa de modo transparente os dados armazenados em colunas de banco de dados criptografado que estão contidos nos resultados da consulta.

Entretanto, embora esse recurso garanta um excelente nível de segurança, fique atento a possíveis problemas de performance ao utilizá-lo e aumento do consumo de espaço:

Always Encrypted vs Transparent Data Encryption (TDE)

Logo abaixo, vou listar algumas semelhanças e diferenças entre essas duas soluções de criptografia do SQL Server:

Criptografia Determinística ou Aleatória

Ao utilizar o Always Encrypted, você verá que existem 2 formas de criptografar colunas nessa solução:

• Determinística (Deterministic): A criptografia determinística sempre gera o mesmo valor criptografado para o mesmo texto. Usar a criptografia determinística proporciona lookups, joins, agrupamentos e indexação em colunas criptografadas. No entanto, também pode permitir que usuários não autorizados estimem informações sobre valores criptografados examinando padrões na coluna criptografada, especialmente se houver um pequeno conjunto de valores possíveis criptografados, como True/False ou região Norte/Sul/Leste/Oeste.
• Aleatória (Randomized): A criptografia aleatória usa um método que criptografa os dados de uma maneira menos previsível, ou seja, para um mesmo texto o valor criptografado é diferente. A criptografia aleatória é mais segura, mas impede o uso de pesquisas, agrupamentos, indexação e joins em colunas criptografadas.

Como instalar e configurar o Always Encrypted no SQL Server

Agora que já expliquei um pouco da teoria do Always Encrypted, vamos partir para a parte prática.

A forma mais prática de se criptografar uma coluna, é utilizando o SQL Server Management Studio (SSMS):

E a alteração de tabelas existentes também pode ser feita utilizando PowerShell:

Entretanto, não é possível criptografar colunas de tabelas já existentes utilizando Transact-SQL, apenas realizar a criação de uma nova tabela criptografada (você pode criar uma nova tabela criptografada e migrar os dados da tabela anterior), que teria essa sintaxe:

Visualizando os dados do Always Encrypted no SQL Server

Agora que criptografamos as colunas da tabela dbo.Pessoa, vamos tentar visualizar os dados originais, logado com um usuário sysadmin:

Para visualizar novamente os dados originais no SSMS, você precisará informar o parâmetro column encryption setting=enabled na string de conexão:

Após alterar essa configuração, você poderá visualizar os dados originais novamente.

Vale lembrar que o usuário só poderá ver os dados originais se ele tiver as permissões de VIEW ANY COLUMN MASTER KEY DEFINITION e VIEW ANY COLUMN ENCRYPTION KEY DEFINITION ou se você estiver armazenando as Master Encryption Key e Column Encryption Key no servidor de banco (Windows Certification Store) e o certificado está armazenado na sua máquina ou no seu usuário. Caso você queira utilizar uma forma mais segura, opte pelo Azure Key Vault (AKV).

Para auxiliar na configuração do Always Encrypted em suas aplicações, separei mais 2 artigos que podem auxiliar os DEV’s a configurarem esse recurso com o Azure Key Vault (AKV):

• https://docs.microsoft.com/en-us/azure/sql-database/sql-database-always-encrypted-azure-key-vault
• https://blogs.msdn.microsoft.com/sqlsecurity/2015/11/10/using-the-azure-key-vault-key-store-provider-for-always-encrypted/

Como identificar quais colunas estão criptografas com Always Encrypted

Para identificar quais colunas estão criptografadas com Always Encrypted e qual o algoritmo de criptografia utilizado, basta utilizar a consulta abaixo:

Result:

Restrições do Always Encrypted

Não há suporte para o Always Encrypted nas colunas com as características abaixo (por exemplo, a cláusula Encrypted WITH não poderá ser usada em CREATE TABLE/ALTER TABLE de uma coluna se uma das seguintes condições se aplicar à coluna):

• Colunas usando um dos seguintes tipos de dados: xml, timestamp/rowversion, image, ntext, text, sql_variant, hierarchyid, geography, geometry, alias e tipos definidos pelo usuário.
• Colunas FILESTREAM
• Colunas com a propriedade IDENTITY
• Colunas com a propriedade ROWGUIDCOL.
• Colunas de strings (varchar, char, etc.) com agrupamentos não bin2
• Colunas que são chaves para índices não clusterizados usando uma coluna criptografada de forma aleatória como uma coluna de chave (colunas criptografadas de forma determinística são permitidas)
• Colunas que são chaves para índices clusterizados usando uma coluna criptografada de forma aleatória como uma coluna de chave (colunas criptografadas de forma determinística são permitidas)
• Colunas que são chaves para índices de fulltext contendo colunas criptografadas, aleatórias e determinísticas
• Colunas referenciadas por colunas computadas (quando a expressão realiza operações sem suporte para o Always Encrypted)
• Conjunto de colunas sparse
• Colunas que são referenciadas por estatísticas
• Colunas usando tipo de alias
• Colunas de particionamento
• Colunas com constraint default
• Colunas referenciadas por unique constraints ao usar a criptografia aleatória (há suporte para a criptografia determinística)
• Colunas de chave primária ao usar a criptografia aleatória (há suporte para a criptografia determinística)
• Fazer referência a colunas em restrições de chave estrangeira ao usar a criptografia aleatória, ou ao usar a criptografia determinística, se as colunas referenciadas e de referência usarem algoritmos ou chaves diferentes
• Colunas referenciadas por constraint de check
• Colunas em tabelas que usam Change Data Capture (CDC)
• Colunas de chave primária em tabelas com Change Tracking
• Colunas mascaradas (usando Dynamic Data Masking)
• Colunas em tabelas Stretch Database (Tabelas com colunas criptografadas com o Always Encrypted podem ser habilitadas para Stretch.)
• Colunas em tabelas externas (PolyBase) (observação: há suporte para o uso de tabelas externas e tabelas com colunas criptografadas na mesma consulta)
• Não há suporte para parâmetros com valor de tabela com direcionamento a colunas criptografadas.

As cláusulas a seguir não podem ser usadas para colunas criptografadas:

• FOR XML
• FOR JSON PATH

Os recursos a seguir não funcionam em colunas criptografadas:

• Replicação transacional ou replicação merge
• Consultas distribuídas (servidores vinculados)

Dynamic Data Masking

Após demonstrar o uso dessa solução de criptografia, você estar se perguntando: “E o Dynamic Data Masking (DDM)???”. Bom, para começar, o DDM não é uma solução de criptografia de dados e sim uma solução de mascaramento de dados.

Enquanto a criptografia de dados efetivamente impede que os seus dados sejam restaurados (inclusive, a partir de backups) e acessados indevidamente, o mascaramento de dados com o Dynamic Data Masking apenas restringe o conteúdo que é mostrado ao final de um comando de SELECT, ou seja, caso você tenha acesso a um arquivo de backup, você pode restaurá-lo em uma instância onde você seja sysadmin e terá acesso livre aos dados antes mascarados.

Para saber mais sobre o Dynamic Data Masking, veja o artigo SQL Server 2016 – Mascaramento de dados com o Dynamic Data Masking (DDM), onde demonstro como utilizá-lo, restrições e até mesmo como “quebrar” o mascaramento e acessar os dados originais (mesmo sem ter permissão para isso).

Bom pessoal, espero que tenham gostado desse artigo e agora comecem a proteger melhor seus dados!
Grande abraço e até a próxima!