Sophos Firewall v22 MR2: atualização ou novo risco?

O Sophos Firewall v22 MR2 chegou. A build 546 foi publicada a 14 de julho de 2026 e traz uma combinação limitada, mas bastante útil, de funções de segurança, alterações de autenticação, ajustes de certificados e mais de 50 correções de erros.

No papel, é uma Maintenance Release clássica. Na prática, contém precisamente a mistura que atualmente me leva a olhar duas vezes para uma versão da Sophos: nova lógica de deteção no IPS, comportamento alterado na atribuição de utilizadores, novas cadeias de certificados e, em simultâneo, uma longa lista de crashes do kernel, problemas de HA, estados Failsafe, erros de VPN e falhas de reporting.

Isto não é apenas positivo. Quando uma Maintenance Release corrige mais de 50 erros, mostra, por um lado, que a Sophos está a arrumar a casa. Por outro, mostra também quantos problemas graves ainda existiam na GA e na MR1. Já critiquei precisamente esta qualidade do firmware em Sophos Firewall: sem CVE, mas com bugs (v21.5 a v22).

Vou instalar já a MR2 num dos meus Sophos Firewalls. Não porque confie cegamente na versão no primeiro dia, mas porque quero perceber se a build 546 finalmente acalma a linha v22 ou se voltam a surgir mais bugs novos do que aqueles que a atualização corrige. Interessa-me sobretudo a HA, o logging, IPsec, o tempo de resposta do WebAdmin, STAS e a estabilidade após atualizações de patterns.

Ao mesmo tempo, a Sophos cria um contraste estranho com esta versão. O Config Studio 2.6 ocupa agora bastante espaço nas atualizações oficiais da firewall. A ferramenta externa no browser recebe fusão de templates, melhor pesquisa, diffs de vários ficheiros, análises de migração e dados de compatibilidade de hardware. Na interface da própria firewall, porém, quase nada de visível volta a mudar na utilização diária.

Por isso, considero a MR2 tecnicamente importante, mas estrategicamente desanimadora. O motor de segurança recebe novas funções, enquanto os workflows modernos de administração voltam a ser transferidos para o Config Studio.

O essencial em resumo

O SFOS 22.0 MR2 tem o número de build 546 e sucede à MR1 build 490. A Sophos destaca sete áreas principais:

• deteção e controlo de criptografia pós-quântica;
• melhor categorização de aplicações de IA generativa;
• nova extensão Chromebook User ID com Manifest V3;
• alteração do comportamento predefinido do STAS;
• anúncio antecipado do fim do suporte a Novell eDirectory no SFOS 23.0;
• novas cadeias de confiança Let’s Encrypt e melhores notificações por e-mail;
• Config Studio 2.6 com novas funções de análise, migração e comparação.

Juntam-se mais de 50 problemas corrigidos. Do ponto de vista operacional, algumas destas correções são mais importantes do que as novas funções, pois incluem crashes do kernel, problemas de HA, estados Failsafe, erros de VPN e problemas de desempenho no reporting.

A minha avaliação resumida:

• Quem já utiliza v22 GA ou MR1 e é afetado por um dos erros listados tem uma razão concreta para instalar MR2.
• Quem tem uma instalação 21.5 estável não deve atualizar à pressa apenas por causa de PQC ou do Config Studio.
• As assinaturas PQC devem começar em modo de observação, não imediatamente com Drop.
• Os ambientes STAS têm de verificar após a atualização como é tratado o tráfego não autenticado durante a Identity Probe.
• Instalações HA, IPsec, WAF, mail e reporting precisam de testes funcionais reais, não apenas de um olhar rápido para indicadores verdes.
• O Config Studio 2.6 é tecnicamente útil, mas não prova que a interface SFOS WebAdmin se tornou mais moderna. Pelo contrário.

O limite de hardware continua a ser importante: o SFOS 22.0 já não suporta appliances XG e SG. A versão destina-se a instalações XGS, virtuais, de software e cloud suportadas. Quem ainda utiliza hardware XG não pode planear MR2 como o passo normal seguinte do firmware.

Detetar e controlar criptografia pós-quântica

A novidade tecnicamente mais interessante é o controlo da criptografia pós-quântica, ou PQC. Isto não significa que o Sophos Firewall passe subitamente a defender-se de computadores quânticos. A função abrange mecanismos criptográficos modernos de troca de chaves que deverão resistir melhor a futuros ataques com computadores quânticos suficientemente potentes.

A MR2 concentra-se no ML-KEM. O mecanismo foi normalizado em 2024 como FIPS 203 e baseia-se na dificuldade presumida do problema Module Learning With Errors. O NIST define três conjuntos de parâmetros:

• ML-KEM-512, com as chaves e o volume de dados mais pequenos;
• ML-KEM-768, variante intermédia hoje particularmente utilizada;
• ML-KEM-1024, com um nível de segurança superior, mas também maior custo de processamento e transmissão.

Nos documentos da MR2, a Sophos fala apenas genericamente de algoritmos de troca de chaves puros e híbridos baseados em ML-KEM. Não revela os conjuntos de parâmetros, grupos TLS ou IDs de assinatura abrangidos. Não se deve, portanto, assumir que todas as variantes ML-KEM possíveis são detetadas.

O que faz tecnicamente um KEM

O ML-KEM não cifra diretamente todo o fluxo de dados. De forma simplificada, um Key Encapsulation Mechanism consiste em três operações:

1. KeyGen gera uma Encapsulation Key e a Decapsulation Key correspondente.
2. Encaps usa a Encapsulation Key pública para criar um objeto Ciphertext e um segredo partilhado.
3. Decaps recupera o mesmo segredo no lado oposto com a Decapsulation Key privada.

A partir deste segredo partilhado, o protocolo deriva depois chaves de sessão simétricas. Os dados úteis continuam protegidos por mecanismos simétricos rápidos, como AES ou ChaCha20. O ML-KEM substitui, portanto, a parte assimétrica vulnerável da negociação de chaves, não toda a cifragem dos dados TLS.

O contexto prático é Harvest now, decrypt later: um atacante pode gravar hoje tráfego cifrado e esperar decifrá-lo dentro de alguns anos com um computador quântico criptograficamente relevante. Para dados efémeros, o risco é menor. No caso de dados médicos, comunicações governamentais, propriedade intelectual ou dados empresariais confidenciais a longo prazo, o período de proteção necessário pode, porém, ser superior ao tempo até ao aparecimento de uma nova classe de ataque.

Puro e híbrido não são a mesma coisa

