En una frase: hemos cerrado los agujeros de permisos de los paneles de avisos (ITSM/alertas) y de los dashboards de WiFi y SAIs — un usuario de “solo mirar” ya no puede tocar nada que no debe, y los secretos de los canales de aviso ya no se enseñan.
¿Qué se ha arreglado y por qué importa?
Estos paneles del producto gestionan cosas sensibles: las políticas de aviso (cuándo y a quién se notifica un problema), los canales por los que llega el aviso (Slack, email, webhooks), las alertas de la red, y los tableros de estado de los puntos WiFi y los SAIs (las baterías que mantienen los equipos encendidos en un apagón).
La auditoría encontró que ninguno de estos paneles comprobaba el permiso del usuario — solo que hubiera entrado con su cuenta. Traducido: alguien con rol de “solo lectura” podía crear o borrar políticas, silenciar alertas, cambiar configuraciones, e incluso lanzar un escaneo de toda la red. Eso ya está cerrado: cada acción pide ahora el nivel correcto (ver vs. editar), igual que ya se hizo en las partes anteriores del módulo.
Otras mejoras de esta tanda, en cristiano:
- Los secretos ya no se enseñan: la lista de canales de aviso devolvía las contraseñas y URLs secretas de los webhooks a la vista. Ahora salen tapadas (
••••). Si editas un canal sin tocar el secreto, el secreto guardado se conserva solo. - Comandos peligrosos bien bloqueados: la protección que impide ejecutar comandos destructivos en los equipos se podía saltar poniendo el comando malo en una segunda línea. Tapado.
- El botón “probar canal” ya no miente: antes decía “éxito” aunque no se enviara nada. Ahora avisa del fallo de verdad.
- Menos ruido de alertas: una avería que dura horas ya no genera miles de eventos repetidos; reutiliza el mismo. Y los avisos de escalado se silencian durante una ventana de mantenimiento (antes seguían sonando).
- Datos coherentes: la “tasa de resolución” contaba como resueltas alertas que solo se habían “visto”; corregido.
¿Qué falta (y por qué se deja para después)?
Dos cosas, a propósito, en sus propios cambios:
- Cifrar los secretos de los canales también dentro de la base de datos (la fuga “por pantalla” ya está tapada). Esto toca el envío de avisos en marcha, así que se prueba antes en el entorno de pruebas (staging) para no dejar a nadie sin alertas.
- Un registro de quién creó/borró qué en estos paneles — se hará con un mecanismo central, en su propio cambio.
Para el equipo
Si gestionáis canales de aviso o alertas y notáis que un usuario de solo-lectura ya no puede tocar algo que antes sí: es lo correcto, no un fallo. Quien necesite editar debe tener rol de operador o admin.
Referencia técnica: PR #70 · Auditoría Suprema, monitoring sub-áreas 4 y 5.
Véase también
- [[feature—monitoring—auditoria-suprema-etapa-3-sa4-sa5]]
- [[feature—network—auditoria-sa4-devices-backups-groups]]