Partilhar via

Registar computador com o Serviço Host Guardian

  • Artigo

Aplica-se a: SQL Server 2019 (15.x) e posterior - apenas Windows

Este artigo descreve como registrar computadores SQL Server para atestar com o Host Guardian Service (HGS).

Observação

O processo de registro de um SQL Server com HGS requer um esforço conjunto do administrador do HGS e do administrador do computador do SQL Server. Consulte Funções e responsabilidades ao configurar a atestação com o HGS.

Antes de começar, certifique-se de que implantou pelo menos um computador HGS e configurou o serviço de certificação HGS. Para obter mais informações, consulte implantar o serviço Host Guardian para SQL Server.

Etapa 1: Instalar os componentes do cliente de atestado

Observação

Esta etapa deve ser executada pelo administrador do computador do SQL Server.

Para permitir que um cliente SQL verifique se está falando com um computador SQL Server confiável, o computador SQL Server deve atestar com êxito com o Serviço Guardião do Host. O processo de certificação é gerenciado por um componente opcional do Windows chamado Cliente HGS. Os passos abaixo irão ajudá-lo a instalar este componente e começar a atestar.

  1. Verifique se o computador do SQL Server atende aos pré-requisitos descritos no documento de planejamento do HGS.

  2. Execute o seguinte comando em um console do PowerShell com privilégios elevados para instalar o recurso Host Guardian Hyper-V Support, que contém o Cliente HGS e os componentes de atestado.

    Enable-WindowsOptionalFeature -Online -FeatureName HostGuardian -All

  3. Reinicie para concluir a instalação.

Etapa 2: Verificar se a segurança baseada em virtualização está em execução

Observação

Esta etapa deve ser executada pelo administrador do computador do SQL Server.

Quando você instala o recurso Host Guardian Hyper-V Support, a segurança baseada em virtualização (VBS) é configurada e habilitada automaticamente. Os enclaves para SQL Server Always Encrypted são protegidos e executados dentro do ambiente VBS. VBS pode não iniciar se o computador não tiver um dispositivo IOMMU instalado e habilitado. Para verificar se o VBS está em execução, abra a ferramenta Informações do Sistema executando msinfo32.exe e localize os itens Virtualization-based security na parte inferior do Resumo do Sistema.

captura de ecrã das Informações do Sistema mostrando o estado e a configuração de segurança baseada em virtualização

O primeiro item a verificar é Virtualization-based security, que pode ter os seguintes três valores:

  • Running significa que o VBS está configurado corretamente e foi capaz de iniciar com êxito. Se o computador mostrar este estado, pode saltar para o Passo 3.
  • Enabled but not running significa que o VBS está configurado para ser executado, mas o hardware não tem os requisitos mínimos de segurança para executar o VBS. Pode ser necessário alterar a configuração do hardware no BIOS ou UEFI para habilitar recursos opcionais do processador, como uma IOMMU ou, se o hardware realmente não suportar os recursos necessários, talvez seja necessário reduzir os requisitos de segurança do VBS. Continue lendo esta seção para saber mais.
  • Not enabled significa que o VBS não está configurado para ser executado. O recurso Host Guardian Hyper-V Support habilita automaticamente o VBS, portanto, é recomendável repetir a etapa 1 se vir esse status.

Se o VBS não estiver em execução no computador, verifique as propriedades de Virtualization-based security. Compare os valores no item Required Security Properties com os valores no item Available Security Properties. As propriedades necessárias devem ser iguais ou um subconjunto das propriedades de segurança disponíveis para que o VBS seja executado.

No contexto da certificação de enclaves do SQL Server, as propriedades de segurança têm a seguinte importância:

  • Base virtualization support é sempre necessário, pois representa os recursos mínimos de hardware necessários para executar um hipervisor.
  • Secure Boot é recomendado, mas não necessário para o SQL Server Always Encrypted. A Inicialização Segura protege contra rootkits exigindo que um carregador de inicialização assinado pela Microsoft seja executado imediatamente após a conclusão da inicialização UEFI. Se você estiver usando o certificado TPM (Trusted Platform Module), a ativação da Inicialização Segura será medida e imposta, independentemente de o VBS estar configurado para exigir a Inicialização Segura.
  • DMA Protection é recomendado, mas não necessário para o SQL Server Always Encrypted. A proteção DMA usa uma IOMMU para proteger o VBS e a memória do enclave contra ataques diretos de acesso à memória. Em um ambiente de produção, você deve sempre usar computadores com proteção DMA. Em um ambiente de desenvolvimento/teste, não há problema em remover o requisito de proteção DMA. Se a instância do SQL Server for virtualizada, você provavelmente não terá proteção DMA disponível e precisará remover o requisito para que o VBS seja executado. Analise o modelo de confiança para obter informações sobre as garantias de segurança reduzidas ao executar em uma VM.

