Configurar administradores e perfis Sophos Firewall em segurança

Na administração diária, cada pessoa deve ter a sua própria conta. Primeiro cria-se um perfil Device Access adequado e, depois, um utilizador local com User type: Administrator em Authentication > Users. O perfil determina o que o administrador pode ver ou alterar. MFA, origens de login e Device Access protegem adicionalmente a autenticação e a acessibilidade do WebAdmin.

O administrador predefinido admin permanece como acesso de emergência testado e não é utilizado como conta diária partilhada. Assim, as alterações continuam associadas a uma pessoa e um erro num perfil limitado não bloqueia a última via de recuperação.

Configurar um administrador local em oito passos

1. Verificar o backup, o administrador predefinido e o acesso de recovery. Manter uma sessão administrativa existente aberta até o teste ser concluído com êxito.
2. Definir por escrito a tarefa e as permissões necessárias, por exemplo, apenas diagnóstico ou também alterações a objetos de rede.
3. Criar um perfil próprio em Profiles > Device access > Add e deixar as áreas desnecessárias como None.
4. Introduzir um nome de utilizador pessoal em Authentication > Users > Add e definir User type como Administrator.
5. Atribuir o novo perfil, uma palavra-passe forte e exclusiva e o endereço de e-mail profissional.
6. Em Administrator advanced settings, limitar Schedule for device access e Login restriction for device access quando necessário.
7. Confirmar que Local continua disponível em Authentication > Services > Administrator authentication methods. Depois, configurar o MFA e o acesso WebAdmin a partir da rede de gestão.
8. Testar a conta de forma positiva e negativa numa janela privada do browser. Só depois alterar outras contas ou desativar acessos antigos.

⚠️ Um novo perfil só deve ser usado em produção quando existir um segundo administrador funcional e uma via de recovery documentada. O perfil integrado Administrator concede acesso total e deve ficar limitado ao menor número de pessoas necessário.

Distinguir as cinco camadas de proteção

No acesso administrativo, várias definições funcionam em conjunto. Têm finalidades diferentes e não se substituem umas às outras:

• Conta de utilizador: identifica a pessoa. As contas pessoais tornam as alterações rastreáveis; contas de equipa como firewalladmin ocultam essa atribuição.
• Perfil Device Access: define, através de None, Read-only e Read-write, que menus e funções ficam visíveis ou podem ser alterados. As permissões também se aplicam à API.
• Schedule e Login Restriction: limitam quando e a partir de que endereços IPv4 esta conta de administrador pode utilizar o WebAdmin.
• Device Access e Local Service ACL: definem a partir de que zonas e origens o WebAdmin está acessível. A implementação é descrita em Configurar Device Access e Local Service ACL em segurança.
• MFA e Audit Trail: o MFA protege a conta além da palavra-passe. O Audit Trail ajuda a associar alterações suportadas a uma identidade, origem e consola. Para Data Anonymization em logs e relatórios, são também preparados pelo menos dois authorizers pessoais com contas separadas.

Um perfil Read-only não protege, por exemplo, contra o roubo da palavra-passe. Por sua vez, o MFA não impede ataques a uma página de login desnecessariamente exposta ao público. Só a combinação reduz tanto as permissões como a superfície de ataque.

Os avisos de início de sessão e as mensagens personalizadas acrescentam apenas informações visíveis a estes níveis. A aceitação não amplia nem o perfil Device Access nem a autorização de rede e não substitui nenhum dos cinco controlos.

Administrador predefinido, contas locais e identidades centrais

O utilizador predefinido admin tem as permissões do perfil integrado Administrator. É adequado como acesso de emergência local, mas não como conta diária partilhada. Palavra-passe, MFA, acesso à consola e processo de recovery devem estar documentados e testados independentemente das contas pessoais.

Administradores locais pessoais são adequados para equipas pequenas, firewalls isoladas e como fallback deliberado. Equipas maiores podem gerir funções de administrador através do Microsoft Entra ID SSO para WebAdmin, de TACACS+ com atribuição local de perfil ou das funções administrativas do Sophos Central. Um utilizador assinalado como Managed by Central em Authentication > Users é gerido no Central e não pode ser editado localmente.

