Auditoría y logs
La auditoría es el sistema que registra qué pasa dentro de la plataforma de manera inmutable y consultable. Es la base sobre la que se sostienen las atestaciones SOC 2, los reportes a autoridades de protección de datos y las propias revisiones internas de la iglesia.
Qué se registra
Toda acción crítica deja un registro en audit_logs con:
- Quién (usuario + rol al momento de la acción).
- Qué (entidad afectada y tipo de cambio).
- Cuándo (timestamp UTC con milisegundos).
- Desde dónde (IP, user agent).
- Datos del cambio (estado antes y después para entidades sensibles).
Acciones cubiertas
| Categoría | Eventos |
|---|---|
| Autenticación | login exitoso, login fallido, logout, cambio de contraseña, activación / reset de MFA. |
| Permisos | invitación de usuario, cambio de rol, cambio de alcance por campus, desactivación. |
| Datos personales | creación, edición y borrado de miembros, hogares y prospectos. |
| Datos financieros | creación de batch, cierre de batch, emisión de recibo fiscal, conexión / desconexión de Stripe, ejecución de pago. |
| Datos sensibles | acceso a campos PHI (HIPAA), acceso a datos de menores (COPPA), descarga de archivos sensibles. |
| Configuración | cambios en configuración de iglesia, branding, política de privacidad, suscripción. |
| Integraciones | conexión y desconexión, errores de sincronización, cambios de credenciales. |
| Exportes | descargas masivas de datos personales o financieros. |
Append-only
El log es append-only: solo se permite agregar entradas. Nadie, ni siquiera super_admin ni el equipo técnico de Ministrium, puede modificar o borrar entradas pasadas.
Cómo se garantiza:
- La tabla
audit_logsno tiene endpoints de UPDATE ni de DELETE expuestos. - Las políticas de Postgres Row-Level Security niegan operaciones de modificación incluso al rol técnico del backend.
- Cada entrada incluye un hash de integridad encadenado con la entrada anterior; alterar una rompería la cadena y se detectaría en el próximo check de integridad.
- Cada noche un job verifica la cadena completa y emite alerta si encuentra inconsistencias.
Esta combinación (RLS + hash encadenado + verificación periódica) es defensa en profundidad: aunque alguien lograra ejecutar SQL arbitrario, una alteración del log se detectaría en menos de 24 horas.
Retención
- 7 años de retención obligatoria, en cumplimiento con regulaciones financieras (recibos fiscales) y SOC 2.
- Después de 7 años, la iglesia puede solicitar exportación final y borrado, o conservación extendida.
- Los logs viejos se mueven a almacenamiento frío después de 12 meses sin cambiar su accesibilidad — solo cambia el costo y el tiempo de respuesta de la consulta (de milisegundos a segundos).
Quién puede consultar el log
El módulo Auditoría del menú lateral está disponible para los roles:
- admin — toda la iglesia.
- pastor — toda la iglesia, sin acciones financieras detalladas.
- contador y finanzas — todas las acciones financieras.
Otros roles no ven el log, aunque sus propias acciones quedan registradas. Esto es deliberado: la auditoría es una herramienta de gobernanza, no una vista operativa.
Filtros y búsqueda
Desde el módulo Auditoría se puede filtrar por:
- Rango de fechas.
- Usuario (quién hizo la acción).
- Tipo de evento (login, edición de miembro, cierre de batch, etc.).
- Entidad afectada (un miembro específico, un evento, un batch).
- IP o user agent.
- Texto libre sobre los datos del cambio.
Los filtros se combinan con AND.
Exportación
Cualquier vista filtrada se puede exportar en:
- CSV — para abrir en hoja de cálculo.
- JSON — para importar a herramientas de SIEM o BI.
Los exportes son por sí mismos eventos auditados (queda registro de quién exportó qué y cuándo).
Integración con SIEM
Para iglesias o denominaciones que operan un SIEM (Security Information and Event Management) propio, ofrecemos:
- Webhook saliente que envía cada evento de auditoría a la URL que configure la iglesia.
- Conector Splunk / Datadog / Elastic estándar bajo plan enterprise.
- API de auditoría documentada en API Reference.
Lo que no se registra
Por diseño:
- Contraseñas en claro. Solo registramos que hubo un cambio de contraseña, no la contraseña.
- Contenido de mensajes pastorales privados. Registramos que el mensaje se envió, no su texto.
- Información de pago de tarjeta. No la procesamos; lo hace Stripe.
Próximos pasos
- SOC 2 — la auditoría externa que valida estos controles.
- Cifrado — cómo se protege el log mismo.
- GDPR y LGPD — cómo el log soporta los derechos del titular.