Configurar e testar o Application Control no Sophos Firewall

Application Control no Sophos Firewall identifica aplicações independentemente da porta. Isto permite, por exemplo, permitir, bloquear ou registar ferramentas de controlo remoto, aplicações de tunneling, streaming, armazenamento cloud, mensageiros ou contornos de browser arriscados.

O benefício prático só surge quando o Application Control está ativo na regra de firewall correta, a aplicação é realmente reconhecida e os logs são analisados. Uma política de filtro de aplicações armazenada por si só não bloqueia nada.

Resposta rápida

O Application Control é utilizado em dois passos:

1. Em Applications > Application filter, planeie ou crie uma política de filtro de aplicações.
2. Na regra de firewall apropriada, em Other security features, selecione Identify and control applications (App control).

Em vistas de navegação mais antigas, esta área pode aparecer em Protect > Applications > Application filter. Depois, é necessário testar com um cliente real se o tráfego passa por essa regra e se a aplicação é corretamente reconhecida no Log Viewer. Para tráfego encriptado, a inspeção TLS pode ser crucial, pois a firewall pode ver menos detalhes dependendo da aplicação.

Quando o Application Control é útil

O Application Control é especialmente útil quando as portas por si só não são suficientes. Muitas aplicações usam HTTPS, destinos variáveis ou infraestrutura cloud. Uma regra de porta simples só vê 443, mas não se é um serviço empresarial permitido, uma ferramenta de controlo remoto ou um armazenamento cloud indesejado.

Casos típicos de uso:

• Bloquear TeamViewer, AnyDesk, Tor ou ferramentas de proxy
• Restringir streaming ou redes sociais em determinadas redes
• Controlar armazenamento cloud
• Limitar mensageiros ou jogos em redes de convidados ou escolares
• Ativar reconhecimento de aplicações para relatórios e análises
• Preparar Traffic Shaping para aplicações reconhecidas

Se o objetivo não é reconhecimento ou bloqueio, mas sim priorização ou limitação de largura de banda, consulte Configurar Application Traffic Shaping no Sophos Firewall.

Pré-requisitos

Antes da configuração, verifique os seguintes pontos:

• Web Protection Subscription válida
• Regra de firewall afetada é conhecida
• Log firewall traffic está ativo para a regra de teste
• Aplicação ou categoria desejada está claramente definida
• Cliente de teste e destino de teste estão definidos
• Para aplicações HTTPS, está claro se a inspeção TLS será usada
• As assinaturas de aplicações e as Pattern Updates funcionam

Verifique o estado da licença em Administration > Licensing. O Application Control, incluindo o Synchronized Application Control, faz parte da Web Protection Subscription. O Synchronized Application Control exige ainda o Security Heartbeat e, por conseguinte, uma Network Protection Subscription, uma conta Sophos Central e um Sophos Endpoint gerido com licença de teste ou completa. Antes da implementação em produção, deve verificar-se não só o pacote da firewall, mas também o estado dos endpoints.

Planear o filtro de aplicações

Um bom filtro de aplicações não é apenas uma longa lista de bloqueios. Primeiro, deve estar claro o que se deseja alcançar.

• Bloquear ferramentas de controlo remoto arriscadas: Bloquear aplicações ou categorias específicas
• Restringir Wi-Fi de convidados: Bloquear categorias indesejadas, deixar serviços básicos permitidos
• Apenas registrar aplicação: Usar Allow com logging e relatórios inicialmente
• Evitar falso positivo: Seleção mais restrita de aplicações em vez de categoria ampla
• Priorizar aplicação crítica para o negócio: Combinar Application Control com Traffic Shaping

Para redes produtivas, um modo de observação é frequentemente útil: ativar o Application Control primeiro, verificar logs e relatórios, depois bloquear de forma direcionada. Assim, é possível ver que aplicações aparecem realmente e se um bloqueio interromperia processos legítimos.

Em critérios amplos, também se deve considerar a manutenção posterior. Novas aplicações são automaticamente consideradas em Application Filter Policies e regras de firewall através de atualizações da base de dados de assinaturas de aplicações. Se uma regra bloquear, por exemplo, todas as aplicações High-Risk, uma nova assinatura High-Risk poderá ser bloqueada posteriormente sem mais alterações manuais à policy. Isto pode ser desejado, mas tem de ser conhecido no processo de change e revisão.

Planear rollout em fases

