Signers de Kernel Personalizados para Controlo de Aplicações para Empresas

A partir de abril de 2026, as autoridades de certificação (ACs) assinadas cruzadas já não são consideradas fidedignas por predefinição para a assinatura do controlador do modo kernel. O caminho padrão para a assinatura do controlador de kernel é através do Hardware Dev Center (HDC), que requer a submissão de binários de controlador à Microsoft para certificação whCP (Programa de Compatibilidade de Hardware do Windows ). No entanto, as organizações com ambientes classificados, confidenciais ou com disponibilidade aérea poderão não conseguir submeter controladores à Microsoft para certificação. Além disso, as organizações que escrevem controladores para utilização interna apenas podem não querer certificar controladores para o ecossistema do Windows.

Os signatários de kernel personalizados resolvem este problema ao expandir o Controlo de Aplicações para Empresas para permitir que as organizações confiem nos controladores de kernel assinados com a sua própria infraestrutura de chaves públicas (PKI), sem necessidade de assinaturas WHCP. A funcionalidade utiliza uma política de Controlo de Aplicações assinada por uma autoridade de assinatura na hierarquia de Arranque Seguro para definir que certificados de assinatura estão autorizados para o código do modo kernel. Esta funcionalidade dá-lhe controlo granular e auditável sobre o limite de fidedignidade do kernel e remove o requisito para que o WHCP certifique os controladores.

Como funcionam os Signatários de Kernel Personalizados

A funcionalidade de sinalizadores de kernel personalizados utiliza uma cadeia de fidedignidade em camadas e uma política de Controlo de Aplicações para substituir os requisitos de assinatura predefinidos incorporados no kernel do Windows. Eis como funciona a cadeia de fidedignidade:

Apenas o titular da plataforma (proprietário de PK ou KEK) pode autorizar a política. Este processo de inscrição de fricção elevada é intencional. O processo impede a utilização indevida em dispositivos de consumidor e garante que apenas as organizações com acesso a firmware físico podem ativar a funcionalidade.

Garantias de segurança

Os signatários de kernel personalizados fornecem as seguintes garantias de segurança:

• Integridade do Arranque Seguro: Os signatários de kernel personalizados só funcionam quando o Arranque Seguro está ativado. A política tem de ser assinada pelo proprietário do Secure Boot PK ou KEK e não pode ser falsificada sem acesso físico ao firmware.
• Proteção contra adulteração: Depois de implementada, a política assinada não pode ser removida sem uma política de substituição assinada pela mesma autoridade.
• Confiança granular: A política de Controlo de Aplicações permite regras de fidedignidade por certificado e por hash. Controla exatamente que controladores são executados no kernel.
• Não rejeição: Todas as assinaturas de políticas e controladores são criptograficamente verificáveis. Os registos de eventos de integridade do código capturam todas as decisões de carregamento e bloqueio para auditoria.

Plataformas e Edições Suportadas

A funcionalidade de sinalizadores de kernel personalizados está disponível nas seguintes plataformas windows com a atualização não relacionada com segurança de abril de 2026:

• Windows 11 (versão 24H2 e posterior)

A funcionalidade está disponível em todas as edições do Windows, exceto em Home Page.

Implementação de Signatários de Kernel Personalizados

Antes de começar, certifique-se de que os seguintes requisitos são cumpridos:

• Instalação limpa do Windows numa edição suportada. Os signatários de kernel personalizados têm de ser ativados durante a configuração inicial do dispositivo. A funcionalidade não será ativada em sistemas atualmente em execução.
• Firmware UEFI (versão 2.3 ou posterior) com Arranque Seguro ativado.
• Infraestrutura PKI pertencente ao cliente. Recomenda-se uma solução de armazenamento de chaves suportada por HSM para ambientes de produção.
• Acesso administrativo a variáveis de firmware UEFI (PK, KEK, DB).
• SignTool.exe do SDK do Windows.
• Estar familiarizado com o design da política do Controlo de Aplicações para Empresas, as regras de política assinadas e as políticas.

Passo 1: Gerar as chaves de Arranque Seguro

Gere o par de chaves PKI que serve como a sua raiz de confiança no Arranque Seguro e seja utilizado para assinar a política de Controlo de Aplicações. O PK ou o KEK podem ser utilizados como a raiz da fidedignidade para assinar a política de Controlo de Aplicações. A documentação de orientação da Microsoft é adicionar a chave PKI à KEK para que o proprietário do PK possa continuar a utilizar a KEK no futuro.

