SQL Server 2016 sempre criptografado: fácil de implementar, difícil de quebrar

Os dados são um ativo fundamental de qualquer empresa, principalmente os dados transacionais que guardam segredos comerciais, como registros financeiros ou de saúde. Os dados são mais vulneráveis ​​em trânsito entre o servidor que os armazena e o cliente que os solicita.

A abordagem padrão para garantir a segurança é criptografar os dados no servidor e usar o protocolo HTTPS habilitado para SSL para proteger os dados no transporte. No entanto, e se pudéssemos aumentar ainda mais o nível de segurança, usando HTTPS e enviando dados em formato criptografado pela linha de comunicação, apenas para descriptografar dados em clientes que possuem certificados válidos? Essa abordagem tornaria um ataque tradicional man-in-the-middle (MITM) muito mais difícil.

A solução da Microsoft para esse problema é o Always Encrypted, uma maneira de enviar dados criptografados pelo pipeline e descriptografá-los apenas por usuários com acesso a certificados válidos. Portanto, mesmo que o invasor obtenha os dados, sem um certificado adequado armazenado na máquina cliente, os dados seriam inúteis.

Este artigo descreve como configurar e usar o Always Encrypted, e sua leitura é recomendada para qualquer pessoa que esteja enviando dados importantes pelas linhas de comunicação públicas, mesmo que estejam protegidas com SSL.

O conceito por trás do Always Encrypted

Always Encrypted é uma tecnologia de criptografia do lado do cliente que a Microsoft introduziu com o SQL Server 2016. O Always Encrypted mantém os dados criptografados automaticamente, não apenas quando são gravados, mas também quando são lidos por um aplicativo aprovado. Ao contrário do Transparent Data Encryption, que criptografa os dados e arquivos de log no disco em tempo real, mas permite que os dados sejam lidos por qualquer aplicativo que consulte os dados, o Always Encrypted exige que o aplicativo cliente use um driver habilitado para Always Encrypted para se comunicar com o base de dados. Ao usar esse driver, o aplicativo transfere com segurança os dados criptografados para o banco de dados que podem ser descriptografados posteriormente apenas por um aplicativo que tenha acesso à chave de criptografia. Qualquer outro aplicativo que consulte os dados também pode recuperar os valores criptografados, mas esse aplicativo não pode usar os dados sem a chave de criptografia, tornando os dados inúteis. Devido a essa arquitetura de criptografia, a instância do SQL Server nunca vê a versão não criptografada dos dados.

No momento, os únicos drivers habilitados para Always Encrypted são o .NET Framework Data Provider para SQL Server, que requer a instalação do .NET Framework versão 4.6 no computador cliente e o driver JDBC 6.0. Isso provavelmente mudará com o tempo, mas esses são os requisitos oficiais do Always Encrypted em abril de 2017.

Mas por que precisamos dessa tecnologia? Existem algumas boas razões pelas quais Always Encrypted deve ser usado:

• Segurança — Os dados sempre precisavam estar seguros. Agora que o SSL está sendo comprometido, o Always Encrypted preenche a lacuna com outra camada de proteção de pipeline de transporte.
• Suporte regulatório — Os dados precisam ser criptografados e protegidos de olhares indiscretos do DBA por mais e mais regulamentações do setor, principalmente nos setores financeiro e de telecomunicações. Isso é descrito no padrão PII (“Informações de identificação pessoal”), que afirma que coisas como números de cartão de crédito, números de previdência social, nomes e endereços devem ser protegidos, ou o proprietário dos dados pode ser severamente penalizado.

Como usar o Always Encrypted

O uso do Always Encrypted requer uma pequena preparação no servidor de banco de dados que armazena as tabelas criptografadas. A preparação é um processo de duas etapas:

• Criar a definição de chave mestra de coluna
• Criar a chave de criptografia da coluna

Chave mestra de coluna

Então, o que é uma chave mestra de coluna?

A chave mestra da coluna é um certificado armazenado em um repositório de certificados do Windows (que é usado na demonstração como uma opção de armazenamento de certificados), um módulo de segurança de hardware de terceiros (um nome genérico para soluções de terceiros para instalação, gerenciamento e uso certificados ) ou o Azure Key Vault (solução baseada em nuvem da Microsoft para gerenciamento de certificados).