As automações não recebem uma conta diária pessoal. Para a XML API, utiliza-se uma conta de serviço separada, com responsável próprio, permissões limitadas e origem fixa autorizada. O percurso completo de proteção é apresentado em Proteger o acesso à XML API do Sophos Firewall.

Planear um perfil Device Access

Em Profiles > Device access, a Sophos disponibiliza vários perfis predefinidos que não podem ser editados:

• Administrator: acesso total ao WebAdmin e à API. A Sophos também descreve o perfil com acesso total à CLI; ainda assim, no SFOS, o login SSH direto só é possível com o nome de utilizador predefinido admin.
• Audit admin: acesso de leitura e escrita a logs e relatórios.
• Crypto admin: acesso de leitura e escrita a certificados de segurança.
• HAProfile: acesso Read-only ao equipamento Auxiliary de um cluster HA.
• Security admin: acesso de escrita às funções, exceto perfis, logs e relatórios.

Estes perfis são pontos de partida úteis, mas não correspondem automaticamente à função adequada para cada operação. Um perfil próprio é melhor quando uma pessoa só necessita de uma área de responsabilidade claramente limitada.

Derivar as permissões da tarefa

O nome do perfil, por si só, não tem efeito técnico. Um perfil chamado ReadOnly pode continuar a incluir permissões de escrita. O que conta é a matriz completa de permissões, incluindo os submenus expandidos.

Para uma conta de helpdesk, pode planear-se, por exemplo:

• Definir como Read-only o diagnóstico, os logs e as áreas de configuração necessárias ao suporte.
• Atribuir Read-write apenas quando a equipa tiver de executar autonomamente uma alteração concretamente definida.
• Deixar os perfis de administrador, certificados e todas as áreas de produto desnecessárias como None.
• Para cada permissão de escrita, definir um exemplo do que deve ser permitido e outro do que não pode ser permitido.

Um perfil Network Operations pode ler mais áreas e, por exemplo, alterar áreas de rede selecionadas. Mesmo assim, não necessita de acesso total a administradores, certificados ou outras funções de segurança independentes. Least Privilege não significa mostrar o menor número possível de menus, mas conceder exatamente as permissões necessárias para a tarefa atribuída.

Criar um perfil próprio

1. Abrir Profiles > Device access.
2. Selecionar Add.
3. Introduzir um nome inequívoco, por exemplo SFOS-NOC-Limited.
4. Selecionar None, Read-only ou Read-write para cada menu visível.
5. Abrir os submenus com Expand e limitar de forma mais restrita as permissões divergentes.
6. Guardar com Save.
7. Comparar novamente o perfil com as tarefas documentadas e os testes negativos.

SFOS-NOC-Limited é apenas um nome de exemplo. Deve ser adaptado à equipa e à tarefa. As permissões efetivamente atribuídas também têm de ser documentadas, porque o nome não explica a matriz de permissões.

Criar um administrador local pessoal

Registar o utilizador

1. Abrir Authentication > Users.
2. Selecionar Add.
3. Em Username, introduzir um nome pessoal permanente, por exemplo m.mueller. O nome de utilizador não pode ser alterado mais tarde.
4. Registar um nome de apresentação compreensível e o endereço de e-mail profissional.
5. Definir User type como Administrator.
6. Em Profile, selecionar o perfil SFOS-NOC-Limited previamente verificado.
7. Definir uma palavra-passe longa, exclusiva e transmitida em segurança. Se a firewall detetar uma palavra-passe de uso frequente ou uma palavra de dicionário, exige uma palavra-passe mais forte.

m.mueller é um modelo e deve ser substituído pela identidade inequívoca da pessoa responsável. Nomes funcionais como noc-admin só devem ser usados quando correspondem realmente a uma única identidade técnica com responsável próprio. Várias pessoas não partilham uma palavra-passe.

Limitar o horário e a origem de login

Em Administrator advanced settings estão disponíveis dois controlos adicionais:

• Schedule for device access: permite logins WebAdmin apenas durante o horário selecionado. É adequado para suporte temporário ou horários operacionais definidos. Num serviço de prevenção, o horário não pode bloquear involuntariamente intervenções de emergência necessárias.
• Login restriction for device access: permite o login WebAdmin apenas a partir de endereços IPv4 ou de um intervalo IPv4 selecionado. Para um jump host administrativo, pode utilizar-se, por exemplo, 10.20.30.25 como Selected node.

