Las auditorías SOC 2 no son difíciles porque los controles sean complicados. Son difíciles porque la evidencia está dispersa. Las revisiones de acceso viven en su proveedor de identidad. Los detalles de cifrado están enterrados en configuraciones de infraestructura. Las evaluaciones de riesgo de proveedores están en hojas de cálculo. Los procedimientos de respuesta a incidentes existen en una wiki que no se ha actualizado desde la última auditoría. Los logs de auditoría están en una base de datos, pero nadie los ha agregado en el formato que su auditor quiere.
Cada trimestre, alguien pasa días extrayendo datos de seis sistemas diferentes, formateándolos en un informe y esperando que nada haya cambiado desde la última vez que verificaron.
El agregador de evidencia SOC 2 de JieGou elimina ese trabajo. Una llamada a la API devuelve un informe estructurado que cubre seis secciones de evidencia — obtenidas en paralelo desde datos en vivo de la plataforma, almacenadas en caché para rendimiento, y diseñadas para fallar graciosamente si alguna sección no está disponible temporalmente.
La estructura del informe
Una sola llamada GET /api/soc2-evidence?accountId=X devuelve el informe completo. Contiene nueve secciones organizadas alrededor de las categorías de evidencia que importan a los auditores SOC 2:
| Sección | Qué contiene | Fuente |
|---|---|---|
| Revisión de acceso | Roles por usuario, permisos, asignaciones departamentales, conteos de acceso a recursos, última actividad | Módulo de gobernanza + motor de permisos |
| Métricas de seguridad | Intentos de autenticación fallidos, IPs bloqueadas, salud de API keys, alertas de picos de uso | Analítica de seguridad |
| Inventario de cifrado | 10 controles de cifrado con algoritmos, tamaños de clave, alcance y detalles de gestión | Catálogo estático |
| Registro de proveedores | 11 proveedores terceros con niveles de riesgo, certificaciones y clasificaciones de acceso a datos | Catálogo estático |
| Respuesta a incidentes | 6 procedimientos en 4 fases con definiciones de severidad, SLAs y manuales paso a paso | Catálogo estático |
| Configuración de cumplimiento | Marcos de cumplimiento activos, reglas de residencia de datos, configuración de detección de PII | Configuración de cuenta |
| Residencia de datos | Modos de residencia por categoría (solo local, sincronización en la nube, nube redactada) | Configuración de cuenta |
| Política de retención | Período de retención de logs de auditoría y configuración | Configuración de cuenta |
| Resumen de log de auditoría | Conteo de eventos de 30 días, desglose por acción, top 10 actores por actividad | Firestore audit_logs |
El informe está versionado (1.0.0) y tiene marca de tiempo. Cada sección incluye su propia marca de tiempo generatedAt para que los auditores puedan ver exactamente cuándo se recopiló cada pieza de evidencia.
Revisión de acceso
La sección de revisión de acceso es en la que los auditores pasan más tiempo. JieGou la genera automáticamente a partir de datos en vivo de la plataforma.
Para cada usuario en su cuenta:
- Identidad — email, nombre para mostrar, ID de usuario
- Rol — rol global (Owner, Admin, Dept Lead, Member, Auditor, Viewer) con nivel numérico
- Departamentos — a qué departamentos pertenece el usuario
- Permisos — la lista completa de permisos granulares que su rol otorga (26 permisos en 8 categorías)
- Acceso a recursos — conteo de recetas y flujos de trabajo accesibles para este usuario
- Última actividad — marca de tiempo de la actividad más reciente del usuario
El informe también incluye distribución de roles — cuántos usuarios en cada nivel de rol — para que los auditores puedan verificar que la asignación de privilegios sigue el principio de mínimo privilegio.
El resumen de API keys completa la revisión de acceso: total de keys, qué proveedores LLM están configurados y detalles por key (proveedor, estado de validez, antigüedad). Los auditores pueden verificar que no existen keys obsoletas o huérfanas sin revisar una consola separada de gestión de keys.
Inventario de cifrado
El criterio CC6.1 de los Trust Services de SOC 2 requiere que las organizaciones documenten sus controles de cifrado. El inventario de cifrado de JieGou cataloga 10 controles que cubren datos en reposo y en tránsito:
| Control | Algoritmo | Alcance |
|---|---|---|
| Cifrado de clave BYOK | AES-256-GCM | API keys de clientes almacenadas en Firestore |
| Datos en reposo de Firestore | AES-256 | Todas las colecciones de Firestore |
| Firma de cookie de sesión | RS256 (JWT) | Cookies de sesión de Firebase Auth |
| Almacenamiento de contraseñas | bcrypt / scrypt | Hashes de contraseñas de usuarios |
| TLS — Istio Gateway | TLS 1.3 | Todo el tráfico HTTPS a *.jiegou.ai |
| TLS — Servicios Firebase | TLS 1.3 | Tráfico API de Firestore y Auth |
| TLS — Clúster Redis | TLS 1.2+ | Conexiones de caché Redis |
| Hash de frescura de documentos | SHA-256 | Detección de cambios en documentos URL |
| Hash de clave de caché de sesión | SHA-256 | Claves de caché de sesión en Redis |
| Verificación de imagen de contenedor | SHA-256 | Digests de imágenes Docker en ECR |
Cada control incluye el tamaño de clave, quién lo gestiona (JieGou, Google Cloud, AWS, Firebase), el módulo fuente en el código base, y si cubre datos en reposo, en tránsito, o ambos. Esto no es una afirmación de marketing — es un inventario legible por máquina que se mapea directamente a su infraestructura.
Registro de proveedores
La gestión de proveedores terceros es un requisito de SOC 2. El registro de proveedores de JieGou cataloga 11 proveedores con evaluaciones de riesgo estructuradas:
Para cada proveedor:
- Nivel de riesgo — crítico, alto, medio o bajo
- Estado de certificación SOC 2 — si el proveedor posee SOC 2 Type II
- Otras certificaciones — ISO 27001, FedRAMP, PCI DSS, HIPAA y otras
- Acceso a datos — qué datos puede acceder y procesar el proveedor
- Mitigaciones — controles específicos que reducen el riesgo para este proveedor
- Programa de revisión — fecha de última revisión y fecha de próxima revisión
Los proveedores van desde crítico (GCP, AWS, Firebase Auth — alojan sus datos) hasta medio (Resend para email, Redis para caché). Los proveedores LLM (Anthropic, OpenAI, Google AI) se clasifican como alto — procesan los prompts de los clientes transitoriamente, pero el soporte BYOK y las políticas de no-entrenamiento mitigan el riesgo.
El registro incluye mitigaciones específicas por proveedor, no declaraciones genéricas. Para Stripe: “Certificado PCI DSS Level 1 — los datos de tarjeta nunca tocan los servidores de JieGou.” Para Redis: “Modo solo caché (persistencia deshabilitada) — sin PVs.” Estos son los detalles que buscan los auditores.
Manual de respuesta a incidentes
SOC 2 CC7.3 y CC7.4 requieren procedimientos documentados de respuesta a incidentes. El manual incluye 6 procedimientos en 4 fases:
Fase 1: Detección y triaje (todas las severidades) — Confirmar la alerta, clasificar severidad P1-P4, crear un canal de incidentes, preservar evidencia inicial.
Fase 2: Contención — Tres procedimientos específicos por severidad:
- Brecha de datos (P1) — Identificar cuentas afectadas, deshabilitar usuarios comprometidos, rotar API keys, vaciar cachés de sesión, preservar logs de auditoría, notificar a clientes dentro de 72 horas según GDPR
- Acceso no autorizado (P1) — Revocar sesiones, deshabilitar cuentas, verificar bloqueo de IP, ejecutar revisión de acceso, investigar movimiento lateral
- Interrupción de servicio (P2) — Verificar circuit breakers, failover a proveedores LLM alternativos, verificar fallo abierto de Redis, publicar actualizaciones de estado al cliente
Fase 3: Erradicación y recuperación (P1-P3) — Análisis de causa raíz, despliegue de corrección, verificación en producción, restauración del servicio.
Fase 4: Post-mortem (P1-P2) — Revisión sin culpas dentro de 48 horas, compilación de cronología del incidente, seguimiento de acciones correctivas.
Cada paso del procedimiento incluye la parte responsable (Ingeniero de guardia, Líder de seguridad, Ingeniero de infraestructura), SLA en minutos, herramientas específicas a usar (no categorías genéricas — nombres de módulos y comandos reales), y disparadores de escalación para cuando la situación empeora.
Las definiciones de severidad tienen SLAs explícitos de tiempo de respuesta: P1 Crítico en 15 minutos, P2 Alto en 1 hora, P3 Medio en 4 horas, P4 Bajo en 24 horas.
Resumen de log de auditoría
El resumen del log de auditoría agrega los últimos 30 días de actividad en dos vistas:
Desglose por acción — conteos por tipo de acción. Cuántas ejecuciones de recetas, ejecuciones de flujos de trabajo, cambios de rol, operaciones de API key, actualizaciones de configuración y otros eventos auditables ocurrieron en el período. Esto le dice a los auditores qué está sucediendo en la plataforma y si los patrones de actividad lucen normales.
Principales actores — los 10 usuarios más activos por conteo de eventos. Los auditores usan esto para verificar que las cuentas de alta actividad correspondan a usuarios esperados (cuentas de servicio de automatización, usuarios avanzados) en lugar de comportamiento anómalo.
El resumen está limitado a 1,000 eventos para rendimiento. Para cuentas con volúmenes más altos, el log de auditoría crudo siempre está disponible a través del módulo de gobernanza.
Cómo está construido
El informe de evidencia se genera obteniendo en paralelo las nueve secciones simultáneamente usando Promise.all. Seis secciones provienen de consultas en vivo (revisión de acceso, métricas de seguridad, configuración de cumplimiento, residencia de datos, política de retención, resumen de log de auditoría). Tres son catálogos estáticos (inventario de cifrado, registro de proveedores, manual de respuesta a incidentes).
Diseño de fallo abierto. Cada sección dinámica está envuelta en un manejador .catch(). Si el servicio de métricas de seguridad no está disponible temporalmente, el informe aún devuelve las otras ocho secciones pobladas y la sección fallida llena con valores predeterminados seguros. El informe siempre devuelve — nunca falla por completo porque un subsistema está lento.
Caché en Redis. El informe completo se almacena en caché por 5 minutos. Durante una auditoría, múltiples miembros del equipo pueden solicitar el mismo informe repetidamente. El almacenamiento en caché previene consultas redundantes a Firestore y mantiene los tiempos de respuesta consistentes.
Acceso por sección. No siempre necesita el informe completo. Agregue ?section=access-review para obtener solo la revisión de acceso, o ?section=encryption-inventory para solo el catálogo de cifrado. Seis secciones son individualmente accesibles: access-review, security-metrics, encryption-inventory, vendor-register, incident-response, audit-log-summary.
Modelo de permisos
El endpoint requiere el permiso audit:read, que se mapea al rol Auditor (nivel 15) o superior. Esto significa:
- Auditor, Dept Lead, Admin, Owner — pueden obtener el informe
- Member, Viewer — no pueden acceder a él
Esto se alinea con el principio de mínimo privilegio. Su equipo de cumplimiento puede generar evidencia sin necesitar acceso de administrador. Los miembros de su equipo de ingeniería, que pueden ejecutar flujos de trabajo y editar recetas, no obtienen visibilidad del informe de postura de seguridad a menos que su rol lo justifique.
Disponibilidad
La recopilación de evidencia SOC 2 está disponible en planes Enterprise. Incluye la API completa de informe de evidencia, acceso individual por sección, revisiones de acceso, inventario de cifrado, registro de proveedores, manual de respuesta a incidentes y resúmenes de logs de auditoría. Conozca más sobre las funcionalidades enterprise o inicie una prueba.