Cómo configurar las notificaciones por correo electrónico del registro de seguridad

Cuándo usar esto

Cuando el administrador de seguridad necesita enterarse por correo electrónico de una infracción de integridad o del bloqueo de una cuenta, sin abrir el registro. El indicador de evento crítico del encabezado solo lo ve quien está en ese momento en la interfaz. El correo llega en cualquier caso.

Las notificaciones se configuran en dos lugares. El servidor de correo se define en el archivo de entorno del dispatcher de vStack Center en la VM de administración. La activación, los destinatarios y el umbral de gravedad se definen en la interfaz del registro. Sin el servidor, el formulario de la interfaz se guarda sin errores, pero no se envía ningún correo. Este es el motivo más habitual de "lo configuramos y no llega nada".

Requisitos previos

• un servidor SMTP que acepte correo de la VM de administración sin autenticación. El dispatcher no tiene parámetros para usuario, contraseña ni modo de cifrado;
• acceso SSH a la VM de administración como root;
• el rol Cluster master para guardar la configuración de notificaciones. Security Admin puede ver la configuración, pero no guardarla;
• vStack Center 3.0.3 o posterior.

Pasos

Paso 1. Definir el servidor de correo en la VM de administración

Añada los parámetros al archivo de entorno del dispatcher /usr/local/etc/vstack_center_dispatcher.env:

SMTP_HOST=192.0.2.25
SMTP_PORT=25
SMTP_SEND_FROM=vstack-security@example.com
SMTP_TIMEOUT=15000

Parámetro	Valor
SMTP_HOST	Dirección del servidor SMTP. Un valor vacío o la ausencia de la línea desactiva el envío
SMTP_PORT	Puerto, 25 de forma predeterminada
SMTP_SEND_FROM	Dirección del remitente. Sin ella, los correos se envían desde no-reply@vstack.com, y el servidor de correo de su organización puede rechazar el correo de un dominio ajeno
SMTP_TIMEOUT	Tiempo de espera de conexión en milisegundos, 15000 de forma predeterminada

Las conexiones salientes desde la VM de administración no están restringidas de forma predeterminada. Si las ha restringido, abra el puerto del servidor SMTP.

Paso 2. Reiniciar el dispatcher y comprobar el log

service vstack_center_dispatcher restart

El dispatcher lee los parámetros solo al iniciarse. En el log de /var/log/vstack-center-dispatcher/, busque una de estas líneas:

Línea	Significado
SMTP initialized: host=…, port=…	Se ha creado el transporte de correo; continúe en la interfaz
SMTP_HOST not set — email notifications disabled	El dispatcher no leyó el parámetro: compruebe el nombre del archivo y la línea SMTP_HOST

SMTP initialized no significa que el servidor sea accesible. El dispatcher se conecta a él solo al enviar un correo.

Paso 3. Activar las notificaciones en el registro

1. Abra Sites → el clúster → Security Event Log.
2. Haga clic en Actions sobre la tabla y seleccione Notification settings.
3. Active Enable email notifications.
4. En Recipients, escriba una dirección y pulse Enter. La dirección se añade a la lista situada debajo del campo. Añada varias direcciones de la misma forma; elimine una con la cruz.
5. En Minimum severity for email, seleccione el umbral.
6. Haga clic en Save. Aparece el mensaje "Notification settings updated".

Un cambio de configuración se escribe en el registro como config.security_settings_changed. La edición del archivo de entorno del paso 1 no pasa por la API y no se registra.

Paso 4. Elegir el umbral de gravedad

Se envía un correo por cada evento cuya gravedad sea igual o superior al umbral. El umbral predeterminado es alert. El diccionario de tipos de eventos no tiene eventos emergency, por lo que con alert solo llegan correos por cinco infracciones de integridad.

Umbral	Llegan correos por
alert (predeterminado)	integrity.file_violation, integrity.config_violation, integrity.vm_config_violation, integrity.manifest_invalid, integrity.log_chain_broken
critical	todo lo anterior, más auth.account_locked, system.disk_space_exhausted, os.kernel_panic y otros eventos critical
error e inferiores	todo lo anterior, más los apagados no limpios del nodo y del servicio de virtualización (os.shutdown_unclean, system.service_stopped_unclean) y otros eventos del nivel seleccionado

El indicador de evento crítico cuenta los tres niveles superiores. Para recibir correos por los mismos eventos que encienden el indicador, establezca el umbral en critical. Con el umbral predeterminado, el bloqueo de una cuenta y el agotamiento del espacio en disco se muestran en la interfaz, pero no generan correo.

Una discrepancia de la suma de comprobación de una imagen al importarla (integrity.image_sha256_mismatch) tiene gravedad warning, aunque pertenece a la categoría de integridad. Solo genera correo con un umbral warning o inferior.

