vTPM e Shielded VMs no Hyper-V: Proteger VMs na PME

Uma VM Generation 2 sem vTPM não consegue activar BitLocker com protector TPM no disco de sistema nem cumprir os requisitos do Windows 11 como convidado. É possível activar BitLocker sem TPM por GPO, com password ou chave de arranque de USB — um cenário improvável em servidores de produção, mas que não é impossível. O vTPM (virtual Trusted Platform Module) é um TPM 2.0 emulado pelo Hyper-V que o sistema convidado vê como um chip físico. Três camadas, separadas: é o BitLocker dentro do convidado que cifra os volumes, é o vTPM que guarda e protege o material criptográfico do desbloqueio, e é uma arquitectura de blindagem que protege contra os administradores da infraestrutura. Adicionar vTPM, por si só, não cifra disco nenhum, e uma VM com vTPM e protector local (encryption-supported, em terminologia Microsoft) pressupõe administradores do host de confiança — quem tem acesso de root ao host continua a conseguir capturar o estado da VM. O terceiro nível é o domínio das Shielded VMs, na secção 7. Em VMs normais, qualquer administrador do host consegue inspecionar o disco, copiar o VHDX e montá-lo noutro servidor.

⚠️ Antes de qualquer acção

Todo o procedimento deste guia — protectores, vTPM, BitLocker e blindagem — deverá primeiro ser executado num ambiente de testes. Só evolua para sistemas em produção depois de validar cada passo e o restauro completo nesse ambiente.

Este guia mostra como activar o vTPM em VMs existentes, cifrar o estado e o tráfego de migração, e apresenta a arquitectura e os principais passos do Host Guardian Service (HGS) para VMs blindadas — o procedimento completo de conversão segue o fluxo documentado e exige validação em ambiente próprio. Também cobre o Trusted Launch do Azure como alternativa para quem já migra cargas para a cloud. Os comandos são todos PowerShell e assumem um host Hyper-V standalone com Windows Server 2025, sem cluster nem System Center.

Neste artigo

1. Requisitos e Verificação Inicial no Host

O vTPM está disponível em VMs Generation 2 desde o Windows Server 2016 e mantém-se no Windows Server 2019, 2022 e 2025. O host não precisa de TPM físico para emular o chip na VM, mas a funcionalidade exige que a VM esteja desligada quando o dispositivo é adicionado. Se a VM estiver em execução, em estado guardado ou em pausa, o cmdlet falha.

Antes de tocar nas VMs, confirme a versão do host e o estado do módulo Hyper-V:

Get-ComputerInfo | Select-Object WindowsProductName, OsVersion, OsArchitecture
Get-WindowsFeature -Name Hyper-V | Select-Object Name, InstallState

Saída típica num host Windows Server 2025 com a role instalada (exemplo de saída):

WindowsProductName   OsVersion  OsArchitecture
------------------   ---------  --------------
Windows Server 2025  10.0.26100 64-bit

Name     InstallState
----     ------------
Hyper-V  Installed

Se a linha InstallState devolver Available em vez de Installed, instale a role primeiro:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

O parâmetro -IncludeManagementTools traz o módulo PowerShell do Hyper-V e o Hyper-V Manager, sem os quais os cmdlets seguintes não existem. O reinício é obrigatório na primeira instalação da role.

⚠️ Atenção

Atente que desligar VMs de produção para activar o vTPM implica uma janela de manutenção. Planeie a operação fora de horas e comunique a interrupção aos utilizadores das aplicações afectadas.

2. Passo 1 — Confirmar Geração e Estado da VM

O vTPM só existe em VMs Generation 2. Uma VM Generation 1 não pode ser convertida: a única via é criar uma VM nova em Gen 2 e migrar a carga de trabalho. Liste as VMs do host e filtre as que ainda não têm o chip virtual:

Get-VM | Select-Object Name, Generation, State, @{N='TpmEnabled';E={(Get-VMSecurity -VMName $_.Name).TpmEnabled}} | Format-Table -AutoSize

Saída típica (exemplo de saída):