O aplicativo que está criptografando os dados usa a chave mestra de coluna para proteger várias chaves de criptografia de coluna que tratam da criptografia de dados nas colunas de uma tabela de banco de dados. O uso de repositórios de certificados do SQL Server, que às vezes são chamados de Enterprise Key Manager , requer o uso do SQL Server Enterprise Edition.

Neste artigo, descrevemos o uso de um certificado autoassinado que você armazena no Microsoft Certificate Store do sistema operacional Windows. Embora essa abordagem não seja a configuração ideal, ela demonstra o conceito de Always Encrypted, mas também precisa ser declarado que essa abordagem não é aceitável para ambientes de produção , onde o gerenciamento de certificados deve ser feito com contas de usuário separadas e seguras e, de preferência, , em servidores separados.

Você pode criar uma definição de chave mestra de coluna usando a interface gráfica no SQL Server Management Studio (SSMS) ou usando T-SQL. No SSMS, conecte-se à instância de banco de dados do SQL Server 2016 na qual você deseja usar Always Encrypted para proteger uma tabela de banco de dados.

Criando e usando chaves mestras de coluna

No Pesquisador de Objetos, navegue primeiro para o banco de dados, depois para Segurança e expanda a pasta Always Encrypted Keys para exibir suas duas subpastas, conforme mostrado nas figuras a seguir:

Para criar a chave mestra de coluna, clique com o botão direito do mouse na pasta Column Master Keys e selecione New Column Master Key . Na caixa de diálogo New Column Master Key , digite um nome para a chave mestra de coluna, especifique se deseja armazenar a chave no repositório de certificados do usuário atual ou do computador local ou no Azure Key Vault e selecione um certificado na lista. Se não houver certificados ou se você quiser usar um novo certificado autoassinado, clique no botão Generate Certificate e clique em OK . Esta etapa cria um certificado autoassinado e o carrega no repositório de certificados da conta de usuário atual que executa o SSMS.

Observação: você deve executar essas etapas em uma máquina confiável, mas não no computador que hospeda sua instância do SQL Server. Dessa forma, os dados permanecem protegidos no SQL Server, mesmo que o computador host seja comprometido.

Assim, após criar o certificado e configurá-lo como chave mestra de coluna, você deve exportá-lo e distribuí-lo para todos os computadores que hospedam clientes que precisam acessar os dados. Se um aplicativo cliente for baseado na web, você deverá carregar o certificado no servidor web. Se for um aplicativo instalado nos computadores dos usuários, você deverá implantar o certificado no computador de cada usuário individualmente.

Você pode encontrar instruções aplicáveis ​​para exportar e importar certificados para seu sistema operacional nos seguintes URLs:

• Exportando certificados
  • Windows 7 e Windows Server 2008 R2
  • Windows 8 e Windows Server 2012
  • Windows 8.1 e Windows Server 2012 R2
  • Windows 10 e Windows Server 2016
• Importando certificados
  • Windows 7 e Windows Server 2008 R2
  • Windows 8 e Windows Server 2012
  • Windows 8.1 e Windows Server 2012 R2
  • Windows 10 e Windows Server 2016

Ao importar certificados para o repositório de certificados em computadores com um aplicativo que criptografa e descriptografa os dados, você deve importar os certificados para o repositório de certificados da máquina ou para o repositório de certificados da conta de domínio que executa o aplicativo.

Chave de criptografia de coluna

Depois de criar uma chave mestra de coluna, você está pronto para criar chaves de criptografia para colunas específicas. O driver ADO.NET do SQL Server 2016 usa chaves de criptografia de coluna para criptografar os dados antes de enviá-los ao SQL Server e para descriptografar os dados após recuperá-los da instância do SQL Server 2016. Assim como a chave mestra de coluna, você pode criar chaves de criptografia de coluna usando T-SQL ou SSMS. Embora as chaves mestras de coluna sejam mais fáceis de criar usando o T-SQL, as chaves de criptografia de coluna são mais fáceis de criar usando o SSMS.

Para criar uma chave de criptografia de coluna, use o Pesquisador de Object Explorer para se conectar à instância do banco de dados, navegue até o banco de dados, depois em Security e expanda a pasta Always Encrypted Keys . Clique com o botão direito do mouse em Column Encryption Keys e selecione New Column Encryption Key . Na caixa de diálogo New Column Encryption Key , digite um nome para a nova chave de criptografia, selecione uma Column Master Key Definition na lista suspensa e clique em OK . Agora você pode usar a chave de criptografia de coluna na definição de uma nova tabela.

