Configurar a Proteção Web do Sophos Firewall com Políticas Web

A Proteção Web do Sophos Firewall controla quais sites, categorias e conteúdos web os utilizadores podem acessar. Na prática, a Proteção Web não é apenas uma única configuração. Uma política web deve ser planeada tecnicamente, ativada numa regra de firewall adequada e depois testada com tráfego real.

Muitos erros ocorrem porque uma política web existe, mas não é aplicada a uma regra de firewall ativa. Outros problemas estão relacionados com HTTPS, Inspeção TLS, QUIC, reconhecimento de utilizadores, ordem das regras ou exceções muito amplas. O procedimento sensato é: planear a política, construir a regra, ativar, testar e monitorizar em operação.

Qual artigo de Proteção Web é adequado?

A Proteção Web sobrepõe-se a regras de firewall, Inspeção TLS, QUIC, relatórios e exceções. Dependendo da tarefa, um artigo mais específico pode ser mais adequado:

• Configurar Proteção Web e Políticas Web de forma geral: Este artigo.
• Avaliar categorias web, grupos de URLs e alertas instantâneos: Utilizar Categorias Web e Alertas Instantâneos do Sophos Firewall.
• Descriptografar e verificar tráfego HTTPS: Implementar corretamente a Inspeção TLS do Sophos Firewall.
• Distribuir certificado CA para clientes geridos: Distribuir Certificado CA do Sophos Firewall para Inspeção TLS.
• Classificar QUIC e HTTP/3 em problemas de filtragem web: Bloquear corretamente QUIC e HTTP/3 no Sophos Firewall.
• Descobrir qual regra de firewall e política realmente se aplica: Testar regras do Sophos Firewall com Log Viewer, Policy tester e Packet Capture.
• Avaliar eventos web e de segurança por mais tempo: Central Firewall Reporting ou Enviar Syslog para SIEM.

Assim, a análise permanece clara: primeiro deve-se verificar se a regra de firewall corresponde. Depois, verifica-se a política web, categoria, contexto do utilizador, QUIC, Inspeção TLS e registo.

O que a Proteção Web controla

A Proteção Web é composta por vários componentes. Nem todos os componentes precisam ser usados em todos os ambientes, mas as inter-relações devem ser claras.

• Política Web: Regras para acessos web permitidos, avisados, bloqueados ou baseados em quotas.
• Categorias Web: Categorias Sophos e categorias próprias para sites.
• Grupos de URLs: Listas de domínios próprias para regras de permissão ou bloqueio específicas.
• Tipos de ficheiros: Controle de tipos de download ou ficheiros específicos.
• Filtros de conteúdo: Termos ou padrões para controle de conteúdo.
• Exceções: Exceções específicas de comportamento web, TLS ou de análise.
• Configurações gerais: SafeSearch, Restrições do YouTube, Google Apps e Restrições de Inquilinos Microsoft Entra ID.
• Registo e Relatórios: Rastreabilidade no Log Viewer, Reporting, Central ou SIEM.

A Proteção Web não substitui uma base de regras de firewall bem estruturada. A regra de firewall decide primeiro qual tráfego de qual zona para qual zona de destino é permitido. A política web complementa esta regra com controle web. As bases sobre a ordem das regras, origem, destino, serviços e perfis de segurança estão em Compreender e construir regras do Sophos Firewall.

Pré-requisitos

Antes da implementação, estes pontos devem ser esclarecidos:

• A Proteção Web está licenciada ou incluída no pacote utilizado.
• As redes de clientes afetadas têm suas próprias regras de firewall.
• O registo está ativo nas regras relevantes.
• DNS e hora do firewall funcionam corretamente.
• O reconhecimento de utilizadores está esclarecido, caso as políticas se apliquem por utilizador ou grupo.
• A Inspeção TLS está planeada, se os conteúdos HTTPS precisarem ser verificados mais detalhadamente.
• QUIC/HTTP/3 é conscientemente permitido ou bloqueado.
• Existe um grupo piloto e um caminho de fallback para sites críticos para o negócio.

