Planejar o atestado do Serviço Guardião de Host
Aplica-se a: 
SQL Server 2019 (15.x) e versões posteriores (somente para Windows)
O atestado é um fluxo de trabalho que permite que um aplicativo cliente verifique se está conversando com um enclave confiável dentro do processo do SQL Server ao usar Always Encrypted com enclaves seguros.
No SQL Server, o Always Encrypted com enclaves seguros usa enclaves de segurança baseada em virtualização (SBV), também conhecidos como modo de segurança virtual, ou enclaves VSM, que são uma tecnologia baseada em software que depende do hipervisor do Windows e não requer nenhum hardware especial. O atestado de um enclave SBV implica verificar se o código dentro do enclave é válido e se o computador que hospeda o SQL Server é confiável. O atestado alcança essa meta introduzindo um terceiro que pode validar a identidade (e, opcionalmente, a configuração) do computador SQL Server. Para que o SQL Server possa usar um enclave para executar uma consulta, ele deve fornecer informações ao serviço de atestado sobre seu ambiente operacional para obter um certificado de integridade. Esse certificado de integridade é enviado para o cliente, que pode verificar de forma independente sua autenticidade com o serviço de atestado. Depois que o cliente confia no certificado de integridade, ele sabe que está se comunicando com um enclave SBV confiável e emitirá a consulta que usará esse enclave.
O atestado é crítico para detectar alguns ataques de administradores de SO mal-intencionados, por exemplo, ataques que envolvem adulterar a biblioteca do SQL Server em execução no enclave. Caso não se preocupe com esses ataques (por exemplo, por usar Always Encrypted com enclaves seguros em um ambiente que não seja de produção), confira Planejar Always Encrypted com enclaves seguros em SQL Server sem atestado.
A função HGS (Serviço Guardião de Host) no Windows Server 2019 fornece funcionalidades de atestado remoto para Always Encrypted com enclaves SBV. Este artigo orientará você pelas decisões e requisitos de pré-implantação para usar Always Encrypted com enclaves VBS e atestado HGS.
Observação
Quando o SQL Server é implantado em uma VM, os enclaves do SBV ajudam a proteger dados contra ataques dentro da VM. Mas eles não fornecem proteção contra ataques que usam contas de sistema privilegiadas originadas do host. Por exemplo, um despejo de memória da VM gerada no computador host pode conter a memória do enclave.
Visão geral da arquitetura
O HGS (Serviço Guardião de Host) é um serviço Web clusterizado executado no Windows Server 2019 ou posterior. Em uma implantação típica, haverá de um a três servidores HGS, pelo menos um computador executando o SQL Server e um computador executando um aplicativo cliente ou ferramentas, como o SQL Server Management Studio. Como o HGS é responsável por determinar quais computadores executando o SQL Server são confiáveis, ele requer isolamento físico e lógico da instância do SQL Server que ele está protegendo. Se os mesmos administradores tiverem acesso ao HGS e a um computador SQL Server, eles poderão configurar o serviço de atestado para permitir que um computador mal-intencionado execute o SQL Server, permitindo que eles comprometam o enclave SBV.
Domínio HGS
A instalação do HGS criará automaticamente um domínio Active Directory para os servidores HGS, os recursos de cluster de failover e as contas de administrador.
O computador que executa o SQL Server não precisa estar em um domínio, mas, se estiver, deverá ser um domínio diferente daquele usado pelo servidor HGS.
Alta disponibilidade
O recurso HGS instala e configura automaticamente um cluster de failover. Em um ambiente de produção, é recomendável usar três servidores HGS para alta disponibilidade. Veja a documentação do cluster de failover para obter detalhes sobre como o quorum de cluster é determinado e configurações alternativas, incluindo clusters de dois nós com uma testemunha externa.
O armazenamento compartilhado não é necessário entre os nós do HGS. Uma cópia do banco de dados de atestado é armazenada em cada servidor HGS e é replicada automaticamente pela rede pelo serviço de cluster.
Conectividade de rede
Tanto o cliente SQL quanto o SQL Server precisa conseguir se comunicar com o HGS por HTTP. Configure o HGS com um certificado TLS para criptografar todas as comunicações entre o cliente SQL e o HGS, bem como entre o SQL Server e o HGS. Essa configuração ajuda na proteção contra ataques man-in-the-middle e garante que você esteja se comunicando com o servidor HGS correto.
Os servidores HGS exigem conectividade entre cada nó do cluster para que o banco de dados do serviço de atestado continue em sincronia. É uma melhor prática de cluster de failover conectar os nós HGS em uma rede para comunicação de cluster e usar uma rede separada para outros clientes se comunicarem com o HGS.
Modos de atestado
Quando um computador que executa o SQL Server tenta atestar com o HGS, ele primeiro pergunta ao HGS como deve atestar. O HGS é compatível com dois modos de atestado a serem usados com o SQL Server:
| Modo de atestado | Explicação |
|---|---|
| TPM | O atestado TPM (Trusted Platform Module) fornece a garantia mais forte sobre a identidade e a integridade do atestado do computador com o HGS. Ele requer que os computadores que executam o SQL Server tenham a versão 2.0 do TPM instalada. Cada chip do TPM contém uma identidade exclusiva e imutável (chave de endosso) que pode ser usada para identificar um determinado computador. Os TPMs também medem o processo de inicialização do computador, armazenando hashes de medidas sensíveis à segurança em PCRs (Registros de Controle de Plataforma) que podem ser lidos, mas não modificados pelo sistema operacional. Essas medidas são usadas durante o atestado para fornecer prova de criptografia de que um computador está na configuração de segurança que alega estar. |
| Chave de host | O atestado de chave de host é uma forma mais simples de atestado que verifica apenas a identidade de um computador usando um par de chaves assimétricas. A chave privada é armazenada no computador que executa o SQL Server, e a chave pública é fornecida para o HGS. A configuração de segurança do computador não é medida e um chip TPM 2.0 não é necessário no computador que executa o SQL Server. É importante proteger a chave privada instalada no computador do SQL Server porque qualquer pessoa que obtiver essa chave poderá representar um computador do SQL Server legítimo e o enclave SBV em execução no SQL Server. |
Em geral, fazemos as seguintes recomendações:
- Para servidores de produção físicos, recomenda-se usar o atestado do TPM para obter as garantias adicionais que ele fornece.
- Para servidores de produção virtuais, recomendamos o atestado de chave de host, pois a maioria das máquinas virtuais não tem TPMs virtuais nem Inicialização Segura. Se você estiver usando uma VM com segurança aprimorada como uma VM blindada no local, poderá optar por usar o modo TPM. Em todas as implantações virtualizadas, o processo de atestado apenas analisa seu ambiente de VM, e não a plataforma de virtualização sob a VM.
- Para cenários de desenvolvimento/teste, recomendamos o atestado de chave de host porque é mais fácil de configurar.
Modelo de confiança
No modelo de confiança de enclave VBS, as consultas e os dados criptografados são avaliados em um enclave baseado em software para protegê-lo do sistema operacional host. O acesso a esse enclave é protegido pelo hipervisor da mesma maneira que duas máquinas virtuais em execução no mesmo computador não podem acessar a memória uma da outra.
Para que um cliente confie que está se comunicando com uma instância legítima de SBV, você deve usar o atestado baseado em TPM que estabelece uma raiz de confiança do hardware no computador SQL Server
As medidas do TPM capturadas durante o processo de inicialização incluem a chave de identidade exclusiva da instância do VBS, garantindo que o certificado de integridade seja válido apenas nesse computador. Além disso, quando um TPM está disponível em um computador que executa o VBS, a parte privada da chave de identidade do VBS é protegida pelo TPM, impedindo que alguém tente representar essa instância de VBS.
A inicialização segura é necessária com o atestado do TPM para garantir que a UEFI carregou um carregador de inicialização legítimo, assinado pela Microsoft e que nenhum rootkit interceptou o processo de inicialização do hipervisor. Além disso, um dispositivo IOMMU é necessário por padrão para garantir que os dispositivos de hardware com acesso direto à memória não possam inspecionar ou modificar a memória do enclave.
Essas proteções pressupõem que o computador que executa o SQL Server é um computador físico. Ao virtualizar o computador que executa o SQL Server, você não poderá mais garantir que a memória da VM esteja protegida contra inspeção pelo hipervisor ou administrador do hipervisor. O administrador de hipervisor poderia, por exemplo, despejar a memória da VM e obter acesso à versão de texto não criptografado da consulta e aos dados no enclave. Da mesma forma, mesmo que a VM tenha um TPM virtual, ela só pode medir o estado e a integridade do sistema operacional da VM e do ambiente de inicialização. Ela não pode medir o estado do hipervisor que controla a VM.
Porém, mesmo quando o SQL Server é virtualizado, o enclave ainda é protegido contra ataques originados no sistema operacional da VM. Se você confia em seu hipervisor ou no provedor de nuvem e se preocupa principalmente com o administrador do banco de dados e ataques de administrador do SO a informações confidenciais, um SQL Server virtualizado pode atender a seus requisitos.
Da mesma forma, o atestado de chave de host ainda é valioso em situações em que um módulo do TPM 2.0 não está instalado no computador que executa o SQL Server ou em cenários de desenvolvimento/teste em que a segurança não é fundamental. Você ainda pode usar muitos dos recursos de segurança mencionados, como inicialização segura e um módulo do TPM 1.2, para proteger melhor a SBV e o sistema operacional como um todo. Mas, como não há como o HGS verificar se o computador realmente tem essas configurações habilitadas com o atestado de Chave de Host, o cliente não tem garantia de que o host está realmente usando todas as proteções disponíveis.
Pré-requisitos
Pré-requisitos do servidor do HGS
Os computadores que executam a função de Serviço Guardião de Host devem atender aos seguintes requisitos:
| Componente | Requisito |
|---|---|
| Sistema operacional | Windows Server 2019 ou posterior, Standard ou Datacenter Edition |
| CPU | 2 núcleos (mínimo), 4 núcleos (recomendado) |
| RAM | 8 GB (mínimo) |
| NICs | Dois NICs com IPs estáticos recomendados (um para o tráfego de cluster, um para o serviço HGS) |
O HGS é uma função associada à CPU devido ao número de ações que exigem criptografia e descriptografia. O uso de processadores modernos com recursos de aceleração criptográfica melhorará o desempenho do HGS. Os requisitos de armazenamento para os dados de atestado são mínimos, no intervalo de 10 KB a 1 MB por atestado de computador exclusivo.
O computador do HGS não deve ser ingressado em um domínio antes de você começar.
Pré-requisitos de computador SQL Server
Os computadores que executam o SQL Server devem atender aos Requisitos de instalação do SQL Server e aos Requisitos de hardware do Hyper-V.
Estes requisitos incluem:
- SQL Server 2019 (15.x) ou posterior
- Windows 10, versão 1809 ou posterior – edição Enterprise, Windows 11 ou posterior – edição Enterprise, Windows Server 2019 ou posterior – edição Datacenter. Outras edições do Windows 10/11 e do Windows Server não dão suporte a atestado com HGS.
- Suporte de CPU para tecnologias de virtualização:
- Intel VT-x com Tabelas de Página Estendida.
- AMD-V com Indexação de Virtualização Rápida.
- Se você estiver executando o SQL Server em uma VM:
- No Azure, use um tamanho de VM de Geração 2 (recomendado) ou use um tamanho de VM de Geração 1 com virtualização aninhada habilitada. Verifique a documentação de tamanhos de VM individuais para determinar quais tamanhos de VM de Geração 1 dão suporte à virtualização aninhada.
- No Hyper-V 2016 ou posterior (fora do Azure), verifique se a sua VM é de Geração 2 (recomendado) ou se é uma VM de Geração 1 com virtualização aninhada habilitada. Para saber mais informações, confira Devo criar uma máquina virtual de geração 1 ou 2 no Hyper-V? e Configurar virtualização aninhada.
- No VMware vSphere 6.7 ou posterior, habilite o suporte de segurança baseada em virtualização para a VM conforme descrito na documentação do VMware.
- Outros hipervisores e nuvens públicas podem dar suporte a recursos de virtualização aninhados que também permitem Always Encrypted com enclaves de VBS. Verifique a documentação da solução de virtualização para obter instruções sobre compatibilidade e configuração.
- Se você planeja usar o atestado de TPM, precisará de um chip TPM 2.0 Rev 1.16 pronto para uso no servidor. Neste momento, o atestado HGS não funciona com chips TPM 2.0 Rev 1.38. Além disso, o TPM deve ter um Certificado de Chave de Endosso válido.
Funções e responsabilidades ao configurar o atestado com o HGS
Configurar o atestado com o HGS envolve a configuração de componentes de diferentes tipos: HGS, computadores SQL Server, instâncias do SQL Server e aplicativos que acionam o atestado de enclave. A configuração de componentes de cada tipo é executada por usuários supondo uma das funções distintas abaixo:
- Administrador do HGS: implanta o HGS, registra computadores SQL Server com HGS e compartilha a URL de atestado do HGS com administradores do computador SQL Server e administradores de aplicativos cliente.
- Administrador do computador SQL Server: instala os componentes cliente do atestado, habilita SBV em computadores SQL Server, fornece ao administrador do HGS as informações necessárias para registrar os computadores SQL Server com o HGS, configura a URL de atestado em computadores SQL Server e verifica se os computadores SQL Server podem atestar com êxito com o HGS.
- DBA: configura enclaves seguros em instâncias do SQL Server.
- Administrador de aplicativos – configura o aplicativo com a URL de atestado obtida do administrador do HGS.
Em ambientes de produção (manipulando dados confidenciais reais), é importante que sua organização obedeça à separação de funções ao configurar o atestado, em que cada função distinta é assumida por pessoas diferentes. Em particular, se a meta da implantação de Always Encrypted em sua organização for reduzir a área da superfície de ataque garantindo que administradores de computadores do SQL Server e DBAs não possam acessar dados confidenciais, os administradores do SQL Server e DBAs não deverão controlar os servidores do HGS.
Considerações de ambiente de desenvolvimento ou de teste
Ao usar o Always Encrypted com enclaves SBV em um ambiente de desenvolvimento ou de teste e não exigir alta disponibilidade ou proteção forte do computador que executa o SQL Server, você poderá fazer uma ou todas as seguintes concessões para uma implantação simplificada:
- Use Always Encrypted com enclaves seguros sem atestado. Confira Planejar Always Encrypted com enclaves seguros em SQL Server sem atestado.
- Como alternativa:
- Implante apenas um nó do HGS. Embora o HGS instale um cluster de failover, você não precisará adicionar mais nós, se a alta disponibilidade não for uma preocupação.
- Use o modo de chave de host em vez do modo TPM para uma experiência de configuração mais simples.
- Virtualize o HGS ou o SQL Server para economizar recursos físicos.
- Execute o SSMS ou outras ferramentas para configurar o Always Encrypted com enclaves seguros no mesmo computador que o SQL Server. Isso deixa as chaves mestras de coluna no mesmo computador que o SQL Server, portanto, não faça isso em um ambiente de produção.