Configurar Access Time para utilizadores na Sophos Firewall

Uma política Access Time limita o acesso à internet de um utilizador, grupo ou utilizadores convidados a horários definidos. A política combina um Schedule recorrente com Allow ou Deny. No entanto, só se aplica a uma identidade que a firewall tenha realmente reconhecido e à qual a política esteja atribuída diretamente ou através do seu grupo principal.

O procedimento rápido para permitir o acesso à internet durante o horário de expediente é o seguinte:

1. Em Administration > Time, verificar a hora e o fuso horário da firewall.
2. Em Profiles > Schedule, criar um Schedule recorrente, por exemplo Internet_OfficeHours.
3. Em Profiles > Access time > Add, criar a política Employees_OfficeHours_Allow com Action: Allow.
4. Em Authentication > Groups, atribuir a política a um pequeno grupo piloto.
5. Em Current activities > Live users, verificar o utilizador e o endereço de origem e, em Authentication > Users, o grupo principal esperado.
6. Testar uma nova ligação à internet dentro e fora da janela de tempo.
7. Adicionar mais utilizadores apenas depois de os testes positivo e negativo terem êxito.

⚠️ Segundo a Sophos, as alterações a uma política Access Time entram em vigor imediatamente. Por isso, uma política partilhada não deve ser alterada de forma improvisada. Primeiro, devem ser inventariados os utilizadores e grupos afetados, documentados uma conta piloto e o estado anterior e, em seguida, testados os limites de tempo de forma controlada.

O que o Access Time realmente controla

O Access Time decide se um utilizador autenticado obtém acesso à internet num determinado momento. A política não cria uma regra de firewall nem uma Web Policy e não autentica nenhum utilizador. Por isso, o caminho de rede, a identificação do utilizador, a correspondência da regra e as funções de proteção já têm de funcionar.

São necessários quatro elementos para a avaliação:

• um Schedule recorrente com dias e horas;
• uma política Access Time com Allow ou Deny;
• uma atribuição a um utilizador, grupo ou utilizador convidado;
• uma identidade reconhecida, por exemplo através do Captive Portal, STAS, SATC ou outro método de autenticação adequado.

Escolher deliberadamente Allow ou Deny

• Allow: o acesso à internet é permitido durante o Schedule selecionado e bloqueado fora dessa janela. Este modelo é adequado para colaboradores, salas de formação ou contas de prestadores com horários de utilização claramente definidos.
• Deny: o acesso à internet é bloqueado durante o Schedule e permitido fora dele. Este modelo é adequado para um período de bloqueio específico, por exemplo uma aula recorrente ou um período de descanso.

Para um novo acesso restrito, Allow é geralmente mais fácil de compreender: a janela permitida fica diretamente visível no objeto e pode ser testada de forma positiva e negativa com um pequeno grupo piloto. Deny faz sentido quando o estado normal deve permanecer expressamente aberto e só é necessária uma janela de bloqueio definida com precisão.

Schedule, quota e hora de início de sessão são níveis diferentes

Funções com nomes semelhantes resolvem tarefas diferentes:

• Um Schedule contém apenas dias e horas. Só produz efeito através de uma regra de firewall, uma política ou uma política Access Time. Schedules da Sophos Firewall para regras e políticas explica a configuração completa.
• Surfing quota limita o tempo de internet que um utilizador pode consumir. É uma quota de utilização, não uma janela horária fixa.
• Network traffic quota limita a quantidade de dados transferidos.
• A validade de uma conta de convidado determina durante quanto tempo as credenciais existem. Não substitui um Access Time recorrente.
• Os Clientless Users não suportam uma política Access Time. Se um dispositivo fixo só deve comunicar a determinadas horas, o Schedule é aplicado a uma regra de firewall com âmbito restrito. Configurar Clientless Users na Sophos Firewall explica a identidade baseada em IP.
• Schedule for device access nas definições de administrador limita os inícios de sessão no WebAdmin. O Access time normal não se destina a esse fim.

