¿Por qué no se puede abordar la seguridad en la nube en el sector sanitario como si se tratara de la seguridad en la nube habitual de las empresas?

¿En qué se diferencia la seguridad de los datos sanitarios de la seguridad empresarial estándar?

La seguridad de los datos sanitarios está sujeta a una serie de consideraciones de seguridad que rara vez se plantean en los debates habituales sobre privacidad y seguridad empresarial. Una gran cantidad de requisitos normativos estrictos, los datos personales que no pueden duplicarse ni sustituirse y la salud del paciente como consecuencia directa son factores que contribuyen a que las obligaciones de proteger los datos sanitarios no se parezcan a las de ningún otro marco de seguridad genérica en la nube.

¿En qué sentido la información sanitaria protegida (PHI) es especialmente sensible?

La información sanitaria protegida (PHI) se encuentra en un nivel de sensibilidad distinto al del resto de los datos empresariales de una organización. El Departamento de Salud y Servicios Humanos (DHHS) define la PHI como información sanitaria identificable individualmente que se refiere al estado de salud física o mental pasado, presente o futuro de una persona, a la prestación de asistencia sanitaria o al pago de dicha asistencia.

Una tarjeta de crédito puede invalidarse una vez que se descubre la intrusión, con la posterior emisión de una nueva tarjeta. No ocurre lo mismo con las enfermedades, los factores genéticos o los diagnósticos de salud mental: esos datos son verdaderamente permanentes.

Siempre que la PHI se ve comprometida, los riesgos que plantean estas filtraciones van mucho más allá del simple robo de identidad. Los historiales médicos pueden utilizarse para excluir a los pacientes de la cobertura del seguro, interferir en sus oportunidades laborales y cometer fraudes dirigidos contra personas mayores y personas con discapacidad. La confidencialidad de la PHI se ve aún más acentuada por la amplitud de la información que puede calificarse como PHI.

Estos son los ejemplos más destacados:

• Nombre completo e información de contacto vinculados a una afección o tratamiento
• Fechas de nacimiento, ingreso, alta o fallecimiento
• Datos geográficos a un nivel inferior al estatal
• Identificadores biométricos, como huellas dactilares o huellas vocales
• Cualquier otro número o código identificativo único asociado a la atención sanitaria

¿Por qué la confidencialidad, la integridad y la disponibilidad tienen un peso diferente en el sector sanitario?

La confidencialidad, la integridad y la disponibilidad (a veces denominadas la «tríada CIA») se aplican a todos los protocolos de seguridad. Sin embargo, los entornos de nube del sector sanitario tienden a considerar estos pilares de forma diferente a como se hace en las implementaciones empresariales habituales.

Por ejemplo, la disponibilidad conlleva consecuencias clínicas significativas a partir de simples interrupciones del servicio que no tienen parangón en ningún otro sector. La pérdida de servicio no supone simplemente una pérdida de productividad en los entornos sanitarios, sino que impide la realización de pedidos de medicación, bloquea el acceso a los resultados de pruebas de imagen o impide que los paramédicos consulten el historial clínico del paciente.

A continuación se ofrece información más general sobre los tres pilares mencionados anteriormente:

¿Cómo influye la necesidad de conservación a largo plazo y de auditabilidad en los requisitos de seguridad?

Los historiales médicos y la documentación de seguridad asociada deben conservarse durante un periodo mucho más largo que los plazos habituales de conservación de datos de las empresas.

HIPAA (Ley de Portabilidad y Responsabilidad del Seguro Médico) establece que las entidades sujetas a su aplicación deben conservar sus políticas y procedimientos, así como los registros relacionados, durante 6 años a partir de la fecha de creación o de la última fecha de vigencia. Ese plazo podría ser incluso más largo en determinados estados en lo que respecta a tipos específicos de registros.

Los controles de seguridad en la nube que respaldan y protegen dichos datos también deben mantenerse durante ese mismo período de tiempo. Estos controles deben ser aplicables, auditables y recuperables durante todo el plazo de seis años.

Dichos requisitos influyen en el diseño general de la arquitectura de seguridad en la nube del sector sanitario. La gestión de claves para el cifrado, los registros de acceso y la integridad de las copias de seguridad: ninguno de estos aspectos puede tratarse simplemente como una cuestión operativa a corto plazo. Un registro de auditoría que sirva de apoyo en la investigación de una brecha de seguridad, o en una investigación regulatoria dentro de cinco años, dependerá de los controles que se implementen y gestionen en la actualidad.

¿Cómo modifican el cumplimiento normativo y las regulaciones sanitarias los requisitos de seguridad en la nube?

Las obligaciones normativas en el sector sanitario no son solo un marco adicional para la seguridad en la nube. Estas obligaciones también implican cambiar qué controles se exigen, quién es responsable de ellos y qué ocurriría si fallaran. La HIPAA, el RGPD, la ley HITECH y una lista cada vez mayor de normativas estatales imponen cada una sus propias exigencias (técnicas y contractuales) a los entornos en la nube, para las que los marcos de cumplimiento empresarial estándar no fueron diseñados.

¿Qué obligaciones específicas imponen la HIPAA, el RGPD y otras normativas sanitarias al uso de la nube?

Cada marco normativo importante tiene su propia perspectiva en lo que respecta a la seguridad en la nube:

• La HIPAA abarca la información médica protegida (PHI) almacenada en las entidades cubiertas con sede en EE. UU. y sus socios comerciales; esto incluye también las soluciones en la nube que almacenan, procesan y transmiten datos sensibles de pacientes en su nombre.
• El RGPD se aplica a situaciones en las que están implicados los datos sanitarios de residentes de la UE, incluso si la infraestructura de almacenamiento en la nube se encuentra en otro lugar.
• La ley HITECH amplía y refuerza las capacidades de aplicación de la HIPAA, aumentando los niveles de sanciones al tiempo que amplía los requisitos de notificación obligatoria de las violaciones de seguridad.

Las obligaciones que cada marco impone al entorno en la nube difieren significativamente entre sí en cuanto a alcance, mecanismo y consecuencias:

¿En qué se diferencian los plazos y el alcance de las notificaciones de violaciones de datos en el caso de las organizaciones sanitarias?

Las notificaciones de violaciones de datos relacionadas con la información sanitaria son, además, mucho más estrictas (y con mayores riesgos) que las que se aplican en la mayoría de los sectores empresariales. Los plazos son fijos, los destinatarios de la notificación son diversos y los umbrales que activan los distintos requisitos de notificación son muy específicos:

• 60 días: plazo máximo de que dispone una entidad sujeta a la HIPAA para notificar a las personas afectadas tras descubrir una filtración
• 60 días: el mismo plazo se aplica a la notificación al Departamento de Salud y Servicios Humanos de EE. UU. (HHS)
• Más de 500 personas afectadas: activa la obligación de notificar a los principales medios de comunicación del estado o jurisdicción afectados
• Menos de 500 personas: se puede registrar y comunicar al HHS anualmente, pero la notificación individual sigue siendo obligatoria en un plazo de 60 días
• RGPD: exige la notificación a la autoridad de control competente en un plazo de 72 horas desde que se tenga conocimiento de la violación de datos, y a las personas afectadas sin demora indebida cuando exista un riesgo elevado
• Leyes estatales: varios estados imponen plazos más cortos que los 60 días de la HIPAA; algunos exigen la notificación en un plazo de 30 días o menos

Todos estos plazos se complican aún más cuando se trata de entornos en la nube. Cada vez que la información médica protegida (PHI) se distribuye entre diferentes proveedores de servicios en la nube, regiones o servicios de terceros, identificar el alcance total de una violación de datos (para una notificación precisa) lleva mucho más tiempo que en entornos locales controlados.

¿Por qué el sector sanitario exige una validación más estricta del cumplimiento normativo en la nube?

La mayor debilidad de una validación rigurosa del cumplimiento normativo en la nube dentro del sector sanitario es que ninguna certificación de cumplimiento existente se ajusta directamente a los requisitos normativos específicos de la sanidad, y la suposición de equivalencia puede estar exponiendo a su organización a un riesgo significativo por lagunas normativas.

Por ejemplo, cuando un proveedor de servicios en la nube cuenta con una certificación SOC 2 Tipo II o una acreditación ISO 27001, cumple con unos requisitos mínimos de seguridad reconocidos. Al mismo tiempo, ninguno de estos marcos se creó teniendo en cuenta la información médica protegida (PHI), la necesidad de accesibilidad clínica ni las medidas de seguridad técnicas de la HIPAA.

