Always Encrypted com enclaves seguros

  • Artigo

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores – Somente Windows Banco de Dados SQL do Azure

O Always Encrypted com enclaves seguros expande as funcionalidades de computação confidencial do Always Encrypted habilitando a criptografia in-loco e as consultas confidenciais mais avançadas. O Always Encrypted com enclaves seguros está disponível no SQL Server 2019 (15.x) e posteriores, bem como no Banco de Dados SQL do Azure.

Introduzido no Banco de Dados SQL do Azure em 2015 e no SQL Server 2016 (13.x), o recurso Always Encrypted protege a confidencialidade de dados confidenciais contra malware e usuários não autorizados com altos privilégios. Esses usuários abrangem Administradores de Banco de Dados (DBAs), administradores de computador, administradores de nuvem ou qualquer pessoa que tenha acesso legítimo para as instâncias de servidor, para o hardware etc., mas não deveria ter acesso a alguns ou a todos os dados reais.

Sem os aprimoramentos discutidos neste artigo, o Always Encrypted protege os dados criptografando-os no lado do cliente e nunca permitindo que os dados ou as chaves de criptografia correspondentes sejam exibidos em texto não criptografado dentro do Mecanismo de Banco de Dados. Como resultado, a funcionalidade em colunas criptografadas dentro do banco de dados fica muito restrita. As únicas operações que o Mecanismo de Banco de Dados pode executar em dados criptografados são comparações de igualdade (disponíveis somente com a criptografia determinística). Não há suporte para todas as outras operações, incluindo operações de criptografia (criptografia de dados inicial ou rotação de chave) e consultas mais avançadas (por exemplo, padrões correspondentes) no banco de dados. Os usuários precisam mover os dados para fora do banco de dados para executar essas operações no lado do cliente.

O Always Encrypted com enclaves seguros soluciona essas limitações, permitindo algumas computações em dados de texto não criptografado em um enclave seguro no lado do servidor. Um enclave seguro é uma região protegida da memória dentro do processo do Mecanismo de Banco de Dados. O enclave seguro é exibido como uma caixa opaca para o restante do Mecanismo de Banco de Dados e os outros processos no computador de hospedagem. Não há nenhuma maneira de exibir os dados ou o código dentro do enclave de fora, mesmo com um depurador. Essas propriedades tornam o enclave seguro um ambiente de execução confiável que pode acessar com segurança chaves de criptografia e dados confidenciais em texto não criptografado, sem comprometer a confidencialidade dos dados.

O Always Encrypted usa enclaves seguros, conforme ilustrado no diagrama a seguir:

Um diagrama do Fluxo de dados para o Always Encrypted.

Ao analisar uma instrução Transact-SQL enviada por um aplicativo, o Mecanismo de Banco de Dados determina se a instrução contém qualquer operação em dados criptografados que exigem o uso do enclave seguro. Para essas instruções:

  • O driver de cliente envia as chaves de criptografia de coluna necessárias para as operações ao enclave seguro (por um canal seguro) e envia a instrução para execução.

  • Ao processar a instrução, o Mecanismo de Banco de Dados delega operações de criptografia ou computações em colunas criptografadas ao enclave seguro. Se necessário, o enclave descriptografa os dados e executa computações em texto não criptografado.

Durante o processamento da instrução, as chaves de criptografia de coluna e os dados não são expostos em texto não criptografado no Mecanismo de Banco de Dados fora do enclave seguro.

Drivers de cliente compatíveis

Para usar o Always Encrypted com enclaves seguros, um aplicativo precisa usar um driver de cliente compatível com esse recurso. Configure o aplicativo e o driver de cliente para habilitar computações de enclave e o atestado de enclave (consulte a seção Proteger atestado de enclave abaixo). Para obter detalhes, incluindo a lista de drivers de cliente compatíveis, confira Desenvolver aplicativos usando o Always Encrypted.

