Atualizações de certificados de Arranque Seguro para Linux em máquinas virtuais do Azure

Aplica-se A
Virtual Machine running Linux

Nota

  • Data de publicação original: 12 de junho de 2026
  • ID da BDC: 5103014

Nota

Neste artigo

Introdução

O Arranque Seguro é uma funcionalidade de segurança de firmware UEFI que ajuda a garantir que apenas o software fidedigno e assinado digitalmente é executado durante a sequência de arranque da VM. Os certificados de Arranque Seguro da Microsoft emitidos em 2011 começam a expirar em junho de 2026.

Para manter a proteção de Arranque Seguro e a manutenção contínua do processo de arranque antecipado, Azure Início Fidedigno em execução Linux tem de ser atualizado com certificados SECURE Boot 2023 DB e KEK em firmware UEFI virtual. Os Máquinas Virtuais confidenciais para Linux no Azure com certificados antigos têm de ser recriados.

Se uma VM continuar a depender dos certificados de 2011 após a expiração, continuará a arrancar. No entanto, deixará de receber novas proteções de segurança sob a forma de atualizações shim e certificados e revogações futuros. Os clientes com VMs que não tenham certificados atualizados devem continuar a trabalhar com os respetivos fornecedores de distribuição para atualizar os respetivos certificados mesmo após a data de expiração.

Identificar cenários que requerem ação

Reveja os seguintes cenários para determinar se é necessária uma ação:

  • Linux VMs de Lançamento Fidedigno (TVM) ou VMs Confidenciais (CVM) criadas antes de abril de 2024
  • Azure imagens da Galeria de Computação capturadas a partir de VMs mais antigas (antes de abril de 2024) Linux Trusted Launch ou Confidential VMs
  • Instantâneos ou cópias de segurança de Linux Lançamento Fidedigno ou VMs Confidenciais criadas antes de abril de 2024
  • VMs confidenciais criadas antes de abril de 2024 a partir de blobs, importadas como disco seguro.

Normalmente, o Lançamento Fidedigno e Máquinas Virtuais Confidenciais criados após abril de 2024 já incluem certificados de Arranque Seguro 2023 no firmware UEFI virtual.

Nota

Linux as VMs Confidenciais criadas antes de abril de 2024 não devem ser atualizadas manualmente, uma vez que a Encriptação de Disco Confidencial depende do valor PCR7 do vTPM, que é calculado com base nas variáveis de arranque seguro. Atualizar os certificados de arranque seguro sem garantir que a nova selagem da chave FDE fará com que a VM confidencial entre no modo de recuperação. Recomenda-se recriar essas VMs confidenciais antigas para obter os novos certificados.

Azure considerações de VMs convidadas

As atualizações de Arranque Seguro para Linux em VMs Azure envolvem dois componentes:

  • Certificados de Arranque Seguro no firmware virtual (instalados manualmente através de ferramentas fornecidas pelo SO ou automaticamente através de Atualizações de segurança)
  • Linux atualizações shim e bootloader (distribuição gerida pelo fornecedor)

As operações de atualização são iniciadas a partir do sistema operativo convidado e dependem do suporte da plataforma para aplicar atualizações autenticadas a variáveis de Arranque Seguro.

Depois de identificar os cenários aplicáveis, faça um inventário do seu ambiente para determinar quais as VMs que necessitam de atualizações.

Ações necessárias

Para todos os Azure VMs convidadas:

  • Verifique se os certificados de Arranque Seguro 2023 estão presentes no firmware UEFI virtual

Métodos de verificação

Execute estes comandos após a atualização e reinicie. Numa VM atualizada com êxito , cada comando devolve uma linha correspondente. Se um comando não devolver nenhuma saída, o certificado de 2023 correspondente não está presente e a atualização não foi aplicada. Verifique novamente os passos de atualização antes de aplicar.

As verificações DB e KEK têm de devolver uma linha. Um computador atualizado com êxito mostra o certificado 2023 DB e o certificado KEK 2023.

Utilizar o mokutil

Nota

  • mokutil --db | grep "UEFI CA 2023"
  • CN = Microsoft UEFI CA 2023
  • mokutil --kek | grep "KEK 2K CA 2023"
  • CN = Microsoft Corporation KEK 2K CA 2023

Utilizar efitools

Nota

  • efi-readvar -v db | grep "UEFI CA 2023"
  • Microsoft UEFI CA 2023
  • efi-readvar -v KEK | grep "KEK 2K CA 2023"
  • Microsoft Corporation KEK 2K CA 2023