Una validación más estricta en los entornos de nube del sector sanitario implica ir más allá de las revisiones habituales de las certificaciones. Esto incluye:

• Verificar que los acuerdos de negocio (BAA) reflejen con precisión las prácticas reales de tratamiento de datos del proveedor
• Asegurarse de que las configuraciones de los registros de auditoría cumplan tanto los requisitos de retención de la HIPAA como los estatales
• Verificar si las implementaciones de cifrado cubren la información médica protegida (PHI) en reposo, en tránsito y, especialmente, durante su procesamiento

¿Por qué la seguridad del paciente es una preocupación de seguridad que el departamento de TI suele pasar por alto?

La mayoría de los sectores sufren pérdidas económicas, pérdida de datos o daños a su reputación debido a una brecha de seguridad. Sin embargo, los problemas de seguridad en el sector sanitario pueden causar lesiones directas al paciente. Esta distinción por sí sola altera de manera fundamental la forma en que se priorizan y gestionan las decisiones sobre seguridad en la nube.

¿Por qué deben las organizaciones sanitarias proteger los datos de los pacientes para garantizar una atención segura?

La disponibilidad constante de los datos de los pacientes es indispensable para la atención clínica. Las repercusiones de cualquier incidencia en un entorno en la nube (una brecha de seguridad, una interrupción del servicio o un caso de corrupción de datos) se extienden inmediatamente mucho más allá del departamento de TI. Esto incluye:

• Que los médicos pierdan el acceso a los historiales de medicación
• Que el personal de enfermería ya no pueda acceder a los planes de cuidados activos
• Que los equipos de urgencias se vean obligados a tomar decisiones sin tener en cuenta el contexto diagnóstico esencial

El hecho de que pueda acceder a los datos de los pacientes y de que disponga de datos válidos no es una medida del rendimiento de TI, sino de la seguridad de los pacientes. La entidad sanitaria que considere la seguridad en la nube como una cuestión de «administración interna» genera un riesgo para los pacientes cada vez que su sistema deja de funcionar o que el registro de datos de un paciente se altera sin que quede constancia de ello.

¿Por qué deben tratarse los SLA de disponibilidad como controles de riesgo clínico?

La protección de la continuidad del negocio es, sin duda, uno de los temas centrales de un SLA empresarial habitual. En los entornos de nube del sector sanitario, este documento debe funcionar como un control de riesgo clínico, teniendo en cuenta las consecuencias que tendría un tiempo de inactividad en el contexto de los pacientes.

Las garantías genéricas de tiempo de actividad son incapaces de abordar las realidades operativas de los entornos clínicos. Un SLA que regule una implementación de nube en el sector sanitario debe especificar:

• Objetivo de tiempo de recuperación (RTO) alineado con la criticidad del flujo de trabajo clínico; el acceso a la historia clínica electrónica (EHR), por ejemplo, requiere un RTO mucho más corto que los sistemas de facturación
• Objetivo de punto de recuperación (RPO) lo suficientemente estricto como para evitar la pérdida de datos clínicamente significativos entre la última copia de seguridad y el momento del fallo
• Ventanas de mantenimiento planificadas programadas en torno a períodos de baja afluencia, y no a las horas estándar fuera de las horas punta
• Procedimientos de escalado que dirijan las notificaciones de interrupciones críticas directamente al equipo directivo de operaciones clínicas, y no solo al departamento de TI
• Apoyo en los procedimientos de tiempo de inactividad: documentación o herramientas que permitan flujos de trabajo clínicos manuales cuando los sistemas en la nube no estén disponibles

¿En qué debería diferir la colaboración de los equipos de seguridad y protección respecto a la habitual en TI y seguridad?

En un entorno empresarial típico, el equipo de seguridad define los controles, mientras que los equipos de TI se encargan de implementarlos. Rara vez se tiene en cuenta la opinión clínica en ninguno de estos procesos.

El uso de las tecnologías de la nube en el ámbito sanitario exige un modelo operativo completamente nuevo que transforme el papel de los responsables de la seguridad del paciente, los equipos de informática clínica y los ingenieros biomédicos, pasando de ser meros destinatarios del flujo de trabajo de las decisiones de seguridad a convertirse en participantes de pleno derecho en ese mismo flujo de trabajo.

Este modelo también modifica la forma en que se aborda el riesgo en su totalidad. Un equipo de seguridad encargado de decidir si se requiere una autenticación adicional necesitará la opinión clínica sobre cómo el aumento de los controles afecta al flujo de trabajo de urgencias. Un ingeniero biomédico que desee gestionar la integración de la conectividad necesita conocer toda la segmentación de la nube que afecta a la comunicación entre dispositivos.

Las políticas de seguridad que se diseñaron sin tener en cuenta aspectos clínicos tienden a eludirse (no porque haya negligencia por parte de nadie, sino porque introducen fricciones que impiden que la atención directa funcione correctamente). La colaboración adecuada entre la seguridad y la protección en el contexto de la asistencia sanitaria es un requisito estructurado, no una buena práctica opcional.

¿Cómo cambia la seguridad en la nube en el sector sanitario el modelo de responsabilidad compartida?

El modelo de responsabilidad compartida suele detallar cómo y dónde se distribuye la carga de la seguridad entre el proveedor de la nube y el cliente. Esta división es mucho más compleja en los entornos sanitarios, ya que el mero hecho de alojar información médica protegida (PHI) no exime a la organización de su responsabilidad normativa. Al mismo tiempo, los mecanismos contractuales que rigen dicha responsabilidad deben ser mucho más precisos que los utilizados en los acuerdos empresariales estándar.

¿Qué responsabilidades corresponden al proveedor de servicios en la nube y cuáles a la organización sanitaria?

El modelo habitual de responsabilidad compartida asigna la seguridad de la infraestructura al proveedor, mientras que la seguridad de los datos recae en el cliente. Esta separación se mantiene en los entornos de nube del sector sanitario, pero el alcance de las obligaciones de cada parte se amplía sustancialmente cuando se trata de información sanitaria protegida (PHI):

¿Por qué las suposiciones sobre las medidas de protección gestionadas por los proveedores pueden exponer datos sensibles e información médica protegida (PHI)?

Por sorprendente que parezca, los ataques complejos no son la principal fuente de exposición de la nube en el sector sanitario. Ese título corresponde a los problemas derivados de un entorno mal configurado que se ha creado utilizando suposiciones no verificadas como punto de partida.

No es raro que las organizaciones sanitarias den por sentado que, si un proveedor de servicios en la nube cumple con la HIPAA, el entorno creado en su interior también cumple con dicha normativa de forma predeterminada. Esa suposición es errónea. Lo que los proveedores pueden hacer es ofrecer todas las capacidades técnicas necesarias para garantizar el cumplimiento de los requisitos, pero la configuración, la aplicación y la verificación de los resultados de dichas capacidades son responsabilidad del cliente.

Podemos tomar el cifrado en reposo como primer ejemplo. Puede estar habilitado de forma predeterminada en el almacenamiento primario, pero no en los niveles de copia de seguridad, las exportaciones de registros o los entornos de procesamiento temporales por los que transita la información médica protegida (PHI) durante los flujos de trabajo de análisis. El registro de auditoría podría estar activado de forma predeterminada, pero no con el nivel de detalle necesario. Los depósitos de almacenamiento de objetos que contienen PHI podrían haberse creado con políticas de acceso poco estrictas durante una migración y nunca haberse reforzado posteriormente.

Cada una de estas deficiencias resultaría prácticamente invisible durante las operaciones rutinarias, mientras que saltaría a la vista de forma notable durante una auditoría regulatoria o una investigación de una violación de seguridad.

¿Qué medidas de seguridad deben incluir los contratos y los SLA para los entornos sanitarios en la nube?

Un Acuerdo de Colaboración Empresarial (BAA) firmado es el requisito contractual mínimo imprescindible para cualquier entorno en la nube que interactúe con la PHI —y, aun así, el BAA por sí solo no es suficiente—. Los contratos de la nube en el ámbito sanitario deben poder abordar obligaciones de seguridad que vayan mucho más allá de cualquier condición comercial estándar:

• Ámbito del BAA y cobertura de los subencargados del tratamiento: el acuerdo debe nombrar explícitamente o cubrir de forma categórica a todos los subencargados del tratamiento que puedan tener acceso a la PHI
• Derechos de auditoría: la organización sanitaria debe conservar el derecho a realizar o encargar evaluaciones de seguridad del entorno del proveedor
• Plazos de notificación de incidentes: los contratos deben especificar plazos de notificación del proveedor al cliente más cortos que el límite máximo de 60 días establecido por la HIPAA, lo que da tiempo a la organización sanitaria para cumplir con sus propias obligaciones de notificación
• Titularidad de las claves de cifrado: los acuerdos deben aclarar si la organización sanitaria controla sus propias claves de cifrado o si depende de claves gestionadas por el proveedor, así como qué acceso conserva el proveedor
• Residencia y soberanía de los datos: los contratos deben especificar los límites geográficos para el almacenamiento y el tratamiento de la PHI, especialmente cuando se aplican los requisitos de localización de datos del RGPD o a nivel estatal
• Eliminación verificada de datos: las cláusulas de rescisión deben exigir una confirmación por escrito de la eliminación de la PHI de todos los niveles de almacenamiento, incluidas las copias de seguridad y los entornos de recuperación ante desastres
• Compromisos de tiempo de actividad y RTO: las garantías de disponibilidad deben estar calibradas clínicamente, no ser genéricas

¿Cómo cambian el modelo de amenazas la interoperabilidad y el intercambio de datos?

Los entornos de nube para la asistencia sanitaria no pueden ser sistemas cerrados debido a su propia naturaleza. Las disposiciones normativas, los requisitos de coordinación asistencial y las obligaciones de acceso de los pacientes exigen que los datos sean transferibles —entre proveedores, pacientes, entidades pagadoras y aplicaciones de terceros—.

Esta naturaleza abierta ni siquiera constituye un fallo de seguridad, sino un requisito de diseño. Lamentablemente, este requisito es también lo que contribuye a la expansión masiva de la superficie de ataque que deben tener en cuenta los programas de seguridad sanitaria.

¿Por qué las API, las integraciones FHIR y la conectividad de las historias clínicas electrónicas aumentan los riesgos de seguridad en la nube?

La Ley «21st Century Cures», junto con las posteriores normas de interoperabilidad de los CMS, exige a las organizaciones sanitarias que faciliten los datos de los pacientes mediante API FHIR (Fast Healthcare Interoperability Resources) estandarizadas. Esto convierte el intercambio de datos externos en una obligación legal, en lugar de ser una mera elección arquitectónica.

Cada punto final de API que facilita información médica protegida (PHI) a un usuario autorizado puede constituir también un posible punto de entrada para usuarios no autorizados. La superficie de ataque generada por la interoperabilidad no es incidental, sino estructural, y crece con cada nueva integración habilitada por las organizaciones sanitarias.

La conectividad con los sistemas de historias clínicas electrónicas (EHR) no hace sino agravar aún más este problema. Las plataformas modernas de historias clínicas electrónicas (EHR) se integran habitualmente con entornos de análisis alojados en la nube, portales de participación de pacientes, herramientas de salud poblacional y sistemas de pagadores. Cada una de estas conexiones representa un flujo de datos que debe autenticarse, cifrarse, supervisarse y revisarse periódicamente.

El modelo de amenazas de los entornos sanitarios no es estático, sino que se amplía con cada nueva integración que se aprueba; sin embargo, rara vez se reduce cuando las integraciones se sustituyen o se dejan de utilizar.

¿Cómo deben protegerse la autenticación, los intercambios de tokens y el cifrado de datos en los flujos de trabajo clínicos?

Los modelos típicos de autenticación empresarial funcionan en entornos controlados en los que los usuarios inician sesión desde dispositivos conocidos dentro de redes gestionadas. Los flujos de trabajo clínicos no funcionan así. Los médicos tienen que acceder a sistemas alojados en la nube desde estaciones de trabajo compartidas, dispositivos personales y ubicaciones remotas —a menudo bajo la presión del tiempo, lo que convierte una autenticación con muchas trabas en un riesgo real para la atención sanitaria—.

SMART (Substitutable Medical Applications, Reusable Technologies) sobre FHIR es un marco de autorización basado en OAuth 2.0 diseñado específicamente para contextos de aplicaciones clínicas, que representa la referencia actual para garantizar el acceso basado en tokens a las API de FHIR.

Sin embargo, la calidad de su implementación varía entre proveedores y despliegues. Los plazos de caducidad de los tokens, las limitaciones de alcance y la gestión de los tokens de actualización requieren una configuración explícita, ya que los ajustes predeterminados suelen priorizar la comodidad frente a la seguridad.

Más allá de la autenticación, es obligatorio aplicar el protocolo TLS en todos los flujos de datos de información médica protegida (PHI), y el cifrado debe extenderse a los datos en reposo dentro de cualquier sistema en la nube que reciba información procedente de un historial médico electrónico (EHR) o de una integración de API.

Las áreas clave que requieren una atención explícita, en lugar de basarse en los valores predeterminados:

• Ámbito del token limitado al acceso mínimo necesario a los datos
• Tokens de acceso de corta duración con políticas de actualización controladas
• TLS mutuo para las conexiones de API de servidor a servidor
• Cifrado verificado en todos los niveles de almacenamiento que reciben PHI procedente de la API

¿Cómo aumenta la conectividad de aplicaciones de terceros los riesgos de la cadena de suministro y de movimiento lateral?

Las empresas del sector sanitario que conectan aplicaciones de terceros a sus entornos en la nube heredan una parte de la postura de seguridad de cada proveedor, independientemente de si la han evaluado o no.

Una aplicación orientada al paciente con acceso de escritura a la historia clínica electrónica (EHR), una herramienta de análisis de salud poblacional con amplios permisos de consulta de datos o una integración de facturación con acceso a datos de reclamaciones y demográficos representan, cada una de ellas, un posible punto de entrada a la cadena de suministro. Si una aplicación de terceros se ve comprometida, un atacante puede heredar cualquier acceso que posea dicha aplicación. En los entornos de nube del sector sanitario, ese acceso suele incluir vías de acceso a sistemas que contienen información médica protegida (PHI) a gran escala.

Los cuestionarios de seguridad periódicos a los proveedores rara vez bastan para detectar los riesgos específicos que plantean las integraciones de API clínicas, y la supervisión continua del comportamiento de las conexiones de terceros aún no es una práctica habitual en todo el sector.

¿Por qué son fundamentales los controles de identidad y acceso para la seguridad de la nube en el sector sanitario?

Controlar quién puede acceder a qué y en qué circunstancias es uno de los mayores retos de seguridad para cualquier entorno en la nube. En el caso del sector sanitario, ese mismo reto se ve amplificado aún más por la gran variedad de personas que necesitan acceder a sistemas sensibles, la urgencia con la que a veces se requiere dicho acceso y las graves consecuencias tanto de restringir en exceso como de no restringir lo suficiente el acceso.

¿En qué se diferencian las necesidades de acceso basadas en roles y en atributos entre los usuarios clínicos y los administrativos?

Los controles de acceso basados en roles (RBAC) consisten en asignar permisos del sistema en función del puesto de trabajo del usuario, en lugar de su identidad individual. Un coordinador de facturación tiene acceso a los registros financieros. Un radiólogo tiene acceso a los sistemas de imágenes. Una enfermera de planta tiene acceso a los registros de administración de medicamentos de la sala que le ha sido asignada.

El RBAC constituye la base de la gestión del acceso a la nube en el ámbito sanitario y reduce en gran medida la posibilidad de que los usuarios tengan que ver información que no les incumbe desde una perspectiva clínica u operativa (si se implementa correctamente).

El principal problema aquí es que las funciones sanitarias rara vez pueden dividirse en categorías bien definidas. Los controles de acceso basados en atributos (ABAC) amplían el RBAC al incorporar diversos factores contextuales: el departamento en el que trabaja actualmente un usuario, la hora del día, el paciente concreto al que está tratando o si accede al sistema desde un dispositivo autorizado en una red interna.

Un médico que atiende en varios departamentos, una enfermera especializada con privilegios en dos centros o un coordinador de cuidados que trabaja tanto en entornos hospitalarios como ambulatorios tienen, todos ellos, necesidades de acceso complejas que una definición estática de funciones tendría dificultades para acomodar de forma clara. El ABAC permite que matices como estos se expresen como una política, en lugar de gestionarse como excepciones.

