Seguridad por diseño
La seguridad no depende de recordar una política. La plataforma aplica los límites.
El detalle técnico que respalda la página de Confianza: cómo se decide el acceso, cómo se registra cada consulta de los datos y cómo los registros conservan su historia. Describe el diseño y la versión web actual, que funciona con datos ficticios hasta que se complete la revisión independiente.
Seis reglas de diseño
- La identidad viene del inicio de sesión verificado, nunca de la solicitud
- Quién actúa se toma del testigo de sesión autenticado. Nada en el cuerpo o la dirección de una solicitud puede cambiar quién cree el servidor que es usted.
- Denegar por defecto, en cada solicitud
- Cada solicitud se comprueba contra el rol de la persona, su relación asistencial con el paciente y el permiso concreto concedido. Una ruta nueva nace cerrada. Ocultar un botón nunca es la protección.
- El acceso se registra antes de mostrar nada
- Una lectura de información clínica escribe primero su registro de auditoría. Si ese registro no puede escribirse, la información no se devuelve. La traza de auditoría es de solo anexado y la aplicación no puede editarla ni borrarla.
- Los roles operativos no tienen camino clínico
- El acceso de los asistentes existe solo a través de una asignación activa y de comprobaciones de permiso en cada solicitud. Las vistas de asistente se construyen como estructuras de datos separadas y deliberadamente limitadas, nunca recortando un registro clínico.
- Los registros conservan su historia
- Las notas clínicas se corrigen anexando; nada se sobrescribe en silencio. La eliminación pasa primero por el archivado, y la conservación y el borrado legales se gestionan como un proceso propio y revisado, nunca con un botón cualquiera.
- Los grupos pequeños permanecen ocultos
- Los informes agregados sobre pocas personas se tratan como información identificable. Los recuentos muy pequeños se ocultan en el servidor antes de enviar el informe, de modo que el cliente nunca los recibe.
Una solicitud
Qué ocurre cuando alguien abre un registro
Un médico abre el registro de un paciente. El servidor confirma primero quién es a partir de la sesión, después confirma una relación asistencial activa con ese paciente y luego comprueba la acción concreta. Solo entonces se registra la lectura, y solo después de registrarla se devuelve el registro.
Un recurso que la persona no puede ver devuelve «no encontrado», no «prohibido», para que no se pueda sondear la existencia de registros. Los mismos pasos se aplican a cada camino secundario: listas, historias, resúmenes y solicitudes de cambio vuelven a comprobar el límite de forma independiente.
- Identidad confirmada desde la sesión verificada
- Relación asistencial con este paciente confirmada
- Permiso concreto para esta acción comprobado
- Acceso registrado, o no se devuelve nada
- Registro devuelto, con las notas privadas ocultas según el rol
En la versión actual
- Acceso parametrizado a la base de datos
Cada consulta usa parámetros vinculados; una comprobación de compilación falla ante SQL construido en línea. Las entradas de texto libre tienen longitud máxima.
- Rol de base de datos con privilegios mínimos
La aplicación se conecta con un rol que puede leer y escribir datos pero no cambiar el esquema.
- Límites de frecuencia en rutas sensibles
Las rutas de inicio de sesión, registro e invitación llevan límites más estrictos por dirección.
- Cabeceras de seguridad y políticas estrictas
La API y la aplicación web envían cabeceras restrictivas de política de contenido y de encuadre. El cliente web no carga código de analítica ni de publicidad de terceros.
- Archivos verificados de extremo a extremo
Los archivos subidos se inspeccionan por contenido y se les calcula un resumen criptográfico; las descargas se registran y fallan de forma segura. Quien no puede verlos recibe «no encontrado».
- Se niega a arrancar mal configurada
Un despliegue de tipo producción se niega a iniciarse con autenticación de desarrollo, un secreto por defecto o una conexión a la base de datos sin cifrar.
- Probada para los fallos que importan
Cada camino de lectura incluye pruebas de denegación de acceso y de ocultación; las pruebas de condiciones de carrera siguen un patrón de exactamente un ganador para citas, invitaciones y retirada de permisos.
- Cifrado, con alojamiento en la UE
Nerida Health cifra los datos en tránsito y en reposo, alojados en la UE (Fráncfort). Las conexiones requieren TLS 1.2 o posterior.
- Mensajes cifrados dos veces
Además del cifrado en reposo, el texto de los mensajes se cifra con una clave distinta para cada conversación.
- Sin acceso clínico para administradores
Los administradores de la plataforma no pueden abrir datos clínicos. El acceso de soporte requiere el consentimiento del usuario, caduca y nunca permite al personal actuar como si fuera el usuario.
- Comprobado en cada compilación
Cada cambio se analiza en busca de dependencias vulnerables y secretos filtrados, y las imágenes de contenedor se analizan antes de publicarse.
- Probado con entradas inesperadas
Cada noche se ejecutan pruebas de fuzzing, pruebas basadas en propiedades y pruebas de mutación.
- Análisis de malwareAntes de usar datos reales de pacientes
Los archivos subidos quedan sin abrir hasta que se analizan; el servicio de análisis se está implantando.
- Prueba de penetración independienteAntes de usar datos reales de pacientes
Ya está contratada y se completará antes de manejar cualquier dato real de pacientes.
- Restauración de copias de seguridad demostradaAntes de usar datos reales de pacientes
Antes de tratar cualquier dato real de pacientes, se ensaya y se registra una restauración cronometrada a partir de una copia de seguridad.
Antes del uso real
El diseño no es una prueba
Todo lo anterior describe cómo está construida la plataforma y qué hace la versión web actual con datos ficticios. Antes de tratar cualquier dato real de pacientes, el servicio desplegado pasa por una prueba de intrusión independiente, una revisión clínica y una revisión jurídica, y los controles de producción se verifican en vivo.
Los investigadores de seguridad que actúan de buena fe son bienvenidos a comunicar hallazgos; la política de divulgación explica cómo y qué esperar.
¿Preguntas sobre el diseño?
Los médicos, los investigadores de seguridad y los responsables de TI de las clínicas pueden pedir el detalle necesario para evaluar el diseño.