Partilhar via

Sempre criptografado com enclaves seguros

  • Artigo

Aplica-se a: SQL Server 2019 (15.x) e posterior - somente Windows Banco de Dados SQL do Azure

O Always Encrypted com enclaves seguros expande as capacidades de computação confidencial do Always Encrypted, permitindo criptografia no local e consultas mais detalhadas e confidenciais. O Always Encrypted with secure enclaves está disponível no SQL Server 2019 (15.x) e posterior, 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 Always Encrypted protege a confidencialidade de dados confidenciais contra malware e usuários de não autorizados altamente privilegiados: administradores de banco de dados (DBAs), administradores de computador, administradores de nuvem ou qualquer outra pessoa que tenha acesso legítimo a instâncias de servidor, hardware, etc., mas não deva 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 criptográficas correspondentes apareçam em texto sem formatação dentro do Mecanismo de Banco de Dados. Como resultado, a funcionalidade em colunas criptografadas dentro do banco de dados é severamente 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 apenas com criptografia determinística ). Todas as outras operações, incluindo operações criptográficas (criptografia de dados inicial ou rotação de chaves) e consultas mais avançadas (por exemplo, correspondência de padrões) não são suportadas dentro do banco de dados. Os usuários precisam mover seus dados para fora do banco de dados para executar essas operações no lado do cliente.

O Always Encrypted com enclaves seguros resolve essas limitações, permitindo alguns cálculos em dados de texto simples dentro de um enclave seguro no lado do servidor. Um enclave seguro é uma região protegida de memória dentro do processo do Mecanismo de Banco de Dados. O enclave seguro aparece como uma caixa opaca para o resto do Mecanismo de Banco de Dados e outros processos na máquina de hospedagem. Não há como visualizar nenhum dado ou código dentro do enclave a partir do exterior, mesmo com um depurador. Essas propriedades tornam o enclave seguro um ambiente de execução confiável que pode acessar com segurança chaves criptográficas e dados confidenciais em texto sem formatação, sem comprometer a confidencialidade dos dados.

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

Um diagrama do fluxo de dados para 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 quaisquer operações em dados criptografados que exijam o uso do enclave seguro. Para tais declarações:

  • O driver do cliente envia as chaves de criptografia de coluna necessárias para as operações para o enclave seguro (através de 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 criptográficas ou cálculos em colunas criptografadas ao enclave seguro. Se necessário, o enclave descriptografa os dados e executa cálculos em texto sem formatação.

Durante o processamento de instruções, nem os dados nem as chaves de criptografia de coluna são expostos em texto claro pelo Mecanismo de Banco de Dados fora do enclave seguro.

Drivers de cliente suportados

Para usar o Always Encrypted com enclaves seguros, um aplicativo deve usar um driver de cliente que ofereça suporte ao recurso. Configure o aplicativo e o driver do cliente para habilitar cálculos de enclave e atestado de enclave (consulte a seção Secure enclave attestation abaixo). Para obter detalhes, incluindo a lista de drivers de cliente suportados, consulte Desenvolver aplicativos usando o Always Encrypted.

Tecnologias de enclave suportadas

O Always Encrypted suporta 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 seu banco de dados.

  • No SQL Server 2019 (15.x) e posterior, o Always Encrypted oferece suporte a enclaves VBS. (Os enclaves SGX da Intel não são suportados.)

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

    • Os bancos de dados que utilizam a configuração de hardware da série DC (disponível com o modelo de compra vCore) utilizam 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 VBS.

    Observação

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

Consulte a seção Considerações de segurança para obter informações importantes sobre o nível de proteção que cada tipo de enclave oferece.

Certificação de enclave seguro

O atestado de enclave é um mecanismo de defesa profunda que pode ajudar a detetar 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 VBS ou Intel SGX genuíno e o código em execução dentro dele é a biblioteca de enclave genuína assinada pela Microsoft para Always Encrypted. Durante o atestado, o driver cliente dentro do 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, você precisa definir um protocolo de atestado na configuração do driver do cliente em seu aplicativo. Um valor de protocolo de atestado determina se 1) o aplicativo cliente usará o atestado e, em caso afirmativo, 2) especifica o tipo do serviço de atestado que ele usará. A tabela abaixo captura os protocolos de atestado suportados para o produto SQL válido e combinações de tipo de enclave:

Produto de hospedagem Tipo de enclave Protocolos de atestado suportados
SQL Server 2019 (15.x) e posterior Enclaves VBS HGS, Sem atestado
Banco de Dados SQL do Azure Enclaves SGX (bases de dados da série DC) Atestado do Microsoft Azure
Banco de Dados SQL do Azure VBS Enclaves Sem atestado