Numa troca de chaves PQC pura, a segurança da negociação depende apenas do novo mecanismo pós-quântico. Uma troca híbrida combina um mecanismo clássico com ML-KEM. Um exemplo comum na prática é X25519MLKEM768: a componente X25519 clássica e o ML-KEM-768 contribuem em conjunto para o segredo resultante.

A abordagem híbrida é atualmente sensata. Se mais tarde surgir um erro de implementação ou uma fraqueza matemática no ML-KEM, a componente clássica mantém-se. Se, pelo contrário, um computador quântico suficientemente potente conseguir quebrar a curva elíptica clássica, permanece a componente ML-KEM. O modelo híbrido é, assim, uma ponte de migração e não uma dupla cifragem desnecessária.

Importa ressalvar que X25519MLKEM768 é aqui um exemplo técnico real de implementações TLS atuais. A Sophos não afirma expressamente que este seja o único ou o principal grupo detetado pela MR2.

O que o IPS faz

O Intrusion Prevention System recebe novas assinaturas para detetar trocas de chaves ML-KEM puras e híbridas. Os administradores podem criar regras IPS específicas e definir ações como Allow, Drop ou Reset.

Tecnicamente, uma firewall consegue identificar a troca de chaves proposta e selecionada no handshake TLS, porque o cliente anuncia os grupos e Key Shares suportados no ClientHello e o servidor confirma a escolha no ServerHello. Esta fase ocorre antes do fluxo aplicacional cifrado. Em princípio, a deteção é possível sem ler o conteúdo HTTPS posterior.

Contudo, a Sophos não documenta onde o Snort ou o pipeline IPS do SFOS avalia estas características, que versões de TLS abrange, nem se a deteção difere entre tráfego proxy, DPI e FastPath não decifrado. As Release Notes confirmam a capacidade, mas não a implementação interna no caminho de dados. Uma policy de produção exige, por isso, testes próprios com logs da firewall e do IPS.

As ações têm efeitos diferentes:

• Allow deixa a ligação prosseguir e, juntamente com logging, é adequado para fazer um inventário.
• Drop descarta silenciosamente os pacotes correspondentes. O cliente vê normalmente um timeout ou um handshake interrompido.
• Reset termina ativamente a ligação TCP. O erro aparece mais depressa, mas pode manifestar-se de outra forma para o utilizador e nos logs da aplicação.

As novas assinaturas estão desativadas por predefinição. É a decisão correta. PQC deixou de ser apenas tecnologia de laboratório: grandes browsers, serviços cloud e plataformas web já testam ou utilizam mecanismos híbridos. Se a Sophos bloqueasse globalmente estas ligações, sites e aplicações legítimos poderiam deixar de funcionar.

Uma implementação sensata é a seguinte:

1. Ativar inicialmente as assinaturas, permitindo e registando o tráfego.
2. Avaliar durante vários dias ou semanas que aplicações e destinos utilizam ML-KEM.
3. Verificar se as políticas criptográficas internas proíbem ou exigem determinados mecanismos.
4. Só depois aplicar seletivamente Drop ou Reset.

Na primeira discussão da comunidade, um administrador relatou logo após a atualização que não conseguia encontrar as assinaturas IPS com termos como PQC, KEM ou quantum. Isso pode dever-se a uma atualização de patterns ainda não recebida ou à nomenclatura. Poucas horas após o lançamento, ainda não é possível concluir que se trata de um defeito do produto. Mas demonstra um problema de documentação: uma função só é administrável se o nome da assinatura, SID, categoria e características do log forem fáceis de encontrar.

Antes de alterar uma policy, verificaria concretamente:

• O IPS está ativo e a subscrição Network Protection é válida?
• Que versão dos patterns IPS está instalada?
• Com que nome e SID aparecem as novas assinaturas?
• As deteções surgem no log IPS e no reporting central?
• A deteção mantém-se igual com exceções DPI, TLS Inspection e FastPath?
• Que browsers, sistemas operativos, serviços cloud e aplicações internas geram deteções?

O que o Web Protection faz

Segundo a Sophos, o Web Protection impede ainda que sessões web negoceiem algoritmos PQC não suportados. É uma tarefa diferente da de uma assinatura IPS. O IPS reconhece padrões específicos e pode reagir. O Web Protection intervém no workflow TLS e web controlado para impedir que uma ligação use um mecanismo que a firewall não consegue processar ou que a policy não permite.

Isto torna-se sobretudo relevante com TLS Inspection. Numa ligação decifrada, a firewall termina a sessão TLS do cliente e estabelece uma segunda sessão TLS com o servidor de destino. Existem, portanto, dois handshakes separados e dois conjuntos de chaves de sessão. Um browser e um servidor web podem suportar PQC, enquanto o componente de inspeção intermédio não consegue processar corretamente um grupo proposto.

Sem um comportamento controlado, surgem erros difíceis de compreender: o cliente propõe um novo grupo, a firewall não consegue intermediar o handshake por completo, o servidor escolhe uma variante inesperada ou um fallback comporta-se de outra forma. A MR2 pretende impedir que as sessões web negoceiem algoritmos PQC não suportados.

O que a Sophos não descreve com precisão é igualmente importante: não há uma matriz própria de policy PQC para o Web Protection, uma lista de grupos suportados nem uma indicação clara sobre se uma proposta não suportada é removida, rejeitada ou substituída por um fallback clássico. Isto não deve ser equiparado à ação IPS livremente configurável.

A função é útil, mas não substitui uma estratégia criptográfica. As empresas continuam a ter de saber que ligações TLS são decifradas, onde existem exceções e se PQC deve apenas ser observado ou realmente imposto.

Aplicações de IA generativa tornam-se mais visíveis

A segunda nova função de segurança diz respeito às aplicações de IA generativa. A Sophos melhora a sua categorização através do Synchronized Application Control.

O princípio não é novo: o Sophos Endpoint vê que processo local estabelece uma ligação e partilha o contexto da aplicação com a firewall através do Security Heartbeat. Assim, a firewall pode associar uma sessão a um programa mesmo quando a porta, o IP de destino e o tráfego cifrado não permitem, por si só, uma identificação inequívoca.

De forma simplificada, o caminho técnico dos dados é o seguinte:

1. Uma aplicação num endpoint protegido abre uma ligação de rede.
2. O Sophos Endpoint conhece o nome do processo, o caminho e o contexto local da aplicação.
3. O Security Heartbeat liga as perspetivas do endpoint e da firewall.
4. O SFOS associa a sessão até então desconhecida, ou apenas identificada genericamente, a uma aplicação.
5. A aplicação aparece no Synchronized Application Control e pode ser categorizada.
6. Uma Application Filter Policy permite, bloqueia ou regula o tráfego correspondente.

