Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access

Os portais de acesso administrativo e de acesso remoto não devem ser protegidos apenas com nome de usuário e senha. Com a autenticação multifator, abreviadamente MFA, o Sophos Firewall também requer um segundo fator, por exemplo, um código OTP baseado em tempo de um aplicativo Authenticator.

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

O artigo explica como planejar, ativar e testar o MFA de maneira sensata. O foco está em WebAdmin, VPN Portal e acesso remoto.

Classificação e proteção de acesso

MFA é uma proteção importante para logins, mas apenas um bloco de construção. Em primeiro lugar, deve ficar claro qual o acesso que está protegido, qual a fonte de identidade que está por detrás dele e se o serviço tem mesmo de ser acessível a partir da respetiva rede.

Qual artigo de autenticação se encaixa?

MFA é apenas parte da segurança de acesso. Dependendo do objetivo, a primeira coisa a considerar é acessibilidade, fonte de identidade, portal, cliente VPN ou aplicação web publicada:

• MFA para WebAdmin, VPN Portal ou Agendar Acesso Remoto: Este artigo.
• WebAdmin, SSH, User Portal, VPN Portal, Restringir DNS ou Ping acessível: Sophos Firewall Protegendo o acesso: Configure Device Access corretamente
• Use o SSO Microsoft Entra ID para Sophos Connect ou VPN Portal: Configurar SSO Microsoft Entra ID para Sophos Connect e VPN Portal
• Compare Sophos Connect, SSL VPN, IPsec ou ZTNA como modelo de acesso remoto: Sophos Connect ou SSL VPN: Qual solução de acesso remoto é a certa?
• Verifique a versão do cliente Sophos Connect, reconexões OTP ou provisionamento SSO: Verifique a versão do cliente Sophos Connect e atualize com segurança
• Protegendo aplicativos da Web publicados no WAF com MFA: WAF Sophos Firewall seguro com MFA
• Conecte o Active Directory clássico como fonte de usuário: Adicionar Active Directory em Sophos Firewall
• Preparar acesso de suporte controlado para Avanet ou Sophos: Configurando o acesso ao suporte da Avanet para Sophos Firewall
• Priorize as descobertas da verificação de integridade para MFA ou acesso ao portal: Use Sophos Firewall Health Check corretamente

Essa separação é importante: MFA protege logins, mas não limita automaticamente de quais redes WebAdmin, SSH ou portais podem ser acessados. Por outro lado, uma regra restrita de acesso a dispositivos não substitui um segundo fator. Uma boa segurança de acesso combina acessibilidade, fonte de identidade, MFA, registro e acesso alternativo testado.

Quando MFA faz sentido

MFA deve ser habilitado pelo menos para todas as contas que têm permissão para acessar interfaces administrativas ou funções de acesso remoto.

Áreas típicas de aplicação:

• Registro em WebAdmin.
• Registro em VPN Portal.
• SSL VPN ou acesso remoto Sophos Connect.
• Acesso para prestadores de serviços externos.
• Acesso para administradores privilegiados.

MFA reduz o risco de senhas roubadas, mas não substitui as restrições de acesso adequadas. SSH, WebAdmin e portais ainda devem ser acessíveis apenas a partir de redes confiáveis ​​ou através de acesso de gerenciamento claramente definido.

MFA não substitui Device Access

MFA protege o processo de login. No entanto, isso não reduz a superfície de ataque de um serviço. Se WebAdmin, User Portal, VPN Portal ou SSL VPN forem acessíveis pela Internet, esses serviços continuarão a ser atingidos por bots, scanners e tentativas de força bruta. Isso cria entradas de log desnecessárias, esforço de suporte e risco.

É por isso que você deve sempre combinar MFA com controles de disponibilidade:

• Device access: Determine basicamente quais serviços estão acessíveis em qual zona.
• Regra de exceção de ACL de serviço local: WebAdmin, SSH ou portais permitem especificamente apenas redes de gerenciamento, redes VPN ou endereços de origem conhecidos.
• MFA: Além disso, proteja os registros caso dados de acesso válidos tenham sido comprometidos.
• Registro e Syslog: Torne compreensíveis as tentativas fracassadas, os problemas de implementação e os ataques.

