Gerir corretamente grupos de utilizadores e o grupo principal na Sophos Firewall

Os grupos de utilizadores na Sophos Firewall agregam políticas comuns para utilizadores autenticados. Permitem uniformizar Access Time, quotas, Traffic Shaping, Remote Access e Sign-in Restrictions. No entanto, um grupo não concede acesso automaticamente: também contam a identidade reconhecida, o grupo principal efetivo, a política concreta de firewall ou VPN e a respetiva ordem.

O procedimento rápido e seguro é o seguinte:

1. Definir a origem dos utilizadores e a tarefa que o grupo deve resolver.
2. Utilizar um grupo do tipo Normal para utilizadores normais; planear separadamente como Clientless as identidades de dispositivos baseadas em IP.
3. Criar ou importar um pequeno grupo piloto com uma função clara e o menor número possível de políticas comuns.
4. Em Authentication > Services, verificar o Default Group pretendido ou o grupo de contingência no servidor Entra.
5. Para Active Directory, documentar a ordem em Authentication > Groups > Reorder e definir o grupo principal esperado.
6. Evitar substituições por utilizador ou documentá-las explicitamente, porque prevalecem sobre as políticas do grupo.
7. Gerar um novo início de sessão e verificar Group e Other group memberships em Authentication > Users.
8. Testar a função afetada com um utilizador positivo e outro negativo; no caso de tráfego, verificar também a Firewall Rule ID esperada.
9. Só depois de um piloto bem-sucedido adicionar mais utilizadores e rever regularmente a ordem dos grupos, o Default Group e as exceções.

⚠️ Reorder não é uma função de ordenação inofensiva. Para utilizadores AD, mover um grupo pode alterar o grupo principal e, consequentemente, MFA, quotas, Access Time, Remote Access e outras políticas para muitos utilizadores. Documentar primeiro a ordem existente, as políticas de grupo, os utilizadores piloto e o caminho de recuperação.

Compreender o modelo de grupos em poucos minutos

Na firewall, um grupo é um suporte comum de políticas. Pode atribuir as mesmas definições a vários utilizadores, evitando a manutenção individual de cada conta. Não substitui a autenticação nem uma regra de firewall. Um utilizador pode aparecer no grupo correto e continuar sem acesso se faltar a regra, a política VPN, a zona, a rota ou o caminho de retorno esperado.

Quatro perguntas separadas ajudam na operação:

1. Qual é a origem da identidade? Local, Active Directory, LDAP, RADIUS, Microsoft Entra ID ou um mapeamento Clientless baseado em IP.
2. Que grupo é efetivo? No AD, pode ser o grupo principal ou, em funções compatíveis, outra associação a um grupo.
3. Que política de grupo se aplica? Access Time, Quota, Remote Access e outros campos seguem regras de avaliação diferentes.
4. Que regra permite o tráfego? As políticas de grupo, por si só, não abrem um caminho de rede.

Não misturar grupos Normal, importados e Clientless

Um grupo local do tipo Normal é adequado para utilizadores que se autenticam através de um serviço compatível. Um utilizador local recebe o seu grupo no objeto de utilizador. Com uma origem de utilizadores externa, os registos locais são geralmente criados apenas depois do primeiro início de sessão bem-sucedido.

As contas temporárias de convidados são geradas através de Guest user settings e herdam um grupo restritivo escolhido de forma consciente. Criar e gerir utilizadores convidados em segurança na Sophos Firewall aborda criação, validade, validação no Captive Portal e offboarding.

Os grupos AD são obtidos através do assistente de importação. As associações são mantidas no diretório e avaliadas no início de sessão. O processo completo de servidor, LDAPS e importação encontra-se em Ligar o Active Directory à Sophos Firewall. Para LDAP genérico, a base de pesquisa, memberOf ou outro atributo de grupo e o Default Group local devem ser planeados separadamente; Ligar um servidor LDAP à Sophos Firewall explica estes campos.

Um grupo do tipo Clientless resolve outra tarefa. Associa uma identidade a um endereço IP fixo sem que uma pessoa inicie sessão. Destina-se a impressoras ou outros sistemas claramente atribuíveis e não substitui a autenticação de utilizadores. Configurar Clientless Users na Sophos Firewall descreve o teste seguro de IP, regra e resultado negativo.