É especialmente importante a separação por grupos-alvo. Uma política web para clientes normais, servidores, convidados, utilizadores VPN e sistemas de gestão não deve ser a mesma. Os servidores geralmente precisam de menos controle de navegação, mas listas de destino e atualização mais rigorosas. Os convidados geralmente precisam de categorias e limitação de largura de banda, mas não de acesso a recursos internos.

Se as políticas web devem reagir a utilizadores ou grupos, o reconhecimento de utilizadores tem de funcionar. AD SSO, Captive Portal, STAS, SATC ou outros métodos não devem ser descobertos apenas durante a implementação da política web. No Log Viewer deve ser visível se um pedido foi avaliado como utilizador conhecido, como grupo ou como Anybody ou utilizador desconhecido.

Planear a Política Web

Uma boa política web não começa na interface, mas com algumas decisões técnicas.

Definir grupos-alvo

Primeiro, determina-se para quem a política se aplica:

• Clientes padrão na LAN
• Notebooks geridos via VPN
• WLAN de convidados
• Salas de formação ou ambientes escolares
• Servidores com acesso HTTP/HTTPS de saída
• Postos de trabalho de administradores privilegiados

Se a mesma regra de firewall contiver vários grupos muito diferentes, a Proteção Web torna-se difícil de entender. É melhor ter regras e políticas separadas, por exemplo, LAN_USERS_WEB, GUEST_WEB ou SERVER_UPDATES_WEB.

Definir Categorias e Grupos de URLs

As categorias web da Sophos são boas para controle amplo: Malware, Phishing, Conteúdo Adulto, Anonimizadores, Streaming, Redes Sociais ou Jogos. Os Grupos de URLs são melhores quando domínios individuais precisam ser permitidos ou bloqueados especificamente.

Uso típico:

• bloquear categorias de risco conhecidas: Categoria Web.
• permitir domínios SaaS específicos: Grupo de URLs.
• tratar um domínio incorretamente categorizado: Grupo de URLs ou categoria própria.
• restringir streaming por tempo: Política Web com Agenda ou Quota.
• Página de aviso em vez de bloqueio rígido: Política Web com ação de aviso.

Os Grupos de URLs não devem se tornar uma lista de coleta desorganizada. Se muitas domínios forem adicionados, a lista precisa de um responsável, um propósito e uma data de revisão. Para listas muito grandes ou dinâmicas, Sophos Firewall Threat Feeds ou outros componentes arquiteturais são frequentemente mais adequados.

Para correspondências puramente por domínio, os Grupos de URLs são normalmente melhores do que categorias web próprias. A Sophos indica que os Grupos de URLs são mais eficientes e podem gerar menos falsos positivos. Categorias próprias são úteis quando um domínio deve aparecer numa lógica de política própria além da sua categoria padrão Sophos.

Keywords em categorias próprias devem ser usadas com muita cautela. As keywords são verificadas contra o URL completo, incluindo caminho e query. Um allow baseado numa keyword pode, por isso, corresponder inadvertidamente se a palavra aparecer num parâmetro de query noutro domínio. Para decisões de allow, domínios concretos ou Grupos de URLs são normalmente mais limpos; regras por keyword encaixam melhor em casos de bloqueio estreitos.

Definir Regras de Permissão com Cuidado

As regras de permissão nas políticas web devem ser restritas. Uma regra de permissão no topo pode tornar ineficazes regras de bloqueio posteriores, pois as regras da política web da Sophos são avaliadas de cima para baixo. Isso é especialmente relevante quando um Grupo de URLs, uma regra de tipo de ficheiro ou uma exceção de categoria está acima de outras regras.

Na prática, funciona bem:

1. Exceções de negócios específicas permitidas no topo.
2. Categorias de bloqueio críticas em seguida.
3. Regras de aviso ou quota para áreas cinzentas.
4. Tráfego web geralmente permitido apenas no final.

Criar a Política Web

A política web é criada no seguinte menu:

Web > Policies

Procedimento básico:

1. Selecionar Add policy.
2. Atribuir um nome descritivo, por exemplo, LAN_USERS_STANDARD_WEB.
3. Adicionar regras.
4. Verificar search engine enforcement, por exemplo SafeSearch ou YouTube restrictions.
5. Definir policy quota status se forem usadas ações Quota.
6. Verificar Advanced settings, especialmente logging, reporting, downloads grandes, Google Apps e Microsoft Entra ID Tenant Restrictions.
7. Guardar a política.