Se um portal precisa ser acessível em todo o mundo, você deve pelo menos combinar MFA, certificados válidos, registro em log, grupos de usuários restritivos e processos regulares de revisão. Para serviços de firewall acessíveis ao público, a questão não é apenas se um invasor pode fazer login, mas se o serviço precisa ser amplamente acessível.

Restringir adicionalmente o acesso com regras ACL

Antes de ativar MFA, você deve verificar onde WebAdmin, SSH, User Portal e VPN Portal podem realmente ser alcançados.

O caminho do menu é Sistema > Administration > Device access.

Existem duas áreas relevantes:

• ACL de serviço local: Acesso básico por zona, por exemplo LAN, VPN ou WAN.
• Regra de exceção de ACL de serviço local: exceções direcionadas para redes de origem individuais, hosts ou acesso de suporte.

Para ambientes de produção, geralmente não se deve habilitar WebAdmin e SSH para a zona WAN. É melhor limitá-lo a:

• um IP de gerenciamento,
• uma rede administrativa,
• uma rede VPN,
• um host de suporte dedicado,
• ou uma exceção FQDN/host claramente definida.

Se SSH for necessário, o acesso deverá ser adicionalmente restrito e idealmente usado com uma chave pública. Isso se encaixa Conectar Sophos Firewall via SSH.

⚠️ MFA protege contra credenciais roubadas, mas não contra serviços expostos desnecessariamente. WebAdmin, SSH e portais nunca devem ser mais amplamente acessíveis do que o necessário.

Selecione a variante MFA e planeje o lançamento

Antes da ativação, você deve decidir se a função local do Sophos OTP é suficiente ou se uma plataforma MFA existente deve ser integrada via RADIUS, NPS ou SSO. A implementação é então planejada para que administradores e usuários não fiquem bloqueados.

Requisitos

Antes da ativação você deve verificar:

• A hora do sistema do firewall está correta.
• Um servidor NTP funcional está configurado.
• Os usuários existem localmente, por meio de AD, LDAP, RADIUS ou outro serviço de autenticação compatível.
• Os usuários afetados podem fazer login no User Portal ou no respectivo serviço.
• Pelo menos um acesso administrativo alternativo está disponível.> ⚠️ Você deve ter cuidado especial com Admin-MFA. MFA não deve ser habilitado diretamente para todos os administradores sem primeiro verificar um usuário de teste, um segundo administrador e acesso substituto. A configuração incorreta do MFA pode resultar no bloqueio do WebAdmin ou VPN Portal.

Sophos MFA ou MFA externo?

Existem basicamente duas maneiras de MFA no Sophos Firewall: você usa a função OTP local do firewall ou conecta uma solução MFA externa via RADIUS ou SSO. Ambas as variantes são legítimas, mas resolvem problemas diferentes.

O MFA local do Sophos Firewall gerencia tokens OTP diretamente no firewall. Esta é geralmente a maneira mais rápida de proteger WebAdmin, portais e acesso remoto com um segundo fator. Nenhuma infraestrutura RADIUS ou provedor de identidade adicional é necessária.

Vantagens do próprio MFA da Sophos:

• Não é necessária integração adicional de RADIUS ou provedor de identidade.
• Implementação rápida para usuários locais e ambientes pequenos.
• Os tokens podem ser gerados e gerenciados diretamente no firewall.
• Adequado para acesso remoto WebAdmin, User Portal, VPN Portal, SSL VPN e acesso remoto IPsec.

Desvantagens:

• Os usuários podem precisar manter um aplicativo ou token Authenticator adicional.
• O token é separado do Microsoft 365, Entra ID ou de outros processos MFA existentes.
• Dependendo da máscara de login, não existe um campo OTP separado.
• Os usuários devem inserir a senha e o token diretamente, um após o outro, em determinados portais.

