Conector de historial de Snowflake.

Un conector de solo lectura que lee el historial de consultas de tu cuenta de Snowflake, evalúa cada sentencia con las reglas de tu workspace y te muestra lo que Vericto habría bloqueado. Solo observa: cuando Vericto lee una consulta, ya se ejecutó.

Próximamente. El conector de historial de Snowflake todavía no está disponible: esta página describe cómo funcionará. Hoy, Snowflake se protege antes de la ejecución con la API de runtime, la CLI y MCP.

Qué es

Conectas una cuenta de Snowflake a una base de datos de Vericto con el dialecto Snowflake. Cada cierto intervalo, Vericto lee el historial de consultas de la cuenta (SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY), evalúa cada sentencia con las reglas del workspace y guarda el resultado como un evento de consulta. Responde a la pregunta «¿qué habría bloqueado, marcado o enmascarado Vericto?» para cada consulta que se ejecutó en Snowflake.

Ve las consultas que se originan dentro de Snowflake, que ningún proxy externo puede ver: worksheets de Snowsight, Cortex, Snowpark, Notebooks, tasks y herramientas de BI, de todos los usuarios de la cuenta.

Solo observa, después de la ejecución. Las sentencias ya se ejecutaron cuando Vericto las lee. El conector no bloquea, no enmascara ni frena nada, y no escribe nada en tu cuenta. Sus hallazgos dicen «Se habría bloqueado», nunca «Bloqueado». Para bloquear antes de la ejecución, usa la API de runtime, MCP o la CLI (ver la comparación).

Requisitos

  • Plan Team o Enterprise. Si el workspace baja a un plan inferior, el conector se pausa, y se reanuda solo (en menos de una hora) al volver a Team o Enterprise.
  • Una base de datos registrada en Vericto con el dialecto Snowflake (Dashboard → Bases de datos). Hay una conexión de historial por base de datos.
  • Alguien que pueda ejecutar el SQL de configuración en Snowflake: ACCOUNTADMIN, o SECURITYADMIN para el rol y el usuario y SYSADMIN para el warehouse.
  • Opcional: el linaje de ACCESS_HISTORY (las columnas que una consulta leyó a través de vistas) requiere Snowflake Enterprise Edition. En Standard Edition, o si el rol no tiene acceso a esa vista, el conector sigue funcionando sin él y la tarjeta de la conexión indica por qué.

Configuración

Vericto genera el par de claves RSA (2048 bits), guarda la clave privada cifrada con la clave de tu workspace y te muestra solo la clave pública, ya dentro del SQL. No generas ni copias ninguna clave privada, y ningún endpoint la devuelve. El usuario es de tipo SERVICE: no tiene contraseña ni MFA y no puede iniciar sesión en Snowsight.

Ejecuta este SQL en Snowflake. El dashboard lo muestra con tu clave pública en lugar del marcador:

USE ROLE ACCOUNTADMIN;  -- or SECURITYADMIN for the role and user, SYSADMIN for the warehouse

CREATE ROLE IF NOT EXISTS VERICTO_HISTORY_ROLE
  COMMENT = 'Vericto history connector: read-only access to query history';

-- Query history (and ACCESS_HISTORY on Enterprise Edition). Pick ONE:
GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE VERICTO_HISTORY_ROLE;   -- narrower
-- GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE VERICTO_HISTORY_ROLE; -- every ACCOUNT_USAGE view

CREATE WAREHOUSE IF NOT EXISTS VERICTO_HISTORY_WH
  WAREHOUSE_SIZE = XSMALL AUTO_SUSPEND = 60 AUTO_RESUME = TRUE INITIALLY_SUSPENDED = TRUE
  COMMENT = 'Vericto history connector';
GRANT USAGE ON WAREHOUSE VERICTO_HISTORY_WH TO ROLE VERICTO_HISTORY_ROLE;

CREATE USER IF NOT EXISTS VERICTO_HISTORY_SVC
  TYPE = SERVICE
  DEFAULT_ROLE = VERICTO_HISTORY_ROLE
  DEFAULT_WAREHOUSE = VERICTO_HISTORY_WH
  RSA_PUBLIC_KEY = '<public key shown by Vericto>'
  COMMENT = 'Vericto history connector';
GRANT ROLE VERICTO_HISTORY_ROLE TO USER VERICTO_HISTORY_SVC;

SNOWFLAKE.GOVERNANCE_VIEWER es el rol de base de datos que cubre QUERY_HISTORY y ACCESS_HISTORY. No se concede nada más: ningún privilegio sobre bases, esquemas o tablas, así que el rol no puede leer tus datos. Sí puede leer el texto de las consultas, que incluye sus literales (ver qué se guarda).

Después, prueba la conexión desde su tarjeta en el dashboard: Vericto comprueba la autenticación, el rol, el warehouse, la lectura del historial y, si lo activaste, ACCESS_HISTORY. Si la prueba pasa, la conexión queda activa.

