Configurar Access Time para usuarios en Sophos Firewall

Una política Access Time limita el acceso a internet de un usuario, un grupo o usuarios invitados a horarios definidos. La política combina una programación recurrente con Allow o Deny. Sin embargo, solo se aplica a una identidad que el firewall haya reconocido realmente y a la que la política esté asignada directamente o a través de su grupo principal.

El procedimiento rápido para permitir el acceso a internet durante el horario laboral es el siguiente:

1. En Administration > Time, comprobar la hora y la zona horaria del firewall.
2. En Profiles > Schedule, crear una programación recurrente, por ejemplo Internet_OfficeHours.
3. En Profiles > Access time > Add, crear la política Employees_OfficeHours_Allow con Action: Allow.
4. En Authentication > Groups, asignar la política a un grupo piloto pequeño.
5. En Current activities > Live users, comprobar el usuario y la dirección de origen y, en Authentication > Users, el grupo principal esperado.
6. Probar una conexión nueva a internet tanto dentro como fuera de la franja horaria.
7. Añadir más usuarios únicamente después de superar las pruebas positiva y negativa.

⚠️ Según Sophos, los cambios en una política Access Time entran en vigor inmediatamente. Por tanto, una política compartida no debe modificarse de forma improvisada. Primero hay que registrar los usuarios y grupos afectados, documentar una cuenta piloto y el estado anterior y, a continuación, probar de forma controlada los límites horarios.

Qué controla realmente Access Time

Access Time decide si un usuario autenticado obtiene acceso a internet a una hora determinada. La política no crea una regla de firewall ni una Web Policy y tampoco autentica al usuario. Por tanto, la ruta de red, la identificación del usuario, la coincidencia de la regla y las funciones de protección ya deben funcionar.

La evaluación requiere cuatro elementos:

• un Schedule recurrente con días y horas;
• una política Access Time con Allow o Deny;
• una asignación a un usuario, grupo o usuario invitado;
• una identidad reconocida, por ejemplo mediante Captive Portal, STAS, SATC u otro método de autenticación apropiado.

Elegir Allow o Deny de forma consciente

• Allow: el acceso a internet está permitido durante la programación seleccionada y denegado fuera de esa franja. Este modelo es adecuado para empleados, aulas o cuentas de proveedores con horarios de uso claramente definidos.
• Deny: el acceso a internet se deniega durante la programación y se permite fuera de ella. Este modelo es adecuado para una franja de bloqueo concreta, por ejemplo una clase recurrente o un periodo de descanso.

Para un acceso restringido nuevo, Allow suele ser más fácil de entender: la franja permitida queda visible directamente en el objeto y puede probarse de forma positiva y negativa con un grupo piloto pequeño. Deny tiene sentido cuando el estado normal debe permanecer expresamente abierto y solo se necesita una franja de bloqueo definida con precisión.

Schedule, cuota y hora de inicio de sesión son capas distintas

Las funciones con nombres parecidos resuelven tareas diferentes:

• Un Schedule solo contiene días y horas. Únicamente produce un efecto a través de una regla de firewall, una política o una política Access Time. Programaciones de Sophos Firewall para reglas y políticas explica la configuración completa.
• Surfing quota limita el tiempo de internet que puede consumir un usuario. Es un contingente de uso, no una franja horaria fija.
• Network traffic quota limita la cantidad de datos transferidos.
• La validez de una cuenta de invitado determina durante cuánto tiempo existen las credenciales. No sustituye a una Access Time recurrente.
• Los Clientless Users no admiten una política Access Time. Si un dispositivo fijo solo debe comunicarse a determinadas horas, la programación se aplica a una regla de firewall con un alcance limitado. Configurar Clientless Users en Sophos Firewall explica la identidad basada en IP.
• Schedule for device access en los ajustes de administrador limita los inicios de sesión en WebAdmin. La opción Access time normal no está destinada a ese fin.

