Registro de auditoría administrativo.

Quién cambió qué en tu workspace, cuándo, desde dónde y cómo terminó. Solo se agrega: nadie edita ni borra una entrada.

Resumen

El registro de auditoría administrativo guarda quién cambió qué en tu workspace, cuándo, desde dónde y cómo terminó: una API key creada, un rol cambiado, una política de enforcement editada, una columna marcada como sensible. Cada cambio y su entrada se guardan en la misma transacción: si la entrada no se puede escribir, el cambio no se aplica.

No es el audit trail de queries. El audit trail registra cada decisión del motor sobre una query; este registro, los cambios de configuración y de acceso que hacen las personas, las API keys, los procesos de Vericto y su equipo.

Qué se registra

Cada uno de estos cambios deja una entrada:

  • API keys: creación, revocación y rotación.
  • Miembros e invitaciones: invitación enviada, aceptada o revocada, cambio de rol y baja de un miembro.
  • SSO y OIDC: la conexión SSO (incluido el inicio de sesión obligatorio por SSO) y sus dominios; las políticas de confianza OIDC para CI y cada credencial que emite un intercambio OIDC.
  • Login de la CLI: cada aprobación, que emite una key para el workspace.
  • Reglas: cambio de severidad, activación o desactivación (en el workspace o en una base), vuelta al valor del catálogo y reglas custom creadas, editadas o borradas.
  • Bases de datos y workspace: alta, cambio de ajustes del proxy y baja de una base; cambio de nombre del workspace.
  • Política de enforcement: acciones por severidad, modo monitor, ventana de observe mode, acción ante queries no parseables (parse_error_action) y modo de telemetría.
  • Columnas sensibles: marcar una columna, cambiar su política o su estilo de máscara y desmarcarla.
  • Destinos de alertas y webhooks: alta, cambio, apagado, encendido y baja. Apagar un destino es una acción propia, porque silencia las alertas.
  • Facturación: cambios de plan o de ciclo pedidos por un usuario, bajas programadas y su cancelación, y el cambio de plan que confirma el proveedor de pagos.
  • Contratos y retención: inicio y fin de un contrato Enterprise y cambios de los plazos de retención por contrato.
  • Audit trail: cada export pedido y cada eliminación de eventos antes de su plazo de retención, que Vericto hace solo a pedido del cliente.

Algunos intentos rechazados también quedan registrados, con resultado denied: por ejemplo, un miembro sin permiso que intenta crear una API key o cambiar un rol. Solo se registran los intentos de miembros del workspace; un request que no cambia nada no deja entrada.

Qué guarda cada entrada

  • Actor y tipo de actor: un usuario, una API key, Vericto (system, por ejemplo el webhook del proveedor de pagos o un intercambio OIDC) o un operador de Vericto que ejecuta un procedimiento, con la referencia que lo autoriza (operator).
  • IP, user agent y request id del request que hizo el cambio, cuando lo hay.
  • Acción y entidad: qué se hizo y sobre qué (una key, un miembro, una base, una política).
  • Resultado: success, denied o failure.
  • Antes y después de solo los campos que cambiaron. En un alta, el estado nuevo; en una baja, el último estado. Los secretos se reemplazan por [REDACTED]: un secreto que cambió figura como cambiado, sin su valor.
  • Hora del servidor de base de datos.

Qué nunca se guarda

El registro no guarda valores de API keys ni sus hashes, tokens, contraseñas, cadenas de conexión, secretos de clientes SSO, URLs de webhooks (llevan su credencial en la ruta) ni el email de las personas invitadas o de quien actúa. Todo campo con nombre de secreto se redacta al escribir, aunque el código que lo envía no lo pida, y también todo valor con forma de secreto: una URL con credenciales, una API key o una clave privada.

Las personas aparecen por su id de usuario. El dashboard muestra su nombre o email al leer, sin guardarlo en el registro.

Solo se agrega

La base de datos rechaza cualquier UPDATE, DELETE o TRUNCATE sobre el registro con un trigger, sea cual sea el rol que lo intente. Ninguna baja en cascada lo borra por debajo, y la purga diaria de retención no lo toca.

La única vía es deliberada y acotada, dentro de una sola transacción: al eliminar la cuenta de una persona (derecho de supresión), sus entradas se conservan y solo pierden el vínculo con ella, que pasa a figurar como erased user; al eliminar un workspace entero, se borran las entradas de ese workspace.

El trigger protege el registro contra errores de la aplicación y escrituras accidentales. No es un control contra alguien con acceso total a la base de datos como dueño de la tabla.

Cómo consultarlo

El owner y los admins lo ven en Configuración → Registro de auditoría del dashboard, en todos los planes. Los members y viewers no tienen acceso: las entradas llevan la IP y el user agent de otros miembros.

Las entradas van de la más reciente a la más antigua. Puedes filtrar por fechas, dominio (API keys, miembros, SSO, facturación…), resultado y actor, y cargar más páginas con un cursor. Al expandir una entrada ves la tabla de antes y después de los campos que cambiaron, la IP, el user agent y el request id.

Leer el registro no deja una entrada: no cambia nada, y una entrada por página vista ocultaría los cambios que el registro existe para mostrar.

Exportación

La exportación de este registro todavía no está disponible. El export firmado del dashboard cubre el audit trail de queries. Mientras tanto, el registro se consulta en el dashboard.

Evidencia para SOC 2

El registro muestra quién dio, cambió o quitó accesos y quién cambió la configuración, con fecha y origen:

  • CC6.1 a CC6.3, acceso lógico: API keys creadas, rotadas y revocadas; miembros invitados, con su rol y dados de baja; conexión SSO, políticas OIDC y credenciales emitidas.
  • CC8.1, gestión de cambios: cambios en reglas, política de enforcement, columnas sensibles, bases de datos y destinos de alertas, con el antes y el después.

Vericto aporta la evidencia; si un control se cumple lo determina tu auditor.