Antes de reduzir os recursos de segurança necessários do VBS, verifique com seu OEM ou provedor de serviços de nuvem para confirmar se há uma maneira de habilitar os requisitos de plataforma ausentes no UEFI ou BIOS (por exemplo, habilitando a Inicialização Segura, Intel VT-d ou AMD IOV).

Para alterar os recursos de segurança de plataforma necessários para o VBS, execute o seguinte comando em um console do PowerShell elevado:

# Value 0 = No security features required
# Value 1 = Only Secure Boot is required
# Value 2 = Only DMA protection is required (default configuration)
# Value 3 = Both Secure Boot and DMA protection are required
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name RequirePlatformSecurityFeatures -Value 0

Depois de alterar o registro, reinicie o computador do SQL Server e verifique se o VBS está sendo executado novamente.

Se o computador for gerenciado pela sua empresa, a Diretiva de Grupo ou o Microsoft Endpoint Manager poderá substituir quaisquer alterações feitas nessas chaves do Registro após a reinicialização. Entre em contato com o suporte técnico de TI para ver se eles implantam políticas que gerenciam sua configuração do VBS.

Etapa 3: Configurar a URL de atestado

Observação

Esta etapa deve ser executada pelo administrador do computador do SQL Server.

Em seguida, você configurará o computador SQL Server com a URL para o serviço de atestado HGS que você obteve do administrador do HGS.

Em um console do PowerShell com privilégios elevados, atualize e execute o seguinte comando para configurar a URL de atestação.

  • Substitua hgs.bastion.local pelo nome do cluster HGS
  • Você pode executar Get-HgsServer em qualquer computador HGS para obter o nome do cluster
  • O URL do atestado deve sempre terminar com /Attestation
  • O SQL Server não aproveita os principais recursos de proteção do HGS, portanto, forneça qualquer URL fictício, como http://localhost para -KeyProtectionServerUrl
Set-HgsClientConfiguration -AttestationServerUrl "https://hgs.bastion.local/Attestation" -KeyProtectionServerUrl "http://localhost"

A menos que você tenha registrado essa máquina no HGS antes, o comando relata uma falha de atestado. Este resultado é normal.

O campo AttestationMode na saída do cmdlet indica qual modo de atestado o HGS usa.

Prossiga para Etapa 4A para registrar o computador no modo TPM ou para Etapa 4B para registrar o computador no modo de chave de anfitrião.

Etapa 4A: Registrar um computador no modo TPM

Observação

Esta etapa é executada em conjunto pelo administrador do computador do SQL Server e pelo administrador do HGS. Consulte as notas abaixo para obter detalhes.

Preparação

Observação

Essa ação deve ser executada pelo administrador do computador do SQL Server.

Nesta etapa, você coleta informações sobre o estado TPM do computador e as registra no HGS.

Se o serviço de atestado HGS estiver configurado para usar o modo de chave do host, pule para Etapa 4B em vez disso.

Antes de começar a recolher medições do TPM, assegure-se de estar a trabalhar numa configuração conhecida e estável do computador do SQL Server. O computador deve ter todo o hardware necessário instalado e as atualizações de firmware e software mais recentes aplicadas. O HGS mede os computadores em relação a essa linha de base quando eles atestam, por isso é importante estar no estado mais seguro e pretendido possível ao coletar as medições do TPM.

Há três arquivos de dados coletados para o certificado TPM, alguns dos quais podem ser reutilizados se você tiver computadores configurados de forma idêntica.

