Criar e gerir utilizadores locais na Sophos Firewall

Um utilizador local é armazenado diretamente na Sophos Firewall e autenticado através da base de dados local de utilizadores. Esta opção é adequada para ambientes pequenos, contas piloto e colaboradores externos individuais. Uma conta local só deve servir de alternativa a um serviço de diretório se tiverem sido testados, nesse serviço, a ordem dos servidores, um nome de utilizador distinto, o acesso ao portal e o comportamento em caso de falha da fonte externa. A ajuda do SFOS documenta a ordem dos servidores, mas não garante a comutação para todos os tipos de erro.

Este artigo aplica-se à interface WebAdmin do SFOS 22. A simples criação de um utilizador não lhe concede acesso. O grupo, o método de autenticação, o portal ou cliente e a regra de firewall ou política VPN têm de estar corretamente configurados em conjunto.

Fluxo de trabalho rápido:

1. Definir o caso de utilização, o grupo de destino e o serviço necessário.
2. Preparar um grupo restritivo do tipo Normal em Authentication > Groups.
3. Em Authentication > Users > Add, introduzir um nome de utilizador permanente e selecionar User type: User.
4. Atribuir uma palavra-passe individual forte e o grupo correto.
5. Deixar os campos de políticas do utilizador inalterados quando devem ser aplicados os valores do grupo.
6. Limitar conscientemente Simultaneous sign-ins e Sign-in restriction.
7. Em Authentication > Services, confirmar que Local está selecionado para o serviço utilizado.
8. Configurar separadamente e com o menor âmbito possível o portal, a regra de utilizador ou a política de Remote Access.
9. Usar uma conta-piloto para testar um início de sessão positivo, um negativo e tráfego real.
10. Só depois ativar MFA, criar mais utilizadores e documentar o offboarding.

⚠️ O nome de utilizador não pode ser alterado posteriormente. Defina o esquema de nomes, o tipo de conta e o responsável antes de guardar. O SFOS converte as letras maiúsculas do nome de utilizador em minúsculas. Uma conta de substituição tem uma nova identidade; volte, por isso, a verificar regras, quotas, atribuições VPN e registos de auditoria.

Quando um utilizador local é adequado

Os utilizadores locais não necessitam de Active Directory nem de um servidor RADIUS ou LDAP externo. Isto simplifica a implementação, mas transfere totalmente para a firewall a gestão de palavras-passe, MFA, grupos, desativação e revisões. É uma solução prática para um pequeno número de contas cuidadosamente geridas. Com muitos colaboradores ou entradas e saídas frequentes, um diretório central é normalmente mais fácil de manter.

Um utilizador local normal é adequado, por exemplo, para:

• uma conta-piloto para Captive Portal, User Portal ou Remote Access;
• um ambiente pequeno sem serviço de diretório;
• um prestador externo individual com duração e responsabilidade claras;
• uma alternativa testada, com um nome de utilizador próprio, quando uma fonte externa de utilizadores estiver temporariamente indisponível.

Não utilize uma conta local para várias pessoas. As credenciais partilhadas dificultam a alteração de palavras-passe, a MFA, as quotas, a auditoria e um offboarding adequado.

Não misturar tipos de utilizador

O SFOS disponibiliza vários tipos de utilizador semelhantes que resolvem tarefas diferentes:

• Um utilizador local normal inicia sessão com nome de utilizador e palavra-passe e recebe políticas através de um grupo normal ou de substituições deliberadas ao nível do utilizador.
• Um utilizador convidado tem duração limitada, utiliza as definições Guest User e é normalmente usado através de Captive Portal.
• Um Clientless User é identificado por um endereço IP e não efetua um início de sessão interativo.
• Um administrador local recebe User type: Administrator e um perfil Device Access para permissões WebAdmin.
• Um utilizador AD, LDAP, RADIUS ou Entra é autenticado por uma fonte externa. Dependendo do método, o respetivo registo local só é criado no primeiro início de sessão bem-sucedido.

Para uma pessoa que deva iniciar sessão em Captive Portal ou num serviço VPN, utiliza-se User type: User. Isto não concede à conta acesso WebAdmin nem SSH.

Exemplo e pré-requisitos