¿Por qué es fundamental el acceso sensible al contexto y basado en el principio del mínimo privilegio para situaciones de atención a pie de cama y de urgencias?

El acceso basado en el principio del mínimo privilegio es una práctica de seguridad bien establecida: el principio de que cualquier usuario solo debe tener acceso a los datos y sistemas estrictamente necesarios para su tarea actual. En la mayoría de los entornos empresariales, la aplicación de esta práctica es principalmente un ejercicio técnico y administrativo. En el ámbito sanitario, sin embargo, esta práctica entra en contradicción significativa con la realidad de la atención de urgencias.

Un médico traumatólogo que atiende a un paciente inconsciente que llega sin identificación necesita acceso inmediato a toda la historia clínica del paciente (su historial de alergias, la medicación actual y los diagnósticos previos). El hecho de que dicho médico no haya tenido ninguna relación previa con el paciente significa que una aplicación estricta del modelo de privilegios mínimos bloqueará precisamente el acceso que la atención médica requiere.

Aquí es donde entra en juego el modelo de acceso de emergencia. Se trata de un mecanismo de anulación controlada que permite a los profesionales clínicos eludir las restricciones de acceso estándar en situaciones de verdadera emergencia, al tiempo que se registra cada acción realizada durante esa sesión para su revisión posterior.

El acceso de emergencia no es una vulnerabilidad de seguridad, sino una válvula de seguridad deliberada y auditable. Sin embargo, puede convertirse en un problema de seguridad cuando su alcance no está bien definido, no se registra de forma coherente o se utiliza con tanta frecuencia que pierde todo su significado como excepción.

Por ello son necesarias políticas de acceso sensibles al contexto. Estas tienen en cuenta la ubicación del paciente, la asignación del equipo asistencial y la urgencia clínica para reducir la frecuencia de uso del modelo de acceso de emergencia sin eliminarlo como opción.

¿Cómo deben gestionarse y auditarse los accesos temporales, contingentes y de proveedores?

Los entornos de nube del sector sanitario suelen dar cabida a usuarios cuyas necesidades de acceso están limitadas en el tiempo por defecto. Esto incluye a enfermeras itinerantes y médicos suplentes que cubren vacantes a corto plazo, proveedores externos que realizan el mantenimiento de los sistemas, consultores de implementación con privilegios administrativos temporales y auditores externos que revisan la documentación de cumplimiento normativo. Conceder acceso a cualquiera de estos usuarios supone un riesgo que sigue aumentando siempre que no se gestione de forma activa.

Los requisitos fundamentales son sencillos, aunque su ejecución coherente no lo sea:

• Las autorizaciones de acceso para usuarios temporales deben incluir fechas de caducidad explícitas establecidas en el momento de la concesión
• El acceso de proveedores y terceros debe limitarse a los sistemas y datos específicos necesarios para el proyecto, sin ir más allá
• Todas las sesiones de acceso temporal deben registrarse con suficiente detalle para permitir un registro de auditoría completo
• Las revisiones de acceso deben programarse de forma proactiva, en lugar de activarse únicamente por eventos de baja

La situación de fallo más habitual ni siquiera es maliciosa, sino administrativa. Esto incluye credenciales temporales que nunca se revocaron, cuentas de proveedores que se mantuvieron más allá de la duración del contrato y accesos de contratistas que se ampliaron gradualmente sin una revisión formal.

¿Cómo modifican los dispositivos médicos y el IoT los requisitos de seguridad en la nube?

Los dispositivos médicos y los equipos clínicos conectados tienen su propia categoría de riesgo que no puede abordarse adecuadamente mediante las directrices estándar del IoT. Dichos dispositivos no son meros sensores para edificios o termostatos inteligentes, sino sistemas críticos para la seguridad con un impacto directo en los pacientes; por ello, las restricciones de seguridad bajo las que operan difieren sustancialmente de todo lo demás en un entorno típico de la nube.

¿Por qué son importantes las restricciones de los dispositivos (sistemas operativos heredados, aplicación limitada de parches) para la integración en la nube?

Muchos dispositivos médicos (bombas de infusión, sistemas de imagen, monitores de pacientes, respiradores) utilizan sistemas operativos obsoletos. Windows 7, Windows XP e incluso plataformas más antiguas siguen utilizándose activamente en el ámbito clínico a día de hoy. Esto suele ocurrir cuando los fabricantes de dispositivos desarrollan y certifican su software para una versión específica del sistema operativo, lo que significa que sustituir o actualizar dicho software obligaría a pasar de nuevo por todo el proceso de revisión reglamentaria de la FDA.

Esta es la principal razón por la que la aplicación de parches —el mecanismo más básico para subsanar las vulnerabilidades de software— no está disponible para una gran parte de los dispositivos que se conectan a entornos de nube del sector sanitario.

Un dispositivo al que no se le pueden aplicar parches tampoco puede considerarse seguro en el sentido convencional. Cada vez que dichos dispositivos tienen que transmitir datos de telemetría de algún tipo a plataformas en la nube o recibir actualizaciones de configuración desde sistemas de gestión alojados en la nube, la seguridad de dicha conexión debe gestionarse exclusivamente desde el lado de la red o la nube, ya que el propio dispositivo apenas puede aportar nada al respecto.

¿Cómo deben diseñarse la telemetría, la identidad del dispositivo y la segmentación para los dispositivos críticos para la seguridad?

La segmentación de la red constituye la primera línea de defensa en entornos relacionados con la asistencia sanitaria. Los dispositivos médicos deben mantenerse dentro de segmentos de red aislados con acceso únicamente a los sistemas en la nube concretos que necesiten. Un monitor de pacientes no debería poder establecer una conexión con el almacenamiento en la nube, los servidores de administración, la red externa ni con ningún otro elemento, salvo ese sistema en la nube concreto. La segmentación no soluciona la vulnerabilidad del propio dispositivo, pero al menos puede limitar el «radio de impacto» de una de las vulnerabilidades que se estén explotando.

La identidad del dispositivo es igual de importante. Cada dispositivo que se conecte a un entorno en la nube debe demostrar su identidad mediante una credencial única (a ser posible, un certificado asociado al dispositivo, no solo datos básicos de inicio de sesión). De este modo, cualquier dispositivo que presente patrones de comportamiento inesperados puede identificarse y gestionarse sin afectar a otros dispositivos de la misma red. Poder mantener un inventario preciso de los dispositivos conectados en un momento dado también supone una ventaja.

Los flujos de telemetría procedentes de los dispositivos médicos también deben supervisarse para detectar anomalías. Cualquier tipo de patrón inusual puede ser un factor identificativo de una vulneración o una configuración errónea (ya se trate de volúmenes de datos inusuales, destinos de conexión inesperados o patrones de comunicación que se desvíen del comportamiento normal de un dispositivo).

¿Cómo pueden los análisis en la nube suponer riesgos para la privacidad de los datos generados por los dispositivos?

Existe una suposición común en torno a la telemetría de los dispositivos que da por hecho que dichos datos son, por naturaleza, de baja sensibilidad, pareciéndose más a la salida de una máquina que a la información médica protegida (PHI). Ese tipo de suposición suele ser errónea.

Los flujos continuos de datos procedentes de dispositivos como medidores de glucosa, unidades de telemetría cardíaca o monitores respiratorios pueden contener información suficiente para identificar a pacientes concretos, deducir diagnósticos y reconstruir cronologías de atención (incluso tras eliminar los identificadores evidentes). Cada vez que dichos datos se transfieren a plataformas de análisis basadas en la nube, pueden agregarse, conservarse, compartirse con proveedores de análisis externos o incluso utilizarse para entrenar modelos de formas inusuales.

El riesgo de reidentificación de los datos sanitarios generados por dispositivos es significativo y, a menudo, se subestima. La importancia crítica de dicha información implica que merece, como mínimo, el mismo tratamiento que se aplica a la información médica protegida (PHI) en el manejo de cualquier dato etiquetado como historial médico.

¿De qué se dan cuenta las organizaciones sanitarias, por lo general, demasiado tarde tras trasladar datos sensibles a la nube?

En el sector sanitario, la adopción de la nube suele ir por delante del desarrollo de los programas de seguridad diseñados para respaldarla. Las brechas de seguridad que surgen como consecuencia de este problema suelen pasar desapercibidas hasta que algo sale mal.