O Application Control não deve ser ativado de uma só vez para todas as redes. É melhor um rollout pequeno com um grupo de teste claro, logging visível e uma decisão definida de quando a observação se torna bloqueio.

Um procedimento prático:

• Inventário: Descobrir que aplicações aparecem realmente. Filtro de aplicações com logging, ainda sem bloqueio amplo
• Piloto: Verificar utilizadores selecionados ou uma rede de teste. Bloquear aplicações arriscadas específicas, controlar de perto ID da regra e logs
• Implementação: Aplicar política confirmada na rede alvo. Ativar filtro na regra produtiva, documentar exceções
• Operação: Monitorar efeitos e efeitos colaterais. Verificar regularmente relatórios, Log Viewer, Central Reporting ou Syslog

Antes da implementação, deve estar claro que aplicações devem permanecer permitidas. Isto geralmente inclui serviços de atualização, suporte remoto, ferramentas de colaboração, armazenamento cloud, telefonia ou aplicações específicas do setor. Se estas dependências só se tornarem visíveis após o bloqueio, o Application Control rapidamente parece um fator de perturbação em vez de uma função de proteção.

Para a aceitação, vale a pena uma lista de decisões curta: que aplicação será bloqueada, que grupo de utilizadores é afetado, que exceção é permitida, quem é o responsável técnico e quando a policy será revista? Esta documentação é mais importante do que um primeiro filtro perfeito.

Distinguir Application Filter, Application Object e Shaping

Os termos são próximos, mas resolvem tarefas diferentes. Esta distinção poupa muita resolução de problemas:

• Application Filter: define que aplicações são permitidas, bloqueadas ou registadas. Típico para ferramentas de controlo remoto, armazenamento cloud ou um modo de observação.
• Application Object: agrupa aplicações para uma rota SD-WAN baseada em aplicações. Determina, assim, que tráfego de aplicações é encaminhado em conjunto através de determinados gateways e não substitui um Application Filter.
• Application-based Traffic Shaping: prioriza ou limita aplicações reconhecidas. Típico para priorização de Teams, limitação de streaming ou throttling de Wi-Fi de convidados.
• Synchronized Application Control: complementa a deteção de aplicações com dados de sistemas Sophos Endpoint através do Security Heartbeat. Isto ajuda especialmente em programas que a firewall só reconheceria de forma genérica ou nem sequer reconheceria.

Para uma policy de bloqueio ou allow, o Application Filter é o ponto de partida correto. Um Application Object só é necessário para rotas SD-WAN baseadas em aplicações; o procedimento está descrito em Configurar uma rota SD-WAN com failover de gateway no Sophos Firewall. O Traffic Shaping é separado e é acrescentado quando as aplicações reconhecidas devem ser priorizadas ou limitadas.

Synchronized Application Control não substitui regras de firewall bem desenhadas. Requer as subscrições indicadas, Sophos Central, Security Heartbeat e cobertura adequada por Sophos Endpoint. Aplicações recém-detetadas aparecem em categorias próprias, como SyncAppCtl discovered, e não devem ser bloqueadas às cegas. Primeiro verificar, depois categorizar e só então incluir no Application Filter.

As aplicações detetadas recebem automaticamente uma etiqueta de estado: New para aplicações ainda desconhecidas, Mapped para aplicações atribuídas automaticamente a uma categoria e Customized para entradas ajustadas manualmente. A Sophos suporta o Synchronized Application Control para até 15.000 aplicações e guarda apenas as últimas cinco ocorrências por aplicação e endpoint para poupar espaço de armazenamento. Este limite é especialmente relevante quando é preciso reconstruir, para fins forenses, quantas vezes uma aplicação ocorreu num endpoint.

Após uma migração para o SFOS 21.0 ou posterior, se o Synchronized Application Control estiver ativo, também é ativada a limpeza automática com um período predefinido de doze meses. Durante a limpeza, as aplicações adicionadas individualmente também são removidas das Application Filter Policies. Quem precisar de dados históricos ou de filtros mantidos manualmente deve, por isso, verificar este período de forma consciente.

Processar em segurança as aplicações detetadas

Na primeira utilização, o Synchronized Application Control tem de estar ativado no Sophos Central. Depois, abre-se Applications > Synchronized Application Control, pesquisa-se por nome, caminho, categoria ou endpoint e expande-se a entrada para verificar as ocorrências detetadas.