Artefacto de atestação O que mede Singularidade
Identificador da plataforma A chave de endosso pública no TPM do computador e o certificado de chave de endosso do fabricante do TPM. 1 para cada computador
Linha de base do TPM Os registos de controlo da plataforma (PCRs) no TPM medem o firmware e a configuração do SO carregados durante o processo de arranque. Os exemplos incluem o estado de Inicialização Segura e se os registos de falhas são criptografados. Uma linha de base por configuração exclusiva do computador (hardware e software idênticos podem usar a mesma linha de base)
Política de integridade de código A a política de de Controlo de Aplicação do Windows Defender em que confia para proteger os computadores Uma por cada política exclusiva de CI implantada nos computadores.

Você pode configurar mais de um artefato de atestado no HGS para suportar uma frota mista de hardware e software. HGS requer apenas que um computador que ateste corresponda a uma política de cada categoria de políticas. Por exemplo, se você tiver três linhas de base do TPM registradas no HGS, as medições do computador poderão corresponder a qualquer uma dessas linhas de base para atender ao requisito da política.

Configurar uma política de integridade de código

Observação

As etapas abaixo devem ser executadas pelo administrador do computador do SQL Server.

O HGS requer que cada computador que ateste no modo TPM tenha uma diretiva WDAC (Windows Defender Application Control) aplicada. As políticas de integridade de código WDAC restringem que software pode ser executado num computador, verificando cada processo que tenta executar código contra uma lista de publicadores confiáveis e hashes de ficheiros. Para o caso de uso do SQL Server, os enclaves são protegidos por segurança baseada em virtualização e não podem ser modificados a partir do sistema operacional host, portanto, o rigor da política WDAC não afeta a segurança das consultas criptografadas. Como tal, é recomendável implantar uma diretiva de modo de auditoria nos computadores SQL Server para atender ao requisito de atestado sem impor restrições adicionais ao sistema.

Se você já estiver usando uma política de integridade de código WDAC personalizada nos computadores para proteger a configuração do sistema operacional, poderá pular para Coletar informações de atestado TPM.

  1. Há políticas de exemplo pré-criadas disponíveis em todos os sistemas operacionais Windows Server 2019, Windows 10 versão 1809 e posterior. A política de AllowAll permite que qualquer software seja executado no computador sem restrições. Converta a política para uma forma binária compreendida pelo SO e HGS para usá-la. Num console elevado do PowerShell, execute os seguintes comandos para compilar a política de AllowAll:

    # We are changing the policy to disable enforcement and user mode code protection before compiling
$temppolicy = "$HOME\Desktop\allowall_edited.xml"
Copy-Item -Path "$env:SystemRoot\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" -Destination $temppolicy
Set-RuleOption -FilePath $temppolicy -Option 0 -Delete
Set-RuleOption -FilePath $temppolicy -Option 3

ConvertFrom-CIPolicy -XmlFilePath $temppolicy -BinaryFilePath "$HOME\Desktop\allowall_cipolicy.bin"

  2. Siga as orientações no guia de implantação do Controle de Aplicativo Windows Defender implantar o arquivo allowall_cipolicy.bin nos computadores SQL Server usando Diretiva de Grupo. Para computadores de grupo de trabalho, siga o mesmo processo usando o Editor de Diretiva de Grupo Local (gpedit.msc).

  3. Execute gpupdate /force nos computadores do SQL Server para configurar a nova diretiva de integridade de código e, em seguida, reinicie os computadores para aplicar a diretiva.

Recolher informações de atestação TPM

Observação

As etapas abaixo devem ser executadas pelo administrador do computador do SQL Server.

Repita as seguintes etapas para cada computador SQL Server que será atestado com HGS:

  1. Com o computador em um estado em boas condições, execute os seguintes comandos no PowerShell para coletar as informações de atestado do TPM:

    # Collects the TPM EKpub and EKcert
$name = $env:computername
$path = "$HOME\Desktop"
(Get-PlatformIdentifier -Name $name).Save("$path\$name-EK.xml")

# Collects the TPM baseline (current PCR values)
Get-HgsAttestationBaselinePolicy -Path "$path\$name.tcglog" -SkipValidation

# Collects the applied CI policy, if one exists
Copy-Item -Path "$env:SystemRoot\System32\CodeIntegrity\SIPolicy.p7b" -Destination "$path\$name-CIpolicy.bin"

  2. Partilhe os três ficheiros de certificação com o administrador do HGS.

Registrar o computador SQL Server com HGS

Observação

Este passo abaixo deve ser realizado pelo administrador do HGS.

