Como usar corretamente o Sophos Firewall Health Check

O Sophos Firewall Health Check é uma verificação integrada da configuração do firewall. Ele mostra no Control Center se configurações importantes estão de acordo com as recomendações de segurança e práticas recomendadas. Para os administradores, isso é especialmente útil, pois torna visíveis configurações arriscadas antes que se tornem um problema de segurança ou operacional.

Para o contexto geral de hardening, consultar o hub Sophos Firewall Hardening: melhores práticas para uma configuração segura.

A Sophos introduziu o Health Check com o Sophos Firewall v22. Segundo as notas de versão oficiais do SFOS 22.0, a função avalia dezenas de configurações face a benchmarks CIS e outras práticas recomendadas. A afirmação anterior de que o SFOS 22.0 MR1 teria sido a primeira versão a atualizar o contexto CIS não é sustentada por esta fonte.

Como usar este guia

O Health Check fornece uma lista, mas não toma a decisão. Por isso, o guia acrescenta uma avaliação Avanet:

• Prioridade alta: controlo fundamental de segurança ou operação; corrigir ou justificar muito bem.
• Dependente do contexto: útil, mas não para todas as regras, fluxos ou arquiteturas.
• Coberto de outra forma: o objetivo de segurança já é cumprido por um controlo equivalente de outro fornecedor ou por outro processo operacional. Um override documentado pode ser adequado.
• Opcional: função de conformidade ou serviço Sophos adicional; um estado vermelho não significa automaticamente uma configuração insegura.

Esta classificação não substitui uma análise de risco. Evita que uma severidade Sophos baixa minimize um backup importante ou que uma integração opcional se transforme demasiado cedo num projeto de compra.

Para que serve o Health Check

O Health Check não é um estado clássico do sistema nem um sensor de hardware. Não verifica se uma fonte de alimentação está avariada ou se um SSD está prestes a falhar. Para isso, são adequadas outras verificações operacionais, como verificar o estado de saúde do SSD ou a monitorização de HA e hardware.

Para a verificação recorrente do estado atual do sistema, dos serviços, da segurança e dos administradores, utiliza-se a checklist diária de administração da Sophos Firewall. Complementa o Health Check da configuração com Control Center, System graphs, relatórios e eventos.

O Health Check responde mais a estas perguntas:

• Os acessos administrativos estão muito abertos?
• O MFA está ativado para logins críticos?
• As regras de firewall são muito abertas?
• Backups, hotfixes, registos ou funções do Sophos Fusion estão bem preparados?
• A configuração desvia dos padrões de segurança recomendados?
• Existem descobertas que devem ser resolvidas antes de uma auditoria ou go-live?

Assim, é uma boa ferramenta para fortalecimento, revisão e controle de mudanças. No entanto, não substitui uma arquitetura limpa, documentação de regras ou avaliação manual.

⚠️ Um Health Check verde não significa automaticamente que o firewall está seguro. Ele mostra se certas configurações verificáveis estão corretas. Design de rede, lógica de negócios, exceções, grupos de usuários e processos operacionais ainda precisam ser avaliados tecnicamente.

Distinguir o SFOS Health Check do Sophos Fusion Account Health Check

Duas funções com nomes semelhantes respondem a perguntas diferentes. O Firewall health check aqui descrito é executado no firewall desde o SFOS 22.0, verifica continuamente a configuração local e está disponível em Monitor & analyze > Firewall health check ou no widget Control center. A ajuda do SFOS 22 não indica uma licença separada para o Health Check. Funções verificadas individualmente, como NDR, MDR threat feeds ou DNS Protection, podem ainda exigir licenças próprias e depender do Sophos Fusion.

O Sophos Fusion Account Health Check (anteriormente Sophos Central Account Health Check), por outro lado, é um serviço do Sophos Fusion para todo o tenant em My Environment > Account Health Check. As pontuações abrangem produtos, dispositivos e políticas licenciados. Segundo o cálculo das pontuações do Sophos Fusion Health Check, a secção Firewall avalia atualmente os backups automáticos do Sophos Fusion; apenas firewalls licenciados, geridos pelo Sophos Fusion e ligados à plataforma influenciam a pontuação. A ajuda atual indica também que o filtro de produto Network exige MDR Plus e um firewall gerido. A vista do Sophos Fusion não é, portanto, a vista detalhada das 31 verificações locais do SFOS nem a substitui.

