Visão geral técnica das políticas de restrição de software
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012
Este tópico descreve as políticas de restrição de software, quando e como usar o recurso, quais alterações foram implementadas em versões anteriores e ainda fornece links para recursos adicionais para ajudar você a criar e implantar políticas de restrição de software começando com o Windows Server 2008 e o Windows Vista.
Introdução
As políticas de restrição de software fornecem aos administradores um mecanismo orientado por Política de Grupo para identificar o software e controlar a capacidade de execução no computador local. Essas políticas podem ser usadas para proteger computadores que executam sistemas operacionais Microsoft Windows (a partir do Windows Server 2003 e do Windows XP Professional) contra conflitos conhecidos e proteger os computadores contra ameaças à segurança, como vírus mal-intencionados e programas cavalo de Tróia. Você também pode usar as políticas de restrição de software para criar uma configuração altamente restrita para computadores em que você permite apenas aplicativos especialmente identificados a serem executados. As políticas de restrição de software são integradas com o Microsoft Active Directory e a Política de Grupo. Você também pode criar políticas de restrição de software em computadores autônomos.
As políticas de restrição de software são políticas de confiança, que são normas definidas por um administrador para restringir scripts e outro código que não seja totalmente confiável de ser executado. A extensão Políticas de Restrição de Software para o Editor de Política de Grupo Local fornece uma única interface do usuário onde as configurações para restringir o uso de aplicativos podem ser gerenciadas no computador local ou em todo um domínio.
Procedimentos
Cenários de uso da política de restrição de software
Os usuários empresariais colaboram usando emails, mensagens instantâneas e aplicativos ponto a ponto. À medida que essas colaborações aumentam, especialmente com o uso da Internet na computação empresarial, também surgem mais ameaças de código mal-intencionado, como worms, vírus e ameaças de invasores ou usuários mal-intencionados.
Os usuários podem receber código hostil de várias formas, desde arquivos executáveis nativos do Windows (arquivos .exe), macros em documentos (como arquivos .doc) e até scripts (como arquivos .vbs). Invasores ou usuários mal-intencionados geralmente usam métodos de engenharia social para fazer com que os usuários executem códigos contendo vírus e worms. (Engenharia social é um termo para enganar as pessoas de modo elas revelem sua senha ou alguma forma de informações de segurança.) Se um código desse for ativado, ele poderá gerar ataques de negação de serviço na rede, enviar dados confidenciais ou privados para a Internet, colocar a segurança do computador em risco ou danificar o conteúdo da unidade de disco rígido.
As organizações de TI e os usuários devem ser capazes de determinar qual software é seguro para executar e qual não é. Com os grandes números e formas que o código hostil pode usar, isso se torna uma tarefa difícil.
Para ajudar a proteger os computadores de rede contra código hostil e software desconhecido ou sem suporte, as organizações podem implementar políticas de restrição de software como parte da estratégia de segurança geral.
Os Administradores podem usar as políticas de restrição de software para as seguintes tarefas:
Definir o que é código confiável
Criar uma Política de Grupo flexível para scripts de regulação, arquivos executáveis e controles ActiveX
As políticas de restrição de software são aplicadas pelo sistema operacional e por aplicativos (como aplicativos de script) que atendem às políticas de restrição de software.
Especificamente, os administradores podem usar as políticas de restrição de software para as seguintes finalidades:
Especificar quais softwares (arquivos executáveis) podem ser executados em computadores clientes
Evitar que usuários executem programas específicos em computadores compartilhados
Especificar quem pode adicionar editores confiáveis aos computadores clientes
Definir o escopo das políticas de restrição de software (especificar se as políticas afetam todos os usuários ou um subconjunto de usuários em computadores clientes)
Evitar que arquivos executáveis sejam executados no computador local, na unidade organizacional (OU), no site, ou no domínio. Isso seria apropriado em casos em que você não estiver usando políticas de restrição de software para resolver possíveis problemas com usuários mal-intencionados.
Diferenças e alterações na funcionalidade
Não há alterações na funcionalidade na política SRP para Windows Server 2012 e Windows 8.
Versões compatíveis
As políticas de restrição de software só podem ser configuradas e aplicadas a computadores que executam pelo menos o Windows Server 2003, incluindo o Windows Server 2012 e pelo menos o Windows XP, incluindo o Windows 8.
Observação
Determinadas edições do sistema operacional cliente Windows a partir do Windows Vista não têm políticas de restrição de software. Computadores não administrados em um domínio por Política de Grupo talvez não recebam políticas distribuídas.
Comparando as funções do controle de aplicativo nas Políticas de Restrição de Software e no AppLocker
A tabela a seguir compara os recursos e as funções do AppLocker e SRP (Políticas de Restrição de Software).
| Função de controle de aplicativo | SRP | AppLocker |
|---|---|---|
| Escopo | As políticas SRP podem ser aplicadas a todos os sistemas operacionais Windows, começando no Windows XP e Windows Server 2003. | As políticas do AppLocker se aplicam somente ao Windows Server 2008 R2, Windows Server 2012, Windows 7 e Windows 8. |
| Criação de política | As políticas SRP são mantidas por meio de Política de Grupo e somente o administrador do GPO pode atualizar a política SRP. O administrador no computador local pode modificar as políticas SRP definidas no GPO local. | As políticas do AppLocker são mantidas por meio de Política de Grupo e somente o administrador do GPO pode atualizar a política. O administrador no computador local pode modificar as políticas do AppLocker definidas no GPO local. O AppLocker permite personalização de mensagens de erro para direcionar usuários a uma página da Web para obter ajuda. |
| Manutenção de política | As políticas SRP devem ser atualizadas usando o snap-in Política de Segurança Local (se as políticas forem criadas localmente) ou o GPMC (Console de Gerenciamento de Política de Grupo). | As políticas do AppLocker podem ser atualizadas usando o snap-in Política de Segurança Local (se as políticas forem criadas localmente), o GPMC ou os cmdlets do AppLocker do Windows PowerShell. |
| Aplicação da política | As políticas SRP são distribuídas por meio de Política de Grupo. | As políticas do AppLocker são distribuídas por meio de Política de Grupo. |
| Modo de imposição | O SRP funciona no "modo de lista de negações", em que os administradores podem criar regras para arquivos que não desejam permitir nesta Empresa, enquanto o restante dos arquivos tem permissão para ser executados por padrão. A política SRP também pode ser configurada no "modo de lista de permissões", em que, por padrão, todos os arquivos são bloqueados e os administradores precisam criar regras de permissão para os arquivos que desejam permitir. |
Por padrão, o AppLocker funciona no "modo de lista de permissões", em que somente esses arquivos têm permissão para serem executados tendo uma regra de permissão correspondente. |
| Tipos de arquivo que podem ser controlados | A política SRP pode controlar os seguintes tipos de arquivo: – Executáveis A política SRP não pode controlar cada tipo de arquivo separadamente. Todas as regras da política SRP estão em uma única coleção de regras. |
O AppLocker pode controlar os seguintes tipos de arquivo: – Executáveis O AppLocker mantém uma coleção de regras separada para cada um dos cinco tipos de arquivo. |
| Tipos de arquivo designados | A política SRP dá suporte a uma lista extensível de tipos de arquivo que são considerados executáveis. Os administradores podem adicionar extensões para arquivos que devem ser considerados executáveis. | O AppLocker não dá suporte a isso. Atualmente, o AppLocker dá suporte às seguintes extensões de arquivo: – Executáveis (.exe, .com) |
| Tipos de regras | A política SRP dá suporte a quatro tipos de regras: – Hash |
O AppLocker dá suporte a três tipos de regras: – Hash |
| Editar o valor do hash | A política SRP permite que os administradores forneçam valores de hash personalizados. | O AppLocker calcula o valor do hash em si. Internamente, ele usa o hash SHA1 Authenticode para executáveis portáteis (Exe e Dll) e Instaladores do Windows e um hash de arquivo simples SHA1 para o restante. |
| Suporte para diferentes níveis de segurança | Com a política SRP, os administradores podem especificar as permissões com as quais um aplicativo pode ser executado. Portanto, um administrador pode configurar uma regra de modo que o bloco de notas sempre seja executado com permissões restritas e nunca com privilégios administrativos. A política SRP no Windows Vista e anterior oferecia suporte a vários níveis de segurança. No Windows 7, essa lista era restrita a apenas dois níveis: Não permitido e Irrestrito (Usuário Básico é convertido em Não Permitido). |
O AppLocker não dá suporte a níveis de segurança. |
| Gerenciar aplicativos empacotados e instaladores de aplicativos empacotados | Não habilitado | .appx é um tipo de arquivo válido que o AppLocker pode gerenciar. |
| Direcionar uma regra para um usuário ou um grupo de usuários | As regras da política SRP se aplicam a todos os usuários em um computador específico. | As regras do AppLocker podem ser direcionadas a um usuário específico ou a um grupo de usuários. |
| Suporte para exceções de regra | A política SRP não dá suporte a exceções de regra | As regras do AppLocker podem ter exceções que permitem aos administradores criar regras como "Permitir tudo do Windows, exceto para Regedit.exe". |
| Suporte para o modo de auditoria | A política SRP não dá suporte ao modo de auditoria. A única maneira de testar políticas SRP é configurar um ambiente de teste e executar alguns experimentos. | O AppLocker dá suporte ao modo de auditoria que permite aos administradores testar o efeito da política deles no ambiente de produção real sem afetar a experiência do usuário. Quando você estiver satisfeito com os resultados, poderá começar a impor a política. |
| Suporte para exportação e importação de políticas | A política SRP não dá suporte à importação/exportação de políticas. | O AppLocker dá suporte à importação e exportação de políticas. Isso permite que você crie a política do AppLocker em um computador de amostra, teste-a e em seguida exporte e importe essa política de volta para o GPO desejado. |
| Imposição de regras | Internamente, a imposição de regras da política SRP ocorre no modo de usuário que é menos seguro. | Internamente, as regras do AppLocker para Exes e Dlls são impostas no modo kernel, que é mais seguro do que impô-las no modo de usuário. |
Requisitos de sistema
As políticas de restrição de software só podem ser configuradas e aplicadas a computadores que executam pelo menos o Windows Server 2003 e pelo menos o Windows XP. A Política de Grupo é necessária para distribuir Objetos de Política de Grupo que contêm políticas de restrição.
Componentes e arquitetura das políticas de restrição de software
As políticas de restrição de software fornecem um mecanismo para o sistema operacional e aplicativos compatíveis com políticas de restrição de software para restringir a execução do runtime de programas de software.
Em um alto nível, as políticas de restrição de software consistem nos seguintes componentes:
API de políticas de restrição de software. As APIs (Interfaces de Programação de Aplicativo) são usadas para criar e configurar as regras que constituem a política de restrição de software. Também há APIs de políticas de restrição de software para consultar, processar e impor políticas de restrição de software.
Uma ferramenta de gerenciamento de políticas de restrição de software. Isso consiste na extensão Políticas de Restrição de Software do snap-in Editor de Objeto de Política de Grupo Local, que os administradores usam para criar e editar as políticas de restrição de software.
Um conjunto de APIs e aplicativos do sistema operacional que chamam as APIs de políticas de restrição de software para fornecer a imposição das políticas de restrição de software em runtime.
Active Directory e Política de Grupo. As políticas de restrição de software dependem da infraestrutura de Política de Grupo para propagar as políticas de restrição de software do Active Directory para os clientes apropriados e para o escopo e a filtragem da aplicação dessas políticas para os computadores de destino apropriados.
APIs Authenticode e WinVerify Trust que são usadas para processar arquivos executáveis assinados.
Visualizador de Eventos. As funções usadas pelas políticas de restrição de software registram eventos nos logs do Visualizador de Eventos.
O RSoP (Conjunto de Políticas Resultante), que pode auxiliar no diagnóstico da política efetiva que será aplicada a um cliente.
Para obter mais informações sobre a arquitetura da política SRP, como a política SRP gerencia regras, processos e interações, consulte Como funcionam as políticas de restrição de software na Biblioteca Técnica do Windows Server 2003.
Práticas recomendadas
Não modifique a política de domínio padrão.
- Se você não editar a política de domínio padrão, sempre terá a opção de reaplicar a política de domínio padrão se algo der errado com a política de domínio personalizada.
Crie um Objeto de Política de Grupo separado para políticas de restrição de software.
- Se você criar um GPO (Objeto de Política de Grupo) separado para políticas de restrição de software, poderá desabilitar as políticas de restrição de software em uma emergência sem desabilitar o restante da política de domínio.
Se você tiver problemas com as configurações de política aplicadas, reinicie o Windows no Modo de Segurança.
- As políticas de restrição de software não se aplicam quando o Windows é iniciado no Modo de Segurança. Se você bloquear acidentalmente uma estação de trabalho com políticas de restrição de software, reinicie o computador no Modo de Segurança, faça logon como administrador local, modifique a política, execute gpupdate, reinicie o computador e faça logon normalmente.
Tenha cuidado ao definir uma configuração padrão de Não permitido.
Quando você define uma configuração padrão de Não permitido, todos os softwares não serão permitidos, exceto o software que tiver sido explicitamente permitido. Qualquer arquivo que você queira abrir precisa ter uma regra de políticas de restrição de software que permita que ele seja aberto.
Para proteger os administradores impedindo que se bloqueiem fora do sistema, quando o nível de segurança padrão for definido como Não permitido, quatro regras de caminho do Registro são criadas automaticamente. Você pode excluir ou modificar essas regras de caminho do Registro, entretanto, isso não é recomendado.
Para obter a melhor segurança, use listas de controle de acesso em conjunto com políticas de restrição de software.
- Os usuários podem tentar contornar as políticas de restrição de software renomeando ou movendo arquivos não permitidos ou substituindo arquivos irrestritos. Como resultado, é recomendável que você use ACLs (listas de controle de acesso) para negar aos usuários o acesso necessário para executar essas tarefas.
Teste as novas configurações de política por completo em ambientes de teste antes de aplicar as configurações de política ao domínio.
As novas configurações de política podem agir de forma diferente do que era esperado originalmente. Testar diminui a chance de encontrar um problema ao implantar configurações de política na rede.
Você pode configurar um domínio de teste, separado do domínio da organização, no qual testará as novas configurações de política. Você também pode testar as configurações de política criando um GPO de teste e vinculando-o a uma unidade organizacional de teste. Quando você tiver testado completamente as configurações de política com usuários de teste, poderá vincular o GPO de teste ao domínio.
Não defina programas ou arquivos como Não permitidos sem antes testar para ver qual poderá ser o efeito. Restrições em determinados arquivos podem afetar seriamente a operação do computador ou da rede.
Informações inseridas incorretamente ou erros de digitação podem resultar em uma configuração de política que não funcionará conforme o esperado. Testar as novas configurações de política antes de aplicá-las pode impedir um comportamento inesperado.
Filtre as configurações de política de usuário com base na associação em grupos de segurança.
Você pode especificar usuários ou grupos para os quais não deseja aplicar uma configuração de política limpando as caixas de seleção Aplicar Política de Grupo e Leitura, que estão localizadas na guia Segurança da caixa de diálogo de propriedades do GPO.
Quando a permissão de Leitura for negada, a configuração de política não será baixada pelo computador. Como resultado, menos largura de banda é consumida com o download de configurações de política desnecessárias, permitindo que a rede funcione mais rapidamente. Para negar a permissão de Leitura, marque Negar para a caixa de seleção Leitura, que está localizada na guia Segurança da caixa de diálogo de propriedades do GPO.
Não vincule a um GPO em outro domínio ou site.
- A vinculação a um GPO em outro domínio ou site pode resultar em mau desempenho.
Recursos adicionais
| Tipo de conteúdo | Referências |
|---|---|
| Planejamento | Referência técnica das políticas de restrição de software |
| Operações | Administrar políticas de restrição de software |
| Solução de problemas | Solução de problemas de políticas de restrição de software (2003) |
| Segurança | Ameaças e contramedidas para políticas de restrição de software (2008) Ameaças e contramedidas para políticas de restrição de software (2008 R2) |
| Ferramentas e configurações | Ferramentas e configurações de políticas de restrição de software (2003) |
| Recursos da comunidade | Bloqueio de Aplicativo com Políticas de Restrição de Software |