Em ambientes maiores, uma solução MFA externa pode fazer mais sentido. Variantes típicas são RADIUS com um back-end compatível com MFA, Microsoft NPS com extensão Entra-MFA ou outro sistema MFA compatível com RADIUS. Dependendo da versão SFOS e do modelo de acesso remoto, o Microsoft Entra ID SSO para WebAdmin, VPN Portal, bem como Sophos Connect com SSL VPN ou IPsec VPN também pode ser adequado.

A distinção importante é: Entra ID não é simplesmente o mesmo mecanismo do recurso OTP local do Sophos. O Entra MFA é indiretamente integrado ao fluxo de autenticação via RADIUS/NPS ou um modelo SSO é usado se o serviço e o cliente usados ​​suportarem isso.

Os usuários geralmente consideram um MFA externo mais conveniente porque estão usando o mesmo MFA do Microsoft 365 ou outros serviços empresariais. Isso não cria um segundo mundo MFA com um aplicativo adicional, token adicional e comportamento de login diferente.

A desvantagem de uma solução externa é a maior complexidade. RADIUS, grupos, tempos limite, comportamento de desafio e fallback devem ser cuidadosamente planejados e testados.| Variante | Vantagem | Desvantagem | Uso típico |

• MFA externo via RADIUS: A plataforma MFA existente pode ser usada, os processos centrais do usuário são mantidos RADIUS, NPS, tempos limite, grupos e comportamento do cliente devem ser testados de forma limpa Ambientes AD/Microsoft 365 com muitos usuários VPN.
• Entra ID SSO: Login familiar da Microsoft, melhor experiência do usuário, processos centrais de identidade Não utilizável de forma idêntica para todos os cenários, dependendo da versão, serviço e cliente do SFOS WebAdmin, VPN Portal e Sophos Connect se o SSO se adequar ao modelo operacional.

Apoio à decisão

A variante MFA correta depende menos do firewall do que da operação de identidade existente.

• Ambiente pequeno com usuários de firewall locais: A função OTP do próprio Sophos costuma ser suficiente.
• Ambiente Microsoft 365 com Entra-MFA existente: Valide MFA externo via RADIUS/NPS ou SSO Entra-ID para que os usuários não precisem manter dois mundos MFA.
• Muitos prestadores de serviços externos: Grupo de usuários próprio, obrigação MFA, prazo claro e revisão regular.
• Acesso crítico de administrador: MFA mais Device Access, combinam rede de gerenciamento, administrador substituto e registro.
• Muitos usuários de acesso remoto: Planeje o grupo piloto, o processo de suporte técnico, a redefinição de token e os testes do cliente antes da implementação ampla.

Se o Microsoft Entra ID for planejado diretamente como uma origem de SSO para VPN Portal ou Sophos Connect, Configurar o SSO do Microsoft Entra ID para Sophos Connect e VPN Portal também será adequado. Este é um modelo operacional diferente da função OTP clássica do Sophos e não deve ser equiparado ao RADIUS-MFA não testado.

Plano MFA

Para ambientes de produção, geralmente é melhor ativar primeiro o MFA para um pequeno grupo piloto.

Este pedido foi bem-sucedido:

1. Prepare usuários de teste ou grupo piloto.
2. Verifique o NTP e a hora do firewall.
3. Habilite MFA para a área de teste.
4. Teste o registro com o aplicativo Authenticator.
5. Só então integre grupos de usuários adicionais.

Um grupo de usuários separado é recomendado para provedores de serviços. Isso torna possível forçar especificamente o MFA e remover o acesso posteriormente com mais facilidade.

Para administradores você também deve planejar:

• Quem é o primeiro administrador do teste?
• Existe um segundo administrador com acesso profissional?
• O acesso é possível através de uma rede de gerenciamento ou VPN?
• O admin padrão é protegido separadamente?
• Está documentado como um token perdido é substituído?

Ative MFA e configure tokens