O exemplo seguinte utiliza:

• nome de utilizador pilotuser01;
• nome apresentado Local Pilot User;
• endereço de e-mail pilotuser01@example.com;
• grupo Local_Pilot_Users;
• regra de firewall Local-Pilot-to-WAN;
• origem de início de sessão permitida entre 10.20.30.10 e 10.20.30.50.

example.com é um domínio reservado para documentação e o intervalo de endereços pertence a uma rede privada de exemplo. Substitua o nome de utilizador, o endereço de e-mail, o grupo, a regra e os endereços por valores do seu ambiente. O nome de utilizador, por não corresponder a um endereço de e-mail, permanece válido mesmo que esse endereço seja alterado. O esquema de nomes deve estar alinhado com o helpdesk, o processo de offboarding e os nomes existentes no diretório.

Antes de criar a conta, é necessário esclarecer:

• Que serviço autentica o utilizador: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec ou outro acesso suportado?
• Que grupo normal contém a configuração de base comum?
• Que política de firewall ou Remote Access permite o acesso posterior?
• A partir de que endereços IPv4 a conta pode iniciar sessão?
• Quantos inícios de sessão simultâneos são realmente necessários?
• É necessário MFA local e através de que portal será efetuado o registo inicial?
• Quem desativa a conta e verifica as sessões existentes durante o offboarding?

Gerir grupos de utilizadores e Main Group na Sophos Firewall explica a lógica comum dos grupos. Para utilizadores locais normais, usa-se um grupo do tipo Normal. Um grupo do tipo Clientless pertence ao modelo baseado em IP e não é a base adequada para este fluxo de início de sessão.

Criar o utilizador local

A conta é criada em Authentication > Users > Add:

1. Em Username, introduza pilotuser01. O SFOS guarda o valor em minúsculas e este não pode ser alterado posteriormente.
2. Em Name, introduzir Local Pilot User.
3. Definir User type como User.
4. Introduzir e confirmar uma palavra-passe longa e individual proveniente do processo de palavras-passe previsto.
5. Em Email, introduza pilotuser01@example.com ou o endereço de correio eletrónico desta pessoa. Para uma conta técnica, utilize um endereço monitorizado com um responsável claramente identificado.
6. Em Group, selecionar Local_Pilot_Users.
7. Altere os campos Quarantine digest, de política e de Remote Access apenas quando a funcionalidade ou uma exceção documentada ao nível do utilizador o exigir.
8. Definir adequadamente Simultaneous sign-ins e Sign-in restriction.
9. Guardar com Save.

O SFOS rejeita palavras-passe comuns e palavras detetadas pela verificação de dicionário. Utilize em cada conta uma palavra-passe longa e exclusiva, gerada de acordo com o processo de gestão de palavras-passe previsto. Uma palavra-passe de exemplo que pudesse ser copiada tornar-se-ia imediatamente um segredo conhecido e, por isso, não seria um modelo seguro.

A mesma vista de utilizadores também apresenta registos autenticados externamente. Para utilizadores importados do Active Directory, a firewall substitui o valor Email introduzido localmente pelo endereço do AD no momento da autenticação. Uma correção local não é, por isso, permanente; a equipa responsável pela administração do AD tem de corrigir o valor na origem.

Para utilizadores AD que pertençam a vários grupos, Group apresenta o Main Group e Other group memberships os restantes grupos AD. Other group memberships aparece a cinzento e não pode ser editado localmente para utilizadores sincronizados através de um servidor de autenticação externo, como AD ou RADIUS. As pertenças a grupos são verificadas e alteradas na fonte responsável, não contornadas através de um grupo local de substituição. O artigo sobre grupos referido acima explica que funcionalidades utilizam os grupos AD adicionais; este suporte não se aplica automaticamente ao RADIUS.

Valores do grupo ou substituições do utilizador

No registo do utilizador podem ser definidos Surfing quota, Access time, Network traffic e Traffic shaping, além de vários campos de Remote Access. Os valores específicos do utilizador têm prioridade sobre os valores do grupo. Se o grupo deve continuar a ser a configuração de base fácil de manter, não substitua estes campos apenas por precaução.