O endereço 10.20.30.25 é um exemplo de uma rede privada. Deve ser substituído pelo endereço fixo do jump host ou posto de gestão utilizado. Com endereços de cliente variáveis, uma VPN administrativa ou uma rede de gestão dedicada é normalmente mais adequada do que um intervalo IP amplo.

Access Time para utilizadores e grupos normais controla o acesso à internet; para o WebAdmin, é relevante Schedule for device access em Administrator advanced settings. Não são a mesma definição.

Manter a autenticação local

Em Authentication > Services > Administrator authentication methods, a base de dados local tem de estar selecionada para administradores locais pessoais. O superadministrador predefinido admin está excluído desta lista de métodos, mas os administradores locais recém-criados não.

O método local não deve ser removido antes de a nova conta ser testada com êxito num browser separado. Com servidores de autenticação externos, a ordem determina para onde é enviada primeiro uma tentativa de login. As alterações dessa ordem pertencem, por isso, ao mesmo plano de aceitação e rollback da própria conta.

Proteger o login com MFA e limitar a acessibilidade

O MFA deve ser ativado para administradores interativos. Os administradores pessoais são adicionados em Authentication > Multi-factor authentication para Web admin console. Para o utilizador predefinido admin, existe um interruptor separado em Administration > Device access > MFA for default admin. O artigo Ativar MFA para Sophos Firewall WebAdmin explica o grupo piloto, o registo do token, Login Security e recovery. O MFA é testado primeiro com um único novo administrador, não simultaneamente com todas as contas.

O WebAdmin continua também limitado a redes de gestão, VPN ou origens estritamente definidas. Uma opção Login restriction for device access ativa não torna segura uma ampla autorização a partir da WAN. Inversamente, uma Local Service ACL não substitui a conta pessoal nem o seu perfil de permissões.

Um teste WebAdmin bem-sucedido também não autoriza SSH. O SFOS só aceita o nome de utilizador admin para login SSH direto; por isso, um administrador WebAdmin local pessoal não é testado como conta SSH. O SSH requer ainda uma decisão própria de Device Access. A gestão da chave pública do administrador predefinido e o acesso SSH seguro são tratados separadamente em Ligar à Sophos Firewall por SSH.

Em Administration > Admin and user settings, Administrator password complexity, Session Timeout e Block login complementam as definições das contas. Estes valores aplicam-se a todo o sistema e, por isso, não são endurecidos de forma agressiva para uma única conta. Em especial, Block login pode bloquear o endereço IP de origem para todos os serviços de login após tentativas falhadas; antes do teste, é necessária uma segunda origem de gestão ou acesso à consola.

Testar permissões e login em segurança

Antes do teste, mantêm-se disponíveis a janela administrativa existente e uma via de recovery independente. Vários logins falhados intencionais são inadequados, porque Block login pode bloquear temporariamente o endereço IP de origem comum para outros serviços de login.

1. Abrir uma janela privada do browser e aceder ao WebAdmin através do FQDN previsto a partir da rede de gestão autorizada.
2. Iniciar sessão com a nova conta e MFA.
3. Verificar se todos os menus necessários estão visíveis e se as informações previstas podem ser lidas.
4. Se o perfil tiver permissões de escrita, executar uma alteração de teste inofensiva e previamente aprovada, com rollback imediato.
5. Abrir uma área definida como None ou Read-only. A conta não pode guardar aí uma alteração proibida.
6. Testar no máximo uma vez um login controlado a partir de uma origem não autorizada. Se o resultado não for claro, analisar primeiro as definições e os logs, sem gerar mais tentativas falhadas.
7. Verificar a alteração de teste e o administrador utilizado no Configuration Audit Trail. Nem todos os objetos geram o mesmo nível de detalhe; o efeito técnico também é verificado na função afetada.
8. Terminar a sessão, iniciar novamente e só depois migrar a conta seguinte.

Num cluster HA, após um failover planeado, verifica-se adicionalmente um novo login no node agora ativo. Uma sessão WebAdmin existente ou a sua continuação sem interrupções não é um critério de sucesso fiável.

