Guia de expiração de certificados da Inicialização segura da Microsoft

Como vários certificados de inicialização segura da Microsoft expiram em 2026, este documento fornece orientações sobre como atualizar as instâncias de VM protegida do Compute Engine para confiar nos certificados atualizados de inicialização segura da Microsoft para inicialização segura da UEFI (Unified Extensible Firmware Interface). Os dois certificados mais críticos que estão perto de expirar são a CA UEFI 2011 da Microsoft Corporation (expira em 27 de junho de 2026), que assina carregadores de inicialização de terceiros, como o Linux Shim, e a PCA de produção do Microsoft Windows 2011, que expira em 19 de outubro de 2026 e assina o carregador de inicialização do Windows.

A inicialização segura do UEFI é um padrão de segurança usado pelas VMs protegidas para garantir que apenas softwares e firmwares confiáveis sejam executados durante o processo de inicialização da VM. Para oferecer suporte à inicialização segura em vários sistemas operacionais, a Microsoft gerencia certificados UEFI, armazenando-os nas variáveis Key Exchange Key (KEK) e Allowed Signature Database (db) no firmware da instância.

Certificados de inicialização segura e datas de validade

Nome do certificado Papel Data de validade
Microsoft Corporation UEFI CA 2011 Assina carregadores de inicialização de terceiros, como o Linux Shim 27 de junho de 2026
PCA de produção do Microsoft Windows 2011 Assina o carregador de inicialização do Windows. 19 de outubro de 2026
Microsoft Corporation KEK CA 2011 Usado para atualizar o DB e o DBX. 24 de junho de 2026

A expiração do certificado só afeta você se a instância de computação atender aos dois pré-requisitos obrigatórios a seguir:

  1. Data de criação:você criou a instância de computação antes de 7 de novembro de 2025 (quando o Compute Engine atualizou os certificados de inicialização segura padrão no firmware UEFI) e não a atualizou.
  2. Estado da Inicialização segura:você ativou a Inicialização segura na instância. Google Cloud não ativa a Inicialização segura por padrão ao criar uma instância de VM protegida.

As instâncias criadas a partir de 7 de novembro de 2025 já incluem os certificados atualizados nas variáveis de firmware, desde que usem uma imagem que dependa do conjunto de certificados padrão.

Se a instância não atender aos dois pré-requisitos, a expiração do certificado não vai afetá-la, e você não precisará fazer nada.

Este documento explica como identificar as instâncias afetadas e fazer as atualizações necessárias.

Google Cloud concluiu o lançamento dos novos certificados em 7 de novembro de 2025. As instâncias criadas nessa data ou depois dela com base em imagens que dependem do conjunto padrão de certificados incluem os certificados atualizados nas variáveis de NVRAM/firmware (db e KEK) e não exigem mais ações. No entanto, algumas instâncias criadas nas semanas anteriores a essa data também podem incluir os novos certificados. Para verificar se o sistema está atualizado, use os comandos na seção Verificação deste documento.

Observação:o vencimento do certificado de Inicialização segura não afeta o seguinte:

  • Instâncias que não têm a Inicialização segura ativada. Observe que, se você usar registros de configuração da plataforma vTPM (especificamente PCR7) para lacre de secret, qualquer atualização nas variáveis UEFI ou recriação da instância ainda vai alterar as medições de PCR7, mesmo com a inicialização segura desativada. No entanto, essas configurações são muito raras.
  • Instâncias que executam o Container-Optimized OS (COS).
  • Instâncias em que você fornece sua própria chave de plataforma de inicialização segura (PK) ou chave de registro de chaves (KEK).

Para instâncias de computação criadas antes de 7 de novembro de 2025 que não têm os certificados atualizados, siga o guia de atualização de KEK e banco de dados para atualizar os certificados. Se, por qualquer motivo, isso não for possível, considere recriar as instâncias.

Como o vencimento do certificado de inicialização segura afeta a VM protegida

Se ativada, a VM protegida vai aplicar a inicialização segura usando o firmware UEFI, que mantém um conjunto de certificados confiáveis (na variável db) para verificar as assinaturas dos binários da sequência de inicialização. Por exemplo, se uma atualização do SO substituir um carregador de inicialização por um assinado apenas pela CA UEFI da Microsoft 2023, e o firmware da instância de computação não confiar na autoridade desse certificado, a verificação da inicialização segura vai falhar, e a inicialização segura vai interromper o processo de inicialização.