Uma substituição do utilizador é adequada para uma exceção claramente documentada, por exemplo um Access Time mais restritivo durante uma intervenção temporária. É necessário registar:

• que campo difere do valor do grupo;
• por que motivo a exceção é necessária;
• quando será revista ou removida;
• como o valor original do grupo voltará a ser aplicado.

Access Time para utilizadores e quotas de Surfing e Network Traffic explicam integralmente cada política. No objeto de utilizador só se atribui uma política cujo funcionamento já seja compreendido.

Limitar o número e a origem dos inícios de sessão

Simultaneous sign-ins limita as sessões simultâneas. Global setting adota o valor aplicável aos novos utilizadores em Authentication > Services. Em alternativa, pode definir-se um valor próprio ou escolher Unlimited. Sessões ilimitadas raramente são necessárias para um utilizador pessoal normal e dificultam a deteção de credenciais partilhadas.

Sign-in restriction limita os endereços IPv4 a partir dos quais o utilizador pode iniciar sessão:

• Any node: permitir o início de sessão a partir de qualquer origem alcançável;
• User group nodes: herdar o valor do grupo;
• Selected nodes: indicar endereços IPv4 individuais previstos;
• Node range: permitir um intervalo IPv4 contínuo.

Neste exemplo, selecione Node range e introduza 10.20.30.10 como endereço inicial e 10.20.30.50 como endereço final. Substitua ambos os valores pelo menor intervalo contíguo a partir do qual o utilizador inicia sessão. Se precisar de endereços IPv4 individuais não contíguos, utilize Selected nodes. Uma seleção demasiado restritiva bloqueia inícios de sessão legítimos; Any node não substitui uma regra de firewall, uma ACL do portal nem a MFA.

Não se ativa MAC binding neste fluxo básico. Suporta autenticação baseada no cliente, mas não Remote Access VPN nem Captive Portal. Se for ativado sem um endereço MAC, o SFOS associa automaticamente o primeiro endereço MAC detetado no primeiro início de sessão. Em dispositivos móveis, após uma mudança de Wi-Fi ou em clientes partilhados, isto pode tornar-se rapidamente uma dependência inesperada.

XML-API: separar os limites de utilizadores e administradores

Para automações, a referência da XML-API para SFOS 22 e 23 distingue as mesmas áreas ao adicionar e atualizar User. Os caminhos seguintes identificam as áreas correspondentes na documentação; não constituem um pedido completo e executável:

• Tipo de conta e permissões: User/UserType permite User ou Administrator; a tabela de parâmetros indica User como valor predefinido e o campo como opcional. User/Profile está aí assinalado com Mandatory: Yes, mas, segundo uma nota explícita, aplica-se apenas a Administrator. Isto não torna o perfil obrigatório para utilizadores normais. Para administradores, continua a ser necessário um perfil Device Access deliberadamente restritivo.
• Origem do início de sessão do utilizador normal: Para User/LoginRestriction, o exemplo apresenta os valores AnyNode, UserGroupNode, SelectedNodes e NodeRange. Com SelectedNodes, os endereços IPv4 são indicados em User/NodeList/IPAddress; com NodeRange, User/FromIP e User/ToIP definem os limites. A indicação Mandatory: Yes na tabela para estes campos está expressamente condicionada à seleção de um intervalo. Não torna estes campos obrigatórios para todos os tipos de restrição.
• Origem do início de sessão do administrador: User/LoginRestrictionForAppliance diz respeito ao início de sessão do administrador no equipamento, não ao início de sessão do utilizador normal. A tabela permite AnyNode, SelectedNodes e NodeRange e indica AnyNode como valor predefinido. Segundo o exemplo, os endereços IPv4 individuais são indicados em User/AdminAccessNodeList/IPAddress e os limites do intervalo em User/AdminAccessFromIP e User/AdminAccessToIP. Os campos do administrador não podem ser trocados pelos campos do utilizador normal; uma indicação Yes na tabela não pode ser interpretada como uma obrigação geral, independentemente do tipo de conta e da restrição selecionada. Um valor predefinido documentado não constitui uma recomendação de acesso irrestrito para administradores.
• Horário de acesso do administrador: User/ScheduleForApplianceAccess seleciona o horário de acesso ao equipamento e, segundo a nota da tabela, aplica-se apenas a administradores. O exemplo apresenta All The Time, mas a coluna de valores predefinidos permanece vazia. Por isso, o valor do exemplo não é um valor predefinido confirmado e este campo não substitui a política de Access Time de um utilizador normal.
• Endereços estáticos de SSL VPN: User/SSLVPNIPv4Address e User/SSLVPNIPv6Address são opcionais. Ambos remetem para o intervalo estático reservado em SSL VPN global settings, não para endereços LAN arbitrários. A ativação explicada abaixo e a seleção de um endereço livre no intervalo IPv4 ou IPv6 correspondente também se aplicam a esta atribuição.

