El problema de la evidencia en SOC2 Type II
Una auditoría SOC2 Type II no evalúa si tienes controles de seguridad — evalúa si esos controles funcionaron de forma consistente durante un periodo (normalmente 6 a 12 meses). Esto significa que necesitas evidencia documentada de cada control en operación, no solo su existencia.
Para los controles de acceso a datos, esto se traduce en una pregunta concreta que los auditores hacen una y otra vez: "demuéstrame que ninguna operación destructiva no autorizada tocó tu base de datos de producción durante el periodo de auditoría."
Sin una capa de proxy con logging, responder esto requiere reconstruir evidencia a partir de logs de Postgres, logs de aplicación, y registros de despliegue — un proceso manual, propenso a errores y que rara vez cubre el periodo completo.
El 60% del tiempo de preparación de una auditoría SOC2 se va en recopilar y correlacionar evidencia que ya debería estar centralizada. El audit trail de Vetro elimina ese trabajo para los controles de acceso a datos.
Qué registra el audit trail de Vetro
Cada query que pasa por el proxy de Vetro genera un registro inmutable en el audit trail. El registro incluye:
- Timestamp con precisión de microsegundos (UTC)
- Texto completo de la query cifrado con AES-256-GCM en reposo
- Hash SHA-256 de la query para indexación sin exponer el contenido
- Decisión — PERMITIDA, BLOQUEADA, o PERMITIDA-EXCEPCIÓN
- Regla activada (si aplica) con código VETRO-XXX y severidad
- Nodo AST infractor para queries bloqueadas
- Identidad del workspace y base de datos
- Latencia de parsing medida
Un registro de ejemplo en formato JSON exportado:
{
"event_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"timestamp": "2026-04-15T02:14:33.847291Z",
"workspace_id": "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
"database": "prod-db",
"decision": "BLOCKED",
"rule_code": "VETRO-001",
"severity": "critical",
"ast_node_path": "DeleteStmt > WhereClause = NULL",
"query_sha256": "e3b0c44298fc1c149afbf4c8996fb924...",
"estimated_rows_affected": 847293,
"latency_ms": 1.3,
"hmac_signature": "9f86d081884c7d659a2feaa0c55ad015..."
}Por qué es inmutable y por qué importa
La inmutabilidad es lo que convierte un log en evidencia. Si un registro puede ser modificado o eliminado después de su creación, un auditor no puede confiar en él como prueba de lo que ocurrió.
El audit trail de Vetro garantiza inmutabilidad con dos mecanismos:
- Append-only a nivel de aplicación. No existe ningún endpoint en la API de Vetro que permita modificar o eliminar registros individuales del audit trail. Los registros solo se pueden crear y leer.
- Firma HMAC-SHA256 por registro. Cada registro incluye una firma HMAC del contenido, calculada con una clave scoped por workspace. Cualquier modificación posterior invalida la firma, lo que es detectable inmediatamente.
Al exportar el audit trail, Vetro incluye una firma HMAC-SHA256 del archivo completo. El auditor puede verificar independientemente que el export no fue modificado desde su generación, usando la clave pública de verificación que Vetro proporciona.
Qué criterios SOC2 satisface directamente
Los Trust Services Criteria de SOC2 incluyen controles específicos que el audit trail de Vetro cubre como evidencia directa:
| Criterio | Descripción | Cómo lo satisface Vetro |
|---|---|---|
CC6.1 |
Controles de acceso lógico a datos | El audit trail documenta cada acceso de escritura y su decisión de bloqueo/permiso |
CC6.3 |
Gestión de acceso a información sensible | Las reglas custom permiten bloquear operaciones en tablas sensibles con registro completo |
CC7.2 |
Monitoreo de actividad anómala | Las alertas en tiempo real de bloqueos CRITICAL documentan la detección de anomalías |
CC7.3 |
Evaluación de eventos de seguridad | Cada query bloqueada incluye el nodo AST infractor y la severidad para evaluación |
Cómo exportar evidencia para el auditor
El plan Team y superiores permiten exportar el audit trail completo en CSV o JSON. Desde el dashboard o via CLI:
vetro audit export \
--workspace ws_6ba7b810 \
--from 2025-07-01 \
--to 2026-06-30 \
--format json \
--output soc2-evidence-2026.json
✓ 4,827,193 eventos exportados
✓ Firma HMAC-SHA256: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b...
✓ Clave de verificación: https://vetro.dev/verify/ws_6ba7b810El archivo exportado incluye todos los eventos del periodo de auditoría con sus firmas individuales y una firma agregada del archivo completo. El auditor puede:
- Verificar la firma agregada contra la clave pública de tu workspace
- Filtrar por decisión BLOCKED para ver todas las operaciones destructivas prevenidas
- Confirmar que las reglas CRITICAL estuvieron activas durante todo el periodo
- Correlacionar eventos con timestamps para reconstruir cualquier incidente
Retención por plan
SOC2 Type II requiere típicamente evidencia de un periodo de 6 a 12 meses. La retención del audit trail varía por plan:
- Free: 7 días — insuficiente para SOC2, adecuado para evaluación
- Builder: 30 días
- Team: 90 días
- Enterprise: configurable — típicamente 12+ meses para cubrir el periodo completo de auditoría
Para auditorías SOC2 Type II, recomendamos el plan Enterprise con retención configurada al periodo de auditoría más un margen de seguridad. Alternativamente, puedes exportar periódicamente el audit trail a tu propio almacenamiento de largo plazo manteniendo las firmas HMAC para preservar la verificabilidad.
Para clientes Enterprise, Vetro puede proporcionar reportes de compliance personalizados con el formato específico que requiera tu auditor, además del acceso directo a los logs de infraestructura durante el periodo de auditoría.
Más allá de SOC2: ISO 27001 y GDPR
El mismo audit trail satisface requisitos de otros marcos de compliance:
- ISO 27001 — el control A.12.4 (Logging y monitoreo) y A.9.4 (Control de acceso a sistemas) se satisfacen con el registro inmutable de accesos a datos
- GDPR — el Artículo 30 (Registro de actividades de tratamiento) y el Artículo 32 (Seguridad del tratamiento) se apoyan en la evidencia de controles de acceso a datos personales
La ventaja de usar AST parsing determinístico para esto es la certificabilidad: puedes afirmar a un auditor que "el sistema bloquea determinísticamente cualquier DELETE sin WHERE clause" — una afirmación verificable y reproducible, no una probabilidad estadística.