Na Connection List, o SFOS pode solicitar informações ao endpoint para ligações não identificadas através de Resolve application info. A lista de aplicações pode ser pesquisada por nome, caminho, categoria ou endpoints. A Sophos indica um limite máximo de 15 000 aplicações geridas por Synchronized Application Control. Por motivos de memória, a firewall só guarda as cinco ocorrências mais recentes por aplicação e endpoint.

A MR2 melhora especificamente a atribuição de aplicações de IA generativa. O Sophos Endpoint deverá reconhecê-las com maior precisão e transmitir a informação à firewall. A categoria Generative AI existe na lista de aplicações do SFOS e pode ser usada em Application Filters e Reports.

Há três aspetos relevantes para os administradores:

• Visibilidade: o reporting deve mostrar mais claramente que aplicações de IA generativa são utilizadas na empresa.
• Regras: as aplicações detetadas podem ser permitidas, limitadas ou bloqueadas com maior precisão.
• Inventário: as equipas de segurança e proteção de dados obtêm uma base melhor para distinguir serviços de IA aprovados e não aprovados.

Isto é útil, mas a expressão “detetar IA generativa” não deve ser interpretada de forma mais abrangente do que realmente é.

O Synchronized Application Control responde sobretudo à pergunta: Que aplicação originou a ligação? Não determina automaticamente:

• que prompt o utilizador introduziu;
• que ficheiro foi carregado;
• se continha dados pessoais ou confidenciais;
• se uma sessão no browser corresponde a utilização privada ou profissional de IA;
• se um serviço de IA permitido foi usado através de uma função integrada no browser.

Um cliente desktop com um caminho de processo inequívoco é mais fácil de atribuir do que dez serviços web de IA executados no mesmo processo do browser. Categorização de URL, TLS Inspection e deteção de Cloud Apps podem fornecer mais informação, mas são tecnicamente outras camadas de deteção.

O valor acrescentado depende também do Sophos Endpoint, de um Security Heartbeat ativo e do Synchronized Application Control ativado. A ativação inicial é feita no Sophos Central. Quem utiliza apenas SFOS sem Sophos Endpoint, ou tem endpoints fora do caminho do Heartbeat, não recebe automaticamente a mesma profundidade de deteção.

A expectativa correta é, portanto, a seguinte: a MR2 melhora a atribuição de aplicações e, consequentemente, a base das policies. Não resolve, por si só, a questão organizacional de que serviços de IA são permitidos e que dados podem ser processados nesses serviços.

Após a atualização, eu não bloquearia imediatamente toda a categoria Generative AI. Primeiro, o reporting deve mostrar que deteções resultaram do contexto do endpoint, de uma assinatura da firewall ou da categorização web. Caso contrário, podem ser bloqueadas funções produtivas no Microsoft 365, ferramentas de desenvolvimento, browsers ou plataformas de suporte sem se compreender a utilização real.

Alterações na autenticação e atribuição de utilizadores

A MR2 traz três temas de autenticação independentes. Dois exigem preparação concreta; o terceiro é um aviso antecipado de migração.

Chromebook User ID com Manifest V3

A extensão Sophos Chromebook User ID foi convertida para Manifest V3, a plataforma atual de extensões do Chrome que substitui a base técnica anterior.

O ponto crucial: a Sophos exige que a extensão antiga seja desinstalada e que a nova versão seja instalada. Uma simples atualização silenciosa da extensão anterior não é suficiente. Escolas e empresas com Chromebooks geridos centralmente devem preparar a mudança nas políticas do Google Admin, validá-la com um grupo de teste e depois distribuí-la amplamente.

Tecnicamente, a extensão é apenas uma parte do caminho SSO. Para Chromebook SSO, a Sophos exige, entre outros elementos:

• um servidor AD, LDAP ou Google Secure LDAP na firewall;
• Chromebooks na rede protegida pelo SFOS;
• endereços de utilizador do domínio Google Workspace registado;
• um certificado para comunicação cifrada;
• um CN correspondente ao certificado;
• por predefinição, a porta de comunicação Sophos 65123;
• uma configuração JSON exportada do SFOS e guardada no Google Workspace;
• acesso a accounts.google.com, aos Google API Hosts e à Chrome Web Store.

No Google Workspace, a nova extensão é distribuída em Devices > Chrome > Apps and extensions > Users and browsers. Em produção, Force install é recomendável para impedir que os utilizadores removam a extensão necessária à atribuição de identidade. Além disso, a Sophos User ID App tem de ser marcada como fidedigna em API Controls, caso contrário o OAuth pode falhar.

Após a mudança, não verificaria apenas se a extensão está instalada. O que importa é toda a cadeia:

1. O utilizador inicia sessão no Chromebook.
2. A extensão chega à firewall através da rede e do certificado previstos.
3. O utilizador aparece em Live users.
4. Uma regra baseada no utilizador corresponde realmente ao utilizador ou grupo.
5. Após terminar sessão ou mudar de dispositivo, a atribuição desaparece corretamente.

Sem a nova extensão, podem deixar de chegar futuras atualizações. Dependendo do desenho da autenticação, isto pode prejudicar a atribuição do utilizador e, consequentemente, regras de firewall ou web baseadas em utilizadores. Numa escola, pode rapidamente tornar-se um problema de filtragem, embora a firewall, o acesso à Internet e o Chromebook pareçam todos “online” à primeira vista.

STAS deixa de bloquear por predefinição durante a verificação de identidade

Na Sophos Transparent Authentication Suite, a MR2 altera o valor predefinido de Restrict client traffic during identity probe para No.

O STAS associa endereços IP aos utilizadores identificados no Windows Domain Controller. O mecanismo é antigo, mas tecnicamente interessante:

1. O utilizador inicia sessão no domínio Windows.
2. O Domain Controller grava um Security Audit Event, normalmente o Event ID 4768 nas versões mais recentes do Windows.
3. O STAS Agent extrai o nome de utilizador e o endereço IP desse evento.
4. Por predefinição, o Agent envia a informação ao Collector através de TCP 5566.
5. O Collector comunica as associações bem-sucedidas à firewall através de UDP 6060.
6. Quando o SFOS vê tráfego de um IP desconhecido, pode consultar o Collector na porta 6677.
7. A firewall obtém a associação a grupos através do servidor AD configurado e aplica regras baseadas no utilizador.

Quando a firewall ainda não tem uma associação para determinado IP, este entra em Learning Mode. Até agora, o tráfego era suspenso ou descartado por predefinição durante esta verificação. O período predefinido documentado é de 120 segundos. Se o Collector não responder, o IP pode depois ser considerado não autenticado durante uma hora, aplicando-se então as regras para tráfego não autenticado.

