Definiciones
- Zero Trust
- Enfoque de seguridad que asume que ninguna solicitud es confiable por defecto y exige verificación continua de identidad, contexto y autorización.
- Incidente de Seguridad
- Evento que compromete o amenaza de forma significativa la confidencialidad, integridad o disponibilidad de la información o de la Plataforma.
- DR / BCP
- Recuperación ante desastres (Disaster Recovery) y continuidad del negocio (Business Continuity Planning).
Alcance
Esta Política describe el marco de seguridad aplicable a Conciencia Sánate y a la suite Elynthis. Se alinea a buenas prácticas de ISO/IEC 27001 e ISO/IEC 27701 como referencia de gestión, y a salvaguardas técnicas inspiradas en HIPAA, sin afirmar certificación formal por este documento.
Aplica a sistemas productivos, entornos de administración, integraciones (Supabase, Cloudflare, Resend, OpenAI, Stripe, Google, Apple) y al personal o contratistas con acceso a información.
Artículo 1
Modelo Zero Trust
- Autenticación fuerte y sesiones con expiración.
- Autorización por rol y contexto (organización, vínculo clínico, permiso).
- Segmentación lógica de datos mediante RLS y APIs controladas.
- Registro y monitoreo de eventos relevantes.
- Mínimo privilegio para soporte y administración.
- Verificación continua ante cambios de riesgo (nuevos dispositivos, patrones anómalos).
Artículo 2
HTTPS y TLS
El tráfico de Usuarios hacia la Plataforma se protege con HTTPS y TLS. Se deshabilitan protocolos inseguros en la medida de las capacidades de la infraestructura y CDN (Cloudflare).
Artículo 3
Cifrado
- Cifrado en tránsito para comunicaciones de aplicación.
- Cifrado en reposo en servicios de infraestructura que lo soporten.
- Protección de secretos (variables de entorno, claves de servicio) fuera del código cliente.
- Hashes e integridad para evidencias de consentimientos y firmas cuando aplique.
Artículo 4
Control de acceso
El acceso a datos clínicos y administrativos se otorga según necesidad de conocer. Los Administradores deben revisar periódicamente usuarios activos. El acceso de soporte se limita, se registra y se revoca al cesar la necesidad.
Artículo 5
RLS (Row Level Security)
Elynthis emplea políticas RLS en Supabase/PostgreSQL para impedir que un Usuario lea o modifique filas ajenas. Las operaciones privilegiadas se ejecutan solo desde backends controlados con claves de servicio protegidas.
Artículo 6
Backups
Se realizan respaldos periódicos de bases de datos y, según diseño, de almacenamiento de archivos. Los backups tienen acceso restringido y se prueban en ejercicios de restauración cuando el programa de continuidad lo programe.
Artículo 7
Registro de auditoría
Se registran eventos de seguridad y trazas de acceso/cambio relevantes para investigación, cumplimiento y soporte. La alteración o desactivación no autorizada de auditoría está prohibida.
Artículo 8
Logs
Los logs técnicos (aplicación, borde Cloudflare, autenticación, errores) se usan para operación y seguridad. Se evita registrar secretos o datos clínicos innecesarios en texto claro.
Artículo 9
Recuperación ante desastres
El programa de DR contempla restauración desde backups, failover según capacidades del proveedor cloud, comunicación a Usuarios afectados y priorización de módulos clínicos críticos (agenda, HCE, teleconsulta) en la medida técnicamente posible.
Artículo 10
Notificación de incidentes
- Detección y clasificación del incidente (confidencialidad, integridad, disponibilidad).
- Contención, erradicación y recuperación.
- Evaluación de impacto a Titulares y Responsables.
- Notificación a afectados y autoridades cuando la ley o el riesgo lo exijan, en plazos razonables.
- Lecciones aprendidas y refuerzo de controles.
Canal de reporte: seguridad@concienciasanate.com. Los Usuarios deben reportar sospechas de acceso indebido de inmediato.
Artículo 11
Disponibilidad
Se monitorea la disponibilidad del servicio y de dependencias críticas. Los mantenimientos se programan para minimizar impacto. Los compromisos de SLA específicos, si existen, constan en contratos institucionales o planes comerciales.
Artículo 12
Desarrollo y operación seguros
- Revisión de cambios con impacto en seguridad (RLS, auth, exportaciones clínicas).
- Separación razonable de entornos.
- Gestión de vulnerabilidades y dependencias.
- Encabezados de seguridad HTTP en el front (por ejemplo, frame denial, nosniff, referrer policy).
Artículo 13
Responsabilidades de los Usuarios
- Custodiar credenciales y dispositivos.
- No desactivar controles de seguridad locales.
- Usar redes razonablemente seguras en teleconsulta.
- Reportar incidentes y retiros de personal con acceso.
Anexos
Anexo A
Mapa de controles (resumen)
| Dominio | Control principal en Elynthis |
|---|---|
| Identidad | Auth Supabase / OAuth Google-Apple, sesiones |
| Autorización | Roles + RLS |
| Red | HTTPS/TLS + Cloudflare |
| Datos | Minimización, cifrado, Retención legal |
| Operación | Logs, backups, incident response |
| Privacidad | Alineación ISO 27701 como referencia |