Alguns pontos importantes a destacar:

  • Atestar enclaves VBS no SQL Server 2019 (15.x) e versões posteriores requer HGS. Você pode também usar enclaves VBS sem atestado (são necessários os drivers de cliente mais recentes).
  • Com enclaves Intel SGX (em bancos 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 VBS no Banco de Dados SQL do Azure não oferecem suporte a atestado.

Para mais informações, consulte:

Terminologia

Chaves com suporte a enclave

Always Encrypted with secure enclaves introduz o conceito de chaves compatíveis com enclaves.

  • Chave mestra de coluna habilitada para Enclave - uma chave de coluna master que tem a propriedade ENCLAVE_COMPUTATIONS especificada no objeto de metadados de chave master dentro do banco de dados. A coluna master objeto de metadados de chave também deve conter uma assinatura válida das propriedades de metadados. Para obter mais informações, consulte CREATE COLUMN MASTER KEY (Transact-SQL)
  • chave de encriptação de coluna compatível com enclave - uma chave de encriptação de coluna que é encriptada com uma chave de coluna compatível com enclave master. Apenas chaves de encriptação de coluna compatíveis com o enclave podem ser usadas para cálculos no interior do enclave seguro.

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

Colunas habilitadas com enclave

Uma coluna de base de dados que suporta enclave está encriptada com uma chave de criptografia de coluna habilitada para enclave.

Capacidades de computação confidenciais para colunas habilitadas para enclave

Os dois principais benefícios do Always Encrypted com enclaves seguros são a encriptação no local e consultas confidenciais avançadas.

Encriptação no local

A criptografia no local permite operações criptográficas em colunas de banco de dados no interior do enclave seguro, sem mover os dados do banco de dados. A encriptação no local melhora o desempenho e a fiabilidade das operações criptográficas. Você pode executar a criptografia no local usando a instrução ALTER TABLE (Transact-SQL).

As operações criptográficas suportadas no local são:

  • Criptografando uma coluna de texto sem formatação com uma chave de criptografia de coluna habilitada para enclave.
  • Recriptografando uma coluna habilitada para enclave para:
    • Girar uma chave de criptografia de coluna - criptografe novamente a coluna com uma nova chave de criptografia de coluna habilitada para enclave.
    • Altere o tipo de criptografia de uma coluna com enclave habilitado, por exemplo, de deterministicamente para aleatoriamente.
  • Descriptografar dados armazenados numa coluna ativada para enclave (convertendo a coluna para texto simples).

A criptografia no local é permitida com criptografia determinística e aleatória, desde que as chaves de criptografia de coluna envolvidas na operação criptográfica sejam compatíveis com enclave.

Consultas confidenciais

Observação

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

Consultas confidenciais são consultas DML que envolvem operações em colunas com enclave ativado realizadas dentro do enclave seguro.

As operações apoiadas no interior dos enclaves seguros são as seguintes:

Funcionamento Banco de Dados SQL do Azure SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Operadores de comparação Suportado Suportado Suportado
ENTRE (Transact-SQL) Suportado Suportado Suportado
EM (Transact-SQL) Suportado Suportado Suportado
GOSTO (Transact-SQL) Suportado Suportado Suportado
DISTINTOS Suportado Suportado Suportado
Junta-se Suportado Suportado Somente uniões de loop aninhadas suportadas
SELECT - Cláusula ORDER BY (Transact-SQL) Suportado Suportado Não suportado
SELECT - GROUP BY- Transact-SQL Suportado Suportado Não suportado

Observação

As operações acima dentro de enclaves seguros requerem criptografia aleatória. Não há suporte para criptografia determinística. A comparação de igualdade continua a ser a operação disponível para colunas que utilizam encriptação determinística.

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

No Banco de Dados SQL do Azure e no SQL Server 2022 (16.x), consultas confidenciais usando enclaves em uma coluna de cadeia de caracteres (char, nchar) exigem que a coluna use um agrupamento de ponto de código binário (_BIN2) ou um agrupamento UTF-8. No SQL Server 2019 (15.x), é obrigatória uma collation do tipo a_BIN2.

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

Índices em colunas com suporte a enclave

Você pode criar índices não clusterizados em colunas habilitadas para enclave usando criptografia aleatória para fazer consultas DML confidenciais usando o enclave seguro serem executadas mais rapidamente.

Para garantir que um índice em uma coluna criptografada usando criptografia aleatória não vaze dados confidenciais, os valores de chave na estrutura de dados do índice (árvore B) são criptografados e classificados com base em seus valores de texto sem formatação. A classificação pelo valor de texto simples também é útil para processar consultas dentro do enclave. Quando o executor de consulta no Mecanismo de Banco de Dados usa um índice em uma coluna criptografada para cálculos dentro do enclave, ele pesquisa o índice para procurar 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 de índice encriptada a ser comparada. Em seguida, executa a comparação em texto simples e retorna o resultado da comparação ao executor.

A criação de índices em colunas que usam criptografia aleatória e não são habilitadas para enclave permanece sem suporte.

Um índice em uma coluna usando criptografia determinística é classificado com base em texto cifrado (não texto sem formatação), independentemente de a coluna estar habilitada para enclave ou não.

Para obter mais informações, consulte Criar e usar índices em colunas usando Always Encrypted com enclaves seguros. Para obter informações gerais sobre como funciona a indexação no motor de base de dados, consulte o artigo Índices Clusterizados e Não Clusterizados Descritos.

Recuperação de banco de dados

Se uma instância do SQL Server falhar, seus bancos de dados podem ser deixados 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 reverter todas as transações incompletas encontradas no log de transações para garantir que a integridade do banco de dados seja preservada. Se uma transação incompleta fez alterações em um índice, essas alterações também precisam ser desfeitas. Por exemplo, alguns valores de chave no índice podem precisar ser removidos ou reinseridos.

Importante

A Microsoft recomenda enfaticamente habilitar de recuperação acelerada de banco de dados (ADR) para seu banco de dados, antes de criar o primeiro índice em uma coluna habilitada para enclave criptografada com criptografia aleatória. O ADR é habilitado por padrão no Banco de Dados SQL do Azure e na Instância Gerenciada SQL do Azure. O ADR está disponível, mas não habilitado por padrão no SQL Server 2019 (15.x) e posterior.

Com o processo de recuperação de bases de dados tradicional (que segue o modelo de recuperação ARIES), para desfazer uma alteração num índice, o Motor de Base de Dados precisa esperar que uma aplicação forneça a chave de criptografia para a coluna ao enclave, algo que pode demorar bastante. A recuperação acelerada de bases de dados (ADR) reduz drasticamente o número de operações de reversão que devem ser adiadas porque uma chave de encriptação de coluna não está disponível na cache dentro do enclave. Consequentemente, aumenta substancialmente a disponibilidade do banco de dados, minimizando a chance de uma nova transação ser bloqueada. Com o ADR habilitado, o Mecanismo de Banco de Dados ainda pode precisar de uma chave de criptografia de coluna para concluir a limpeza de versões de dados antigas, mas ele faz isso como uma tarefa em segundo plano que não afeta a disponibilidade do banco de dados ou as transações do usuário. Você pode ver mensagens de erro no log de erros, indicando falha nas operações de limpeza devido à falta de chave de criptografia de coluna.

Considerações de segurança

As seguintes considerações de segurança aplicam-se ao Always Encrypted com enclaves seguros.

  • Os enclaves VBS ajudam a proteger seus dados contra ataques dentro da VM. No entanto, eles não fornecem nenhuma proteção contra ataques usando contas de sistema privilegiadas originadas do host. Os enclaves Intel SGX protegem os dados contra ataques provenientes do SO convidado e do SO anfitrião.
  • O uso do atestado de enclave é recomendado se ele estiver disponível para seu ambiente e se você estiver preocupado em proteger seus dados contra ataques de usuários com acesso de administrador no nível do sistema operacional à máquina que hospeda seu banco de dados. Se você usar atestado, precisará garantir que o serviço de atestado e sua configuração sejam gerenciados por um administrador confiável. Além disso, ambos os serviços de certificação suportados oferecem diferentes políticas e modos de atestado, alguns dos quais realizam verificação mínima do enclave e seu ambiente, e são projetados para teste e desenvolvimento. Siga de perto as diretrizes específicas do seu serviço de certificação para garantir que você esteja usando as configurações e políticas recomendadas para suas implantações de produção.
  • Criptografar uma coluna usando criptografia aleatória com uma chave de criptografia de coluna habilitada para enclave pode resultar em vazamento da ordem dos dados armazenados na coluna, pois essas colunas suportam comparações de intervalo. Por exemplo, se uma coluna criptografada, contendo salários de funcionários, tiver um índice, um DBA mal-intencionado poderá verificar o índice para encontrar o valor máximo de salário criptografado e identificar uma pessoa com o salário máximo (supondo que o nome da pessoa não esteja criptografado).
  • Se você usar o Always Encrypted para proteger dados confidenciais contra acesso não autorizado por DBAs, não compartilhe as chaves de coluna master 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 de coluna dentro do enclave.

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

Ao configurar uma solução de alta disponibilidade ou recuperação de desastres para um banco de dados usando Always Encrypted com enclaves seguros, certifique-se de que todas as réplicas de banco de dados possam 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 tente usar a funcionalidade do Always Encrypted com enclaves seguros falhará após o failover.

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

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

  • SQL Server

    • Ao configurar um grupo de disponibilidade Always On, certifique-se de que cada instância do SQL Server que hospeda um banco de dados no grupo de disponibilidade ofereça suporte a Always Encrypted com enclaves seguros e tenha um enclave e um atestado configurados.
    • Ao restaurar a partir de um arquivo de backup de um banco de dados que usa a funcionalidade Always Encrypted com enclaves seguros em uma instância do SQL Server que não tenha o enclave configurado, a operação de restauração será bem-sucedida e todas as funcionalidades que não dependem do enclave estarão disponíveis. No entanto, qualquer instrução subsequente usando a funcionalidade enclave falhará, e os índices em colunas habilitadas para enclave usando criptografia aleatória se tornarão inválidos. O mesmo se aplica ao anexar um banco de dados usando Always Encrypted com enclaves seguros na instância que não tem o enclave configurado.
    • Se o seu banco de dados contiver índices em colunas habilitadas para enclave usando criptografia aleatória, certifique-se de ativar a Recuperação Acelerada de Banco de Dados (ADR) no banco de dados antes de criar um backup. O ADR assegurará que a base de dados, incluindo os índices, esteja disponível imediatamente após o restauro da base de dados. Para obter mais informações, consulte Database Recovery.

  • Banco de Dados SQL do Azure

    • Ao configurar de replicação geográfica ativa, certifique-se de que um banco de dados secundário suporte enclaves seguros, se o banco de dados primário também os suportar.

No SQL Server e na Base de Dados SQL do Azure, ao migrar a sua base de dados usando um ficheiro bacpac, você precisa remover todos os índices de colunas com enclave ativado usando criptografia aleatória antes de criar o ficheiro bacpac.

Limitações conhecidas

Always Encrypted with secure enclaves resolve algumas limitações do Always Encrypted suportando criptografia no local e consultas confidenciais mais ricas com índices, conforme explicado em Recursos de computação confidenciais para colunas habilitadas para enclave.

As restantes limitações de Always Encrypted listadas em Limitações aplicam-se igualmente 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 usando criptografia aleatória.
  • As colunas habilitadas para enclave usando criptografia aleatória não podem ser colunas de chave primária e não podem ser referenciadas por restrições de chave estrangeira ou restrições de chave única.
  • No SQL Server 2019 (15.x) (essa limitação não se aplica ao Banco de Dados SQL do Azure ou ao SQL Server 2022 (16.x)) apenas as junções de loop aninhadas (usando índices, se disponíveis) são suportadas em colunas habilitadas para enclave usando criptografia aleatória. Para obter informações sobre outras diferenças entre produtos, consulte Consultas confidenciais.
  • As operações criptográficas in-loco não podem ser combinadas com quaisquer outras alterações de metadados de coluna, exceto alterar um agrupamento dentro da mesma página de código e anulabilidade. Por exemplo, você não pode criptografar, criptografar novamente ou descriptografar uma coluna E alterar um tipo de dados da coluna em uma única instrução ALTER TABLE/ALTER COLUMN Transact-SQL. Utilize duas instruções separadas.
  • Não se dá suporte ao uso de chaves habilitadas para enclave em colunas de tabelas em memória.
  • As expressões que definem colunas computadas não podem executar nenhum cálculo em colunas habilitadas para enclave usando criptografia aleatória (mesmo que os cálculos estejam entre as operações suportadas listadas em Consultas confidenciais).
  • Os caracteres de escape não são suportados em parâmetros do operador LIKE em colunas habilitadas para enclave usando criptografia aleatória.
  • As consultas com o operador LIKE ou um operador de comparação que tenha um parâmetro de consulta usando 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 ferramentas:
    • Os únicos armazéns de chaves com suporte para armazenar chaves de coluna master com suporte para enclave são o Repositório de Certificados do Windows e o Cofre de Chaves do Azure.
    • Para acionar uma operação criptográfica no local via ALTER TABLE/ALTER COLUMN, precisa emitir a instrução usando uma janela de consulta no SSMS ou no Azure Data Studio, ou pode escrever o seu próprio programa que emite a instrução. Atualmente, o cmdlet Set-SqlColumnEncryption no módulo SqlServer PowerShell e o assistente Always Encrypted no SQL Server Management Studio não oferecem suporte à criptografia in-loco. 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 estejam 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