¿Por qué los entornos en la nube que cumplen técnicamente con la normativa siguen sufriendo filtraciones de datos sanitarios?

Las evaluaciones de cumplimiento normativo solo pueden medir si existen los controles de seguridad necesarios en un momento concreto. Dichas pruebas no pueden determinar si esos controles seguirán funcionando correctamente varios meses después, una vez que el entorno a su alrededor haya cambiado.

La propia infraestructura en la nube rara vez es estática e inactiva. Los desarrolladores crean nuevos recursos de almacenamiento, se añaden integraciones entre sistemas con regularidad y, a menudo, se ajustan los permisos para resolver rápidamente problemas de acceso (sin revisarlos posteriormente). Ninguno de estos cambios va a desencadenar por sí solo una revisión de cumplimiento, pero cada uno de ellos puede considerarse una oportunidad para que el entorno se aleje del estado que le permitió superar la última auditoría.

Es necesario mencionar temas como estos porque la configuración incorrecta sigue siendo, a día de hoy, la principal causa de las filtraciones de datos en la nube; ni siquiera los sofisticados ataques de Estados-nación ni los exploits de día cero se le acercan. Una parte sustancial de los incidentes en la nube del sector sanitario se debe a:

• Depósitos de almacenamiento expuestos
• Políticas de acceso excesivamente permisivas
• Registro de eventos desactivado

Es bastante habitual que una organización sanitaria supere una auditoría de la HIPAA y, tan solo unos meses después, sufra una filtración que se podría haber evitado. No había ningún problema en el entorno de la organización en el momento de la auditoría, pero el propio entorno cambió. Por eso el cumplimiento normativo es un estado, no una garantía.

¿Cómo las suposiciones sobre la migración a la nube debilitan silenciosamente la seguridad en la nube del sector sanitario?

El peor error de migración que se puede cometer es dar por sentado que los controles de seguridad locales van a funcionar exactamente de la misma manera una vez trasladados a la nube. Este enfoque se denomina a veces «lift-and-shift»: consiste en tomar las cargas de trabajo preexistentes y trasladarlas a la infraestructura en la nube sin realizar ningún cambio para adaptarlas al nuevo entorno. Es una solución rápida para algunos problemas, pero también es extremadamente arriesgada.

• Las reglas de cortafuegos que protegían un centro de datos no rigen los depósitos de almacenamiento en la nube
• Los perímetros de red que contenían el movimiento lateral en las instalaciones no existen de la misma manera en un entorno en la nube
• Los controles de acceso que un equipo de TI local gestionaba manualmente no se migran junto con los datos y deben reconstruirse deliberadamente en la nube

La causa principal de casi todas las vulnerabilidades relacionadas con la migración se reduce a la confusión en torno al modelo de responsabilidad compartida. Las empresas que migran sus datos a un proveedor de servicios en la nube dan por sentado que los ajustes de seguridad predeterminados del proveedor cubrirán lo que su equipo interno solía hacer en las instalaciones propias; pero no es así.

Una de las conclusiones más recurrentes tras la migración se refiere a los roles de gestión de identidades y accesos (IAM) con permisos excesivos: configuraciones que se crearon con amplios derechos de acceso durante la migración para evitar complicaciones, se marcaron como temporales y nunca se eliminaron posteriormente. Estos roles pueden permanecer inactivos en el entorno durante mucho tiempo, proporcionando a los atacantes que logran acceder a ellos un acceso mucho mayor del que jamás debería concederse a un solo usuario.

Problemas como estos nunca son dramáticos ni evidentes, ya que los sistemas siguen funcionando, los registros continúan generándose, etcétera. Los problemas comienzan a aparecer durante un incidente, cuando resulta que se ha podido acceder durante meses a un depósito mal configurado, o que el rol con permisos excesivos tiene acceso de lectura a todos los conjuntos de datos de información médica protegida (PHI) del entorno.

¿Por qué los fallos en las copias de seguridad y la recuperación suelen ser más perjudiciales que el ataque inicial a la nube?

Muchos ataques a la nube solo pueden interrumpir las operaciones en el momento en que se producen. Por el contrario, un fallo en la recuperación amenaza con prolongar dicha interrupción de forma indefinida.

No es infrecuente que las organizaciones sanitarias descubran problemas críticos en sus copias de seguridad en la nube durante ataques de ransomware, precisamente cuando menos se lo pueden permitir. Entre ellos se incluyen:

• Las copias de seguridad se almacenaban en el mismo entorno que los sistemas principales y se cifraban junto con ellos
• Las tareas de copia de seguridad se completaban con éxito en el panel de control, pero los datos restaurados estaban incompletos o dañados
• La recuperación nunca se había probado de principio a fin en un escenario realista
• Las políticas de retención se habían configurado incorrectamente, dejando puntos de restauración demasiado antiguos como para ser clínicamente útiles

El segundo punto sobre los informes de copias de seguridad merece una atención especial. Los paneles de control de copias de seguridad, por su propia naturaleza, informan de la finalización de las tareas, no del éxito de la restauración. Es perfectamente posible que una tarea finalice sin errores y, sin embargo, se cree una copia de seguridad que no pueda utilizarse para recuperar un sistema operativo. La única forma de saber si una copia de seguridad funciona es probarla, pero las pruebas son algo que demasiadas empresas se saltan de forma habitual.

Las copias de seguridad inmutables son la contramedida directa frente al riesgo de las copias de seguridad en la era del ransomware. Se trata de copias que solo se pueden escribir una vez, sin posibilidad de modificarlas, eliminarlas o cifrarlas posteriormente. La inmutabilidad no impide que se produzca un ataque, pero puede garantizar que la recuperación siga siendo posible una vez que este se haya producido.

La ausencia de copias de seguridad inmutables es un problema crítico, ya que muchos autores de ataques de ransomware con acceso suficiente a los sistemas principales suelen tener también acceso a las copias de seguridad, lo que les permite arruinar de raíz cualquier plan de recuperación.

¿Cómo se desarrolla normalmente una filtración de datos en la nube del sector sanitario moderno?

Las filtraciones en entornos de nube del sector sanitario rara vez comienzan con un exploit técnico complejo. Estos incidentes se inician con una persona y se agravan rápidamente a partir de ahí.

¿Cómo pasan los atacantes del phishing al compromiso de los sistemas sanitarios en la nube?

Por lo general, basta con un solo correo electrónico para poner en marcha toda la cadena. Cualquier miembro del personal podría hacer clic en un enlace que parezca una identificación rutinaria de TI o una actualización del portal de pacientes. Una vez introducidas sus credenciales, el ataque pasa a una fase diferente.

El camino desde el phishing hasta el acceso al entorno en la nube es mucho más corto de lo que la mayoría de las empresas creen, ya que gran parte del personal sanitario sigue utilizando el mismo conjunto de credenciales en diferentes sistemas (mientras que se puede acceder a las consolas de gestión de la nube desde cualquier navegador).

No es necesario que un atacante traspase el perímetro de seguridad cuando dispone de una combinación válida de nombre de usuario y contraseña: simplemente puede iniciar sesión como cualquier otra persona.

Una vez dentro, el objetivo pasa a ser la expansión y la persistencia. El atacante intenta localizar los entornos de almacenamiento en la nube que contienen más datos, las cuentas de servicio con los permisos más amplios y los sistemas conectados que podrían utilizarse para obtener más información médica protegida (PHI).

La mayoría de los ataques a la nube en el sector sanitario llegan a la fase de exfiltración de información médica protegida (PHI) a los pocos días de la entrada inicial. Para cuando se detecta el comportamiento anómalo, es muy probable que el atacante ya haya alcanzado su objetivo.

¿Por qué las plataformas de almacenamiento en la nube y las API sanitarias son cada vez más objeto de ataques?

Tanto las API sanitarias como las plataformas de almacenamiento en la nube son objeto de ataques principalmente debido a su enorme retorno de la inversión.

Basta con un único depósito de almacenamiento en la nube mal configurado en un entorno sanitario para exponer millones de historiales de pacientes. Mientras tanto, las credenciales de API comprometidas podrían ofrecer un acceso continuo y autenticado a un flujo de datos que se actualiza en tiempo real.