Alternativa casi en tiempo real: INFORMATION_SCHEMA

En lugar de ACCOUNT_USAGE, la conexión puede leer la función INFORMATION_SCHEMA.QUERY_HISTORY() de una base de datos. No tiene la latencia de ingesta de ACCOUNT_USAGE, pero solo ve las consultas que el rol puede ver: las de su propio usuario y las de los warehouses donde tiene MONITOR. Concede USAGE sobre una base de datos (donde se llama a la función) y MONITOR sobre cada warehouse cuyas consultas quieras ver. MONITOR es de solo lectura.

GRANT USAGE ON DATABASE <database> TO ROLE VERICTO_HISTORY_ROLE;      -- where INFORMATION_SCHEMA.QUERY_HISTORY() is called
GRANT MONITOR ON WAREHOUSE <warehouse> TO ROLE VERICTO_HISTORY_ROLE;  -- one per warehouse whose queries you want to see

Rotar la clave. La rotación genera un par nuevo: la conexión vuelve a pendiente y las lecturas se detienen hasta que ejecutes ALTER USER VERICTO_HISTORY_SVC SET RSA_PUBLIC_KEY = '<new public key>' y la prueba pase. La posición de lectura se conserva, así que no se pierde historial.

Cómo se lee el historial

Cada conexión se lee en el intervalo que elijas: 15 o 30 minutos, o 1, 3 o 6 horas. La primera lectura empieza 24 horas atrás. Una conexión pausada retoma desde donde quedó, hasta 7 días atrás como máximo.

Latencia

  • ACCOUNT_USAGE.QUERY_HISTORY (por defecto): Snowflake tarda hasta 45 minutos en publicar una consulta en esa vista, así que Vericto lee solo las consultas que terminaron hace más de 1 hora.
  • Con ACCESS_HISTORY: su latencia es de hasta 3 horas, así que la espera sube a 3 h 15 min. Por eso viene desactivado.
  • INFORMATION_SCHEMA.QUERY_HISTORY(): sin latencia de ingesta; Vericto espera unos 2 minutos después de que la consulta termine. Cubre una ventana de 7 días, con un intervalo de 15 minutos o más. Si un tramo tiene más consultas de las que la función devuelve, la tarjeta avisa que la lectura quedó truncada.

Una fila que Snowflake publique más tarde que esos máximos documentados no se lee: es el costo de leer con una posición que siempre avanza.

Sin duplicados. Cada consulta se identifica por su QUERY_ID: una consulta ya guardada no se vuelve a evaluar ni a contar, aunque una lectura se interrumpa y se repita.

Lecturas acotadas. Páginas de 1.000 filas, como máximo 5.000 filas por lectura y 60 segundos por sentencia. Un atraso mayor se recupera en las lecturas siguientes (la próxima empieza al minuto) y la tarjeta muestra el retraso.

Qué se evalúa. Todas las sentencias terminadas, también las que fallaron (un DROP que falló por permisos sigue siendo un hallazgo), salvo los tipos sin riesgo: SHOW, DESCRIBE, USE, ALTER SESSION, SET/UNSET, BEGIN/COMMIT/ROLLBACK, EXPLAIN y los comandos de archivos de stage (LIST, GET, PUT, REMOVE). Las consultas en curso o en cola no se leen. Los textos de más de 65.536 caracteres se omiten y se cuentan. Las consultas del propio conector llevan QUERY_TAG = 'vericto-history-connector' y se excluyen.

Mismas reglas que en runtime. Cada lectura usa la misma configuración que la API de runtime para esa base: las reglas activas y sus ajustes por base, las columnas sensibles, la política de enforcement y la de errores de parseo, y las allowlists de agentes por usuario de base de datos: un USER_NAME de Snowflake con una allowlist en esta base se evalúa contra ella, con la base y el esquema de la consulta como contexto.

Linaje con ACCESS_HISTORY (Enterprise Edition). Con ACCESS_HISTORY activado, Vericto conoce las tablas y columnas que una consulta leyó realmente, también a través de vistas. Si una columna etiquetada como sensible aparece ahí y el análisis del SQL no la vio (por ejemplo, una vista sobre esa columna), se agrega al evento y se registra un hallazgo VERICTO-085 con la acción de la etiqueta como acción hipotética. Si no está disponible, la lectura sigue sin él, sin error y sin desactivar la conexión.

Qué se guarda y cómo se ve