Para mais detalhes sobre essa transição, consulte as orientações da Microsoft e de outros fornecedores de SO:

Impacto no sistema operacional

Se você ativou a Inicialização segura em uma instância de VM protegida criada antes de 7 de novembro de 2025, recomendamos que você verifique se os certificados de 2023 estão instalados. Caso contrário, a instância de computação terá problemas de inicialização se você aplicar uma atualização que contenha um carregador de inicialização assinado apenas pelo certificado da CA UEFI da Microsoft de 2023 (e não com assinatura dupla com o certificado de 2011). Se você não fizer nada, talvez não seja possível aplicar atualizações futuras do carregador de inicialização ou do kernel que contenham binários assinados apenas com o certificado de 2023. Como os fornecedores de SO planejam assinar duas vezes o carregador de inicialização e as atualizações de shim com os certificados de 2011 e 2023 no futuro próximo, não é esperado que falhas de inicialização ou bloqueios de atualização ocorram imediatamente. Para instâncias de computação criadas antes de 7 de novembro de 2025: os clientes do Windows podem encontrar o ID do evento 1801 ("É necessário atualizar a AC/chaves de inicialização segura") no log de eventos do sistema se não tiverem aplicado as atualizações de certificado.

  • Imagens públicas fornecidas pelo Google:atualize os certificados de banco de dados e KEK seguindo o guia de atualização de KEK e banco de dados. Como alternativa, considere recriar todas as VMs de longa duração criadas antes de 7 de novembro de 2025.

  • Imagens personalizadas ou importadas:a grande maioria das imagens personalizadas ou importadas depende de certificados de inicialização segura padrão. Se você não substituiu explicitamente as variáveis de inicialização segura db ou KEK ao criar a imagem, ela usa o conjunto de chaves padrão e não requer nenhuma ação no nível da imagem. O Compute Engine fornece automaticamente os certificados atualizados quando você cria uma instância de qualquer imagem que dependa desses padrões.

    Você só precisa Entre em ação se tiver definido explicitamente variáveis personalizadas de db ou KEK Inicialização segura (por exemplo, para incluir um certificado de um fornecedor de segurança terceirizado junto com os certificados padrão da Microsoft) nos metadados da imagem durante o processo de build da imagem. Como especificar uma variável db ou KEK personalizada substitui completamente os padrões (e o sistema ignora as chaves públicas padrão), suas variáveis personalizadas podem não ter os certificados "Microsoft UEFI CA 2023" ou KEK de 2023 atualizados. Se a configuração da sua imagem personalizada excluir esses certificados atualizados, recrie ou atualize a imagem protegida para incluí-los. Para instruções, consulte Como criar imagens personalizadas de VMs protegidas.

Se você tiver instâncias de computação criadas antes de 7 de novembro de 2025 com a inicialização segura ativada, revise os requisitos, as limitações e os fatores complicadores a seguir antes de planejar o caminho de atualização:

  • Requisitos antes da atualização:
    • Verifique o acesso à chave de recuperação:se as instâncias usarem FDE (incluindo BitLocker no Windows ou LUKS no Linux), verifique se você tem acesso às chaves de recuperação antes de atualizar os certificados ou recriar as instâncias. A modificação das variáveis da UEFI altera as medições de inicialização e aciona solicitações de recuperação.
    • Gerenciar segredos do vTPM:se as instâncias usarem registros de configuração da plataforma vTPM (especificamente PCR7) para lacre de segredos, será necessário remover o lacre ou fazer backup desses segredos antes da atualização para evitar a perda permanente do acesso.
  • Fatores e limites complicadores:
    • Requisito de ordem de atualização:para evitar falhas na verificação da CA e loops de inicialização do sistema, instale os novos certificados db e KEK antes de aplicar novas atualizações de kernel ou shim.
    • Rollbacks de firmware:restaurar uma instância para uma imagem de máquina legada capturada antes de 7 de novembro de 2025 restaura o firmware antigo e remove a confiança nos certificados de 2023. Se você reverter, precisará reaplicar as atualizações de certificado.

Para conferir um detalhamento dos cronogramas, das etapas de auditoria e dos processos de migração, consulte as instruções a seguir.

Impacto em configurações específicas de convidados