Los datos sanitarios son un bien mucho más valioso en los mercados delictivos que los datos financieros. Un historial médico completo vale muchas veces más que un número de tarjeta de crédito, ya que contiene datos que no se pueden modificar y que pueden aprovecharse de múltiples formas durante un periodo de tiempo prolongado.

La naturaleza accesible de las API también las convierte en objetivos atractivos. Una API es necesaria para transferir información entre sistemas de forma fluida, lo que las hace accesibles, funcionales y consultables a gran escala sin que se activen muchas alertas en el entorno.

¿Qué interrupciones operativas se producen después de que los atacantes accedan a los entornos de nube del sector sanitario?

Una brecha de seguridad en la nube del sector sanitario tiene un impacto clínico y operativo de gran alcance que va más allá de los propios sistemas comprometidos. Entre las interrupciones más comunes se incluyen:

• Indisponibilidad de los historiales médicos electrónicos (EHR): los profesionales sanitarios pierden el acceso a los historiales de medicación, los planes de cuidados y los resultados de los diagnósticos, lo que les obliga a recurrir a procesos manuales basados en papel
• Desvío de ambulancias: los hospitales que operan con procedimientos de contingencia pueden declarar emergencias internas que redirijan a los pacientes que llegan a otros centros
• Procedimientos cancelados: las cirugías programadas y no urgentes, las citas para pruebas de imagen y las visitas ambulatorias se posponen cuando los sistemas que gestionan las comprobaciones previas a los procedimientos están fuera de servicio
• Retrasos en farmacia y en la dispensación de medicamentos: los sistemas de prescripción electrónica dejan de funcionar, lo que supone un riesgo en el momento de la administración de la medicación
• Parálisis de la facturación y las reclamaciones: los sistemas del ciclo de ingresos que dependen de la infraestructura en la nube dejan de procesar, lo que genera atrasos financieros que persisten mucho después de que se hayan restablecido los sistemas clínicos
• Exposición normativa y legal: las obligaciones de notificación de infracciones se activan de inmediato, lo que añade una carga de trabajo de cumplimiento normativo justo cuando la recuperación operativa está consumiendo la máxima capacidad de la organización

Las interrupciones clínicas podrían resolverse en cuestión de días o semanas, pero las consecuencias normativas, legales y reputacionales de un solo ataque suelen durar mucho más tiempo que eso.

¿Por qué deben adaptarse la respuesta ante incidentes y el análisis forense a las nubes del sector sanitario?

El objetivo principal de la respuesta ante incidentes para la mayoría de los sectores es contener la amenaza y recuperar el entorno. El sector sanitario añade otro objetivo a esto: garantizar la seguridad de los pacientes durante el proceso. Además, estos dos objetivos no siempre apuntan en la misma dirección.

¿Cómo altera la necesidad de una rápida continuidad clínica las estrategias de contención de incidentes?

Las doctrinas estándar de respuesta ante incidentes se basan en gran medida en el aislamiento. Siempre que un sistema se ve comprometido, se desconecta de la red para evitar que el ataque se propague. Es un buen enfoque para la mayoría de los sistemas que dan soporte a las operaciones empresariales. Lamentablemente, no puede decirse lo mismo de los sistemas que dan soporte a la atención activa de los pacientes.

Desconectar un sistema de historias clínicas electrónicas (EHR) durante un incidente activo impide a los profesionales sanitarios acceder a los registros de medicación, los historiales de alergias y los datos de monitorización en tiempo real. Intentar aislar un entorno en la nube que da soporte a la telemetría de la UCI o a la dispensación de medicamentos supone un riesgo clínico directo. La propia medida de contención puede causar daños, razón por la cual los equipos de respuesta a incidentes en entornos sanitarios no pueden limitarse a seguir el manual habitual con el que trabaja todo el mundo.

En este caso, es necesario un enfoque más preciso. En lugar de llevar a cabo un aislamiento generalizado, los equipos de respuesta a incidentes (IR) del sector sanitario deben contar con estrategias de contención predefinidas capaces de distinguir entre los sistemas que pueden desconectarse y los entornos que deben permanecer disponibles pase lo que pase. Todas estas decisiones deben tomarse con suficiente antelación a que se produzca un incidente, ya que tomar decisiones en tiempo real sobre qué sistemas clínicos pueden interrumpirse de forma segura durante una brecha de seguridad es una práctica de alto riesgo.

¿Qué controles forenses y registros son necesarios para respaldar tanto las investigaciones legales como las clínicas?

La mayoría de las brechas de seguridad típicas en entornos de nube del sector sanitario requieren al menos dos investigaciones simultáneas:

1. La revisión de cumplimiento normativo y litigios
2. La revisión del impacto de la compromisión de datos clínicos y de las decisiones sobre la atención al paciente

El elemento crítico que cada investigación buscará se basará exactamente en las mismas pruebas: los registros. Prácticamente todo el valor forense de un entorno en la nube viene determinado por las decisiones de registro tomadas mucho antes del incidente. Las pruebas que no se hayan capturado tampoco podrán recuperarse a posteriori.

Los requisitos fundamentales de registro para los entornos de nube del sector sanitario incluyen:

• Registros de acceso que cubran todas las interacciones con la información médica protegida (PHI): quién accedió a ella, cuándo, desde dónde y qué acciones se llevaron a cabo
• Registros de autenticación, incluidos los intentos fallidos de inicio de sesión, los eventos de elusión de la autenticación multifactorial (MFA) y la escalada de privilegios
• Registros de llamadas a la API que recojan todas las solicitudes a las interfaces de gestión de la nube y a las API de datos sanitarios
• Registros de flujo de red suficientes para reconstruir los movimientos laterales y las rutas de exfiltración de datos
• Registros de cambios de configuración que hagan un seguimiento de las modificaciones en los permisos de almacenamiento, los roles de IAM y las reglas de los grupos de seguridad

Los períodos de conservación de estos registros deben ajustarse tanto al requisito de documentación de seis años de la HIPAA como a cualquier normativa estatal aplicable. Los registros deben almacenarse por separado de los sistemas que supervisan, con el fin de impedir que un atacante que haya obtenido acceso a la infraestructura principal altere o elimine las pruebas.

¿En qué deben diferir los ejercicios de simulación y los manuales de respuesta de los escenarios exclusivos de la empresa?

La mayoría de los ejercicios de simulación de respuesta a incidentes (IR) de las empresas suelen involucrar a los equipos de TI y de seguridad (en ocasiones también participan los equipos jurídicos y de comunicación). Los simulacros del sector sanitario requieren un espacio considerablemente más amplio, así como escenarios significativamente diferentes.

Debe estar presente la dirección de operaciones clínicas, ya que las decisiones sobre qué sistemas deben desconectarse deben tomarse bajo la autoridad clínica. El departamento de ingeniería biomédica debe participar siempre que los escenarios afecten a dispositivos conectados. Los responsables de protección de datos deben participar en los árboles de decisión relativos a la notificación de infracciones.

Los propios escenarios deben reflejar amenazas específicas del sector sanitario:

• Un ransomware que cifre simultáneamente tanto los sistemas primarios de historias clínicas electrónicas (EHR) como las copias de seguridad en la nube
• Una credencial de API comprometida que proporciona acceso silencioso a los datos de los pacientes durante un período prolongado
• Una configuración errónea de la nube que ha expuesto públicamente la información médica protegida (PHI) durante un tiempo indeterminado
• Una violación de seguridad de un proveedor externo que se propaga al entorno en la nube de la organización sanitaria a través de una integración activa

Un manual de procedimientos no puede considerarse suficiente en el contexto sanitario si no incluye la activación del procedimiento de tiempo de inactividad (flujos de trabajo manuales a los que recurre el personal clínico cuando los sistemas no están disponibles). Esa sección de la respuesta presenta el mayor riesgo para la seguridad de los pacientes y suele estar ausente en los planes tomados de sectores no clínicos.

¿Por qué resulta más difícil la seguridad en la nube en el sector sanitario que la seguridad empresarial tradicional en la nube?

Todos los sectores se enfrentan, en mayor o menor medida, a retos de seguridad en la nube, y el sector sanitario no es una excepción; de hecho, presenta una serie de limitaciones que no se dan en ningún otro sector. La dificultad de la seguridad en la nube en el sector sanitario es estructural, no técnica.

¿Por qué los proveedores sanitarios no pueden simplemente restringir todo el acceso a la nube?