Uma regra dentro da política web é criada com Add rule. O firewall cria primeiro uma regra padrão desativada que bloqueia HTTP para Anybody. Depois, os campos são ajustados de forma deliberada:

1. Abrir Users e definir conscientemente Anybody, utilizadores concretos ou grupos.
2. Abrir Activities e selecionar All web traffic, User activities, Categories, URL Groups, File types ou Content filters.
3. Adicionar Content filters se necessário. Para Content filters, o firewall usa a mesma ação para HTTPS que para HTTP.
4. Definir Action para HTTP: Allow, Warn, Block ou Quota.
5. Verificar a ação HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS ou Quota HTTPS.
6. Definir Constraints se a regra só deve aplicar-se a uma agenda.
7. Verificar a posição da regra dentro da política.
8. Ativar o estado da regra.
9. Guardar a política.

Uma política web por si só ainda não tem efeito. A política deve ser usada numa regra de firewall. Este é um dos erros de configuração mais comuns.

As regras numa política web são avaliadas de cima para baixo. Uma regra Allow para All web traffic acima de uma regra Block torna a regra de bloqueio praticamente ineficaz. Por isso, após cada alteração, deve-se verificar não só o conteúdo da regra, mas também a ordem e o interruptor de estado.

Ativar a Política Web na Regra de Firewall

A regra de firewall está em:

Rules and policies > Firewall rules

Para tráfego normal de clientes para a Internet, geralmente uma regra de LAN ou de uma zona de clientes para WAN é responsável. Lá, na seção Web filtering, a política web apropriada é selecionada.

Pontos de verificação na regra de firewall:

• A zona de origem e as redes de origem correspondem à rede do cliente.
• A zona de destino é geralmente WAN.
• Os serviços incluem HTTP/HTTPS ou os serviços web desejados.
• Log firewall traffic está ativo.
• Na seção Web filtering, a política web correta está definida.
• Scan HTTP and decrypted HTTPS está ativo quando a verificação de malware web ou conteúdo deve funcionar.
• Use Zero-day protection só faz sentido se os ficheiros forem verificados por HTTP ou HTTPS desencriptado.
• Block QUIC protocol está conscientemente definido.
• Use web proxy instead of DPI engine está conscientemente ativado ou desativado.
• A Inspeção TLS é planeada separadamente e não confundida com a política web.

O Sophos Firewall ativa Block QUIC protocol por padrão quando uma política web é selecionada na regra ou quando Scan HTTP and decrypted HTTPS está ativo. Isto é frequentemente útil, porque QUIC não pode ser verificado como tráfego HTTPS clássico. Mesmo assim, a opção deve ser testada conscientemente: browsers, serviços Google, ferramentas de colaboração e aplicações SaaS individuais podem mudar o comportamento quando QUIC é bloqueado.

Se Application Control também for usado na mesma regra de firewall, existe uma sobreposição importante: algumas Micro Apps, por exemplo uploads ou downloads no Dropbox ou Gmail, são reconhecidas por detalhes de URL. Em ambientes DPI, esse reconhecimento requer uma regra SSL/TLS Inspection adequada com desencriptação. Assim, Application Control pode avaliar essas Micro Apps mesmo que a política web não seja o ponto principal de decisão.

Se uma regra mais geral acima da regra web desejada corresponder, o tráfego não alcança a política web. Em tais casos, Testar regras do Sophos Firewall com Log Viewer e Packet Capture pode ajudar.

Classificar HTTPS, Inspeção TLS e QUIC

Uma grande parte do tráfego web é HTTPS. Sem Inspeção TLS, o firewall vê menos conteúdo. Categorias, SNI, certificados, IP de destino, informações de domínio e metadados ajudam, mas não substituem uma verificação completa de conteúdo.

DPI ou Web Proxy?

Na Proteção Web, deve-se decidir cedo se a regra de firewall afetada usa o DPI Engine ou o Web Proxy. Esta decisão influencia quais funções são aplicadas e quais registos são relevantes posteriormente.