Criando uma tabela com valores criptografados

Depois de criar a definição da chave mestra da coluna e as chaves de criptografia da coluna, você pode criar uma tabela para conter os valores criptografados.

Antes de fazer isso, você deve decidir que tipo de criptografia usar, quais colunas criptografar e se você pode indexar essas colunas. Com o recurso Always Encrypted , você define os tamanhos das colunas normalmente e o SQL Server ajusta o tamanho do armazenamento da coluna com base nas configurações de criptografia. Depois de criar sua tabela, talvez seja necessário alterar seu aplicativo para executar comandos nessa tabela usando Always Encrypted .

Tipos de criptografia do SQL Server 2016

Antes de criar uma tabela para conter valores criptografados, você deve decidir se cada coluna deve ou não ser criptografada.

Primeiro, essa coluna será usada para pesquisar valores ou apenas retornar esses valores?

Se a coluna for usada para pesquisas, a coluna deverá usar um tipo de criptografia determinística , que permite operações de igualdade. No entanto, há limitações na pesquisa de dados que foram criptografados usando o recurso Always Encrypted . O SQL Server 2016 oferece suporte apenas a operações de igualdade, que incluem joins equal to , not equal to , (que usam igualdade) e o valor na cláusula GROUP BY . Qualquer pesquisa usando LIKE não é suportada. Além disso, a classificação de dados criptografados usando Always Encrypted deve ser feita no nível do aplicativo, pois o SQL Server classificará com base no valor criptografado em vez do valor descriptografado.

Se a coluna não for usada para localizar registros, a coluna deverá usar o tipo de criptografia aleatória. Esse tipo de criptografia é mais seguro, mas não oferece suporte a pesquisas, associações ou operações de agrupamento.

Criando uma tabela com colunas criptografadas

Ao criar tabelas, você usa a sintaxe CREATE TABLE normal com alguns parâmetros adicionais na definição de coluna. Três parâmetros são usados ​​na sintaxe ENCRYPTED WITH para a instrução CREATE TABLE .

