Audit: investigar acciones con contexto
Objetivo y acceso
Audit muestra actividad administrativa para reconstruir qué acción se solicitó y cuál fue su resultado. Navegar requiere admin.audit.view; la información queda limitada al alcance permitido. Auditoría no es el log de ejecución de un Mapping ni una copia de datos transformados. Para investigar una ejecución utilice Monitor en Dova y relacione sólo identificadores permitidos.
Confirme tenant y rol activo antes de buscar. La ausencia de un registro visible no prueba que nunca ocurrió una acción: puede haber una restricción de alcance, un filtro o una diferencia entre el registro consultado y la operación investigada.
Leer la evidencia
La tabla presenta registros mediante el componente común de datos. Use controles visibles de búsqueda, ordenación, columnas y paginación según estén habilitados. Examine tipo de acción, objeto, contexto temporal y resultado expuestos. No complete campos ausentes mediante suposiciones.
| Situación | Interpretación |
|---|---|
| Solicitud registrada | Se recibió una intención; no prueba éxito final |
| Resultado completado | El flujo registró finalización según su contrato |
| Fallo registrado | Revisar motivo y estado actual antes de reintentar |
| Eventos cercanos | Pueden ser etapas o reintentos, no necesariamente efectos duplicados |
En acciones cloud se distingue solicitud de resultado. La operación del proveedor y la limpieza del registro Dova tienen un orden propio. Conserve la secuencia al elaborar conclusiones.
Procedimiento de investigación
- Formule la pregunta: por ejemplo, si terminó una modificación de rol o falló una retirada.
- Acote tenant y periodo autorizados. No mezcle casos independientes.
- Localice el evento y lea su detalle. Busque resultado correspondiente cuando haya varias etapas.
- Consulte el módulo del objeto para confirmar estado actual. Auditoría histórica y estado actual responden preguntas distintas.
- Documente referencias mínimas: clase de evento, momento y resultado. Evite datos personales, secretos y payloads de otros tenants.
Si debe compartir evidencia, prepare un resumen con valores sintéticos o debidamente minimizados. Conserve el vínculo interno autorizado al caso original fuera del documento público. La explicación debe distinguir lo observado de lo inferido.
POC sintético
En un entorno local aislado cambie la etiqueta de un rol de laboratorio y compruebe el resultado en Roles. Busque la actividad en Audit usando los controles ofrecidos. Repita una acción rechazada por permiso insuficiente mediante fixture autorizado y compare la evidencia disponible.
Para cloud, los tests de API ofrecen una expectativa precisa: fallo del proveedor conserva worker y no registra éxito de eliminación. Explique ese resultado sin provocar fallos en una VM real. Use nombres como rol_revision_demo. La prueba debe concluir con estado final verificado, no sólo con una captura del mensaje de confirmación.
Errores, recuperación y límites
Si la tabla no carga revise mensaje y sesión. Un 403 no se resuelve cambiando tenant manualmente. Si no encuentra evento, revise filtros, periodo y módulo. No efectúe un segundo cambio sólo para comprobar que aparece en auditoría.
Este capítulo no promete retención indefinida, firma criptográfica del historial, exportación forense ni campos ausentes en UI. Esas garantías necesitan contrato específico. Para investigación formal preserve evidencia mediante el procedimiento autorizado; una captura aislada no sustituye ese proceso.
Cuando dos eventos parezcan contradictorios, confirme su orden y alcance. Una solicitud fallida seguida de reintento exitoso no implica pérdida de auditoría. Evite usar únicamente el último mensaje visible para describir toda la operación.