Os certificados PK e KEK têm de ser certificados de raiz ou certificados intermédios (PCAs) emitidos diretamente a partir da raiz. O documento Orientações de Criação e Gestão de Chaves de Arranque Seguro do Windows tem mais informações e orientações sobre a criação de certificados compatíveis com o Arranque Seguro. Também pode utilizar a chave Microsoft KEK como um modelo de referência para propriedades e extensões de chave.

Passo 2: Configurar as variáveis UEFI de Arranque Seguro com acesso ao PK

Se for o proprietário do PK em dispositivos, pode assinar a inscrição KEK para adicionar a sua chave pública KEK ao firmware UEFI. Se não for o proprietário do PK, pode avançar para o Passo 3.

Gerar o conteúdo de inscrição KEK

# Generate KEK content file
# Replace the SignatureOwner GUID with your organization's GUID
Format-SecureBootUEFI `
    -Name KEK `
    -SignatureOwner "55555555-5555-5555-5555-555555555555" `
    -ContentFilePath C:\KEK\KEK_SigList.bin `
    -FormatWithCert `
    -Certificate C:\KEK\policy_signer.cer `
    -SignableFilePath C:\KEK\KEK_Signable_SigList.bin `
    -Time 2025-01-01T00:00:00Z `
    -AppendWrite:$true

Assinar o ficheiro de inscrição KEK com o seu PK

signtool.exe sign /fd sha256 
    /p7 .\ 
    /p7co 1.2.840.113549.1.7.1 `
    /p7ce DetachedSignedData `
    /a `
    /f PK.pfx`
    C:\KEK\KEK_Signable_SigList.bin

Etapa 3. Configurar as variáveis UEFI de Arranque Seguro sem acesso ao PK

Para definir as variáveis de Arranque Seguro UEFI, desative primeiro o Arranque Seguro no menu UEFI para colocar o firmware no Modo de Configuração. No Modo de Configuração, as variáveis podem ser definidas sem atualizações assinadas.

Defina as variáveis pela seguinte ordem:

1. DB – Adicione o certificado OEM e a AC UEFI do Windows 2023.
2. KEK – adicione o microsoft KEK CA 2K 2023 e o certificado do signatário da política da sua organização.
3. PK – Defina a Chave de Plataforma da sua organização (ou deixe o OEM PK implementado se estiver a utilizar a inscrição KEK).

Passo 4: Criar a política de Controlo de Aplicações

Comece com a Política predefinida imposta do Windows como o modelo base e, em seguida, analise o dispositivo quanto a outros signatários que precisem de ser fidedignos.

Localizar o modelo de política predefinido

O modelo de política predefinido está disponível em:

%WINDIR%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml

Analisar os signatários de kernel existentes no dispositivo

