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. Depois, guardar o utilizador com Save, confirmar a entrada na lista de utilizadores e voltar a abri-la: User type: Administrator, Profile, Schedule for device access e Login restriction for device access têm de corresponder aos valores previstos antes de sair de Users.
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. None impede o administrador de ver a configuração em causa no WebAdmin ou de a obter através da API. Read-only, por sua vez, permite consultá-la, mas não alterá-la.
• 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.

Durante a primeira configuração, é obrigatório alterar a palavra-passe de fábrica do superadministrador predefinido. A nova palavra-passe não pode ser uma palavra-passe de uso comum nem uma palavra de dicionário: a firewall compara-a com uma base de dados correspondente e pede a sua alteração se encontrar uma correspondência. Esta verificação já faz parte da configuração inicial, não apenas da criação de contas pessoais.

Numa atualização a partir de 18.0 MR3 ou anterior ou 17.5 MR14, é necessária uma alteração única da palavra-passe do superadministrador predefinido para beneficiar de uma proteção mais forte da palavra-passe. Não é um requisito geral para todas as atualizações de firmware.

Guardar a palavra-passe atual num cofre de palavras-passe com acesso controlado. Se se regressar a uma versão anterior do firmware que utiliza esta palavra-passe, será necessária para iniciar sessão nessa versão. Antes de reverter o firmware, devem estar disponíveis a palavra-passe exigida pela versão anterior e um acesso de recuperação independente; não presumir que a última palavra-passe definida no firmware mais recente também é válida nessa versão.

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 Fusion. Um utilizador assinalado como Managed by Central em Authentication > Users é gerido no Sophos Fusion e não pode ser editado localmente.

Para o SFOS 23, Google Workspace OIDC com mapeamento de grupos de administradores descreve outra via de autenticação centralizada, com uma conta de serviço separada, perfis locais de Device Access e o planeamento e a verificação do processo de reversão.

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.

Alterar permissões existentes sem perder o acesso

Para consultar um perfil existente, abrir Profiles > Device access e selecionar Edit no perfil em causa. Utilizar Expand para abrir os submenus e ver toda a matriz de permissões atual; numa simples consulta, não alterar nem guardar quaisquer permissões. Os perfis predefinidos continuam sem poder ser editados: Edit permite apenas consultá-los e as permissões só podem ser alteradas em perfis personalizados.

Uma alteração de perfil afeta todos os administradores a quem está atribuído. Antes de o restringir, documentar o nome atual, toda a matriz expandida e todas as contas atribuídas. O estado anterior inclui também a ordem em Authentication > Services > Administrator authentication methods, o horário, a restrição de login, as permissões WebAdmin em Administration > Device access e os valores atuais de complexidade da palavra-passe e Block login. Um backup atual, uma sessão aberta de um segundo administrador completo e acesso testado à consola são pré-requisitos, mas não constituem o próprio rollback.

Em vez de editar diretamente um perfil partilhado, criar separadamente o perfil mais restritivo e atribuí-lo primeiro a exatamente uma conta piloto. Migrar as outras contas uma a uma apenas após o teste positivo, o negativo e a verificação da auditoria.

O rollback seguro repõe, através da sessão completa ainda aberta, os valores anteriores exatamente documentados: voltar a atribuir o perfil anterior à conta piloto e devolver métodos e ordem de autenticação, horário, restrição de login, Device Access e valores de bloqueio ao respetivo estado anterior. Se a sessão já não estiver disponível, usar o segundo administrador testado ou a consola local. Restaurar um backup completo apenas numa janela de recuperação planeada, pois também reverte alterações não relacionadas.

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 SFOS guarda-o em minúsculas e converte automaticamente maiúsculas; 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.
8. Antes de guardar, configurar as Administrator advanced settings descritas a seguir. Depois, guardar e verificar o utilizador conforme indicado abaixo antes de passar a Services ou MFA.

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 selecionados ou de um intervalo IPv4. Para um jump host administrativo, selecionar Selected nodes, introduzir o endereço de exemplo 10.20.30.25 depois de o substituir pelo endereço adequado ao próprio ambiente e clicar no botão mais (+) para cada endereço IPv4. Verificar se a lista resultante corresponde às origens previstas. Se se optar por Node range, introduzir antes os endereços inicial e final do intervalo IPv4 previsto. Depois, guardar o utilizador conforme indicado abaixo; escrever o endereço, por si só, não acrescenta uma entrada à lista.

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.

Depois de preencher os campos do utilizador e as Administrator advanced settings, clicar em Save antes de sair de Authentication > Users. Confirmar que o utilizador aparece na lista e voltar a abrir a entrada. User type tem de ser Administrator; Profile, Schedule for device access e Login restriction for device access, incluindo os endereços IPv4 adicionados, têm de corresponder aos valores previstos. Só depois passar a Services ou MFA. Manter disponíveis a sessão administrativa existente e a via de recuperação independente para os testes seguintes.

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.

XML API: não adotar valores de modo contraditórios

Para a automatização, a documentação da XML API da Sophos para o SFOS 22 e 23 indica os caminhos AdminAuthentication/AuthenticationMethods e AdminAuthentication/AuthenticationServerList/AuthenticationServer. O exemplo mostra SameAsFirewall/Custom para o primeiro caminho e ServerName para o servidor; não se trata de uma seleção de modo executável e verificada.

A tabela de parâmetros contradiz o exemplo: para AuthenticationMethods, permite apenas o token escrito literalmente como ''on''. As descrições também parecem trocadas: AuthenticationServer descreve a adoção do método de autenticação da firewall, enquanto AuthenticationMethods descreve o servidor utilizado no login. Não se pode deduzir daí nem um seletor confirmado nem uma correspondência de on com Custom.