Tecnologias de enclave compatíveis

Always Encrypted dá suporte para as seguintes tecnologias de enclave (ou tipos de enclave):

O tipo de enclave disponível para seu banco de dados depende do produto SQL que o hospeda (Banco de Dados SQL do Azure vs. SQL Server) e, no caso do Banco de Dados SQL do Azure, da configuração do banco de dados.

  • No SQL Server 2019 (15.x) e posteriores, o Always Encrypted oferece suporte a enclaves SBV. (Não há suporte para enclaves Intel SGX.)

  • No Banco de Dados SQL do Azure, um banco de dados pode usar um enclave Intel SGX ou um enclave de SBV, dependendo do hardware em que o banco de dados está configurado para ser executado:

    • Bancos de dados que usam a configuração de hardware da série DC (disponível com o modelo de compra vCore) usam enclaves Intel SGX.
    • Os bancos de dados que usam uma configuração diferente da série DC com o modelo de compra vCore e os bancos de dados que usam o modelo de compra DTU podem ser configurados para usar enclaves de SBV.

    Observação

    Os enclaves SBV estão disponíveis no momento em todas as regiões do Banco de Dados SQL do Azure, exceto: Jio India Central.

Confira a seção Considerações de segurança para obter informações importantes sobre o nível de proteção fornecido por cada tipo de enclave.

Atestado de enclave seguro

O atestado de enclave é um mecanismo de defesa profunda que pode ajudar a detectar ataques que envolvam adulteração do código do enclave ou de seu ambiente por administradores mal-intencionados.

O atestado de enclave permite que um aplicativo cliente estabeleça confiança com o enclave seguro para o banco de dados ao qual o aplicativo está conectado antes que o aplicativo use o enclave para processar dados confidenciais. O fluxo de trabalho de atestado verifica se o enclave é um enclave SBV original ou Intel SGX genuíno e o código em execução dentro dele é a biblioteca de enclave assinada pela Microsoft original para Always Encrypted. Durante a atestação, o driver do cliente no aplicativo e o Mecanismo de Banco de Dados se comunicam com um serviço de atestado externo usando um ponto de extremidade especificado pelo cliente.

O Always Encrypted pode usar um dos dois serviços de atestado:

Para habilitar o Always Encrypted com enclaves seguros para seu aplicativo, defina um protocolo de atestado na configuração do driver cliente em seu aplicativo. Um valor de protocolo de atestado determina se 1) o aplicativo cliente usará atestado e, em caso positivo, 2) especifica o tipo de serviço de atestado que ele usará. A seguinte tabela captura os protocolos de atestado com suporte para as combinações válidas de produto SQL e tipo de enclave:

Produto de hosting Tipo de enclave Protocolos de atestado com suporte
SQL Server 2019 (15.x) e posterior Enclaves SBV HGS, sem atestado
Banco de Dados SQL do Azure Enclaves SGX (bancos de dados da série DC) Atestado do Microsoft Azure
Banco de Dados SQL do Azure Enclaves SBV Sem atestado

Alguns pontos importantes a destacar:

  • Atestar enclaves de SBV no SQL Server 2019 (15.x) e posterior requer HGS. Você também pode usar enclaves de SBV sem atestado (os drivers de cliente mais recentes são necessários).
  • Com enclaves Intel SGX (nos banco de dados da série DC) no Banco de Dados SQL do Azure, o atestado é obrigatório e requer o Atestado do Microsoft Azure.
  • Os enclaves SBV no Banco de Dados SQL do Azure atualmente não dão suporte a atestado.

Para saber mais, veja:

Terminologia

Chaves habilitadas para enclave