⚠️ O exemplo XML apresenta, para LoginRestrictionForAppliance, o valor truncado AnyNode/. Não constitui uma lista completa de valores nem um modelo para copiar; a tabela indica os três valores enumerados acima. Se a referência da versão utilizada, uma exportação existente e a atribuição planeada divergirem, interrompe-se o processo antes de gravar e esclarecem-se o tipo de conta, o campo e o valor permitido com base na referência adequada ou junto do suporte da Sophos. Não se completa o valor truncado por suposição nem se flexibiliza qualquer restrição de acesso para conseguir que um pedido seja aceite.

Configurar o método de autenticação e o acesso

Um utilizador guardado só pode iniciar sessão num serviço que consulte a base de dados local. Em Authentication > Services, ative o método Local na lista correspondente ao serviço utilizado.

As áreas estão separadas:

• Firewall authentication methods para tráfego de firewall e Captive Portal;
• User portal authentication methods para User Portal;
• VPN portal authentication methods para VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para estes métodos VPN;
• SSL VPN authentication methods para Remote Access SSL VPN.

Quando existem várias fontes, são consultadas pela ordem apresentada. Assim, um teste bem-sucedido em User Portal não prova automaticamente que o mesmo utilizador está configurado corretamente para SSL VPN ou IPsec.

É possível selecionar, no máximo, 20 servidores por método de autenticação. Para User Portal e VPN Portal, a opção de herança é Set authentication methods same as firewall. Para SSL VPN, o SFOS apresenta Same as VPN ou Same as firewall, consoante a referência selecionada. Verifique esta opção e a ordem resultante antes de adicionar ou mover Local.

Configurar o acesso separadamente

A identidade local, por si só, não concede acesso à rede. Captive Portal requer adicionalmente Device Access, Web Authentication e uma regra de utilizador adequada. O fluxo completo é apresentado em Configurar e testar Captive Portal na Sophos Firewall.

User Portal e VPN Portal também são serviços separados. O modelo de portais da Sophos Firewall explica portas, finalidade, Device Access e limites WAN. As políticas de Remote Access são mantidas nos respetivos guias VPN e não são consideradas concluídas apenas porque foi definido um campo no objeto do utilizador.

Interpretar corretamente os campos de Remote Access

Nos métodos de Remote Access diferentes de SSL VPN, os valores de política específicos do utilizador prevalecem sobre o grupo. SSL VPN segue outra lógica: O utilizador recebe os recursos de todas as políticas Full e Split Tunnel que incluam diretamente o utilizador ou um dos seus grupos suportados. Por isso, o campo SSL VPN policy não substitui simplesmente as políticas de grupo.

Dois campos adicionais de grupos só são visíveis em determinadas condições:

• Group SSL VPN policies apresenta as políticas Remote Access SSL VPN dos grupos apenas se o utilizador pertencer a vários grupos AD e pelo menos dois desses grupos estiverem incluídos em políticas Remote Access SSL VPN.
• Group clientless SSL VPN policies apresenta as políticas Clientless SSL VPN dos grupos apenas se o utilizador pertencer a vários grupos AD e pelo menos dois desses grupos estiverem incluídos em políticas Clientless SSL VPN.

Se algum destes campos não aparecer, verifique primeiro ambas as condições para esse tipo específico de VPN. A apresentação do campo não constitui um controlo independente de autorização de acesso; os recursos, bookmarks, a validação e a reversão continuam a ser tratados nos respetivos guias VPN.