Note

  • Se "mokutil" não estiver instalado, instale-o a partir dos repositórios padrão da sua distribuição ou utilize "efi-readvar -v db` / `efi-readvar -v KEK".
  • Para VMs Confidenciais, não execute uma atualização manual com base nesta saída— recrie a VM conforme descrito em Recomendações por Azure para VMs Confidenciais.

Linux atualização da cadeia de arranque

Após a atualização de firmware com êxito, é seguro aplicar atualizações shim dos fornecedores de distribuição Linux.

Outras considerações sobre recursos Azure

Azure recurso Criado antes de abril de 2024 Ação necessária para a TVM Ação necessária para o CVM
Cópia de segurança/instantâneo Sim VM de arranque, aplicar atualizações, recapturar Recriar o CVM, recapturar
Cópia de segurança/instantâneo Não Não é necessária nenhuma ação Não é necessária nenhuma ação
Imagem da Galeria de Computação Sim Implementar, atualizar, recapturar Recriar o CVM, recapturar
Imagem da Galeria de Computação Não Não é necessária nenhuma ação Não é necessária nenhuma ação

Monitorizar o estado da atualização

Verifique as atualizações através do SO convidado:

  • Validar o arranque com êxito após as atualizações
  • Confirme que os certificados de Arranque Seguro estão presentes no firmware

As abordagens de monitorização e validação podem variar consoante Linux distribuição e deve contactar o fornecedor de distribuição.

Para VMs de Lançamento Fidedigno:

  • Todas as atualizações têm de ser aplicadas pela ordem correta.

    Importante

    Atualize sempre o firmware de Arranque Seguro (variáveis UEFI) antes de atualizar o shim ou o bootloader.

  • Recomenda-se que reinicie primeiro a VM para se certificar de que está a executar o firmware mais recente e verificar se o arranque foi bem-sucedido.

  • Inicie atualizações a partir do sistema operativo da VM convidada Linux, sempre que necessário, de acordo com as ferramentas e orientações recomendadas do fornecedor de distribuição.

  • Se encontrar falhas de atualização da KEK ou da BD e não tiver reiniciado primeiro, reinicie a VM para se certificar de que está a executar o firmware mais recente e tente atualizar a KEK e a BD novamente.

  • Atualizar o shim antes de atualizar o firmware primeiro pode resultar numa falha de arranque.

Para VMs Confidenciais:

Implementar atualizações

As atualizações do certificado de Arranque Seguro para Linux em Azure VMs são iniciadas a partir do sistema operativo convidado. Estas atualizações diferem consoante os fornecedores de distribuição e os clientes devem consultar primeiro o fornecedor de distribuição no método recomendado.

Nota

  • Apenas os Linux fornecedores de SO que publicaram a documentação de orientação de atualização de certificados de Arranque Seguro estão listados aqui. Esta lista é atualizada à medida que os fornecedores adicionais publicam as respetivas orientações.
  • Se o fornecedor da sua distribuição não estiver listado, isso não significa que a VM não seja afetada— significa que o fornecedor ainda não publicou a documentação de orientação de atualização de KEK e DB de arranque seguro 2023. Nesse caso, contacte o fornecedor de distribuição para obter o método recomendado ou utilize um dos métodos de atualização de firmware alternativos manuais descritos abaixo.

Recomendações de fornecedores de SO Linux aprovados:

Recomendações por Azure para VMs Confidenciais:

  • O número de CVMs criados antes de abril de 2024 é muito baixo. Se a VM Confidencial for uma das poucas que não tem os novos certificados, siga os passos para recriar o CVM.

Métodos de atualização de firmware alternativos

Nota

Antes de experimentar as atualizações da variável UEFI diretamente em VMs de produção, os clientes podem utilizar o modelo de início rápido Azure para simular a VM de Início Fidedigno Linux com certificados de AC UEFI mais antigos de 2011.

Importante

Os métodos manuais de atualização de firmware nesta secção são uma alternativa emutuamente exclusivos com a metodologia recomendada do fornecedor de distribuição. Utilize o método do fornecedor do SO sempre que estiver disponível primeiro (veja Recomendações de fornecedores de SO Linux). Utilize os métodos manuais abaixo apenas quando o fornecedor não tiver publicado a documentação de orientação ou quando o fornecedor o direcionar explicitamente para. Não aplique o método do fornecedor e um método manual à mesma VM.  Só precisa de utilizar um método alternativo para atualizações (fwupd, efitools ou sbsigntools)— não é necessário executar os três.  Cada Linux distribuição empacota diferentes ferramentas e versões e através de repositórios diferentes, pelo que é importante seguir as instruções fornecidas pelo so Linux.