• Modo DPI: padrão moderno para muitas regras de clientes para a Internet. A Inspeção TLS é feita através de regras de inspeção SSL/TLS, Quota não é suportada.
• Modo Web Proxy: Ambientes com comportamento de proxy explícito ou Quota de política. Verificar comportamento do proxy, compatibilidade de navegador/cliente e registos do proxy conscientemente.

Em muitas instalações, o Modo DPI é o melhor ponto de partida. No entanto, se forem necessários tempos de contingência através de Quota, uma regra puramente DPI não é suficiente. Nesse caso, o Modo Web Proxy deve ser planeado e testado conscientemente. Esta decisão deve ser tomada antes da implementação, pois uma mudança posterior pode gerar outros problemas, registos e experiências do utilizador.

O Web Proxy filtra na regra de firewall apenas as portas clássicas 80 e 443. O DPI Engine pode inspecionar tráfego HTTP e SSL/TLS noutras portas, desde que a regra e as regras SSL/TLS Inspection correspondam. Em designs de proxy direto, também deve ficar claro se os clientes usam explicitamente o proxy ou se o tráfego transparente normal passa pela regra. Caso contrário, testa-se facilmente o caminho errado.

Inspeção TLS

Se downloads, verificação de malware, certas categorias web ou controles de conteúdo precisarem ser verificados de forma confiável, a Inspeção TLS deve ser planeada. Para isso, é necessário um certificado CA confiável nos clientes, regras TLS adequadas, exceções e um piloto limpo.

A implementação está em Implementar gradualmente a Inspeção TLS no Sophos Firewall. Para distribuir e validar o certificado CA, consulte Instalar Certificado CA do Sophos Firewall para Scanning HTTPS.

QUIC e HTTP/3

Os navegadores modernos frequentemente usam QUIC ou HTTP/3 sobre UDP 443. Isso pode interferir nas expectativas de filtragem web, inspeção TLS e verificação, se se pretende verificar o tráfego HTTPS clássico sobre TCP.

Em muitos ambientes empresariais, é sensato bloquear QUIC em regras de clientes para que os navegadores voltem para HTTPS sobre TCP. Os detalhes estão em Bloquear corretamente QUIC e HTTP/3 no Sophos Firewall.

SafeSearch, YouTube e Restrições de Inquilinos

O Sophos Firewall pode definir controles adicionais de pesquisa e nuvem em políticas web.

Opções típicas:

• Enforce SafeSearch para Google, Yahoo e Bing.
• Enforce YouTube restrictions para conteúdos restritos do YouTube.
• Restrict login domains for Google Apps para domínios Google permitidos.
• Apply Microsoft Entra ID tenant restrictions para controle de inquilinos na nuvem Microsoft.

Essas funções são úteis, mas não mágicas. No caso de HTTPS, a eficácia depende parcialmente da verificação HTTPS ou Inspeção TLS. Além disso, não substituem a governança de identidade e aplicativos na nuvem no Microsoft 365 ou Google Workspace. Para ambientes produtivos, deve-se testar o efeito com utilizadores de teste reais e os navegadores afetados.

No Bing e Yahoo, SafeSearch só pode ser imposto em ligações HTTPS se HTTPS scanning estiver ativo na regra de firewall afetada. As restrições de login do Google Apps aplicam-se apenas a domínios alojados pela Google. Microsoft Entra ID Tenant Restrictions precisam de valores de tenant limpos e devem ser testadas com logins reais na cloud Microsoft, não apenas com um URL de exemplo.

Quota e Páginas de Aviso

As políticas web podem não apenas bloquear ou permitir. Com ações de aviso ou quota, pode-se informar conscientemente os utilizadores ou permitir acesso temporário.

Exemplos úteis:

• Os utilizadores podem confirmar conscientemente um aviso para certas áreas cinzentas.
• Streaming ou compras são permitidos apenas por tempo limitado.
• Ambientes escolares ou de laboratório permitem certas categorias apenas durante horários definidos.

Importante: A Quota de política não é suportada no Modo DPI. Se forem necessários tempos de contingência, o Modo Web Proxy deve ser usado. Isso deve ser decidido cedo, pois DPI e Web Proxy têm características e limites diferentes.