O primeiro deles é o parâmetro ENCRYPTION_TYPE , que aceita um valor RANDOMIZED ou DETERMINISTIC . O segundo é o parâmetro ALGORITHM , que aceita apenas um valor de RAEAD_AES_256_CBC_HMAC_SHA_256 . O terceiro parâmetro é o COLUMN_ENCRYPTION_KEY , que é a chave de criptografia que você usa para criptografar o valor.

 CREATE TABLE [dbo].[Customers] ( [CustomerId] [int] IDENTITY(1,1), [TaxId] [varchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL, [FirstName] [nvarchar](50) NULL, [LastName] [nvarchar](50) NULL, [MiddleName] [nvarchar](50) NULL, [Address1] [nvarchar](50) NULL, [Address2] [nvarchar](50) NULL, [Address3] [nvarchar](50) NULL, [City] [nvarchar](50) NULL, [PostalCode] [nvarchar](10) NULL, [State] [char](2) NULL, [BirthDate] [date] ENCRYPTED WITH (ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL PRIMARY KEY CLUSTERED ([CustomerId] ASC) ON [PRIMARY] ); GO

Indexação com Always Encrypted

As colunas que contêm dados criptografados podem ser usadas como colunas-chave nos índices, desde que essas colunas sejam criptografadas usando o tipo de criptografia DETERMINISTIC . As colunas criptografadas usando o tipo de criptografia RANDOMIZED retornam uma mensagem de erro quando você tenta criar um índice nessas colunas. As colunas criptografadas usando qualquer tipo de criptografia podem ser usadas como colunas INCLUDE em índices não clusterizados.

Como os valores criptografados podem ser índices, nenhuma medida adicional de ajuste de desempenho é necessária para valores criptografados com Always Encrypted além da indexação e ajuste que você normalmente executa. Largura de banda de rede adicional e maior E/S são os únicos efeitos colaterais que resultam do aumento do tamanho dos valores retornados.

Desempenho sempre criptografado

O desempenho é sempre um fator chave, especialmente neste caso, quando adicionamos sobrecarga de criptografia ao tráfego normal do banco de dados. O melhor site para testar o desempenho é o SQL Performance, que testou a execução de consultas e o uso do disco em vários cenários:

Como há trabalho de CPU e disco rígido que precisa ser executado com processos de criptografia e descriptografia, há um impacto óbvio na quantidade de espaço de armazenamento usado e na duração das consultas. Como isso é influenciado pelo seu ambiente—CPU, RAM e recursos de disco—você deve testar se isso apresentará um problema na produção.

Observação: caso você queira saber mais sobre a otimização de desempenho do Microsoft SQL Server, confira um de nossos artigos anteriores, Como ajustar o Microsoft SQL Server para desempenho.

Alterações no aplicativo

O que você precisa fazer para implementar corretamente o Always Encrypted no código herdado?

Uma das coisas boas sobre o recurso Always Encrypted do SQL Server 2016 é que os aplicativos que já usam procedimentos armazenados, ORMs ou comandos T-SQL parametrizados não devem exigir alterações no aplicativo para usar o Always Encrypted, a menos que operações de não igualdade já estejam sendo usadas. Os aplicativos que criam instruções SQL como SQL dinâmico dentro do aplicativo e executam esses comandos diretamente no banco de dados precisam ser modificados para usar a parametrização de suas consultas, uma prática recomendada de segurança recomendada para todos os aplicativos, antes que possam aproveitar o recurso Always Encrypted.

Outra alteração necessária para que o Always Encrypted funcione é a adição de um atributo de cadeia de conexão à cadeia de conexão do aplicativo que se conecta ao banco de dados: Column Encryption Setting=enabled .

Com essa configuração adicionada à cadeia de conexão, o driver ADO.NET pergunta ao SQL Server se o comando em execução inclui colunas criptografadas e, em caso afirmativo, quais colunas são criptografadas. Para aplicativos de alta carga, o uso dessa configuração pode não ser a melhor prática, especialmente se uma grande porcentagem de comandos em execução não incluir valores criptografados.

Consequentemente, o .NET Framework fornece um novo método no objeto SqlConnection chamado SqlCommandColumnEncryptionSetting , que tem três valores possíveis:

• Disabled — Não há colunas ou parâmetros Always Encrypted a serem usados ​​para as consultas executadas usando este objeto de conexão.
• Enabled — Existem colunas e/ou parâmetros Always Encrypted em uso para as consultas executadas usando este objeto de conexão.
• ResultSet — Não há parâmetros Always Encrypted. No entanto, a execução de consultas usando esse objeto de conexão retorna colunas criptografadas usando Always Encrypted.

Observação: Esteja ciente de que o uso desse método pode exigir uma quantidade significativa de alterações no código do aplicativo. Uma abordagem alternativa é refatorar seu aplicativo para usar conexões diferentes.

Para obter o melhor desempenho do SQL Server, é aconselhável solicitar apenas os metadados sobre Always Encrypted para as consultas que usam Always Encrypted. Isso significa que em aplicativos para os quais uma grande porcentagem de consultas usa Always Encrypted, a cadeia de conexão deve ser habilitada e as consultas específicas no aplicativo devem especificar SqlCommandColumnEncryptionSetting como Disabled . Para aplicativos para os quais a maioria das consultas não usa valores Always Encrypted, a cadeia de conexão não deve ser habilitada e SqlCommandColumnEncryptionSetting deve ser definido como Enabled ou ResultSet conforme necessário para as consultas que usam colunas Always Encrypted. Na maioria dos casos, os aplicativos podem simplesmente habilitar o atributo de cadeia de conexão e o desempenho do aplicativo permanecerá inalterado ao usar os dados criptografados.

Sempre criptografado vale o esforço?

Resposta curta? Sim definitivamente!

Isso não apenas ajuda a evitar muitas preocupações potenciais de segurança e fornece aos desenvolvedores de SQL recursos de segurança adicionais, mas também torna seu sistema mais compatível, o que é vital em vários setores, de telecomunicações a bancos e seguros. Também é importante observar que, de acordo com os pré-requisitos técnicos mencionados no artigo, o Always Encrypted pode ser implementado com alterações mínimas de aplicativos nos sistemas existentes .

Embora você possa usar soluções personalizadas para obter o mesmo efeito, essa tecnologia é fornecida com a nova versão do SQL Server e pode ser usada pronta para uso. Também é importante notar que, como esta é uma tecnologia nova, ainda existem algumas limitações em seu uso, e adiciona algumas demenads extras de hardware.

No entanto, a menos que eles sejam um fator decisivo para o seu ambiente e você tenha um aplicativo distribuído fora da Intranet da sua empresa, praticamente não há motivo para não usar o Always Encrypted.