Ciberseguridad para un backend Laravel de exámenes médicos

Una plataforma de exámenes médicos gestiona información que, si se filtra, tiene consecuencias reales: resultados de analíticas, identificadores de pacientes y datos de contacto. Este caso cuenta cómo se aseguró su backend —PHP con Laravel, MySQL y Apache— a partir de una auditoría de seguridad previa, sin detener la plataforma ni cambiar la forma de trabajar del laboratorio.

No es un caso de desarrollo de funciones nuevas, sino de cambiar las reglas del sistema: qué puede ver cada rol, cómo se guardan los datos sensibles y cómo se demuestra después quién consultó qué. Por acuerdo de confidencialidad no se publica el nombre del cliente ni capturas de la aplicación; los dos diagramas resumen las decisiones técnicas.

El reto: un sistema en producción con datos que no pueden filtrarse

La plataforma llevaba tiempo funcionando y el equipo dominaba el negocio: recepción, laboratorio y administración trabajaban sobre ella a diario. El problema no era de uso, sino de diseño. El sistema había crecido por acumulación y nadie había revisado con criterio de seguridad ni el modelo de permisos ni la forma de almacenar los datos.

Permisos definidos por costumbre, no por un modelo

Los accesos se habían ido concediendo según hacía falta, así que varios perfiles internos podían consultar información que no necesitaban para su trabajo. Sin un modelo de roles declarado tampoco era fácil saber quién debía poder ver un resultado y quién no: la respuesta estaba en la memoria del equipo, no en el sistema.

Información sensible guardada sin cifrar

La base de datos y las copias de seguridad conservaban datos identificativos de pacientes en claro. Cualquier acceso indebido al servidor, a una copia o a un volcado de la base de datos exponía directamente la información: no había una segunda barrera que la protegiera.

Sin registro de quién consultaba cada resultado

Consultar un informe no dejaba rastro centralizado. Si alguien accedía a un resultado que no le correspondía, no había forma de reconstruirlo a posteriori, y eso es precisamente lo que se pide en una auditoría o ante la reclamación de un paciente.

La solución: cifrado, roles y trazabilidad

Antes de escribir código se decidió qué información es sensible de verdad y qué necesita cada perfil para hacer su trabajo. Con ese mapa se rediseñó el modelo de permisos y se añadieron dos capas nuevas: el cifrado de los datos y el registro de auditoría. La aplicación sigue siendo la misma —Laravel sobre Apache, con MySQL—, pero ahora cada petición pasa por un control de acceso explícito.

Cifrado en reposo y en tránsito

Los datos identificativos sensibles se guardan cifrados, también en las copias de seguridad, y todo el tráfico viaja por HTTPS de extremo a extremo. El cifrado se aplica por capas —primero el canal, después el almacenamiento—, de forma que un descuido en una capa no deje la información expuesta en la siguiente.

Un permiso por responsabilidad, no por persona

Cada perfil —recepción, laboratorio, administración y paciente— recibe los permisos mínimos que necesita. El control de acceso por roles se comprueba en el servidor, en cada petición, y no en la interfaz: aunque alguien construyera una petición a mano, la aplicación respondería igual con una denegación si su rol no autoriza ese dato.

Trazabilidad: cada consulta deja registro

El sistema anota quién consultó cada resultado, con fecha, recurso e IP, en un registro de solo anexado: la aplicación escribe, pero no puede editar ni borrar entradas. Es la prueba que permite reconstruir un acceso meses después y, sobre todo, la que hace que nadie consulte un dato sin dejar rastro.

Cómo lo implementamos sin parar el servicio

El backend estaba en producción y no se podía detener: hay pacientes esperando resultados todos los días. El plan fue por capas y con vuelta atrás preparada, probando siempre primero sobre una copia de la base de datos y de la aplicación.

Mapa de datos y prioridades

Se identificó dónde vive cada dato sensible, quién lo usa y qué ocurriría si se filtrara. Con esa prioridad se decidió qué cifrar primero y qué permisos ajustar sin interferir en el trabajo diario del laboratorio.

Cambios por capas, con vuelta atrás preparada

Primero HTTPS en todo el sitio, después el cifrado de los datos sensibles y de las copias, y por último la reorganización de roles. Cada paso se probó sobre una copia antes de aplicarlo en producción, con una ventana breve de mantenimiento para el despliegue.

Verificación antes de dar el visto bueno

Cada cambio se comprobó con dos preguntas: ¿el usuario correcto sigue pudiendo hacer su trabajo?, ¿y el incorrecto ya no puede? Además se revisaron dependencias, credenciales y configuración del servidor, que es donde suelen aparecer los huecos que nadie mira.

Resultados

La plataforma sigue funcionando igual para quien la usa a diario, pero ahora el acceso a los datos sensibles es explícito, está cifrado y queda registrado. Estos son los cambios respecto al punto de partida que detectó la auditoría:

El resultado que más valoramos no es una cifra, sino poder responder con datos a una pregunta incómoda: quién ha consultado el resultado de un paciente concreto y cuándo. Eso ahora se responde en segundos, y ese es el 100% de los datos sensibles que la plataforma guarda cifrados.

Qué revisar si tu sistema maneja datos de salud

Estos son los puntos que, en nuestra experiencia, marcan la diferencia entre «tener permisos» y tener el acceso realmente controlado:

• Roles declarados, no improvisados. Cada perfil debe tener por escrito qué datos necesita, y el sistema debe comprobarlo en el servidor en cada petición.
• Cifrado en las dos direcciones. En reposo (base de datos y copias) y en tránsito. Si solo hay una de las dos, un descuido puntual deja los datos a la vista.
• Un registro de auditoría que no se pueda reescribir. Debe anotar quién, qué, cuándo y desde dónde, y la propia aplicación no debería poder modificarlo ni borrarlo.
• Copias de seguridad cifradas y probadas. Una copia que nunca se ha restaurado no es una copia: es una carpeta con ilusiones.
• Dependencias y servidor al día. Muchas brechas no entran por una puerta que hayas construido, sino por una pieza antigua que nadie actualizó.

Si tu plataforma guarda datos de pacientes y no puedes responder a estas preguntas con seguridad, en la página de ciberseguridad contamos cómo trabajamos, y si prefieres el caso concreto puedes escribirnos y lo revisamos contigo.

Preguntas frecuentes

¿Cómo se protegen los datos sensibles de los pacientes?

Con cifrado en reposo —los datos se guardan cifrados en la base de datos y en las copias de seguridad— y cifrado en tránsito, porque todo el tráfico viaja por HTTPS. El acceso no depende de la contraseña de cada persona: cada rol tiene permisos concretos y toda consulta queda registrada.

¿Qué es el control de acceso por roles y por qué es clave en un sistema de salud?

Es un modelo en el que el permiso depende del rol —recepción, laboratorio, administración o paciente— y no del criterio de cada persona. En una plataforma de exámenes evita que alguien vea resultados que no le corresponden: quien publica un informe no tiene por qué poder leer el historial completo de un paciente.

¿Se puede aplicar a un sistema que ya está en producción?

Sí, y es lo habitual. Se parte de un mapa de datos para saber dónde está la información sensible, se cifra por capas sin cortar el servicio, se reorganizan los permisos y todo se prueba primero sobre una copia de la base de datos antes de tocar producción.

¿Qué se revisa en una auditoría de seguridad de un backend médico?

Autenticación y gestión de sesiones, permisos por rol, cifrado en reposo y en tránsito, gestión de credenciales y secretos, copias de seguridad y su restauración, registro de auditoría de los accesos, y actualización tanto de las dependencias como del propio servidor.