A allowed time quota é definida ao nível da política web e aplica-se a todas as regras dessa política que usam uma ação Quota. Se duas categorias precisarem de quotas temporais diferentes, políticas web separadas são mais limpas do que uma única política com expectativas de quota misturadas. As quotas são repostas localmente à meia-noite e não podem ser definidas como zero.

Policy Overrides são uma ferramenta diferente das quotas. Permitem que utilizadores autorizados no User Portal criem acesso temporário a sites normalmente bloqueados. Isto pode ser útil para escolas ou cenários de suporte, mas precisa de limites claros: categorias não contornáveis, pessoas autorizadas, janelas de tempo e revisão dos overrides.

Web Exceptions e exceções TLS

Web Exceptions são poderosas e, por isso, perigosas quando usadas como reparação rápida. Uma exceção em Web > Exceptions pode ignorar verificações de proteção para tráfego correspondente, independentemente da política web atualmente aplicada. Conforme a seleção, são ignorados HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection ou Policy checks.

Em ambientes DPI aplica-se uma limitação importante: Web Exceptions só têm efeito quando existe uma política web definida, Malware and content scanning está ativo ou ATP está ativo. SSL/TLS Exclusion Rules são, por outro lado, o local correto quando o objetivo é apenas não desencriptar determinadas ligações TLS. A diferença operacional é importante:

• SSL/TLS Exclusion Rule: exclui ligações TLS da desencriptação de forma direcionada, normalmente por Certificate Pinning ou incompatibilidade.
• Web Exception: pode ignorar verificações de política web, verificação de malware, análise Zero-Day ou validação de certificados.
• URL Group in Web Policy: controla Allow, Warn, Block ou Quota dentro da lógica normal da política.

Para exceções, devem evitar-se domínios raiz e padrões URL regex demasiado amplos. Um padrão como example.com também pode aparecer em caminhos ou parâmetros de query de outros domínios. Hostnames concretos, Grupos de URLs adequados e um scope claro por origem, destino, categoria ou grupo de utilizadores são melhores.

As exceções combinam os seus diferentes critérios com AND. Dentro de um tipo de critério, por exemplo vários URL Patterns, aplica-se OR. Isto é prático, mas sujeito a erros: uma exceção com URL Pattern e Source IP só se aplica se ambos corresponderem. Uma exceção com muitos URL Patterns pode, pelo contrário, atuar muito mais amplamente do que esperado.

É preciso ter especial cuidado com Policy checks. Se uma Web Exception ignorar Policy checks, pode enfraquecer indiretamente outras decisões de regras. Em combinação com Synchronized Security Heartbeat, uma exceção desse tipo pode fazer com que pedidos web não sejam bloqueados como esperado, embora existam controlos Heartbeat na regra de firewall.

Testar a Proteção Web

Após guardar, não se deve apenas verificar se a política existe. O crucial é se ela se aplica ao tráfego real.

1. Usar o Policy Tester

Em Web > Policies, está disponível o Policy tester. Com ele, pode-se verificar qual decisão de política é esperada para utilizadores, URLs e contexto.

O Policy Tester é uma boa pré-verificação, mas não substitui um fluxo de pacotes real. Uma regra de firewall, NAT, Inspeção TLS, QUIC ou roteamento ainda pode impedir que a política esperada se aplique ao tráfego real.

2. Teste Real com Cliente Piloto

Com um cliente piloto, verificar:

• site de negócios permitido
• categoria bloqueada
• categoria de aviso
• Permissão de Grupo de URLs
• Bloqueio de Grupo de URLs
• Página HTTPS com e sem Inspeção TLS
• Download de um tipo de ficheiro de teste inofensivo
• Comportamento com QUIC ativo ou bloqueado

3. Verificar o Log Viewer

No Log Viewer, deve ser visível:

• qual regra de firewall foi atingida
• qual utilizador foi reconhecido, se relevante
• qual categoria web ou grupo de URLs esteve envolvido
• se HTTPS, Inspeção TLS ou verificação de malware estiveram envolvidos
• se a ação permitiu, avisou ou bloqueou
• se uma Web Exception ou TLS Exclusion foi aplicada
• se um download foi tratado de forma diferente por tamanho, erro de verificação de malware ou análise Zero-Day