As ações também diferem. Fix now no SFOS abre apenas a página de configuração afetada; um administrador revê e guarda a alteração. Fix automatically no Sophos Fusion Account Health Check pode alterar definições. Segundo o procedimento do Sophos Fusion para backups automáticos da firewall, o Sophos Fusion muda por predefinição um agendamento Never para mensal no primeiro dia e adiciona firewalls em falta. Para evitar a alteração automática, deve configurar-se manualmente Global Settings > Products and Services > Firewall > Schedule Backup. Os backups são executados às 08:00 no fuso horário local da região da conta e esta hora não pode ser alterada.

Ao abrir no Sophos Fusion uma sessão WebAdmin do firewall, as permissões de firewall do Sophos Fusion determinam as ações: Full permite alterações, Read-only apenas consulta e Help Desk monitorização, diagnósticos, logs e relatórios. A remediação exige assim uma função autorizada a alterar a definição afetada. O acesso aos diagnósticos ou ao Health Check não equivale a uma autorização de alteração.

Avaliar corretamente a pontuação e o estado

O Health Check é útil, mas não é uma auditoria de segurança independente do fornecedor. Também favorece Sophos Fusion (anteriormente Sophos Central), DNS Protection, NDR Essentials, MDR threat feeds e Synchronized Security. Na perspetiva da Avanet, isto contém uma componente clara de cross-selling: Noncompliant pode indicar uma falha real, como WebAdmin exposto sem MFA, ou apenas a decisão de não usar um serviço Sophos opcional quando Microsoft Defender, outro EDR/NDR, SIEM ou filtro DNS já cobre o objetivo.

Recomendação da Avanet: analisar cada finding, mas não implementar todos sem avaliação. Um ponto vermelho relativo a WebAdmin, MFA, autenticação não cifrada, backups ou regras abertas merece muita atenção. Um ponto vermelho relativo a um serviço Sophos não licenciado é, antes de mais, uma decisão de arquitetura e produto, não uma falha de segurança automaticamente comprovada. O objetivo de segurança, as alternativas existentes e o processo operacional determinam se a resposta correta é ativar, cobrir de outra forma ou aplicar um override justificado.

Portanto, não se deve ativar cada recomendação apenas para que a exibição fique verde. Um exemplo é o aviso de login: em ambientes de auditoria ou conformidade, pode ser exigido um aviso de login. Em muitos ambientes operacionais normais, ele gera principalmente um clique adicional em cada login e não traz praticamente nenhum ganho técnico de segurança. Quando a função é necessária, Configurar o aviso de início de sessão e as mensagens na Sophos Firewall explica a gestão do texto, a pré-visualização, a validação e o rollback. Se isso apenas aumentar a pontuação do Health Check, o valor agregado é limitado.

Para estas funções, deve-se perguntar qual risco reduzem, se já existe um controlo equivalente, que licença e transferência de dados exigem e quem trata alertas, exceções e falsos positivos. Sem respostas claras, um override documentado é mais honesto do que uma função não operada ativada apenas para melhorar a pontuação.

Não se deve confundir NDR Essentials com MDR. NDR Essentials analisa tráfego selecionado do firewall e produz deteções. Sophos MDR significa Managed Detection and Response e é um serviço adicional pago com analistas e processos de incidentes. Os MDR threat feeds só fazem sentido quando esse serviço está realmente licenciado e integrado na operação. Um finding NDR não significa automaticamente que seja necessário comprar MDR.

Como regra geral:

• Acessos de gerenciamento expostos à Internet, MFA, hotfixes, backups, regras de senha, IPS Normalmente, fundamentos reais de segurança ou operação. Esses pontos devem ser levados muito a sério.
• Registros, relatórios, notificações, NTP Importante para operação e rastreabilidade. O caminho específico depende do modelo operacional.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Fusion e Synchronized Security são soluções possíveis, não requisitos universais. Uma alternativa eficaz importa mais do que o logótipo Sophos no controlo.
• Aviso de login Geralmente mais uma função de conformidade/aviso do que uma medida de proteção técnica. Ativar apenas se realmente exigido ou desejado.

Decisão rápida: o que deve ser realmente implementado?

Ao abrir o Health Check pela primeira vez, os findings podem ser separados em quatro grupos de trabalho:

• Verificar imediatamente e normalmente corrigir: 8, 9, 11, 13-20, 22, 25, 28 e 31. Incluem hotfixes, proteção de login, passwords de administrador, MFA, autenticação cifrada, SSH, exposição WAN, pattern updates, IPS, regras amplas e hora correta.
• Muito importantes, mesmo que a Sophos os classifique como Low ou Medium: 16 e 21. Backups exigem um restore testado. Alertas exigem um canal funcional por e-mail, monitoring, Sophos Fusion ou SIEM.
• Decidir por fluxo de tráfego e arquitetura: 3, 5, 10 e 23-27. X-Ops, Heartbeat, regras de password de utilizadores, Web Policy, Zero-Day Protection, Application Control e TLS Inspection não são igualmente úteis em todas as regras.
• Ativar apenas com o ecossistema Sophos adequado ou uma decisão consciente sobre o serviço cloud: 1, 2, 4, 6, 12, 29 e 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection e funções do Sophos Fusion não são requisitos mínimos universais. O ponto 7, Login disclaimer, é sobretudo uma decisão de conformidade.

Esta classificação é deliberadamente mais direta do que a severidade Sophos. Avalia o que reduz primeiro o risco no ambiente real, não o que a Sophos pode vender ou integrar tecnicamente.

Abrir o Health Check

O status do Health Check aparece no Control center. A visão detalhada também pode ser encontrada através do menu principal:

Monitor & analyze > Firewall health check

Lá, você vê o número de configurações verificadas, os pontos conformes e os pontos não conformes. A Sophos mostra entradas não conformes por gravidade. Os dados são atualizados quando uma configuração monitorada é alterada. Isso torna o Health Check adequado também para uma revisão direta após alterações.

Para a revisão, não se deve apenas anotar o status geral. Mais importantes são as descobertas concretas, o contexto de risco e a medida planejada. Uma única descoberta crítica sobre a acessibilidade do WebAdmin pela WAN é mais importante na operação do que várias descobertas de baixa gravidade sem exposição à Internet.

Compreender estado, severidade e override

A vista detalhada mostra, para cada verificação, se a configuração está compliant, noncompliant ou foi substituída manualmente. Para a operação, estes três estados são mais importantes do que a percentagem isolada.

• Compliant: a configuração verificada cumpre a policy correspondente. Após alterações maiores, deve ainda assim ser validada tecnicamente.
• Noncompliant: a configuração verificada não cumpre a policy. É necessário avaliar risco, exposição e viabilidade.
• Manual policy status override: a configuração não cumpre a policy, mas foi marcada manualmente como compliant. Este estado só deve ser usado com justificação, owner e data de revisão.

O menu de ações abre-se através dos três pontos na coluna Action do finding correspondente. Fix now abre a página de configuração relevante, onde é necessário verificar e guardar a alteração. Override status marca manualmente um ponto não conforme como Complies, sem alterar a configuração. Undo override só aparece para uma policy cujo estado já foi substituído e repõe o estado Doesn't comply; não reverte uma correção da configuração. É útil, mas não substitui a avaliação: o Health Check não sabe automaticamente se um controlo equivalente é realmente aplicado noutro local.

A severidade ajuda a ordenar, mas não substitui a avaliação técnica. É uma classificação Sophos estática e não conhece exposição nem controlos compensatórios. Um finding Low por backups ausentes pode ser mais urgente do que um Medium por um serviço Sophos não utilizado.

Se um finding parecer ilógico, também se devem verificar a versão de firmware e os problemas conhecidos. As notas oficiais enumeram para o SFOS 22.0 GA Build 411 as correções NC-165825 para um resultado Doesn't comply incorreto do NDR Essentials em firewalls virtuais, NC-169472 para um finding incorreto de regras de firewall e NC-167645 para a ordenação que não persistia após clicar em Override status. Estes IDs comprovam apenas os defeitos descritos, não uma causa geral para resultados posteriores. Se o comportamento reaparecer num build atual, devem documentar-se a policy, a configuração real e o build antes de envolver o Sophos Support, em vez de alterar uma definição arriscada apenas para obter um estado verde.

As funções de pesquisa e ordenação da tabela Health Check ajudam a agrupar findings por policy, módulo, standard ou severidade. Em firewalls maiores, isto é mais prático do que olhar apenas para o mosaico do dashboard.

Avaliação individual das verificações do Health Check

A lista baseia-se nas 31 verificações da vista inglesa usadas nesta análise. A Sophos pode alterar o número, o nome, o standard ou a severidade com uma atualização de firmware. Se o firewall local mostrar findings adicionais ou com nomes diferentes, essa vista é a referência. O status não é apresentado porque varia entre firewalls. O importante é compreender e avaliar corretamente cada verificação.

