Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:
SQL Server 2019 (15.x) e versões posteriores no Windows
Atestação é um processo que permite a uma aplicação cliente verificar que está a comunicar com um enclave confiável dentro do processo do SQL Server ao utilizar Always Encrypted com enclaves seguros.
No SQL Server, o Always Encrypted com enclaves seguros usa enclaves VBS (Segurança Baseada em Virtualização) (também conhecidos como Modo de Segurança Virtual ou enclaves VSM) - uma tecnologia baseada em software que depende do hipervisor do Windows e não requer nenhum hardware especial. Atestar um enclave VBS envolve verificar tanto que o código dentro do enclave é válido como o computador que aloja o SQL Server é fiável. A atestação atinge este objetivo ao introduzir um terceiro que pode validar a identidade (e, opcionalmente, a configuração) do computador SQL Server. Antes de o SQL Server poder usar um enclave para executar uma consulta, este deve fornecer informações ao serviço de atestação sobre o seu ambiente operativo para obter um certificado de saúde. Este certificado de saúde é então enviado ao cliente, que pode verificar de forma independente a sua autenticidade com o serviço de atestado. Quando o cliente confia no certificado de saúde, sabe que está a falar com um enclave VBS confiável e irá emitir a consulta que irá usar esse enclave.
A atestação é fundamental para detetar alguns ataques de administradores maliciosos do sistema operativo, por exemplo, ataques que envolvem manipulação da biblioteca SQL Server a correr dentro do enclave. Se não estiver preocupado com tais ataques (por exemplo, está a usar Always Encrypted com enclaves seguros num ambiente não de produção), veja Plano para Always Encrypted com enclaves seguros no SQL Server sem confirmação.
A função Host Guardian Service (HGS) no Windows Server 2019 ou posterior oferece capacidades remotas de atestação para enclaves do Always Encrypted com VBS. Este artigo irá guiá-lo pelas decisões e requisitos pré-implementação para usar o Always Encrypted com enclaves VBS e atestação HGS.
Observação
Quando o SQL Server é implantado em uma VM, 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. Por exemplo, um despejo de memória da VM gerada na máquina host pode conter a memória do enclave.
Visão geral da arquitetura
O Host Guardian Service (HGS) é um serviço web em cluster que corre no Windows Server 2019 ou posterior. Numa implementação típica, haverá entre 1 a 3 servidores HGS, pelo menos um computador a correr SQL Server e um computador a correr uma aplicação cliente ou ferramentas, como o SQL Server Management Studio. Como o HGS é responsável por determinar quais os computadores a correr SQL Server que são fiáveis, requer isolamento físico e lógico da instância SQL Server que está a proteger. Se os mesmos administradores tiverem acesso ao HGS e a um computador SQL Server, poderiam configurar o serviço de atestação para permitir que um computador malicioso execute o SQL Server, comprometendo assim o enclave VBS.
Domínio HGS
A configuração do HGS criará automaticamente um novo domínio Active Directory para os servidores HGS, recursos do cluster de failover e contas de administrador.
O computador a correr SQL Server não precisa de estar num domínio, mas se estiver, deve ser um domínio diferente daquele que o servidor HGS usa.
Alta disponibilidade
A funcionalidade HGS instala e configura automaticamente um cluster de failover. Num ambiente de produção, recomenda-se usar três servidores HGS para alta disponibilidade. Consulte a documentação do cluster de failover para obter detalhes sobre como o quórum do cluster é determinado e as configurações alternativas, incluindo clusters de dois nós com uma testemunha externa.
Não é necessário armazenamento partilhado entre os nós HGS. Uma cópia da base de dados de atestação é armazenada em cada servidor HGS e é replicada automaticamente pela rede pelo serviço do cluster.
Conectividade de rede
Tanto o cliente SQL como o SQL Server precisam de conseguir comunicar com o HGS via HTTP. Configure o HGS com um certificado TLS para encriptar todas as comunicações entre o Cliente SQL e o HGS, bem como entre SQL Server e HGS. Esta configuração ajuda a proteger contra ataques man-in-the-middle e garante que está a falar com o servidor HGS correto.
Os servidores HGS requerem conectividade entre cada membro do cluster para garantir que a base de dados do serviço de atestação permanece sincronizada. É uma boa prática para clusters de failover ligar os nós HGS numa única rede para comunicação do cluster e usar uma rede separada para outros clientes comunicarem com o HGS.
Modos de atestação
Quando um computador a executar SQL Server tenta atestar com o HGS, primeiro pergunta ao HGS como deve atestar. O HGS suporta dois modos de atestação para uso com SQL Server:
| Modo de atestação | Explanation |
|---|---|
| TPM | A atestação do Módulo de Plataforma Confiável (TPM) fornece a maior garantia sobre a identidade e integridade do computador que atesta com o HGS. Exige que os computadores a correr SQL Server tenham o TPM versão 2.0 instalado. Cada chip TPM contém uma identidade única e imutável (Chave de Endosso) que pode ser usada para identificar um determinado computador. Os TPMs também medem o processo de arranque do computador, armazenando hashes de medições sensíveis à segurança em Registos de Controlo de Plataforma (PCRs) que podem ser lidos, mas não modificados pelo sistema operativo. Estas medições são usadas durante a atestação para fornecer provas criptográficas de que um computador está na configuração de segurança que afirma ter. |
| Chave do Host | A atestação de chave host é uma forma mais simples de atestação que só verifica a identidade de um computador utilizando um par de chaves assimétricas. A chave privada é armazenada no computador a correr o SQL Server e a chave pública é fornecida ao HGS. A configuração de segurança do computador não é medida e não é necessário um chip TPM 2.0 no computador que corre SQL Server. É importante proteger a chave privada instalada no computador SQL Server porque qualquer pessoa que obtenha esta chave pode fazer-se passar por um computador SQL Server legítimo e pelo enclave VBS a correr dentro do SQL Server. |
De um modo geral, fazemos as seguintes recomendações:
- Para servidores de produção física, recomendamos o uso da atestação TPM pelas garantias adicionais que proporciona.
- Para servidores de produção virtual, recomendamos a atestação de chaves do anfitrião, pois a maioria das máquinas virtuais não tem TPMs virtuais nem Secure Boot. Se estiveres a usar uma VM com segurança melhorada, como uma VM blindada on-premiss, podes optar por usar o modo TPM. Em todas as implementações virtualizadas, o processo de atestação analisa apenas o seu ambiente de VM, e não a plataforma de virtualização por baixo da VM.
- Para cenários de desenvolvimento/teste, recomendamos a autenticação da chave de host porque é mais fácil de configurar.
Modelo de confiança
No modelo de confiança do enclave VBS, as consultas e dados encriptados são avaliados num enclave baseado em software para o proteger do sistema operativo anfitrião. O acesso a este enclave é protegido pelo hipervisor da mesma forma que duas máquinas virtuais a correr no mesmo computador não conseguem aceder à memória uma da outra.
Para que um cliente confie que está a falar com uma instância legítima de VBS, deve usar uma atestação baseada em TPM, que estabelece uma raiz de confiança de hardware no computador que executa o SQL Server.
As medições TPM captadas durante o processo de arranque incluem a chave de identidade única da instância VBS, garantindo que o certificado de saúde é válido apenas nesse computador exato. Além disso, quando um TPM está disponível num computador que executa VBS, a parte privada da chave de identidade VBS é protegida pelo TPM, para impedir que alguém tente imitar essa instância de VBS.
O recurso Secure Boot é obrigatório com atestação TPM para garantir que o UEFI carregou um bootloader legítimo, assinado pela Microsoft, e que nenhum rootkit intercetou o processo de arranque do hipervisor. Além disso, um dispositivo IOMMU é obrigatório por defeito para garantir que quaisquer dispositivos de hardware com acesso direto à memória não possam inspecionar ou modificar a memória do enclave.
Estas proteções assumem todas que o computador a correr o SQL Server é uma máquina física. Se virtualizar o computador a correr SQL Server, já não pode garantir que a memória da VM está segura contra a inspeção pelo hipervisor ou administrador do hipervisor. Um administrador do hipervisor poderia, por exemplo, despejar a memória da VM e aceder à versão em texto simples da consulta e dos dados no enclave. De forma semelhante, mesmo que a VM tenha um TPM virtual, só pode medir o estado e a integridade do sistema operativo e do ambiente de arranque da VM. Não consegue medir o estado do hipervisor que controla a VM.
No entanto, mesmo quando o SQL Server está virtualizado, o enclave continua protegido contra ataques originados no sistema operativo da VM. Se confia no seu hipervisor ou fornecedor de cloud, e está principalmente preocupado com ataques de administradores de bases de dados e administradores do sistema operativo a dados sensíveis, um SQL Server virtualizado pode satisfazer os seus requisitos.
De forma semelhante, a atestação da Host Key continua a ser valiosa em situações em que um módulo TPM 2.0 não está instalado no computador a correr SQL Server ou em cenários de desenvolvimento/teste onde a segurança não é primordial. Ainda pode usar muitas das funcionalidades de segurança mencionadas, incluindo o Secure Boot e um módulo TPM 1.2, para proteger melhor o VBS e o sistema operativo como um todo. Mas, como não há forma do HGS verificar se o computador tem realmente estas definições ativadas com a atestação da Chave de Anfitrião, o cliente não tem a certeza de que o anfitrião está realmente a usar todas as proteções disponíveis.
Pré-requisitos
Pré-requisitos para servidores HGS
O(s) computador(es) que executa o papel de Serviço de Guardião Anfitrião devem cumprir os seguintes requisitos:
| Componente | Requisito |
|---|---|
| Sistema Operativo | Windows Server 2019 ou posterior, edição Standard ou Datacenter |
| CPU | 2 núcleos (mínimo), 4 núcleos (recomendado) |
| RAM | 8 GB (min) |
| Placas de Interface de Rede (NICs) | 2 NIC com IPs estáticos recomendados (1 para tráfego de cluster, 1 para serviço HGS) |
O HGS é uma função limitada pela CPU devido ao número de ações que requerem cifração e decifração. A utilização de processadores modernos com capacidades de aceleração criptográfica irá melhorar o desempenho do HGS. Os requisitos de armazenamento para dados de atestação são mínimos, na ordem de 10 KB a 1 MB por computador único que atesta.
Não ligues o(s) computador(es) HGS a um domínio antes de começares.
Pré-requisitos para computador SQL Server
O(s) computador(es) que executa(m) o SQL Server deve(m) atender aos Requisitos para Instalar o SQL Server e aos Hyper-V requisitos de hardware.
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 suportam atestação com HGS.
- Suporte de CPU para tecnologias de virtualização:
- Intel VT-x com tabelas de páginas estendidas.
- AMD-V com Indexação Rápida de Virtualização.
- Se você estiver executando o SQL Server em uma VM:
- No Azure, use um tamanho de VM de Geração 2 (recomendado) ou tamanho de VM de Geração 1 com a virtualização aninhada ativada. Consulte a documentação de tamanhos individuais de VMs para determinar quais os tamanhos de VM da Geração 1 que suportam virtualização aninhada.
- Em Hyper-V de 2016 ou posterior (fora do Azure), certifique-se de que a sua VM é de Geração 2 (recomendada) ou de uma VM de Geração 1 com virtualização aninhada ativada. Para mais informações, veja Devo criar uma máquina virtual de geração 1 ou 2 em Hyper-V? e Configurar a virtualização aninhada.
- No VMware vSphere 6.7 ou posterior, habilite o suporte de segurança baseado em virtualização para a VM, conforme descrito na documentação VMware.
- Outros hipervisores e nuvens públicas podem suportar capacidades de virtualização aninhada que permitem Always Encrypted com VBS Enclaves. Consulte a documentação da solução de virtualização para obter instruções de compatibilidade e configuração.
- Se planeias usar atestação TPM, vais precisar de um chip TPM 2.0 rev 1.16 pronto para uso no servidor. Neste momento, a atestação HGS não funciona com chips TPM 2.0 rev 1.38. Além disso, o TPM deve possuir um Certificado de Chave de Endosso válido.
Funções e responsabilidades ao configurar a atestação com HGS
Configurar atestação com HGS envolve configurar componentes de diferentes tipos: HGS, computadores do SQL Server, instâncias do SQL Server e aplicações que iniciam a atestação de enclave. A configuração dos componentes de cada tipo é realizada pelos utilizadores que assumem um dos seguintes papéis distintos:
- Administrador do HGS - implementa o HGS, regista computadores SQL Server com o HGS e partilha o URL de atestação do HGS com administradores de computadores SQL Server e administradores de aplicações clientes.
- Administrador de computadores SQL Server - instala componentes do cliente de atestado, ativa o VBS nos computadores SQL Server, fornece ao administrador do HGS a informação necessária para registar os computadores SQL Server no HGS, configura a URL de atestação nos computadores SQL Server e verifica se os computadores SQL Server conseguem atestar com sucesso com o HGS.
- DBA - configura enclaves seguros em instâncias SQL Server.
- Administrador de aplicações - configura a aplicação com a URL de atestação obtida do administrador do HGS.
Em ambientes de produção (a lidar com dados sensíveis), é importante que a sua organização garanta a separação de funções ao configurar a atestação, em que cada função distinta é assumida por pessoas diferentes. Em particular, se o objetivo de implementar o Always Encrypted na sua organização é reduzir a área de ataque ao garantir que os administradores e DBAs do SQL Server não possam aceder a dados sensíveis, os administradores e DBAs do SQL Server não devem controlar os servidores HGS.
Considerações sobre o desenvolvimento ou o ambiente de teste
Se estiver a usar o Always Encrypted com enclaves VBS num ambiente de desenvolvimento ou teste e não exigir alta disponibilidade ou proteção forte do computador que executa o SQL Server, pode fazer qualquer uma ou todas as seguintes concessões para uma implementação simplificada:
- Use o Always Encrypted com enclaves seguros sem atestação - veja Plano para Sempre Encriptado com enclaves seguros no SQL Server sem atestado.
- Alternativamente:
- Implante apenas um nó do HGS. Apesar de o HGS instalar um cluster de failover, não é necessário adicionar nós extra se a alta disponibilidade do sistema não for uma preocupação.
- Use o modo host key em vez do modo TPM para uma experiência de configuração mais simples.
- Virtualize o HGS e/ou o SQL Server para poupar recursos físicos.
- Execute SSMS ou outras ferramentas para configurar o Always Encrypted com enclaves seguros no mesmo computador do SQL Server. Isto deixa as chaves mestras das colunas no mesmo computador que o SQL Server, por isso não faças isto num ambiente de produção.