Em Syslog ou SIEM, URL e action não são suficientes. Para uma análise robusta, também são necessários Firewall Rule ID, utilizador, categoria, política web, método HTTP, status, resultado da verificação, indicação de exceção e relação SSL/TLS. Se estes campos estiverem ausentes no SIEM ou forem normalizados incorretamente, a Proteção Web parece rapidamente menos clara nos relatórios do que realmente é no firewall.

Para resolução de problemas mais aprofundada, também são relevantes os ficheiros de log. A atribuição está em Resolução de Problemas do Sophos Firewall: Serviços e Logs.

Alertas Instantâneos e Relatórios

Se certas categorias não apenas devem ser bloqueadas, mas também relatadas ativamente, os Alertas Instantâneos podem ser úteis. Isso é particularmente útil em escolas, ambientes altamente regulados ou áreas com uma política clara de uso da Internet.

Os três métodos de avaliação respondem a diferentes perguntas:

• E-mail rápido para poucas categorias web sensíveis: Alertas Instantâneos.
• Relatórios recorrentes, tendências e avaliações de utilizadores ou categorias: Central Firewall Reporting.
• Retenção mais longa, correlação com outros sistemas ou processos SOC: Syslog ou SIEM.

Antes dos Alertas Instantâneos, deve-se esclarecer quem recebe a notificação, quais categorias realmente desencadeiam uma reação, como os falsos positivos são tratados e quando a seleção de categorias é revisada. Uma lista de alertas ampla sem responsável gera rapidamente ruído de e-mail, mas não melhora a segurança.

Para a ativação técnica e triagem, consulte Utilizar Categorias Web e Alertas Instantâneos do Sophos Firewall. Para avaliações de longo prazo, deve-se considerar Central Firewall Reporting ou Enviar Syslog do Sophos Firewall para SIEM.

Gerir Alterações e Exceções em Operação

A Proteção Web muda continuamente em operação. Novos serviços SaaS são adicionados, domínios individuais são categorizados incorretamente, departamentos precisam de acesso temporário e o comportamento dos navegadores muda. Sem um procedimento claro, rapidamente surgem exceções amplas que ninguém pode explicar mais tarde.

Para cada alteração, deve-se pelo menos registrar:

• Quem precisa de acesso? evita exceções globais para poucos utilizadores.
• Qual domínio, categoria ou tipo de ficheiro está envolvido? separa claramente Grupo de URLs, Categoria Web e Tipo de Ficheiro.
• É uma exceção temporária ou permanente? força revisão em vez de aprovações permanentes.
• Qual regra de firewall e política web são afetadas? evita alterações na regra errada.
• Como será testado? torna o sucesso verificável no Log Viewer.

Um pequeno procedimento de mudança tem se mostrado eficaz:

1. Registrar o pedido com utilizador, URL, horário, motivo de negócios e captura de tela ou mensagem de erro.
2. Verificar no Log Viewer qual regra de firewall, política web, categoria e ação foram aplicadas.
3. Decidir se a categoria está fundamentalmente errada, se apenas um domínio individual deve ser liberado ou se o pedido é rejeitado.
4. Se uma exceção for necessária, trabalhar o mais restritamente possível: grupo de URLs individual em vez de categoria inteira, grupo de utilizadores individual em vez de toda a LAN.
5. Verificar a alteração numa regra de teste ou grupo piloto.
6. Após guardar, realizar um teste real e documentar Log Viewer, categoria, ID da regra e contexto do utilizador.
7. Definir uma data de revisão, especialmente para exceções temporárias de negócios.

Exceções temporárias devem ser claramente nomeadas, por exemplo, TMP_ALLOW_vendor-portal_until_2026-07-31. Exceções permanentes de negócios também precisam de um responsável. Se ninguém for responsável por uma exceção, ela não deve permanecer permanentemente na política.

Se muitos domínios individuais surgirem para o mesmo serviço, geralmente o problema não é a política web, mas a arquitetura do serviço. Então, deve-se verificar se uma regra de firewall própria, uma política web própria, um grupo de URLs bem mantido ou outro ponto de controle é mais adequado. Para listas dinâmicas de IOC ou de bloqueio, as exceções de política web geralmente não são o local correto; para isso, são mais adequados Sophos Firewall Threat Feeds.

