¿qué hay de la localización de datos, de la supuesta “opacidad” de la gestión de cambios, de la confidencialidad de los datos alojados…? El objetivo de este artículo es presentar este nuevo paradigma de prestación de servicios de aplicaciones poniendo como ejemplo la migración de una infraestructura a un entorno “Cloud” por parte de una empresa internacional, al mismo tiempo que se preserva la calidad y la integridad de los datos regulados.

Algunas definiciones

Comencemos definiendo el término de “Cloud computing” según la definición normalizada del NIST⁽²⁾: El “Cloud computing” es un modelo que permite el acceso práctico y bajo demanda de cualquier terminal conectado a la red de internet a recursos informáticos compartidos y configurables (por ejemplo, componentes de red, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente aprovisionados y activados con una mínima gestión y sin que interactúe el proveedor de servicios.

Este modelo se compone de cinco características esenciales, de tres modelos de servicio y de cuatro modelos de despliegue.

Las cinco características esenciales

1. Autoservicio bajo demanda

Un cliente puede disponer de las capacidades de tratamiento de datos, como las del tiempo del servidor y de las capacidades de almacenamiento, en función de sus necesidades, sin que sea necesaria la interacción humana con cada proveedor de servicios.

2. Amplio acceso a la red

Los recursos están disponibles en la red de internet y son accesibles a través de mecanismos estándar que favorecen su utilización por plataformas de clientes heterogéneas ligeras o más pesadas (por ejemplo: teléfonos móviles, tabletas, ordenadores portátiles y estaciones de trabajo).

3. Puesta en común de los recursos

Los recursos informáticos del proveedor son compartidos para servir a varios clientes a través de un modelo de usuarios múltiples (“multi-tenant”), con diferentes recursos físicos y virtuales asignados dinámicamente y reasignados en función de la demanda de los consumidores. La sensación es que la ubicación es independiente, en el sentido de que el cliente generalmente no controla ni conoce la ubicación exacta de los recursos suministrados, aunque sí puede especificar una ubicación a un nivel de abstracción superior (por ejemplo, país, estado o centro de datos). Los recursos disponibles incluyen, por ejemplo, el almacenamiento, el tratamiento, la memoria y el ancho de banda de la red.

4. Rápida elasticidad

Las capacidades se pueden aprovisionar y activar de manera escalable, en determinados casos automáticamente, para evolucionar rápidamente de forma creciente o decreciente en función de la demanda. Para el consumidor, las capacidades disponibles parecen a menudo ilimitadas y pueden ser monopolizadas en cualquier cantidad y momento.

5. Medición del servicio

Los sistemas Cloud controlan y optimizan automáticamente la utilización de los recursos a través de una capacidad de medición al nivel de abstracción apropiado para el tipo de servicio (por ejemplo, almacenamiento, tratamiento, ancho de banda y cuentas de usuarios activos). La utilización de los recursos puede ser vigilada, controlada y notificada, lo que garantiza la transparencia al proveedor

Modelos de servicios

• Aplicación como servicio (Software as a Service o SaaS)

Este modelo da al consumidor la posibilidad de utilizar las aplicaciones del proveedor a partir de una infraestructura Cloud. Las aplicaciones están accesibles a partir de diversos dispositivos clientes por medio de una interfaz cliente ligera, como un navegador Web (por ejemplo, correo web) o a partir de una interfaz programable (API). El consumidor no gestiona ni controla la infraestructura Cloud subyacente, incluida la red, los servidores, los sistemas de explotación, el almacenamiento o incluso las aplicaciones individuales, con la única excepción posible de los parámetros de configuración modificables por el usuario.

• Plataforma como servicio (Platform as a Service -PaaS)

Este modelo permite al consumidor desplegar en la infraestructura Cloud aplicaciones creadas o adquiridas por él, mediante lenguajes de programación, bibliotecas, servicios y herramientas suministradas por el proveedor. El consumidor ni gestiona ni controla la infraestructura Cloud subyacente, incluida la red, los servidores, los sistemas de explotación o el almacenamiento, pero controla las aplicaciones desplegadas y eventualmente los parámetros de configuración del entorno de alojamiento de las aplicaciones.

• Infraestructura como servicio (Infrastructure as a Service – IaaS)

En este modelo, el consumidor es quien provee el tratamiento, el almacenamiento, las redes y otros recursos informáticos fundamentales que le permiten desplegar y ejecutar un software de su elección, que puede incluir sistemas de explotación y aplicaciones. El consumidor no gestiona ni controla la infraestructura Cloud subyacente pero controla los sistemas de explotación, el almacenamiento y las aplicaciones desplegadas, teniendo eventualmente un control limitado de los componentes de red seleccionados (por ejemplo, cortafuegos anfitriones).

Modos de despliegue

• “Cloud” privada

En este modo, la infraestructura Cloud se suministra para la utilización exclusiva de una sola organización que consta de varios consumidores (por ejemplo, unidades comerciales). La propiedad, gestión y explotación de la infraestructura depende de la organización, de terceros o de una combinación de ambos. Además, puede existir dentro o fuera de los locales de la organización.

• “Cloud” comunitaria

La infraestructura Cloud se implementa para la utilización exclusiva de una comunidad específica de consumidores que provienen de organizaciones con las mismas inquietudes (por ejemplo, una misión, exigencias de seguridad, normas y obligaciones reglamentarias). La propiedad, gestión y explotación de la infraestructura depende de una o varias organizaciones de la comunicad, de terceros o de una combinación de ambos. Por ejemplo, las operadoras de transporte aéreo han implementado este tipo de despliegue para facilitar los numerosos intercambios entre ellas (reservas, facturación cruzada…).

• “Cloud” pública

La infraestructura Cloud se suministra para una utilización abierta, por el público en general. Su propiedad, gestión y explotación depende de un organismo comercial, universitario o gubernamental, o una combinación de éstos. Existe en los locales del proveedor de Cloud.

• “Cloud” híbrida

En este caso, la infraestructura Cloud es el resultado de combinar dos o varias infraestructuras Cloud distintas (privadas, comunitarias o públicas) que continúan siendo entidades únicas pero están vinculadas por una tecnología estandarizada o patentada que permite la portabilidad de los datos y de las aplicaciones (por ejemplo, el equilibrado de carga entre dos servidores distribuidos).

Principales autoridades

Los principales actores del mercado Cloud se ven expuestos a numerosas y variadas exigencias habida cuenta de los diferentes mercados y dominios a los que atienden.
Deben así adoptar las normas de calidad más severas para satisfacer el nivel de seguridad y de confidencialidad requerido por los sectores más exigentes (banca, salud, defensa…). La mayoría de dichos actores están certificados por las principales autoridades en estos ámbitos.

• ISO 27001:2013
• Norma internacional de sistema de gestión de la seguridad de la información, publicada en octubre de 2005 y revisada en 2013. Se trata del estándar de seguridad más extendido que especifica las exigencias relativas al establecimiento, la implementación, la actualización y la mejora continua de un sistema de gestión de la seguridad de la información en el contexto de una organización.
• SOC 1, 2, 3
• Los informes de los Controles para la Organización de Servicios (SOC), elaborados por un auditor de acuerdo con las normas del American Institute of Certified Public Accountants (AICPA), están específicamente destinados a evaluar los medios de control de una organización de servicios en base a 5 factores de confianza: seguridad, disponibilidad, integridad del tratamiento y de los datos, confidencialidad, y respeto de los datos privados.
• PCI-DSS
• La norma PCI DSS es establecida por los proveedores de tarjetas de pago y gestionada por el Consejo sobre Normas de Seguridad PCI (fórum internacional abierto para la mejora, difusión e implementación de las normas de seguridad para la protección de los datos de cuentas). Este estándar ha sido creado a fin de incrementar el control de los datos de los titulares de tarjetas para reducir la utilización fraudulenta de los instrumentos de pago.
• HIPAA
• El segundo capítulo de la ley del Health Insurance Portability and Accountability Act (HIPAA) define las normas norteamericanas para la gestión electrónica del seguro médico, la transmisión de las solicitudes de reembolso y todos los identificadores necesarios para el programa de desmaterialización de estas últimas para el seguro médico.
• GDPR (Global Data Privacy Regulation)
• De aplicación desde el 25 de mayo de 2018, el Reglamento europeo de protección de datos impone obligaciones específicas a los encargados del tratamiento cuya responsabilidad podría verse comprometida en caso de incumplimiento. Estas obligaciones atañen a todos los organismos que tratan datos personales por cuenta de otro organismo, en el marco de un servicio o de una prestación como los proveedores de servicios informáticos (alojamiento, mantenimiento, …). Los encargados del tratamiento habrán de respetar obligaciones específicas en materia de seguridad, confidencialidad y documentación de la actividad. Deben tener en cuenta la protección de los datos desde la fase de diseño de un servicio o producto y, de forma predeterminada, deben implementar medidas que permitan garantizar una protección óptima de los datos.La mayoría de las autoridades de certificación no son específicas de la actividad farmacéutica pero contienen la mayoría de las exigencias relativas a la seguridad de datos, esto es:
  • Integridad. Los datos han de ser los que se espera que sean, y no deben ser alterados de forma fortuita ni voluntaria.
  • Confidencialidad. Únicamente las personas autorizadas tienen acceso a la información que se les destina. Ha de impedirse todo acceso no deseado.
  • Disponibilidad. El sistema debe funcionar sin fallo alguno durante las franjas de utilización previstas, así como garantizar el acceso a los servicios y recursos instalados con el tiempo de respuesta esperado.

  Pero también:

  • El no repudio y la imputación. Ningún usuario deberá poder negar las operaciones realizadas por él en el marco de sus acciones autorizadas y ningún tercero debe poder atribuirse las acciones de otro usuario.
  • Autentificación. La identificación de los usuarios es fundamental para la gestión de los accesos a los espacios de trabajo y para mantener la confianza en las relaciones de intercambio.

  En textos normativos más específicamente vinculados a la actividad farmacéutica, encontramos referencias al “Cloud computing” en los siguientes marcos:

• 21 CFR Part 11⁽³⁾
• Noción de sistema abierto que se define como un entorno cuyo acceso no es controlado por las personas responsables del contenido de los registros electrónicos residentes en el sistema. Para estos sistemas, la normativa CFR 21 Parte 11 recomienda en el artículo 11.30 que “las personas que utilicen sistemas abiertos para crear, modificar, mantener o transmitir registros electrónicos deben hacer uso de los procedimientos y medios de control diseñados para garantizar la autenticidad, la integridad y, dado el caso, la confidencialidad de los documentos electrónicos desde el punto de creación hasta el punto de recepción. Estos procedimientos y medios de control incluyen los identificados en el párrafo 11.10, y en su caso, medidas adicionales tales como el cifrado de documentos y la utilización de estándares de firma digitales para garantizar, en función de las circunstancias, la autenticidad, la integridad y la confidencialidad de los registros”.
• OMS (WHO)⁽⁴⁾
• En el marco de un acuerdo de subcontratación, la guía de la OMS insiste en la necesidad de que “las responsabilidades del ordenante y del aceptador definidas en un contrato, tal y como se define en las directrices de la OMS, abarquen completamente los procesos de integridad de los datos de las dos partes incluyendo el trabajo externalizado o los servicios prestados… Estas responsabilidades se extienden a todos los proveedores de servicios informáticos, a los centros de datos, al personal de mantenimiento de las bases de datos y de los sistemas informáticos incluidos en el contrato, así como a los proveedores de soluciones de “Cloud computing”… El personal que realiza la auditoría y evalúa periódicamente la competencia de un organismo o de un proveedor de servicios subcontratado, debería poseer los conocimientos, cualificaciones, experiencia y formación apropiados para evaluar los sistemas de gobierno de la integridad de los datos y detectar los problemas de validez. La evaluación y la frecuencia y enfoque de la vigilancia o de la evaluación periódica del aceptador del contrato deben estar fundados en una evaluación de riesgos documentada que incluya una evaluación de los procesos de datos. Finalmente, este documento subraya la importancia de que “las estrategias de control de la integridad de datos deberían incluirse en los acuerdos de calidad (“Quality Agreement”) junto con las disposiciones contractuales y técnicas redactadas, dado el caso, entre el ordenante y el aceptador del contrato. Éstas deberían incluir disposiciones que permitan al ordenante tener acceso a todos los datos en posesión de la organización subcontratada en relación con el producto o el servicio del ordenante, así como todos los registros de sistemas de calidad pertinentes, como el acceso del ordenante a los expedientes electrónicos, incluyendo las pistas de auditoría (“audit trails”) de los sistemas informáticos de la organización, así como todos los informes impresos y cualquier otro documento electrónico o en formato de papel pertinente.
  Cuando se recurra a terceros para la conservación de datos y documentos, deben aclararse especialmente las cuestiones de propiedad y recuperación de los datos que le pertenecen con arreglo a este acuerdo. También habrá de tenerse en cuenta la ubicación física en la que se conservan los datos, incluyendo el impacto de las leyes aplicables en ese lugar geográfico específico. En los acuerdos y contratos deberían establecerse por común acuerdo las consecuencias en caso de que el aceptador del contrato deniegue o restrinja el acceso del ordenante a los registros en su posesión. En el caso de la externalización de bases de datos, el ordenante debe velar por que los encargados del tratamiento, en particular los proveedores de servicios Cloud, sean incluidos en el acuerdo de calidad y reciban la formación apropiada sobre la gestión de registros y de datos. Sus actividades deberían ser objeto de un seguimiento regular determinado por la evaluación de riesgos.”
• US FDA⁽⁵⁾
• Se proponen recomendaciones interesantes sobre la utilización de registros y firmas electrónicas en los estudios clínicos y más particularmente sobre la utilización de los servicios de aplicaciones Cloud:- La documentación de validación, que debe definirse a partir de un enfoque basado en los riesgos, puede apoyarse en la documentación y los procedimientos de los proveedores.- Posibilidad de generar copias exactas y completas de los registros regulados.- Disponibilidad y conservación de los registros en el plazo establecido por la normativa aplicable para que los documentos puedan sean requeridos en caso de inspección.- Capacidades de archivado de la solución.- Controles de acceso y verificación de las autorizaciones concedidas a los usuarios.- Pistas de auditoría (“audit trails”) seguras, generadas por el sistema y con marcas temporales de las acciones de los usuarios y de las modificaciones aportadas a los datos.- Cifrado de los datos en reposo y en tránsito.- Modalidades de firma electrónica.- Registros de rendimiento del proveedor de servicios electrónicos y del servicio electrónico prestado.- Capacidad de vigilancia del cumplimiento del proveedor de servicios electrónicos con sus obligaciones en materia de seguridad del servicio y controles de integridad de los datos.

Proyecto de migración a Cloud de una infraestructura en el contexto de una empresa internacional

Baxter Healthcare inició en junio de 2017 un proyecto de migración de sus servidores informáticos a una arquitectura “Cloud”, lo que representa unos 450 servidores y una cartera de 20 aplicaciones GxP y 80 aplicaciones no Gxp: finanzas, ventas…

La fase de preparación duró 6 meses, concluyendo a finales de diciembre de 2017 con la elección final del proveedor Amazon Web Services (AWS), líder del mercado que satisface los criterios del contrato y que dispone de los certificados de calidad requeridos para el proyecto.
En esta fase de preparación y habida cuenta del importante número de servidores que migrar, se llevó a cabo una evaluación preliminar para clasificar los sistemas y determinar las opciones de migración:

1. Desmantelamiento. La aplicación está al final de su vida útil y puede detenerse sin dificultad para la actividad. Seguidamente se informará a los usuarios y se procederá al desmantelamiento según un procedimiento preestablecido. Para cada aplicación identificada como GxP, se elaborará un plan de desmantelamiento con un archivado de los registros GxP según el plazo legal de conservación.
2. Racionalización. Es posible combinar varias instancias de una misma aplicación para reducir la talla de la instancia. Esta combinación debe realizarse según el procedimiento de gestión de modificaciones, poniendo especial atención a la confidencialidad de los datos.
3. Alojamiento simple. La aplicación puede ser alojada en una infraestructura Cloud con mínimos cambios. Para su traslado al futuro Data Center, se aplicará el proceso de gestión de modificaciones de las aplicaciones e infraestructuras.
4. Conversión “Cloud”. La aplicación debe ser actualizada para ser alojada en la Cloud. Se aplica entonces el procedimiento de gestión del cambio de las aplicaciones con las etapas necesarias de especificación y diseño, así como las correspondientes fases de validación.

La seguridad y la integridad de los datos, centro del enfoque

En caso de desmantelamiento, existen dos opciones:

1. La base de datos se conserva en formato de sólo lectura y es posible acceder a los datos regulados mediante informes o consultas validados.
2. La aplicación se conserva en un servidor virtual para poder seguir accediendo a los datos a través de la aplicación; esta máquina virtual, que se activa únicamente en caso de auditoría o inspección, deberá ser objeto de una atención particular (vínculo entre la base de datos y la aplicación, denominación o direccionamiento IP específico…). Este modo de conservación puede ser utilizado en la mayoría de los casos a no ser que existan incompatibilidades en los sistemas de explotación.

Para cada sistema/aplicación afectado por el proyecto identificado en la base de datos de configuración (CMDB), se realiza un análisis de riesgos de Calidad para determinar el grado de validación requerido con respecto al cambio de infraestructura. Se lleva a cabo un análisis de riesgos reglamentario específico a fin de evaluar el impacto y definir posibles medidas específicas con las que garantizar la integridad de los datos, así como un análisis de riesgos de seguridad que va a definir las disposiciones de protección en la Cloud (Cloud privada virtual, autentificaciones multifactoriales, configuración de la máquina virtual (AMI)…).
El conjunto de estos análisis da lugar a un informe que va a consolidar los resultados y los medios de control de riesgos para cada sistema afectado.
A partir de ahí, pueden redactarse las especificaciones del futuro sistema (especificaciones funcionales y técnicas) que permitirán identificar la herramienta de migración a implementar.

El entorno de desarrollo se ejecuta en la plataforma Cloud y, para las aplicaciones que necesitan reconstruirse, se modificará el código de la aplicación segura en un gestor de código fuente en función de las especificaciones aprobadas. En este entorno se llevan a cabo pruebas de gran calado para evitar la aparición de anomalías en la fase de validación. Una vez concluidas estas pruebas, denominadas “dry run”, se inicializa y preaprueba una solicitud de modificación tras haber verificado la identificación y las especificaciones de la aplicación, el informe de análisis de riesgos y las especificaciones de construcción del entorno de preproducción que debe ser idéntico al comprobado en el entorno de desarrollo.

El entorno de preproducción se construye según las especificaciones aprobadas y se ponen a prueba las funcionalidades básicas y las funciones críticas de la aplicación: comunicación, interfaces, impresión, acceso a la base de datos… Los tests se registran, los errores eventuales se analizan y, tras la corrección, vuelven a ejecutarse a fin de verificar la eficacia de la medida correctiva.
Los registros de gestión del cambio se actualizan con las referencias de los tests efectuados y el informe de análisis de riesgo se aprueba con la aprobación del cambio.

El entorno de producción ya puede construirse, con comprobaciones específicas en caso necesario. Se implementa una fase de seguimiento de la aplicación en producción, y se lleva a cabo la aprobación final (cierre) del registro del cambio.

Puntos clave

Cada etapa crítica del proyecto se somete a un estricto proceso de inspección y aprobación. Las transiciones de las instancias de desarrollo hacia las instancias de verificación (QA) y después las de migración hacia las instancias de producción deben ser probadas por un comité de gestión de cambios (“Change Advisory Board” o CAB).

El proceso de gestión del cambio es el núcleo del proyecto. Se inicia un cambio para cada migración de base de datos y para cada entorno teniendo cuidado de disociar los entornos de verificación (Calidad) y de producción. Éste debe integrar un plan de contingencia (posibilidad de volver atrás) y ser aprobado por el propietario del proceso (“Business Process Owner” o BPO), el responsable de seguridad (“Chief Security Officier” o CSO) así como el representante de Garantía de Calidad (“Quality System Representative” o QSR).
Una vez realizada la migración, a la solicitud de cambio se adjunta un informe de verificación de la integridad de los datos migrados.
La automatización de determinadas fases permite un ahorro de tiempo considerable en la implementación. La verificación (tests), la gestión de desviaciones, así como la gestión del cambio son gestionadas mediante aplicaciones dedicadas. La infraestructura propuesta por Amazon permite una segregación de las responsabilidades:

• El mantenimiento de la infraestructura subyacente Cloud es garantizada por Amazon (AWS) que dispone de los medios técnicos, del personal y de las certificaciones de calidad requeridas; AWS es responsable de proteger la infraestructura que ejecuta todos los servicios disponibles en la Cloud. Esta infraestructura se compone de los equipos, del software, de la red y de las instalaciones que ejecutan los servicios Cloud AWS.
• El mantenimiento en la Cloud es responsabilidad de Baxter sin ningún cambio con respecto al proveedor de infraestructura anterior; Baxter continúa controlando el mantenimiento y la seguridad a nivel de los sistemas de explotación, aplicación, seguridad (antivirus…). Si Baxter despliega una instancia Amazon EC2, es responsable de gestionar el sistema de explotación invitado (actualizaciones y medidas correctivas de seguridad incluidas), softwares, aplicaciones y utilidades instaladas por el cliente en la o las instancias, así como de la configuración del cortafuegos proporcionado por AWS (grupo de seguridad) en cada instancia.

Así, el personal de AWS no puede acceder a la infraestructura de aplicaciones y a los datos desplegados por Baxter, preservando de esa forma su integridad y su seguridad. La localización de los datos queda garantizada y se comparte la gestión del cambio.
Por ejemplo:

• Gestión de medidas correctivas

AWS es responsable de corregir los defectos relacionados con la infraestructura, pero Baxter es responsable de corregir su o sus sistemas de explotación y aplicaciones.

• Gestión de la configuración

AWS se ocupa de la configuración de sus infraestructuras, pero Baxter debe configurar sus propios sistemas de explotación, bases de datos y aplicaciones invitadas.

• Conocimiento y formación

AWS forma a sus colaboradores y Baxter es responsable de formar a sus propios colaboradores.

En conclusión

Aunque resulta difícil anticipar beneficios económicos a corto plazo, a medio plazo (3-5 años) cabe esperar ganancias, ya que Baxter ya no tendrá que soportar la obsolescencia de los componentes de la red y de los equipos informáticos. Por otra parte, la optimización progresiva de las soluciones disponibles en la plataforma supondrá ahorros significativos en materia de costes de licencias. Este proyecto en proceso de finalización demuestra la capacidad y la viabilidad de una empresa internacional para migrar a una arquitectura Cloud sin dejar de garantizar la integridad de los datos y de las aplicaciones transferidas.