O Always Encrypted com enclaves seguros apresenta o conceito de chaves habilitadas para enclave:

  • Chave mestra de coluna habilitada para enclave: uma chave master de coluna que tem a propriedade ENCLAVE_COMPUTATIONS especificada no objeto de metadados da chave master de coluna dentro do banco de dados. O objeto de metadados da chave master de coluna também deve conter uma assinatura válida das propriedades de metadados. Para obter mais informações, confira CREATE COLUMN MASTER KEY (Transact-SQL)
  • Chave de criptografia de coluna habilitada para enclave: uma chave de criptografia de coluna que é criptografada com uma chave master de coluna habilitada para enclave. Somente as chaves de criptografia de coluna habilitadas para enclave podem ser usadas para computações dentro do enclave seguro.

Para obter mais informações, confira Gerenciar chaves para Always Encrypted com enclaves seguros.

Colunas habilitadas para enclave

Uma coluna habilitada para enclave é uma coluna de banco de dados criptografada com uma chave de criptografia de coluna habilitada para enclave.

Funcionalidades de computação confidencial para colunas habilitadas para enclave

Os dois principais benefícios do Always Encrypted com enclaves seguros são a criptografia in-loco e as consultas confidenciais avançadas.

Criptografia in-loco

A criptografia in-loco permite operações de criptografia em colunas de banco de dados dentro do enclave seguro, sem mover os dados para fora do banco de dados. Ela aprimora o desempenho e a confiabilidade das operações de criptografia. Execute a criptografia in-loco usando a instrução ALTER TABLE (Transact-SQL).

As operações de criptografia compatíveis in-loco são:

  • Criptografia de uma coluna de texto não criptografado com uma chave de criptografia de coluna habilitada para enclave.
  • Nova criptografia de uma coluna criptografada habilitada para enclave para:
    • Girar uma chave de criptografia de coluna: criptografar novamente a coluna com uma nova chave de criptografia de coluna habilitada para enclave.
    • Alterar o tipo de criptografia de uma coluna habilitada para enclave, por exemplo, de determinística para aleatória.
  • Descriptografar dados armazenados em uma coluna habilitada para enclave (converter a coluna em uma coluna de texto não criptografado).

A criptografia in-loco é permitida com a criptografia determinística e aleatória, desde que as chaves de criptografia de coluna envolvidas em uma operação de criptografia sejam habilitadas para enclave.

Consultas confidenciais

Observação

O SQL Server 2022 (16.x) adiciona suporte para consultas confidenciais com as operações JOIN, GROUP BY e ORDER BY nas colunas criptografadas.

Consultas confidenciais são consultas DML que envolvem operações em colunas habilitadas para enclave executadas dentro do enclave seguro.

As operações compatíveis com os enclaves seguros são:

Operação Banco de Dados SQL do Azure SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Operadores de comparação Com suporte Compatível Com suporte
BETWEEN (Transact-SQL) Com suporte Compatível Com suporte
IN (Transact-SQL) Com suporte Compatível Com suporte
LIKE (Transact-SQL) Com suporte Compatível Com suporte
DISTINCT Com suporte Compatível Com suporte
Junções Com suporte Com suporte Só há suporte para junções de loop aninhadas
SELECT – Cláusula ORDER BY (Transact-SQL) Com suporte Compatível Sem suporte
SELECT – GROUP BY – Transact-SQL Com suporte Compatível Sem suporte

Observação

As operações acima dentro de enclaves seguros exigem criptografia randomizada. Não há suporte para a criptografia determinística. A comparação de igualdade continua sendo a operação disponível para colunas que usam criptografia determinística.

O nível de compatibilidade do banco de dados deve ser definido para o SQL Server 2022 (160) ou superior.

No Banco de Dados SQL do Azure e no SQL Server 2022 (16.x), as consultas confidenciais que usam enclaves em uma coluna de cadeia de caracteres (char, nchar) exigem que a coluna use uma ordenação UTF-8 ou uma ordenação _BIN2 (ponto de código binário). No SQL Server 2019 (15.x), o agrupamento a_BIN2 é necessário.