Rollback e Liberação de Emergência

Uma alteração na política web pode afetar imediatamente o trabalho produtivo. Portanto, antes de grandes alterações, deve-se definir como restaurar o estado anterior.

Opções práticas de rollback:

• Duplicar ou documentar a política web afetada antes da alteração
• Testar a alteração primeiro numa regra piloto ou pequeno grupo de utilizadores
• Não excluir imediatamente a regra de firewall antiga ou a política web antiga
• Definir janela de tempo, utilizadores de teste e critério de fallback
• Após guardar, verificar Log Viewer, ID da regra e decisão de categoria

Para bloqueios agudos, não se deve inserir reflexivamente uma regra de permissão ampla no topo. É melhor uma exceção restrita e temporária com um grupo de URLs claro, grupo de utilizadores e data de revisão. Se a pressão for alta, uma exceção temporária pode estabilizar a operação, mas deve ser reavaliada posteriormente.

Erros Comuns

A Política Web não se aplica

Geralmente, a política não está ativada na regra de firewall correta, a regra não é atingida, uma regra acima permite o tráfego ou o contexto do utilizador não corresponde. Primeiro, verificar Log Viewer e ID da regra.

HTTPS não é bloqueado como esperado

Sem Inspeção TLS, o firewall vê menos detalhes. Dependendo do destino, uma decisão de domínio ou categoria pode funcionar, enquanto a verificação de conteúdo, tipos de ficheiros ou certas funções de pesquisa permanecem limitadas.

Se a ligação não for desencriptada, o firewall ainda pode usar informações SNI ou de domínio para decisões de política. Páginas de bloqueio, páginas de aviso, tipos de ficheiros, Content Filters, verificação de malware e análise Zero-Day precisam, porém, de mais visibilidade. Por isso, no Log Viewer deve-se verificar não só a ação da política web, mas também o estado SSL/TLS Inspection.

QUIC contorna a expectativa

Se os navegadores usarem UDP 443, o tráfego pode ser processado de forma diferente do HTTPS clássico sobre TCP. Em regras de clientes, deve-se decidir conscientemente se o QUIC é bloqueado.

Regra de Permissão está muito acima

Uma regra de permissão ampla no início da política web pode anular regras de bloqueio posteriores. A ordem das regras dentro da política web é tão importante quanto a ordem das regras na lista de regras de firewall.

Muitas Exceções

Exceções resolvem rapidamente um problema individual, mas podem reduzir a eficácia da proteção. Cada exceção precisa de um propósito, responsável e data de revisão. Se muitas exceções surgirem, geralmente a estrutura da política está errada ou uma aplicação de negócios precisa de uma regra própria.

São especialmente arriscadas as Web Exceptions que ignoram Policy checks ou Malware and content scanning. Se apenas HTTPS decryption causar problemas, uma SSL/TLS Exclusion é normalmente mais estreita e mais compreensível.

Relatórios não mostram nada

Então, deve-se verificar registo, relatórios, regra de firewall, seleção de política ou encaminhamento de logs. Uma política sem registo é difícil de avaliar em operação.

Lista de Verificação de Operação

• Status da licença de Proteção Web verificado.
• Tráfego de clientes, servidores, convidados e VPN avaliado separadamente.
• Política web criada com nome descritivo.
• Categorias críticas e Grupos de URLs planeados conscientemente.
• Ordem das regras dentro da política web verificada.
• Política web ativada na regra de firewall apropriada.
• Log firewall traffic, logging da política web e Reporting ativos.
• Regras da política web ativadas e na ordem correta.
• Inspeção TLS e certificado CA para grupo piloto verificados.
• Estratégia QUIC definida.
• Web Exceptions e TLS Exclusions documentadas separadamente.
• Policy Tester e testes reais realizados.
• Log Viewer e relatórios controlados.
• Processo de alteração para exceções de política web definido.
• Exceções temporárias com data de validade atribuída.
• Exceções documentadas com responsável e data de revisão.

FAQ