Quando os pré-requisitos, grupos e substitutos forem esclarecidos, MFA poderá primeiro ser ativado para um grupo piloto. Somente após testes bem-sucedidos você deverá incluir usuários ou administradores adicionais.

Ative MFA no Sophos Firewall

As configurações MFA estão localizadas em Configure > Authentication > Multi-factor authentication.

1. Faça login no WebAdmin do Sophos Firewall.
2. Abra Configurar > Autenticação.
3. Mude para a guia Autenticação multifator.
4. Para Senha de uso único (OTP), selecione a quem MFA deve se aplicar:
   • Sem OTP: MFA está desabilitado.
   • Todos os usuários: MFA se aplica a todos os usuários.
   • Usuários e grupos específicos: MFA se aplica apenas a usuários ou grupos selecionados.
5. Ative Gerar token OTP no próximo login se quiser que os próprios usuários configurem seu token na próxima vez que fizerem login.
6. Em Exigir MFA para, selecione para quais serviços MFA é necessário.
7. Salve a configuração com Aplicar.

As opções típicas em Exigir MFA para são:

• Portal do usuário
• Console de administração da Web
• Portal VPN
• Acesso remoto SSL VPN
• Acesso remoto IPsec
• Firewall de aplicativos da Web

Dependendo do ambiente, MFA pode ser aplicado de forma diferente para serviços individuais ou grupos de usuários. Para administradores, MFA deve ser aplicado de forma consistente, mas primeiro testado de maneira controlada.

Se os aplicativos Web forem publicados por meio do Web Server Protection, também será necessária uma política de autenticação WAF apropriada. O processo está em Sophos Firewall WAF seguro com MFA.

Prepare-se para implementação e operações

MFA não é apenas uma chave no firewall. Após a ativação, comportamento de login, dúvidas de suporte e alteração de acesso de emergência. Portanto, antes da ampla implementação, deve ficar claro quem emite tokens, quem redefine tokens perdidos e como será a reação fora do horário comercial.

Estes pontos provaram ser úteis para a operação:

• Teste o grupo piloto com usuários reais, não apenas administradores.
• Documente um segundo administrador e quebre o acesso.
• Informar o helpdesk sobre o comportamento da senha+OTP.
• Defina o processo de redefinição de token para novos smartphones ou dispositivos perdidos.
• Verifique Log Viewer e os logs de autenticação após a implementação.
• Teste MFA externo via RADIUS com tempos limite realistas.
• Verifique regularmente as exceções Device Access e ACL.

Especialmente com acesso remoto, você deve testar o MFA junto com as regras, grupos de usuários e perfis de clientes afetados do VPN. Um login WebAdmin funcional não prova automaticamente que SSL VPN, IPsec Remote Access ou Sophos Connect funcionam da mesma forma.

Planeje substituto e quebra de vidro

MFA aumenta a segurança, mas também pode bloquear administradores legítimos se o token, a hora, o servidor de autenticação ou os grupos não corresponderem. É por isso que um plano alternativo é necessário antes da ativação.

Pelo menos estes pontos devem ser documentados:

• Quem tem um segundo acesso de administrador testado?
• O acesso é possível a partir de uma rede de gerenciamento ou administrador VPN?
• O padrão local admin está protegido como conta de emergência, mas não é usado para uso diário?
• Como redefinir um token OTP perdido ou quebrado?
• Quem pode redefinir tokens para administradores?
• Como você reage fora do horário de expediente?
• Existe um backup atual antes da mudança?A alternativa não deve significar que o acesso de administrador desprotegido permaneça permanentemente acessível pela Internet. É melhor ter uma conta de emergência com documentação clara, um caminho de acesso estreito e revisões regulares.

MFA para o administrador padrão

O usuário padrão local admin é um caso especial. MFA para este usuário não está ativado diretamente na guia Autenticação multifator.

O caminho do menu é Sistema > Administration > Device access.

Lá você pode ativar MFA para administrador padrão. Você só deve fazer isso se:

• a hora do sistema está correta,
• um segundo administrador foi testado,
• o acesso funciona através de uma rede de gestão confiável,
• e está claro como você pode recuperar o acesso administrativo em caso de emergência.