Para obter mais informações, confira Executar instruções Transact-SQL usando enclaves seguros.

Índices em colunas habilitadas para enclave

Você pode criar índices não clusterizados em colunas habilitadas para enclave que usam a criptografia aleatória para fazer consultas DML confidenciais com o enclave seguro executado mais rapidamente.

Para garantir que não haja vazamento de dados confidenciais de um índice em uma coluna criptografada que usa a criptografia aleatória, os valores de chave na estrutura de dados do índice (árvore B) são criptografados e classificados com base nos respectivos valores de texto não criptografado. A classificação pelo valor de texto não criptografado também é útil para o processamento de consultas dentro do enclave. Quando o executor de consultas usa um índice em uma coluna criptografada para cálculos dentro do enclave no Mecanismo de Banco de Dados, ele pesquisa o índice para localizar valores específicos armazenados na coluna. Cada pesquisa pode envolver várias comparações. O executor de consultas delega cada comparação ao enclave que descriptografa um valor armazenado na coluna e o valor da chave criptografada do índice a ser comparado, realiza a comparação em texto não criptografado e retorna o resultado da comparação ao executor.

Ainda não há suporte para criação de índices em colunas que usam criptografia aleatória e que não são habilitadas para enclave.

Um índice em uma coluna que usa a criptografia determinística é classificado com base no texto cifrado (não no texto não criptografado), independentemente de a coluna estar habilitada para enclave.

Para obter mais informações, confira Criar e usar índices em colunas usando o Always Encrypted com enclaves seguros. Para obter informações gerais sobre como funciona a indexação no Mecanismo de Banco de Dados, confira o artigo Descrição de índices clusterizados e não clusterizados.

Recuperação de banco de dados

Quando uma instância do SQL Server falha, os respectivos bancos de dados podem ficar em um estado em que os arquivos de dados podem conter algumas modificações de transações incompletas. Quando a instância é iniciada, ela executa um processo chamado recuperação de banco de dados, que envolve a reversão de todas as transações incompletas encontradas no log de transações para garantir que a integridade do banco de dados seja preservada. Caso uma transação incompleta tenha feito alterações em um índice, essas alterações também precisam ser desfeitas. Por exemplo, talvez seja necessário remover ou reinserir alguns valores de chave no índice.

Importante

A Microsoft recomenda habilitar a ADR (Recuperação de Banco de dados Acelerada) no banco de dados, antes de criar o primeiro índice em uma coluna habilitada para enclave com criptografia aleatória. A ADR está habilitada por padrão no Banco de Dados SQL do Azure, mas não no SQL Server 2019 (15.x) e posteriores.

Para desfazer uma alteração feita em um índice com o processo de recuperação de banco de dados tradicional (que segue o modelo de recuperação ARIES), o SQL Server precisa aguardar até que um aplicativo forneça a chave de criptografia da coluna para o enclave, o que pode levar muito tempo. A ADR (Recuperação Acelerada de Banco de Dados) reduz significativamente a quantidade de operações de desfazer que precisam ser adiadas devido a uma chave de criptografia de coluna não estar disponível no cache dentro do enclave. Consequentemente, esse recurso aumenta consideravelmente a disponibilidade do banco de dados, reduzindo a chance de uma nova transação ser bloqueada. Com a ADR habilitada, o SQL Server ainda pode precisar de uma chave de criptografia de coluna para concluir a limpeza de versões de dados anteriores, mas ele realiza esse processo como uma tarefa em segundo plano que não afeta a disponibilidade do banco de dados ou as transações do usuário. Talvez você receba mensagens de erro no log de erros, indicando falhas nas operações de limpeza devido à ausência de uma chave de criptografia da coluna.

Considerações de segurança

