Explicación de Registros y Pistas de Auditoría
Los registros y la auditoría de PostgreSQL parecen un solo tema desde el exterior, pero en realidad son tres mecanismos distintos que responden a tres preguntas de investigación distintas.
//
Busca en todas las páginas de la documentación
Los registros y la auditoría de PostgreSQL parecen un solo tema desde el exterior, pero en realidad son tres mecanismos distintos que responden a tres preguntas de investigación distintas.
Esta página construye el modelo mental que separa esos mecanismos: los registros del servidor, la auditoría a nivel de sentencia a través de pgaudit y el historial a nivel de fila a través de disparadores de auditoría, para que pueda elegir la herramienta adecuada en lugar de recurrir a la que ya está configurada.
El registro del servidor es la caja negra de propósito general de PostgreSQL, que captura conexiones, desconexiones, errores, puntos de control y, opcionalmente, consultas lentas.
Responde a preguntas operativas como "¿tuvo éxito esta conexión?" o "¿qué consulta superó el umbral de latencia?", y existe en cada clúster por defecto en alguna forma mínima.
pgaudit es una extensión diseñada específicamente que añade un registro de acceso estructurado a nivel de sentencia sobre el registro del servidor, respondiendo "¿quién ejecutó qué tipo de SQL contra qué objetos?".
Los disparadores de auditoría son un mecanismo completamente diferente: disparadores a nivel de aplicación que escriben los valores de fila anteriores y posteriores en tablas de auditoría dedicadas, respondiendo "¿cómo se veía esta fila específica antes y después de que cambiara?".
La distinción más importante es la granularidad: los registros del servidor y pgaudit describen sentencias y conexiones, mientras que los disparadores de auditoría describen cambios de datos a nivel de fila con valores antiguos y nuevos capturados.
Una analogía útil es una tienda minorista: el registro del servidor es el mostrador de entrada de la puerta, pgaudit es la cámara de seguridad que graba quién caminó por qué pasillo, y los disparadores de auditoría son el recibo detallado que muestra exactamente qué cambió de manos.
Ninguno de los tres reemplaza a otro, porque un recibo no te dice nada sobre quién estaba navegando sin comprar, y un contador de puertas no te dice nada sobre lo que había en la cesta de nadie.
PostgreSQL 18.4 utiliza por defecto un registro mínimo, por lo que casi todas estas capacidades requieren una configuración deliberada antes de producir evidencia útil.
Estos mecanismos se encuentran en diferentes puntos del ciclo de vida de la solicitud, lo que explica tanto sus fortalezas como sus puntos ciegos.
El registro del servidor se popula como un efecto secundario de la ejecución de la conexión y la consulta, controlado por configuraciones como log_connections, log_statement y log_min_duration_statement.
pgaudit se engancha en la misma ruta de ejecución pero clasifica la actividad en categorías lógicas (read, write, ddl, role), permitiendo a los equipos limitar el registro a exactamente las clases que requiere un programa de cumplimiento en lugar de un interruptor de todo o nada.
Los disparadores de auditoría se ejecutan dentro de la misma transacción que el cambio de datos en sí, activándose en INSERT, UPDATE o DELETE y escribiendo una fila en una tabla de auditoría antes de que la transacción original se confirme.
Ese acoplamiento transaccional es la diferencia mecánica clave: el registro de un disparador de auditoría se confirma con el cambio que describe o se revierte con él, mientras que una línea de registro escrita en el registro del servidor no es transaccional en ese mismo sentido.
-- Un mecanismo hecho concreto: un disparador de auditoría mínimo captura
-- el estado de la fila antiguo/nuevo de forma transaccional, ligado al cambio que describe.
CREATE FUNCTION audit_orders() RETURNS trigger AS $$
BEGIN
INSERT INTO audit.orders_history(order_id, old_row, new_row, changed_at)
VALUES (COALESCE(NEW.id, OLD.id), to_jsonb(OLD), to_jsonb(NEW), now());
RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;El volumen es la otra preocupación mecánica que conecta los tres: registrar cada sentencia en un clúster OLTP ocupado puede llenar el disco en cuestión de horas, por lo que tanto los registros del servidor como pgaudit están diseñados para ser limitados de forma estrecha (solo consultas lentas, solo DDL, roles específicos) en lugar de ejecutarse con la máxima verbosidad por defecto.
Un error de razonamiento frecuente es tratar el volumen de registro como un problema puramente de infraestructura, cuando en realidad es un problema de diseño de evidencia: registrar todo produce tanto ruido que encontrar la única línea relevante durante un incidente se convierte en su propia investigación.
A escala, el registro y la auditoría se convierten en un problema de retención y canalización tanto como un problema de captura.
Centralizar los registros en un SIEM o un canal de envío de registros desacopla la retención del disco local, lo que es importante porque los programas de cumplimiento a menudo requieren de 90 días a varios años de evidencia retenida que un host de base de datos nunca fue diseñado para almacenar localmente.
Formatos estructurados como csvlog o la salida de registro JSON de PostgreSQL existen específicamente para hacer que esa canalización sea confiable, ya que analizar la salida stderr no estructurada a escala es frágil en comparación con analizar campos bien definidos.
Los datos regulados introducen una tensión específica: la evidencia de auditoría debe ser capturada, pero la misma evidencia (texto de consulta, valores de fila) puede contener los datos sensibles que se están protegiendo, por lo que la redacción y el control de acceso en la pista de auditoría son tan importantes como en las tablas de origen.
Los disparadores de auditoría y pgaudit se combinan con frecuencia en lugar de elegirse exclusivamente, y pgaudit proporciona el rastro de acceso amplio requerido por marcos como PCI DSS y los disparadores proporcionan el historial a nivel de fila para las tablas específicas donde "cuál era el valor anterior" es una pregunta regulatoria real.
La resistencia a la manipulación es un detalle de diseño que merece atención deliberada: las tablas de auditoría normalmente deberían revocar UPDATE y DELETE de los roles de aplicación para que solo la función del disparador pueda agregar filas, preservando el valor probatorio del rastro.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
Registro del servidor (log_min_duration_statement, log_statement) | Infraestructura adicional cero, siempre disponible | Grueso, no consultable como datos estructurados | Solución de problemas operativos, captura de consultas lentas |
| pgaudit | Rastro de acceso estructurado, clasificado y con ámbito de rol | Sin valores de fila antiguos/nuevos, se requiere canalización de registro | Evidencia de cumplimiento a nivel de sentencia (SOC2, PCI) |
| Disparadores de auditoría | Valores anteriores/posteriores a nivel de fila, consultables en SQL | Sobrecarga de escritura, esfuerzo de implementación por tabla | Historial de filas exigido por el regulador, UI de cambios en la aplicación |
Los registros del servidor registran eventos operativos, pgaudit añade un rastro de acceso estructurado a nivel de sentencia, y los disparadores de auditoría capturan valores anteriores/posteriores a nivel de fila de forma transaccional.
No está estructurado y está orientado a eventos, careciendo del rastro de acceso clasificado y consultable que los marcos como SOC2 o PCI suelen requerir.
No, pgaudit registra el texto de la sentencia y la clasificación de acceso, no los datos de la fila; capturar valores anteriores/posteriores requiere un disparador de auditoría que escriba en una tabla de historial.
La fila de auditoría del disparador se escribe dentro de la misma transacción que el cambio de datos, por lo que se confirma o revierte junto con él, a diferencia de una línea de registro del servidor.
Puede llenar el disco en cuestión de horas en una carga de trabajo ocupada y entierra las líneas de registro genuinamente útiles en ruido durante un incidente.
A menudo sí, con pgaudit proporcionando evidencia de acceso amplia en muchas tablas y los disparadores proporcionando historial a nivel de fila en las tablas específicas donde los valores anteriores son importantes.
Hace que el envío de registros a un SIEM o canalización sea confiable, ya que analizar campos bien definidos es mucho más robusto que analizar texto stderr no estructurado.
El texto de la consulta y los valores de fila capturados pueden contener los mismos datos sensibles que la pista de auditoría existe para proteger, por lo que el rastro necesita sus propios controles de acceso.
Revocar UPDATE y DELETE de los roles de aplicación para que solo la función del disparador pueda agregar nuevas filas preserva el valor probatorio del rastro.
Generalmente sí, porque las ventanas de retención de cumplimiento a menudo exceden lo que un host de base de datos fue diseñado para almacenar localmente, y la centralización desacopla la retención del disco local.
Normalmente proporcionan infraestructura de entrega de registros (CloudWatch, Cloud Logging), pero la configuración del registro en sí, y cualquier diseño de disparador de auditoría, sigue siendo responsabilidad del cliente.
Descubrir durante un incidente o una auditoría de cumplimiento que la evidencia específica necesaria, ya sea el rastro de acceso o el historial de filas, nunca se estaba capturando.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (línea principal estable 18, línea de mantenimiento 17).
Revisado por Chris St. John·Última actualización: 15 jul 2026