Entenda como o vencimento do certificado afeta cada configuração somente se a instância atender aos dois pré-requisitos obrigatórios (ela foi criada antes de 7 de novembro de 2025 e tem a Inicialização segura ativada):

  • Proteção de segredos de PCR do vTPM:
    • Quando isso se torna um fator:quando você usa registros de configuração da plataforma vTPM (especificamente PCR7) para lacrar secrets, como chaves de descriptografia.
    • Impacto:a atualização dos certificados de inicialização segura (usando o guia de atualização de KEK e db ou recriando a instância de um snapshot de disco) modifica as variáveis da UEFI, mudando o valor de medição PCR7 na próxima inicialização. Essa mudança impede que o SO ou os aplicativos convidados desencriptem ou descriptografem esses segredos, a menos que você primeiro desencripte ou faça backup deles antes da atualização e depois os encripte novamente com o novo valor PCR7.
    • Quando não afetado:se você criou a VM em 7 de novembro de 2025 ou depois dessa data, usando uma imagem que depende dos certificados padrão, não é necessário atualizar os certificados. O PCR7 permanece inalterado, e o isolamento de secrets funciona normalmente.
  • Instâncias de computação do Windows que usam o BitLocker ou o modo seguro virtual (VSM):
    • Quando isso se torna um fator:quando as VMs do Windows usam a criptografia de disco completo do BitLocker ou o VSM, que confiam na Inicialização segura do UEFI e no PCR7 para proteger as chaves de criptografia.
    • Impacto:modificar os certificados de inicialização segura da UEFI ou recriar a instância de um snapshot muda as medições de inicialização PCR7. Na reinicialização subsequente, o BitLocker detecta a mudança de configuração, não libera automaticamente a chave e inicializa uma tela de recuperação do BitLocker solicitando a chave de recuperação.
    • Remediação:verifique se você tem as chaves de recuperação do BitLocker disponíveis antes de atualizar os certificados ou migrar as instâncias. Depois, siga as orientações em Atualizar o banco de dados e a KEK no Windows.
    • Quando não afetado:o vencimento do certificado não afeta instâncias do Windows sem o BitLocker ou o VSM ativados, nem aquelas sem a inicialização segura ativada.
  • VMs do Linux usando FDE:
    • Quando isso se torna um fator:quando as instâncias do Linux usam FDE, como LUKS, em que você sela as chaves de descriptografia para PCRs de vTPM (especificamente PCR7).
    • Impacto:a atualização dos certificados de Inicialização Segura ou a recriação da VM altera PCR7, impedindo a descriptografia automática do volume de inicialização. O sistema para durante a inicialização e pede uma senha longa de descriptografia.
    • Remediação:confirme se você tem as chaves ou frases de recuperação antes de executar as atualizações. Desvincule ou desproteja as chaves LUKS do TPM antes da atualização e vincule ou proteja novamente com o novo valor PCR7 depois de concluir a atualização.
    • Quando não há impacto:o vencimento do certificado não afeta as VMs do Linux que não usam FDE ou descriptografia LUKS selada por vTPM, nem aquelas que não têm a Inicialização segura ativada.
  • Instâncias que reverter para uma imagem de máquina anterior a novembro de 2025:
    • Quando isso se torna um fator:quando você restaura ou reverter uma VM para uma imagem de máquina capturada antes de 7 de novembro de 2025 com a inicialização segura ativada.
    • Impacto:a instância revertida restaura a configuração e o armazenamento de certificados do firmware UEFI mais antigo, que não tem os certificados de 2023. Isso torna a instância vulnerável a falhas de inicialização futuras após atualizações subsequentes do carregador de inicialização, exigindo que você reaplique as atualizações de certificado.
    • Quando não afetado:a reversão para uma imagem de máquina não afeta a instância se você desativar a inicialização segura ou se tiver criado a imagem de máquina em ou após 7 de novembro de 2025, com base em uma imagem que usa os certificados padrão.

Identificar as instâncias de computação afetadas e planejar a atualização

Ao longo de 2026, recomendamos que você identifique as instâncias de computação afetadas e siga estas etapas para se preparar para a atualização:

  1. Identificar instâncias:use o comando gcloud compute instances list para identificar instâncias com a inicialização segura ativada e que foram criadas antes da data limite:

    gcloud compute instances list \
--filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
--format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"

  2. Verifique se há variáveis personalizadas (opcional): se você usa imagens personalizadas ou importadas, verifique se elas definem explicitamente variáveis personalizadas de db ou KEK da Inicialização segura (que substituem completamente os padrões). Se eles usarem certificados padrão, não será necessário fazer nada no nível da imagem:

    • Para verificar uma instância de VM, execute:

      gcloud compute instances describe INSTANCE_NAME \
    --zone=ZONE \
    --format="yaml(shieldedInstanceInitialState)"

    • Para verificar uma imagem de disco de origem, execute:

      gcloud compute images describe IMAGE_NAME \
    --format="yaml(shieldedInstanceInitialState)"

    Se a saída estiver vazia ou retornar null, a instância ou imagem usará os certificados padrão e não exigirá nenhuma ação no nível da imagem.

  3. Garanta a integridade dos dados:faça backups de dados recentes e tenha acesso às chaves de recuperação do FDE ou do BitLocker antes de fazer qualquer mudança.

  4. Atualizar certificados:siga o guia de atualização de KEK e banco de dados para atualizar os certificados de banco de dados e KEK. Como alternativa, migre para uma instância de computação criada a partir de 7 de novembro de 2025, que inclui os certificados de 2023 (desde que a nova instância use uma imagem que dependa dos certificados padrão). Para isso, siga as instruções em Recriar uma instância de computação de um snapshot de disco.

Recriar uma instância de computação com base em um snapshot de disco

Quando você faz um snapshot de disco e cria uma nova instância com base nele, a nova instância de computação herda um estado de firmware (vTPM/NVRAM) novo que confia nos padrões atualizados e limpa os certificados antigos.

Antes de recriar uma instância de computação de um snapshot, verifique se o SO convidado tem todas as atualizações necessárias instaladas (como KBs relevantes da Microsoft para Windows ou o Shim mais recente para distribuições Linux) para confiar nos certificados de 2023.

Você pode usar a seguinte sequência de comandos gcloud para gerenciar essa migração:

  1. Identifique o disco de inicialização:determine o nome do disco de inicialização anexado à instância de computação de origem:

    SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
    --zone=ZONE \
    --format="value(disks[0].source.basename())")

  2. Crie um snapshot do disco:tire um snapshot do disco de inicialização. Para ter a melhor integridade de dados, interrompa a instância de computação antes de executar este comando:

    gcloud compute disks snapshot $SOURCE_DISK \
    --snapshot-names="migration-snapshot-$(date +%s)" \
    --zone=ZONE \
    --storage-location=REGION

  3. Crie uma nova instância de computação:provisione uma nova instância de computação usando o snapshot como origem de inicialização. Se a Inicialização segura estiver ativada na instância de origem, inclua a flag --shielded-secure-boot para ativar a Inicialização segura na nova instância.

    gcloud compute instances create NEW_INSTANCE_NAME \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE \
    --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
    --shielded-secure-boot

Observação:as instâncias provisionadas usando essa abordagem recebem novos endereços IP internos e externos, a menos que sejam alocados de forma estática e reatribuídos especificamente. Metadados, tags e contas de serviço no nível da instância não são replicados automaticamente e precisam ser configurados explicitamente durante a recriação.

Verificação

Depois de atualizar o firmware e o SO das instâncias de computação, você pode verificar se os certificados de 2023 estão presentes. Se as variáveis KEK e db mostrarem que os certificados de 2023 estão presentes, sua instância estará atualizada e nenhuma outra ação será necessária.

Linux

Para verificar os bancos de dados de assinatura no Linux, use o comando efi-readvar do pacote efitools ou (em distribuições em que efitools não está disponível, como RHEL 8/9) use mokutil.

Método 1: usar efi-readvar

  1. Se efi-readvar não estiver presente, instale o pacote efitools. Para instalar no Linux, execute o comando da sua distribuição:

    Debian/Ubuntu

    sudo apt update && sudo apt install efitools

    RHEL/CentOS/Fedora (somente Fedora; efitools não está disponível nos repositórios RHEL/CentOS)

    sudo yum install efitools

    SLES

    sudo zypper install efitools

  2. Verifique os certificados nas variáveis KEK e db:

    sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v db | grep "UEFI CA 2023"

Método 2: usar mokutil

Em distribuições como o Red Hat Enterprise Linux (RHEL), em que o efitools não está disponível, use o utilitário mokutil, que é instalado por padrão:

sudo mokutil --kek | grep "KEK 2K CA 2023"
sudo mokutil --db | grep "UEFI CA 2023"

Windows (PowerShell)

Execute o seguinte em um prompt do PowerShell de administrador. Cada comando precisa retornar True.

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

Solução de problemas