Para uma entrada desconhecida de SyncAppCtl discovered, seleciona-se Customize em Manage > More options. Atribui-se um nome compreensível e a categoria adequada à organização. Acknowledge marca uma entrada verificada como processada sem a alterar, Hide apenas a oculta da vista atual e Show volta a torná-la visível.

Delete não é apenas uma ação de limpeza: também remove a aplicação das Application Filter Policies. Se um endpoint voltar a detetá-la mais tarde, ela reaparece na lista. Antes da eliminação, deve verificar-se que filtros utilizam a aplicação; depois, testam-se novamente a policy, a Firewall Rule ID esperada e um fluxo de tráfego real.

Para o caso de utilização específico da inteligência artificial generativa, Detetar e controlar IA generativa no Sophos Firewall explica como combinar Application Filter, telemetria de Endpoint, fase piloto e reporting.

Criar filtro de aplicações

Caminho do menu:

Applications > Application filter

Em versões anteriores do SFOS, o caminho ainda pode aparecer como Protect > Applications > Application filter.

Procedimento:

1. Abrir Add.
2. Atribuir um nome descritivo, por exemplo, Block_Remote_Control_Tools.
3. Escolher uma policy existente como template, por exemplo uma Allow-All-Policy como ponto de partida para regras de bloqueio específicas.
4. Guardar a policy.
5. Abrir novamente a policy e adicionar uma regra dentro do filtro.
6. Selecionar aplicação, categoria, risco, Characteristics, Technology, Classification ou Smart Filter.
7. Definir a ação, por exemplo Deny ou Allow.
8. Definir o Schedule, caso a regra só deva aplicar-se temporariamente.
9. Guardar a regra e, em seguida, guardar a policy.

Configurar agendamentos para regras e políticas na Sophos Firewall explica como criar o agendamento e validá-lo em relação à hora da firewall, à ordem das regras e às regras de fallback.

Ao lidar com categorias, deve-se ter cuidado. Uma categoria ampla pode afetar mais aplicações do que o esperado. Para testes iniciais, aplicações individuais ou grupos bem definidos são frequentemente melhores do que um grande bloco coletivo.

Ao adicionar uma regra, há duas formas típicas de trabalhar. Select All com filtros é adequado quando se pretende abranger um grupo inteiro, por exemplo Category File Transfer, Characteristics Transfer files e Technology Browser Based. Select Individual Application é melhor quando apenas aplicações individuais, como AnyDesk, TeamViewer ou um serviço cloud específico, devem ser afetadas. O Smart Filter procura pelo nome e pela descrição de uma aplicação; não substitui uma validação técnica da lista de resultados.

O filtro Classification aplica-se apenas a aplicações cloud. Se uma Cloud-App for reclassificada posteriormente, o Sophos Firewall também atualiza regras baseadas nessa Classification. Estas regras são práticas, mas mais dinâmicas do que uma lista fixa de aplicações individuais.

Exemplo: bloquear transferências de ficheiros baseadas no browser

Um bom primeiro exemplo é bloquear transferências de ficheiros baseadas no browser numa rede de convidados ou de clientes. Neste caso, não se bloqueia genericamente toda a categoria File Transfer; a seleção é limitada a transferências de ficheiros baseadas no browser.

Configuração no Application Filter:

1. Abrir Applications > Application filter.
2. Criar uma policy, por exemplo Block_File_Transfer.
3. Escolher uma policy Allow adequada como modelo.
4. Guardar a policy e abri-la novamente.
5. Abrir Add para uma nova regra de filtro.
6. Usar Select All e limitar a seleção com Category: File Transfer, Characteristics: Transfer files e Technology: Browser Based.
7. Definir Action como Deny.
8. Definir Schedule como All the time, se não for necessária programação horária.
9. Guardar a regra de filtro e depois guardar a policy.

Este exemplo é deliberadamente mais restrito do que um bloqueio global de todas as aplicações de transferência de ficheiros. Em muitas empresas, serviços legítimos de cloud, atualização, backup ou colaboração seriam afetados. Antes da utilização produtiva, o filtro deve ser testado no Log Viewer com clientes reais.

Ativar na regra de firewall

O Application Control só tem efeito quando o filtro é selecionado numa regra de firewall.

Caminho do menu:

Rules and policies > Firewall rules

Procedimento:

1. Abrir a regra de firewall pela qual o tráfego afetado realmente passa.
2. Abrir a secção Other security features.
3. Selecionar o filtro de aplicações em Identify and control applications (App control).
4. Ativar Log firewall traffic, pelo menos para teste e aceitação.
5. Guardar a regra.
6. Testar com um cliente definido.

A ordem das regras é crucial. Se o tráfego já for processado por uma regra mais geral acima, ele não alcançará a regra com Application Control. Nesse caso, a configuração no WebAdmin parece correta, mas não tem efeito.

Quando é criada uma nova regra LAN-WAN, o NAT deve ser considerado separadamente. Os exemplos da Sophos usam frequentemente Create linked NAT rule com MASQ para acesso simples à Internet. Em regras produtivas existentes, não se deve criar novas regras NAT sem validação; deve verificar-se que regra SNAT/MASQ já se aplica a esse tráfego.

Para Application-Control-Policies baseadas em utilizadores ou grupos, a regra de firewall tem de fazer realmente match ao contexto do utilizador. Match known users e uma autenticação funcional são tão importantes como o próprio Application Filter. Sem contexto de utilizador, a policy aplica-se apenas a critérios de rede, zonas e serviços.

Em regras novas, deve escolher-se conscientemente entre IPv4 e IPv6. O Application Control é ativado na respetiva regra de firewall. Se um cliente seguir por IPv6 um caminho diferente do IPv4, o teste pode parecer correto apesar de parte do tráfego passar ao lado da regra esperada.

Os fundamentos sobre Source, Destination, Services, Security Features e ordem das regras estão em Entender e configurar regras de firewall do Sophos Firewall de forma segura.

Verificar conscientemente a correspondência da regra

Antes de guardar, a regra deve ser lida como um caso de teste:

• Source zone e Source network: O cliente de teste deve vir realmente por esta zona e por esta rede
• Destination zone e Destination network: Destinos amplos podem funcionar, mas são mais difíceis de rastrear
• Services: Para tráfego web, TCP 80/443 é frequentemente relevante; QUIC usa UDP 443
• Web policy, IPS e TLS Inspection: Várias Security Features podem influenciar o mesmo fluxo
• Log firewall traffic: Sem logging, o efeito é difícil de comprovar no Log Viewer

Quando o Application Control é introduzido pela primeira vez, a primeira regra deve ser preferencialmente um pouco mais estreita e fácil de medir. Uma regra LAN-to-WAN enorme com muitas exceções torna a aceitação claramente mais trabalhosa.

Inspeção TLS e reconhecimento

O Application Control pode reconhecer aplicações baseadas em assinaturas mesmo sem inspeção TLS completa. No entanto, em tráfego encriptado, o DPI-Engine só reconhece Micro Apps baseadas em URL, como transferências de ficheiros do Dropbox ou Gmail, através do URL desencriptado. Para isso, uma regra SSL/TLS inspection adequada tem de desencriptar efetivamente o tráfego.

Se uma aplicação não for reconhecida como esperado via HTTPS, deve verificar-se:

• O tráfego passa pela regra de firewall correta?
• O Application Control está ativo nessa regra?
• A aplicação é reconhecida fundamentalmente pela Sophos?
• A inspeção TLS é necessária e justificável para esse tráfego?
• O cliente utiliza QUIC ou HTTP/3? O QUIC não pode ser analisado e contorna o Web Filtering; para tráfego web controlado, deve verificar-se Block QUIC protocol na regra de firewall adequada.
• Web Policy, IPS ou DNS Protection estão atuando adicionalmente?

A inspeção TLS deve ser introduzida gradualmente e com exceções. O procedimento adequado está em Introduzir corretamente a inspeção TLS no Sophos Firewall. Para QUIC e HTTP/3, consulte Bloquear corretamente o protocolo QUIC e HTTP/3 no Sophos Firewall.

Nas aplicações cloud, a diferença é particularmente visível: dados básicos de bytes e utilização exigem sobretudo que o firewall logging esteja ativo. Informações mais precisas de upload/download e tipo de ficheiro só são vistas de forma fiável quando o HTTPS é desencriptado. Algumas aplicações transferem ficheiros através de mecanismos próprios; nesses casos, campos de detalhe podem ficar vazios ou parecer incompletos apesar de existir tráfego.

