Considerações de segurança para o AppLocker
Este tópico para o profissional de TI descreve as considerações de segurança que você precisa ter em mente ao implementar AppLocker.
O objetivo do AppLocker é restringir o acesso ao software e, portanto, aos dados acessados pelo software, para um grupo específico de usuários ou em um grupo de negócios definido. A seguir estão as considerações de segurança para o AppLocker:
O AppLocker é implantado em uma empresa e administrado centralmente por aqueles na IT com credenciais confiáveis. Isso faz com que a criação e implantação de políticas sigam processos de implantação de política e restrições de segurança semelhantes.
As políticas do AppLocker são distribuídas por processos e meios conhecidos no domínio através da Política de Grupo. Mas as políticas do AppLocker também poderão ser definidas em computadores individuais, se a pessoa tiver privilégios de administrador, e essas políticas poderão ser contrárias à política de segurança da organização. As configurações de imposição de políticas locais são substituídas pelas mesmas políticas do AppLocker em um Objeto de Política de Grupo (GPO). No entanto, como as regras do AppLocker são cumulativas, uma política local que não esteja em um GPO ainda será avaliada para aquele computador.
A Microsoft não fornece uma maneira de desenvolver quaisquer extensões para o AppLocker. As interfaces não são públicas. Um usuário com credenciais de administrador pode automatizar alguns processos do AppLocker usando os cmdlets do Windows PowerShell. Para obter informações sobre como cmdlets do Windows PowerShell do AppLocker, consulte Cmdlets do AppLocker no Windows PowerShell.
O AppLocker é executado no contexto de administrador ou sistema local, que é o conjunto de privilégio mais alto. Esse contexto de segurança tem o potencial de uso incorreto. Se um usuário com credenciais administrativas fizer alterações em uma política do AppLocker em um dispositivo local que tenha ingressado em um domínio, essas alterações poderão ser substituídas ou não permitidas pelo GPO que contém a regra do AppLocker para o mesmo arquivo (ou caminho) que foi alterado no dispositivo local. No entanto, como as regras do AppLocker são cumulativas, uma política local que não esteja em um GPO ainda será avaliada para aquele computador. Se o computador local não estiver associado a um domínio e não for administrado pela Política de Grupo, uma pessoa com credenciais administrativas poderá alterar a política do AppLocker.
Ao proteger arquivos em um diretório com uma regra do tipo de condição de caminho, seja usando a ação de permissão ou negação na regra, a restrição do acesso a esses arquivos ainda será uma prática recomendada necessária ao definir as listas de controle de acesso (ACLs) de acordo com sua política de segurança.
O AppLocker não protege contra a execução de binários de 16 bits no DOS em uma máquina DOS virtual (NTVDM). Essa tecnologia permite a execução de programas DOS herdados e Windows de 16 bits em computadores usando o Intel 80386 ou posterior quando já houver outro sistema operacional executando e controlando o hardware. O resultado é que os binários de 16 bits ainda podem ser executados no Windows Server 2008 R2 e Windows 7 com o AppLocker configurado para bloquear binários e bibliotecas. Se houver um requisito para impedir a execução de aplicativos de 16 bits, você deverá configurar a regra de negação na coleção de regras executáveis para o NTVDM.exe.
Você não pode usar o AppLocker (ou as Políticas de Restrição de Software) para impedir a execução de códigos fora do subsistema Win32. Em particular, isso se aplica para o subsistema (POSIX) no Windows NT. Se houver um requisito para impedir que aplicativos funcionem no subsistema POSIX, você deverá desabilitar o subsistema.
O AppLocker só pode controlar arquivos VBScript, JScript, .bat, .cmd e scripts do Windows PowerShell. Ele não controla todos os códigos interpretados que são executados em um processo de host, por exemplo, macros e scripts Perl. O código interpretado é uma forma de código executável que é executado em um processo de host. Por exemplo, os arquivos em lote do Windows (*.bat) são executados no contexto do host de comando do Windows (cmd.exe). Para controlar o código interpretado usando o AppLocker, o processo de host deve chamar o AppLocker antes de executar o código interpretado e impor a decisão retornada pelo AppLocker. Nem todos os processos de host chamarão o AppLocker e, portanto, o AppLocker não poderá controlar cada tipo de código interpretado, como as macros do Microsoft Office.
Importante
Você deverá definir as configurações de segurança adequadas desses processos de host, se sua execução for necessária. Por exemplo, defina as configurações de segurança do Microsoft Office para garantir que apenas as macros assinadas e confiáveis sejam carregadas.
As regras do AppLocker tanto permitem como impedem que um aplicativo seja iniciado. O AppLocker não controla o comportamento dos aplicativos depois que são iniciados. Os aplicativos podem conter sinalizadores que são transmitidos a funções que avisam ao AppLocker para burlar as regras e permitir que outro .exe ou. dll seja carregado. Na prática, um aplicativo que é permitido pelo AppLocker poderia usar esses sinalizadores para ignorar as regras do AppLocker e iniciar processos filhos. Você deve examinar detalhadamente cada aplicativo antes de permitir que sejam executados usando as regras do AppLocker.
Observação
Dois sinalizadores que ilustram essa condição são SANDBOX_INERT, que pode ser transmitido para CreateRestrictedToken, e LOAD_IGNORE_CODE_AUTHZ_LEVEL, que pode ser transmitido para LoadLibraryEx. Esses dois sinalizadores avisam ao AppLocker para contornar as regras e permitir que um .exe ou. dll filho seja carregado.