SSL VPN IP address só aparece quando os endereços estáticos estão ativados em SSL VPN global settings. O endereço IPv4 ou IPv6 tem de estar livre e pertencer ao intervalo estático criado automaticamente nessa área. Se um servidor RADIUS atribuir endereços, essa atribuição prevalece. IPsec remote access, por sua vez, ativa o acesso com Sophos Connect e pode receber um endereço lease próprio.

L2TP e PPTP são métodos legados. Cada um dos dois campos no objeto do utilizador permite o respetivo tipo de Remote Access e disponibiliza a introdução de um endereço IP a atribuir por lease ao utilizador remoto. Trata-se de uma atribuição de lease específica do utilizador, não de uma configuração completa do túnel nem de um motivo para ativar um novo acesso legado. Após a atribuição, o utilizador tem primeiro de iniciar sessão no VPN Portal e criar uma palavra-passe antes de poder estabelecer a ligação. O enquadramento atual e o percurso de migração do L2TP continuam disponíveis em L2TP Remote Access; o PPTP já não deve ser considerado para novos acessos. Clientless SSL VPN policy abre apenas os bookmarks de navegador atribuídos e não constitui um túnel completo. O procedimento separado encontra-se em Clientless Access.

Para uma regra de firewall baseada em utilizadores, a origem, o destino, o serviço e o utilizador ou grupo são definidos com o menor âmbito possível. Log firewall traffic permanece ativo durante a validação. Os fundamentos são explicados em Compreender e configurar com segurança as regras da Sophos Firewall.

Validar com testes positivos e negativos

Uma conta visível com estado Active ainda não comprova o sucesso. A conta-piloto é testada através do serviço que será realmente utilizado:

1. Iniciar sessão como pilotuser01 numa janela privada do navegador ou a partir de um cliente de teste limpo.
2. Em Current activities > Live users, verificar o nome de utilizador, o IP de origem e o Client Type.
3. Em Log Viewer > Authentication, verificar o início de sessão bem-sucedido, a autenticação local e a hora.
4. Gerar o tráfego pretendido e verificar, no registo da firewall ou da VPN, se Local-Pilot-to-WAN ou o respetivo Firewall Rule ID corresponde à regra esperada.
5. Usar uma origem ou função expressamente não permitida como teste negativo.
6. Se estiver ativa uma quota ou um Access Time, testar separadamente o efeito dentro e fora do limite.
7. Documentar o resultado, o grupo utilizado, as substituições do utilizador e o método de autenticação.

Um teste de início de sessão negativo não deve falhar apenas porque se usou intencionalmente uma palavra-passe incorreta. Também se confirma que uma origem não autorizada, um utilizador sem o grupo adequado ou uma função não prevista não obtêm realmente acesso. Desta forma, separa-se a validação da palavra-passe do efeito das políticas e regras.

Se não for claro se o erro é causado pelo estado do utilizador, pelo método de autenticação, pelo grupo ou pela regra de acesso, Resolver sistematicamente erros de autenticação na Sophos Firewall apresenta a sequência de verificações. Para uma análise detalhada, /log/access_server.log contém eventos de autenticação, autorização e contabilização; o Log Viewer continua a ser o primeiro passo.

Gerir palavras-passe, MFA e utilização

Para alterar como administrador a palavra-passe de uma conta local existente no SFOS 22 e 23, abre-se o utilizador correspondente em Authentication > Users e clica-se em Change password. Antes, verificam-se a conta e o respetivo responsável e prepara-se uma nova palavra-passe longa e exclusiva através do processo aprovado de gestão de palavras-passe. Introduz-se a nova palavra-passe, guarda-se a alteração e transmite-se o segredo de forma segura à pessoa autorizada. Depois, testa-se um novo início de sessão com a nova palavra-passe no serviço efetivamente utilizado. Esta operação no WebAdmin é distinta do autosserviço no User Portal; as contas autenticadas externamente continuam a ser geridas na respetiva fonte de utilizadores. Isto não garante que as sessões existentes sejam terminadas automaticamente.