Surfing Quota y Network Traffic Quota en Sophos Firewall explica cómo crear y asignar ambos créditos de consumo, comprobarlos en View usage y restablecerlos de forma segura.

Solo se deben combinar varias capas temporales con una intención documentada. La programación de una regla de firewall puede cerrar toda la ruta de red, mientras que Access Time solo afecta a los usuarios asignados. Si ambas capas utilizan franjas diferentes, cada límite debe probarse por separado.

Planificar el ejemplo y los requisitos

El ejemplo siguiente permite a un grupo de empleados acceder a internet de lunes a viernes entre las 07:30 y las 18:00:

• Schedule: Internet_OfficeHours
• Política Access Time: Employees_OfficeHours_Allow
• Action: Allow
• Grupo: Internet_OfficeHours
• Usuario de prueba: access-time-pilot
• Zona horaria: Europe/Zurich
• Franja horaria: de lunes a viernes, de 07:30 a 18:00

Los nombres y las horas son valores de ejemplo. En el entorno real, el nombre del grupo, el responsable, la zona horaria y el horario autorizado se toman del requisito de acceso efectivo. Un grupo solo debe contener usuarios con el mismo modelo horario.

Antes del cambio hay que comprobar estos requisitos:

1. En Administration > Time, Current time y Time zone son correctos. Configurar la hora del sistema y NTP en Sophos Firewall explica la configuración NTP.
2. El usuario piloto puede autenticarse con el método previsto.
3. En Current activities > Live users aparecen el nombre de usuario y la dirección de origen; en Authentication > Users, el campo Group es correcto.
4. Una regla de usuario o de red adecuada permite la ruta prevista a internet y registra el tráfico de prueba.
5. Están documentados la asignación Access Time anterior, el grupo principal y las posibles excepciones de usuario.

Si el usuario no puede identificarse como Live User, primero se corrige la autenticación. Una política Access Time no puede controlar de forma fiable una identidad desconocida por usuario o grupo.

Crear la programación y la política Access Time

Preparar una programación recurrente

Las políticas Access Time solo aceptan programaciones recurrentes. Aquí no está disponible una programación One-time.

Para el ejemplo:

1. Abrir Profiles > Schedule > Add.
2. Establecer Name en Internet_OfficeHours.
3. Establecer Recurrence type en Recurring.
4. Seleccionar de lunes a viernes.
5. Establecer Start time en 07:30 y Stop time en 18:00.
6. Documentar en Description el propósito, la zona horaria y el responsable.
7. Guardar con Save.

La programación por sí sola no modifica ningún acceso. Es un objeto temporal reutilizable y también puede utilizarse en otros lugares. Antes de cambiarla posteriormente, siempre hay que comprobar todos sus usos.

Crear la política Access Time

A continuación se conecta el objeto temporal con la acción de acceso:

1. Abrir Profiles > Access time.
2. Seleccionar Add.
3. Establecer Name en Employees_OfficeHours_Allow.
4. En Description, introducir, por ejemplo, Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT.
5. Establecer Action en Allow.
6. En Schedule, seleccionar Internet_OfficeHours.
7. Guardar con Save.

Esta política tampoco tiene ningún efecto mientras no se asigne a un usuario, grupo o usuario invitado.

Asignar la política a un grupo o usuario

Utilizar un grupo como modelo operativo normal

Para usuarios con el mismo modelo horario, un grupo resulta más claro que muchas asignaciones individuales:

1. Abrir Authentication > Groups.
2. Crear el grupo piloto Internet_OfficeHours o editar un grupo existente con un alcance adecuado.
3. En la sección de políticas, seleccionar Employees_OfficeHours_Allow en Access time.
4. No modificar de forma incidental otros ajustes de cuota, Traffic Shaping o Remote Access.
5. Guardar los cambios.
6. Autenticar un único usuario de prueba de este grupo y comprobar el grupo principal real.

