Alertas de inicio de sesión de VPN: ¿qué evento debería activarlas en realidad?
El éxito de autenticación, un túnel establecido y un RADIUS accounting Start son tres afirmaciones distintas. Elija la que su destinatario pueda aprovechar y luego correlacionelas.
El éxito de autenticación, un túnel establecido y un RADIUS accounting Start son tres afirmaciones distintas, y un correo de inicio de sesión solo significa algo cuando elige una de ellas. La mayoría de los diseños de alertas de VPN mezclan las tres y producen una bandeja de entrada en la que nadie confía. La decisión depende de quién lee la alerta y qué puede hacer en los siguientes cinco minutos. Si se equivoca, la alerta se convierte en ruido que oculta el único evento que necesitaba.
Tres preguntas deciden el disparador
Pregunte quién la recibe, qué hará y con qué rapidez debe ocurrir la acción. Un equipo de seguridad que vigila el uso indebido de credenciales quiere un patrón de fallo y luego éxito desde una cuenta en cuestión de minutos. Un equipo de operaciones que vigila la capacidad quiere la duración de la sesión y los motivos de desconexión, no los inicios de sesión. Un servicio de ayuda quiere la identidad de la sesión para poder emparejarla con un ticket.
Esas respuestas apuntan a eventos distintos, y ninguna regla única satisface las tres. Si la acción del destinatario es «llama al usuario», la autenticación basta. Si la acción es «libera una licencia» o «verifica que el túnel transportó tráfico», solo sirven el establecimiento o el accounting Start. Si la acción es «factura el tiempo», necesita registros Stop en lugar de un inicio de sesión.
Escriba la respuesta en una sola frase antes de configurar algo. «Este correo le dice al ingeniero de guardia que la cuenta X abrió un túnel desde la red Y a la hora Z, para que pueda comprobar si se usó la ventana de mantenimiento.» Si no puede rellenar cada casilla, el disparador aún no está elegido.
Ajuste el evento a la afirmación que hace
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
La tabla esconde una dependencia: cada fila solo es fiable si la puerta de enlace la emite de forma fiable y su colector conserva el campo que necesita. Lea la definición del evento para la versión exacta que ejecuta, porque el nombre de «sesión establecida» cambia entre versiones y el significado cambia más a menudo que el nombre. Cuando una definición es vaga, pida una captura de sesión en lugar de adivinar por la etiqueta.
Tratar un Access-Accept como la finalización de todo lo que viene después es el error más común. Es un veredicto sobre las credenciales, no una sesión. El error espejo es leer una coincidencia de política como prueba de autorización, cuando una regla puede coincidir y el siguiente paso aún puede fallar.
Una sesión, una notificación
Una cuenta, varios dispositivos, retransmisiones y reconexiones: un correo por evento será incorrecto en ambas direcciones, duplicando una sesión mientras divide otra. Fije la notificación en la puerta de enlace más un identificador de sesión, y trate el nombre de la cuenta como un atributo en lugar de como la clave. Un usuario con portátil y teléfono puede mantener dos túneles a la vez, y ambos merecen su propia línea.
Los registros contables retransmitidos son normales, así que deduplique por el id de sesión y la marca de tiempo antes de representar el mensaje. Las sesiones consecutivas del mismo dispositivo deben permanecer separadas, y una reconexión durante una ventana de mantenimiento debe seguir visible en lugar de colapsar en la anterior. Si su colector reescribe las marcas de tiempo al ingerir, deduplique por los campos del registro original, no por los almacenados.
Un registro Stop ausente es incertidumbre, no una sesión permanente. Los reinicios de la puerta de enlace, las caídas del colector y la pérdida de UDP dejan huecos, así que la alerta necesita una ruta de reconciliación que consulte la tabla de sesiones activas antes de que alguien concluya que un túnel sigue en pie.
Mantenga la auditoría y la notificación separadas
El flujo de auditoría y el flujo de alertas tienen trabajos diferentes. Conserve los registros en bruto, incluidos cuenta, puerta de enlace, id de sesión, marcas de tiempo y motivo de terminación, incluso cuando los correos rutinarios se agrupan, se suprimen o se envían a una lista de guardia pequeña. Un umbral de gravedad es un filtro de entrega, no una selección del evento del ciclo de vida que quería anunciar.
Envíe el contexto mínimo que el destinatario necesita para encontrar el registro protegido. Los nombres de cuenta, las direcciones internas y los detalles de sesión son sensibles, y un correo que se reenvía bien es un correo que se filtra bien.
Luego demuéstrelo de principio a fin. Ejecute un inicio y cierre de sesión normales, una reconexión, dos sesiones simultáneas y un fallo de entrega forzado, y rastree un evento desde la puerta de enlace a través del colector hasta el mensaje entregado. Si el correo llega sin un id de sesión, el contrato está incompleto. Si dos correos describen una sesión, la correlación está rota. Ninguno de los dos problemas aparece cuando lo único que prueba es que la entrega de correo funciona.