Era precisamente aí que existia um problema operacional real na MR1. A Sophos documenta NC-181885: com Restrict client traffic during identity probe = Yes, Identity Probes repetidas podiam causar interrupções intermitentes ou bloquear a atualização para MR1. A MR2 é indicada como versão de correção e altera simultaneamente o valor predefinido para No.

Com No, o tráfego do cliente pode continuar durante a verificação. Isso reduz interrupções, mas altera o equilíbrio:

• o utilizador sofre menos interrupções;
• durante a verificação, a firewall pode ainda não ter uma identidade confirmada;
• as regras baseadas em utilizadores e o logging têm, por isso, de ser verificados cuidadosamente nesta fase de transição.

É o clássico compromisso entre disponibilidade e aplicação rigorosa da identidade. Com Yes, uma falha de comunicação com o Collector pode bloquear o cliente. Com No, pode circular tráfego durante a verificação antes de a identidade estar confirmada. É necessário testar no próprio conjunto de regras se esse tráfego corresponde a uma regra geral de rede, a uma regra para não autenticados ou, mais tarde, a uma regra de utilizador.

As Release Notes dizem que o valor predefinido muda para No. Não afirmam claramente que a MR2 substitua automaticamente uma configuração existente e deliberadamente definida. Por isso, as instalações existentes devem verificar o valor efetivamente configurado após a atualização.

Também verificaria os seguintes pontos:

• UDP 6060 e 6677 estão abertos entre a firewall e o Collector?
• O STAS Service está em execução e ligado à NIC correta?
• Existem vários Collectors configurados em grupos para Fault Tolerance?
• Os objetos Clientless User abrangem impressoras, IoT e outros equipamentos fora do domínio?
• Os utilizadores aparecem corretamente após Sleep, Roaming, mudança de DHCP e Logout?
• Durante Learning Mode e o estado não autenticado, as regras correspondem ao previsto no desenho de segurança?

Isto é particularmente importante quando a identidade do utilizador não é usada apenas para reporting, mas como condição real de acesso.

Novell eDirectory termina no SFOS 23.0

A MR2 anuncia antecipadamente, pela primeira vez, que a Sophos terminará o suporte a servidores de autenticação Novell eDirectory no SFOS 23.0.

O eDirectory continua a funcionar na MR2. É um aviso prévio, não uma perda imediata de funcionalidade. Quem ainda o utiliza em produção deve, contudo, aproveitar o tempo restante para migrar para um tipo de autenticação suportado antes de instalar o SFOS 23.0.

Uma migração deste tipo envolve mais do que a entrada do servidor. Grupos, regras de firewall, Web Policies, acessos VPN, portais de utilizador e reporting podem depender da fonte de identidade atual. Diferenças em Distinguished Names, grupos aninhados, caminhos de pesquisa e formatos de nomes de utilizador podem ainda fazer com que um teste LDAP tecnicamente bem-sucedido esteja longe de garantir uma migração funcional das policies.

Existe também uma limitação antiga: o STAS não suporta LDAP sobre SSL/TLS no eDirectory. Por isso, a remoção completa no SFOS 23.0 não é totalmente surpreendente. Ainda assim, a arquitetura de substituição tem de estar pronta atempadamente. Deve ser tratada como um projeto próprio, com contas de teste, grupos reproduzidos em paralelo, referências de regras documentadas e um plano de recuo.

Let’s Encrypt: novas cadeias e melhor identificação

A Let’s Encrypt está a transferir gradualmente a infraestrutura de certificados para novos certificados Root e Intermediate. A MR2 adiciona suporte para YE Root, YE1, YE2, YR Root, YR1 e YR2.

Esta hierarquia, denominada Generation Y, inclui duas novas Root CAs com tipos de chave diferentes:

• ISRG Root YE usa ECDSA P-384 e é o caminho sucessor da hierarquia ECDSA anterior.
• ISRG Root YR usa RSA 4096 e é o novo caminho Root RSA.
• YE1 e YE2 são Intermediates ECDSA P-384.
• YR1 e YR2 são Intermediates RSA 2048.

As Roots são cross-signed pelas ISRG Roots anteriores. Assim, as novas cadeias podem ser validadas através de Trust Anchors mais antigos e já difundidos enquanto fabricantes de browsers e sistemas operativos adicionam as novas Roots aos Trust Stores. Os Intermediates YE1, YE2, YR1 e YR2 tornaram-se relevantes para emissão ativa em 2026.

Para o SFOS, é sobretudo uma alteração de compatibilidade. A firewall tem de conhecer e processar corretamente os novos emissores e cadeias para que emissão automática, renovação, utilização em WAF e validação continuem a funcionar com a próxima geração da infraestrutura Let’s Encrypt. Sem uma cadeia de confiança atualizada, as operações de certificados poderiam falhar apesar de o domínio, a porta 80 e a validação HTTP-01 estarem corretamente configurados.

Um erro ACME deste tipo é particularmente incómodo, porque facilmente se procura a causa no DNS, DNAT, porta 80, regra WAF ou Terms of Service, quando a causa real pode ser uma nova cadeia de CA.

O SFOS continua a usar HTTP-01 nos pedidos Let’s Encrypt. O FQDN do domínio tem de apontar para o endereço WAN público selecionado. A porta 80 tem de chegar à firewall, e uma regra DNAT concorrente no mesmo endereço e porta 80 pode impedir a validação. A MR2 não altera este princípio; amplia apenas a hierarquia CA suportada.

Além disso, as notificações Let’s Encrypt por e-mail passam a incluir o hostname e o número de série da firewall. Parece uma pequena alteração, mas é muito útil para MSP e ambientes maiores. Quem gere dezenas de firewalls consegue finalmente associar um aviso mais depressa ao equipamento correto, sem ter de investigar a partir de uma mensagem genérica.

É uma melhoria clássica de qualidade de vida: pouco espetacular tecnicamente, mas útil no dia a dia. Idealmente, todas as mensagens geradas por uma firewall gerida centralmente deveriam incluir pelo menos hostname, número de série, modelo e firmware. A Sophos já seguia esta direção nos e-mails de backup; a Let’s Encrypt acompanha-a na MR2.

Config Studio 2.6: todas as novas funções explicadas

A Sophos apresenta oficialmente o Config Studio 2.6 como parte do anúncio da MR2, embora continue a ser uma ferramenta separada no browser e não uma nova interface executada diretamente no SFOS. Quem ainda não conhece o princípio encontra no artigo anterior Sophos Firewall Config Studio V2: mais do que um viewer o workflow completo com exportação, Entities.xml, comparação e Editor.

