Database
 sql >> Base de Dados >  >> RDS >> Database

Criptografia de dados transparente e sempre criptografada


Se você precisar armazenar dados confidenciais em seu banco de dados, poderá usar a criptografia de dados . O SQL Server oferece suporte à criptografia com chaves simétricas, chaves assimétricas, certificados e frases de senha. Presumo que você, leitor, já esteja familiarizado com esses termos. Neste artigo, focarei em duas das muitas opções de criptografia fornecidas pelo SQL Server:
  • Criptografia de dados transparente (TDE)
  • Sempre criptografado (AE)


Criptografia de dados transparente


A Criptografia de Dados Transparente (TDE) protege os dados em repouso quando não são usados. Quando os dados são usados, o SQL Server os descriptografa automaticamente. Você pode usar o TDE para criptografia e descriptografia em tempo real dos dados e arquivos de log. Você criptografa os dados com a chave de criptografia do banco de dados (DEK) , que é uma chave simétrica. Ele é armazenado no registro de inicialização do banco de dados e, portanto, já está disponível durante o processo de recuperação do banco de dados. Você protege o DEK com um certificado no banco de dados mestre. Você também pode usar uma chave assimétrica em vez do certificado; no entanto, a chave assimétrica deve ser armazenada em um módulo EKM. A TDE usa apenas as criptografias AES e Triple DES. O TDE foi implementado pela primeira vez no SQL Server com a versão 2012.

Você pode usar TDE apenas em bancos de dados de usuários. Você não pode exportar a chave de criptografia do banco de dados. Essa chave é usada apenas pelo Mecanismo de Banco de Dados do SQL Server. Os usuários finais nunca o usam. Mesmo se você alterar o proprietário do banco de dados, não será necessário gerar novamente o DEK.

TDE criptografa dados no nível da página. Além disso, criptografa também o log de transações. Você deve fazer backup do certificado usado para proteger o DEK e da chave privada usada para proteger o certificado imediatamente após habilitar o TDE. Se você precisar restaurar ou anexar o banco de dados criptografado a outra instância do SQL Server, precisará restaurar o certificado e a chave privada ou não poderá abrir o banco de dados. Observe novamente que você não exporta a DEK, pois ela faz parte do próprio banco de dados. Você precisa manter e manter o certificado usado para proteger o DEK mesmo depois de desabilitar o TDE no banco de dados. Isso ocorre porque partes do log de transações ainda podem ser criptografadas. O certificado é necessário até que você execute o backup completo do banco de dados.

Sempre criptografado


O SQL Server 2016 Enterprise Edition apresenta um novo nível de criptografia, a saber, o Always Encrypted (AE) característica. Esse recurso permite o mesmo nível de proteção de dados que a criptografia dos dados no aplicativo cliente. Na verdade, embora este seja um recurso do SQL Server, os dados são criptografados e descriptografados no lado do cliente. As chaves de criptografia nunca são reveladas ao Mecanismo de Banco de Dados do SQL Server. Dessa forma, também um DBA não pode ver dados confidenciais sem as chaves de criptografia, apenas por ter permissões de sysadmin na instância do SQL Server com os dados criptografados. Dessa forma, o AE faz uma separação entre os administradores que gerenciam os dados e os usuários que possuem os dados.

Teclas AE


Você precisa de duas chaves para Always Encrypted. Primeiro, você cria a chave mestra de coluna (CMK) . Em seguida, você cria a chave de criptografia de coluna (CEK) e proteja-o com a CMK. Um aplicativo usa o CEK para criptografar os dados. O SQL Server armazena apenas dados criptografados e não pode descriptografá-los. Isso é possível porque as chaves mestras de coluna não são realmente armazenadas em um banco de dados SQL Server. No banco de dados, o SQL Server armazena apenas o link para essas chaves. As chaves mestras de coluna são armazenadas fora do SQL Server, em um dos seguintes locais possíveis:
  • Repositório de certificados do Windows para o usuário atual
  • Repositório de certificados do Windows para a máquina local
  • Serviço do Azure Key Vault
  • Um módulo de segurança de hardware (HSM) , que suporta Microsoft CryptoAPI ou API de criptografia:próxima geração