Repita as seguintes etapas para cada computador SQL Server que será atestado com HGS:

  1. Copie os arquivos de atestado, obtidos do administrador do computador do SQL Server para o servidor HGS.

  2. No servidor HGS, execute os seguintes comandos em um console do PowerShell com privilégios elevados para registrar o computador do SQL Server:

    # TIP: REMEMBER TO CHANGE THE FILENAMES
# Registers the unique TPM with HGS (required for every computer)
Add-HgsAttestationTpmHost -Path "C:\temp\SQL01-EK.xml"

# Registers the TPM baseline (required ONCE for each unique hardware and software configuration)
Add-HgsAttestationTpmPolicy -Name "MyHWSoftwareConfig" -Path "C:\temp\SQL01.tcglog"

# Registers the CI policy (required ONCE for each unique CI policy)
Add-HgsAttestationCiPolicy -Name "AllowAll" -Path "C:\temp\SQL01-CIpolicy.bin"

    Dica

    Se encontrar um erro ao tentar registar o identificador TPM exclusivo, certifique-se de que importou os certificados intermédios e raiz do TPM no computador HGS que está a utilizar.

Além do identificador da plataforma, da linha de base do TPM e da política de integridade do código, existem políticas internas configuradas e aplicadas pelo HGS que talvez seja necessário alterar. Essas políticas internas são medidas a partir da linha de base do TPM coletada do servidor e representam várias configurações de segurança que devem ser habilitadas para proteger o computador. Se você tiver computadores que não tenham uma IOMMU presente para proteger contra ataques DMA (por exemplo, uma VM), será necessário desativar a política IOMMU.

Para desativar o requisito IOMMU, execute o seguinte comando no servidor HGS:

Disable-HgsAttestationPolicy Hgs_IommuEnabled

Observação

Se você desativar a política IOMMU, IOMMUs não serão necessárias para qualquer computador que ateste com HGS. Não é possível desativar a política IOMMU para apenas um único computador.

Você pode revisar a lista de hosts e políticas TPM registrados com os seguintes comandos do PowerShell:

Get-HgsAttestationTpmHost
Get-HgsAttestationTpmPolicy

Etapa 4B: Registrar um computador no modo de chave de host

Observação

Esta etapa é executada em conjunto pelo administrador do computador do SQL Server e pelo administrador do HGS. Consulte as notas abaixo para obter detalhes.

Esta etapa irá guiá-lo através do processo para gerar uma chave exclusiva para o host e registrá-la com HGS. Se o serviço de atestado HGS estiver configurado para usar o modo TPM, siga a orientação na Etapa 4A em vez disso.

Gerar uma chave para um computador SQL Server

Observação

Essa parte deve ser executada em conjunto pelo administrador do computador do SQL Server.

O atestado de chave do host funciona gerando um par de chaves assimétricas no computador do SQL Server e fornecendo ao HGS a metade pública dessa chave.

Repita as seguintes etapas para cada computador SQL Server que será atestado com HGS:

  1. Para gerar o par de chaves, execute o seguinte comando em um console do PowerShell elevado:

    Set-HgsClientHostKey
Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"

    Se você já criou uma chave de host e deseja gerar um novo par de chaves, use os seguintes comandos:

    Remove-HgsClientHostKey
Set-HgsClientHostKey
Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"

  2. Partilhe o ficheiro de certificado com o administrador do HGS.

Registrar o computador SQL Server com HGS

Observação

Este passo abaixo deve ser realizado pelo administrador do HGS.

Repita as seguintes etapas para cada computador SQL Server que será atestado com HGS:

  1. Copie o arquivo de certificado, obtido do administrador do computador do SQL Server, para um servidor HGS.

  2. Execute o seguinte comando em um console do PowerShell com privilégios elevados para registrar o computador do SQL Server:

    Add-HgsAttestationHostKey -Name "YourComputerName" -Path "C:\temp\yourcomputername.cer"

Passo 5: Confirme se o anfitrião pode atestar com sucesso

Observação

Esta etapa deve ser executada pelo administrador do computador do SQL Server.

Depois de registar o computador SQL Server no HGS (Etapa 4A para o modo TPM, Etapa 4B para o modo de chave do host), deve confirmar que consegue atestar com êxito.