As considerações a seguir sobre segurança se aplicam ao Always Encrypted com enclaves seguros.

  • Os enclaves de SBV ajudam a proteger seus dados contra ataques dentro da VM. Porém, eles não fornecem proteção contra ataques que usam contas de sistema privilegiadas originadas do host. Os enclaves Intel SGX protegem os dados contra ataques originados do SO convidado e do SO de host.
  • O uso do atestado de enclave será recomendado se ele estiver disponível para seu ambiente e se você estiver preocupado em proteger seus dados contra ataques de usuários com o acesso de administrador no nível do sistema operacional ao computador que hospeda seu banco de dados. Se você usar atestado, precisará garantir que um administrador confiável gerencie o serviço de atestado e sua configuração. Além disso, ambos os serviços de atestado com suporte oferecem políticas e modos de atestado diferentes, alguns dos quais realizam uma verificação mínima do enclave e do respectivo ambiente, e são projetados para fins de testes e desenvolvimento. Siga rigorosamente as diretrizes específicas do serviço de atestado para garantir que você esteja usando as configurações e políticas recomendadas para suas implantações de produção.
  • Criptografar uma coluna que usa a criptografia aleatória com uma chave de criptografia de coluna habilitada para enclave pode resultar no vazamento da ordem dos dados armazenados na coluna, pois essas colunas dão suporte a comparações de intervalos. Por exemplo, se uma coluna criptografada contendo salários de funcionários tiver um índice, um administrador de banco de dados mal-intencionado poderá verificar o índice para encontrar o maior valor de salário criptografado e identificar uma pessoa que recebe esse salário (supondo que o nome dela não esteja criptografado).
  • Se você usar o Always Encrypted para proteger dados confidenciais contra o acesso não autorizado por DBAs, não compartilhe as chaves master de coluna ou as chaves de criptografia de coluna com os DBAs. Um DBA pode gerenciar índices em colunas criptografadas sem ter acesso direto às chaves usando o cache de chaves de criptografia da coluna dentro do enclave.

Considerações sobre continuidade dos negócios, recuperação de desastre e migração de dados

Ao configurar uma solução de alta disponibilidade ou de recuperação de desastre para um banco de dados usando o Always Encrypted com enclaves seguros, verifique se todas as réplicas de banco de dados podem usar um enclave seguro. Se um enclave estiver disponível para a réplica primária, mas não para a réplica secundária, qualquer instrução que tentar usar a funcionalidade do Always Encrypted com enclaves seguros falhará após o failover.

Ao copiar ou migrar um banco de dados usando o Always Encrypted com enclaves seguros, verifique se o ambiente de destino sempre dá suporte a enclaves. Caso contrário, as instruções que usam enclaves não funcionarão no banco de dados migrado ou de cópia.

Estas são as considerações específicas que você deve ter em mente:

  • SQL Server

    • Ao configurar um grupo de disponibilidade do Always On, verifique se todas as instâncias do SQL Server que hospedam um banco de dados no grupo de disponibilidade dão suporte ao Always Encrypted com enclaves seguros e têm um enclave e um atestado configurados.
    • Quando você restaurar um arquivo de backup de um banco de dados que usa a funcionalidade do Always Encrypted com enclaves seguros em uma instância do SQL Server que não tem o enclave configurado, a operação de restauração será bem-sucedida e todas as funcionalidades que não dependem do enclave ficarão disponíveis. No entanto, todas as instruções seguintes que usarem a funcionalidade de enclave falharão, e os índices nas colunas habilitadas para enclave que usam a criptografia aleatória ficarão inválidos. O mesmo se aplica quando você anexa um banco de dados usando o Always Encrypted com enclaves seguros na instância que não têm o enclave configurado.
    • Caso seu banco de dados contenha índices em colunas habilitadas para enclave que usam a criptografia aleatória, habilite a ADR (Recuperação Acelerada de Banco de Dados) no banco de dados antes de criar um backup de banco de dados. A ADR garantirá que o banco de dados, inclusive os índices, fique disponível imediatamente após a restauração. Para saber mais, confira Recuperação de banco de dados.

  • Banco de Dados SQL do Azure

    • Ao configurar a replicação geográfica ativa, verifique se um banco de dados secundário dá suporte a enclaves seguros, caso o banco de dados primário dê suporte a eles.