As chaves de criptografia de coluna são armazenadas no banco de dados. Dentro de um banco de dados SQL Server, apenas a parte criptografada dos valores das chaves de criptografia de coluna é armazenada, juntamente com as informações sobre a localização das chaves mestras de coluna. As CEKs nunca são armazenadas como texto simples em um banco de dados. As CMKs são, conforme mencionado, realmente armazenadas em repositórios de chaves confiáveis ​​externas.

Usando as teclas AE


Um aplicativo pode usar as chaves AE e criptografia usando um driver habilitado para AE, como .NET Framework Data Provider para SQL Server versão 4.6 ou superior, Microsoft JDBC Driver para SQL Server 6.0 ou superior ou driver ODBC do Windows para SQL Server versão 13.1 ou superior. O aplicativo deve enviar consultas parametrizadas ao SQL Server. O driver habilitado para AE funciona em conjunto com o SQL Server Database Engine para determinar quais parâmetros devem ser criptografados ou descriptografados. Para cada parâmetro que precisa ser criptografado ou descriptografado, o driver obtém os metadados necessários para a criptografia do Mecanismo de Banco de Dados, incluindo o algoritmo de criptografia, o local da CMK correspondente e o valor criptografado da CEK correspondente. Em seguida, o driver entra em contato com o repositório da CMK, recupera a CMK, descriptografa a CEK e usa a CEK para criptografar ou descriptografar o parâmetro. Em seguida, o driver armazena em cache o CEK, para acelerar o próximo uso do mesmo CEK. A figura a seguir mostra o processo graficamente.



A figura representa todo o processo em etapas:
  1. O aplicativo cliente cria uma consulta parametrizada
  2. O aplicativo cliente envia a consulta parametrizada para o driver habilitado para AE
  3. O driver habilitado para AE entra em contato com o SQL Server para determinar quais parâmetros precisam de criptografia ou descriptografia, o local da CMK e o valor criptografado da CEK
  4. O driver habilitado para AE recupera a CMK e descriptografa a CEK
  5. O driver habilitado para AE criptografa os parâmetros
  6. O driver envia a consulta ao Mecanismo de Banco de Dados
  7. O Mecanismo de Banco de Dados recupera os dados e envia o conjunto de resultados ao driver
  8. O driver realiza a descriptografia, se necessário, e envia o conjunto de resultados para o aplicativo cliente

Tipos de criptografia AE


O Mecanismo de Banco de Dados nunca opera nos dados de texto simples armazenados nas colunas criptografadas. No entanto, algumas consultas nos dados criptografados são possíveis, dependendo do tipo de criptografia. Existem dois tipos de criptografia:
  • Criptografia determinística , que sempre gera o mesmo valor criptografado para o mesmo valor de entrada. Com essa criptografia, você pode indexar a coluna criptografada e usar pesquisas de ponto, junções de igualdade e expressões de agrupamento na coluna criptografada. No entanto, um usuário mal-intencionado pode tentar adivinhar os valores analisando os padrões dos valores criptografados. Isso é especialmente perigoso quando o conjunto de valores possíveis para uma coluna é discreto, com um pequeno número de valores distintos.
  • Criptografia aleatória , que criptografa dados de maneira imprevisível.

Demonstração do AE:Criando os objetos


É hora de mostrar como o AE funciona através de algum código de demonstração. Primeiro, vamos criar e usar um banco de dados de demonstração.
USE master;
IF DB_ID(N'AEDemo') IS NULL
   CREATE DATABASE AEDemo;
GO
USE AEDemo;
GO

Em seguida, crie a CMK na GUI do SSMS. No Pesquisador de Objetos, atualize a pasta Bancos de Dados para ver o banco de dados AEDemo. Expanda esta pasta de banco de dados, expanda a subpasta Security, depois a subpasta Always Encrypted Keys e clique com o botão direito do mouse na subpasta Column Master Key e selecione a opção New Column Master Key no menu pop-up. Na caixa de texto Nome, escreva AE_ColumnMasterKey e certifique-se de selecionar a opção Windows Certificate Store – Local Machine na lista suspensa Key Store, como mostra a figura a seguir.