Até que a Sophos esclareça oficialmente os valores para o build de destino específico, não é fornecida qualquer receita executável para selecionar o modo. Manter o método local de recuperação e a ordem documentada dos servidores; qualquer alteração posterior aprovada deve integrar o plano de aceitação e rollback existente.

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 existem duas secções separadas: Administrator password complexity settings para administradores e User password complexity settings para utilizadores. Ativar Enable password complexity check separadamente em cada secção e definir a complexidade pretendida. A definição dos administradores não substitui a dos utilizadores. Escolher os valores segundo a política de palavras-passe da organização; não é indicada aqui uma extensão mínima nem uma quantidade fixa de caracteres como requisito do produto. Antes de uma alteração, documentar ambas as definições e os valores anteriores. Depois de guardar, voltar a abrir a página e verificar as duas secções separadamente, mantendo disponível o acesso de recuperação testado.

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.

Antes de alterar Block login, registar exatamente o estado da caixa, o número e a janela temporal das tentativas falhadas e a duração do bloqueio. Ao atingir o limite, o IP de origem fica bloqueado para WebAdmin, CLI, VPN Portal e User Portal. Uma única tentativa falhada abaixo do limite não testa este bloqueio; a Sophos também indica que um CAPTCHA falhado não conta como tentativa de login falhada. Em produção, verificar primeiro apenas se os valores foram guardados e se os logins válidos continuam a funcionar a partir das duas origens de gestão. Se for necessário um teste real de bloqueio, realizá-lo numa janela de manutenção a partir de uma origem de teste isolada até atingir o limite. Em seguida, verificar o bloqueio esperado, aguardar a duração documentada ou usar o caminho de recuperação independente e confirmar depois um login válido. Perante comportamento inesperado, usar a sessão de recuperação aberta para repor exatamente os valores anteriores.

A opção Log out admin session after termina por predefinição as sessões WebAdmin inativas após 10 minutos. Se a opção for desativada, a sessão não permanece aberta indefinidamente: o SFOS termina-a automaticamente após 30 minutos. A desativação não é, por isso, um método para manter sessões administrativas permanentes; o comportamento real deve ser verificado com uma sessão de teste.

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. Testar as duas restrições separadamente:
   • Com None, a configuração em causa não pode estar visível nem ser legível. Uma alteração recusada, por si só, não é prova suficiente.
   • Com Read-only, a configuração prevista tem de continuar legível, mas uma alteração proibida não pode ser guardada. Utilizar apenas uma ação de teste inofensiva e previamente aprovada, com rollback preparado.
   • Se a conta já for utilizada para acesso à API, verificar separadamente as leituras API previstas e os acessos recusados com as proteções existentes para origens, permissões e segredos. Não ativar o acesso à API apenas para testar uma conta WebAdmin interativa.
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.

Os logs e relatórios não são sincronizados entre dispositivos HA: no diagnóstico, verificar Log viewer > System e os eventos de autenticação relevantes em ambos. Desde o SFOS 22.0 MR1, as alterações a uma firewall individual através do Sophos Fusion (anteriormente Sophos Central) registam a identidade do utilizador Sophos Fusion e as sessões SSO do Entra ID reavaliam as políticas de Conditional Access. Após uma atualização, validar esta atribuição com uma alteração inofensiva. Antes de cada implementação, verificar o build de destino, o percurso de atualização suportado e os bloqueios específicos da versão na verificação de atualização para o SFOS 22 e aprová-los na alteração; a verificação de versões e problemas conhecidos aí efetuada determina a decisão de implementação.

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.

Esta conta deve ser distinguida do acesso do fabricante em Diagnostics > Support access. Este gera, durante o período selecionado, um Access ID que permite ao Sophos Support aceder a WebAdmin e à shell sem receber credenciais de administrador. A firewall estabelece a ligação por TCP 22 a *.apu.sophos.com; os sistemas a montante têm de a permitir. Partilhar o Access ID apenas no caso de suporte ativo, acompanhar o estado durante os trabalhos e desativar Support access imediatamente depois, mesmo que o período ainda não tenha terminado.

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 Fusion 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.

O NC-177609 está documentado especificamente para o SFOS 22.0 GA Respin Build 411: após uma atualização, as alterações de configuração através da API de um utilizador migrado podem ser rejeitadas quando o MFA está ativo e o pedido não inclui um one-time token. Se o sintoma corresponder exatamente, registar o build e o estado de migração da conta. A solução documentada exige que a automatização utilize uma conta API dedicada com privilégios mínimos, com o MFA desativado ou explicitamente excluída do MFA; o MFA permanece ativo para administradores interativos. O responsável designado pela API deve aprovar e documentar esta exceção, atribuir um proprietário à conta e uma data de revisão, limitar a origem e as permissões da API, guardar o segredo num cofre e efetuar a sua rotação, monitorizar a utilização e remover a exceção quando deixar de ser necessária. Após a alteração, validar com um pedido de leitura inofensivo e depois com uma operação de escrita controlada e aprovada, com rollback. Proteger o acesso à XML API do Sophos Firewall e o responsável designado pela API são conjuntamente responsáveis por este processo; não inferir o estado da correção a partir de um build posterior.

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.
• Estão documentados o estado anterior e o rollback entre contas para alterações de perfil, autenticação e bloqueio.
• Em HA, foram verificados um novo login e os logs separados em ambos os dispositivos.
• 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