Importante para a avaliação técnica e de proteção de dados: a Sophos afirma que parsing, análise e geração de relatórios ocorrem localmente no browser do endpoint. A configuração carregada não deverá ser enviada para a Sophos nem para outro servidor. Isto é crucial numa configuração completa de firewall, pois Entities.xml pode conter redes internas, objetos, regras, definições VPN, referências de certificados e nomes organizacionais.

Processamento local não significa automaticamente ausência de riscos. O browser continua a carregar a aplicação da Internet. Em ambientes muito sensíveis, permanecem questões sobre a versão do código, cache do browser, utilização offline, proteção do endpoint e armazenamento seguro das exportações. Um ficheiro Entities.xml não deve ficar sem controlo em Downloads, tickets ou sincronização cloud normal.

O Config Studio 2.6 abrange agora cinco áreas de trabalho:

• Configuration Report com Policy Test, análise e pesquisa global;
• comparação de duas ou mais configurações;
• Editor visual com Bulk Editing e saída XML, API ou curl;
• migração de Sophos UTM, SonicWall, FortiGate e Palo Alto Networks;
• compatibilidade de Backup Restore, Flexi Port, transceivers e modelos.

A versão 2.6 amplia estas áreas em vários pontos.

Combinar templates

O Merge Templates permite combinar configurações base com modelos específicos de um setor. Um MSP pode, por exemplo, juntar uma configuração técnica base para logging, DNS, acessos administrativos e objetos standard a um template para consultórios médicos, escolas ou filiais.

A vantagem está na reutilização: não é necessário começar do zero em cada firewall. Uma baseline pode conter acessos administrativos, NTP, DNS, Syslog, serviços standard e convenções de logging. Um segundo template acrescenta regras e objetos específicos do setor.

O ponto crítico continua a ser a resolução de conflitos:

• O que acontece com nomes de objetos idênticos e valores diferentes?
• UUID, referências e ordem das regras são resolvidos de forma consistente?
• Que referências de interfaces e zonas não correspondem ao modelo de destino?
• A fusão cria regras duplicadas ou sobrepostas?
• Um objeto restritivo existente é substituído por um valor mais abrangente do template?

Depois da fusão, Duplicate Analysis, Shadow Rule Analysis, Usage References e um Policy Test completo são obrigatórios. Uma fusão tecnicamente bem-sucedida não prova que a policy resultante é segura.

Pesquisa global melhorada

A pesquisa global permite encontrar objetos de configuração mais depressa e navegar diretamente até eles. Em conjuntos de regras grandes, isto é mais importante do que parece. Um objeto Host pode ser referenciado em configurações de firewall, NAT, TLS, web ou VPN. Saltar diretamente para o resultado evita muitos cliques e regressos manuais.

O Config Studio não pesquisa apenas o nome visível do objeto. Dependendo do tipo de dados, valores, caminhos e elementos referenciados também são relevantes. A navegação direta é especialmente valiosa com nomes genéricos como Server, LAN_Network ou grupos de hosts antigos.

Pesquisa não é, contudo, o mesmo que Usage Reference. Search responde: “Onde encontro este objeto ou valor?” Usage Reference responde: “Que outros elementos da configuração dependem dele?” Uma alteração segura exige ambas as perspetivas.

É precisamente uma função que também faz muita falta diretamente na interface da firewall.

Relatórios de configuração mais informativos

Nos relatórios de regras Firewall, NAT e TLS passam a aparecer não apenas os nomes das referências, mas também os valores e detalhes dos objetos utilizados. Em vez de ver apenas Webserver-Gruppe, o reviewer consegue identificar diretamente os hosts ou redes incluídos.

É um grande avanço para auditorias, passagens de responsabilidade e revisões a quatro olhos. Uma regra só pode ser avaliada devidamente se origem, destino, serviços e objetos associados forem visíveis sem cliques adicionais. Um nome de objeto pode parecer correto e, ainda assim, conter Any, uma rede demasiado abrangente ou entradas esquecidas.

O relatório também suporta Policy Test e análise. O Policy Test verifica que regra ou rota corresponde aos valores de origem e destino definidos. A análise procura, entre outros, Shadowing e duplicados. Como o SFOS avalia as regras de firewall de cima para baixo e termina na primeira correspondência, a ordem faz parte da lógica de segurança, não apenas da apresentação.

Config Studio 2.6: migração, comparação e exportação

Análises de migração com taxa de sucesso

O Config Studio mostra informações de migração e conversão, incluindo a percentagem transferida com êxito. Uma percentagem é um indicador rápido, não um relatório de aceitação.

A Sophos distingue vários estados nas migrações de terceiros:

• Supported: migração automática e sem alteração de conteúdo;
• Partial: migração com lacunas que precisam de ser completadas;
• Manual: tem de ser recriado manualmente no Sophos Firewall;
• Not supported: não é migrado;
• Action required: exige uma decisão concreta antes da exportação.

Se 95% de uma configuração for convertido, os 5% em falta podem ser precisamente certificados, palavras-passe, VPN, NAT ou routing especial. O benefício prático não está apenas no valor verde, mas na lista de elementos não migrados, parcialmente migrados ou resolvidos automaticamente.

As diferenças entre as lógicas dos fabricantes são reais. As regras FortiGate podem ser mais orientadas a interfaces, enquanto o SFOS usa zonas. A Palo Alto utiliza outros modelos de objetos, zonas e policies. O Config Studio consegue converter sintaxe e muitas estruturas, mas não prova automaticamente que o modelo de segurança permaneceu semanticamente idêntico.

Multi-File Configuration Diff

Até agora, a comparação clássica seguia sobretudo um modelo antes/depois. O Multi-File Diff permite carregar dois ou mais estados de configuração e compará-los ao longo de vários momentos. O Config Studio ordena os ficheiros pela data de modificação e mostra ao nível dos campos o que foi adicionado, removido ou alterado.

Estão disponíveis as vistas Side-by-Side, Unified e Semantic. A comparação semântica é particularmente interessante porque um simples diff de texto em XML fica rapidamente poluído pela ordem, IDs ou formatação. Um diff ao nível de Entity e Field tenta mostrar a verdadeira alteração de configuração.

É útil para reconstruir mudanças e investigar problemas. Se um erro não surgir imediatamente após uma única janela de manutenção, podem comparar-se várias exportações para determinar quando uma regra, objeto ou definição foi realmente alterado.

O problema mantém-se: são necessários estados de configuração guardados regularmente, timestamps corretos e um tratamento adequado dos dados sensíveis exportados. A data de modificação de um ficheiro descarregado ou copiado não corresponde necessariamente ao momento da alteração na firewall. Para um histórico fiável, nome do ficheiro, hora de exportação, hostname, número de série, firmware e Change Ticket associado devem ser documentados em conjunto.