Se uma instância não for inicializada devido a um erro de Inicialização segura após junho de 2026, tente uma das seguintes opções para recuperá-la:

  • Desative temporariamente a Inicialização segura:isso permite inicializar a instância para aplicar atualizações.

    Observação:desativar a Inicialização segura muda os valores de PCR, especificamente PCR7, o que pode afetar a funcionalidade de lacre secreto ou criptografia de disco.

    Para desativar a inicialização segura, execute o seguinte comando:

    gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot

    Depois de aplicar as atualizações necessárias ao carregador de inicialização/shim, reative a Inicialização segura:

    gcloud compute instances update INSTANCE_NAME --shielded-secure-boot

  • Restaurar de um backup:restaure a instância de uma imagem de máquina criada antes do início dos problemas de inicialização.

  • Recriar a instância:recrie a instância e recupere os dados de um snapshot.

Se você continuar tendo problemas ou precisar de ajuda, entre em contato com o Cloud Customer Care.

Perguntas frequentes

Esta seção fornece respostas a perguntas comuns sobre o vencimento do certificado do Microsoft Secure Boot.

Quando os certificados de inicialização segura expiram?

Os certificados de inicialização segura da Microsoft vão expirar em 2026. Especificamente:

  • Os dois certificados mais críticos que estão chegando ao fim da vida útil são a CA UEFI da Microsoft Corporation 2011 (expira em junho de 2026), que assina carregadores de inicialização de terceiros, como o Linux Shim, e a PCA de produção do Microsoft Windows 2011, que expira em outubro de 2026 e assina o carregador de inicialização do Windows.

Quem é afetado pela expiração do certificado?

A expiração do certificado só afeta você se a instância de computação atender aos dois pré-requisitos obrigatórios a seguir:

  1. Você criou a instância antes de 7 de novembro de 2025, quando o Compute Engine atualizou os certificados padrão de inicialização segura no firmware UEFI, e não a atualizou.
  2. Você ativou a Inicialização segura na instância.

As instâncias criadas em 7 de novembro de 2025 ou depois não serão afetadas, desde que sejam criadas com base em uma imagem que dependa do conjunto de certificados padrão.

Se a instância atender aos dois pré-requisitos, a expiração do certificado afetará as seguintes configurações em circunstâncias específicas:

  • Lacre de secret de PCR do vTPM:se a instância usa registros de configuração da plataforma (PCRs) do módulo de plataforma confiável virtual (vTPM), especificamente PCR7, para lacrar chaves de criptografia ou secrets.
  • Windows BitLocker / VSM:se a instância do Windows usar a criptografia de disco do BitLocker ou o modo seguro virtual (VSM) com a Inicialização segura.
  • FDE do Linux:se a instância do Linux usar FDE que você lacra em PCRs do vTPM (especificamente PCR7).
  • Reverter instâncias:se você restaurar ou reverter a VM para uma imagem de máquina criada antes de 7 de novembro de 2025.

Para um detalhamento detalhado do impacto e das etapas de correção de cada uma dessas configurações, consulte Impacto em configurações específicas de convidados.

Quem não será afetado pela expiração do certificado?

A expiração do certificado não afeta você se alguma das seguintes condições for verdadeira:

  • A Inicialização segura está desativada:se a Inicialização segura não estiver ativada na instância de VM protegida, ela não vai validar nem usar os certificados UEFI que estão expirando. A inicialização segura está desativada por padrão. No entanto, observe que se você usar registros de configuração da plataforma vTPM (especificamente PCR7) para lacre de Secret, qualquer atualização nas variáveis UEFI ou recriação da instância ainda vai alterar as medições de PCR7, mesmo com a inicialização segura desativada. No entanto, essas configurações são muito raras.
  • Criada em ou após 7 de novembro de 2025:você criou a instância nessa data ou depois dela. Portanto, o firmware já inclui os certificados atualizados de 2023, desde que você tenha criado a instância com base em uma imagem que usa o conjunto de certificados padrão.
  • Execução do Container-Optimized OS (COS): essas atualizações de certificado não afetam os ambientes do COS.
  • Variáveis personalizadas de PK, KEK ou db:se você definir e gerenciar explicitamente suas próprias variáveis personalizadas de inicialização segura PK, KEK ou db sem depender dos certificados padrão da Microsoft UEFI, o vencimento dos certificados padrão não vai afetar você. No entanto, você é responsável por atualizar e manter seus próprios certificados.

O que acontece se eu não fizer nada?