Active Threat Response e Advanced Security

• 1. Synchronized Application Control deve estar ativado. Standard: Recommended, Severidade: Medium. Identifica aplicações com maior precisão através do Sophos Endpoint e requer Security Heartbeat; na primeira utilização, também deve ser ativado no Sophos Fusion. Avaliação Avanet: opcional. Ativar apenas quando existem endpoints Sophos compatíveis e as aplicações detetadas serão depois classificadas e utilizadas através de Application Filter. Com Microsoft Defender ou outro produto endpoint, um override justificado é mais útil do que uma ativação sem efeito.
• 2. NDR Essentials deve estar ativado e monitorizar pelo menos uma interface. Standard: Recommended, Severidade: Medium. O firewall analisa tráfego selecionado através do serviço cloud Sophos NDR, deteta IoCs e regista-os, mas não os bloqueia automaticamente. São suportadas determinadas interfaces nas zonas LAN, DMZ e Custom; WAN, Wi-Fi e vários tipos de interface, como RED ou XFRM, estão excluídos. Active-Active HA não é suportado. Também devem estar ativos os logs de Active Threat Response e, conforme o tipo de IoC, as verificações de firewall, DNS, IPS ou decryption. Avaliação Avanet: dependente do contexto ou opcional. Ativar apenas quando licença, análise cloud, privacidade, interfaces adequadas e responsabilidade pelos alertas estiverem esclarecidas. Não substituir um NDR existente apenas para tornar o Health Check verde.
• 3. Sophos X-Ops deve estar ativado, Ação Log and drop. Standard: CIS, Severidade: High. Relevante para segurança se os Threat Feeds forem usados ativamente. Falsos positivos e registros devem ser verificados.
• 4. MDR threat feeds devem estar ativados, Ação Log and drop. Standard: Recommended, Severidade: High. Requer Sophos MDR, registo no Sophos Fusion e licenças adequadas. Avaliação Avanet: opcional. O guia ligado explica piloto, Audit ID, Task Queue e validação do incidente. Sem contrato MDR, não é uma falha de configuração, mas uma recomendação de produto e serviço.
• 5. Uma regra de firewall deve usar Synchronized Security Heartbeat. Standard: CIS, Severidade: Medium. Avaliação Avanet: dependente do contexto. Tem grande valor com Sophos Endpoint, mas não se aplica com Microsoft Defender ou outro EDR. É essencial um teste piloto: conforme a regra, os dispositivos que nunca enviaram um heartbeat podem continuar a ter acesso. As opções Block clients with no heartbeat e Block request to destination with no heartbeat aplicam o comportamento pretendido a esses dispositivos.
• 6. Security Heartbeat deve estar ativado. Standard: CIS, Severidade: High. Importante se o Sophos Endpoint for usado. Caso contrário, primeiro deve-se esclarecer o design do Endpoint.
• 12. DNS Protection deve ser configurado e ativo. Standard: Recommended, Severidade: Medium. O estado ativo requer a licença adequada, os resolvers de DNS Protection no firewall e o IP público do firewall como Location no Sophos Fusion. Avaliação Avanet: opcional. Ativar apenas quando o serviço é operado conscientemente como camada de segurança DNS e os respetivos logs são analisados. Outros filtros DNS podem cobrir o mesmo objetivo sem que o Sophos Health Check os marque como compliant.

Administração, autenticação e Device Access