Você pode verificar a configuração do cliente de atestado HGS e executar uma tentativa de atestado a qualquer momento com Get-HgsClientConfiguration.

A saída do comando será semelhante à abaixo:

PS C:\> Get-HgsClientConfiguration


IsHostGuarded                  : True
Mode                           : HostGuardianService
KeyProtectionServerUrl         : http://localhost
AttestationServerUrl           : http://hgs.bastion.local/Attestation
AttestationOperationMode       : HostKey
AttestationStatus              : Passed
AttestationSubstatus           : NoInformation
FallbackKeyProtectionServerUrl :
FallbackAttestationServerUrl   :
IsFallbackInUse                : False

Os dois campos mais importantes no resultado são AttestationStatus, que indica se o computador passou na atestação, e AttestationSubStatus, que explica quais políticas falharam se o computador não passou na atestação.

Os valores mais comuns que podem aparecer em AttestationStatus são explicados abaixo:

AttestationStatus Explicação
Expirado O anfitrião foi aprovado na atestação anteriormente, mas o certificado de saúde que foi emitido já expirou. Verifique se o host e o tempo do HGS estão sincronizados.
InsecureHostConfiguration O computador não atendeu a uma ou mais das diretivas de atestado configuradas no servidor HGS. Para obter mais informações, consulte AttestationSubStatus.
Não Configurado O computador não está configurado com um URL de atestado. Configurar a URL de atestado
Aprovado O computador passou na verificação e é confiável para executar enclaves no SQL Server.
TransientError A tentativa de atestado falhou devido a um erro temporário. Este erro geralmente significa que houve um problema ao entrar em contato com HGS através da rede. Verifique a conexão de rede e certifique-se de que o computador consegue resolver e encaminhar para o nome do serviço HGS.
TpmError O dispositivo TPM do computador relatou um erro durante a tentativa de atestado. Verifique os logs do TPM para obter mais informações. Limpar o TPM pode resolver o problema, mas tenha cuidado para suspender o BitLocker e outros serviços que dependem do TPM antes de limpar o TPM.
UnauthorizedHost A chave do host não é conhecida pelo HGS. Siga as instruções no Passo 4B para registar o computador no HGS.

Quando o AttestationStatus mostrar InsecureHostConfiguration, o campo AttestationSubStatus será preenchido com um ou mais nomes de política que falharam. A tabela abaixo explica os valores mais comuns e como corrigir os erros.

AttestationSubStatus O que significa e o que fazer
Política de Integridade de Código A política de integridade de código no computador não está registada no HGS ou o computador não está atualmente a utilizar uma política de integridade de código. Consulte Configurar uma política de integridade de código para obter orientações.
DumpsEnabled O computador está configurado para permitir despejos de memória para falhas, mas a política Hgs_DumpsEnabled não permite despejos. Desative despejos neste computador ou desative a diretiva Hgs_DumpsEnabled para continuar.
Arranque completo O computador saiu de um estado de suspensão ou hibernação, resultando em alterações nas medições do TPM. Reinicie o computador para gerar medições limpas do TPM.
HibernaçãoAtivado O computador está configurado para permitir a hibernação com ficheiros de hibernação não encriptados. Desative a hibernação no computador para resolver esse problema.
Política de Integridade de Código Imposta pelo Hypervisor O computador não está configurado para usar uma diretiva de integridade de código. Verifique a Diretiva de Grupo ou a Diretiva de Grupo Local > Configuração do Computador > Modelos Administrativos > Sistema > Device Guard > Ativar a Segurança Baseada em Virtualização > Proteção da Integridade do Código Baseada em Virtualização. Este item de política deve ser "Ativado sem bloqueio UEFI".
Iommu Este computador não tem um dispositivo IOMMU ativado. Se for um computador físico, ative a IOMMU no menu de configuração UEFI. Se for uma máquina virtual e uma IOMMU não estiver disponível, execute Disable-HgsAttestationPolicy Hgs_IommuEnabled no servidor HGS.
Arranque Seguro A Inicialização Segura não está habilitada neste computador. Habilite a Inicialização Segura no menu de configuração UEFI para resolver esse erro.
VirtualSecureMode A segurança baseada em virtualização não está em execução neste computador. Siga as orientações em Etapa 2: Verificar se o VBS está executado no computador.

Próximos passos