Audit log¶

Eval360Pro registra eventos relevantes para seguridad y compliance en una tabla AuditLogs. Cada tenant tiene su propio audit log; el SystemAdmin tiene el de plataforma.

Acceso¶

TenantAdmin → ve el audit log de su tenant en Registro de auditoría
SystemAdmin → ve el audit log de plataforma en Registro de auditoría
Otros roles no tienen acceso al audit log

Estructura de cada evento¶

Campo	Descripción
`OccurredAt`	Timestamp UTC del evento
`EventType`	Categoría del evento, formato dotted (ej. `auth.login.success`)
`EntityType`	Tipo de entidad afectada (ej. `Tenant`, `User`, `Plan`)
`EntityId`	ID de la entidad afectada (Guid o int)
`UserId` / `UserName`	Quién disparó el evento (puede ser null para acciones anónimas o de sistema)
`Details`	JSON con contexto adicional (ej. payload del cambio, razón del fallo) — máximo ~1900 chars
`IpAddress`	IP del cliente que originó el request
`UserAgent`	Browser / cliente

Eventos registrados¶

Lista de event types implementados en el código (categorías de tres niveles area.entity.action):

Autenticación¶

Event	Detalles típicos en `Details`
`auth.login.success`	`email`, `scheme` ("cookie" / "jwt")
`auth.login.failure`	`email`, `reason` (`INVALID`, `LOCKED_OUT`, `TENANT_MISMATCH`, `TENANT_SLUG_UNKNOWN`)
`auth.logout`	—
`auth.password.changed`	(cuando un usuario cambia su propia contraseña)
`auth.password.reset.requested`	(cuando se solicita reset por email)
`auth.password.reset.completed`	(cuando se completa el reset)
`auth.email.confirmed`	(cuando se confirma el email vía link)
`auth.2fa.enabled`	(al activar 2FA)
`auth.2fa.disabled`	(al desactivar 2FA)

Tenants (visible solo en audit de plataforma)¶

Event	Detalles
`tenant.created`	`slug`, `name`, `adminEmail`
`tenant.status.changed`	`from`, `to`, `slug`
`tenant.plan.assigned`	`planId`
`tenant.impersonation.started`	`slug`, `name`
`tenant.impersonation.stopped`	—

Planes (plataforma)¶

Event	Detalles
`plan.created`	`code`, `name`, `maxEmployees`, `maxAnnualCycles`
`plan.updated`	`code`, `name`, `maxEmployees`, `maxAnnualCycles`, `isActive`
`plan.deleted`	—

Plantillas de email¶

Event	Detalles
`emailtpl.saved`	`key`, `lang`, `scope` (Tenant / Platform)
`emailtpl.reset`	`key`, `lang`, `scope`
`emailtpl.restored`	`key`, `lang`, `scope` (cuando se hace undo)

Otros eventos¶

Los servicios internos (creación de empleados, ciclos, planes de desarrollo, goals, etc.) no generan eventos en audit log por default. Lo que queda registrado son los eventos sensibles (auth, tenant lifecycle, planes, plantillas).

Si necesitas auditar otros eventos específicos, cada servicio puede llamar a IAuditService.LogAsync(...) para agregarlos.

Filtros en la UI¶

Tipo de evento — autocomplete con los eventos existentes
Entidad — filtrar por EntityType (ej. solo Tenant)
Fecha — desde / hasta
Usuario — buscar por nombre o email

Lectura de un evento¶

Click en una fila de la lista → modal con: - Toda la metadata - El Details JSON expandido (formateado) - IP + user-agent

Retención¶

Por default los eventos no se borran automáticamente. Quedan en DB indefinidamente. Si necesitas limpiar (compliance / espacio), ejecutar manualmente:

-- Eliminar eventos de más de 24 meses
DELETE FROM AuditLogs WHERE OccurredAt < DATEADD(month, -24, GETUTCDATE());

Tener en cuenta que los eventos de auditoría suelen ser requeridos por normativas (GDPR, ISO 27001, SOC 2) por períodos de 12-36 meses.

Casos de uso típicos¶

Investigar un acceso sospechoso¶

Filtrar por EventType = auth.login.failure y mirar la IP/user-agent. Si hay muchos intentos desde una IP, considerar bloquearla a nivel firewall/Plesk.

Saber quién cambió una configuración¶

Filtrar por EventType = emailtpl.saved (por ejemplo) → ver quién modificó qué plantilla y cuándo.

Exportar todos los eventos de un usuario específico (UserId = X) para responder a un "Right to Access" request.

Diagnosticar problema de plan limit¶

Si un usuario reporta "no puedo crear más empleados", buscar en logs de aplicación (Serilog) el error PLAN_LIMIT_EMPLOYEES. Audit log no registra estos rechazos (son validaciones de negocio, no eventos auditables).

Limitaciones¶

No hay export del audit log a CSV/Excel desde la UI. Si necesitas, consulta la tabla AuditLogs directamente vía SQL Server Management Studio
No hay alertas automáticas (ej. "avisame si hay >10 logins fallidos en 1 minuto"). Hay que armar externo (monitoreo + reglas SIEM si querés algo serio)
Soft-delete no escapa al audit log: si una entidad se borra, el evento que la creó/modificó sigue en el log (con EntityId apuntando a un registro ya eliminado)