Se você não fizer nada, a instância vai continuar sendo inicializada e operando normalmente com os binários atuais. No entanto, talvez não seja possível aplicar futuras atualizações do carregador de inicialização ou do kernel que contenham binários assinados apenas com o certificado de 2023. Note que, como os fornecedores de SO fazem a assinatura dupla do carregador de inicialização e das atualizações de shim com os certificados de 2011 e 2023, não é esperado que falhas de inicialização ou bloqueios de atualização ocorram imediatamente.

Se eu não atualizar os certificados, as instâncias do Windows não vão inicializar?

Não. A falha na correção não impede a inicialização do sistema Windows. No entanto, talvez você veja o ID do evento 1801 ("É necessário atualizar a CA/chaves de inicialização segura") no log de eventos do sistema, e não será possível aplicar novas atualizações de segurança do kernel ou do carregador de inicialização que contenham binários assinados apenas com o novo certificado de 2023.

Quais condições específicas causam falhas de inicialização no Linux?

Uma falha de inicialização pode ocorrer no Linux em condições específicas:

  • A instância tem a Inicialização segura ativada.
  • A variável UEFI db não é atualizada para confiar no certificado "Microsoft UEFI CA 2023".
  • O SO atualiza um carregador de inicialização (ou shim) que depende estritamente desse certificado e não tem assinatura dupla com o certificado de 2011.

Se você não aplicar atualizações de certificado ou de shim que referenciam os novos certificados, sua instância do Linux vai continuar sendo inicializada com sucesso.

Como posso determinar se minha instância tem os certificados atualizados?

Para determinar se a instância inclui os novos certificados no firmware, consulte os comandos descritos na seção Verificação. Se os certificados estiverem faltando, atualize-os seguindo o guia de atualização do KEK e do banco de dados ou recrie a instância.

A reinicialização de uma instância afetada resolve o problema?

Não. Reiniciar ou rebootar uma instância de computação não atualiza os certificados de inicialização segura, mas a instância continua sendo inicializada e operando normalmente com os certificados atuais até que uma atualização do carregador de inicialização ou do kernel seja aplicada com binários assinados apenas com o certificado de 2023. Se você reiniciar a instância de computação, ela vai manter os certificados antigos se tiver sido criada antes de 7 de novembro de 2025. Os certificados fazem parte do firmware da instância (vTPM/NVRAM). Portanto, siga o guia de atualização de KEK e banco de dados ou recrie a instância para aplicar os novos certificados.

Como devo me preparar para o vencimento do certificado?

Para se preparar, siga estas etapas:

  • Identifique:faça uma auditoria do uso de VMs protegidas, inicialização segura, FDE, BitLocker ou qualquer software que dependa de PCRs do vTPM.
  • Chaves de recuperação e backups:verifique se as chaves de recuperação (para FDE/BitLocker) e os backups de dados mais recentes estão disponíveis.
  • Gerenciar imagens:identifique imagens personalizadas legadas e descontinue o uso delas ou garanta que elas incluam os novos certificados.
  • Atualizar ou migrar:se você quiser atualizar certificados, consulte o guia de atualização de KEK e banco de dados. Como alternativa, considere recriar todas as instâncias de computação de longa duração criadas antes de 7 de novembro de 2025, já que as novas instâncias já incluem os certificados necessários (desde que você crie a nova instância com base em uma imagem que dependa dos certificados padrão).

Os snapshots de disco padrão oferecem o método mais confiável. Um snapshot é uma cópia no nível do bloco do disco e não contém variáveis UEFI nem metadados no nível da instância. Para restaurar usando um snapshot, faça o seguinte:

  1. Crie um snapshot do disco de inicialização da instância.
  2. Crie uma instância de computação e selecione o snapshot como origem do disco de inicialização.

Não use imagens de máquina, clonagem de instâncias ou o serviço de Backup e DR para essa migração, porque eles replicam o firmware da instância e retêm os certificados antigos de qualquer instância de computação de origem criada antes de 7 de novembro de 2025.

O que devo fazer se meu sistema parar de inicializar após junho de 2026?

Se você acredita que esse problema causou uma falha na inicialização, consulte Solução de problemas.

Como o Google Cloud está lidando com a expiração dos certificados de inicialização segura da Microsoft?

Google Cloud incluiu automaticamente os novos certificados para instâncias de computação criadas após 7 de novembro de 2025. Apenas os clientes que quiserem manter as instâncias de computação em execução antes de 7 de novembro de 2025 precisarão aplicar uma atualização futura. No entanto, recomendamos migrar para uma instância criada a partir de 7 de novembro de 2025 (usando certificados padrão).

A seguir