El sector sanitario ya ha superado el punto en el que la restricción sería una estrategia viable. Muchos de los elementos actuales de un entorno sanitario son prácticamente imposibles sin el almacenamiento en la nube. Por ejemplo:

• Los flujos de trabajo clínicos dependen de plataformas de historias clínicas electrónicas (EHR) alojadas en la nube
• Los pacientes esperan poder acceder a sus historiales a través de portales en línea
• La telesalud funciona sobre una infraestructura en la nube
• Las imágenes diagnósticas se almacenan y transmiten a través de la nube, ya que el tamaño de los archivos hace que el almacenamiento local resulte poco práctico a gran escala

Restringir el acceso a la nube en el ámbito sanitario de forma significativa no va a aumentar su seguridad, sino que impediría su funcionamiento. La cuestión nunca es permitir o denegar el acceso a la nube, sino hacer que dicho acceso sea lo más seguro posible sin interrumpir la atención sanitaria que sustenta.

¿De qué manera los flujos de trabajo de la atención de urgencias generan compromisos inevitables en materia de seguridad en la nube?

Las políticas de seguridad no se ajustan a los mismos plazos que la atención de urgencias. Un equipo de traumatología que atiende a un paciente en estado crítico no esperará a que se complete un proceso de autenticación de varios pasos. Un médico que sustituye a otro en una sala desconocida a las 3 de la madrugada no esperará a que se apruebe una solicitud de acceso mientras revisa el historial médico de un paciente cuyo estado se está deteriorando.

La propia naturaleza de la atención de urgencias implica que cualquier control de seguridad que suponga un obstáculo acaba siendo eludido, en lugar de respetado. En el ámbito sanitario, esas elusiones suelen estar justificadas clínicamente, lo que hace que sean extremadamente difíciles de evitar únicamente mediante políticas.

Unos controles de seguridad más estrictos pueden reducir el riesgo en condiciones estables, pero también lo aumentan en situaciones de emergencia. La disyuntiva es real y completamente inevitable. La seguridad de un centro sanitario debe abordarse no como un medio para alcanzar un fin, sino como una serie de decisiones razonadas y documentadas sobre en qué casos se pueden aceptar esos riesgos (teniendo en cuenta el criterio clínico, no solo la seguridad).

¿Por qué el acceso continuo a los datos genera riesgos de ciberseguridad únicos en los sistemas sanitarios?

La mayoría de los sistemas empresariales suelen tener ritmos naturales que incluyen:

• Picos de uso durante el horario laboral
• Reducción de la actividad durante la noche
• Ventanas de mantenimiento los fines de semana

Esto no se aplica a los sistemas sanitarios. Las plataformas de historias clínicas electrónicas (HCE), los sistemas de farmacia alojados en la nube y los entornos de monitorización de pacientes funcionan a plena capacidad las 24 horas del día, todos los días del año.

Esta disponibilidad continua descarta ciertas opciones en las que los equipos de seguridad empresarial suelen basarse habitualmente. Programar tiempos de inactividad para la gestión de parches se convierte, en esencia, en un debate sobre la gestión del riesgo clínico. Los sistemas diseñados para detectar anomalías en el tráfico normal de la red deben tener en cuenta que, en el ámbito sanitario, hay muy pocos periodos de menor actividad en el sentido habitual.

Un sistema siempre activo es un sistema que está constantemente expuesto. Diseñar la seguridad en torno a esta realidad requiere un enfoque completamente diferente al que se utiliza para proteger la mayoría de las demás infraestructuras en otros sectores.

¿Cómo cambia la arquitectura nativa de la nube la seguridad en la nube en los entornos sanitarios?

Los entornos informáticos sanitarios tradicionales se construyeron en torno a grandes aplicaciones centralizadas, en las que los datos se almacenaban en ubicaciones previsibles y los límites de seguridad eran fáciles de definir. La llegada de la arquitectura nativa de la nube cambió ambos factores al mismo tiempo.

¿Por qué los microservicios, los contenedores y la arquitectura sin servidor requieren un nuevo modelo de amenazas para la información médica protegida (PHI)?

En una aplicación monolítica tradicional, la mayor parte de la funcionalidad tiene lugar dentro del mismo sistema. El proceso es sencillo: la información médica protegida (PHI) entra, se procesa y se almacena. Todo ello dentro de un único sistema con límites de seguridad bastante bien definidos.

Las aplicaciones nativas de la nube se comportan de manera diferente. Una arquitectura de microservicios convierte esa única aplicación en docenas o cientos de servicios más pequeños que son independientes, pero que pueden comunicarse entre sí a través de la red. Cada uno de estos servicios puede gestionar la PHI de forma breve (recibirla, transformarla, transmitirla) sin almacenarla de forma permanente.

Si bien este enfoque moderno es extremadamente eficiente, también implica que la PHI se mueve constantemente a través de un gran número de componentes, y cada uno de ellos representa un punto de exposición potencial.

Los contenedores —pequeños paquetes portátiles que ejecutan servicios individuales— son efímeros por naturaleza, por lo que pueden aparecer, realizar su tarea y luego desaparecer. La propia naturaleza de los contenedores los hace especialmente problemáticos en lo que respecta a la supervisión constante y la aplicación de parches de seguridad en el sentido convencional.

Las funciones sin servidor llevan este enfoque un paso más allá, ya que el código se ejecuta en respuesta a un desencadenante, funciona brevemente y, a continuación, se detiene. De este modo, no existe ningún servidor persistente que supervisar o proteger, al menos de forma tradicional. Cada vez que la PHI pasa por una función sin servidor, el margen de tiempo para observarla y registrarla sigue siendo muy reducido.

Todas estas características y enfoques requieren un modelo de amenazas que está mucho más distribuido que cualquier otro para el que se diseñó la seguridad informática tradicional del sector sanitario.

¿Cómo deben adaptarse los flujos de trabajo de CI/CD y DevSecOps para cumplir con la normativa sanitaria?

Un flujo de trabajo de CI/CD (integración continua y despliegue continuo) es un mecanismo automatizado que toma el código escrito por los desarrolladores, lo prueba y lo envía a producción. Este proceso puede ser muy rápido en el contexto de los entornos nativos de la nube. Las nuevas configuraciones, los servicios actualizados y las políticas de acceso modificadas pueden entrar en funcionamiento en cuestión de minutos.

Si los controles de seguridad no se integran en el proceso desde el principio, esa rapidez se convierte en un riesgo para el cumplimiento normativo. DevSecOps es la práctica de incorporar pasos de validación de seguridad en el proceso de desarrollo y despliegue, en lugar de revisarlos por separado posteriormente.

Lo que esto significa en el contexto sanitario:

• Analizar automáticamente el código de la infraestructura en busca de configuraciones erróneas antes del despliegue
• Señalar los recursos de almacenamiento o los puntos finales de API que podrían exponer información médica protegida (PHI) sin cifrado
• Bloquear las implementaciones que eliminarían los registros de auditoría obligatorios
• Validar que los nuevos servicios cumplan los requisitos de seguridad pertinentes al BAA antes de que lleguen a producción

Detectar las deficiencias de cumplimiento normativo cuando su corrección resulta menos costosa (antes de que el código entre en funcionamiento) es el objetivo principal de este enfoque, que resulta significativamente más eficaz que descubrir todos los problemas tras un incidente o durante una auditoría.

¿Qué controles automatizados protegen la infraestructura en la nube del sector sanitario frente a las configuraciones erróneas?

La revisión manual de la configuración resulta claramente insuficiente dada la velocidad a la que cambian los entornos nativos de la nube. Los controles automatizados son prácticamente imprescindibles para supervisar continuamente el entorno y detectar las desviaciones en el momento en que se producen.

Las principales categorías de controles que conviene tener en cuenta incluyen:

• Gestión de la postura de seguridad en la nube (CSPM): herramientas que analizan continuamente los entornos de la nube en busca de errores de configuración, comparando los ajustes actuales con los parámetros de referencia de seguridad y los marcos de cumplimiento normativo en tiempo real
• Análisis de «infraestructura como código» (IaC): análisis automatizado del código utilizado para definir la infraestructura en la nube, que detecta configuraciones inseguras antes incluso de que se implementen
• Detección de desviaciones: supervisión que identifica cuándo un entorno en la nube en funcionamiento se desvía de su configuración de referencia aprobada, señalando los cambios no autorizados o accidentales a medida que se producen
• Aplicación de «políticas como código»: reglas de seguridad redactadas como políticas legibles por máquina que se aplican y se hacen cumplir automáticamente en todos los recursos de la nube, eliminando la dependencia de la revisión manual