Name       Generation State TpmEnabled
----       ---------- ----- ----------
SRV-AD01            2    Off       True
SRV-FS01            2 Running      False
SRV-SQL01           2    Off       True

Neste inventário de exemplo, a SRV-FS01 corre e ainda não tem vTPM, portanto é a candidata aos passos seguintes. Se alguma VM aparecer como Generation 1, o valor TpmEnabled não se aplica — anote-a para um projecto de migração separado, porque o disco e a configuração terão de ser reconstruídos em Gen 2.

3. Passo 2 — Criar o Key Protector

O key protector é o envelope criptográfico que guarda as chaves que autorizam o host a executar a VM. O vTPM de uma VM não shielded precisa de um protector local, gerado no próprio host:

# desligue por encerramento normal (na VM ou Stop-VM sem -Force) e confirme o estado Off:
( Get-VM -Name "SRV-FS01" ).State
# o -Force só em situações deliberadas — pode cortar com dados não gravados (a nota da Microsoft admite perda de dados)
Stop-VM -Name "SRV-FS01"
Set-VMKeyProtector -VMName "SRV-FS01" -NewLocalKeyProtector

Prefira o encerramento normal da VM — pela aplicação ou por um Stop-VM sem flags — e confirme o estado Off (Get-VM) antes de alterar chaves. O -Force não é encerramento limpo garantido: a nota da própria documentação do cmdlet avisa que pode cortar com dados não gravados — reserve-o às situações deliberadas. O Set-VMKeyProtector com -NewLocalKeyProtector gera e guarda o protector na configuração da VM, sem saída no ecrã.

⚠️ Atenção

O protector local vive apenas no host atual. Se o VHDX e a configuração forem copiados para outro host sem actualizar o key protector, a VM não arranca lá. Para mover VMs com vTPM entre hosts, os protetores têm de ser actualizados ou geridos por um HGS, como na secção 7.

4. Passo 3 — Activar o vTPM

Com a VM desligada e o protector criado, adicione o dispositivo TPM virtual:

Enable-VMTPM -VMName "SRV-FS01"

O cmdlet não devolve saída quando corre bem. Confirme o estado:

Get-VMSecurity -VMName "SRV-FS01" | Select-Object TpmEnabled, Shielded, EncryptStateAndVmMigrationTraffic

Saída típica (exemplo de saída):

TpmEnabled Shielded EncryptStateAndVmMigrationTraffic
---------- -------- ---------------------------------
      True    False                             False

TpmEnabled em True significa que o convidado passa a ver um TPM 2.0 completo. A coluna Shielded distingue o cenário deste guia, vTPM sem blindagem, de uma Shielded VM gerida por HGS, que verá True nas duas colunas. A partir deste momento, o sistema convidado já consegue usar BitLocker, Credential Guard e as políticas de integridade de código que dependem de TPM.

No próximo arranque, dentro da VM, o TPM aparece disponível. Verifique dentro do convidado com Get-Tpm (módulo TrustedPlatformModule) ou tpm.msc. A partir daqui, o BitLocker dentro da VM sela a chave de arranque ao vTPM, tal como faria com um TPM físico num servidor.

5. Passo 4 — Cifrar Estado e Tráfego de Migração

O BitLocker cifra os volumes dentro da VM, e o vTPM protege o material criptográfico que o protector TPM usa para os desbloquear. A cifra do estado guardado e do tráfego de live migration é uma camada separada, que impede que alguém capture a memória da VM durante uma migração ou num ficheiro de estado:

Set-VMSecurity -VMName "SRV-FS01" -EncryptStateAndVmMigrationTraffic $true
Get-VMSecurity -VMName "SRV-FS01" | Select-Object TpmEnabled, EncryptStateAndVmMigrationTraffic

Saída típica (exemplo de saída):

TpmEnabled EncryptStateAndVmMigrationTraffic
---------- ---------------------------------
      True                              True

A partir de agora, o tráfego de live migration entre hosts é cifrado e o estado guardado (saved state) também. O custo é um overhead de CPU durante migrações, irrelevante na maioria das PME com janelas de migração fora de horas.

Ligue a VM de novo:

Start-VM -Name "SRV-FS01"

O arranque deve ser normal. Se a VM arranca um SO que já tinha BitLocker activo antes do vTPM existir, é possível que o BitLocker peça a recovery key na primeira inicialização, porque o ambiente de arranque mudou. Tenha a recovery key à mão antes de desligar.

6. Passo 5 — Activar BitLocker na VM

No Windows Server, o BitLocker é um componente opcional — instale-o dentro da VM antes de qualquer cmdlet:

Install-WindowsFeature BitLocker

Dentro da VM, o BitLocker passa a ver o vTPM como protector válido. A secção do disco com BitLocker é o que garante que, mesmo que alguém copie o VHDX do host, o conteúdo está cifrado:

Enable-BitLocker -MountPoint "C:" -TpmProtector -EncryptionMethod XtsAes256 -SkipHardwareTest

# o -TpmProtector sozinho não gera recovery password — acrescente o protector de recuperação:

Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

# e consulte/imprima a chave para o destino de backup:

(Get-BitLockerVolume -MountPoint "C:").KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'

Guarde a recovery key num local seguro e separado do host. A via depende do sistema: servidores raramente são Entra-joined, e para eles o caminho habitual é o escrow por GPO no AD DS; as estações geridas por Intune fazem o backup no Entra ID. Sem nenhum dos dois, imprima a chave e guarde-a em cofre. O escrow é o depositário de confiança: o Windows envia a cópia da recovery key sozinho para o destino configurado e o admin consulta-a na ficha do device, sem ninguém a copiar à mão. O BitLocker Enterprise com Intune cobre o backup da recovery key no Entra ID em detalhe para as estações.

Para automatizar em várias VMs, repita os passos 2 a 4 em lote a partir do inventário do passo 1:

$vms = Get-VM | Where-Object { $_.Generation -eq 2 -and $_.State -eq 'Off' -and -not (Get-VMSecurity -VMName $_.Name).TpmEnabled }
foreach ($vm in $vms) {
    Set-VMKeyProtector -VMName $vm.Name -NewLocalKeyProtector
    Enable-VMTPM -VMName $vm.Name
    Set-VMSecurity -VMName $vm.Name -EncryptStateAndVmMigrationTraffic $true
}

O filtro evita reprocessar VMs ligadas e VMs com vTPM activo. Em caso de falha parcial, reveja o key protector e o estado da VM antes de repetir a execução. Revise o inventário antes: VMs Gen 1 ficam de fora por definição.

7. Passo 6 — Shielded VMs com Host Guardian Service

O BitLocker dentro do convidado — com o vTPM a proteger o material criptográfico do desbloqueio — resolve a cifra dos volumes, mas não impede um administrador do host de aceder à consola da VM, usar PowerShell Direct ou copiar o VHDX. As Shielded VMs fecham esse nível: a VM só arranca em hosts aprovados por um Host Guardian Service (HGS), a consola é bloqueada e o estado fica sempre cifrado.

Diagrama do arranque de uma shielded VM em oito passos: o utilizador pede para iniciar a VM, o host guardado pede atestação ao Host Guardian Service, o Serviço de Atestado valida o host, o Serviço de Protecção de Chaves aprova a libertação da chave, e o host desbloqueia e inicia a VM

O arranque duma shielded VM em 8 passos: atestação primeiro, chave depois — diagrama oficial Microsoft Learn

Um guarded fabric tem duas partes: o HGS, tipicamente em cluster de três nós num domínio próprio, e os guarded hosts, os hosts Hyper-V aprovados. O HGS presta dois serviços: atestação, que valida que o host é de confiança, e protecção de chaves, que só liberta as chaves de arranque para hosts aprovados.

O servidor HGS precisa de preparação própria: a role HostGuardianServiceRole, um domínio dedicado — o Install-HgsServer cria e promove o domínio HGS — e certificados reais para assinatura e cifragem. Thumbprints vazios falham:

Install-WindowsFeature HostGuardianServiceRole -IncludeManagementTools

Install-HgsServer -HgsDomainName "hgs.pme.local" -SafeModeAdministratorPassword (Read-Host -AsSecureString) -Restart