Gestionar grupos de usuarios de Sophos Firewall de forma segura explica cómo interactúan los grupos locales e importados, el grupo principal y las excepciones de usuario. La importación de AD propiamente dicha se mantiene en Conectar Active Directory con Sophos Firewall.

Utilizar una excepción de usuario solo de forma consciente

En Authentication > Users puede seleccionarse una Access time propia para un usuario concreto. Este valor del usuario tiene prioridad sobre la política del grupo.

Una excepción resulta útil para un caso documentado, pero puede hacer que los cambios del grupo parezcan no tener efecto. Si un grupo está configurado correctamente pero un usuario se comporta de forma distinta, primero se comprueba su objeto de usuario. Para volver a la política del grupo, no se selecciona cualquier política individual nueva; se restablece de forma controlada el estado de herencia anterior.

En Active Directory solo cuenta el grupo principal

Para los usuarios de AD, Access Time no evalúa Other group memberships. Se aplica el grupo principal que aparece en Group dentro del objeto de usuario, salvo que se haya seleccionado expresamente una política para ese usuario.

El orden en Authentication > Groups > Reorder influye en qué grupo importado se convierte en el grupo principal. Por tanto, cambiar este orden puede afectar no solo a Access Time, sino también a otras funciones. No debe utilizarse como solución rápida para un solo usuario. Es preferible un orden de grupos planificado conscientemente o una excepción de usuario documentada.

Los cambios en los grupos de AD, su orden y sus políticas se aplican la próxima vez que el usuario inicia sesión. Para realizar una prueba limpia, hay que crear una nueva sesión de autenticación y volver a comprobar el grupo principal.

Controlar los usuarios invitados mediante su grupo

Los usuarios invitados en Sophos Firewall reciben un grupo en Authentication > Guest user settings y heredan sus políticas. Para aplicar a los invitados una franja recurrente de acceso a internet, se asigna la política Access Time a este grupo de invitados claramente delimitado.

El Validity period de la cuenta de invitado sigue siendo un límite adicional: determina durante cuánto tiempo es válida la cuenta. Access Time determina las horas recurrentes permitidas o denegadas dentro de esa validez. Configurar y probar Captive Portal en Sophos Firewall explica el inicio de sesión de invitados y la regla de firewall.

Probar de forma fiable los límites horarios

Una política guardada todavía no demuestra el éxito. La aceptación comprueba conjuntamente la identidad, la política y el acceso real a internet:

1. Documentar la hora del firewall, la zona horaria, la programación y la acción.
2. Volver a autenticar al usuario piloto.
3. En Current activities > Live users, comprobar el nombre de usuario y la dirección de origen; en Authentication > Users, comprobar el grupo principal.
4. Dentro de la franja Allow, abrir una conexión HTTP o HTTPS nueva a un destino de prueba permitido.
5. En Log Viewer, comprobar el usuario, el grupo, el origen, el destino, el Firewall Rule ID, la acción y la marca de tiempo.
6. Fuera de la franja, probar una conexión nueva al mismo destino y confirmar el bloqueo esperado.
7. Para una política Deny, realizar la misma prueba con la expectativa inversa.
8. Solo entonces asignar usuarios adicionales o el grupo de producción.

La regla de firewall debe seguir coincidiendo con el usuario, la red y el destino. Probar correctamente una regla de Sophos Firewall explica cómo evaluar conjuntamente Rule ID, Log Viewer y Packet Capture.

Sophos documenta que los cambios en las políticas Access Time entran en vigor inmediatamente. Sin embargo, eso no constituye una promesa general de que todas las sesiones de aplicaciones existentes finalicen exactamente en el límite horario. Para requisitos críticos de seguridad, se observan por separado una conexión nueva y una sesión que ya estaba en curso.

Delimitar errores de forma sistemática

El usuario no tiene acceso a internet a pesar de la política

