Seguridad por diseño, no por defecto.

Vetro está construido sobre el principio de que la seguridad no puede depender de decisiones correctas en tiempo de ejecución. El AST parsing es determinístico. El cifrado es obligatorio. El audit trail es inmutable. No hay modo inseguro.

Arquitectura zero-trust

Vetro opera bajo el principio de zero-trust: ninguna query es confiable por defecto, independientemente de su origen. Cada query interceptada por el proxy es analizada desde cero, sin estado previo, sin caché de decisiones, sin excepciones implícitas.

Sin bypass implícito

No existe un modo de bypass silencioso. Si el proxy de Vetro no puede alcanzar la base de datos o falla internamente, la query recibe un error explícito — nunca pasa sin verificar.

Least privilege por defecto

Las 4 reglas CRITICAL (DELETE sin WHERE, UPDATE sin WHERE, DROP, TRUNCATE) están activas por defecto en todos los workspaces. Desactivarlas requiere acción explícita de un administrador.

Audit trail inmutable

Cada decisión de bloqueo o permiso queda registrada con timestamp, query completa (cifrada), nodo AST, regla activada y latencia. Los registros no pueden ser modificados ni eliminados por usuarios.

Multi-región

El proxy de Vetro está desplegado en múltiples regiones con failover automático. Los datos se almacenan en la región que configures — sin transferencias cross-region por defecto.

Cómo funciona el AST parsing

El core de Vetro es un parser AST (Abstract Syntax Tree) determinístico implementado en Rust. Utiliza dos librerías de parsing SQL de referencia:

  • pg_query: binding de libpg_query, el parser oficial de PostgreSQL. El mismo código que usa el motor de PostgreSQL internamente para parsear queries. Garantía de compatibilidad 100% con el dialecto Postgres.
  • sqlparser-rs: parser SQL multi-dialecto en Rust con soporte para MySQL, SQLite, Snowflake y otros dialectos. Mantenido activamente por la comunidad de Apache Arrow.

El proceso de evaluación de una query ocurre en tres fases, todas en el mismo proceso Rust sin llamadas de red:

Proceso de evaluación AST — <2ms p99

1

Parsing del árbol sintáctico

La query SQL en texto plano es parseada por pg_query o sqlparser-rs según el dialecto configurado. El resultado es un AST completo en memoria — un árbol de nodos tipados que representa la estructura semántica de la query.

2

Evaluación del ruleset

El motor de reglas recorre el AST en profundidad buscando nodos que violen las reglas activas del workspace. Las reglas estándar son condiciones AST predefinidas (ej: UpdateStmt.where_clause == NULL). Las reglas custom son condiciones YAML compiladas a predicados sobre el AST.

3

Decisión y respuesta

Si ninguna regla es violada, la query es forwarded a la base de datos real. Si al menos una regla es violada, se genera una respuesta de error con el nodo AST infractor, el código de regla, la severidad, y la query segura sugerida. La decisión es registrada en el audit trail de forma asíncrona.

Flujo de datos del proxy TCP

El proxy de Vetro opera a nivel de protocolo TCP, por debajo de cualquier ORM o driver. Intercepta el protocolo de wire de PostgreSQL y MySQL directamente.

Vetro nunca almacena los resultados de tus queries — solo el texto de la query, los metadatos de la decisión, y el nodo AST infractor (si aplica). Los datos de respuesta de la base de datos pasan directamente al cliente sin ser almacenados.

El flujo de datos completo para una query interceptada:

  1. El driver/ORM de tu aplicación abre una conexión TCP al proxy de Vetro (proxy.vetro.dev:5432).
  2. El proxy establece una conexión upstream a tu base de datos real usando el connection string que configuraste (almacenado cifrado con AES-256-GCM).
  3. Cada query enviada por tu aplicación es interceptada a nivel de protocolo de wire. El texto de la query es extraído y enviado al parser AST.
  4. El parser AST evalúa la query en <2ms. Si es segura, la query es forwarded a la base de datos real sin modificación. Si es destructiva, se genera una respuesta de error.
  5. El evento (query, decisión, metadatos) es registrado en el audit trail de forma asíncrona — fuera del path crítico.

Cifrado y almacenamiento

Todos los datos sensibles en Vetro están cifrados en reposo y en tránsito:

  • Connection strings: cifrados con AES-256-GCM usando claves derivadas por workspace (HKDF sobre una clave maestra). Nunca almacenados en texto plano.
  • Texto de queries en el audit trail: cifrado con AES-256-GCM. El hash SHA-256 de la query se usa para indexación y deduplicación sin exponer el contenido.
  • Webhook signing secrets: cifrados con claves scoped por workspace.
  • API keys: almacenadas como hashes bcrypt. La clave en texto plano solo se muestra una vez en el momento de creación.
  • Tránsito: TLS 1.3 para todas las conexiones HTTP. TLS 1.2+ para conexiones TCP del proxy. HSTS con preload en todos los dominios de Vetro.

Autenticación y autorización

Vetro usa un modelo de autenticación en dos capas:

  • Dashboard y API REST: JWT con expiración de 24h almacenado en httpOnly cookie. Refresh token con rotación en cada uso. Todas las sesiones son revocadas al cambiar la contraseña.
  • CLI y CI/CD: API keys con scope limitado (ci_dryrun:execute). Las API keys se autentican con Bearer token + firma HMAC-SHA256 de la request con timestamp (ventana de 5 minutos para prevenir replay attacks).

El modelo de autorización es RBAC (Role-Based Access Control) con 5 roles: owner, admin, member, viewer, y api_key_ci. Los permisos se verifican en el middleware de la API y, como defensa en profundidad, en las políticas de Row Level Security de la base de datos.

Rate limiting: 100 requests/minuto por IP para endpoints de autenticación. 5 intentos fallidos de login en 10 minutos resultan en bloqueo de 15 minutos.

Compliance SOC2/ISO27001

El audit trail de Vetro está diseñado para ser evidencia directa en auditorías de seguridad:

SOC2 Type II (en proceso)
GDPR compliant
Audit trail exportable
Firma HMAC-SHA256 en exports

Cada export del audit trail incluye una firma HMAC-SHA256 del contenido del archivo. Los auditores pueden verificar que el export no ha sido modificado desde su generación. El formato JSON del export es compatible con el schema de evidencia de SOC2.

Para clientes Enterprise, Vetro puede proporcionar: reportes de compliance personalizados, acceso a logs de infraestructura, y soporte directo durante auditorías.

Reporte de vulnerabilidades

Si descubres una vulnerabilidad de seguridad en Vetro, te pedimos que nos lo comuniques de forma responsable antes de divulgarlo públicamente.

Envía tu reporte a security@vetro.dev con:

  • Descripción detallada de la vulnerabilidad
  • Pasos para reproducirla
  • Impacto potencial estimado
  • Tu nombre o alias (opcional, para crédito público si lo deseas)

Nos comprometemos a responder en menos de 48 horas y a publicar un fix en menos de 30 días para vulnerabilidades críticas. No tomaremos acciones legales contra investigadores que reporten vulnerabilidades de buena fe.