141 lines
7.2 KiB
Markdown
141 lines
7.2 KiB
Markdown
# 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. | |