Você pode verificar se a CMK foi criada com sucesso com a consulta a seguir.
SELECT * 
FROM sys.column_master_keys;

Em seguida, você cria o CEK. No SSMS, no Pesquisador de Objetos, clique com o botão direito do mouse na subpasta Chaves de Criptografia de Coluna logo abaixo da subpasta Chave Mestra de Coluna e selecione a opção Nova Chave de Criptografia de Coluna no menu pop-up. Nomeie a CEK como AE_ColumnEncryptionKey e use a CMK AE_ColumnMasterKey para criptografá-la. Você pode verificar se a criação do CEK foi bem-sucedida com a consulta a seguir.
SELECT * 
FROM sys.column_encryption_keys;

Atualmente, apenas os novos agrupamentos binários, os agrupamentos com o BIN2 sufixo, são suportados para AE. Portanto, vamos criar uma tabela com agrupamentos apropriados para as colunas de caracteres.
CREATE TABLE dbo.Table1
(id INT,
 SecretDeterministic NVARCHAR(10) COLLATE Latin1_General_BIN2 
  ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey,
   ENCRYPTION_TYPE = DETERMINISTIC,
   ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL,
 SecretRandomized NVARCHAR(10) COLLATE Latin1_General_BIN2
  ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey,
   ENCRYPTION_TYPE = RANDOMIZED,
   ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL
);

Demonstração do AE:inserindo os dados


Agora você pode tentar inserir uma linha de dados com a seguinte instrução.
INSERT INTO dbo.Table1
 (id, SecretDeterministic, SecretRandomized)
VALUES (1, N'DeterSec01', N'RandomSec1');

Você recebe o erro 206, texto do erro:“Operand type clash:nvarchar is incompatível com nvarchar(4000) criptografado com (encryption_type ='DETERMINISTIC', encryption_algorithm_name ='AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name ='AE_ColumnEncryptionDemo', column_encryption_key_database_name ='AE)” . O SQL Server não pode criptografar ou descriptografar os dados. Você precisa modificar os dados de um aplicativo cliente. Você pode fazer um conjunto limitado de operações na tabela do SQL Server. Por exemplo, você pode usar a instrução TRUNCATE TABLE em uma tabela com colunas AE.

Eu criei um aplicativo cliente Windows Console muito simples em Visual C#. Na verdade, o aplicativo apenas recupera as chaves e insere uma única linha na tabela criada com o código acima. Aqui está o código C#.
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace AEDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            string connectionString = "Data Source=localhost; “ +
              “Initial Catalog=AEDemo; Integrated Security=true; ” +
              “Column Encryption Setting=enabled";
            SqlConnection connection = new SqlConnection(connectionString);
            connection.Open();
            if (args.Length != 3)
            {
                Console.WriteLine("Please enter a numeric “ + 
                                  “and two string arguments.");
                return;
            }
            int id = Int32.Parse(args[0]);
            {
                using (SqlCommand cmd = connection.CreateCommand())
                {
                    cmd.CommandText = @"INSERT INTO dbo.Table1 “ +
                        “(id, SecretDeterministic, SecretRandomized)" +
                        " VALUES (@id, @SecretDeterministic, @SecretRandomized);";

                    SqlParameter paramid= cmd.CreateParameter();
                    paramid.ParameterName = @"@id";
                    paramid.DbType = DbType.Int32;
                    paramid.Direction = ParameterDirection.Input;
                    paramid.Value = id;
                    cmd.Parameters.Add(paramid);

                    SqlParameter paramSecretDeterministic = cmd.CreateParameter();
                    paramSecretDeterministic.ParameterName = 
                      @"@SecretDeterministic";
                    paramSecretDeterministic.DbType = DbType.String;
                    paramSecretDeterministic.Direction = ParameterDirection.Input;
                    paramSecretDeterministic.Value = "DeterSec1";
                    paramSecretDeterministic.Size = 10;
                    cmd.Parameters.Add(paramSecretDeterministic);

                    SqlParameter paramSecretRandomized = cmd.CreateParameter();
                    paramSecretRandomized.ParameterName =
                      @"@SecretRandomized";
                    paramSecretRandomized.DbType = DbType.String;
                    paramSecretRandomized.Direction = ParameterDirection.Input;
                    paramSecretRandomized.Value = "RandomSec1";
                    paramSecretRandomized.Size = 10;
                    cmd.Parameters.Add(paramSecretRandomized);

                    cmd.ExecuteNonQuery();
                }
            }
            connection.Close();
            Console.WriteLine("Row inserted successfully");            
        }
    }
}

