Seguridad de Expediente Astrocyte

Este documento describe cómo Neuroglia protege la Plataforma Digital Expediente Astrocyte (la «Plataforma»): las reglas que seguimos, cómo detectamos y corregimos vulnerabilidades, cómo operamos la infraestructura y qué hacemos ante un incidente. Complementa el Aviso de Privacidad, que describe qué datos personales tratamos y con qué finalidad.

Para reportar una vulnerabilidad o un incidente de seguridad, escriba a [email protected] con el asunto «Seguridad». El detalle está en la sección 2.5.

1. Política de seguridad

1.1 Alcance

Esta política aplica a la aplicación web de la Plataforma, a su API, a las integraciones con terceros (como Zoom, Google Calendar y Stripe) y a la infraestructura en la nube que las ejecuta. La cumple toda persona con acceso al código o a los entornos de la Plataforma.

1.2 Principios

• Mínimo privilegio. Cada usuario, servicio y proceso recibe solo el acceso que su función necesita.
• Aislamiento por organización. Toda consulta de datos se limita a la organización del usuario. Un recurso de otra organización responde igual que uno inexistente.
• Trazabilidad. Las lecturas de información clínica y los cambios a ella quedan en un registro de auditoría que la aplicación no edita ni borra.
• Defensa en profundidad. Ningún control se considera suficiente por sí solo; la seguridad se verifica en cada etapa, desde el código hasta la operación.

1.3 Controles técnicos

• Cifrado en tránsito. Toda comunicación usa TLS 1.2 o superior; los dominios de la Plataforma rechazan TLS 1.0 y 1.1.
• Cifrado en reposo. La base de datos corre en MongoDB Atlas, que cifra el almacenamiento y los respaldos con AES-256. Los archivos se guardan en Cloudflare R2, que cifra los objetos en reposo. Además, la Plataforma cifra con AES-256-GCM los campos más sensibles, como los tokens de acceso a Zoom y Google Calendar, con un esquema de llave primaria y secundaria que permite su rotación planificada.
• Contraseñas. Se guardan con Argon2; nadie, incluido Neuroglia, puede leerlas en texto claro.
• Sesiones. Los tokens de acceso expiran en pocas horas y los tokens de renovación rotan en cada uso. Los intentos de inicio de sesión están limitados por dirección IP.
• Autorización. Cada petición pasa por una cadena de controles (autenticación, correo confirmado, rol, permisos delegados y suscripción) antes de llegar a los datos.
• Registros. Los registros técnicos de la aplicación se diseñan para no contener datos personales ni clínicos, y los errores se depuran de datos sensibles antes de enviarse al sistema de monitoreo. Un dato personal que aparezca en un registro se trata como vulnerabilidad.
• Integraciones. Las conexiones con Zoom y Google Calendar usan OAuth, así que la Plataforma nunca recibe ni guarda las contraseñas de esos servicios.

1.4 Desarrollo seguro

El desarrollo de la API sigue un ciclo de vida seguro organizado con el marco NIST SSDF (SP 800-218):

• Todo cambio entra a la rama principal por una solicitud de integración (pull request) y solo si pasan las verificaciones automáticas obligatorias.
• Esas verificaciones incluyen pruebas automatizadas, análisis estático de seguridad (SAST) con Semgrep, búsqueda de secretos con gitleaks y auditoría de dependencias.
• La búsqueda de secretos también corre en el equipo de cada desarrollador antes de crear un commit.
• Las rutas críticas (autenticación, aislamiento por organización, auditoría y datos clínicos) exigen pruebas automatizadas en cada cambio.

La aplicación web también integra cada cambio por solicitud de integración, con pruebas automatizadas y auditoría de dependencias obligatorias. Este sitio ejecuta pruebas y auditoría de dependencias en cada solicitud de integración.

2. Gestión de vulnerabilidades

2.1 Detección

Fuente	Frecuencia
Análisis estático (SAST) con Semgrep (API)	En cada solicitud de integración y cada semana sobre todo el código
Búsqueda de secretos con gitleaks (API)	En cada commit, en cada solicitud de integración y cada semana sobre todo el historial
Auditoría de dependencias con pnpm audit	En cada solicitud de integración de la API, la aplicación web y este sitio; en la API, también cada semana
Alertas de seguridad de dependencias (Dependabot)	Activas en la API y la aplicación web
Análisis dinámico (DAST) con OWASP ZAP contra el entorno de pruebas	Antes de cambios mayores y al menos cada trimestre
Reportes externos	Por el canal de la sección 2.5

2.2 Clasificación

Cada hallazgo se clasifica por severidad con CVSS (crítica, alta, media o baja), considerando si afecta datos clínicos o personales y si es explotable sin autenticación.

2.3 Plazos de corrección

