Controlo de aplicação Essential Eight
Este artigo detalha os métodos para alcançar o Modelo De Oito Maturidades Essenciais do Centro de Cibersegurança australiano (ACSC) para o Controlo de Aplicações, utilizando o Microsoft App Locker e o Controlo de Aplicações do Windows Defender.
O controlo de aplicações é uma abordagem de segurança concebida para proteger contra a execução de código malicioso em sistemas. Quando esta abordagem de segurança é implementada, garante que apenas o código aprovado, como executáveis, bibliotecas de software, scripts, instaladores e controladores, está autorizado a ser executado. Devido à sua eficácia, o controlo de aplicações é um dos Oito Essenciais das Estratégias do ACSC para Mitigar Incidentes de Cibersegurança.
O controlo de aplicações é uma abordagem de segurança concebida para proteger contra a execução de código malicioso em sistemas. Quando esta abordagem de segurança é implementada, garante que apenas o código aprovado, como executáveis, bibliotecas de software, scripts, instaladores e controladores, está autorizado a ser executado.
Embora o controlo de aplicações tenha sido concebido principalmente para impedir a execução e propagação de código malicioso num sistema, também pode impedir a instalação e a utilização de aplicações não aprovadas.
- Nível de maturidade 1 (ML1): pode ser alcançado com o Microsoft AppLocker
- Níveis de maturidade 2 e 3 (ML2 & ML3): podem ser alcançados com o Controlo de Aplicações do Microsoft Windows Defender
A implementação do controlo de aplicações envolve os seguintes passos de alto nível para uma organização:
- Identificar aplicações aprovadas
- Desenvolver regras de controlo de aplicações para garantir que apenas as aplicações aprovadas podem ser executadas
- Manter as regras de controlo de aplicações através de um processo de gestão de alterações
- Validar regras de controlo de aplicações com frequência
Ao determinar como impor a autorização de aplicação na sua organização, o Centro de Cibersegurança da Austrália considera os seguintes métodos adequados quando implementados corretamente:
- Regras de hash criptográfico
- Regras de certificação do Publisher
- Regras de Caminho (quando as permissões do sistema de ficheiros são configuradas para impedir a modificação não autorizada de permissões de pastas e ficheiros, conteúdos de pastas e ficheiros individuais)
O controlo de aplicações pode impedir a execução não autorizada de aplicações não aprovadas. O controlo de aplicações também pode contribuir para a identificação de tentativas de execução de código malicioso num sistema por parte de um ator de ameaças. Configurar o WDAC para gerar registos de eventos para execuções autorizadas e não autorizadas pode fornecer informações valiosas ao centro de operações de segurança de uma organização.
É importante ter em atenção que uma solução de controlo de aplicações não substitui o antivírus e outras soluções de software de segurança que já estão implementadas. O WDAC funciona sempre em conjunto com soluções antivírus, como Defender Antivírus. A utilização de soluções de segurança da Microsoft em conjunto contribui para uma abordagem eficaz de defesa em profundidade para impedir o comprometimento dos sistemas.
O Centro de Cibersegurança da Austrália tem três níveis de maturidade para as suas estratégias de mitigação que constituem o Essential Eight. Os níveis de maturidade baseiam-se na mitigação dos níveis crescentes de ofícios comerciais utilizados por um actor de ameaças. No contexto do controlo de aplicações, o Centro de Cibersegurança da Austrália determina o que é necessário para cumprir o ML 1, 2 e 3.
Controlo ISM Set 2024 | Nível de maturidade | Mitigação |
---|---|---|
ISM-0109 | 3 | Os registos de eventos de estações de trabalho são analisados em tempo útil para detetar eventos de cibersegurança. |
ISM-0140 | 2, 3 | Os incidentes de cibersegurança são reportados ao ASD assim que possível após ocorrerem ou serem detetados. |
ISM-0123 | 2, 3 | Os incidentes de cibersegurança são comunicados ao Diretor de Segurança de Informações, ou a um dos seus delegados, assim que possível após ocorrerem ou serem detetados. |
ISM-0843 | 1, 2, 3 | O controlo de aplicações é implementado em estações de trabalho. |
ISM-1490 | 2, 3 | O controlo de aplicações é implementado em servidores com acesso à Internet. |
ISM-1656 | 3 | O controlo de aplicações é implementado em servidores que não têm acesso à Internet. |
ISM-1544 | 2, 3 | A lista de bloqueio de aplicações recomendada da Microsoft está implementada. |
ISM-1657 | 1, 2, 3 | O controlo de aplicações restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicações HTML e applets do painel de controlo para um conjunto aprovado pela organização. |
ISM-1658 | 3 | O controlo de aplicação restringe a execução de controladores para um conjunto aprovado pela organização. |
ISM-1582 | 2, 3 | Os conjuntos de regras de controlo de aplicações são validados numa base anual ou mais frequente. |
ISM-1659 | 3 | A lista de bloqueio de controladores vulneráveis da Microsoft está implementada. |
ISM-1660 | 2, 3 | Os eventos de controlo de aplicações permitidos e bloqueados são registados centralmente. |
ISM-1815 | 2, 3 | Os registos de eventos estão protegidos contra modificações e eliminações não autorizadas. |
ISM-1819 | 2, 3 | Após a identificação de um incidente de cibersegurança, o plano de resposta a incidentes de cibersegurança é decretado. |
ISM-1870 | 1, 2, 3 | O controlo de aplicações é aplicado a perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail. |
ISM-1871 | 2, 3 | O controlo de aplicações é aplicado a todas as localizações que não os perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail. |
ISM-1228 | 2, 3 | Os eventos de cibersegurança são analisados em tempo útil para identificar incidentes de cibersegurança. |
ISM-1906 | 2, 3 | Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança. |
ISM-1907 | 3 | Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança. |
Controlo ISM Set 2024 | Nível de maturidade | Control | Measure |
---|---|---|---|
ISM-0109 | 3 | Os registos de eventos de estações de trabalho são analisados em tempo útil para detetar eventos de cibersegurança. | Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de Eventos Segurança do Windows através de soluções de Eventos Reencaminhados do Windows ou AMA. |
ISM-0140 | 2, 3 | Os incidentes de cibersegurança são reportados ao ASD assim que possível após ocorrerem ou serem detetados. | Não está no âmbito deste documento. Veja a nota a seguir a esta tabela. 3 |
ISM-0123 | 2, 3 | Os incidentes de cibersegurança são comunicados ao Diretor de Segurança de Informações, ou a um dos seus delegados, assim que possível após ocorrerem ou serem detetados. | Não está no âmbito deste documento. Veja a nota a seguir a esta tabela. 3 |
ISM-0843 | 1, 2, 3 | O controlo de aplicações é implementado em estações de trabalho. | Configure e utilize o Controlo de Aplicações do Windows Defender/AppLocker consoante os requisitos de nível de maturidade da organização. |
ISM-1490 | 2, 3 | O controlo de aplicações é implementado em servidores com acesso à Internet. | Configurar e utilizar o Controlo de Aplicações do Windows Defender |
ISM-1656 | 3 | O controlo de aplicações é implementado em servidores que não têm acesso à Internet. | Configurar e utilizar o Controlo de Aplicações do Windows Defender |
ISM-1544 | 2, 3 | A lista de bloqueio de aplicações recomendada da Microsoft está implementada. | As "regras de bloqueio recomendadas" da Microsoft são implementadas |
ISM-1657 | 1, 2, 3 | O controlo de aplicações restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicações HTML e applets do painel de controlo para um conjunto aprovado pela organização. | A Microsoft recomenda que seja criada uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. 1 |
ISM-1658 | 3 | O controlo de aplicação restringe a execução de controladores para um conjunto aprovado pela organização. | A integridade do código protegido pelo hipervisor está ativada e está predefinida para Windows 11 2022+ |
ISM-1582 | 2, 3 | Os conjuntos de regras de controlo de aplicações são validados numa base anual ou mais frequente. | Não está no âmbito deste documento. Veja a nota abaixo desta tabela. 3 |
ISM-1659 | 3 | A lista de bloqueio de controladores vulneráveis da Microsoft está implementada. | As "regras de bloqueio de controladores recomendadas" da Microsoft são implementadas |
ISM-1660 | 2, 3 | Os eventos de controlo de aplicações permitidos e bloqueados são registados centralmente. | Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de soluções "Eventos Segurança do Windows" através de AMA ou "Eventos Reencaminhados do Windows". |
ISM-1815 | 2, 3 | Os registos de eventos estão protegidos contra modificações e eliminações não autorizadas. | Role-Based Controle de Acesso para Microsoft Defender XDR e Microsoft Sentinel é imposta. |
ISM-1819 | 2, 3 | Após a identificação de um incidente de cibersegurança, o plano de resposta a incidentes de cibersegurança é decretado. | Não está no âmbito deste documento. Veja a nota abaixo desta tabela. 3 |
ISM-1870 | 1, 2, 3 | O controlo de aplicações é aplicado a perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail. | A Microsoft recomenda que seja criada uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. O Nível de Maturidade 1 pode ser alcançado com o Microsoft AppLocker. O Nível de Maturidade 2 e 3 requer o Controlo de Aplicações do Windows Defender. 2 |
ISM-1871 | 2, 3 | O controlo de aplicações é aplicado a todas as localizações que não os perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail. | Implementação e configuração do Controlo de Aplicações do Windows Defender |
ISM-1228 | 2, 3 | Os eventos de cibersegurança são analisados em tempo útil para identificar incidentes de cibersegurança. | Não está no âmbito deste documento. Veja a nota a seguir a esta tabela. 3 |
ISM-1906 | 2, 3 | Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança. | Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de Eventos Segurança do Windows através de soluções de Eventos Reencaminhados do Windows ou AMA. |
ISM-1907 | 3 | Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança. | Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de Eventos Segurança do Windows através de soluções de Eventos Reencaminhados do Windows ou AMA. |
Importante
1 Para cumprir o ISM-1657, a Microsoft recomenda que tenha sido criada uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. Se as Regras de Caminho de Ficheiro também estiverem a ser aproveitadas, uma organização tem de garantir que o utilizador está impedido de modificar permissões de pastas e ficheiros, ficheiros e ficheiros individuais. Por exemplo, o utilizador não deve ter Acesso de Escrita no NTFS para a localização da Regra de Caminho de Ficheiro.
2 Para cumprir o ISM-1870, a Microsoft recomenda a criação de uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. O Nível de Maturidade 1 pode ser alcançado com o Microsoft AppLocker. O Nível de Maturidade 2 e 3 tem um requisito para o Controlo de Aplicações do Windows Defender devido aos requisitos adicionais do ISM. As Regras de Caminho de Ficheiro não são recomendadas para ISM-1870 devido ao utilizador ter permissão de sistema de ficheiros no perfil do utilizador e pastas temporárias.
3 Os controlos ISM-0140, 0123, 1582, 1819 e 1228 são explicitamente principais e controlos de processo. A Microsoft recomenda que as pessoas e os processos sejam documentados e armazenados como artefactos no Gestor de Conformidade do Purview, como parte de provas tecnológicas automatizadas para revisões de conformidade do Essential 8.
A Microsoft recomenda que os clientes implementem o Controlo de Aplicações do Windows Defender (WDAC) em vez do AppLocker. O Controlo de Aplicações do Windows Defender está a sofrer melhorias contínuas. Embora o AppLocker continue a receber correções de segurança, não recebe melhoramentos de funcionalidades.
No entanto, o AppLocker também pode ser implementado como um complemento do Controlo de Aplicações do Windows Defender para cenários como dispositivos partilhados, onde é importante impedir que alguns utilizadores executem uma aplicação específica. A Microsoft recomenda que a sua organização aplique o Controlo de Aplicações do Windows Defender como o nível mais restritivo possível para a sua organização e que utilize o AppLocker para otimizar ainda mais as restrições do modo de utilizador, se necessário.
Dica
Embora o WDAC seja preferido, pode ser mais simples e fácil para a maioria das organizações alcançar o ML1 com apenas o AppLocker como ponto de partida, ambas as soluções são gratuitas.
O AppLocker foi introduzido com o Windows 7 e permite que a organização controle que processos de modo de utilizador (aplicações) podem ser executados nos seus Sistemas Operativos Windows. As Políticas do AppLocker podem aplicar-se a todos os utilizadores num sistema ou a utilizadores e grupos individuais com regras que podem ser definidas com base em:
- Regras de hash criptográfico
- Regras de certificação do Publisher
- Regras de caminho
As políticas do AppLocker podem ser criadas em todas as versões e adições suportadas do Sistema Operativo Windows e podem ser implementadas com Política de Grupo, o PowerShell ou uma solução de Gerenciamento de Dispositivos Móvel.
O Controlo de Aplicações do Windows Defender (WDAC) foi introduzido com Windows 10. Permite que as organizações controlem que processos de modo de utilizador (aplicações) e modo kernel (controladores) podem ser executados nos seus Sistemas Operativos Windows. As políticas WDAC são aplicadas ao sistema gerido como um todo e afetam todos os utilizadores do dispositivo com regras que podem ser definidas com base em:
- Regras de hash criptográfico
- Regras de certificação do Publisher
- Regras de Caminho
- Reputação da aplicação conforme determinado pelo Gráfico de Segurança Inteligente da Microsoft
- Identidade do processo que iniciou a instalação da aplicação pelo instalador gerido
As políticas WDAC podem ser criadas em qualquer edição de cliente suportada de Windows 10, Windows 11 ou em Windows Server 2016 e superior. As políticas WDAC podem ser implementadas com Política de Grupo, uma solução de Gerenciamento de Dispositivos Móvel, Configuration Manager ou PowerShell.
Devido ao Windows as a Service da Microsoft permitir o desenvolvimento e implementação de novas funcionalidades para os nossos clientes, algumas capacidades do WDAC só estão disponíveis em versões específicas do Windows.
Para obter informações detalhadas sobre o Controlo de Aplicações do Windows Defender e o Applocker, consulte Controlo de Aplicações do Windows Defender e disponibilidade de funcionalidades do AppLocker.
Quando o administrador está a implementar uma política do AppLocker para o controlo de aplicações baseado no utilizador, as seguintes regras podem ser utilizadas como uma implementação baseada no caminho de exemplo. Isto inclui as regras, a imposição de regras e o início automático do serviço de Identidade da Aplicação.
A sugestão é bloquear (no mínimo) os seguintes caminhos:
- C:\Windows\Temp\*.*
- %USERPROFILE%\AppData\Local\*.*
- Adicionar exceção para %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
- %USERPROFILE%\AppData\Roaming\*.*
Para obter informações sobre o AppLocker na ML1, consulte os seguintes artigos:
As políticas do Microsoft AppLocker podem ser criadas com vários métodos. A Microsoft recomenda a utilização do projeto Microsoft Open source AaronLocker para ajudar na criação de políticas AppLocker. O AaronLocker permite a criação e manutenção de um controlo de aplicações robusto, rigoroso e rigoroso para o AppLocker o mais fácil e prático possível como utilizar o serviço de Scripts do PowerShell. O AaronLocker foi concebido para restringir a execução de programas e scripts por utilizadores não administrativos.
Para obter informações detalhadas sobre o Aaronlocker, consulte AaronLocker: Controlo de aplicações robusto e prático para o Windows.
O Microsoft AppLocker pode ser implementado com Microsoft Intune, Política de Grupo ou PowerShell. O método de implementação dependeria da solução de gestão atual da organização.
Para obter informações detalhadas sobre a implementação do Cacifo de Aplicações, consulte os seguintes artigos:
Os eventos relacionados com o Microsoft AppLocker são monitorizados por uma solução de Gestão de Informações e Eventos de Segurança, como o Sentinel da Microsoft. Os eventos também são monitorizados com as informações avançadas de investigação do Microsoft Defender para Ponto de Extremidade.
Microsoft Defender para Ponto de Extremidade: Referência do AppLocker
Microsoft Defender para Ponto de Extremidade captura os seguintes eventos em relação ao Microsoft AppLocker.
Nome do ActionType | ID da origem do evento |
---|---|
AppControlExecutableAudited | 8003 |
AppControlExecutableBlocked | 8004 |
AppControlPackagedAppAudited | 8021 |
AppControlPackagedAppBlocked | 8022 |
AppControlPackagedAppBlocked | 8006 |
AppControlScriptBlocked | 8007 |
AppControlCIScriptAudited | 8001 |
Para obter informações detalhadas sobre Visualizador de Eventos e Investigação avançada, consulte os seguintes artigos:
- Utilizar Visualizador de Eventos com o AppLocker
- Consultar eventos do Controlo de Aplicações centralmente com a Investigação avançada
A Microsoft está a destacar o processo de conceção, a gestão do ciclo de vida, a implementação e a documentação de orientação operacional para cumprir o controlo de aplicações Essential Eight ML2 e ML3 com o WDAC.
Os clientes com o requisito do Essential Eight Application Control ML1 podem ser alcançados com o Microsoft AppLocker.
São necessários os pré-requisitos para utilizar esta documentação de orientação:
- Windows 11 22H2 Enterprise
- Utilizar Intune para solução de gestão
- Defender para Endpoint, para solução de segurança de ponto final
- Microsoft Sentinel para informações de segurança e gestão de eventos; e
- Permissões adequadas dos administradores nas soluções utilizadas neste documento
WDAC em Sistemas Operativos Windows Server no âmbito deste guia. A documentação de orientação para o Windows Server será fornecida numa versão futura.
O serviço relacionado com o M365 pode estar localizado no Microsoft 365 e Office 365 descrições do serviço para compreender os serviços necessários necessários, as propostas de valor e os requisitos de licenciamento:
Descrições de serviços do Microsoft 365 e do Office 365
Para obter informações sobre os produtos associados ao WDAC, consulte os seguintes artigos:
Quando uma organização começa a planear o WDAC, a consideração das decisões de design forma como afeta a implementação de políticas e a manutenção da política de controlo de aplicações.
O WDAC deve ser utilizado como parte das políticas de controlo de aplicações da sua organização se o seguinte for verdadeiro:
- Implementou ou planeou implementar as versões suportadas do Windows na sua organização
- Precisa de um controlo melhorado sobre o acesso às aplicações da sua organização e aos dados de acesso do utilizador
- A sua organização tem um processo bem definido para a gestão e implementação de aplicações
- Tem recursos para testar políticas em relação aos requisitos da organização
- Tem recursos para envolver o Suporte Técnico ou criar um processo de ajuda autónoma para problemas de acesso à aplicação do utilizador final
- Os requisitos do grupo para produtividade, capacidade de gestão e segurança podem ser controlados por políticas restritivas
O WDAC incorpora um conceito de "círculo de confiança". Cada organização tem uma definição diferente de "círculo de confiança" exclusivo para os seus requisitos comerciais. A definição relacionada com o ACSC Essential 8 é o controlo ISM 1657 – "O controlo de aplicações restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicações HTML e applets de painel de controlo para um conjunto aprovado pela organização."
A Microsoft fornece várias políticas de exemplo no formato XML localizado no Windows em %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies. As políticas de exemplo da Microsoft podem permitir que a sua organização comece a partir de uma política base existente e adicione ou remova regras para criar políticas personalizadas, se necessário.
Para obter mais informações sobre a conceção de políticas, consulte os seguintes artigos:
- Documentação do Microsoft Intune
- Políticas base de exemplo do Controlo de Aplicações do Windows Defender
O WDAC suporta dois formatos de política:
Formato de política única: o formato de política original que foi lançado com Windows 10 RTM e Windows Server 2016. O formato de política única só suporta uma única política ativa num sistema a qualquer momento
Formato de várias políticas (recomendado): este formato de política é suportado no Windows 10 1903+, Windows 11 e Windows Server 2022. Um formato de política múltipla permite uma maior flexibilidade para implementar o Controlo de Aplicações do Windows Defender e suporta até 32 políticas ativas num dispositivo. Além disso, permite os seguintes cenários:
- Impor e auditar lado a lado: para validar as alterações de política antes de implementar a imposição. Os utilizadores podem implementar a política base do modo de auditoria lado a lado com uma política baseada no modo de imposição existente
- Várias políticas base: os utilizadores podem impor duas ou mais políticas de base em simultâneo
- Políticas suplementares: os utilizadores podem implementar uma ou mais políticas suplementares para expandir uma política base. Pode utilizar políticas suplementares para diferentes pessoas na sua organização, por exemplo, RH e TI
A Microsoft recomenda a utilização de múltiplos formatos de política e apenas a utilização do formato de política única para cenários bem definidos ou em que não sejam possíveis vários formatos de política, como Windows Server 2016 e o Windows Server 2019.
Para obter informações detalhadas sobre as políticas de controlo do WDAC, veja Utilizar várias Políticas de Controlo de Aplicações do Windows Defender.
O WDAC contém dois conceitos:
- Regras de política WDAC: as regras de política WDAC especificam configurações como o Modo de Auditoria, instalador gerido, Imposição de Scripts, Políticas de Suplemento (Formato de Política Múltipla), inteligência de Reputation-Based (Autorização ISG/Controlo de Aplicações Inteligentes) e talvez outras. As Regras de Política também determinam se o WDAC para binários de modo kernel e de modo de utilizador
- Regras de ficheiro WDAC: as regras de ficheiro wDAC especificam autorização e reautorização para execução no Windows. As regras de ficheiro suportam hash, nome de ficheiro, caminho de ficheiro e regras do Publisher permitem que um cliente defina um conjunto aprovado pela organização de aplicações permitidas. A regra processa primeiro todas as regras de negação explícitas que encontra e, em seguida, processa todas as regras de permissão explícitas. Se não existir nenhuma regra de negação ou permissão, o WDAC verifica o instalador gerido. Por último, se nenhum destes conjuntos existir, o WDAC reverterá para Reputation-Based inteligência
Para obter informações detalhadas sobre regras de políticas e regras de ficheiros, consulte o seguinte artigo:
Existem duas formas principais de criar uma Política WDAC com o PowerShell ou o Assistente do WDAC:
- PowerShell: as políticas WDAC são criadas com Cmdlets de Integridade de Código Configuráveis no PowerShell. O PowerShell permite que um Profissional de TI automatize a análise do sistema de políticas WDAC, o que gera um XML de política. O PowerShell pode ser utilizado para intercalar XMLs de política, definir regras de política e adicionar outras regras de ficheiro de política, se necessário Os Cmdlets de Integridade do Código Configurável também podem ser utilizados para modificar as políticas de exemplo do WDAC para satisfazer os requisitos da sua organização.
- Assistente de Controlo de Aplicações do Windows Defender (recomendado): o assistente de política do WDAC é uma aplicação de ambiente de trabalho windows open source escrita em C# e agrupada como um pacote MSIX. Foi criado para fornecer aos arquitetos de segurança segurança e administradores de sistema um meio mais adequado para criar, editar e intercalar políticas de Controlo de Aplicações. Esta ferramenta utiliza os cmdlets do PowerShell da CI de Configuração no back-end, pelo que a política de saída da ferramenta e os cmdlets do PowerShell são idênticos
Para obter informações detalhadas sobre a criação de políticas, veja os seguintes artigos:
- Criar uma política WDAC com um computador de referência
- Assistente de Controlo de Aplicações do Windows Defender
- ConfigCI
- Assistente de Políticas do WDAC
A Microsoft recomenda a utilização do Assistente de Controlo de Aplicações do Windows Defender para implementar o Essential Eight para o Controlo de Aplicações. Em alternativa, o PowerShell pode ser utilizado por organizações com requisitos avançados num modelo operacional de DevOps com as políticas de exemplo como base ou que pretendam criar uma política para cenários bem definidos a partir de um sistema de referência.
Antes de uma organização começar a implementar uma solução de controlo de aplicações, tem de considerar como as suas políticas são geridas e mantidas ao longo do tempo. A maioria das políticas WDAC evoluem ao longo do tempo e continuam através de um conjunto de fases identificáveis durante a sua duração. Estas fases incluem:
- Defina a política e crie uma versão do modo de auditoria do XML da política. No modo de auditoria, os eventos de bloqueio são gerados, mas os ficheiros não são impedidos de ser executados
- Implementar a política do modo de auditoria nos sistemas pretendidos
- Monitorizar eventos de bloqueio de auditoria a partir dos sistemas pretendidos e refinar as regras conforme necessário para resolver blocos inesperados/indesejados
- Repita estes passos até que os restantes eventos de bloco satisfaçam as suas expectativas durante a auditoria
- Gere a versão do modo imposto da política. No modo de imposição, os ficheiros que não são definidos como permitidos pela política são impedidos de executar e os eventos de bloco correspondentes são gerados
- Implementar a política de modo de imposição nos sistemas pretendidos
- Repita todos estes passos continuamente para abordar quaisquer ações de bloqueio inesperadas/indesejadas
Para gerir eficazmente as políticas WDAC, deve armazenar e manter os documentos XML de política num repositório central. A Microsoft recomenda uma solução de controlo de código fonte, como o GitHub ou a solução de gestão de documentos, como o SharePoint, que fornece controlo de versões.
Esta secção destina-se a fornecer orientações do cliente sobre os requisitos de configuração do instalador gerido pelo WDAC com o PowerShell e Microsoft Intune.
- Reveja a proteção contra ameaças do Windows automaticamente para permitir aplicações implementadas por um instalador gerido com o Controlo de Aplicações do Windows Defender (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)
Observação
Este script de exemplo não utiliza o AppLocker, pelo que as regras DENY benignas não estão presentes no passo 1. Esta configuração do AppLocker seria criada para todos os dispositivos que necessitam do instalador gerido.
- Crie um Script do PowerShell que conclua o seguinte:
- Armazenar o XML do AppLocker
- Exportar o XML do AppLocker
- Definir Política appLocker
- Iniciar o Serviço AppLocker
Segue-se um exemplo de um script que pode ser implementado com Intune extensão de gestão – scripts do PowerShell:
$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path
$AppLockerMIPolicy =
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
<FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
<BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
</AppLockerPolicy>
"@
$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml
Importante
O administrador tem de adicionar o script de configuração à política de Regra de Ficheiro WDAC através de Hash ou Publisher.
A funcionalidade do WDAC denominada instalador gerido permite que uma organização equilibre a segurança e a capacidade de gestão ao impor políticas de controlo de aplicações. Isto permite que as aplicações sejam instaladas por uma solução de distribuição de software, como Microsoft Configuration Manager ou Intune.
Um equívoco comum é configurar a regra do "instalador gerido" na política do WDAC são os únicos passos necessários. Isto está incorreto e é necessária outra configuração do AppLocker para que esta funcionalidade funcione.
O instalador gerido utiliza uma coleção de regras no AppLocker para designar binários considerados fidedignos pela sua organização para instalação de aplicações. O Windows monitoriza o processo do binário configurado e todos os processos subordinados que inicia enquanto monitoriza os ficheiros associados que estão a ser escritos no disco. Estes ficheiros são identificados como provenientes de um instalador gerido, pelo que podem ser executados.
A criação da política appLocker no GPO Edit e os cmdlets do PowerShell do AppLocker não podem ser utilizados diretamente para criar regras para a coleção do instalador gerido. Tem de utilizar o VS Code ou outra ferramenta de editor para criar uma coleção de Regras do instalador gerido.
Atualmente, o Fornecedor de Serviços de Configuração (CSP) do AppLocker não suporta o tipo de coleção de regras do instalador gerido, pelo que a política appLocker tem de estar a entrar com o PowerShell para Microsoft Intune.
Uma vez que a funcionalidade "Imposição de Scripts" do Controlo de Aplicações do Windows Defender é necessária para cumprir o ISM-1657, é necessária a imposição de scripts para controlar o PowerShell, o VBscript, o cscript, o HSMTA e o MSXML. O script do PowerShell para configurar o "instalador gerido" tem de estar dentro da regra de política de ficheiros WDAC com Hash ou Publisher.
A Microsoft recomenda a configuração do instalador gerido para Microsoft Intune. Intune permite uma gestão robusta das Aplicações empacotadas com Microsoft Intune sem o requisito de atualizar frequentemente uma política de Controlo de Aplicações do Windows Defender.
A implementação deste script de configuração para o instalador gerido pode ser obtida de duas formas ao utilizar Microsoft Intune consoante o cenário:
- Hash: o hash do script teria de ser conhecido na Política de Ficheiros WDAC, empacotado e implementado com a Ferramenta de Preparação de Conteúdos do Microsoft Win32 ou a funcionalidade Script do PowerShell no Microsoft Intune.
- Assinado por código (Publisher): o Script do PowerShell foi assinado por uma autoridade fidedigna e conhecido com a Política de Ficheiros WDAC, empacotado e implementado com a Ferramenta de Preparação de Conteúdos do Microsoft Win32 ou a funcionalidade script do PowerShell no Microsoft Intune.
Para obter informações detalhadas sobre a implementação de scripts do PowerShell, veja os seguintes artigos:
- Permitir automaticamente aplicações implementadas por um instalador gerido com o Controlo de Aplicações do Windows Defender
- CSP do AppLocker
- Imposição de scripts com o Controlo de Aplicações do Windows Defender (WDAC)
- Gerenciamento de aplicativos Win32 no Microsoft Intune
- Use scripts do PowerShell em dispositivos Windows 10/11 no Intune
Com as opções compreendidas e as decisões de conceção tomadas, a organização é capaz de criar a primeira política de auditoria com o Assistente de Controlo de Aplicações do Windows Defender:
Abra o Assistente de Controlo de Aplicações do Windows Defender e selecione "Criador de Políticas".
No Criador de Políticas, selecione Formato de Política Múltipla e Política Base e, em seguida, selecione Seguinte.
No Modelo de Política, são-lhe apresentadas três opções:
- O Modo Predefinido do Windows inclui SO windows, Aplicações da Loja, Microsoft 365 Apps para Enterprise (Office 365 Pro Plus) e controladores de kernel assinados whQL.
- Permitir o Modo Microsoft inclui todas as secções no Modo Predefinido do Windows e Todas as aplicações assinadas pela Microsoft.
- O Modo Assinado e Respeitável inclui todas as secções anteriores e Reputation-Based inteligência.
Importante
Reputation-Based Intelligence for Application Control não cumpre o Controlo de Aplicações Essential Eight devido ao requisito "Conjunto aprovado pela organização" (ISM 1657) e "Os conjuntos de regras de controlo de aplicações são validados numa base anual ou mais frequente" (ISM 1582). Esta funcionalidade no WDAC não cumprirá os requisitos para ML2 ou ML3. A Microsoft recomenda a utilização do Reputation-Based Intelligence para a adoção organizacional do WDAC fora do contexto do Controlo de Aplicações Essential Eight.
- Selecione Modo Predefinido do Windows ou Permitir Modo Microsoft consoante os requisitos da sua organização. Para este documento, a Microsoft está a utilizar Permitir o Modo Microsoft.
- Modifique o Nome da Política e a Localização para o Nome da Política e a Localização do Ficheiro de Política pretendidos para armazenar o ficheiro e selecione Seguinte.
Observação
As Informações Detalhadas do WDAC – Regras de Política podem ser encontradas aqui.
- Desativar a Imposição de Script definida como "Desativado" é necessária para a ISM 1657 e 1658 para controlar Scripts, Aplicações HTML e HTML aplicadas.
- O Gráfico de Segurança Inteligente definido como "Desativado" é necessário para ISM 1657, 1658 e 1582.
- O instalador gerido é recomendado para ser "Ativado" para ajudar uma organização com o ciclo de vida da política WDAC.
- A Integridade do Código do Modo de Utilizador é necessária para que as políticas WDAC se apliquem tanto ao modo kernel como aos binários do modo de utilizador.
- A opção Permitir Políticas suplementares é necessária para utilizar o formato de várias políticas para ajudar uma organização com o ciclo de vida da política WDAC.
Observação
Todas as outras regras de política do WDAC dependem dos requisitos numa organização.
- Nas Regras de Assinatura, o administrador consegue ver todos os certificados da Microsoft que foram adicionados como Permitir Regras do Publicador. Vamos abordar Adicionar Regra Personalizada mais à frente neste artigo.
- Selecione Avançar.
O Assistente de Controlo de Aplicações do Windows Defender gera:
- XML de Política
- {GUID}. CIP
As Informações Detalhadas do WDAC – Regras de Política podem ser encontradas aqui.
Observação
Cada política gerada através do Assistente de Controlo de Aplicações do Windows Defender obtém um novo Identificador Exclusivo Global (GUID).
A política WDAC foi criada com êxito.
Uma vez que a organização criou a política WDAC com o Assistente do WDAC, a organização consegue ver o contexto deste ficheiro num editor de texto. O XML é dividido em várias secções diferentes, para o contexto do Essential Eight, tome nota do PolicyID e do BasePolicyID.
Observação
Embora seja possível editar diretamente o XML da Política. A Microsoft recomenda que todas as alterações adicionais às regras de política ou aos ficheiros de assinatura sejam efetuadas através do Assistente de Controlo de Aplicações do Windows Defender ou cmdlets de Integridade de Código Configuráveis no PowerShell.
Agora que a organização criou uma política de auditoria, está na altura de implementá-la com Intune gestão de dispositivos.
- Inicie sessão no centro de administração do Intune.
- No Intune centro de administração, aceda a Dispositivos e, em seguida, Perfis de Configuração.
- Em seguida, crie uma Plataforma de Perfis>– Windows 10 ou Posterior, Modelos de Tipo de Perfil e Personalizado.
- Crie um nome para a política (por exemplo, "Controlo de Aplicações – Permitir Microsoft – Auditoria") e selecione Seguinte.
- Em Definições OMA-URI, selecione Adicionar.
Observação
Estas Informações dependem do ID da Política gerado a partir do Assistente de Controlo de Aplicações do Windows >Defender para o XML de política criado a partir de "Criar Política de Auditoria" na secção acima:
- Nome = Permitir Auditoria da Microsoft
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- Tipo de Dados = Base64 (Ficheiro)
- Quando o Assistente de Controlo de Aplicações do Windows Defender gerou o XML da política, também criou um (GUID). Ficheiro CIP. O ficheiro CIP tem de ser copiado e mudar o nome da extensão de ficheiro para . BIN por exemplo {CB46B243-C19C-4870-B098-A2080923755C}.bin.
- Carregue o BIN em Base64 (Ficheiro).
- Selecione Salvar.
- Siga as instruções para criar o Perfil de Configuração.
- Implemente a política que criou, por exemplo, "Controlo de Aplicações – Permissão da Microsoft – Auditoria", Perfil de Configuração no sistema pretendido.
Após o ciclo de vida da política WDAC, a organização tem de rever os eventos gerados a partir da política "Permitir Auditoria da Microsoft". A monitorização da política de auditoria do WDAC pode ser obtida com dois métodos:
- IDs de eventos do Controlo de Aplicações: os IDs de Eventos do controlo de aplicações são o método tradicional de revisão de eventos auditados num Sistema Operativo Windows. Estes IDs de evento podem ser reencaminhados para uma localização centralizada através do Reencaminhamento do Registo de Eventos do Windows ou da gestão de informações e eventos de Segurança de terceiros.
Para obter informações sobre os IDs de eventos, veja Compreender os IDs de eventos do Controlo de Aplicações – segurança do Windows.
- Microsoft Defender para Ponto de Extremidade (recomendado): os eventos relacionados com o Windows Defender para Endpoint e o AppLocker são capturados na Investigação Avançada para Microsoft Defender para Ponto de Extremidade. As informações incluídas nos eventos são Device, FileName, FolderPath, InitiatingProcessFileName, File Hashes e muito mais. Veja: Consultar eventos do Controlo de Aplicações com Investigação Avançada (Windows) – Segurança do Windows
A Microsoft recomenda a utilização da integração de Microsoft Defender XDR (MDPE) para Microsoft Sentinel. MDPE e Sentinel permitem que os dados telemétricos de Investigação Avançada sejam armazenados durante mais de 30 dias, em comparação com o Microsoft Defender para Ponto de Extremidade.
Para obter informações detalhadas sobre ligações e monitorização, consulte os seguintes artigos:
- Ligar dados de Microsoft Defender XDR a Microsoft Sentinel
- Agente do Azure Monitor em dispositivos cliente Windows
- Recolher eventos e contadores de desempenho de máquinas virtuais com o Agente do Azure Monitor
O exemplo seguinte demonstra que um utilizador tem várias aplicações utilizadas para as tarefas diárias de uma organização. O exemplo contém aplicações da Microsoft e várias aplicações código aberto.
Como o exemplo está no modo de auditoria de imposição, pode ser visto pelo administrador (mas não afeta o utilizador) que os eventos acionados para WinSCP, VLC, Putty e FileZilla, uma vez que estas aplicações não fazem parte da política de auditoria inicial.
Agora, através do portal Microsoft Defender, introduza Investigação Avançada para restringir os eventos de auditoria para compreender que blocos inesperados/indesejados estariam a ocorrer se o modo de auditoria fosse desativado e, assim, transformado em modo de imposição neste exemplo.
Com o esquema de referência da página anterior, procure todos os eventos de Auditoria de Política acionados pelo WDAC dos últimos sete dias e apresenta informações relevantes com a consulta KQL (Keyboard Query Language) de exemplo:
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId, // The device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
Eis um exemplo de uma saída com a consulta KQL anterior.
Nos registos, existe um relatório detalhado de informações como a Árvore de Processos, Caminho do Ficheiro, Informações SHA, Signatário e Informações do Emissor.
O próximo passo consiste em restringir os resultados.
Com a mesma consulta KQL, adicione outro campo em que o Nome do Ficheiro do Processo de Início é Windows Explorer. A consulta KQL apresenta as aplicações executadas pelos utilizadores na GUI.
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId, // The device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
Eis um exemplo de uma saída com a consulta KQL anterior.
A ação de consulta KQL reduziu agora as informações para um conjunto de dados mais de gestão. O que se pode ver são as aplicações que estão a ser utilizadas pelos sistemas pretendidos. Estas aplicações têm de ser adicionadas à política da organização ou consideradas como adicionadas através do controlo de alterações organizacionais.
Observação
O KQL é uma ferramenta avançada para apresentar conjuntos de dados estruturados e não estruturados. Este é apenas um exemplo de utilização de KQL e a Microsoft recomendaria rever a seguinte documentação: Saiba mais sobre a linguagem de consulta de investigação avançada no Microsoft Defender XDR
Atualizar a política de auditoria com o assistente de Microsoft Defender para Ponto de Extremidade e WDAC
Com uma redução dos nossos resultados de pesquisa através de KQL, o passo seguinte é atualizar a política base do WDAC ou utilizar uma política de suplementos. O exemplo seguinte utiliza políticas de suplementos.
Abra o Assistente de Controlo de Aplicações do Windows Defender e selecione Criador de Políticas.
No Criador de Políticas, selecione Formato de Política Múltipla e Política Suplementar, navegue para a sua política base, atualize a localização para guardar a sua Política Suplementar e selecione Seguinte.
Selecione Seguinte em Regras de Política.
Em Regras de Assinatura de Políticas , selecione Regra Personalizada.
Dentro das Condições de Regra Personalizada, estão disponíveis muitas opções:
- Regra de Modo de Utilizador do Âmbito da Regra/Regra do Modo de Kernel
- Ação de Regra: Permitir/Negar
- Tipo de Regra
- Publicador (recomendado)
- Arquivo
- File Attribute
- Aplicação Empacotada
- Hash
- Ficheiro de Referência
Observação
A Microsoft recomenda a utilização de regras baseadas no Publisher, sempre que adequado, e reverter para regras baseadas em Hash para ficheiros de referência não assinados para implementar o Controlo de Aplicações Essential Eight.
Utilizar Microsoft Defender para Ponto de Extremidade
- Pesquise Nome do Ficheiro na Pesquisa , navegue para o ficheiro Informações e transfira o ficheiro.
- Inspecione o registo diretamente a partir da Investigação Avançada e transfira o ficheiro que, em seguida, transfere os binários necessários.
- Com os binários necessários, continue a criar outra política para as aplicações ISV da sua organização.
- No Assistente de Controlo de Aplicações do Windows Defender, selecione o Tipo de Regra pretendido e navegue para os binários de referência do passo anterior. O exemplo seguinte demonstra que o VLC cumpre as informações necessárias do publicador.
Observação
A Microsoft recomenda que a AC emissora, o Publisher, seja seletiva no mínimo para criar uma regra baseada no publicador. O nome do produto pode ser incluído e é recomendado pelo ACSC para regras baseadas no publicador.
- Prima Seguinte e Criar.
- Implemente esta Política suplementar com os passos descritos anteriormente na secção "Implementar a Política de Auditoria de Controlo de Aplicações do Windows Defender através de Microsoft Intune".
Para mudar para impor a política:
Abra o Assistente de Controlo de Aplicações do Windows Defender e selecione Política Editor.
Navegue para o XML de Política que deve ser alterado para imposto.
Desative o comutador Modo de Auditoria nas Regras de Política.
Selecione Seguinte em Regras de Política.
É criada uma Política de Atualização com um número de versão alterado e foi criado um novo ficheiro CIP.
No Centro de Administração do Microsoft Endpoint Manager, aceda a Dispositivos e, em seguida, a Perfis de Configuração.
Em seguida, crie um Perfil, Plataforma – Windows 10 ou Posterior, Modelos de Tipo de Perfil e Personalizado.
Crie um nome para a política, por exemplo Controlo de Aplicações – Impor Política e selecione Seguinte.
Em Definições OMA-URI, selecione Adicionar.
Observação
Estas Informações dependem do ID da Política gerado a partir do Assistente de Controlo de Aplicações do Windows Defender para a política XML criada na secção criar auditoria acima.
- Name = Microsoft Allow Enforce
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- Tipo de Dados = Base64 (Ficheiro)Quando o Assistente de Controlo de Aplicações do Windows Defender gerou o XML da política, também criou um (GUID). Ficheiro CIP. O passo seguinte é copiar este Ficheiro CIP e mudar o nome da extensão de ficheiro para . BIN por exemplo {CB46B243-C19C-4870-B098-A2080923755C}.bin.
Carregue o BIN em Base64 (Ficheiro).
Selecione Salvar.
Siga as instruções para criar o Perfil de Configuração.
Implementar o Controlo de Aplicações – Impor o Perfil de Configuração de Políticas ao sistema pretendido.
Observação
O administrador tem de excluir a Aplicação criada anteriormente – Política de Auditoria do sistema pretendido que está a ser mudado para impor