Você pode executar o código C# do Visual Studio no modo de depuração ou compilar o aplicativo. Em seguida, você pode executar o aplicativo AEDemo.exe no prompt de comando ou no SSMS no modo SQMCMD.

Demonstração do AE:lendo os dados


Depois de executar o aplicativo, você deve tentar ler os dados da mesma sessão no SSMS que usou para criar a tabela.
SELECT *
FROM dbo.Table1;

Você pode ver apenas dados criptografados. Agora abra uma segunda janela de consulta no SSMS. Clique com o botão direito do mouse nesta janela e escolha Conexão e, em seguida, Alterar Conexão. Na caixa de diálogo Conexão, clique no botão Opções na parte inferior. Digite AEDemo para o nome do banco de dados e clique na guia Parâmetros de Conexão Adicionais. Na caixa de texto, digite “Column Encryption Setting=enabled” (sem aspas duplas). Em seguida, clique em Conectar.

Tente novamente inserir uma linha do SSMS. Use a seguinte consulta.
INSERT INTO dbo.Table1
 (id, SecretDeterministic, SecretRandomized)
VALUES (2, N'DeterSec2', N'RandomSec2');

Eu tenho um erro novamente. Esta versão do SSMS que estou usando ainda não pode parametrizar inserções ad-hoc. No entanto, vamos tentar ler os dados com a seguinte consulta.
SELECT * 
FROM dbo.Table1;

Desta vez, a consulta funciona e você obtém o seguinte resultado:

Id SecretDeterministic SecretRandomized

— ————————————-

1 DeterSec1 RandomSec1

2 DeterSec2 RandomSec2

Limitações de AE


Você já viu algumas limitações do Always Encrypted, incluindo:
  • Somente ordenações BIN2 são compatíveis com strings
  • Você pode indexar apenas colunas com criptografia determinística e usar um conjunto limitado de operações T-SQL nessas colunas
  • Você não pode indexar colunas com criptografia aleatória
  • AE é limitado apenas às edições Enterprise e Developer
  • Trabalhar com EA no SSMS pode ser doloroso

Consulte os Manuais Online para obter uma lista mais detalhada das limitações do AE. No entanto, observe também os pontos fortes do AE. É simples de implementar porque não necessita de modificações em uma aplicação, exceto a modificação de strings de conexão. Os dados são criptografados de ponta a ponta, da memória do cliente pela rede até o armazenamento do banco de dados. Mesmo os DBAs não podem visualizar os dados apenas no SQL Server; até mesmo os DBAs precisam de acesso ao armazenamento de chaves fora do SQL Server para ler a CMK. AE e outras opções de criptografia no SQL Server fornecem um conjunto completo de possibilidades, e cabe a você e ao problema de negócios que está resolvendo selecionar o método apropriado.

Conclusão


A Criptografia de Dados Transparente é extremamente simples de usar. No entanto, a proteção de dados é muito limitada. A TDE protege apenas os dados em repouso. No entanto, Always Encrypted é realmente um recurso poderoso. Ainda não é muito complexo de implementar e os dados estão completamente protegidos. Nem mesmo um DBA pode vê-lo sem ter acesso às chaves de criptografia. Esperamos que as limitações do AE, especialmente a limitação de agrupamento, sejam removidas nas versões futuras do SQL Server.