diff --git a/BACKLOG.md b/BACKLOG.md index 12d8e0a..cc3492b 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -7,6 +7,19 @@ ## Seguridad +### [SEC-002] Sprint de compliance & seguridad +- **Estado:** Diferido — pendiente de priorizar tras Sprint 4 +- **Contexto:** COMPLIANCE.md documenta el estado actual de seguridad (v2.1.0) y el roadmap + de hardening. Antes de escalar a más empresas o datos reales, se requiere un sprint dedicado. +- **Ítems principales (ver COMPLIANCE.md secciones 5 y 6):** + - Registro de auditoría append-only (log inmutable de operaciones sensibles) + - Hashing SHA-256 de integridad de respuestas (detección de tampering sin blockchain) + - Cifrado en reposo a nivel de volumen/disco de la base de datos + - Roadmap de hardening por capas: aplicación, autenticación, datos, infraestructura, + observabilidad y proceso (revisión periódica de CVEs, pen testing) +- **Dependencia:** no bloquea Sprint 4; sí bloquea escalar a producción masiva. +- **Ver:** `COMPLIANCE.md` secciones 5 y 6. + ### [SEC-001] Actualizar Next.js — CVE pendiente en 15.3.3 - **Estado:** Pendiente - **Prioridad:** Alta diff --git a/COMPLIANCE.md b/COMPLIANCE.md new file mode 100644 index 0000000..7d9ba98 --- /dev/null +++ b/COMPLIANCE.md @@ -0,0 +1,141 @@ +# 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-20 · 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. + +--- + +## 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. | \ No newline at end of file