Severidad	Plazo máximo para corregir o mitigar
Crítica	7 días naturales
Alta	30 días naturales
Media	90 días naturales
Baja	180 días naturales

El plazo corre desde que se confirma el hallazgo. Si una corrección definitiva requiere más tiempo, se aplica antes una mitigación que reduzca el riesgo y se documenta.

2.4 Seguimiento

Cada hallazgo confirmado se registra en el sistema de seguimiento de trabajo con su severidad y su plazo. Su corrección incluye una prueba automatizada que falla sin el arreglo, para que el problema no reaparezca.

2.5 Reporte responsable

Si encuentra una vulnerabilidad, escriba a [email protected] con el asunto «Seguridad» e incluya una descripción, los pasos para reproducirla y su impacto. Le pedimos:

• No acceder, modificar ni conservar datos de otras personas; use solo cuentas propias.
• No degradar el servicio ni realizar pruebas de denegación de servicio.
• No divulgar la vulnerabilidad hasta que esté corregida.

Confirmamos la recepción del reporte en un plazo de 3 días hábiles y le informamos cuando la corrección esté publicada. El archivo /.well-known/security.txt publica este mismo canal en el formato estándar RFC 9116.

3. Infraestructura y dependencias

3.1 Infraestructura

Componente	Proveedor
Aplicación web y API	Render
Base de datos	MongoDB Atlas
Archivos	Cloudflare R2
Pagos	Stripe

Producción y el entorno de pruebas están separados y usan credenciales distintas. El entorno de pruebas trabaja solo con datos sintéticos.

3.2 Despliegue

• Producción se despliega de forma manual y solo desde la rama principal protegida.
• Producción recibe exactamente la misma versión del código que se validó antes en el entorno de pruebas.
• La rama principal no admite reescritura del historial ni integración sin las verificaciones obligatorias.

3.3 Dependencias

• Las versiones de las dependencias quedan fijadas en un archivo de bloqueo, que la instalación respeta sin modificarlo.
• Una versión recién publicada no se instala de inmediato: la API exige 7 días de antigüedad y la aplicación web, 1 día. Así hay margen para que una versión maliciosa se detecte y retire antes de llegar a la Plataforma. Un parche de seguridad urgente puede exceptuarse de forma explícita y por versión.
• En la API, solo las dependencias autorizadas pueden ejecutar scripts durante la instalación.
• Las GitHub Actions se fijan por su SHA, y las imágenes de las herramientas de seguridad de la integración continua, por su digest, no por etiquetas que puedan cambiar.

3.4 Secretos

• Las credenciales viven en la configuración cifrada de cada proveedor, nunca en el código.
• Si una credencial se expone, se rota de inmediato en el proveedor; borrar el commit que la contenía no basta.

4. Gestión y respuesta a incidentes

4.1 Definición

Un incidente de seguridad es cualquier evento que comprometa o pueda comprometer la confidencialidad, integridad o disponibilidad de la Plataforma o de los datos que trata. Ejemplos: acceso no autorizado, exposición de credenciales, pérdida de datos o una vulnerabilidad explotada.

4.2 Responsable

El responsable de seguridad de Neuroglia coordina la respuesta a todo incidente y es el contacto para las organizaciones clientes y las autoridades. Se le contacta en [email protected].

4.3 Proceso

La respuesta sigue las fases de la guía NIST SP 800-61 Rev. 2:

1. Detección y análisis. Se confirma el incidente, se clasifica su severidad y se determina qué datos y qué organizaciones podrían estar afectados. Los registros de auditoría y el monitoreo de errores sirven de evidencia.
2. Contención. Se limita el daño: revocar sesiones o credenciales, desactivar la función afectada o bloquear el acceso comprometido.
3. Erradicación y recuperación. Se elimina la causa, se rotan las credenciales involucradas y se restablece el servicio con la corrección verificada.
4. Actividades posteriores. Se documenta qué ocurrió, por qué y qué se cambió para que no se repita. Toda corrección incluye una prueba automatizada.

4.4 Notificación

Respecto de los datos de pacientes, Neuroglia actúa como Encargado: notifica sin dilación indebida a la organización cliente, que es la Responsable, cualquier incidente que afecte de forma significativa esos datos, con la información disponible y las medidas tomadas, conforme a los Términos y Condiciones. Respecto de los datos de los propios usuarios de la Plataforma, de los que Neuroglia es Responsable, les informa sin demora en los términos de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente.

4.5 Evidencia

La aplicación conserva los registros de auditoría sin editarlos ni borrarlos, y no les aplica caducidad automática, lo que permite reconstruir quién accedió a qué información y cuándo durante la investigación de un incidente. Cualquier excepción operativa sobre esos registros se aprueba y documenta.