Sem disciplina de versões, nem o Multi-File Diff consegue inventar um histórico. Por isso, esta função seria muito mais poderosa diretamente no Central, com um Audit History imutável, do que num upload manual de ficheiros.

Referência de Backup Restore, Flexi Port e velocidades

O Config Studio consegue verificar a compatibilidade de Backup Restore e os layouts de portas de diferentes modelos Sophos Firewall. Também apresenta informações sobre módulos Flexi Port e velocidades e normas suportadas, incluindo 25, 40 ou 100 Gbit/s.

Esta função ajuda nas migrações de hardware. Antes de mudar de modelo, é mais fácil avaliar:

• se um backup pode, em princípio, ser restaurado;
• quantas portas físicas estão disponíveis;
• se os módulos Flexi Port existentes são compatíveis;
• que normas e velocidades de interface são suportadas.

Mesmo assim, não substitui o desenho da migração. LAG, VLAN, Bridges, HA, nomes de portas, zonas e atribuições concretas de interfaces continuam a ter de ser planeados e verificados depois do Restore.

A compatibilidade mais ampla de Backup Restore aplica-se a destinos a partir do SFOS 20.0 MR2. Dependendo da versão de origem e plataforma de destino, aparece o Backup Restore Assistant para mapear interfaces. As portas físicas podem ser remapeadas, enquanto VLAN e Aliases seguem a Parent Interface e LAG ou Bridges são reconstruídos a partir das portas atribuídas.

Sobretudo nos Flexi Ports, perguntar “o módulo encaixa fisicamente?” não chega. É preciso verificar em conjunto geração do modelo, formato, transceiver, norma suportada, velocidade da porta, comportamento Breakout e versão SFOS disponível. O Config Studio torna a referência mais rápida, mas não substitui testes de Link e Failover após a migração.

Dark Mode

As Release Notes propriamente ditas referem ainda um Dark Mode. É uma pequena melhoria de utilização, não uma função da firewall. Ainda assim, é quase simbólico: até o Dark Mode chega primeiro ao Config Studio, enquanto a consola WebAdmin local evolui muito lentamente há anos em termos visuais e ergonómicos.

O que o Editor consegue produzir tecnicamente

O Editor pode importar ou criar configurações, efetuar Bulk Changes e apresentar o resultado antes da exportação como Import XML, API Request ou curl. Em alternativa, pode descarregar-se XML ou um arquivo TAR e importá-lo no SFOS através de Backup & firmware > Import export.

É poderoso, mas aumenta a responsabilidade do administrador. Um API Request gerado não é automaticamente idempotente. Um import bem-sucedido não confirma que Rule Order, utilização de objetos, NAT, VPN e Security Policies estão funcionalmente corretos. Antes da aplicação em produção, a saída deve constar do Change Ticket, o diff deve ser revisto e a firewall resultante deve passar por um teste real do caminho de dados.

Mais de 50 correções são a verdadeira razão para MR2

A Sophos refere mais de 50 problemas de fiabilidade, estabilidade e segurança corrigidos. Nem todos afetam todas as instalações, mas vários são operacionalmente sérios.

Considero estes grupos particularmente relevantes:

HA e Failsafe não são temas marginais

Várias correções afetam não apenas uma função, mas a própria capacidade operacional do appliance:

• NC-181331: uma partição de configuração cheia podia colocar a firewall em Failsafe Mode.
• NC-180110: no Primary, o Logging Daemon podia não arrancar, fazendo o equipamento HA entrar em Failsafe.
• NC-177441: após um upgrade para v22 GA, o equipamento originalmente Primary podia entrar em Failsafe devido a um problema no Postgres.
• NC-178906: o RED Server Service podia não arrancar e provocar um estado Failsafe.
• NC-177467: o equipamento Auxiliary não arrancava corretamente perante muitas tentativas SSH simultâneas não autenticadas.

São causas diferentes, mas com o mesmo efeito operacional: a firewall perde serviços, entra num modo de proteção ou o parceiro HA não está disponível como a imagem verde do cluster sugeria. Por isso, após a atualização, olhar para HA status: Active-Passive não chega. É necessário testar sincronização, estado dos serviços, Failover e tráfego real.

As correções IPsec chegam ao núcleo do caminho de dados

As correções VPN também não são cosméticas:

• NC-180433: tráfego multicast através de um túnel VPN podia causar crashes repetidos da firewall.
• NC-171719: tráfego ESP seguia routing incorreto numa configuração SD-WAN.
• NC-180520: com IPsec Acceleration ativo, um XFRM Gateway continuava indisponível após o upgrade quando o túnel estava ligado a um Alias IP e o ESP chegava por outra porta WAN.
• NC-176855: o desempenho IPv6 através de IPsec route-based era afetado.
• NC-178121: Drag-and-Drop podia mover ligações Site-to-Site IPsec para posições erradas dentro de um Failover Group.

Nestes cenários, um túnel com estado Active não prova nada. Em VPN route-based, é preciso testar separadamente XFRM Interface, Routing Table, decisão SD-WAN, caminho ESP, MTU, IPv4 e IPv6. Nos Failover Groups, deve confirmar-se ainda que a ordem e a comutação continuam a obedecer à prioridade documentada.

Logging e reporting podiam provocar falhas

NC-155252 é uma correção particularmente desagradável: elevada carga de Disk I/O no reporting causava picos de CPU e falhas intermitentes da Internet até um minuto. É exatamente o tipo de erro em que um subsistema de análise afeta o caminho de dados de produção.

NC-178745 descreve o restart automático de um equipamento HA devido a Out of Memory no Logging Framework. NC-181520 melhora o desempenho do Log Viewer. Em conjunto, mostram que o logging no SFOS não pode ser tratado como função secundária inofensiva. Storage, base de dados, Garner, Log Viewer e Central Reporting estão operacionalmente mais ligados ao sistema do que a interface sugere.

Depois da MR2, não verificaria apenas se aparecem novas linhas no log. É relevante saber:

• Os eventos Firewall, IPS, WAF, Authentication e VPN chegam completos?
• A cronologia mantém-se sem lacunas?
• O Syslog Collector externo continua a receber dados?
• CPU, RAM e Disk I/O permanecem estáveis sob carga normal?
• Os Reports são gerados sem afetar o caminho de dados?

As correções Central mostram os limites do “Single Pane of Glass”

Com NC-181175, Group Policies do Sophos Central podiam ficar em Pending. NC-180513 afetava o import da configuração a partir do Central View depois do upgrade para MR1. NC-181904 impedia libertar e-mails em quarentena através do Central.