Es importante mencionar que ninguno de estos controles elimina por completo la necesidad de la supervisión humana, pero sí tratan de garantizar que el volumen y el ritmo de los cambios en los entornos nativos de la nube no puedan superar la capacidad del equipo de seguridad para mantenerse al día.

¿Cómo pueden las organizaciones sanitarias mejorar la seguridad en la nube durante la adopción de esta tecnología?

Limitarse a comprender por qué la seguridad en la nube en el sector sanitario supone un reto tan grande es solo la mitad del trabajo. La otra mitad consiste en crear programas que sean lo suficientemente prácticos como para que el personal clínico, los equipos de seguridad y la dirección los sigan al mismo tiempo.

¿Qué riesgos de la computación en la nube deben abordar las organizaciones sanitarias durante la migración?

La fase de mayor riesgo en el proceso de adopción de la nube es la migración: la toma rápida de decisiones bajo la presión del proyecto da lugar a años de deuda de seguridad. Antes de que la información médica protegida (PHI) se traslade a cualquier entorno en la nube, las organizaciones deben abordar lo siguiente:

• Clasificación de datos: identificar qué datos constituyen información médica protegida (PHI), dónde se encuentran actualmente y qué servicios en la nube tendrán acceso a ellos
• Cobertura de los acuerdos de socio comercial (BAA): confirmar que se han firmado acuerdos de socio comercial con todos los proveedores y subencargados del tratamiento que vayan a manejar información médica protegida (PHI)
• Diseño del control de acceso: definir políticas de acceso basadas en roles para el entorno en la nube antes de la migración, no después
• Configuración del registro de eventos: establecer el alcance de los registros de auditoría, los períodos de retención y el aislamiento del almacenamiento como parte de la configuración inicial
• Verificación del cifrado: confirmar que el cifrado abarca todos los niveles de almacenamiento, las rutas de tránsito y los entornos de procesamiento que gestionarán la PHI
• Pruebas de copia de seguridad y recuperación: validar que los procesos de copia de seguridad funcionan correctamente en el entorno en la nube antes de la conmutación de los sistemas principales
• Mapeo de la responsabilidad compartida: documentar explícitamente qué obligaciones de seguridad corresponden al proveedor y cuáles a la organización

¿Cómo pueden las organizaciones sanitarias reducir el riesgo en un entorno en la nube durante una adopción por fases?

Trasladar todo a la nube de una sola vez maximiza tanto la velocidad como el riesgo. Un enfoque gradual, paso a paso, permite verificar los controles de seguridad en cada etapa antes de que comience la siguiente.

Un punto de partida razonable es poner a prueba la adopción de la nube con cargas de trabajo de menor sensibilidad: sistemas administrativos, herramientas de colaboración no clínicas o entornos de análisis anonimizados. Esto da tiempo a los equipos de seguridad y de TI para comprender cómo se comportan realmente en la práctica los controles del proveedor de la nube, identificar las discrepancias entre los parámetros de seguridad predeterminados supuestos y los reales, y familiarizarse con el funcionamiento antes de que se vean afectados los datos sanitarios protegidos (PHI).

Cada fase debe incluir un punto de control de validación formal antes de la expansión. Esto implica probar las copias de seguridad y la recuperación, revisar los registros de acceso en busca de comportamientos inesperados, confirmar que los registros recogen lo que deben y verificar que los límites de la responsabilidad compartida se mantienen en la práctica.

La adopción por fases no supone una adopción más lenta de la nube. Se trata de una adopción de la nube que no genera atrasos en las medidas correctivas que persiguen a la organización durante años.

¿Qué métricas e indicadores clave de rendimiento (KPI) deben supervisar los responsables del sector sanitario para medir la madurez de la seguridad en la nube?

Determinar la madurez de la seguridad supone un verdadero reto sin mediciones específicas. Las métricas que se describen a continuación tienen como objetivo ayudar a los responsables del sector sanitario a comprobar si las medidas de seguridad en la nube están operativas y no se limitan a haber sido implementadas.

¿Cómo puede Bacula Systems mejorar la seguridad en la nube en entornos sanitarios?

Proteger la información sanitaria protegida (PHI) en la nube requiere algo más que controles preventivos: también es necesario tener la certeza de que la recuperación es posible cuando dichos controles se someten a pruebas adecuadas. Bacula Systems ofrece capacidades de copia de seguridad de nivel empresarial, así como funciones de recuperación y gestión de datos diseñadas teniendo en cuenta la complejidad de los entornos sanitarios modernos en la nube.

Áreas en las que Bacula Systems marca una diferencia directa:

• Copias de seguridad inmutables: copias de seguridad que no pueden ser modificadas, eliminadas ni cifradas por un atacante, ni siquiera por uno que tenga acceso administrativo a los sistemas principales
• Recuperación granular: restaure archivos individuales, bases de datos o sistemas completos sin necesidad de recuperarlo todo de una sola vez, lo que reduce el tiempo de inactividad clínica durante un incidente
• Control de las claves de cifrado: las organizaciones conservan la propiedad de sus propias claves de cifrado en lugar de delegar esa responsabilidad en los valores predeterminados del proveedor de la nube
• Registros preparados para auditorías: registros detallados de copias de seguridad y recuperación que cumplen los requisitos de documentación de la HIPAA y satisfacen las necesidades de las investigaciones forenses
• Compatibilidad con entornos híbridos y multinube: protección de datos coherente en entornos locales, de nube privada y de nube pública desde una única interfaz de gestión
• Implementación flexible: la arquitectura de Bacula se adapta a la infraestructura sanitaria existente, en lugar de requerir un enfoque de sustitución total

En última instancia, todos los programas de seguridad en la nube para el sector sanitario pueden evaluarse con una sola pregunta: cuando algo sale mal, ¿con qué rapidez y con qué exhaustividad pueden restablecerse las operaciones? Bacula Systems está diseñado para ofrecer una respuesta definitiva, tanto en entornos de TI sanitarios reales como en entornos híbridos, multinube y heredados.

Preguntas frecuentes

¿Por qué les cuesta tanto a las organizaciones sanitarias mantener políticas de seguridad en la nube coherentes en entornos sanitarios híbridos y multinube?

Los entornos en la nube que utilizan las organizaciones sanitarias rara vez se crean partiendo de cero. A menudo son el resultado de años de compras independientes, fusiones, adquisiciones y acuerdos con proveedores. Cada entorno cuenta con su propio modelo de control de acceso, su propio mecanismo de registro y su propio conjunto de herramientas para supervisar la seguridad. La aplicación de una política para la protección de la información sanitaria protegida (PHI) requerirá una capa de gestión centralizada que la mayoría de las organizaciones no ha creado hasta la fecha.

¿Cómo deben investigar las organizaciones sanitarias las violaciones de seguridad en la nube cuando los registros y las pruebas se encuentran distribuidos entre múltiples proveedores?

La exhaustividad de una investigación de una violación de seguridad depende de la exhaustividad de los registros que la respaldan. Los entornos multinube rara vez almacenan los registros en una única ubicación o en un formato coherente. Los registros deberían transmitirse desde cada entorno en la nube a un repositorio seguro, centralizado e independiente en tiempo real, en lugar de recopilarse de forma reactiva tras el descubrimiento de una violación. Los procedimientos forenses para cada proveedor, incluida la forma de obtener las pruebas conservadas, deberían definirse antes de que se produzca una violación, en lugar de desarrollarse durante la misma.

¿Por qué la automatización nativa de la nube y los flujos de trabajo de DevSecOps pueden exponer accidentalmente datos sanitarios sensibles a gran escala?

Si una configuración errónea se consolida en un proceso automatizado, no afectará solo a un sistema. Se extenderá a todos los entornos con los que interactúe dicho proceso. Un sistema de implementación automatizado diseñado para crear un recurso de almacenamiento que otorgue permisos de acceso abierto como configuración predeterminada puede reproducir ese error cientos de veces antes de que un ser humano se dé cuenta siquiera de su existencia. En el ámbito sanitario, una comprobación de seguridad codificada en un proceso automatizado no es una simple comodidad de ingeniería; es una obligación en materia de privacidad del paciente.