Primero hay que comprobar si la hora actual está dentro de la programación para Allow o fuera de ella para Deny. A continuación, comprobar la identidad del usuario y la dirección de origen en Current activities > Live users, y el grupo principal en Authentication > Users. Si el usuario no aparece en Live users, el siguiente paso es la autenticación, no una política Access Time más amplia.

Después se comprueban la regla de firewall, la coincidencia del usuario, la posición de la regla y Log Viewer. Access Time no puede reparar una ruta de red inexistente ni una política web, de aplicaciones o TLS que bloquee el tráfico.

El acceso funciona fuera de la franja Allow

Comprobar que realmente se está probando el usuario esperado y que el objeto de usuario no tiene otra Access Time configurada. En AD, comprobar además el grupo principal y el orden de grupos. Una prueba sin autenticar o con una asignación incorrecta no demuestra que la política falle.

A continuación, generar un flujo de prueba nuevo. Una sesión existente puede comportarse de forma distinta a una conexión nueva. Si el tráfico aparece en Log Viewer sin el usuario esperado, primero hay que resolver la identificación del usuario.

Un cambio de grupo no afecta a un usuario

Una política explícita del usuario tiene prioridad sobre la política del grupo. En Authentication > Users, comprobar el campo Access time y, en AD, el grupo principal. Access Time no evalúa Other group memberships.

Tras modificar los grupos de AD, volver a autenticar al usuario. Solo entonces puede evaluarse el orden actual de grupos y la asignación de políticas.

Captive Portal aparece de forma inesperada

Sophos enumera una Access Time restringida, credenciales incorrectas y cuotas agotadas como posibles causas de problemas de NTLM o Captive Portal. Comprobar por separado Access Time, Surfing quota, Network traffic quota y las credenciales. No se debe cambiar precipitadamente la política a Allow ni ampliar la programación mientras no esté clara la causa real.

Un cambio afecta a más usuarios de lo esperado

Una política Access Time compartida afecta inmediatamente a todas sus asignaciones después de un cambio. Primero se restablecen la acción y la programación documentadas anteriormente. A continuación, se inventarían los grupos y las excepciones de usuario afectadas y se prueba el nuevo requisito con una política piloto separada.

Planificar cambios y rollback

Antes de cada cambio productivo se documentan el nombre de la política, la acción, la programación, los grupos afectados, las excepciones de usuario, los grupos principales, la hora del firewall y el resultado de la prueba. De este modo, el rollback queda inequívoco.

Un rollback controlado consiste en:

1. Restablecer la asignación Access Time anterior para el usuario o el grupo piloto.
2. En AD, volver a autenticar al usuario de prueba.
3. En Current activities > Live users, comprobar el usuario y la dirección de origen y, en Authentication > Users, el grupo principal.
4. Probar una conexión nueva tanto dentro como fuera de la franja relevante.
5. Comprobar Log Viewer y el Firewall Rule ID utilizado.
6. Eliminar la política y la programación nuevas únicamente cuando ya no queden dependencias.
7. Actualizar el ticket, el responsable y el resultado de la prueba.

En funcionamiento, las políticas compartidas deben tener un responsable y una descripción clara. Cuando cambien los horarios laborales, los modelos de festivos o las estructuras de grupos, hay que revisar de nuevo las franjas y las asignaciones en vez de ampliar silenciosamente la política cada vez más.

Lista de comprobación operativa

• La hora y la zona horaria del firewall son correctas.
• La programación es recurrente y está documentada.
• Allow o Deny coincide con el estado normal deseado.
• La política Access Time está asignada al grupo o usuario correcto.
• Se han comprobado las excepciones de usuario.
• En AD, el grupo principal es correcto; no se presuponen Other group memberships.
• El usuario piloto aparece como Live User y su objeto de usuario muestra el grupo principal esperado.
• Se han realizado pruebas positivas y negativas en los límites con conexiones nuevas.
• La regla de firewall, el usuario, Rule ID y los logs concuerdan.
• El estado anterior y el rollback están documentados.

Preguntas frecuentes