No SQL Server e no Banco de Dados SQL do Azure, ao migrar seu banco de dados usando um arquivo BACPAC, remova todos os índices de colunas habilitadas para enclave que usam a criptografia aleatória antes de criar o arquivo BACPAC.

Limitações conhecidas

O Always Encrypted com enclaves seguros soluciona algumas limitações do Always Encrypted dando suporte à criptografia in-loco e a consultas confidenciais mais avançadas com índices, conforme explicado em Funcionalidades de computação confidencial para colunas habilitadas para enclave.

Todas as outras limitações do Always Encrypted listadas em Limitações também se aplicam ao Always Encrypted com enclaves seguros.

As seguintes limitações são específicas do Always Encrypted com enclaves seguros:

  • Não é possível criar índices clusterizados em colunas habilitadas para enclave com criptografia aleatória.
  • Colunas habilitadas para enclave com criptografia aleatória não podem ser colunas de chave primária e não podem ser referenciadas por restrições de chaves estrangeiras nem por restrições de chaves exclusivas.
  • No SQL Server 2019 (15.x) (esta limitação não se aplica ao Banco de Dados SQL do Azure nem ao SQL Server 2022 (16.x)), só há suporte para junções de loop aninhadas (com índices, se disponíveis) em colunas habilitadas para enclave que usam a criptografia aleatória. Para obter informações sobre outras diferenças entre produtos, confira Consultas confidenciais.
  • Operações criptográficas no local não podem ser combinadas com outras alterações de metadados de coluna, exceto as alterações de ordenação, na mesma página de código e nulidade. Por exemplo, não é possível criptografar, recriptografar ou descriptografar uma coluna E alterar um tipo de dados da coluna em uma única instrução ALTER TABLE/ALTER COLUMN do Transact-SQL. É necessário usar duas instruções separadas.
  • Não há suporte para o uso de chaves habilitadas para enclave para colunas em tabelas na memória.
  • As expressões que definem colunas computadas não podem executar computações em colunas habilitadas para enclave que usam a criptografia aleatória (mesmo que as computações estejam entre as operações compatíveis listadas em Consultas confidenciais).
  • Não há suporte para caracteres de escape em parâmetros do operador LIKE em colunas habilitadas para enclave usando criptografia aleatória.
  • Consultas com o operador LIKE ou um operador de comparação que inclui um parâmetro de consulta com um dos seguintes tipos de dados (que se tornam objetos grandes após a criptografia) ignoram índices e executam verificações de tabela.
    • nchar[n] e nvarchar[n], se n for maior que 3967.
    • char[n], varchar[n], binary[n], varbinary[n], se n for maior que 7935.
  • Limitações de conjunto de ferramentas:
    • Os únicos repositórios de chaves com suporte para o armazenamento de chaves master de coluna habilitadas para enclave são o Repositório de Certificados do Windows e o Azure Key Vault.
    • Para disparar uma operação criptográfica no local por meio de uma instrução ALTER TABLE/ALTER COLUMN, é necessário emitir a instrução usando uma janela de consulta no SSMS ou no Azure Data Studio, você pode escrever seu próprio programa que emite a instrução. Atualmente, o cmdlet Set-SqlColumnEncryption no módulo PowerShell do SqlServer e o assistente Always Encrypted no SQL Server Management Studio não dão suporte à criptografia no local. Mova os dados para fora do banco de dados para operações criptográficas, mesmo que as chaves de criptografia de coluna usadas para as operações sejam habilitadas para enclave.
  • Quando você restaura um banco de dados habilitado para enclave VBS, é essencial reconfigurar a configuração do enclave VBS novamente.

Conteúdo relacionado