Para Cloud-App-Reporting, recomenda-se por isso uma combinação de três pontos: ativar Log firewall traffic para os dados básicos de bytes, desencriptar HTTPS onde forem necessários contadores de upload/download e tipos de ficheiro, e usar uma Web Policy diferente de None para maior precisão. A Web Policy é uma recomendação adicional da Sophos; o requisito indispensável para estes detalhes de ficheiros é a desencriptação HTTPS.

Testar efeito

Após a ativação, não se deve apenas esperar pelo feedback dos utilizadores. Um teste bem feito poupa muito tempo.

Procedimento prático:

1. Defina o cliente de teste e o IP de origem.
2. Inicie a aplicação conscientemente ou aceda ao destino.
3. No Log viewer, filtre por IP de origem, destino, serviço e aplicação.
4. Verifique qual ID de regra de firewall foi atingida.
5. Verifique se o Application Control reconhece a aplicação.
6. Anotar Application ID, categoria, ação e Application Filter.
7. Em caso de bloqueio, verificar se o bloqueio é tecnicamente pretendido.
8. Em caso de deteção incerta, complementar com Packet Capture, logs de serviço e, em logging central, os campos de Syslog.

O tipo de log depende da ação: uma correspondência bloqueada do Application Filter aparece como Content Filtering > Application > Denied. O tráfego permitido e apenas reconhecido aparece, por outro lado, no log da firewall como Firewall > Firewall Rule > Allowed. Para a aceitação, são sobretudo relevantes Firewall Rule ID, utilizador, aplicação, categoria, risco, ação, origem e destino.

Nas avaliações Syslog ou SIEM, também se deve considerar o formato de saída. No atual Central Reporting Format, os campos importantes chamam-se fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier e status. O Device Standard Format (Legacy) utiliza, entre outros, application_filter_policy, application_name, application_category, application_risk e appresolvedby. Os dois conjuntos de nomes não devem ser misturados no SIEM. O respetivo campo de deteção mostra se esteve envolvida uma assinatura, uma deteção por proxy ou Micro App, ou o Synchronized Application Control (EAC).

O Application Filter e a deteção de aplicações do DPI-Engine registam detalhes técnicos em ips.log. A atribuição de logs está em Solução de problemas do Sophos Firewall: Serviços e Logs. Para delimitação com Log Viewer e Packet Capture, consulte Testar regra do Sophos Firewall com Log Viewer, Policy Test e Packet Capture.

Passar da observação para o bloqueio

A passagem da simples deteção para o bloqueio deve ser feita de forma consciente. Em muitos ambientes, é melhor usar primeiro o Application Control como ferramenta de observação e reporting. Depois, devem ser bloqueadas apenas as aplicações cujo risco, grupo de utilizadores e dependência de negócio estejam claros.

Antes de bloquear, deve verificar-se:

• Que utilizadores, redes ou dispositivos usam realmente a aplicação?
• Que regra de firewall e que Rule ID aparecem no Log Viewer?
• A aplicação é detetada de forma fiável ou apenas como categoria genérica?
• Existe utilização empresarial legítima, casos de suporte ou ferramentas do fabricante?
• A aplicação deve ser bloqueada em todos os locais ou apenas em redes de convidados, escolares, clientes ou servidores?
• Quem aprova uma exceção e quando será revista novamente?

Um fluxo prático limpo é: primeiro recolher dados de log, depois bloquear uma aplicação individual ou um pequeno grupo e, em seguida, validar com um cliente de teste e Log Viewer. Se um bloqueio for demasiado amplo, não se deve desativar todo o Application Filter, mas ajustar especificamente a aplicação, categoria ou posição da regra afetada.

Quando o Application Control não se aplica

Em caso de problemas, não se deve desativar imediatamente todo o filtro. Primeiro, deve-se verificar onde o processo falha.

