Monosign: auditoría, informes y resolución de problemas
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 3 → 4
Actualización5 lecciones actualizadas
Actualización de contenido. Se notificó a los estudiantes inscritos.
Cada acción del producto escribe una fila de auditoría. Reports → `Audit` muestra estas filas de la más reciente a la más antigua, con filtros por objeto, actor, tipo de auditoría, aplicación y periodo. La misma lista aparece en la página de un usuario como pestaña `Audit`.
::shot aud-audit-list
### Qué puede hacer en la página
- **`Details`** abre una fila con sus datos y su `Correlation Id`, el valor que une las filas de una misma petición.
- **`Schedule`** envía por correo un resumen de auditoría: una lista de filas de los tipos que elija, enviada al instante, al alcanzar un umbral o por tiempo.
- La lista **no tiene exportación a archivo**. Cuando alguien necesite filas de auditoría en un archivo, cree un informe de Report Studio sobre el origen de datos `Audit Events`. El módulo siguiente lo explica.
### Permisos para un rol de soporte
Abrir la página y leer las filas son dos permisos distintos. La ruta de la página necesita `System.Management.Report.Audit`. La lista necesita `System.Management.User.AuditList` y, desde v2026.10, también `Details` de una sola fila. Hasta v2026.09 cualquier usuario de Management con sesión podía abrir una fila por su id. Tras una actualización, un rol de soporte personalizado que solo leía filas sueltas recibe HTTP 403 hasta que se añade `System.Management.User.AuditList`. No busque una API para listar auditorías: la API lee una fila por su id o escribe filas para sistemas externos.
### Retención
Las filas de auditoría permanecen hasta que la regla `Audit` de System → `Data Retention` las elimina. Cada regla tiene `Enable` y `Remove older than N days`. El borrado es permanente: no se archiva nada antes ni se exporta nada por usted.
Acuerde por tanto el orden del trabajo con el cliente. Si cumplimiento debe conservar evidencias más tiempo que el periodo de la regla, prepare primero la exportación, por ejemplo un informe programado de Report Studio sobre `Audit Events`, y solo después active la regla.
::diagram aud-retention-order
> Consejo: anote el periodo de retención y la programación de la exportación en el mismo documento de entrega. Un auditor pedirá ambos.
Una lista de asignaciones muestra quién tiene acceso **hoy**. Las sesiones y las auditorías de inicio de sesión muestran quién **inició sesión**. Ninguna responde a la pregunta clásica de auditoría: *¿quién tenía acceso a esta aplicación en una fecha pasada concreta?* Para eso está Dashboard → `Timeline`, la página titulada `Access Timeline`.
::diagram aud-three-questions
La línea de tiempo registra como eventos cada concesión y revocación de roles, permisos, grupos, aplicaciones y recursos, y los cambios de valores de perfil. Como sabe cuándo empezó y terminó cada acceso, muestra los mismos datos en varias vistas:
| Vista | Para qué sirve |
| --- | --- |
| `Events` | La lista en bruto, filtrada por fechas, usuario, origen, aplicación o tipo de evento |
| `Timeline` | El acceso como intervalos de concedido a revocado |
| `Snapshot` | El estado del acceso en un momento dado |
| `Compare` | Lo añadido y lo retirado entre dos fechas |
| `Unused` | Acceso a aplicaciones con el que nadie inicia sesión |
| `Pinned` | Eventos que usted fijó con una nota de investigación |
`Export CSV` escribe la vista actual en un archivo, hasta 100.000 filas.
::shot aud-access-timeline
### Límites que debe conocer el auditor
- La página llegó en v2026.07. `Build history` reconstruye eventos a partir de los datos actuales, de modo que se puede mostrar acceso anterior, pero las filas reconstruidas y los eventos escritos antes de v2026.09 muestran `System` como actor.
- **Las eliminaciones de grupo hechas antes de v2026.09 no se registraron y no se pueden reconstruir.** `Build history` no las recupera. Si la evidencia que necesita es una eliminación así, dígalo y busque otra evidencia, como el registro de auditoría.
- Para `Unused` solo cuentan los inicios de sesión en aplicaciones. No se sigue el uso de roles ni de permisos.
- Ninguna regla de retención elimina eventos de la línea de tiempo, así que un hueco nunca se debe a una purga.
- Quien puede abrir la página ve todo el tenant.
> Consejo: ante una pregunta sobre una fecha concreta, empiece con `Snapshot` en esa fecha y use después `Compare` contra hoy para mostrar qué ha cambiado.
En Reports → `Report Studio` se crean informes propios. Un informe lee un **origen de datos**: uno de los predefinidos, como `Audit Events`, o un origen de datos que el cliente compuso en `Custom Data Sources`. No se puede escribir SQL, y los informes no están disponibles en la API pública.
::shot aud-report-studio
### Dos tipos de informe
- **`Report Builder`**: una tabla con columnas, filtros, agrupación, agregados y orden, mostrada como `Table`, `Bar`, `Line` o `Pie`.
- **`Composite Report`**: un documento hecho de bloques, como títulos, texto, tablas, gráficos y un resumen de KPI. Sirve para un resumen de dirección, por ejemplo la cobertura de MFA junto a los usuarios de riesgo.
Las plantillas del sistema están listas para ejecutarse y no se pueden editar.
### Ejecución
Una ejecución produce `CSV`, `Excel`, `PDF` o `HTML`. Las ejecuciones se ponen en cola y se generan en segundo plano, y los archivos aparecen en `Run History`, un botón de la barra de herramientas de `Report Studio`. Sin el permiso para gestionar todos los informes solo verá sus propias ejecuciones. Los archivos no se guardan para siempre: los artefactos caducados se eliminan.
### Los datos personales se enmascaran por defecto
Las columnas con datos personales se enmascaran. El constructor tiene un interruptor `Unmasked PII` que se guarda con el informe. Eso no significa que todas las ejecuciones salgan sin máscara:
- Si una ejecución sale sin máscara se decide **cuando se pone en cola, según el permiso de quien la ejecuta**.
- Para un usuario sin el permiso de exportación sin máscara, el interruptor guardado se ignora y su ejecución sale enmascarada.
- Cada ejecución sin máscara escribe la auditoría `REPORT_EXPORT_UNMASKED`.
Por eso el mismo informe puede mostrar nombres completos a su autor y nombres enmascarados a un analista júnior. Es el comportamiento previsto, no un fallo. Dé el permiso a las pocas personas que lo necesitan y revise ese tipo de auditoría.
::diagram aud-unmasked-run
> Consejo: comparta un informe con roles, no con personas, y mantenga el permiso sin máscara fuera de esos roles salvo que el informe lo requiera.
Un responsable que quiere el mismo resumen cada lunes no debería tener que iniciar sesión en Management, y nadie debería exportarlo a mano. Una programación de informes ejecuta un informe de Report Studio según un calendario y entrega el resultado. La barra lateral no tiene una entrada para las programaciones: abra el informe en `Report Studio` y elija `Schedule (admin)`, o use `More` → `Schedules` en la barra de herramientas.
::shot aud-report-schedules
### Qué contiene una programación
- **Recurrencia**: diaria, semanal o mensual, a una hora en la zona horaria propia de la programación. No hay expresión cron libre.
- **Formato**: uno de los formatos de ejecución, por ejemplo `PDF`.
- **Destinatarios**: el propietario y direcciones adicionales.
- **Entrega**: `Download link` o `Email attachment`.
- Opcionalmente un **webhook** que se llama cuando termina la ejecución.
### Elegir la entrega
| Entrega | Qué recibe el destinatario | Sirve para |
| --- | --- | --- |
| `Download link` | Un enlace que exige iniciar sesión en Management | Personas con cuenta y derecho sobre la ejecución |
| `Email attachment` | Los archivos en el correo si suman 10 MB o menos; si no, enlaces | Cualquiera con buzón, incluido un auditor externo sin cuenta |
| Webhook | Metadatos y URL autenticadas, nunca los datos del informe | Sistemas que reaccionan a una ejecución terminada |
El error habitual es `Download link` para un destinatario que solo tiene una dirección de correo. Esa persona no puede pasar el inicio de sesión y nunca ve el archivo. Cambie la programación a `Email attachment` y mantenga el informe lo bastante pequeño para no superar el límite.
### Suscripciones
Un usuario con acceso a Report Studio también puede usar `Subscribe` en un informe para sí mismo. Una suscripción siempre envía un enlace, siempre va enmascarada y necesita una cuenta, así que no sirve para llegar a lectores externos.
### Cuándo se detiene una programación
Una programación se pausa sola tras 5 fallos consecutivos, cuando se desactiva a su propietario o cuando se borra el informe, y guarda el motivo. Revise `More` → `Schedules` cuando alguien diga que el informe del lunes no llegó.
> Consejo: asigne a las programaciones un propietario que vaya a permanecer, como un administrador de servicio, y no el consultor que las creó.
Cuando una cuenta puede estar comprometida, importan tres herramientas: la lista de sesiones, la contraseña y una vista en vivo de lo que hace el usuario. Cada una tiene un comportamiento que debe conocer antes del incidente.
### Encontrar una sesión
Management → `Sessions` muestra `Active Sessions`. Sin un filtro de usuario, la lista muestra solo las sesiones **iniciadas o actualizadas en los últimos 30 minutos**. Una sesión todavía válida pero inactiva durante más tiempo no aparece en esta página.
La misma sesión se ve desde la página del usuario: Users → usuario → `Sessions` → `Active`, porque esa ruta filtra por el usuario. No concluya que un usuario no tiene sesión hasta haber mirado allí. Las sesiones están en una tabla compartida, así que el centro de datos al que esté conectado no cambia nada.
Desde ambos sitios puede cerrar una sesión, todas las sesiones de un usuario en una aplicación o todas. El cierre escribe una auditoría de cierre de sesión y revoca los tokens de la sesión.
::shot aud-active-sessions
### Un cambio de contraseña no termina las sesiones
Una contraseña nueva, la cambie el usuario, la fije un administrador o venga de un restablecimiento, **no** termina las sesiones que ya estaban abiertas. Siguen siendo válidas hasta que caducan o alguien las termina.
Ante una sospecha de compromiso, haga las dos cosas: cambie la contraseña **y** termine las sesiones del usuario. Si solo restablece la contraseña, el registro de auditoría puede seguir mostrando actividad de la sesión del atacante.
::diagram aud-incident-steps
Desde v2026.10 la política de contraseñas tiene dos interruptores relacionados: `End Active Sessions When Locked After Failed Attempts` (desactivado por defecto) y `End Active Sessions When an Administrator Locks the Account` (activado por defecto). Afectan a los bloqueos, no a los cambios de contraseña.
### Live Tracking
Directory → Users → `Live Tracking` permite elegir un usuario y ver llegar sus eventos de auditoría en tiempo real. Dos límites:
- **La página no guarda nada.** Solo muestra eventos generados mientras está abierta. La actividad pasada está en el registro de auditoría.
- **Los eventos generados en otro centro de datos nunca aparecen.** En un despliegue con dos centros de datos, averigüe a cuál llega el usuario y abra Management allí antes de concluir que no ocurre nada.
> Consejo: en una llamada de soporte, inicie primero el seguimiento y pida después al usuario que repita la acción.