Um utilizador local pode alterar a própria palavra-passe em User Portal > Personal > Change Password. Isto aplica-se à base de dados local, não a contas AD, LDAP ou RADIUS autenticadas externamente. Em Personal > Personal Details, o utilizador também pode alterar o nome de apresentação. O nome de utilizador e o endereço de e-mail permanecem só de leitura e são mantidos pelo administrador no objeto do utilizador. User Portal só é disponibilizado a partir das zonas necessárias e não é aberto de forma geral à WAN apenas para esta manutenção.

Para proteção adicional, selecione a conta em Authentication > Multi-factor authentication. Com Generate OTP token with next sign-in, o utilizador regista o token através de User Portal ou VPN Portal. MFA para Sophos Firewall explica o algoritmo de hash, o acesso ao portal, a recuperação e a implementação piloto. Ative a MFA apenas depois de testar o início de sessão normal e o processo de recuperação.

Em Authentication > Users > > View usage é possível ver as quotas atribuídas, o tempo de Surfing e o consumo de dados. Para isso, o tráfego tem de corresponder a uma regra de firewall baseada em utilizadores com Log firewall traffic. Reset user accounting repõe a zero os contadores de Surfing e Network Traffic e, por isso, não é utilizado como correção geral para problemas de início de sessão.

Reverter a alteração e remover a conta

Antes da fase piloto, documente a ordem existente em Authentication > Services e todas as definições de grupos, portais, regras e VPN que alterar. Isto garante que a reversão não depende de valores predefinidos presumidos. Quando uma pessoa sair, um piloto falhar ou a conta deixar de ser necessária, proceda pela ordem inversa:

1. Verificar dependências em regras, grupos, políticas Remote Access, quotas, MFA e documentação.
2. Em Authentication > Users, selecionar o utilizador e definir Change status como Inactive.
3. Efetuar um novo início de sessão como teste negativo.
4. Em Current activities > Live users, verificar as sessões existentes e usar Disconnect para um utilizador normal quando necessário.
5. Remover o utilizador das regras de firewall e das políticas de Remote Access ou repor a seleção anterior documentada.
6. Repor as definições alteradas de grupos, portais e serviços de autenticação exatamente no estado anterior registado.
7. Verificar nos registos da firewall, da VPN e da configuração se existem novas tentativas, tráfego residual e as alterações efetuadas.
8. Eliminar a conta apenas depois de resolver todas as dependências ou mantê-la inativa de acordo com o processo de retenção.

XML-API: verificar separadamente a conta a eliminar e o resultado. A referência da operação Delete para SFOS 22 e 23 exige o Username exato guardado. O fragmento descritivo <Name><username></Name> refere-se a esse nome de utilizador, não ao nome de apresentação Name do formulário de adição nem a um identificador interno presumido. Não constitui um pedido completo e executável. O procedimento acima diz respeito a utilizadores normais; os administradores e a conta com sessão atualmente iniciada devem ser tratados separadamente. Antes de qualquer eliminação, mantém-se um acesso de administração independente e funcional.

As linhas de estado desta operação associam 200 a Message.UserDeleteSuccess, 204 a Message.UserAdminOrCurrentUserNotDeleted, 205 a Message.AuthorizerExists, 206 a Message.UserForeignKeyExists, 210 a Message.UserIMRuleExists e 500 a Message.UserDeleteFailed. Estes são identificadores literais no código-fonte, não textos de mensagens aqui confirmados nem resultados testados. Em particular, os identificadores de não eliminação e de dependências associados a 204, 205, 206 e 210 não representam um sucesso de eliminação genérico; esta tabela de operações não constitui uma classificação de estados HTTP. Dos identificadores não se deduz uma eliminação automática em cascata nem passos de limpeza de Authorizer, chaves estrangeiras ou regras IM; o identificador IM não confirma uma funcionalidade atualmente suportada na interface gráfica.

Se o resultado for incerto ou uma operação de escrita for interrompida, verifica-se em Authentication > Users, antes de uma nova tentativa, o nome de utilizador exato guardado e o respetivo estado atual. Para uma eliminação autorizada e suportada, utiliza-se a interface suportada ou esclarece-se com o suporte da Sophos, antes de efetuar operações de escrita incertas através da API, o contrato de pedido e de resultado da compilação instalada. Depois, confirma-se que apenas a conta prevista deixou de existir e que as outras contas necessárias e o acesso de administração continuam a funcionar sem alterações. As dependências e a retenção têm de ser esclarecidas previamente; a desativação e o encerramento das sessões não substituem esta comprovação da eliminação.