New-CIPolicy -ScanPath 'C:\' -UserPEs -NoScript `
    -FilePath '.\ScannedPolicy.xml' `
    -Level PCACertificate -Fallback Hash

Intercalar a política predefinida com os resultados da análise

Merge-CIPolicy `
    -PolicyPaths 'C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml', '.\ScannedPolicy.xml' `
    -OutputFilePath '.\CustomKernelSignersPolicy.xml'

Preparar a política para assinatura

A funcionalidade de sinalizadores de kernel personalizados requer que a política seja assinada e protegida pelo Arranque Seguro e pelos componentes de arranque inicial do Windows. Veja mais informações sobre as políticas de Controlo de Aplicações assinadas. Para ativar a política assinada, remova a Opção 6 (política não assinada):

Set-RuleOption -Option 6 -FilePath .\CustomKernelSignersPolicy.xml -Delete

(Opcional) Remover Integridade do Código do Modo de Utilizador

Se quiser que a política se aplique apenas aos controladores do modo kernel, remova a Opção 0 (UMCI):

Set-RuleOption -Option 0 -FilePath .\CustomKernelSignersPolicy.xml -Delete

Melhores práticas para a política base

• Personalize primeiro a imagem. Remova qualquer software não aprovado antes de analisar o dispositivo.
• Utilizar -Level PCACertificate para o melhor equilíbrio de especificidade e cobertura.
• A análise captura todos os signatários existentes no dispositivo, garantindo que os componentes do Windows e os controladores de hardware permanecem fidedignos. Considere analisar apenas os controladores confidenciais.
• Teste minuciosamente no Modo de auditoria antes de implementar no modo imposto.

Passo 5: adicionar signatários de kernel personalizados à política

Adicione o hash TBS (A Assinar) de cada certificado fidedigno às secções seguintes do XML da política. Precisa de entradas para:

# Policy signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Update

# Custom kernel signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Kernel

Passo 6: Converter e assinar a política

Converter a política XML em formato binário

Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\CustomKernelSignersPolicy.xml
$PolicyId = ([xml](Get-Content .\CustomKernelSignersPolicy.xml)).SiPolicy.PolicyId
ConvertFrom-CIPolicy .\CustomKernelSignersPolicy.xml -BinaryFilePath ("./" + $PolicyId + ".cip")

Assinar a política com o certificado de assinatura de política

signtool.exe sign /fd sha256 `
    /p7 .\ `
    /p7co 1.3.6.1.4.1.311.79.1 `
    /p7ce Embedded`
    /a `
    /f policy_signer.pfx `
    ("./" + $PolicyId + ".cip")

Passo 7: Implementar a política

Pode implementar o binário da política assinada com qualquer um dos seguintes métodos:

• Solução MDM, como Microsoft Intune
• CiTool (disponível no Windows 11)
• Política de Grupo (implementar através de GPO)
• Implementação baseada em scripts (implementar através de script)

Implementação baseada em scripts para a Partição do Sistema EFI

Todas as soluções acima, além da implementação baseada em scripts, implementam automaticamente o binário da política na Partição do Sistema EFI (ESP). Se implementar através de script, tem de copiar manualmente o binário da política assinada para a partição EFI:

# Mount the EFI System Partition
mountvol s: /s

# Copy the signed policy to the active policies directory
copy ("./" + $PolicyId + ".cip") s:\EFI\Microsoft\Boot\CiPolicies\Active\

Passo 8: Repor o Windows

É necessária uma reposição do Windows para ativar a funcionalidade. Assim que a política estiver presente na partição EFI, tem de repor o dispositivo através de um método de reposição, como a reinicialização rápida. A política não será considerada fidedigna pelo Windows se não for efetuada uma reposição.

Passo 9: Desativar a Política de Controlador do Windows

A partir da atualização não relacionada com segurança de abril de 2026, o Windows 11 (24H2 e posterior) e o Windows Server 2025 impõem uma política de kernel que restringe a confiança para o programa de controladores transassinados. Se a política estiver ativa, tem de a desativar. Caso contrário, a política de controladores bloqueará os controladores personalizados assinados por PKI.

# Mount the EFI System Partition
mountvol s: /s

# Remove the default Windows kernel policy if present
del s:\EFI\Microsoft\Boot\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip

Passo 10: Validar a implementação

Testar primeiro no Modo de auditoria

Antes de impor a política, implemente com o Modo de auditoria ativado para registar violações de políticas sem bloquear os controladores:

1. Certifique-se de que Enabled:Audit Mode está definido na secção de política <Rules> .
2. Implemente a política e reinicie o dispositivo.
3. Reveja os registos de eventos da Integridade do Código em Aplicações e Serviços Regista a>Integridade do Código doMicrosoft>Windows>.

Lista de verificação de validação

• Os controladores assinados personalizados são carregados com êxito.
• Os controladores não assinados ou não autorizados estão bloqueados (no modo Impor).
• Windows Update e os fluxos de manutenção do SO continuam a funcionar.
• Os registos de eventos da Integridade do Código mostram apenas os eventos de bloco esperados.
• A política é validada em todas as configurações de hardware de destino antes da implementação em toda a frota.

Assim que a validação estiver concluída, remova a opção Enabled:Audit Mode de regra da política, volte a assinar e implemente em dispositivos de produção. Não é necessária uma instalação limpo do Windows para atualizações de políticas.

Conteúdo relacionado

• Guia de conceção do Controlo de Aplicações para Empresas
• Regras de políticas e regras de ficheiros do Controlo de Aplicações
• Implementar políticas de Controlo de Aplicações com script
• Utilizar políticas assinadas para proteger o Controlo de Aplicações contra adulteração
• Assinatura de versão WHCP
• Visão geral da inicialização segura