O seguinte se aplica ao admin padrão: Não o desative, não o torne acessível desprotegido na Internet e não o utilize como um usuário normal. É uma conta quebrada ou de emergência.

Outros administradores não devem presumir que podem editar ou excluir o token MFA do admin padrão como um token de usuário normal. Este acesso deve ser planejado e testado conscientemente através do caminho de acesso do seu próprio dispositivo.

Configurar tokens para usuários

Uma vez ativado, o usuário precisa configurar seu segundo fator. Se Gerar token OTP com próximo login estiver ativo, o usuário faz login no User Portal ou VPN Portal e digitaliza o código QR com um aplicativo Authenticator.

Os aplicativos adequados incluem:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Outros aplicativos Authenticator compatíveis com TOTP.

O código gerado é baseado no tempo. Se a hora no firewall ou no smartphone for significativamente diferente, o login falhará.

Se User Portal estiver desabilitado, os usuários talvez não consigam configurar seus próprios tokens. Neste caso, você deve disponibilizar o portal de forma controlada ou preparar os tokens administrativamente.

Algoritmo de token e troca de aplicativos

Sophos Firewall suporta os algoritmos de hash SHA1, SHA256 e SHA512 para tokens OTP. Versões SFOS anteriores à 22.0 usam SHA1 para MFA; a partir do SFOS 22.0, tokens novos ou migrados devem ser testados com SHA256 ou SHA512. Esta opção não deve ser aplicada às cegas: o algoritmo escolhido tem de ser compatível com a aplicação de autenticação utilizada.

A Sophos indica explicitamente que a aplicação tem de suportar o algoritmo selecionado. Se uma aplicação não suportar corretamente SHA256 ou SHA512, o código QR pode ser lido, mas o login continua a falhar. Por isso, o algoritmo deve fazer sempre parte do teste piloto, sobretudo quando Microsoft Authenticator, TOTP em gestores de palavras-passe, Google Authenticator ou Sophos Intercept X for Mobile são usados em conjunto.

Estes pontos são importantes para a operação:

• Não agende mais novos tokens com suposições de aplicativos antigos.
• Use um aplicativo Authenticator que suporte o algoritmo de hash selecionado.
• Se você mudar de aplicativo ou perder seu smartphone, exclua o token antigo e regenere o código QR.
• Use tokens de hardware somente se o algoritmo, o intervalo de tempo e o segredo puderem ser gerenciados adequadamente.
• Teste um grupo piloto antes de uma migração SHA256/SHA512 em vez de trocar todos os tokens de uma vez.
• Elimine e recrie tokens SHA1 existentes de forma controlada durante uma migração.

A antiga aplicação Sophos Authenticator já não deve ser planeada como nova aplicação padrão; segundo a Sophos, está End of Life desde 31 de julho de 2022. Em muitos ambientes, Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password ou Bitwarden são opções mais realistas. A marca da aplicação é menos importante do que a compatibilidade entre TOTP, algoritmo de hash, comportamento de backup/restauro e processo de helpdesk.

Nota importante sobre senha e tokens

Dependendo do serviço Sophos, não existe um campo de formulário separado para o código OTP. Isso sempre causa confusão, especialmente com VPN Portal ou logins de acesso remoto. Nestes casos, muitas vezes o usuário precisa inserir a senha e o código OTP um após o outro.

Exemplo:

Palavra-passe: MinhaPalavraPasseSegura
Codigo OTP:    123456
Entrada:       MinhaPalavraPasseSegura123456

Isso deve ser comunicado claramente aos usuários antes da implementação. Caso contrário, parecerá ao usuário que a senha está incorreta, mesmo que esteja faltando apenas o código OTP.

Esse comportamento deve ser testado e documentado antes da implementação porque é percebido de forma diferente dependendo do serviço e da máscara de login.

Operação de teste e controle