• 7. Aviso de login deve estar ativado. Standard: CIS, Severidade: Medium. Tema de conformidade. Pouco efeito de proteção técnica, mas gera um clique adicional no login.
• 8. Configuração de hotfix deve estar ativada. Standard: CIS, Severidade: High. Avaliação Avanet: prioridade alta. No SFOS 22 atual, já não aparece um bloco Hotfix separado em Backup & firmware > Firmware. A Sophos instala hotfixes automaticamente por predefinição; o estado pode ser verificado com system hotfix show na Device Console. A ausência da caixa na interface não é um finding.
• 9. Sessões inativas devem ser encerradas e logins bloqueados após tentativas falhas. Standard: CIS, Severidade: High. Clareza na proteção de login. Especialmente importante em portais expostos e acessos administrativos.
• 10. A complexidade da senha deve ser configurada para usuários. Standard: CIS, Severidade: High. Útil, especialmente para usuários locais e portais. Com IdP externo, também verifique a política de senha e MFA deste.
• 11. A complexidade da senha deve ser configurada para administradores. Standard: CIS, Severidade: High. Fortalecimento básico. Mais importante ainda são administradores individuais, MFA e acesso restrito.
• 13. MFA deve estar ativo para logins de VPN de Acesso Remoto. Standard: CIS, Severidade: High. Muito importante para SSL VPN e IPsec Remote Access. Planeje o rollout com administrador de fallback e usuários de teste.
• 14. MFA deve estar ativo para WebAdmin Console e VPN Portal. Standard: CIS, Severidade: High. Muito importante, especialmente se os portais forem acessíveis a partir de redes menos controladas.
• 15. Conexões com servidores de autenticação devem ser criptografadas. Standard: CIS, Severidade: Medium. Importante em integrações AD/LDAP/RADIUS. Evite autenticação não criptografada.
• 17. Autenticação por chave pública deve estar ativada para SSH. Standard: Recommended, Severidade: High. Muito útil. Além disso, permita SSH apenas a partir de redes confiáveis.
• 18. User Portal não deve ser acessível a partir da zona WAN. Standard: Recommended, Severidade: High. Correto em muitos ambientes. Se o acesso WAN for necessário, restrinja fortemente e use MFA.
• 19. WebAdmin Console não deve ser acessível a partir da zona WAN. Standard: CIS, Severidade: High. Um dos pontos mais importantes. Nunca abra amplamente o WebAdmin para a Internet.
• 20. MFA deve ser configurado para o administrador padrão. Standard: CIS, Severidade: High. Importante, mas melhor ainda é um processo administrativo limpo com contas de administrador pessoais.

Backups, atualizações, regras e inspection

• 16. Backups devem ser planejados no firewall ou no Sophos Fusion. Standard: CIS, Severidade: Low. Baixa gravidade, mas extremamente importante em caso de emergência. Cifre os backups, guarde-os fora do firewall e teste o processo de restauração, documentando o resultado.
• 21. Emails de notificação devem ser configurados para eventos de sistema e segurança. Standard: CIS, Severidade: Low. O Sophos Firewall pode enviar notificações por email e SNMP; os eventos pretendidos são selecionados em System services > Notification list. Avaliação Avanet: dependente do contexto. O importante é um canal de alerta fiável e testado. Se Syslog, SIEM, monitorização ou Central Alerts forem operados de forma fiável, o email não é obrigatório. Um servidor SMTP configurado sem eventos selecionados e sem teste de entrega ainda não constitui um processo de alertas.
• 22. Atualizações automáticas de padrões devem estar ativadas. Standard: CIS, Severidade: High. Avaliação Avanet: prioridade alta. Sem padrões atuais, várias funções de proteção perdem eficácia. O procedimento para configurar e verificar as atualizações de padrões mostra a automação, os status e a instalação separada do firmware de APX e RED. Em ambientes Air-Gap, também é necessário um processo manual de padrões e licenciamento documentado.
• 23. Uma política da Web deve ser selecionada em uma regra de firewall. Standard: Recommended, Severidade: Medium. Útil para tráfego web de usuários. Não aplique cegamente a tráfego de servidor para servidor ou tráfego especial.
• 24. Proteção contra zero-day deve ser selecionada em uma regra de firewall. Standard: CIS, Severidade: High. Útil para caminhos web e de download apropriados. Considere licença, desempenho e falsos positivos.
• 25. IPS deve estar ativado e uma política de IPS deve ser selecionada em uma regra de firewall. Standard: CIS, Severidade: High. Ponto de proteção muito importante. IPS deve ser escolhido e registrado adequadamente por caminho de tráfego.
• 26. Uma política de controle de aplicativos deve ser selecionada em uma regra de firewall. Standard: CIS, Severidade: Medium. Útil para regras de internet de clientes. Teste primeiro em tráfego crítico.
• 27. Uma regra de inspeção SSL/TLS deve usar a ação Decrypt. Standard: CIS, Severidade: High. Não ative cegamente. TLS Inspection requer distribuição de CA, proteção da privacidade, consideração do certificate pinning, exceções, fase piloto e processos de suporte e solução de problemas.
• 28. Uma regra de permissão não deve usar Any em todos os campos de rede e serviço. Standard: CIS, Severidade: Medium. Muito importante para higiene de regras. Any pode ser necessário conscientemente, mas deve ser justificado e registrado.

Sophos Fusion e hora