Surfing Quota e Network Traffic Quota na Sophos Firewall explica como criar e atribuir os dois créditos de consumo, verificá-los em View usage e repô-los em segurança.

Vários níveis de tempo só devem ser combinados com uma intenção documentada. O Schedule de uma regra de firewall pode fechar todo o caminho de rede, enquanto o Access Time afeta apenas os utilizadores atribuídos. Se os dois níveis utilizarem janelas diferentes, cada limite deve ser testado separadamente.

Planear o exemplo e os requisitos

O exemplo seguinte permite a um grupo de colaboradores aceder à internet de segunda a sexta-feira entre as 07:30 e as 18:00:

• Schedule: Internet_OfficeHours
• Política Access Time: Employees_OfficeHours_Allow
• Action: Allow
• Grupo: Internet_OfficeHours
• Utilizador de teste: access-time-pilot
• Fuso horário: Europe/Zurich
• Janela de tempo: segunda a sexta-feira, das 07:30 às 18:00

Os nomes e as horas são valores de exemplo. No ambiente real, o nome do grupo, o responsável, o fuso horário e o horário de funcionamento autorizado são obtidos a partir do requisito de acesso efetivo. Um grupo só deve conter utilizadores com o mesmo modelo de tempo.

Antes da alteração, devem ser verificados estes requisitos:

1. Em Administration > Time, Current time e Time zone estão corretos. Configurar a hora do sistema e NTP na Sophos Firewall explica a configuração de NTP.
2. O utilizador piloto consegue autenticar-se com o método previsto.
3. Em Current activities > Live users, aparecem o nome de utilizador e o endereço de origem; em Authentication > Users, o campo Group está correto.
4. Uma regra de utilizador ou de rede adequada permite o caminho previsto para a internet e regista o tráfego de teste.
5. A atribuição Access Time anterior, o grupo principal e eventuais exceções de utilizador estão documentados.

Se o utilizador não for reconhecido como Live User, deve corrigir-se primeiro a autenticação. Uma política Access Time não consegue controlar de forma fiável uma identidade desconhecida por utilizador ou grupo.

Criar o Schedule e a política Access Time

Preparar um Schedule recorrente

As políticas Access Time aceitam exclusivamente Schedules recorrentes. Um Schedule One-time não está disponível aqui.

Para o exemplo:

1. Abrir Profiles > Schedule > Add.
2. Definir Name como Internet_OfficeHours.
3. Definir Recurrence type como Recurring.
4. Selecionar segunda a sexta-feira.
5. Definir Start time como 07:30 e Stop time como 18:00.
6. Documentar em Description o objetivo, o fuso horário e o responsável.
7. Guardar com Save.

O Schedule, por si só, ainda não altera nenhum acesso. É um objeto de tempo reutilizável que também pode ser utilizado noutros locais. Por isso, devem verificar-se sempre todas as utilizações antes de uma alteração posterior.

Criar a política Access Time

Em seguida, associa-se o objeto de tempo à ação de acesso:

1. Abrir Profiles > Access time.
2. Selecionar Add.
3. Definir Name como Employees_OfficeHours_Allow.
4. Em Description, introduzir, por exemplo, Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT.
5. Definir Action como Allow.
6. Em Schedule, selecionar Internet_OfficeHours.
7. Guardar com Save.

Esta política também não produz efeito enquanto não for atribuída a um utilizador, grupo ou utilizador convidado.

Atribuir a política a um grupo ou utilizador

Utilizar um grupo como modelo operacional normal

Para utilizadores com o mesmo modelo de tempo, um grupo é mais claro do que muitas atribuições individuais:

1. Abrir Authentication > Groups.
2. Criar o grupo piloto Internet_OfficeHours ou editar um grupo existente com um âmbito adequado.
3. Na secção de políticas, selecionar Employees_OfficeHours_Allow em Access time.
4. Não alterar inadvertidamente outras definições de quota, Traffic Shaping ou Remote Access.
5. Guardar as alterações.
6. Autenticar um único utilizador de teste deste grupo e verificar o grupo principal real.