# após o reboot, inicializar com certificados reais (PKI da empresa):

Initialize-HgsServer -HgsServiceName 'HGS' -SigningCertificateThumbprint '<thumbprint>' -EncryptionCertificateThumbprint '<thumbprint>' -TrustHostKey

Numa PME, o modo mais simples de atestação é por chave de host — com uma ressalva que interessa ao modelo de ameaça: atestar por chave prova a posse de uma chave registada, enquanto o modo TPM-trusted valida ainda a identidade do TPM, as medições de arranque e as políticas de integridade de código. Host-key é aceitável quando os administradores são de confiança, mas não substitui o TPM attestation contra um host comprometido:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart
Set-HgsClientHostKey
Get-HgsClientHostKey -Path "C:\temp\$env:COMPUTERNAME-HostKey.cer"

No servidor HGS, registe a chave do host:

Add-HgsAttestationHostKey -Name "HV-HOST01" -Path "C:\temp\HV-HOST01-HostKey.cer"

De volta ao host, aponte o cliente para o HGS e verifique a atestação:

Set-HgsClientConfiguration -AttestationServerUrl 'http://hgs.pme.local/Attestation' -KeyProtectionServerUrl 'http://hgs.pme.local/KeyProtection'
Get-HgsClientConfiguration | Select-Object IsHostGuarded, AttestationStatus

Saída típica num host aprovado (exemplo de saída):

IsHostGuarded AttestationStatus
------------- -----------------
         True            Passed

Com o host aprovado, a conversão de uma VM existente para shielded não é um único cmdlet — é o fluxo documentado de blindagem de VMs existentes, com requisitos que o guia até aqui não cobre:

  • A VM tem de estar desligada — os passos anteriores deixaram-na a correr no passo 4, e o estado entra no key protector.
  • O key protector leva dois guardians: o owner, com os certificados do proprietário das VMs (e as chaves privadas dele), e o fabric, importado dos metadados públicos do HGS — esse objecto importado contém os certificados públicos, não as respectivas chaves privadas, e é por isso que não pode servir de owner. As chaves privadas dos certificados de assinatura e cifragem mantêm-se no serviço HGS, que as usa para as operações de protecção de chaves. O erro documentado — HGS cannot be an owner because it does not have private keys — refere-se ao objecto importado e não ao servidor.
  • A política em si configura-se com Set-VMSecurityPolicy -Shielded $true — o Set-VMSecurity só tem -EncryptStateAndVmMigrationTraffic e -VirtualizationBasedSecurityOptOut, sem parâmetro de blindagem.

A conversão completa (owner + fabric guardian, shielding data, pré-requisitos e recuperação) segue a documentação própria: Provision shielded VMs in VMM (Microsoft Learn) — o caminho com VMM, helper VHD e serviço de provisioning — e o Planning Guide for Tenants (Microsoft Learn). O esqueleto do procedimento no host:

# (1) no PC de gestão do proprietário das VMs — owner guardian (gera os DOIS certificados,

# de assinatura e de cifragem, e as chaves privadas ficam com o dono):

$owner = New-HgsGuardian -Name "Owner" -GenerateCertificates

# (2) fabric guardian: descarregar os metadados PÚBLICOS do HGS e importar

# (contém só a parte pública dos certificados — não serve de owner):

Invoke-WebRequest -Uri "http://hgs.pme.local/KeyProtection/service/metadata/2014-07/metadata.xml" -OutFile .\hgs-guardian.xml

$fabric = Import-HgsGuardian -Path .\hgs-guardian.xml -Name "Fabric" -AllowUntrustedRoot

# (3) key protector com os DOIS guardians, aplicar à VM DESLIGADA e só depois blindar:

$kp = New-HgsKeyProtector -Owner $owner -Guardian $fabric -AllowUntrustedRoot

Set-VMKeyProtector -VMName "SRV-FS01" -KeyProtector $kp.RawData

Set-VMSecurityPolicy -VMName "SRV-FS01" -Shielded $true

