Seguridad por diseño
La seguridad no depende de recordar una política. La plataforma aplica los límites.
Esta página explica, en términos más técnicos que el resto del sitio, cómo están construidos el modelo de acceso, los registros y la traza de auditoría de Nerida. Describe el diseño y la versión web actual. Los controles de producción se expresan en futuro hasta que se verifiquen en vivo.
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 y copias de seguridad en producciónAntes del uso real
El servicio en producción protegerá los datos en tránsito y en reposo y demostrará la restauración cronometrada de copias antes del uso real. Expresado en futuro hasta su verificación.
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.