Gerir grupos de utilizadores da Sophos Firewall em segurança explica como interagem grupos locais e importados, o grupo principal e as substituições dos utilizadores. A importação AD propriamente dita continua descrita em Ligar o Active Directory à Sophos Firewall.

Utilizar uma exceção de utilizador apenas de forma consciente

Em Authentication > Users, pode selecionar-se um Access time próprio para um utilizador individual. Este valor do utilizador tem prioridade sobre a política do grupo.

Uma exceção é útil para um caso documentado, mas pode fazer com que as alterações do grupo pareçam não ter efeito. Se um grupo estiver configurado corretamente mas um utilizador se comportar de forma diferente, deve verificar-se primeiro o respetivo objeto de utilizador. Para voltar à política do grupo, não se deve selecionar uma nova política individual qualquer; o estado de herança anterior deve ser restaurado de forma controlada.

No Active Directory, só conta o grupo principal

Para utilizadores de AD, o Access Time não avalia Other group memberships. Aplica-se o grupo principal apresentado em Group no objeto de utilizador, a menos que tenha sido explicitamente selecionada uma política para o utilizador.

A ordem em Authentication > Groups > Reorder influencia qual dos grupos importados se torna o grupo principal. Alterar essa ordem pode, por isso, afetar não só o Access Time, mas também outras funções. Não deve ser usada como correção rápida para um único utilizador. É preferível uma ordem de grupos planeada deliberadamente ou uma exceção de utilizador documentada.

As alterações aos grupos de AD, à ordem dos grupos e às políticas associadas são aplicadas no início de sessão seguinte do utilizador. Para um teste limpo, deve criar-se uma nova sessão de autenticação e voltar a verificar o grupo principal.

Controlar os utilizadores convidados através do seu grupo

Os utilizadores convidados na Sophos Firewall recebem um grupo em Authentication > Guest user settings e herdam as respetivas políticas. Para aplicar aos convidados uma janela recorrente de acesso à internet, atribui-se a política Access Time a este grupo de convidados claramente delimitado.

O Validity period da conta de convidado continua a ser um limite adicional: determina durante quanto tempo a conta é válida. O Access Time determina, dentro dessa validade, as horas recorrentes permitidas ou bloqueadas. Configurar e testar o Captive Portal na Sophos Firewall explica o início de sessão do convidado e a regra de firewall.

Testar os limites de tempo de forma fiável

Uma política guardada ainda não é uma prova de sucesso. O teste de aceitação verifica em conjunto a identidade, a política e o acesso real à internet:

1. Documentar a hora da firewall, o fuso horário, o Schedule e a Action.
2. Voltar a autenticar o utilizador piloto.
3. Em Current activities > Live users, verificar o nome de utilizador e o endereço de origem; em Authentication > Users, verificar o grupo principal.
4. Dentro da janela Allow, abrir uma nova ligação HTTP ou HTTPS para um destino de teste permitido.
5. No Log Viewer, verificar o utilizador, o grupo, a origem, o destino, a Firewall Rule ID, a ação e o carimbo de data/hora.
6. Fora da janela, testar uma nova ligação ao mesmo destino e confirmar o bloqueio esperado.
7. Para uma política Deny, executar o mesmo teste com a expectativa inversa.
8. Só depois atribuir outros utilizadores ou o grupo de produção.

A regra de firewall deve continuar a corresponder ao utilizador, à rede e ao destino. Testar corretamente uma regra da Sophos Firewall explica como avaliar em conjunto a Rule ID, o Log Viewer e o Packet Capture.

A Sophos documenta que as alterações às políticas Access Time entram em vigor imediatamente. No entanto, isso não representa uma garantia geral de que todas as sessões de aplicações existentes sejam terminadas exatamente no limite de tempo. Para requisitos críticos de segurança, devem observar-se separadamente uma nova ligação e uma sessão já em curso.

Delimitar os erros de forma sistemática

O utilizador não tem acesso à internet apesar da política