O ponto comum é que a interface central pode aceitar ou apresentar uma tarefa sem que a alteração desejada tenha sido efetivamente executada na firewall. Depois de um Group Policy Push, é necessário verificar no dispositivo de destino se objeto, regra, ordem e timestamp chegaram realmente. Fechar com sucesso uma janela no Central não é uma prova técnica de commit.

Esta lista também mostra por que não avalio Maintenance Releases apenas pelo tamanho da lista de funções. Quando logging, Postgres, SD-WAN ou Multicast coloca uma firewall em Failsafe ou a reinicia, a correção vale mais do que um novo mosaico no dashboard.

Ao mesmo tempo, o número de correções não é automaticamente um certificado de qualidade. Mostra que os problemas foram resolvidos, mas também quantos erros graves existiam nas builds anteriores. Quem gere um ambiente HA, VPN ou WAF crítico não deve ficar eternamente numa build antiga por receio, nem distribuir a MR2 sem testes em todo o lado logo no primeiro dia.

O que os administradores devem verificar antes do upgrade

A Sophos recomenda instalar a MR2 atempadamente devido às correções de segurança, estabilidade e desempenho. É compreensível. Mas, em produção, atempadamente não significa às cegas.

O tagging VLAN legacy em Bridges bloqueia MR2

A MR2 introduz um bloqueio rígido do upgrade para tagging VLAN antigo, configurado por CLI, em Bridge Interfaces. Se a configuração ainda usar o mecanismo legacy system vlan-tag, a firewall não pode ser atualizada para SFOS 22.0 MR2 ou posterior.

Estas configurações têm de ser limpas ou migradas antes do upgrade. Além disso, backups com esta configuração legacy não podem ser restaurados no SFOS 22.0 GA ou posterior. É especialmente importante em instalações antigas que foram modificadas por CLI em algum momento.

Os obstáculos anteriores da v22 mantêm-se

Continuam ainda a aplicar-se os pré-requisitos conhecidos da GA e MR1:

• Legacy Remote Access IPsec tem de ser removido ou migrado antes de MR1 ou MR2.
• O SFOS 22 precisa de mais espaço; determinados appliances desktop, virtuais ou de software têm de ser ajustados primeiro.
• O comportamento de VPN IPsec policy-based mudou desde GA e deve ser verificado nos túneis relevantes.
• Hardware XG e SG não é suportado pelo SFOS 22.
• Os antigos RED 15, RED 15w e RED 50 deixaram de ser suportados desde v21.5.

O meu processo de upgrade

Para firewalls de produção, faria pelo menos o seguinte:

1. Criar um backup atual e guardá-lo externamente.
2. Verificar suporte, licenças e o caminho de upgrade aprovado.
3. Excluir Legacy Remote Access IPsec e tagging VLAN por CLI em Bridges.
4. Verificar avisos de Disk Space no Control Center.
5. Em HA, verificar o estado dos dois nós, sincronização e firmware disponível.
6. Documentar VPN críticas, publicações WAF, Mail Flows, regras SD-WAN e autenticação.
7. Instalar primeiro MR2 num appliance de teste representativo ou menos crítico.
8. Após o upgrade, testar logs, versão dos patterns, HA, routing, DNS, VPN, WebAdmin, reporting e Policy Pushes centrais.

Numa versão com tantas correções, um teste limpo antes/depois é particularmente valioso. Caso contrário, sabe-se apenas que o firmware é novo, mas não se os caminhos de dados críticos continuam a funcionar exatamente como previsto.

Desde a versão 20, o SFOS tem Firmware Rollback automático quando a migração da configuração falha durante o upgrade. Isto reduz o risco de arrancar com Factory Configuration em vez da configuração de produção. Porém, a proteção não atua em todos os cenários, por exemplo num caminho de upgrade não suportado ou em determinados workflows do Setup Assistant. Após um rollback automático, migration.log e migrationhash.log devem ser analisados.

Um rollback automático não substitui um backup externo, o Secure Storage Master Key nem acesso funcional à consola. Protege sobretudo contra falhas na migração da configuração. Não prova que WAF, VPN, HA ou reporting funcionem corretamente depois de um upgrade tecnicamente bem-sucedido.

No meu teste direto da MR2, medirei ou provocarei os mesmos pontos antes e depois do upgrade:

• restart e arranque completo dos serviços;
• login no WebAdmin e tempo de resposta de grandes listas de regras;
• fluxo de logs local e externo;
• tráfego IPsec, Rekey e Failover;
• Central Policy Push com verificação na firewall;
• atualização de patterns para IPS e Application Control;
• nova autenticação STAS e comportamento de um Client IP ainda desconhecido;
• sincronização HA e mudança de função controlada, caso o sistema de teste seja um cluster.

Só depois poderei dizer se a MR2 é realmente melhor no meu ambiente. Uma instalação bem-sucedida e uma página verde no Control Center não são suficientes.

O que dizem os primeiros comentários da comunidade

O tópico de feedback foi aberto no mesmo dia que a MR2. No momento desta análise, tem apenas algumas horas. Não se pode concluir que a MR2 é estável, nem que é problemática.

Ainda assim, duas discussões merecem referência:

• Um operador de uma XGS 5500 em HA Active-Passive pergunta expressamente pela profundidade dos testes, porque NC-177467 o afetou durante meses na MR1. A Sophos lista o erro como corrigido na MR2. A correção diz respeito a um equipamento Auxiliary que não arrancava devido a muitas tentativas SSH simultâneas não autenticadas.
• Nas assinaturas PQC, um colaborador da Sophos salienta que foram intencionalmente desativadas. Como PQC-TLS está a aumentar nos browsers e aplicações, a ativação imediata poderia gerar muitos alertas. A recomendação inicial é Allow com logging e só mais tarde, se realmente necessário, uma ação de bloqueio.

É uma fase inicial razoável para uma nova versão: testes concretos, Case IDs e comentários compreensíveis, em vez de um genérico “funciona” ou “está avariado”. Continuaria a acompanhar o tópico nos primeiros dias e semanas, sobretudo quanto a HA, IPsec, WAF, STAS e reporting.

Config Studio torna-se o armazém de peças de uma interface antiga

Agora, a parte desagradável.

O Config Studio 2.6 é uma boa ferramenta. Combinar templates, procurar objetos, resolver referências no relatório, comparar vários estados da configuração e preparar migrações de hardware são funções reais de administração. Não critico a Sophos por as desenvolver. Critico o local onde são desenvolvidas.

A Sophos menciona agora o Config Studio diretamente nas Firewall Release Notes e no anúncio oficial da MR2. Assim, parece cada vez mais a resposta estratégica a problemas que deveriam ser resolvidos no WebAdmin ou Sophos Central.