• 29. Sophos Central Reporting deve estar ativado. Standard: Recommended, Severidade: Medium. Útil para relatórios e análises mais longas. Não é obrigatório se Syslog/SIEM for operado corretamente.
• 30. O firewall deve estar registado no Sophos Central Management, que deve estar ativado. Standard: Recommended, Severidade: Medium. Prático para gestão central, backups e relatórios. Nem todos os ambientes querem ou precisam de gestão na cloud.
• 31. Um servidor NTP deve ser configurado. Standard: CIS, Severidade: Low. Requisito básico. Sem tempo correto, logs, certificados, autenticação e solução de problemas sofrem.

Priorizar e implementar descobertas

Nem toda descoberta tem a mesma importância em todos os ambientes. Uma boa revisão classifica as entradas não apenas pela gravidade técnica, mas também pela exposição e risco operacional.

Esta ordem tem se mostrado eficaz:

1. Verificar acessos de gerenciamento e portais expostos à Internet.
2. Verificar MFA e segurança de login para administradores, VPN Portal, User Portal e Acesso Remoto.
3. Limpar regras de firewall com fontes, destinos ou serviços muito amplos.
4. Controlar registros, backups e hotfixes.
5. Verificar funções de proteção por regra, como IPS, política da Web, controle de aplicativos, TLS Inspection ou Zero-Day Protection.
6. Avaliar descobertas do Sophos Fusion, relatórios ou NDR se a função é realmente utilizada e operada no ambiente.

A ordem é pragmática: primeiro as coisas que são diretamente visíveis na Internet ou permitem acesso ao firewall. Depois, higiene de regras e funções de proteção. Depois, questões operacionais e de ecossistema.

Aplicar e reverter alterações com segurança

Antes da primeira correção, registam-se o build do SFOS, o finding, o valor inicial e o fluxo afetado. Alterações ao acesso de gestão, autenticação, regras ou inspection exigem ainda um backup recente, um acesso administrativo alternativo testado e um retorno claro. Fix now é apenas um link de navegação, não uma autorização para aceitar a definição proposta sem análise.

As alterações devem ser aplicadas individualmente ou em pequenos grupos lógicos. Depois verifica-se tanto o estado do Health Check como a função afetada: acesso administrativo permitido e recusado, login de teste com MFA, correspondências da regra no Log Viewer ou teste da aplicação após alterar a inspection. Se o finding permanecer, confirma-se primeiro se foram alterados a policy e o objeto corretos. A ajuda não promete um intervalo fixo; indica apenas que os dados são atualizados quando uma configuração monitorizada muda.

Se ocorrer um efeito secundário, utiliza-se o change ticket para repor a definição específica no valor inicial documentado e valida-se novamente. Um restauro completo é o último recurso e deve corresponder à plataforma e à versão de firmware. Override status não altera a configuração e Undo override não reverte uma correção; apenas devolve a policy a Doesn't comply.

Descobertas típicas e medidas adequadas

WebAdmin, User Portal ou VPN Portal estão muito acessíveis

Se portais administrativos ou voltados para o usuário são acessíveis a partir de muitas zonas, o risco de varreduras, tentativas de força bruta e preenchimento de credenciais aumenta. O artigo mais importante sobre isso é Proteger o acesso ao Sophos Firewall: configurar corretamente o Device Access.

Para ambientes produtivos, deve-se verificar:

• O WebAdmin é realmente necessário a partir da zona WAN?
• Existe uma Local Service ACL Exception Rule para IP de gerenciamento ou rede de administradores?
• O SSH é permitido apenas a partir de redes confiáveis?
• Os User Portal e VPN Portal são acessíveis apenas onde são necessários?

MFA está ausente ou não está ativado consistentemente

O MFA deve estar presente, pelo menos, em acessos administrativos e Acesso Remoto. Se o Health Check mostrar descobertas de MFA, não se deve mudar cegamente para todos os usuários ao mesmo tempo. É melhor um rollout controlado com usuário de teste, administrador de fallback e processo de token limpo.

O guia prático está em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Acesso Remoto.

Regras de firewall são muito abertas

Regras muito amplas com Any em fonte, destino ou serviço são frequentemente históricas. Nem toda regra ampla está automaticamente errada, mas cada uma deve ser justificada.

Para a limpeza, estas perguntas são úteis:

• Qual zona realmente pode acessar qual zona?
• Os destinos ou serviços podem ser restringidos?
• O registro está ativo para que os acertos sejam visíveis?
• Existem regras de teste antigas ou exceções temporárias?
• A regra pode ser dividida em várias regras mais compreensíveis?