Este bloco é um esqueleto — não conclui a conversão. A blindagem de VMs existentes segue o fluxo documentado de ponta a ponta: com VMM, o caminho passa pelo helper VHD e pelo serviço de provisioning (o método PrepareSpecializedMachine); sem VMM, o proprietário prepara o shielding data (PDK) que autoriza a fabric e a VM é exportada do host original e importada num host guardado. Pré-requisitos documentados: Generation 2, Secure Boot com o template Microsoft Windows, disco GPT, VM offline e BitLocker activado antes da mudança. Enquanto esse procedimento completo não passar no vosso ambiente, trate a secção 7 como arquitectura, não como receita. Para criar Shielded VMs novas a partir de um template, o fluxo envolve disco de template cifrado, shielding data (PDK) e os cmdlets de deployment da Microsoft Learn.

⚠️ Atenção

Blinde primeiro uma VM de teste. No fluxo com HGS, uma shielded sem HGS acessível não arranca (a Microsoft documenta também blindagem local sem HGS, fora deste guia). Perder os certificados do guardian nem sempre é o fim: o guardian pode ser reconstruído a partir dos certificados adequados, e uma recovery key BitLocker válida ainda recupera os volumes mesmo sem o estado do vTPM — é exactamente o cenário em que o escrow salva o restore.

O investimento em HGS só compensa se houver mesmo um adversário interno a considerar. Para a maioria das PMEs com um único host e uma equipa de TI pequena, vTPM com protector local mais BitLocker no convidado cobre o essencial sem uma infraestrutura nova para manter.

8. Passo 7 — Trusted Launch no Azure como Caminho de Migração

Se parte das VMs vai para o Azure, o equivalente ao conjunto vTPM mais Secure Boot chama-se Trusted Launch. É uma security type das VMs Gen 2 no Azure que activa Secure Boot e vTPM por omissão. A monitorização de integridade de arranque não vem apenas de activar os dois parâmetros — exige a extensão de Guest Attestation (e o Defender for Cloud para os relatórios). A Microsoft recomenda Trusted Launch como predefinição para novas VMs.

Numa VM Gen 2 existente no Azure, o az vm create não se aplica — esse comando cria uma nova. A conversão faz-se no portal em Security type ou por CLI com desalocação, actualização e arranque. A documentação nota que não está disponível se a VM tiver backup com política Standard:

az vm deallocate -n SRV-FS01 -g rg-pme

az vm update -n SRV-FS01 -g rg-pme --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true

az vm start -n SRV-FS01 -g rg-pme
az vm create -n SRV-FS01 -g rg-pme --image Win2025Datacenter --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true

Para cargas on-premises que vão migrar com Azure Migrate, escolha o destino com security type Trusted Launch para que a VM chegue à cloud com as mesmas garantias de arranque que tinha no Hyper-V. É um caminho de migração parcial: não traz HGS para on-premises, mas alinha o nível de segurança das VMs em ambos os lados, e os procedimentos de recuperação de chave passam a ser os do Azure em vez do guardian local.

A diferença que interessa à decisão: o Trusted Launch protege contra bootkits e rootkits e permite Microsoft Defender for Cloud, mas não impede o operador da plataforma — a Microsoft ou quem gere o host físico — de aceder ao estado da VM. Proteger contra o operador é o domínio das Confidential VMs, pensadas para o adversário interno da plataforma e não para o administrador do tenant, e ficam fora do âmbito deste guia.

9. O que muda nos backups e restores

O vTPM acrescenta uma dependência nova à cadeia de backup: o estado do chip virtual vive na configuração da VM, encriptado, e não se exporta como ficheiro isolado. Cada vTPM é único e muda ao longo da vida da VM. A recomendação da Microsoft, na documentação do guarded fabric, é proteger VMs com vTPM por ferramentas que percebam que a VM é mais do que um VHDX com definições à volta — capturando configuração e estado, não só o disco. Na prática, uma solução compatível pode preservar os discos, a configuração e o estado que o vTPM precisa — cópias só do VHDX, não. O arranque após restauro depende ainda da autorização do host e da disponibilidade do material criptográfico, e confirma-se com um teste de recuperação. E o protector local depende dos certificados Shielded VM Local Certificates do host: um host reconstruído sem os mesmos certificados não consegue arrancar o restore.

