Enforcement.

Cómo decide Vericto qué hacer con cada query: la separación entre severidad y acción, las decisiones posibles y el observe mode (dry-run) para validar el ruleset antes de bloquear en producción.

Resumen

Cada query que pasa por Vericto se analiza contra el ruleset del workspace. Del análisis salen dos cosas distintas: una severidad, que describe qué tan peligrosa es la query, y una acción de enforcement, que describe qué hace Vericto al respecto. Separar ambos conceptos es lo que te permite ajustar la respuesta sin cambiar la clasificación de riesgo.

La acción la resuelve la política de enforcement del workspace a partir de la severidad. El resultado final de cada query es una de cinco decisiones: ALLOWED, FLAGGED, MONITORED, BLOCKED o PARSE_ERROR.

Solo BLOCKED detiene una query. Las demás decisiones reenvían la query a la base de datos; se diferencian en la telemetría y las alertas que generan. Cuando el observe mode está activo, ni siquiera BLOCKED detiene nada: todas las acciones BLOCK se degradan a FLAG.

Severidad frente a acción

Vericto trata estos dos ejes por separado a propósito:

  • Severidad: qué tan peligrosa es la query. Es una propiedad de la regla que se dispara y no cambia entre workspaces. Los niveles son Critical, High, Medium, Low e Informational.
  • Acción de enforcement: qué hace Vericto cuando una query viola una regla. Las acciones son BLOCK (detener), FLAG (reenviar con alerta) y MONITOR (reenviar y registrar, sin alerta). La acción la decide la política de enforcement del workspace.

La ventaja práctica: dos organizaciones pueden coincidir en que un DELETE sin WHERE es de severidad Critical, pero una elige bloquearlo y otra solo alertar mientras ajusta sus procesos. La severidad es un hecho sobre la query; la acción es una decisión de política.

Decisiones por query

Tras el análisis, cada query recibe exactamente una de estas decisiones. Solo BLOCKED impide que la query llegue a la base de datos:

Decisión Acción origen Comportamiento
ALLOWED — La query no viola ninguna regla. El proxy la reenvía a la base de datos sin cambios.
FLAGGED FLAG La query viola una regla con acción FLAG. Se reenvía a la base de datos, pero genera telemetría y dispara una alerta a los canales de notificación configurados.
MONITORED MONITOR La query viola una regla con acción MONITOR. Se reenvía y se registra en el audit trail, sin disparar alertas.
BLOCKED BLOCK La query viola una regla con acción BLOCK. El proxy TCP devuelve SQLSTATE 42501 y la query nunca llega a la base de datos. El CLI y la API reportan status BLOCKED y exit_code 1.
PARSE_ERROR — La sintaxis de la query es inválida y no se pudo parsear. Por defecto Vericto opera en fail-open: reenvía la query y la registra, sin contarla como bloqueo. El comportamiento es configurable a fail-closed por workspace.

Política por defecto

Cuando activas el enforcement, Vericto aplica esta correspondencia entre severidad y acción. Puedes ajustarla por regla, pero estos son los valores de partida:

Severidad Acción por defecto Decisión resultante
Critical BLOCK BLOCKED
High BLOCK BLOCKED
Medium FLAG FLAGGED
Low MONITOR MONITORED
Informational MONITOR MONITORED
Parse error Allow + report (fail-open) PARSE_ERROR

Resumen de la política por defecto: Critical y High se bloquean, Medium se marca (flag), Low e Informational se monitorean, y los errores de parseo se permiten y se registran.

Observe mode (dry-run)

El observe mode es un modo dry-run pensado para validar el impacto del ruleset antes de bloquear tráfico real. Mientras está activo, todas las acciones BLOCK se degradan a FLAG: nada se bloquea, pero verás en el dashboard exactamente qué queries se habrían bloqueado y con qué regla.

En el schema real, el observe mode se controla con una ventana temporal: mientras NOW() < observe_mode_expires_at, cada decisión BLOCK se degrada a FLAG. Hay dos campos relacionados: observe_mode_expires_at (el instante en que caduca la ventana) y monitor_mode (un booleano).

Elección en el onboarding

Al conectar tu primera base de datos eliges entre dos modos:

  • Observación (recomendado): ventana de 7 días en la que Vericto no bloquea nada, solo marca lo que habría bloqueado. Ideal para medir el impacto sin riesgo.
  • Protección inmediata: el enforcement se activa desde el primer momento y las acciones BLOCK detienen queries de verdad.

Cómo activar el enforcement real

Mientras el observe mode está activo, el dashboard muestra un banner con los días restantes de la ventana. Puedes salir del observe mode y activar el enforcement real en cualquier momento desde Dashboard → Rules. Al salir, las acciones BLOCK vuelven a detener queries de inmediato.

Mientras el observe mode esté activo, tu base de datos no está protegida frente a queries destructivas: todo se reenvía. Úsalo para calibrar el ruleset y sal a enforcement real en cuanto estés seguro del impacto.

El estado se puede consultar y modificar por API con GET y PATCH sobre el endpoint enforcement-policy, que expone los campos observe_mode_active, observe_days y monitor_mode.

Manejo de errores de parseo

Cuando una query tiene sintaxis inválida y Vericto no puede parsearla, no hay AST que analizar contra el ruleset. El comportamiento en ese caso lo define la política del workspace:

  • Fail-open (por defecto): la query se reenvía a la base de datos y se registra como PARSE_ERROR. No cuenta como bloqueo. Prioriza la disponibilidad: una query mal formada suele fallar sola en el motor de la base de datos.
  • Fail-closed (configurable): la query se bloquea si no se puede parsear. Prioriza la seguridad, a costa de rechazar queries que el parser no reconoce aunque fueran legítimas.

La opción por defecto es fail-open porque evita cortes por dialectos SQL o construcciones que el parser aún no cubre. Si tu entorno exige que nada llegue a la base de datos sin analizarse, cambia a fail-closed en la configuración del workspace.

Preguntas frecuentes

¿Qué diferencia hay entre severidad y acción?

La severidad describe qué tan peligrosa es una query y es una propiedad de la regla que se dispara. La acción describe qué hace Vericto (bloquear, marcar o monitorear) y la decide la política de enforcement del workspace. Puedes cambiar la acción sin cambiar la severidad.

¿Qué recibe el cliente cuando una query se bloquea?

El proxy TCP devuelve SQLSTATE 42501 y la query nunca llega a la base de datos. Cuando usas el CLI o la API, el status es BLOCKED y el exit_code es 1, lo que te permite fallar un pipeline de CI/CD ante una query peligrosa.

¿El observe mode protege mi base de datos?

No. En observe mode todas las acciones BLOCK se degradan a FLAG, así que ninguna query se detiene. Sirve para medir el impacto del ruleset, no para proteger. Sal a enforcement real desde Dashboard → Rules cuando estés listo.

¿Puedo cambiar la acción de una severidad concreta?

Sí. La tabla de política por defecto es solo el punto de partida. Puedes ajustar la acción por regla desde Dashboard → Rules, por ejemplo bajar una regla High de BLOCK a FLAG mientras adaptas tus procesos.

¿Qué pasa si Vericto no puede parsear una query?

Por defecto, en fail-open, la query se reenvía y se registra como PARSE_ERROR, sin contar como bloqueo. Si tu workspace está en fail-closed, la query se bloquea al no poder analizarse.