A ajuda do SFOS não confirma que a desativação termine todas as ligações existentes. Verifique e encerre separadamente as sessões e os túneis. Após uma reativação, repita os testes positivos e negativos.

Antes de uma eliminação arriscada, pode exportar o objeto de configuração User com Include dependent entity em Backup and firmware > Import export. Esta exportação contém dados sensíveis, incluindo palavras-passe, e deve ser cifrada e guardada num local com acesso controlado. A Secure Storage Master Key correta também tem de estar disponível para uma importação posterior. Uma importação atualiza a configuração existente e aplica os valores importados quando existem objetos sobrepostos. Por isso, as dependências partilhadas incluídas na exportação também podem ser substituídas. Reveja o conteúdo e o impacto antes da importação, de preferência num ambiente de teste adequado.

Um backup completo não permite reverter rapidamente apenas um utilizador: uma restauração substitui toda a configuração, reinicia a firewall e elimina alterações posteriores. O processo é explicado em Backup e restauração na Sophos Firewall.

Num cluster HA, efetue a alteração no equipamento primário e verifique depois o estado da sincronização. Os registos e relatórios não são sincronizados entre os nós e têm de ser analisados separadamente durante o diagnóstico.

Utilizadores e grupos partilham identificadores internos. Um grande número de objetos, por si só, não prova um problema. Contudo, se um utilizador apresentar uma User ID superior a 65535 e não for autenticado, utiliza-se o fluxo separado relativo ao limite de User ID da Sophos Firewall, em vez de alterar palavras-passe ou regras por tentativa.

Delimitar erros por sintoma

O nome de utilizador e a palavra-passe são rejeitados

Em Authentication > Users, verificar se a conta é local, está ativa e existe com o nome de utilizador esperado. Depois, em Authentication > Services, confirmar se Local está selecionado para o serviço específico. Um início de sessão bem-sucedido noutro portal não comprova que Local esteja selecionado para este serviço.

O início de sessão funciona, mas a regra de utilizador não corresponde

Em Current activities > Live users, verificar a identidade, o IP de origem e o Client Type. Depois, controlar no Log Viewer a posição da regra, Source Zone, o utilizador ou grupo e Firewall Rule ID. Uma regra de rede acima da regra de utilizador pode já corresponder ao tráfego.

Uma alteração do grupo não tem efeito

Procurar no utilizador valores específicos para quota, Access Time, Traffic Shaping ou Remote Access. Estas substituições têm prioridade sobre o grupo. Reponha a herança do grupo apenas depois de comparar o valor com a exceção documentada.

O utilizador pode iniciar sessão a partir de uma origem inesperada

Verificar Sign-in restriction no utilizador e no grupo. Confirmar também o serviço efetivamente utilizado, Device Access e a regra de rede. Uma definição Any node não é automaticamente compensada por MFA nem por uma regra de firewall restritiva.

View usage permanece vazio

Verificar se o utilizador é reconhecido como Live User e se o tráfego corresponde a uma regra baseada em utilizadores com Log firewall traffic. Depois, controlar o período, a atribuição de quota e o tráfego real de teste. Reset user accounting não gera logs em falta nem corrige uma regra errada.

Lista de verificação operacional

• Live users apresenta pilotuser01, o IP de origem esperado e o Client Type previsto.
• O registo de autenticação confirma o início de sessão local; Local-Pilot-to-WAN ou o respetivo Firewall Rule ID corresponde ao tráfego de teste.
• Uma palavra-passe incorreta, uma origem não permitida e uma função não autorizada produzem os resultados negativos esperados.
• As substituições ao nível do utilizador, Simultaneous sign-ins, Sign-in restriction e qualquer data de expiração estão documentadas.
• O registo da MFA e o processo de recuperação foram testados, caso seja utilizada MFA.
• O estado anterior, a responsabilidade, a desativação, o encerramento das sessões e a eliminação posterior estão documentados.

Perguntas frequentes