Os fundamentos estão em Entender e configurar corretamente as regras do Sophos Firewall. Se não estiver claro qual regra está em vigor, Testar regra de firewall com Log Viewer, Policy Test e Packet Capture pode ajudar.

Backups, hotfixes e processo de atualização estão ausentes

Um Health Check pode apontar para a falta de backups ou questões de atualização/hotfix. Esses pontos parecem menos espetaculares do que a exposição de portais, mas são decisivos em caso de emergência.

Antes de grandes mudanças, deve-se criar um backup e saber como funciona uma restauração. O procedimento está em Criar ou restaurar backup do Sophos Firewall. Para questões de firmware, Atualização de firmware do Sophos Firewall - Preparação e Melhores Práticas é adequado.

Registros e relatórios estão incompletos

Se faltam logs, a operação fica cega. O Health Check pode dar dicas sobre questões de registro ou relatório, mas a decisão real depende do modelo operacional.

Para análise local, são relevantes Log Viewer, Service-Logs e Packet Capture. Para armazenamento mais longo, é necessário Central Firewall Reporting ou Syslog/SIEM. Se não forem eventos de log individuais, mas fluxos de tráfego, picos de largura de banda ou relações de comunicação notáveis que devem ser investigados, Monitoramento sFlow é adicionalmente adequado. Os fundamentos locais estão em Solução de problemas do Sophos Firewall: Serviços e Logs.

Funções de proteção não estão ativas em regras

Um ponto frequente são regras sem IPS, política da Web, controle de aplicativos, TLS Inspection ou Zero-Day Protection. Aqui, não se deve ativar tudo indiscriminadamente, mas entender o caminho do tráfego.

Exemplos:

• O tráfego web de usuários precisa de controles diferentes do tráfego de servidor para servidor.
• TLS Inspection deve ser introduzido de forma planejada, pois pode interferir em aplicativos.
• IPS e controle de aplicativos precisam de registro e uma rotina de revisão.
• Funções de NDR ou Threat-Feed só ajudam se as descobertas forem posteriormente avaliadas.

Para TLS Inspection, Introduzir corretamente o TLS Inspection do Sophos Firewall é adequado. Para Threat Feeds, Sophos Firewall Threat Feeds é adequado.

Documentar e rever a revisão

O Sophos Firewall permite substituir manualmente o status de verificações individuais. Isso pode ser útil se uma recomendação não for implementada conscientemente no próprio ambiente.

No entanto, as substituições não devem ser mal interpretadas como uma função de limpeza. Só fazem sentido se o requisito for deliberadamente cumprido de outra forma ou existir um controlo compensatório eficaz e equivalente. Um exemplo documentado diz respeito à policy MFA should be configured for the default admin: se o ambiente utilizar Microsoft Entra ID SSO com MFA como controlo obrigatório de início de sessão, este finding pode ser substituído com justificação técnica, dependendo da arquitetura, mas apenas se o início de sessão ou a conta em causa estiver realmente protegido de forma equivalente. SSO com MFA para contas pessoais de administrador, por si só, não demonstra proteção equivalente da conta de administrador predefinida. Os acessos locais de reserva e emergência devem continuar a ser protegidos e verificados separadamente. Isto não é uma autorização geral para substituir todos os findings locais de MFA; outros controlos equivalentes também podem justificar uma exceção. Sem essa justificação, o risco mantém-se mesmo que a apresentação do Health Check melhore.

Se um ponto for substituído, deve estar documentado:

• Por que a recomendação não é adequada?
• Quem aprovou a decisão?
• A exceção é permanente ou apenas temporária?
• Quando será revisada novamente?
• Existe uma medida compensatória?

⚠️ Uma substituição não é uma correção. É uma aceitação consciente de risco ou uma exceção documentada. Sem justificativa, o Health Check se torna menos valioso.

Documentar corretamente o resultado

Uma revisão do Health Check deve gerar um resultado rastreável. Caso contrário, você pode ver brevemente um painel, mas não saberá mais tarde qual decisão foi tomada e quais pontos ainda estão pendentes.

Para ambientes pequenos, uma lista simples é muitas vezes suficiente:

• Data: Quando foi verificado o Health Check?
• Firmware: Em que versão do SFOS foi feita a avaliação?
• Finding: Que ponto não conforme foi reportado?
• Risco: Porque é que este ponto é relevante ou menos relevante neste ambiente?
• Medida: O que será alterado, testado ou conscientemente aceite?
• Responsável: Quem esclarece o ponto do ponto de vista técnico ou operacional?
• Prazo: Até quando a medida deve ser concluída ou novamente avaliada?
• Evidência: Screenshot, ticket, Change-ID ou indicação no Audit Log.