Um teste WebAdmin bem-sucedido não é suficiente. Cada superfície de login afetada deve ser testada separadamente porque o portal, o cliente VPN, o grupo de usuários e o servidor de autenticação podem reagir de maneira diferente.

Teste de login

MFA deve primeiro ser testado com um usuário que não seja o único administrador.

Esses pontos devem ser verificados:

• Registro em WebAdmin.
• Registro em VPN Portal.
• Faça login no serviço de acesso remoto.
• Comportamento em caso de código OTP incorreto.
• Comportamento após a expiração de um código OTP.
• Acesso com usuário que não pertence ao grupo MFA.
• Faça login com senha e código OTP anexado.
• Acesso via regras ACL agendadas.

Somente quando esses testes forem bem-sucedidos o MFA deverá ser implementado em outros grupos.

Matriz de teste por serviço

Um teste MFA não deve consistir apenas em um login WebAdmin bem-sucedido. Dependendo do serviço, outros portais, grupos, perfis e arquivos de log serão aplicados. Esta matriz ajuda a examinar os casos mais importantes separadamente:

• WebAdmin: Faça login no usuário administrador com OTP correto e incorreto OTP correto permite acesso, OTP incorreto é rejeitado e registrado de forma limpa.
• Padrão admin: Teste o caminho MFA separado em Sistema > Administration > Device access A conta de emergência está protegida, mas uma rota de fuga documentada permanece disponível.
• User Portal: O próprio usuário configura tokens O código QR aparece apenas para usuários autorizados, o token funciona ao fazer login.
• VPN Portal: O usuário faz login com senha e OTP O login funciona com um formato de entrada documentado e é visível no Log Viewer.
• SSL VPN/Sophos Connect: Importar perfil ou reconectar MFA é consultado no cliente real, não apenas no navegador.
• IPsec Acesso Remoto: Verifique o grupo e o método de autenticação MFA aplica-se ao mesmo grupo que também é permitido na configuração de acesso remoto.
• MFA externo via RADIUS: Teste push, desafio ou token com cliente real O tempo limite é suficiente, o comportamento do desafio corresponde ao cliente, os erros são visíveis no servidor RADIUS.

Cada teste também deve verificar se Device Access ou uma regra ACL de serviço local permite intencionalmente o serviço. Se o token funcionar, mas o portal estiver acessível pela rede errada, a configuração MFA é apenas parte do problema resolvido.

Logs e controle operacional

Após a implementação, você deve verificar se os eventos MFA podem ser rastreados durante a operação. Isto é importante para casos de suporte, análises de segurança e resposta a incidentes.

Pontos de verificação úteis:

• Verifique eventos de autenticação no Visualizador de logs.
• Distinguir logins com falha de senha incorreta, OTP incorreto e OTP expirado.
• Documentar portal VPN e testes de acesso remoto com horário e usuário.
• Para RADIUS externo, verifique também o servidor RADIUS, os logs NPS ou os logs do provedor de identidade.
• Para armazenamento mais longo, planeje o Central Reporting ou Syslog/SIEM.

Para arquivos de log locais e mapeamento de serviço, Sophos Firewall Solução de problemas: Services e logs é adequado. Se a autenticação e os eventos do portal forem avaliados a longo prazo, Sophos Firewall enviar Syslog para SIEM é adequado.

Solução de problemas

O código OTP não é aceito

Primeiro verifique a hora do sistema do firewall e a hora do smartphone. TOTP depende do tempo. Mesmo um desvio significativo pode levar à rejeição de códigos válidos.

Você pode verificar os tokens emitidos em Autenticação > Autenticação multifator. Se um único token continuar errando o alvo, você não deve alterar imediatamente toda a configuração do MFA. Primeiro verifique o desvio do tempo do token, o aplicativo usado, o algoritmo de hash e o intervalo de tempo.

O usuário não vê o código QR

O usuário deve ser elegível para MFA e fazer login no portal correto. Além disso, deve-se verificar se o usuário foi encontrado através da fonte de autenticação esperada.

Se User Portal estiver desativado, o usuário poderá não conseguir configurar o token sozinho. O portal deve então ficar temporariamente acessível ou o token deve ser criado administrativamente.