Um menu visível ainda não comprova que a permissão de escrita funciona. Um menu oculto não comprova que as outras funções atribuídas estão corretas. Por isso, teste positivo, teste negativo e associação no Audit Trail devem ser considerados em conjunto.

Verificar e remover contas em segurança

Os acessos administrativos são revistos regularmente quanto ao responsável, tarefa, perfil, MFA, origem de login e última utilização. As contas temporárias de suporte recebem ainda uma data final documentada. Para um caso Avanet limitado no tempo, continua a aplicar-se o procedimento específico Configurar o acesso Avanet Support na Sophos Firewall.

No offboarding, um processo controlado é mais seguro do que a eliminação imediata:

1. Verificar se a conta é utilizada em scripts de API, cofres de palavras-passe, documentação ou processos de suporte.
2. Em Authentication > Users, definir o estado como inativo.
3. Confirmar num browser privado que já não é possível iniciar uma nova sessão.
4. Verificar separadamente as sessões WebAdmin ativas e as alterações recentes. A desativação não pode ser considerada, sem verificação, como prova de que todas as sessões existentes terminaram imediatamente.
5. Remover ou rodar tokens MFA, secrets e atribuições externas associados à conta.
6. Após o período de observação acordado, eliminar o utilizador se já não existirem dependências.
7. Eliminar um perfil personalizado que deixou de ser necessário apenas quando já não estiver atribuído a nenhum administrador.

O administrador predefinido não faz parte deste offboarding normal. Se a palavra-passe ou o acesso MFA forem perdidos, o artigo Recuperar a palavra-passe de administrador da Sophos Firewall ajuda a preparar a via de recovery.

Diagnosticar problemas típicos

A conta existe, mas o login WebAdmin falha

Verificar estes pontos pela ordem indicada:

• User type está realmente definido como Administrator.
• O estado do utilizador está ativo e a palavra-passe está correta.
• Local está selecionado em Administrator authentication methods.
• Schedule for device access permite o horário atual.
• Login restriction for device access contém o endereço IPv4 de origem real.
• O token MFA, a hora do sistema e o registo estão corretos.
• Block login não bloqueou o endereço IP de origem após tentativas falhadas.
• Device Access ou uma Local Service ACL permite HTTPS a partir desta origem.

Se a página de login não estiver acessível, a análise começa em Device Access, routing e endereço de origem. Se estiver acessível, mas rejeitar apenas esta conta, o utilizador, o perfil, o método de autenticação, Schedule, Login Restriction e MFA são as pistas mais prováveis.

Para a correlação temporal, são úteis a área Authentication no Log Viewer e access_server.log para autenticação e autorização. syslog.log acrescenta eventos de sistema e eventos iniciados pelo administrador. As alterações a objetos suportados são verificadas separadamente em configuration-audit.log.

A conta vê demasiado ou demasiado pouco

Verificar o perfil atribuído e os respetivos submenus expandidos. Read-only e Read-write podem ter definições diferentes dentro de um menu principal. Depois, testar novamente com um novo login, sem confiar apenas no nome do perfil.

Com Managed by Central, a função vem do Sophos Central e não é alterada no utilizador local. Com Entra SSO, o mapeamento de funções ou grupos do servidor Entra determina o perfil Device Access local.

WebAdmin funciona, mas API ou SSH não

O perfil Device Access também se aplica às permissões da API, mas a API necessita adicionalmente de acesso API ativado e de uma origem autorizada. O SSH é um serviço local separado e não constitui um teste de sucesso adequado para um perfil WebAdmin limitado. Uma conta não obtém acesso SSH apenas porque o login WebAdmin funciona.

Lista de verificação operacional

• O administrador predefinido e a via de recovery estão testados e não são partilhados.
• Cada pessoa utiliza a sua própria conta.
• Os perfis derivam das tarefas e os submenus expandidos foram verificados.
• O acesso total está limitado ao menor número de pessoas necessário.
• MFA, Schedule e origem de login correspondem à finalidade.
• O WebAdmin só está acessível a partir das origens de gestão previstas.
• Foram realizados testes positivos e negativos das permissões.
• As alterações são rastreáveis, quando suportado, no Audit Trail através de uma conta admin pessoal.
• As contas de API e suporte têm responsáveis e ciclos de vida próprios.
• O offboarding inclui estado, sessões, MFA, secrets e dependências.

FAQ