Un umbral inferior a error produce un flujo de correos sobre eventos rutinarios: un inicio de sesión fallido es warning, uno correcto es info.

Qué contiene el correo

El asunto es [vStack Security] <event name> — <severity code>, por ejemplo [vStack Security] Блокировка учётной записи — critical. El nombre del evento procede del diccionario de tipos de eventos y siempre está en ruso.

El cuerpo es texto sin formato, también en ruso:

Событие безопасности
Наименование: Блокировка учётной записи
Уровень: Критическое состояние (critical)
Дата/время: 2026-10-09T08:15:42.118305+00:00
Субъект: operator (uid=17)
Объект: user/17 (operator)
Результат: success
IP: 198.51.100.40

Las líneas son: nombre del evento, gravedad, fecha y hora, sujeto (nombre e ID del usuario), objeto (tipo, ID, nombre), resultado y dirección IP de origen. Un campo ausente se sustituye por un guion. Cada destinatario recibe un correo independiente.

Tenga en cuenta tres cosas al leer un correo:

• la hora del correo es el momento en que se generó el correo, en UTC, no la hora de la entrada del registro. La diferencia suele ser una fracción de segundo, pero no permite emparejar entradas con precisión de milisegundos;
• el correo no incluye el número de entrada ni el UUID del evento. Busque la entrada en el registro filtrando por tipo de evento y hora; consulte Cómo leer el registro y filtrar eventos;
• el correo se envía después de guardar la entrada. Si la entrada se revierte, no hay correo. Un servidor lento o inaccesible no retrasa la entrada del registro.

Verificar el resultado

No hay ningún botón de correo de prueba, así que compruebe la entrega con un evento real. El bloqueo de una cuenta es lo más sencillo:

1. Establezca el umbral en critical.
2. Cree una cuenta de prueba y agote su límite de intentos fallidos de inicio de sesión. El registro recibe auth.account_locked.
3. El log del dispatcher muestra email notify: sent to <address> o email notify: failed to send to <address> con el motivo, una línea por destinatario.
4. Compruebe el buzón del destinatario.
5. Desbloquee o elimine la cuenta de prueba y restablezca el umbral si necesita otro.

sent to significa que el servidor SMTP aceptó el correo, no que haya llegado al buzón. Si el log indica sent to y no hay correo, busque en la carpeta de spam y en el log del servidor de correo.

Solución de problemas

La configuración se guarda, pero no llega ningún correo. Busque en el log del dispatcher la entrada de su último inicio. Si indica SMTP_HOST not set — email notifications disabled o no hay ninguna línea SMTP initialized, el servidor de correo no está definido. En ese caso, los eventos por encima del umbral producen email notify: SMTP not available en el log. Realice los pasos 1 y 2.

No hay correos ni nada en el log sobre el evento. El evento está por debajo del umbral, las notificaciones están desactivadas o la lista de destinatarios está vacía. En estos casos, el dispatcher omite el correo sin avisar. Compruebe el formulario Notification settings y la gravedad del evento en la ficha de la entrada.

El log indica failed to send to <address>. El servidor SMTP es inaccesible o rechazó el correo. El motivo figura en la misma línea. Los más habituales: el servidor requiere autenticación o TLS, el remitente es de un dominio ajeno (defina SMTP_SEND_FROM), el puerto está cerrado. No hay reintento: el correo de ese evento se pierde y la entrada del registro se conserva.

Los correos dejaron de llegar después de una actualización de vStack Center. El archivo de entorno del dispatcher se regenera en cada despliegue de la configuración de la VM de administración, incluidas las actualizaciones, y las líneas SMTP_* desaparecen. Después de cada actualización, compruebe que la línea SMTP initialized aparece en el log y repita los pasos 1 y 2 si es necesario.

La configuración no se guarda (-24007). Una dirección de destinatario tiene un error tipográfico, o no se pulsó Enter y la dirección no está en la lista.

El menú Actions no tiene el elemento Notification settings. El rol no tiene el privilegio View Security Notify Settings. Solo Cluster master puede guardar la configuración.

Limitaciones

• El dispatcher no admite usuario, contraseña ni TLS para SMTP. Si su servidor de correo requiere autenticación, necesita un relay intermedio que acepte correo de la VM de administración sin ella.
• No hay reintento. Un error de entrega solo es visible en el log del dispatcher; no aparece en el registro de seguridad ni en la interfaz.
• El servidor de correo solo se define en el archivo de entorno. No se puede configurar a través de la interfaz ni de la API, y una actualización lo borra.

Métodos de la API

Operaciones de esta página en la API: security-event-notify-settings-get, security-event-notify-settings-set; consulte la referencia de la API.

Véase también

• Registro de seguridad: niveles de gravedad y eventos críticos.
• Cómo leer el registro y filtrar eventos: el indicador de eventos críticos y la marca de lectura.