Os cenários que o manual de recuperação da PME tem de cobrir:

  • Restore com a VM completa. Um teste de recuperação em que a solução preservou configuração e estado — num host autorizado — devolve o vTPM com o estado e o BitLocker desbloqueia sem recovery key. Sem esse teste, trate o resultado como por confirmar.
  • Só o VHDX sobreviveu → recovery. Recriar a VM à volta do disco arranca em BitLocker recovery e pede a chave de 48 dígitos — o cenário que o escrow no Entra ID (ou a chave no cofre, como acima) resolve.
  • Mudar de host, de fabric ou de protector. Três cenários com chaves diferentes: migração dentro da mesma fabric — o HGS autoriza o host aprovado e nenhuma chave privada de blindagem viaja com a VM; mudança de fabric — é preciso novo key protector autorizante (novo shielding data com o fabric guardian da nova fabric, ver secção 7); VM com protector local — o protector anda com a configuração e o host de destino precisa dos certificados de guardian locais para o arranque. A chave de host de attestation, que identifica o host perante o HGS, é outra peça, separada dos guardians e do key protector da VM.
  • Shielded completo. Consola e PowerShell Direct ficam desligadas — o processamento host-based dentro do convidado deixa de estar disponível. O suporte de backup depende do produto, da versão e da modalidade (captura dos discos e estado vs. consistência aplicacional vs. restauro granular): confirme com o fabricante e teste o restauro em vez de assumir que um Veeam ou Windows Server Backup genérico preserva tudo. A fabric não guarda recovery keys automaticamente — isso fica nos processos Windows normais (escrow).

O único custo permanente: um VHDX com volumes BitLocker é, para os algoritmos de deduplicação e compressão, quase aleatório. O backup destas VMs ocupa mais espaço — a cifra destrói a compressibilidade dos dados, e a duração varia com a modalidade — dimensione o repositório como se os dados fossem sempre incompressíveis.

10. Erros Comuns

Problema Causa Solução
Enable-VMTPM falha com “The virtual machine must be off” A VM está em execução, guardada ou em pausa Stop-VM com shutdown limpo, nunca “Turn Off”, e repetir o cmdlet
O cmdlet não existe no PowerShell Falta o módulo Hyper-V no host Install-WindowsFeature Hyper-V -IncludeManagementTools e reabrir a consola
A VM não arranca depois de activar o vTPM O guest tinha BitLocker activo e o ambiente de arranque mudou Introduzir a recovery key no arranque e manter o protector activo
VM com vTPM não arranca noutro host O key protector local não conhece o novo host Actualizar o key protector com os guardians de ambos os hosts, ou gerir por HGS
IsHostGuarded devolve False após configurar o cliente HGS DNS sem reencaminhamento para o domínio HGS ou chave de host não registada Correr Get-HgsTrace -RunDiagnostics no host e revalidar o registo da chave no HGS
Windows 11 guest reclama que não cumpre os requisitos VM Generation 1 ou Secure Boot desligado Recriar em Gen 2 e activar Secure Boot com o template MicrosoftWindows

11. Checklist

  • [ ] Host com Hyper-V instalado e módulo PowerShell disponível
  • [ ] Inventário de VMs feito, com lista separada de Gen 1 a migrar
  • [ ] Janela de manutenção comunicada para desligar as VMs alvo
  • [ ] Key protector local criado em cada VM antes do vTPM
  • [ ] Get-VMSecurity a devolver TpmEnabled True em cada VM processada
  • [ ] Encryption de estado e migração activada em VMs sensíveis
  • [ ] BitLocker activo no convidado com recovery key em cofre seguro
  • [ ] Plano de actualização de key protectors antes de mover VMs entre hosts
  • [ ] Avaliação feita: HGS compensa ou não para o tamanho do ambiente
  • [ ] Se HGS activo: atestação a passar em todos os guarded hosts
  • [ ] Novas VMs no Azure criadas com Trusted Launch e vTPM

Artigos Relacionados

Fontes Oficiais