Escolher deliberadamente o Default Group e o grupo de contingência

Em Authentication > Services > Firewall authentication methods, Default group determina que grupo um utilizador externo recebe quando não existe um grupo local correspondente. Um Default Group amplo ou historicamente acumulado pode assim atribuir políticas inesperadas. É mais seguro utilizar um grupo de contingência deliberadamente restritivo, cujo efeito tenha sido testado positiva e negativamente.

O Microsoft Entra ID SSO utiliza o seu próprio Fallback user group na configuração do servidor Entra. Esta definição também se aplica quando o servidor é utilizado em Firewall authentication methods. Por isso, o Default Group geral e o grupo de contingência do Entra não devem ser considerados a mesma definição.

Planear o exemplo e os pré-requisitos

O exemplo seguinte separa três finalidades:

• Local_Contractors: grupo piloto local para poucos colaboradores externos;
• SFOS_Internet_Standard: grupo AD importado para acesso normal à Internet;
• SFOS_SSLVPN: grupo AD importado para uma política SSL VPN;
• auth-pilot@example.com: conta de teste criada deliberadamente;
• LAN-Users-to-WAN: regra de firewall com registo para o teste de Internet.

example.com é um domínio reservado para documentação. Os nomes dos grupos, o utilizador e o nome da regra devem ser substituídos pela convenção de nomenclatura do ambiente. Um bom nome de grupo descreve a função e não apenas um departamento. Por exemplo, SFOS_SSLVPN continua compreensível se a estrutura da organização mudar mais tarde.

Antes da primeira alteração, registar:

• a ordem atual em Authentication > Groups;
• o Default Group e, para Entra ID, o grupo de contingência;
• as políticas de grupo e as substituições específicas dos utilizadores;
• os serviços de autenticação e as políticas Remote Access afetados;
• um acesso de administrador testado e um caminho de gestão independente;
• um utilizador piloto com o efeito positivo e negativo esperado.

Criar um grupo de utilizadores local

Em Authentication > Groups > Add, criar a base comum:

1. Em Name, introduzir Local_Contractors.
2. Em Group type, selecionar Normal.
3. Definir Surfing quota, Access time, Network traffic e Traffic shaping apenas se o grupo realmente precisar destas funções em comum.
4. Ativar campos Remote Access, como SSL VPN policy ou IPsec remote access, apenas para o acesso planeado.
5. Limitar Sign-in restriction aos endereços de origem realmente necessários ou ao intervalo previsto, se o modelo de autenticação o permitir.
6. Ativar Quarantine digest e MAC binding apenas de forma deliberada.
7. Guardar com Save.

Os nomes dos campos são definidos pelo produto. As políticas selecionadas dependem do ambiente. Um grupo normal de Internet não precisa automaticamente de VPN, Quota ou MAC Binding. Quanto menos tarefas um grupo combinar, mais fácil será compreender o seu efeito e a reversão.

Atribuir utilizadores sem criar substituições ocultas

Criar e gerir utilizadores locais normais explica integralmente o nome de utilizador, a palavra-passe, a herança do grupo, o método de autenticação e a validação. Podem ser atribuídos a um grupo em Authentication > Users. Na edição do grupo, Show group members apresenta os membros e Add member(s) permite adicionar utilizadores locais adequados. Para identidades geridas externamente, o diretório continua a ser a origem da associação. Uma atribuição local manual não substitui uma configuração correta de AD, LDAP ou Entra.

As políticas específicas do utilizador têm prioridade sobre as políticas do grupo. Uma substituição pode ser útil para uma exceção documentada ou um piloto, mas pode fazer com que uma alteração posterior do grupo pareça ineficaz. Por isso, para cada utilizador divergente, registar o campo substituído, o motivo da exceção e a forma de regressar ao valor do grupo.

A criação e validação completas das políticas Access Time, das quotas Surfing e Network Traffic e do MFA para Sophos Firewall permanecem nos respetivos artigos especializados. No objeto de grupo, apenas se atribui a política já planeada.

Operar grupos AD importados de forma controlada