Primeiro, verificar se a hora atual está dentro do Schedule para Allow ou fora dele para Deny. Depois, verificar a identidade do utilizador e o endereço de origem em Current activities > Live users e o grupo principal em Authentication > Users. Se o utilizador não aparecer em Live users, o passo seguinte é a autenticação, não uma política Access Time mais ampla.

Em seguida, verificar a regra de firewall, a correspondência do utilizador, a posição da regra e o Log Viewer. O Access Time não consegue reparar um caminho de rede em falta nem uma política Web, Application ou TLS que esteja a bloquear.

O acesso funciona fora da janela Allow

Verificar se está realmente a ser testado o utilizador esperado e se existe outro Access Time definido no objeto de utilizador. Para AD, verificar também o grupo principal e a ordem dos grupos. Um teste não autenticado ou atribuído incorretamente não prova que a política falhou.

Em seguida, gerar um novo fluxo de teste. Uma sessão existente pode comportar-se de forma diferente de uma nova ligação. Se o tráfego aparecer no Log Viewer sem o utilizador esperado, deve resolver-se primeiro a identificação do utilizador.

Uma alteração de grupo não afeta um utilizador

Uma política explícita do utilizador tem prioridade sobre a política do grupo. Em Authentication > Users, verificar o campo Access time e, para AD, o grupo principal. O Access Time não avalia Other group memberships.

Depois de alterar grupos de AD, voltar a autenticar o utilizador. Só então é possível avaliar a ordem atual dos grupos e a atribuição da política.

O Captive Portal aparece inesperadamente

A Sophos indica um Access Time restrito, credenciais incorretas e quotas esgotadas como possíveis causas de problemas de NTLM ou Captive Portal. Verificar separadamente o Access Time, a Surfing quota, a Network traffic quota e as credenciais. Não se deve mudar precipitadamente a política para Allow nem alargar o Schedule enquanto a causa real não estiver esclarecida.

Uma alteração afeta mais utilizadores do que o esperado

Uma política Access Time partilhada afeta imediatamente todas as suas atribuições após uma alteração. Primeiro, restaurar a Action e o Schedule anteriormente documentados. Em seguida, inventariar os grupos e as exceções de utilizador afetados e testar o novo requisito com uma política piloto separada.

Planear alterações e rollback

Antes de cada alteração em produção, documentar o nome da política, a Action, o Schedule, os grupos afetados, as exceções de utilizador, os grupos principais, a hora da firewall e o resultado do teste. Assim, o caminho de rollback permanece inequívoco.

Um rollback controlado consiste em:

1. Restaurar a atribuição Access Time anterior para o utilizador ou grupo piloto.
2. Para AD, voltar a autenticar o utilizador de teste.
3. Em Current activities > Live users, verificar o utilizador e o endereço de origem e, em Authentication > Users, o grupo principal.
4. Testar uma nova ligação dentro e fora da janela relevante.
5. Verificar o Log Viewer e a Firewall Rule ID utilizada.
6. Remover a nova política e o novo Schedule apenas quando já não existirem dependências.
7. Atualizar o ticket, o responsável e o resultado do teste.

Em funcionamento, as políticas partilhadas devem ter um responsável e uma Description clara. Quando os horários de trabalho, os modelos de feriados ou as estruturas dos grupos mudarem, as janelas de tempo e as atribuições devem ser novamente verificadas, em vez de a política ser silenciosamente alargada cada vez mais.

Lista de verificação operacional

• A hora e o fuso horário da firewall estão corretos.
• O Schedule é recorrente e está documentado.
• Allow ou Deny corresponde ao estado normal pretendido.
• A política Access Time está atribuída ao grupo ou utilizador correto.
• As exceções de utilizador foram verificadas.
• Para AD, o grupo principal está correto; não se pressupõem Other group memberships.
• O utilizador piloto aparece como Live User e o respetivo objeto de utilizador apresenta o grupo principal esperado.
• Foram realizados testes de limite positivos e negativos com novas ligações.
• A regra de firewall, o utilizador, a Rule ID e os logs estão em conformidade.
• O estado anterior e o rollback estão documentados.

Perguntas frequentes