motor-de-encuestas/COMPLIANCE.md

COMPLIANCE.md — Cumplimiento, seguridad y auditabilidad

Documento vivo. Área: Compliance & Seguridad del producto "Datos País sobre el Cuidado". Audiencia: dirección técnica, auditores externos, equipo legal, clientes (resumen). Última actualización: 2026-06-24 · Versión del producto: 2.1.0 (prod) / 3.0.0 (desarrollo)

---

1. Principio rector de seguridad

No existe un sistema "imposible de hackear". El objetivo es defensa en profundidad: encarecer progresivamente el ataque, minimizar la superficie expuesta, contener el daño si una capa cae, y garantizar trazabilidad para detectar, auditar y reconstruir cualquier incidente. Toda afirmación de inviolabilidad absoluta se considera, en sí misma, una señal de inmadurez en seguridad.

---

2. Naturaleza de los datos y marco normativo

2.1 Clasificación de datos

• Datos sensibles (salud, discapacidad): preguntas marcadas is_sensitive=true (Sección de prevalencia, condición propia y de familiares).
• Cuasi-identificadores: departamento, ciudad, sector, rango etario, género.
• Dato confidencial restringido: franja salarial (analyst-only, nunca en vistas de empresa).
• NO se recogen identificadores directos: sin nombre, documento, email ni teléfono en la encuesta anónima. La encuesta es anónima por diseño.

2.2 Marco normativo aplicable (Paraguay)

• Ley N° 6534/2020 de Protección de Datos Personales Crediticios y normativa de datos personales aplicable en Paraguay.
• Principios alineados a estándares internacionales (minimización, finalidad, consentimiento).
• Pendiente de revisión legal formal con el equipo de Fundación Solidaridad / asesoría legal.

2.3 Consentimiento

• Registrado en tablas consent_records + consent_versions con versión y timestamp.
• Doble propósito separado y autorizable independientemente: diagnóstico interno de empresa (requerido) y estudio país (opcional).
• Por ser anónima, la encuesta no permite revocación post-envío (no hay forma de localizar una respuesta individual) — comunicado explícitamente al participante en el consentimiento.

---

3. Anonimato y protección contra reidentificación

3.1 k-anonimato (k ≥ 5)

• Regla no negociable del sistema: ningún corte de datos con menos de 5 respuestas se muestra.
• Implementado en las RPCs del dashboard (SECURITY DEFINER), no en el frontend.
• Estados de supresión: suppressed con n real solo a nivel agregado.

3.2 Separación de datos sensibles

• Franja salarial (3.4 / 8.4 según versión): nunca expuesta en vistas de empresa ni en /admin/responses.
• Política RLS deny_sensitive a nivel de base de datos.
• Vista de control /admin/responses excluye is_sensitive=true y text_long a nivel de query, no de presentación (los valores no llegan al servidor).

---

4. Seguridad — estado actual (v2.1.0)

4.1 Implementado