Os grupos AD são importados para a firewall em Authentication > Servers > Import. Num cluster HA, a importação é efetuada no dispositivo Primary. O assistente importa apenas os grupos selecionados. Um grupo criado posteriormente no AD não aparece, portanto, automaticamente na firewall e tem de ser novamente importado ou deliberadamente criado de forma correspondente.

Os grupos AD aninhados não são avaliados. Se um subgrupo for utilizado numa regra de firewall, política VPN ou outra função, esse subgrupo específico tem de ser importado. O grupo AD primário de um utilizador também não é importado como associação normal. Por isso, grupos de segurança explícitos são mais adequados para políticas do que o grupo AD predefinido Domain Users.

Após alterar associações AD, grupos importados ou a ordem dos grupos, gerar um novo início de sessão. Só então a firewall volta a avaliar os grupos e atualiza o objeto de utilizador.

Compreender o grupo principal e a ordem dos grupos

Para um utilizador AD, Authentication > Users apresenta dois níveis diferentes:

• Group: o primeiro grupo correspondente na lista da firewall e, portanto, o grupo principal;
• Other group memberships: os outros grupos importados do utilizador.

Alterar a ordem em Authentication > Groups > Reorder. Se auth-pilot@example.com pertencer a SFOS_Internet_Standard e SFOS_SSLVPN, o grupo correspondente colocado mais acima na lista torna-se o grupo principal no próximo início de sessão.

Esta ordem não deve ser alterada espontaneamente para um caso isolado. Primeiro, verificar qual é a função concreta afetada e se suporta outros grupos. Caso contrário, uma deslocação pode corrigir um caso de VPN e alterar simultaneamente MFA, Quota ou Access Time para outros utilizadores.

Vários grupos são avaliados de forma diferente por função

O limite seguinte aplica-se expressamente às associações a grupos do Active Directory. Não deve ser transferido sem verificação para LDAP, RADIUS ou Microsoft Entra ID.

Podem ser considerados vários grupos AD em:

• Firewall rules e SSL/TLS inspection rules;
• SD-WAN routes;
• Web policies;
• IPS e Application control policies;
• Policy test;
• Remote access SSL VPN;
• Clientless SSL VPN.

Em Remote access SSL VPN, as permissões das políticas de utilizador e grupo correspondentes são combinadas. Assim que estiver envolvida uma política Full Tunnel correspondente, o resultado será um Full Tunnel. Por isso, esta combinação deve ser validada com um teste real do cliente e não apenas através da comparação dos nomes dos grupos.

Só o grupo principal ou uma atribuição explícita do utilizador é considerado em:

• WAF rules, My policy overrides e Hotspots;
• Remote access IPsec VPN, L2TP e PPTP;
• Surfing quota, Access time, Network traffic e Traffic shaping;
• Quarantine digest, MAC binding e Sign-in restriction;
• MFA.

Nas funções que suportam vários grupos, a ordem da regra ou política correspondente continua a ser determinante. Por exemplo, uma regra de firewall pode corresponder através de SFOS_SSLVPN, mesmo que SFOS_Internet_Standard seja o grupo principal. Isso não significa que MFA ou Quota também utilizem SFOS_SSLVPN.

Testar o efeito do grupo com um utilizador real

Um grupo guardado e um utilizador visível ainda não comprovam o sucesso. Para o piloto, utilizar o mesmo procedimento que será aplicado posteriormente em produção:

1. Terminar a sessão existente do utilizador piloto e gerar um novo início de sessão.
2. Em Authentication > Users, documentar o estado, Group, Other group memberships e possíveis substituições do utilizador.
3. Em Current activities > Live users, verificar o nome de utilizador, o IP de origem e Client Type.
4. Para uma regra de firewall baseada no utilizador, gerar o fluxo esperado e verificar a Firewall Rule ID no Log Viewer.
5. Para Access Time, Quota, MFA ou Remote Access, testar separadamente o serviço afetado.
6. Executar o mesmo fluxo como teste negativo com um utilizador que não pertença ao grupo piloto.
7. Registar o resultado, a hora, a ordem dos grupos e a política efetiva.