Portal não pode ser acessado através de Device Access

Se os usuários não conseguirem configurar seu token mesmo que MFA tenha sido ativado corretamente, não deverá excluir o token primeiro. Muitas vezes, o portal necessário não pode ser acessado a partir da rede atual por meio de Sistema > Administration > Device access ou de uma regra ACL de serviço local.

Verifique primeiro:

• Qual portal é usado para configuração de token?
• De que zona ou fonte vem o usuário?
• O acesso é permitido intencionalmente ou bloqueado acidentalmente?
• Existe uma exceção de ACL mais restrita em vez de uma versão ampla?

O administrador está bloqueado

Nesse caso, use o acesso alternativo preparado. Se não existir um substituto, o acesso deverá ser avaliado por meio de console, suporte ou caminhos de recuperação, dependendo da situação.

MFA não funciona para acesso remoto

Verifique se a configuração de acesso remoto utiliza o mesmo grupo de usuários para o qual MFA foi ativado. Freqüentemente, o erro não está no MFA em si, mas em diferentes grupos em VPN e regras de autenticação.

Os perfis de cliente também devem corresponder à configuração atual. Após fazer alterações em VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO ou RADIUS, os perfis Sophos Connect afetados devem ser reimportados ou redistribuídos.

O usuário digita apenas a senha

Se um campo OTP separado não for exibido, o usuário deverá inserir a senha e o código OTP um após o outro. Este é um dos casos de suporte mais comuns após a ativação do Sophos OTP.

MFA externo não funciona de maneira confiável

Para soluções MFA baseadas em RADIUS, os tempos limite, o comportamento do desafio e os grupos devem se ajustar perfeitamente. Se Push-MFA, Call-MFA ou respostas de desafio forem usadas, você deverá testar todo o processo de login com o cliente afetado.

MFA foi ativado para o grupo errado

Se MFA funcionar para alguns usuários e não para outros, você deve primeiro comparar os grupos tecnicamente. Não apenas os nomes de exibição visíveis são relevantes, mas também os grupos realmente importados ou correspondentes de AD, LDAP, RADIUS ou Entra ID. Um usuário pode autenticar com sucesso e ainda assim não acabar no grupo para o qual MFA é necessário.

Lista de verificação operacional e recomendação

Após a ativação técnica, o MFA precisa de um processo operacional simples: quem redefine os tokens, quem verifica os logs e como é verificado se os portais não estão amplamente acessíveis desnecessariamente?

Lista de verificação de operações

• Hora do sistema e NTP verificados.
• Grupo piloto definido e testado.
• MFA não ativado diretamente para todos os administradores ao mesmo tempo.
• Segundo administrador e acesso de quebra de vidro documentado.
• Device Access e Local Service ACL testados para WebAdmin, User Portal, VPN Portal e SSL VPN.
• Acesso de redes de fontes permitidas e proibidas testadas.
• Usuário informado sobre comportamento de senha+OTP.
• Processo de redefinição de token documentado para smartphones perdidos.
• Aplicativo Authenticator, algoritmo de hash e migração de token documentados.
• Acesso Remoto testado com clientes reais e perfis atuais.
• Tempo limite RADIUS/Entra testado se MFA externo for usado.
• Logs e armazenamento central verificados.

Recomendação operacional

MFA deve ser padrão para acesso administrativo. MFA é particularmente importante para WebAdmin, VPN Portal e todos os usuários com autorização de acesso remoto.

Para ambientes pequenos, a função OTP do próprio Sophos costuma ser suficiente. Em ambientes Microsoft 365 ou Entra ID, um MFA externo sobre RADIUS pode ser mais conveniente porque os usuários não precisam aprender um segundo mundo MFA.

Independentemente da variante MFA, o seguinte se aplica: primeiro restrinja o acesso com regras ACL, teste Admin-MFA cuidadosamente, informe os usuários sobre senha + token e só então implemente-o amplamente.

Perguntas frequentes