Para firewalls produtivos, a evidência não deve consistir apenas em uma captura de tela. Se uma configuração foi alterada, ticket de mudança, trilha de auditoria, regra de firewall afetada e resultado da revisão devem estar juntos. Para alterações em regras, interfaces, hosts e serviços, Verificar os logs de trilha de auditoria do Sophos Firewall é particularmente útil.

Verificar novamente após alterações

Após uma correção, deve-se abrir novamente o Health Check e verificar se a descoberta realmente desapareceu. Além disso, é necessária uma verificação técnica de funcionalidade, pois um status verde por si só não prova que o tráfego produtivo ainda está funcionando corretamente.

Exemplos:

• Após uma alteração em Device access, verifique se o acesso administrativo a partir da rede de gerenciamento prevista ainda funciona e não é mais acessível a partir de redes indesejadas.
• Após alterações de MFA, faça login com um usuário de teste e verifique separadamente o administrador de fallback.
• Após alterações de regras, teste Log Viewer, Policy Test e aplicativos afetados.
• Após alterações de registro ou relatório, verifique se novos eventos são realmente visíveis localmente, no Sophos Fusion ou no Syslog.
• Após uma substituição, defina um lembrete para que a exceção não seja esquecida permanentemente.

Se várias descobertas forem tratadas ao mesmo tempo, as alterações devem ser divididas em blocos pequenos. Caso contrário, em um problema posterior, não está claro se o Device Access, MFA, regras de firewall, TLS Inspection ou outra alteração foi a causa.

Usar o Health Check como processo operacional

O Health Check é mais forte quando é executado regularmente e após mudanças importantes.

Momentos adequados:

• após a configuração inicial ou um go-live,
• antes e depois de grandes alterações de regras,
• antes de atualizações de firmware,
• após restauração ou troca de hardware,
• após migrações ou grandes mudanças de arquitetura,
• antes de auditorias,
• trimestralmente como revisão de segurança.

Para as próprias alterações, a trilha de auditoria deve ser usada adicionalmente. O artigo Verificar os logs de trilha de auditoria do Sophos Firewall explica como avaliar o configuration-audit.log e rastrear alterações de configuração.

Processo prático de revisão

Uma revisão pragmática do Health Check segue assim:

1. Abra o Health Check no Control Center.
2. Classifique as descobertas não conformes por gravidade.
3. Verifique primeiro serviços e acessos administrativos expostos à Internet.
4. Trate temas de MFA, senha e sessão.
5. Identifique regras de firewall amplas e valide com Log Viewer.
6. Verifique backups, hotfixes, registros e relatórios.
7. Avalie funções de proteção por regra.
8. Documente exceções justificadas em vez de substituir sem comentários.
9. Verifique novamente após alterações.
10. Documente o resultado com data, responsável e pontos pendentes.

Para revisões recorrentes, muitas vezes uma tabela simples com descoberta, risco, medida, responsável, status e lembrete é suficiente. O importante é que as descobertas não sejam apenas vistas, mas tratadas ou conscientemente aceitas.

Limites

O Health Check é útil, mas tem limites claros.

• Ele não conhece toda a lógica de negócios do ambiente.
• Ele não avalia se uma regra é necessária tecnicamente.
• Ele não substitui segmentação de rede e modelo de zonas.
• Ele não reconhece automaticamente todos os casos especiais arriscados.
• Ele não substitui uma auditoria externa e uma revisão manual de regras.
• Ele não diz se os alertas serão tratados posteriormente.

Portanto, o Health Check deve ser visto como um ponto de partida. Ele torna visíveis desvios palpáveis, mas a verdadeira qualidade de segurança surge de uma boa arquitetura, processos limpos e manutenção consistente.

Lista de verificação operacional

• Execute o Health Check após o go-live e após grandes mudanças.
• Priorize descobertas por gravidade e exposição.
• Verifique a acessibilidade WAN do WebAdmin, SSH, User Portal e VPN Portal.
• Ative MFA para administradores, portais e Acesso Remoto.
• Limpe ou justifique regras de firewall amplas.
• Ative registros em regras importantes.
• Verifique backups e processo de restauração.
• Documente o processo de hotfix e firmware.
• Defina substituições apenas com justificativa.
• Documente regularmente o resultado do Health Check.

FAQ