Sempre criptografado com enclaves seguros

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores no Windows Azure SQL Database

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á forma de ver quaisquer dados 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:

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 afirmações:

• O driver do cliente envia as chaves de encriptação das colunas necessárias para as operações ao enclave seguro (através de um canal seguro) e submete a declaraçã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 declarações, tanto os dados como as chaves de encriptação das colunas não são expostos em texto não cifrado no motor de base de dados, fora do enclave seguro.

Controladores 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 a aplicação e o driver do cliente para ativar operações do enclave e atestação do enclave (consulte a secção Atestação segura do enclave 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):

• Enclaves de Segurança Baseada em Virtualização (VBS) (também conhecidos como Virtual Secure Mode ou enclaves VSM) - uma tecnologia baseada em software que depende do hipervisor do Windows e não requer nenhum hardware especial.
• Extensões Intel Software Guard (Intel SGX) enclaves - uma tecnologia de ambiente de execução confiável baseada em hardware.

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. (As enclaves Intel SGX não são suportadas.)

• 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:

  • Bases de dados que usam 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.

Atestação segura de enclave

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:

• Microsoft Azure Attestation - uma solução de atestado baseada em nuvem.
• Host Guardian Service (HGS) que implementa atestado de tempo de execução do Windows Defender System Guard.

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:

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 bases de dados da série DC) no Azure SQL Database, a atestação é obrigatória e requer o atestado da Microsoft Azure.
• Os enclaves VBS no Banco de Dados SQL do Azure não oferecem suporte a atestado.

Para mais informações, consulte:

• Planeie a atestação do Serviço de Guardiões do Anfitrião.
• Plano para enclaves e atestação do Intel SGX nas bases de dados Azure SQL.

Terminologia

Chaves habilitadas pelo enclave

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

• Chave mestra de coluna habilitada por enclave - uma chave de coluna master que tem a ENCLAVE_COMPUTATIONS propriedade especificada no objeto de metadados da chave de coluna master dentro da base de dados. O objeto de metadados da chave da coluna master deve também conter uma assinatura válida das propriedades dos 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 está encriptada com uma chave de coluna master compatível com enclave. Apenas chaves de encriptação de colunas habilitadas pelo enclave podem ser usadas para cálculos dentro do enclave seguro.

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

Colunas habilitadas pelo enclave

Uma coluna habilitada por enclave é uma coluna de base de dados encriptada com uma chave de encriptação de coluna habilitada pelo enclave.

Capacidades de computação confidenciais para colunas habilitadas por 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:

• Encriptação de uma coluna de texto simples com uma chave de encriptação de coluna habilitada por enclave.
• Reencriptar uma coluna encriptada com enclave encriptado para:
  • Rodar uma chave de encriptação de coluna - voltar a encriptar a coluna com uma nova chave de encriptação habilitada pelo enclave.
  • Alterar o tipo de encriptação de uma coluna habilitada por enclave, por exemplo, de determinista para randomizada.
• Descriptografar dados armazenados numa coluna com enclave habilitada (convertendo a coluna numa coluna de texto simples).

A encriptação no local é permitida tanto com encriptação determinística como aleatória, desde que as chaves de encriptação das colunas envolvidas numa operação criptográfica estejam habilitadas pelo enclave.

Consultas confidenciais

Consultas confidenciais são consultas DML que envolvem operações sobre colunas habilitadas pelo enclave realizadas dentro do enclave seguro.

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

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

Índices em colunas habilitadas pelo 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 consulta delega cada comparação ao enclave, que desencripta um valor armazenado na coluna e o valor da chave de índice encriptada a comparar, realiza a comparação em texto simples e devolve o resultado da comparação ao executor.

Criar índices em colunas que usam encriptação aleatória e que não são habilitados pelo enclave continua 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.

No processo tradicional de recuperação da base de dados (que segue o modelo de recuperação ARIES), para desfazer uma alteração num índice, o mecanismo de base de dados precisa esperar até que uma aplicação forneça a chave de encriptação da coluna para o enclave, o que pode demorar muito tempo. A recuperação acelerada de bases de dados (ADR) reduz drasticamente o número de operações de anulação que têm de ser adiadas, porque uma chave de cifragem 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. Poderá ver mensagens de erro no registo de erros, indicando falhas em operações de limpeza devido à falta de uma chave de encriptação 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.
• Encriptar uma coluna usando encriptação aleatorizada com uma chave de encriptação de coluna ativada por enclave pode resultar na divulgação da ordem dos dados armazenados na coluna, pois tais colunas suportam comparações de intervalos. 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 fazem uso de enclaves não irão funcionar na cópia nem na base de dados migrada.

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

• Servidor SQL

  • 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 a sua base de dados contiver índices em colunas habilitadas por enclaves usando encriptação aleatória, certifique-se de ativar a Recuperação Acelerada da Base de Dados (ADR) na base de dados antes de criar uma cópia de segurança da base de dados. 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 a geo-replicação ativa, certifique-se de que uma base de dados secundária suporta enclaves seguros, caso a base de dados principal o fizer.

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

O Always Encrypted com enclaves seguros resolve algumas limitações do Always Encrypted ao suportar encriptação no local e consultas confidenciais mais enriquecidas com índices, conforme explicado em Capacidades de computação confidenciais para colunas habilitadas por 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.
• Colunas habilitadas por enclave usando encriptação aleatória não podem ser colunas de chave primária nem podem ser referenciadas por restrições de chave estrangeira ou de chave única.
• No SQL Server 2019 (15.x) (esta limitação não se aplica ao Azure SQL Database ou SQL Server 2022 (16.x)) apenas as juntas de loop aninhadas (usando índices, se disponíveis) são suportadas em colunas habilitadas pelo enclave usando encriptação aleatória. Para informações sobre outras diferenças entre diferentes produtos, consulte Consultas confidenciais.
• As operações criptográficas no local não podem ser combinadas com quaisquer outras alterações nos metadados das colunas, exceto alterar uma colação dentro da mesma página de códigos e a 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. Use duas instruções separadas.
• O uso de chaves habilitadas por enclave para colunas em tabelas em memória não é suportado.
• 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).
• Caracteres de escape não são suportados nos parâmetros do operador LIKE em colunas habilitadas por enclave usando encriptação 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.
• 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.
• Quando você restaura um banco de dados habilitado para enclave VBS, é essencial reconfigurar a configuração do enclave VBS novamente.

Conteúdo relacionado

• Sempre encriptado com documentação de enclaves seguros
• Azure SQL Database Always Encrypted, SIGMOD '20: Atas da Conferência Internacional ACM SIGMOD 2020 sobre Gestão de Dados
• Tutorial: Introdução ao uso do Always Encrypted com enclaves seguros
• Configurar e usar Always Encrypted com enclaves seguros
• Sempre encriptado com enclaves seguros, demos/samples
• exemplos do SQL Server
• Computação Confidencial do Azure