Seguridad

Vericto 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

Vericto 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.

Cómo funciona el AST parsing

El core de Vericto 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. Vericto lo usa para MySQL, Oracle, SQL Server (T-SQL), Snowflake y SQLite. 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:

Flujo de datos del proxy TCP

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

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 Vericto (localhost:5433).
2. El proxy, que corre en tu infraestructura, abre la conexión con tu base de datos real usando el connection string que le configuras localmente. Vericto no recibe ni almacena ese connection string.
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 Vericto están cifrados en reposo y en tránsito:

• Connection strings: Vericto no los recibe ni los almacena: se configuran en el proxy, dentro de tu infraestructura.
• 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: se guardan como hash SHA-256 de una clave aleatoria de 256 bits; la clave en texto plano se muestra una sola vez, al crearla. Las contraseñas se guardan con bcrypt.
• Tránsito: HTTPS obligatorio con TLS 1.2 o superior en todas las conexiones HTTP (TLS 1.3 con cualquier cliente moderno) y TLS 1.2+ en las conexiones TCP del proxy. HSTS con includeSubDomains en todos los dominios de Vericto.

Autenticación y autorización

Vericto 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), enviadas en la cabecera X-API-Key sobre TLS. Las keys se emiten y revocan desde el dashboard; en CI se recomienda inyectarlas como secretos, o usar OIDC (GitHub Actions) para intercambiar un token efímero por una key ci_dryrun:execute sin almacenar credenciales de larga duración.

El modelo de autorización es RBAC (Role-Based Access Control) con 4 roles de usuario: owner, admin, member y viewer. Las API keys de CI/CD no son un rol de usuario: se autentican con scopes acotados (por ejemplo ci_dryrun:execute). 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.

Auditorías SOC 2 e ISO 27001

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

Cada export del audit trail, y su reporte PDF de cumplimiento, se firma con Ed25519. Con la clave pública de Vericto, los auditores verifican de forma independiente y sin conexión que el archivo no cambió desde que se generó. Los clientes Enterprise reciben además un reporte firmado cada mes. Más detalle en Evidencia para auditorías.

Para clientes Enterprise, Vericto ofrece soporte directo durante auditorías y revisiones de seguridad.

Certificación de Vericto: Vericto está en proceso de certificación SOC 2. Todavía no contamos con un informe SOC 2 ni con la certificación ISO 27001. Si tu revisión de seguridad necesita más información, escríbenos a security@vericto.com.

Reporte de vulnerabilidades

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

Envía tu reporte a security@vericto.com 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.