A interface local da firewall continua antiga no dia a dia e, com configurações maiores, frequentemente lenta. As alterações em massa são insuficientes. Utilização de objetos, verdadeira pesquisa global, diffs limpos, clonagem de NAT, conflitos de regras e um workflow moderno de alterações faltam diretamente onde os administradores trabalham diariamente. O Sophos Central cobre apenas parte desta lacuna.

O problema não é só o design. Na minha opinião, uma interface moderna de firewall precisa de um processo de alterações robusto:

• Candidate Configuration em vez de alterações individuais imediatamente distribuídas;
• diffs completos antes/depois do commit;
• verificação de dependências entre objetos, regras, NAT, VPN e TLS;
• commit atómico ou estado claro da transação;
• rollback validado para o último estado conhecido;
• atribuição real de utilizador, hora e origem no Audit Trail;
• Bulk Operations com pré-visualização e verificação de conflitos;
• saída API consistente para alterações reproduzíveis.

O Config Studio recria partes disso fora do sistema. Analisa um export, gera XML ou API Requests e ajuda nos diffs. Mas continua a existir uma lacuna entre esta vista offline e o estado ativo da firewall. Sessions, routing dinâmico, estado HA, patterns atuais, estado dos certificados e a configuração realmente carregada não são o mesmo que um Entities.xml aberto localmente.

Seria exagerado concluir de um anúncio de release que a Sophos nunca mais modernizará profundamente a interface SFOS. Não existe uma declaração confirmada nesse sentido. O sinal continua, porém, a ser negativo: os avanços mais visíveis na utilização, pesquisa, comparação e trabalho de configuração voltam a surgir fora das interfaces de gestão principais.

O workflow mantém-se fragmentado:

1. Exportar a configuração da firewall.
2. Descompactar o arquivo e procurar Entities.xml.
3. Carregar o ficheiro numa ferramenta separada no browser.
4. Analisar, comparar ou editar aí.
5. Exportar novamente o resultado e reintroduzi-lo por XML, API ou curl.

Para uma auditoria, é aceitável. Para uma administração moderna, segura e rastreável, é um desvio. É especialmente irritante que o Config Studio não cubra apenas um caso especial. Recebe precisamente os Low-Hanging Fruits que os administradores Sophos esperam há anos.

E aqui torno-me mais crítico: quando a Sophos apresenta o Config Studio como um grande tema nas Firewall Release Notes normais, a ferramenta externa deixa de poder ser descartada como pequeno auxiliar. A Sophos torna-a visivelmente parte da estratégia de administração. Aumenta, por isso, a pressão para explicar que funções serão integradas no WebAdmin ou Central e quais ficarão permanentemente na ferramenta do browser.

Sem esse roadmap, fica a impressão de que a interface antiga, lenta e cada vez menos fácil de usar em configurações maiores se manterá no essencial e de que os administradores devem simplesmente usar o Config Studio nos workflows modernos. Não é um plano confirmado pela Sophos. Mas é a direção que o produto atualmente transmite.

Por que a UniFi fica com o caminho facilitado

A UniFi não substitui por completo todos os Sophos Firewalls. Conforme a licença e a arquitetura, a Sophos oferece funções de segurança mais profundas, IPS, Web Protection, WAF, integração Endpoint, ligação MDR/XDR e funções Enterprise clássicas. Uma comparação justa não deve ignorar estas diferenças.

Mas, na qualidade percebida do produto, a facilidade de utilização vence todos os dias.

A Ubiquiti investe visivelmente em design, aplicações móveis, navegação consistente, topologia, integração simples de equipamentos e uma interface compreensível mesmo sem anos de experiência no produto. Nem todas as funções UniFi têm maior profundidade técnica. O produto parece, porém, mais moderno, e isso influencia decisões de compra mais do que os fabricantes tradicionais de firewalls gostam de admitir.

Quando uma pequena equipa de TI escolhe entre duas soluções, não olha apenas para fichas técnicas do IPS. Também pergunta:

• Com que rapidez encontro um dispositivo, uma regra ou um cliente?
• Consigo verificar o ambiente de forma útil a partir do smartphone?
• Compreendo avisos e dependências sem conhecimentos especializados?
• Quantos cliques são necessários para uma alteração quotidiana?
• O produto parece uma plataforma coerente ou várias ferramentas lado a lado?

É aqui que a Sophos facilita desnecessariamente o trabalho a fabricantes como a Ubiquiti. O Sophos Firewall pode fazer mais em termos de segurança e continuar a ser a solução mais sensata para muitos ambientes PME. Porém, se os administradores têm de abrir um Config Studio separado para pesquisa moderna, diffs, templates e alterações em massa, enquanto a interface central permanece antiga e lenta, a Sophos perde confiança no nível mais visível.

Boa segurança não precisa apenas de um motor forte. Precisa de uma interface onde as pessoas compreendam regras, detetem erros e executem alterações em segurança. A facilidade de utilização não é, por isso, um extra cosmético, mas parte da segurança operacional.

Conclusão: instalar MR2, mas o problema do produto mantém-se

O SFOS 22.0 MR2 não é uma grande Feature Release. É uma Maintenance Release importante, com adições úteis.

O controlo PQC chega no momento certo, mas deve ser implementado primeiro em modo de observação. A melhor deteção de aplicações de IA generativa ajuda na visibilidade e nas policies, mas não substitui uma estratégia de DLP ou governação de IA. Os administradores de Chromebook têm de distribuir ativamente a nova extensão Manifest V3. O STAS torna-se menos propenso a interrupções, mas exige uma verificação consciente das regras de identidade. A Let’s Encrypt fica preparada para as próximas cadeias de certificados. E as muitas correções tratam vários problemas que podiam provocar falhas reais em produção.

Vou instalar MR2 diretamente depois do backup e do preflight e testar de seguida estes caminhos de dados. Quem é afetado pelos problemas HA, VPN, reporting, Central ou Failsafe mencionados tem boas razões para atualizar. No dia do lançamento, ainda não é possível responder seriamente se a build 546 será mais estável ou se trará novas regressões.

A minha crítica mantém-se clara: o Config Studio 2.6 é útil, mas o seu papel proeminente na release da firewall reforça a impressão de que a Sophos transfere a administração moderna para uma ferramenta secundária. Isto não confirma o abandono de uma nova interface SFOS. Mas é um sinal estratégico de alerta.

A Sophos tem uma base de firewall forte. O fabricante deveria finalmente dar aos administradores uma experiência de gestão à altura dessa base técnica. Caso contrário, plataformas mais modernas não ganham necessariamente por terem melhor segurança, mas porque levam mais a sério a pessoa em frente ao ecrã.

Até à próxima,
Joe

FAQ