Nota

A disponibilidade e as versões das ferramentas diferem por distribuição e por origem de ferramentas.

Alternativa 1: Utilizar fwupd

Certifique-se de que a VM tem a versão fwupd 2.0.8 ou posterior instalada.

Para atualizar a KEK e a BD, execute estes comandos com fwupdmgr:

Nota

  • sudo fwupdmgr refresh
  • sudo fwupdmgr update

Alternativa 2: Utilizar efitools

  • Transfira pacotes de atualização DB e KEK para Azure.

    Nota

    • wget https://github.com/microsoft/secureboot_objects/raw/refs/heads/main/\
    • PostSignedObjects/Optional/DB/amd64/DBUpdate3P2023.bin
    • wget https://github.com/microsoft/secureboot_objects/raw/refs/heads/main/\
    • PostSignedObjects/KEK/Microsoft/KEKUpdate_Microsoft_PK1.bin
  • Verifique se o MD5 ou SHA1 dos binários transferidos devem corresponder exatamente ao seguinte:

    Nota

    • sha1sum *.bin
    • 87cc5bb2efe9b59c6ad9f717a78e190bf1a191e8 DBUpdate3P2023.bin
    • d9a2fa28017653c26afc3d1b5c001adae9dc16a6 KEKUpdate_Microsoft_PK1.bin
    • md5sum *.bin
    • ef9fd1874610c2077f4c2476661ea4cd DBUpdate3P2023.bin
    • 5e67b7beafac7801fd920e40e3592611 KEKUpdate_Microsoft_PK1.bin
  • Utilizar o efi-updatevar para instalar os pacotes de atualização

    Nota

    • sudo efi-updatevar -a -f DBUpdate3P2023.bin db
    • sudo efi-updatevar -a -f KEKUpdate_Microsoft_PK1.bin KEK
    • sudo reboot

Alternativa 3: Utilizar sbsigntools

  • Transfira e verifique DBUpdate3P2023.bin e KEKUpdate_Microsoft_PK1.bin , conforme descrito em "Alternativa 2: Utilizar efitools" acima.

  • Utilize o utilitário sbkeysync das sbsigntools para instalar os pacotes de atualização:

    Nota

    • sudo mkdir -p /etc/secureboot/keys/db
    • sudo cp DBUpdate3P2023.bin /etc/secureboot/keys/db
    • sudo mkdir -p /etc/secureboot/keys/KEK
    • sudo cp KEKUpdate_Microsoft_PK1.bin /etc/secureboot/keys/KEK
    • sudo chattr -i /sys/firmware/efi/efivars/db-*
    • sudo chattr -i /sys/firmware/efi/efivars/KEK-*
    • sudo sbkeysync --verbose
    • sudo chattr +i /sys/firmware/efi/efivars/db-*
    • sudo chattr +i /sys/firmware/efi/efivars/KEK-*
    • sudo reboot

Passos de mitigação em caso de falhas de arranque

No caso de um cenário de falha, como falha de arranque após a atualização da variável UEFI, pode repor as definições de UEFI com um dos métodos abaixo:

  1. Restaure a cópia de segurança efetuada antes de iniciar o processo de atualização manual.
  2. Converta a VM de Iniciação Fidedigna em VM Standard e volte a aplicar o tipo de segurança Lançamento Fidedigno na VM. (Mais detalhes aqui: Ativar o Lançamento fidedigno em VMs gen2 existentes - Azure Máquinas Virtuais | Microsoft Learn)
  3. Exporte o vhd do SO para uma conta de armazenamento, crie uma imagem da galeria a partir do vhd e implemente a VM com a versão da imagem da galeria .

Exclusão de responsabilidade de informações de terceiros

Os produtos de terceiros que este artigo aborda são fabricados por empresas que são independentes da Microsoft. Não estabelecemos garantias, implícitas ou de outro tipo, relativamente ao desempenho ou fiabilidade destes produtos.

Fornecemos informações de contacto de terceiros para o ajudar a obter suporte técnico. Estas informações de contacto poderão ser alteradas sem aviso prévio. Não garantimos a exatidão destas informações de contacto de terceiros.

Registo de alterações

Alterar data Alterar descrição
29 de julho de 2026 Revisões importantes para aumentar a clareza das ações necessárias e métodos de atualização de firmware alternativos.
18 de junho de 2026 Foram adicionadas ligações de referência à secção "Recomendações de Linux fornecedores de SO".