• Cifrado en tránsito: TLS/SSL vía Kong + Traefik (Let's Encrypt) en db.inqualityhq.com y economia-cuidado.inqualityhq.com.
• Soberanía del dato: Supabase self-hosted en infraestructura propia (VPS controlado), no en nube de terceros. Decisión arquitectónica fundacional.
• RLS (Row Level Security): políticas activas en tablas sensibles; el rol anon solo puede insertar respuestas, no leer datos de otros.
• Service role aislado: la clave de servicio nunca llega al bundle del cliente (verificado: vistas server-side, no Client Components con la key).
• Gestión de vulnerabilidades: CVE-2025-66478 resuelto (Next.js 15.3.8, pin exacto).
• Backups: GFS local (3 días diarios + domingos 14 días), restore probado.
• Aislamiento de red: Studio de administración solo accesible vía SSH tunnel, no expuesto.

4.2 Deuda de seguridad registrada (ver TECH_DEBT.md)

• TECH-DEBT-006: backup remoto S3 — sin réplica off-site, riesgo ante pérdida del VPS. Bloqueante antes del primer dato real de empresa.
• TECH-DEBT-008: /admin/responses sin autenticación — mitigado por URL no publicada, pero requiere gate de auth antes de exponer.
• TECH-DEBT-009: rotación de secrets Supabase post-CVE — pendiente.
• SEC-004 (ver BACKLOG.md): el submit v3 (rpc_submit_response, Etapa 4G) cerró el INSERT directo de anon sobre consent_records/responses/answers (antes WITH CHECK(true)). La RPC valida estructura en SQL; la coherencia de flujo (visibilidad, instancias legítimas) se valida en TypeScript antes de llamarla — quien la invoque directo por REST puede evadir esa segunda capa. No es un riesgo de privacidad (el dato sigue anónimo y sujeto a k-anonimato), es de calidad de datos de investigación.

---

5. Auditabilidad y trazabilidad (roadmap)

Objetivo: ante una auditoría o un incidente, poder responder "quién accedió a qué, cuándo, y demostrar que un registro no fue alterado".

5.1 Pendiente de diseño e implementación (BACKLOG — sprint de compliance)

• Registro de auditoría append-only: log inmutable de operaciones sensibles (accesos a datos sensibles, cambios de configuración, ejecución de migraciones).
• Hashing de integridad (SHA-256): hash de los registros de respuesta para demostrar no-alteración, encadenable para detección de tampering. Provee el beneficio probatorio de inmutabilidad SIN los costos de blockchain.
• Cifrado en reposo: cifrado a nivel de volumen/disco de la base de datos.
• Trazabilidad de cambios de datos: tablas de historial con triggers, o aprovechamiento del WAL de PostgreSQL para reconstrucción temporal.

5.2 Por qué NO blockchain (decisión registrada)

Blockchain aporta valor cuando se requiere registro inmutable verificable entre partes que NO confían entre sí, sin autoridad central legítima. En este sistema la confianza está legítimamente centralizada (InQuality es responsable y operador soberano del dato), por lo que blockchain no resuelve ningún problema real que no esté mejor resuelto por audit logs + hashing. Además, su inmutabilidad absoluta entra en CONFLICTO con el derecho de rectificación y supresión exigido por la normativa de protección de datos. Se descarta por inadecuación técnica y normativa, no por desconocimiento.

---

6. Roadmap de hardening de seguridad (a evaluar en sprint de compliance)

Defensa en profundidad — capas a evaluar e implementar gradualmente.

• Capa de aplicación: validación y sanitización de inputs, protección contra inyección (parametrización ya usada vía PostgREST/Supabase), rate limiting en endpoints públicos, headers de seguridad (CSP, HSTS, X-Frame-Options).
• Capa de autenticación: gate de auth para vistas administrativas, rotación de secretos, gestión de sesiones robusta cuando se introduzcan roles autenticados.
• Capa de datos: cifrado en reposo, RLS exhaustivo, principio de mínimo privilegio en roles.
• Capa de infraestructura: firewall, fail2ban, actualizaciones de SO, monitoreo de intrusiones, segmentación de red.
• Capa de observabilidad: logs centralizados, alertas ante patrones anómalos, registro de auditoría (sección 5).
• Proceso: revisión periódica de dependencias (npm audit), gestión de CVEs, pruebas de penetración antes de escalar a producción masiva.

---

7. Responsabilidades

• Responsable del dato: InQuality (operador de infraestructura y autoridad del dato).
• Aliado institucional: Fundación Solidaridad.
• Revisión legal: pendiente de formalizar con asesoría legal especializada en protección de datos en Paraguay.

---

8. Historial de revisiones de este documento

Fecha	Versión producto	Cambio
2026-06-20	2.1.0 / 3.0.0-dev	Creación inicial. Estado de seguridad v2.1.0, roadmap de auditabilidad, decisión sobre blockchain.
2026-06-24	2.1.0 / 3.0.0-dev	Etapa 4G: submit v3 vía RPC SECURITY DEFINER, cierra INSERT directo de anon. Registra SEC-004 (riesgo residual de bypass vía REST, ver BACKLOG.md).