Pontos principais
- Verifique a proteção LSA conferindo a Segurança do Windows, os valores do registro e os logs de eventos para confirmar o status protegido do LSASS.
- Use uma política corporativa para aplicar a proteção LSA e mantê-la após atualizações.
- Confirme os valores RunAsPPL e RunAsPPLBoot para validar a configuração da proteção LSA.
- Analise os eventos de Integridade de Código e de auditoria da LSA para comprovar que o LSASS iniciou como processo protegido.
- Alinhe a proteção LSA ao Credential Guard para manter uma postura consistente de segurança de credenciais.
- Guarde capturas de tela, exportações do registro e IDs de eventos como evidência pronta para auditoria.
- Resolva divergências entre interface, política e estado em execução para garantir relatórios de proteção precisos.
O processo LSASS (Local Security Authority Subsystem Service) é um componente central do Windows responsável por autenticar usuários, aplicar políticas de segurança e gerar os tokens de acesso que controlam o acesso aos recursos do sistema. Como o LSASS processa e armazena material de credencial sensível (hashes de senha, tickets Kerberos etc.), ele é um alvo de alto valor para invasores. Se comprometido, permite extrair credenciais da memória, elevar privilégios e se mover lateralmente pelos sistemas.
A proteção LSA (Local Security Authority) é um controle de segurança essencial do Windows 11 criado para reduzir esse risco. Ela protege o processo LSASS executando-o como processo protegido e restringindo o acesso apenas a componentes confiáveis e assinados. Isso ajuda a impedir acesso não autorizado à memória, injeção de código e técnicas comuns de roubo de credenciais. No entanto, confirmar se a proteção LSA está ativada exige checar vários indicadores do sistema, e não apenas um botão na interface.
Continue lendo para conhecer um fluxo prático que administradores e provedores de serviços gerenciados (MSPs) podem usar para verificar a proteção LSA no Windows 11.
Como saber se a proteção da Autoridade de Segurança Local está ativada
É importante validar a proteção LSA por vários ângulos, principalmente em ambientes gerenciados. Os passos a seguir percorrem verificações na interface, valores do registro, evidências nos logs de eventos, contexto de política e recursos de segurança complementares para garantir que o LSASS esteja rodando como processo protegido.
📌 Pré-requisitos:
- Direitos de administrador local no endpoint
- Acesso à Segurança do Windows, ao Visualizador de Eventos e a um shell elevado (PowerShell, Prompt de Comando etc.)
- Registro formal de mudança para qualquer correção
Passo 1: verifique a Segurança do Windows
Primeiro, confira o status em Segurança do Windows para ver como o sistema reporta a proteção LSA no momento. Nesse passo também aparecem avisos ou recomendações que exijam atenção imediata.
- Acesse Configurações > Privacidade e segurança > Segurança do Windows > Segurança do dispositivo > Detalhes do isolamento de núcleo.
- Localize o botão Proteção da Autoridade de Segurança Local e confirme que está Ativado.
- Leia as recomendações ou avisos exibidos ao usuário.
- Faça uma captura de tela se precisar de evidência para auditoria ou para o ticket.
Passo 2: confirme pelo registro
Em seguida, consulte o registro para saber se a proteção LSA também está configurada no nível do sistema. Isso permite distinguir problemas de exibição na interface da intenção real de proteção.
- Abra o Editor do Registro com direitos administrativos.
- Navegue até HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
- Verifique RunAsPPL e confirme que está definido como 1 ou 2, ativando a proteção LSA (com ou sem bloqueio UEFI), para que o LSASS seja executado como processo protegido após a reinicialização.
- Verifique RunAsPPLBoot e confirme que está definido como 1 ou 2, aplicando a proteção LSA mais cedo no processo de inicialização, sendo que 2 oferece uma aplicação mais forte ao bloquear a configuração contra adulteração em sistemas compatíveis.
- Use esses valores junto com os logs de eventos do próximo passo para confirmar o comportamento em execução.
Passo 3: valide com os logs de eventos
Os logs de eventos também confirmam com autoridade se o LSASS realmente iniciou como processo protegido e revelam plug-ins que não carregaram por causa dos requisitos de proteção.
- Abra o Visualizador de Eventos.
- Vá até Logs de Aplicativos e Serviços > Microsoft > Windows > CodeIntegrity > Operacional.
- Procure eventos de Integridade de Código (por exemplo, ID 3065 ou 3089) que indiquem que o LSASS iniciou como processo protegido e sinalizem plug-ins da LSA bloqueados ou que falharam ao carregar.
- Siga as orientações de auditoria da Microsoft para uma análise mais aprofundada.
Passo 4: verifique com PowerShell e o contexto de política
Além disso, a validação por PowerShell e por política ajuda a confirmar que a proteção LSA está ativada e aplicada pelas ferramentas de gerenciamento, de modo que a configuração sobreviva a atualizações do sistema operacional e não possa ser alterada pelos usuários finais.
- Use uma sessão elevada do PowerShell para confirmar os valores de registro relacionados à LSA e verificar o estado configurado com este comando:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL","RunAsPPLBoot" -ErrorAction SilentlyContinue
- Confira se a Política de Grupo ou o MDM aplica a proteção LSA, para que ela persista após atualizações e prevaleça sobre as configurações locais da interface.
Passo 5: compare a postura do LSASS e do Credential Guard
Também vale validar como a proteção LSA interage com o Credential Guard, já que os dois recursos dependem do comportamento protegido do LSASS e da segurança baseada em virtualização. Ainda assim, são recursos de proteção distintos, e confirmar esse alinhamento evita configurações incorretas que enfraqueçam o isolamento ou gerem avisos inesperados.
- Confirme que o Credential Guard está ativado.
- Confirme que o LSASS está rodando como processo protegido validando os valores de registro RunAsPPL e os eventos de inicialização protegida identificados nos passos anteriores.
- Consulte os logs de auditoria de Integridade de Código e da LSA em busca de erros que indiquem componentes bloqueados ou conflitos entre o Credential Guard e a proteção LSA
- Registre qualquer divergência entre a postura esperada e a real para corrigi-la antes de prosseguir com a validação.
Passo 6: guarde evidências para auditoria
Para conseguir revisar as descobertas depois e facilitar muito a resolução de problemas, colete sempre evidências claras e verificáveis.
- Faça capturas de tela do estado da proteção LSA na Segurança do Windows.
- Exporte as chaves de registro relevantes de HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
- Anote os IDs de eventos que confirmam a inicialização protegida do LSASS ou que apontam problemas em plug-ins.
- Registre o nome do dispositivo, a build do Windows e o escopo de política aplicável e, depois, armazene a evidência no seu RMM ou sistema de tickets.
Passo 7: corrija inconsistências de status
Por fim, aja quando os sinais da proteção LSA não baterem entre interface, registro e logs de eventos. Resolver essas inconsistências garante que o dispositivo esteja de fato protegido e que a postura reportada seja precisa.
- Reaplique a política correspondente se a interface mostrar a proteção LSA desativada, mas o registro e os valores de política indicarem que está ativada.
- Reinicie o dispositivo e repita se necessário, até que a Segurança do Windows, os valores do registro e os eventos de Integridade de Código mostrem de forma consistente o LSASS iniciando como processo protegido.
- Investigue estados de aviso ou mensagens de pacote da LSA não assinado exibidas na Segurança do Windows.
- Use o artigo de correção que já utiliza para resolver plug-ins ou drivers fora de conformidade.
- Revalide a configuração depois da correção para confirmar que o estado está consistente em todas as fontes.
Resumo das boas práticas
Veja a seguir boas práticas que ajudam a validar a proteção LSA de forma consistente e a aplicá-la com confiabilidade. Elas reduzem ambiguidades e aceleram as investigações.
| Prática | Objetivo | Valor entregue |
| Verificar na interface, no registro e nos eventos | Cruzar o estado real da proteção em várias fontes | Mais confiança e menos suposições equivocadas |
| Aplicar por Política de Grupo ou MDM | Aplicar a proteção LSA de forma centralizada e mantê-la após upgrades | Configuração mais estável e previsível em todos os dispositivos |
| Coletar evidências | Manter provas rastreáveis para auditorias e resolução de problemas | Investigações mais rápidas e mais responsabilização |
| Tratar os avisos primeiro | Resolver problemas com plug-ins desprotegidos ou incompatíveis | Verificação mais limpa e menos alertas recorrentes |
| Documentar build e escopo | Registrar o contexto do ambiente de cada dispositivo | Resultados reproduzíveis e validação consistente entre equipes |
O que é a proteção LSA e por que verificá-la
A proteção LSA é um recurso de segurança do Windows que executa o LSASS como processo protegido, impedindo que código não confiável se injete nele e bloqueando tentativas de roubar credenciais armazenadas na memória. Ela reforça um dos componentes mais sensíveis do sistema operacional e é a base dos controles modernos de segurança de credenciais, como o Credential Guard.
A verificação é fundamental para:
- garantir que o LSASS não esteja apenas configurado, mas realmente rodando como processo protegido;
- detectar divergências entre interface, registro e aplicação por política;
- garantir que a proteção persista após upgrades ou mudanças de política;
- identificar plug-ins da LSA desprotegidos ou incompatíveis que enfraquecem a segurança;
- fornecer evidências para auditorias, verificações de conformidade e investigações de segurança.
Resolução de problemas
Alguns problemas comuns podem aparecer durante a verificação da proteção LSA. Considere os passos a seguir para garantir que o dispositivo reporte corretamente sua postura de segurança.
A LSA aparece desativada após um upgrade
Confirme se a política corporativa continua aplicada e se os valores de RunAsPPL seguem configurados. Alguns upgrades do Windows redefinem configurações de segurança, então pode ser necessário reiniciar. Se a configuração não persistir, reaplique a política e verifique de novo.
O botão da interface sumiu ou está esmaecido
Normalmente, isso significa que a configuração é controlada por política corporativa, e não pela configuração local. Verifique a precedência das políticas e confirme se o registro reflete o estado aplicado. Configurações sem suporte ou legadas também deixam o botão indisponível.
Avisos sobre plug-ins não protegidos
Consulte as orientações de auditoria da Microsoft para identificar quais plug-ins ou drivers falharam ao carregar como protegidos. Atualize, remova ou substitua os componentes fora de conformidade para restaurar o comportamento correto da LSA. Depois, confira de novo os logs de eventos para garantir que nenhum outro plug-in foi afetado.
Analistas confundem LSA e LSASS
Deixe claro que a LSA é o subsistema responsável pela política de autenticação, enquanto o LSASS é o processo que a implementa. Criar uma explicação interna curta ajuda a reduzir essa confusão recorrente.
Guia de início rápido
NinjaOne ajuda a verificar e gerenciar a proteção da Autoridade de Segurança Local (LSA) em dispositivos Windows 11 por meio da Script Template Library.
Principais ações possíveis com NinjaOne:
1. Verificar o status da proteção LSA: use scripts para confirmar se a proteção LSA está ativada e em execução, mesmo quando a Segurança do Windows mostra que está desativada.
2. Ativar a proteção LSA: implante scripts para ativar a proteção LSA manualmente alterando configurações do registro (por exemplo, RunsAsPPL).
3. Garantir Inicialização Segura e TPM: embora NinjaOne não gerencie diretamente as configurações de BIOS/UEFI, dá para usar scripts para checar se o TPM e a Inicialização Segura estão ativados e gerar alertas quando faltarem.
4. Atualizar o Windows: use o gerenciamento de patches do NinjaOne para manter os dispositivos em dia com as atualizações de segurança mais recentes, que costumam trazer melhorias na proteção LSA.
5. Automatizar verificações de conformidade: agende execuções periódicas de scripts para monitorar o status da proteção LSA e corrigir problemas automaticamente em toda a frota.
Validar a proteção LSA para uma segurança duradoura
A verificação da proteção LSA deve seguir uma abordagem estruturada para garantir que o LSASS realmente esteja rodando como processo protegido. Seguindo o fluxo apresentado, da validação dos valores de registro à correção de inconsistências, MSPs e administradores mantêm a estabilidade no longo prazo.
Temas relacionados:
- Como ativar o Credential Guard e a proteção LSA nos dispositivos dos clientes
- Como ativar ou desativar a proteção da Autoridade de Segurança Local no Windows 11
- Como corrigir o aviso “O pacote da LSA não está assinado conforme o esperado” no Windows 11
- Como redefinir todas as configurações da Política de Segurança Local para o padrão no Windows