• Nenhuma entrada de log para a ligação de teste: Falta logging ou o tráfego não chega à regra de firewall. Verificar Rule ID, zona de origem e Packet Capture
• Log Viewer mostra outra Rule ID: Uma regra mais geral está acima. Corrigir ordem das regras e critérios de correspondência
• A aplicação permanece unknown ou genérica: O reconhecimento não é suficiente sem mais contexto. Verificar TLS Inspection, QUIC e assinaturas de aplicações
• O bloqueio afeta demasiados serviços: Categoria ou Smart Filter demasiado amplo. Usar aplicações individuais ou grupos menores
• Após uma Pattern Update, subitamente é bloqueado mais tráfego: Uma regra ampla baseada em Risk, Category ou Classification abrange novas assinaturas. Verificar critérios da regra e processo de change.
• Faltam detalhes de Cloud-App: Os contadores de upload/download e os tipos de ficheiro exigem HTTPS-Decryption. Uma Web Policy diferente de None melhora adicionalmente a precisão e o nível de detalhe. Verificar separadamente Cloud-App-Reporting, estado TLS e Web Policy.
• O bloqueio só funciona em alguns clientes: Regra, zona, grupo de utilizadores ou caminho do browser diferente. Comparar cliente de teste, utilizador e caminho de rede
• IPv6 comporta-se de forma diferente do IPv4: Pode existir uma regra IPv6 separada, outro caminho DNS ou outro caminho do browser. Testar conscientemente ambos os protocolos ou considerar IPv6 corretamente no conjunto de regras.

O ponto de verificação mais importante é a Rule ID. Se a regra esperada não for atingida, a política de Application Control quase nunca é a verdadeira causa.

Tratar falsos positivos corretamente

Se o Application Control bloquear tráfego legítimo, não se deve desativar imediatamente todo o filtro.

Ordem sensata:

1. Documente a aplicação afetada e a entrada de log.
2. Verifique qual regra de firewall e qual filtro de aplicação estão envolvidos.
3. Verifique aplicação, categoria e ação no filtro.
4. Verifique se a aplicação é reconhecida de forma diferente pela inspeção TLS.
5. Defina exceção o mais restrita possível: aplicação, rede de origem, grupo de utilizadores ou destino.
6. Documente o responsável e a data de revisão para a exceção.

Uma exceção para Any ou uma categoria ampla resolve rapidamente o caso atual, mas enfraquece o controlo permanentemente. É melhor uma exceção pequena e justificável com uma razão clara.

Erros comuns

• Filtro de aplicação criado, mas não selecionado na regra: Sem efeito no tráfego. Ativar filtro na regra de firewall real
• Tráfego passa por outra regra: Filtro nunca é alcançado. Verificar ID da regra no Log Viewer
• Categoria muito ampla bloqueada: Serviços cloud ou empresariais legítimos afetados. Usar aplicações individuais ou grupos mais restritos
• Filtros dinâmicos mal compreendidos: Risk, Category ou Classification podem produzir novos acertos através de atualizações de assinaturas e Cloud Apps. Rever regularmente.
• Reconhecimento HTTPS sobrestimado: Aplicação não é reconhecida de forma fiável. Verificar inspeção TLS e comportamento QUIC
• Falta de logging: Efeito permanece invisível. Ativar logging de regra para teste e operação
• Exceção muito ampla: Função de proteção é praticamente anulada. Definir exceção restrita e com data de revisão

Verificação operacional

O Application Control deve ser verificado regularmente. As aplicações mudam, os serviços cloud usam novos endpoints, os utilizadores utilizam novas ferramentas e as assinaturas são atualizadas.

Deve-se documentar:

• Propósito do filtro de aplicações
• Regras de firewall afetadas
• Aplicações bloqueadas ou permitidas
• Exceções conhecidas
• Responsável técnico
• Data de revisão
• Última alteração relevante

Se o Application Control for usado para aplicações críticas de negócios, redes escolares ou requisitos de conformidade, o Central Reporting, Syslog ou SIEM também devem ser verificados. Para avaliação central, consulte Ativar Central Firewall Reporting ou Configurar Syslog e SIEM no Sophos Firewall.

Lista de verificação

• Estado da licença verificado.
• Regra de firewall afetada claramente identificada.
• Filtro de aplicações criado com propósito claro.
• Template, filtros dinâmicos e critérios da regra documentados.
• Filtro selecionado na regra de firewall correta.
• Logging de regra ativo.
• Cliente de teste e aplicação de teste definidos.
• Log Viewer verificado para ID de regra e Application Control.
• Utilização real, owner e regra de exceção clarificados antes do bloqueio.
• Percurso IPv4 e IPv6 verificado, se ambos estiverem ativos na rede.
• Inspeção TLS e QUIC avaliados, se o reconhecimento HTTPS for incerto.
• Cloud App Reporting verificado se necessário com HTTPS-Decryption e Web Policy.
• Exceções documentadas de forma restrita.
• Data de revisão definida.

Perguntas frequentes