Cada sentencia evaluada es un evento en Queries y en el Audit Trail, con la etiqueta Observado (historial). Para ver solo estos eventos, filtra la lista por source=observe_history.

  • Fecha: el END_TIME de la consulta, así que los gráficos la ubican cuando se ejecutó.
  • Usuario: el USER_NAME de Snowflake.
  • Decisión: la del motor, salvo que nada se guarda como bloqueado, porque nada se bloqueó. Un hallazgo cuya acción es bloquear se muestra como Se habría bloqueado y no cuenta en ningún contador, reporte, exportación de cumplimiento ni resumen de consultas bloqueadas.
  • Texto de la consulta: cifrado en reposo con la clave del workspace, como todos los eventos. En un workspace con telemetría sanitizada, se sanitiza antes de guardarse. Nunca va en las notificaciones ni en los logs.

Cuota. Cada sentencia observada cuenta en el volumen mensual de queries del plan, como la telemetría del proxy: un evento guardado es una query, sin duplicados. La tarjeta de la conexión muestra cuántas queries agregó el conector este mes. Si se agota la cuota de un plan con límite, el conector se pausa sin usar tu warehouse, conserva su posición y se reanuda solo (lo comprueba cada hora) cuando la cuota lo permite. Una pausa que hiciste tú no se levanta sola.

Notificaciones

Después de una lectura con hallazgos nuevos que Vericto habría bloqueado, cada destino en tiempo real cuyo filtro de severidad coincida recibe un resumen: «N hallazgos detectados después de la ejecución (historial de Snowflake)», con las reglas principales, las severidades y un enlace a las queries filtradas por source=observe_history. Nunca incluye el texto de las consultas. Los webhooks reciben type: query.observed.

Los destinos de resumen periódico (de 5 minutos a 1 día) no incluyen los hallazgos observados: cuentan consultas bloqueadas, y un evento observado nunca lo es. La campana del dashboard avisa una vez por lectura cuando hay un hallazgo crítico que se habría bloqueado, y cuando la conexión se desactiva por errores de autenticación. Más en Alertas y notificaciones.

Fallos y reintentos

  • Autenticación: tras 3 fallos seguidos, la conexión se desactiva y la campana lo avisa. Una prueba exitosa la reactiva.
  • Permisos: la tarjeta muestra el permiso que falta (el error nombra el objeto) y la lectura se reintenta más tarde.
  • Warehouse, tiempo de espera, red o límite de tasa: la lectura se reintenta más tarde. Si Vericto no puede evaluar, no guarda nada ni avanza su posición, y reintenta.

Los reintentos esperan cada vez más: el intervalo se duplica con cada fallo seguido, hasta 6 horas. Una lectura exitosa vuelve al intervalo normal.

Costo en Snowflake

El warehouse VERICTO_HISTORY_WH es tuyo y Snowflake te lo factura. Se reanuda en cada lectura: Snowflake cobra al menos 60 segundos por reanudación, más hasta 60 segundos de inactividad antes de suspenderse (AUTO_SUSPEND = 60). Un X-Small (1 crédito por hora) usado solo por Vericto cuesta como máximo unos 2 minutos por lectura, es decir, 1/30 de crédito.

IntervaloLecturas por díaCréditos por día (cota superior)
15 min96≈ 3,2
60 min24≈ 0,8
6 h4≈ 0,13

La tarjeta de la conexión muestra la estimación para el intervalo elegido; multiplícala por tu precio por crédito. Los créditos de cloud services de las consultas de metadatos suelen quedar dentro de la franquicia diaria del 10 % de Snowflake.

Políticas de red

El conector usa la SQL API de Snowflake por HTTPS, siempre contra https://<account>.snowflakecomputing.com. Si tu cuenta restringe las IP de los clientes con una política de red, permite la dirección IP de salida de Vericto. Pídela a soporte.

Desconectar

Desconectar en Vericto borra la conexión y su clave privada. Después, elimina los objetos de Snowflake:

USE ROLE ACCOUNTADMIN;
DROP USER IF EXISTS VERICTO_HISTORY_SVC;
DROP ROLE IF EXISTS VERICTO_HISTORY_ROLE;
DROP WAREHOUSE IF EXISTS VERICTO_HISTORY_WH;

Comparación con la API de runtime, MCP y la CLI

Conector de historialAPI de runtime / MCP / CLI
Bloquea o enmascaraNo, después de la ejecuciónSí, antes de la ejecución
Ve consultas de dentro de Snowflake (worksheets, Cortex, tasks, BI)Sí, de todos los usuarios (con ACCOUNT_USAGE)Solo lo que envía quien llama
Retraso1 a 3 h (ACCOUNT_USAGE), ~2 min (INFORMATION_SCHEMA)Ninguno
Linaje a través de vistasCon ACCESS_HISTORY (Enterprise Edition)No
Costo en SnowflakeTiempo de warehouse (ver costo)Ninguno
ConfiguraciónRol, usuario de servicio y warehouseUn cambio de código en cada cliente

Se complementan: el conector muestra lo que pasó en toda la cuenta, y la API de runtime, MCP y la CLI bloquean antes de la ejecución en los caminos que controlas.