Testar regras de firewall com Log Viewer, Policy Test e Packet Capture mostra o teste de tráfego completo. Se já não for claro se falha a seleção do serviço, a identidade, o grupo principal ou a regra posterior, Resolver sistematicamente erros de autenticação da Sophos Firewall conduz por toda a cadeia de verificação.

Alterações, reversão e operação

As alterações a grupos devem ser tratadas como alterações a políticas:

1. Documentar o estado inicial e os utilizadores afetados.
2. Alterar apenas um grupo, uma política ou uma posição de cada vez.
3. Autenticar novamente o utilizador piloto.
4. Verificar de novo o grupo principal, as outras associações e a função concreta.
5. Em caso de efeito inesperado, restaurar a ordem dos grupos e a atribuição da política anteriores.
6. Gerar outro novo início de sessão e repetir os testes positivo e negativo.

Um grupo AD é primeiro removido no diretório e depois na firewall. Um utilizador que ainda exista no AD pode voltar a ser criado localmente num início de sessão posterior. Por isso, Purge AD users não é um botão de sincronização nem um passo normal após uma alteração de grupo.

Os utilizadores e grupos partilham o intervalo interno de ID até 65535. Um número elevado de objetos visíveis, por si só, não comprova um problema de limite. Se um utilizador apresentar uma User ID superior a 65535 e não se tornar Live User, deve seguir-se o procedimento separado relativo ao limite de ID de utilizador da Sophos Firewall.

Delimitar erros por sintoma

O novo grupo AD não aparece na firewall

Os novos grupos não são sincronizados automaticamente. Executar novamente o assistente de importação e, em HA, fazê-lo no Primary. Depois, verificar em Authentication > Groups se está presente exatamente o grupo necessário. Não criar um grupo de substituição amplo apenas para fazer funcionar um início de sessão.

O utilizador tem o grupo principal errado

Documentar primeiro as associações AD, os grupos importados e a ordem atual. Em seguida, verificar se o grupo esperado existe realmente na firewall. Uma alteração planeada em Reorder só deve ser avaliada depois de um novo início de sessão e tem de ser testada com vários utilizadores representativos.

A regra de firewall corresponde, mas MFA ou Quota não se aplica

As regras de firewall suportam outros grupos AD, enquanto MFA e quotas não. No objeto de utilizador, verificar qual é o grupo apresentado em Group como grupo principal. Em seguida, controlar as substituições específicas do utilizador e a atribuição real da política. A correspondência da regra não comprova que MFA ou Quota avaliem os grupos da mesma forma.

A alteração do grupo só funciona incorretamente para um utilizador

Comparar os campos de política específicos do utilizador em Authentication > Users. Uma substituição individual tem prioridade sobre a política de grupo. O valor não deve ser alterado sem análise; primeiro deve ser comparado com a exceção documentada e o estado de herança pretendido.

O utilizador fica no Default Group

No AD ou noutro servidor de autenticação clássico, provavelmente falta um grupo local ou mapeamento de grupo correspondente. Verificar a importação, o nome do grupo, a base de pesquisa e os atributos devolvidos. Para Microsoft Entra ID SSO, verificar em alternativa o Fallback user group do servidor Entra. O Default Group não deve ser alargado indiscriminadamente para ocultar o verdadeiro erro de mapeamento.

O grupo AD aninhado não se aplica

Importar o próprio subgrupo necessário e adicionar diretamente o utilizador. Depois, gerar um novo início de sessão e verificar Group e Other group memberships. Importar apenas o grupo superior não é suficiente.

Lista de verificação operacional

• A finalidade do grupo e a origem de utilizadores responsável estão documentadas.
• Os grupos locais, importados e Clientless não são misturados.
• O Default Group ou grupo de contingência Entra foi escolhido deliberadamente e de forma restritiva.
• A ordem dos grupos e os grupos principais esperados estão documentados.
• As substituições dos utilizadores estão justificadas ou removidas.
• A função concreta suporta a associação ao grupo utilizada.
• O utilizador piloto foi novamente autenticado e verificado em Authentication > Users.
• Os testes positivo e negativo confirmam a política ou Firewall Rule ID esperada.
• Remote Access, MFA, Access Time e quotas foram validados separadamente quando utilizados.
• O caminho de reversão da ordem dos grupos e da atribuição de políticas está documentado.

Perguntas frequentes