Seguridad y despliegue

Autenticación por credenciales con política de contraseña y contraseñas con hash. Multifactor de contraseña de un solo uso basada en tiempo (TOTP) con códigos de recuperación de un solo uso, bloqueo por cuenta tras fallos repetidos y re-autenticación reforzada (step-up) aplicada en servidor para acciones sensibles.

Ámbito: El multifactor se exige para roles privilegiados (administrativos) y puede requerirse por institución; está disponible y es activable por todos los usuarios, pero no se fuerza globalmente en cada cuenta.

Tokens de acceso de corta duración con tokens de refresco rotatorios y revocación en servidor: una acción administrativa (suspensión, revocación de dispositivo, bloqueo de institución, cierre de todas las sesiones) invalida las sesiones activas en la siguiente petición sin esperar a la expiración. La reutilización de un token de refresco se detecta y revoca la familia de tokens.

Ámbito: Se aplica a todas las sesiones autenticadas.

Los dispositivos nuevos requieren aprobación administrativa explícita antes de emitir una sesión, y pueden revocarse en cualquier momento (la revocación termina las sesiones y queda auditada). Los dispositivos pueden probar la posesión de una clave privada en el inicio de sesión, con TLS mutuo opcional; la fuerza del vínculo se gradúa con honestidad y los acompañantes móviles reciben una sesión de solo lectura y alcance limitado.

Ámbito: La prueba criptográfica de dispositivo en el inicio de sesión está soportada y es configurable por nivel de despliegue; no está activada por defecto en todos los niveles.

La autorización se aplica en servidor como comprobaciones de permisos en cada ruta — no ocultando elementos de interfaz. Un modelo cerrado de rol-a-permiso aplica mínimo privilegio, los datos por institución/tenant se aíslan en la capa de datos y de permisos, y las denegaciones de acceso se registran. El acceso entre tenants por roles de plataforma o auditoría queda registrado explícitamente en la traza de auditoría.

Ámbito: Los roles incluyen operador de laboratorio, revisor autorizado, administrador institucional y auditor de solo lectura.

Desarrollo, staging y producción se ejecutan en cuentas cloud separadas con almacenes de datos, almacenamiento y distribuciones independientes. Guardas a nivel de código impiden que modos exclusivos de desarrollo (semillas de demo, ejecutores simulados, dispositivos auto-confiados) se ejecuten en producción y detectan discrepancias de recursos entre entornos.

Ámbito: Se aplica en toda la plataforma.

El tráfico público se sirve solo por HTTPS (el HTTP se redirige), con un perfil TLS moderno (TLS 1.2 o superior) y un certificado gestionado, y se aplica HTTP Strict Transport Security en producción.

Ámbito: Se aplica al sitio público y a la API de la aplicación.

Los almacenes de datos de aplicación y el almacenamiento de objetos están cifrados en reposo con claves gestionadas, la base de datos está cifrada, y el material de claves del servidor se guarda en un almacén de claves o secretos gestionado — nunca en texto plano en disco ni en el navegador.

Ámbito: Se aplica a los datos de aplicación gestionados y al almacenamiento de objetos.

Los buckets de almacenamiento bloquean todo acceso público y solo son accesibles a través de la capa de entrega de contenido con un control de acceso al origen; la base de datos no es accesible públicamente. El almacenamiento de objetos nunca es navegable desde internet.

Ámbito: Se aplica al almacenamiento web y de aplicación.

Los secretos de los workloads se suministran desde un almacén de secretos gestionado en el arranque, nunca se escriben en logs, y el servicio falla de inmediato si falta un secreto o es un marcador. El repositorio incorpora escaneo automático de secretos y comprobaciones pre-commit, y los artefactos publicados no contienen secretos.

Ámbito: La inyección gestionada de secretos se aplica a los workloads de staging y producción; la rotación sigue un procedimiento documentado con herramientas de preflight.

El sitio web público y el correo ordinario no son canales autorizados para muestras, secuencias, archivos genómicos, identificadores de muestras ni datos de pacientes. Cualquier evaluación con datos se realiza a través de un canal y condiciones acordados con VBS.

Ámbito: Se aplica a todas las superficies de contacto públicas.

Cada ejecución conserva el contexto técnico necesario para revisión y reproducibilidad: un identificador de ejecución y timestamps, entorno y versión de pipeline/app, digest de la imagen de contenedor, hashes de workflow, versiones del contrato de resultado y de bases de datos/referencias, hashes y estado de los artefactos de entrada y salida, el actor y dispositivo iniciadores, el estado de ejecución y los warnings, y un registro explícito de cualquier campo que no pudo determinarse — anotado como ausente, nunca inventado.

Ámbito: Se aplica a cada ejecución de análisis.

Los eventos relevantes de seguridad pasan por un único escritor validado y se registran como una cadena de hashes criptográfica por tenant y de solo adición, de modo que cualquier modificación, borrado o reordenación es detectable por un verificador independiente. Los tipos de evento y los metadatos se restringen a una lista permitida no personal, y las lecturas se limitan por rol.

Ámbito: Se aplica a los eventos relevantes de seguridad.

Endpoints de salud y liveness, logging estructurado y correlacionado por petición con una vista interna limitada por rol que redacta datos personales, y un catálogo de alertas técnicas vinculadas a playbooks de guardia.

Ámbito: Monitorización técnica; guiada por alertas con playbooks de guardia.

La base de datos gestionada tiene copias de seguridad automáticas con una ventana de retención definida y no es accesible públicamente. Los procedimientos de restauración están documentados y se ejercitan periódicamente con un ensayo no destructivo.

Ámbito: El mecanismo de copia está implementado; la verificación continua y firmada de la restauración está en validación.

Un conjunto mantenido de runbooks de respuesta a incidentes etiquetados por severidad (pipeline, API, base de datos, almacenamiento, rotación de secretos, hallazgos de amenaza, rollback de despliegue), validados estructuralmente en integración continua, junto con remediación automatizada de determinados hallazgos de amenaza en cloud.

Ámbito: Los runbooks están documentados y validados en CI; los ejercicios de incidente de extremo a extremo están pendientes.

El sitio público envía cabeceras de respuesta de refuerzo — HTTP Strict Transport Security, anti-framing, sin MIME sniffing y una política de referrer prudente — y el entorno de staging está marcado como no indexable.

Ámbito: Se aplica al sitio web público.

Se está desplegando una Content Security Policy que restringe desde dónde pueden cargarse scripts, estilos, fuentes, imágenes y conexiones — aplicada y verificada primero en staging y después en producción.

Ámbito: Se aplica al sitio web público; despliegue a producción tras verificación en staging.

NextGenAMR se ejecuta actualmente como un servicio de cloud gestionado operado por VBS sobre AWS, con la responsabilidad operativa, las actualizaciones, el manejo de secretos, el logging y las copias de seguridad gestionados por VBS. Otros modelos de despliegue no se ofrecen como opciones genéricas; el diseño de despliegue, las responsabilidades y el tratamiento de datos se revisan durante una evaluación institucional.

Ámbito: La única modalidad de despliegue actual.