Tema
PCI DSS Pregunta 68 — Muestra de eventos del registro de auditoría
| Campo | Valor |
|---|---|
| Solicitante | José David Álvarez — QSA ControlCase |
| Pregunta | «Registros reales de eventos del sistema central de registro para cada plataforma en alcance, con los seis campos de Req 10.3.x» |
| Documento | EVD-Q68, revisión 2 |
| Fecha de esta revisión | 2026-08-12 |
| Sustituye a | Revisión 1, retirada en su totalidad — ver §1 |
| Controles PCI | Req 10.2.1.1, 10.3.1 a 10.3.6 |
| Elaborado | Gabriel Ureña Chacón — CTO Fintrix Pay |
1. Nota de corrección — lea esto primero
La revisión anterior de este documento se retira en su totalidad. Presentaba diez eventos fechados el 2026-06-16 como «muestra real». Esos eventos no existen en ningún sistema de Fintrix Pay. Se comprobó el 2026-08-12 contra la tabla de auditoría y contra el índice de eventos: no hay registro alguno de esa fecha ni de las direcciones que allí figuraban.
No se trata de datos desactualizados. Se trata de una muestra que no procede del entorno.
Al verificarlo apareció el problema de fondo, que es más grave que el documento:
| Comprobación (2026-08-12) | Resultado |
|---|---|
| Sesiones de usuario registradas en el sistema | 11 |
| De ellas, con evento de auditoría asociado | 0 |
| Contenido de la tabla de auditoría | 4 filas, todas marcadores de arranque del componente |
| Eventos de credenciales y de segundo factor | 0 |
El registro de auditoría a nivel de aplicación no capturaba ningún acceso. El componente que lo escribe estaba desarrollado, probado y disponible desde julio, pero el flujo de autenticación nunca lo invocaba, y además pedía unas variables de conexión que ese despliegue no define, de modo que tampoco habría podido escribir.
Se declara expresamente que, hasta el 2026-08-12, no se cumplía el Req 10.2.1.1 en lo relativo al registro de accesos individuales de usuario.
1.1 Corrección aplicada
| Fecha | Acción |
|---|---|
| 2026-08-12 | Se instrumenta el flujo de autenticación para registrar todo acceso, en su límite y no rama por rama, de modo que cubra también las salidas que se añadan en el futuro |
| 2026-08-12 | Se corrige la conexión del componente de auditoría, que pedía variables inexistentes en este despliegue |
| 2026-08-12 | Se despliega en producción y se verifica de extremo a extremo |
Lo que sí permanecía operativo durante el periodo afectado, y consta en sus propias evidencias: el registro de eventos de sistema operativo, la detección en tiempo de ejecución y la conservación inmutable de los registros recogidos. Lo que faltaba era específicamente la traza de aplicación.
2. Muestra real — contenido íntegro de la tabla
Se aporta la tabla completa, no una selección. Son ocho filas.
sql
SELECT timestamp, event_type, actor_id, actor_type, actor_ip,
outcome, target_resource, severity, component
FROM iam_core.pci_audit_events
ORDER BY timestamp;| timestamp (UTC) | event_type | actor_id | tipo | origen | resultado | severidad |
|---|---|---|---|---|---|---|
| 2026-07-26 15:09:42 | audit.log.initialized | system | system | — | success | info |
| 2026-07-26 15:10:06 | audit.log.initialized | system | system | — | success | info |
| 2026-07-26 15:10:41 | audit.log.initialized | system | system | — | success | info |
| 2026-07-26 15:11:17 | audit.log.initialized | system | system | — | success | info |
| 2026-08-12 18:54:28 | audit.auth.login.failure | [email protected] | user | 201.244.255.204 | failure | warn |
| 2026-08-12 18:54:28 | audit.auth.login.failure | [email protected] | user | 201.244.255.204 | failure | warn |
| 2026-08-12 18:55:06 | audit.auth.login.failure | unknown | user | 201.244.255.204 | failure | warn |
| 2026-08-12 19:56:52 | audit.auth.login.failure | unknown | user | 201.244.255.204 | failure | warn |
Sobre la procedencia de estos eventos, y para que no haya lugar a dudas:
- Las cuatro primeras filas son marcadores de arranque del componente, no actividad de usuario.
- Las cuatro últimas son tráfico de verificación generado por nosotros el 2026-08-12 al comprobar que la corrección funciona. No son actividad orgánica de usuarios. Los dos registros con actor
unknowncorresponden a peticiones sin credencial, y por eso el sistema no puede atribuirles identidad — que es el comportamiento correcto ante un intento de acceso inválido.
Esta muestra es pequeña y reciente porque el control empezó a registrar el 2026-08-12. Preferimos aportar ocho eventos ciertos y verificables antes que una muestra amplia que no se sostenga. La tabla crecerá con el uso normal del sistema y quedamos a disposición para aportar una muestra de actividad orgánica cuando el equipo evaluador lo considere oportuno.
3. Cobertura de los seis campos de Req 10.3.x
Los campos se comprueban sobre las filas reales de §2, no sobre el diseño.
| Requisito | Exige | Columna | Ejemplo de la muestra |
|---|---|---|---|
| 10.3.1 | Identificación del usuario | actor_id + actor_type | [email protected] / user |
| 10.3.2 | Tipo de evento | event_type | audit.auth.login.failure |
| 10.3.3 | Fecha y hora | timestamp | 2026-08-12 18:54:28 UTC |
| 10.3.4 | Indicación de éxito o fallo | outcome | failure |
| 10.3.5 | Origen del evento | actor_ip + component | 201.244.255.204 / auth-service |
| 10.3.6 | Recurso afectado | target_resource + target_id | — en un intento fallido no hay recurso alcanzado |
La tabla dispone además de event_id, severity, trace_id y extra, este último para el detalle específico de cada tipo de evento.
3.1 Sobre la dirección de origen
El servicio se ejecuta detrás de la pasarela de API. La dirección que se registra es la del cliente, tomada de la cabecera de reenvío, y no la de la pasarela: en caso contrario todos los eventos compartirían origen y el campo perdería su utilidad para Req 10.3.5.
3.2 Sobre lo que no se registra
La contraseña no se registra en ningún campo, en ningún caso. Hay una prueba automatizada que serializa todo lo que se entrega al componente de auditoría y comprueba que el secreto no aparece, en lugar de revisar campo por campo — que dejaría de proteger el día que alguien añada un campo nuevo.
4. Eventos cubiertos
El registro contempla acceso correcto, acceso fallido, cierre de sesión, segundo factor superado y fallido, bloqueo de cuenta, cambio y restablecimiento de contraseña, alta, baja y borrado de cuenta, y asignación de función.
El bloqueo de cuenta se registra como evento propio y no como credencial incorrecta: el requisito los trata por separado y su severidad no es la misma.
5. Por qué no se detectó antes
El componente existía, estaba probado y se importaba desde el módulo correspondiente. Nada en el arranque ni en los paneles indicaba anomalía, porque no había ninguna: el código no fallaba, sencillamente no se le llamaba desde el flujo de acceso, y su conexión estaba mal configurada de un modo que solo se manifestaba al intentar escribir.
Se ha incorporado a la revisión periódica de controles la comprobación de que las tablas de auditoría crecen, y no solo de que existen. Una tabla de auditoría que no crece mientras hay sesiones activas es un fallo, aunque todo lo demás figure correcto.
6. Verificación independiente
Cualquiera de las comprobaciones de este documento puede repetirse en sesión compartida con el equipo evaluador, incluida la generación de un intento de acceso y la consulta inmediata de la fila resultante.
Firma
- Elaborado: Gabriel Ureña Chacón — CTO Fintrix Pay
- Fecha: 2026-08-12
- Revisión: 2 (sustituye íntegramente a la anterior)