quid de la localisation des données, de l’”opacité” présumée de la gestion des changements, de la confidentialité des données hébergées… ? Cet article a pour objet de présenter ce nouveau paradigme de fourniture de services applicatifs avec un exemple de migration d’infrastructure dans un environnement “Cloud” à l’échelle d’une société internationale, tout en préservant la qualité et l’intégrité des données réglementées.

Quelques définitions
Commençons par définir le terme de “Cloud computing” en reprenant la définition normalisée du NIST⁽²⁾ : Le “Cloud computing” est un modèle qui permet un accès pratique et à la demande de n’importe quel terminal connecté sur le réseau internet, à des ressources informatiques partagées et configurables (par exemple de composants réseaux, serveurs, stockage, applications et services) qui peuvent être rapidement provisionnées et activées avec un minimum d’effort de gestion et sans l’interaction du fournisseur de services.

Ce modèle est composé de cinq caractéristiques essentielles, de trois modèles de service et de quatre modèles de déploiement.

Les cinq caractéristiques essentielles

1. Un libre-service à la demande
un client peut disposer des capacités de traitement de données, telles que du temps serveur et des capacités de stockage, en fonction de ses besoins, sans nécessiter d’interaction humaine avec chaque fournisseur de services.

2. Un accès large au réseau
Les capacités sont disponibles sur le réseau internet et sont accessibles via des mécanismes standard qui favorisent l’utilisation par des plates-formes client hétérogènes légères ou plus lourdes (par exemple : téléphones mobiles, tablettes, ordinateurs portables et stations de travail).

3. Une mise en commun des ressources
Les ressources informatiques du fournisseur sont mutualisées pour servir plusieurs clients à l’aide d’un modèle à locataires multiples (“multi-tenant”), avec différentes ressources physiques et virtuelles attribuées dynamiquement et réaffectées en fonction de la demande des consommateurs. Il existe un sentiment d’indépendance de localisation, en ce sens que le client n’a généralement aucune maîtrise ou connaissance sur l’emplacement exact des ressources fournies mais peut spécifier un emplacement à un niveau d’abstraction supérieur (par exemple pays, état ou centre de données). Les ressources disponibles incluent, par exemple, le stockage, le traitement, la mémoire et la bande passante réseau.

4. Une élasticité rapide
Les capacités peuvent être provisionnées et activées de manière élastique, dans certains cas automatiquement, pour évoluer rapidement de façon croissante ou décroissante en fonction de la demande. Pour le consommateur, les capacités disponibles semblent souvent illimitées et peuvent être monopolisées en n’importe quelle quantité à tout moment.

5. Une mesure du service
Les systèmes Cloud contrôlent et optimisent automatiquement l’utilisation des ressources en exploitant une capacité de mesure à un niveau d’abstraction approprié au type de service (par exemple stockage, traitement, bande passante et comptes d’utilisateurs actifs). L’utilisation des ressources peut être surveillée, contrôlée et signalée, ce qui garantit la transparence pour le fournisseur .

Les modèles de services

• Application en tant que service (Software as a Service ou SaaS)

Ce modèle confère au consommateur la possibilité d’utiliser les applications du fournisseur fonctionnant sur une infrastructure Cloud. Les applications sont accessibles à partir de divers dispositifs clients par le biais d’une interface de client léger, telle qu’un navigateur Web (par exemple, un courrier électronique basé sur le Web) ou d’une interface programmable (API). Le consommateur ne gère ni ne maîtrise l’infrastructure Cloud sous-jacente, y compris le réseau, les serveurs, les systèmes d’exploitation, le stockage, ou même les applications individuelles, à l’exception possible des paramètres de configuration d’application spécifiques limités à l’utilisateur.

• Plate-forme en tant que service (Platform as a Service -PaaS)

Ce modèle permet au consommateur de déployer sur l’infrastructure Cloud des applications créées ou acquises par le consommateur à l’aide de langages de programmation, de bibliothèques, de services et d’outils pris en charge par le fournisseur. Le consommateur ne gère ni ne maîtrise l’infrastructure Cloud sous-jacente, y compris le réseau, les serveurs, les systèmes d’exploitation ou le stockage, mais maîtrise les applications déployées et éventuellement les paramètres de configuration de l’environnement d’hébergement des applications.

• L’infrastructure en tant que service (Infrastructure as a Service – IaaS)

Ce modèle permet au consommateur de provisionner le traitement, le stockage, les réseaux et d’autres ressources informatiques fondamentales qui lui permettent de déployer et d’exécuter un logiciel de son choix, qui peut inclure des systèmes d’exploitation et des applications. Le consommateur ne gère ni ne maîtrise l’infrastructure Cloud sous-jacente mais contrôle les systèmes d’exploitation, le stockage et les applications déployées et éventuellement un contrôle limité des composants réseau sélectionnés (par exemple des pare-feu hôtes).

Les modes de déploiement

• “Cloud privé

Dans ce mode, l’infrastructure Cloud est fournie pour une utilisation exclusive par une seule organisation comprenant plusieurs consommateurs (par exemple des unités commerciales). Il peut être détenu, géré et exploité par l’organisation, une tierce partie ou une combinaison d’entre eux, et il peut exister dans ou hors des locaux de l’organisation.

• “Cloud” communautaire

L’infrastructure Cloud est mise en oeuvre pour une utilisation exclusive par une communauté spécifique de consommateurs provenant d’organisations ayant des préoccupations communes (par exemple, la mission, les exigences de sécurité, les règles et les contraintes réglementaires). Il peut être détenu, géré et exploité par une ou plusieurs organisations de la communauté, une tierce partie ou une combinaison d’entre elles, et il peut exister dans des locaux propres ou à l’extérieur. Par exemple, les sociétés de transport aérien ont mis en oeuvre ce type de déploiement pour faciliter les nombreux échanges entre eux (réservations, facturation croisée…).

• “Cloud” public

L’infrastructure Cloud est provisionnée pour une utilisation ouverte par le grand public. Il peut être détenu, géré et exploité par un organisme commercial, universitaire ou gouvernemental, ou une combinaison d’entre eux. Il existe dans les locaux du fournisseur de Cloud.

• “Cloud” hybride

L’infrastructure Cloud est un assemblage de deux ou plusieurs infrastructures Cloud distinctes (privées, communautaires ou publiques) qui restent des entités uniques, mais sont liées par une technologie standardisée ou propriétaire qui permet la portabilité des données et des applications (par exemple l’équilibrage de charge entre des serveurs répartis).

Les principales autorités
Les principaux acteurs du marché Cloud sont confrontés à des exigences nombreuses et variées compte tenu des différents métiers et domaines qu’il servent.
Ils doivent ainsi adopter les exigences qualité les plus sévères pour satisfaire le niveau de sécurité et de confidentialité requis par les secteurs les plus exigeants (banque, santé, défense…). La plupart d’entre eux sont certifiés vis à vis des principales autorités dans ces différents domaines

• ISO 27001:2013

Norme internationale de système de gestion de la sécurité de l’information, publiée en octobre 2005 et révisée en 2013. Il s’agit du standard de sécurité le plus répandu qui spécifie les exigences relatives à l’établissement, à la mise en oeuvre, à la mise à jour et à l’amélioration continue d’un système de management de la sécurité de l’information dans le contexte d’une organisation.

• SOC 1, 2, 3

Les rapports de Contrôle d’Organisation de Service (SOC) sont préparés par un auditeur conformément aux normes de l’American Institute of Certified Public Accountants (AICPA) et sont spécifiquement destinés à évaluer les moyens de maîtrise d’une organisation de services autour de 5 facteurs de confiance : sécurité, disponibilité, intégrité du traitement et des données, confidentialité et le respect des données privées.

• PCI-DSS

La norme PCI DSS est établie par les fournisseurs de cartes de paiement et est gérée par le Conseil des normes de sécurité PCI (forum international ouvert pour l’amélioration, la diffusion et la mise en œuvre de normes de sécurité pour la protection des données de comptes). Ce standard a été créé afin d’augmenter le contrôle des informations du titulaire de la carte dans le but de réduire l’utilisation frauduleuse des instruments de paiement.

• HIPAA

Le second volet de la loi de l’Health Insurance Portability and Accountability Act (HIPAA) définit les normes américaines pour la gestion électronique de l’assurance maladie, la transmission des feuilles de soins électroniques et tous les identifiants nécessaires au programme de dématérialisation des feuilles de soins pour l’assurance maladie.

• GDPR (Global Data Privacy Regulation)

Applicable à compter du 25 mai 2018, le Règlement européen sur la protection des données impose des obligations spécifiques aux sous-traitants dont la responsabilité sera susceptible d’être engagée en cas de manquement. Ces obligations concernent tous les organismes qui traitent des données personnelles pour le compte d’un autre organisme, dans le cadre d’un service ou d’une prestation comme les prestataires de services informatiques (hébergement, maintenance, …). Les sous-traitants sont tenus de respecter des obligations spécifiques en matière de sécurité, de confidentialité et de documentation de leur activité. Ils doivent prendre en compte la protection des données dès la conception du service ou du produit et par défaut mettre en place des mesures permettant de garantir une protection optimale des données.

La plupart de ces autorités de certification ne sont pas spécifiques au métier pharmaceutique mais contiennent la plupart des exigences relatives à la sécurité des données, c’est à dire à :

• L’intégrité. Les données doivent être celles que l’on s’attend à ce qu’elles soient, et ne doivent pas être altérées de façon fortuite ou volontaire.
• La confidentialité. Seules les personnes autorisées ont accès aux informations qui leur sont destinées. Tout accès indésirable doit être empêché.
• La disponibilité. Le système doit fonctionner sans faille durant les plages d’utilisation prévues, garantir l’accès aux services et ressources installées avec le temps de réponse attendu.

Mais aussi à :

• La non-répudiation et l’imputation. Aucun utilisateur ne doit pouvoir contester les opérations qu’il a réalisées dans le cadre de ses actions autorisées et aucun tiers ne doit pouvoir s’attribuer les actions d’un autre utilisateur.
• L’authentification. L’identification des utilisateurs est fondamentale pour gérer les accès aux espaces de travail pertinents et maintenir la confiance dans les relations d’échange.

S’agissant des textes réglementaires plus spécifiquement liés au métier pharmaceutique, on trouve des références au “Cloud computing” dans les référentiels suivants :

• 21 CFR Part 11⁽³⁾

la notion de système ouvert qui est défini comme un environnement pour lequel l’accès au système n’est pas maîtrisé par les personnes responsables du contenu des enregistrements électroniques résidents dans ce système. Pour ces systèmes, le 21 CFR Part 11 préconise dans l’article 11.30 que “Les personnes qui utilisent des systèmes ouverts pour créer, modifier, maintenir, ou transmettre des enregistrements électroniques doivent employer les procédures et les moyens de maîtrise conçus pour assurer l’authenticité, l’intégrité et, le cas échéant, la confidentialité des documents électroniques du point de leur création jusqu’au point de réception. Ces procédures et moyens de maitrise comprennent ceux identifiés dans le paragraphe 11.10, et le cas échéant, des mesures supplémentaires telles que le chiffrement de documents et l’utilisation de standards de signature numériques pour assurer, en fonction des circonstances, l’authenticité, l’intégrité et la confidentialité des enregistrements”.

• OMS (WHO)⁽⁴⁾

Dans le cadre d’un accord de sous-traitance, le guide de l’OMS insiste sur la nécessité que “les responsabilités du donneur d’ordre et de l’accepteur définies dans un contrat tel que décrit dans les lignes directrices de l’OMS recouvrent complètement les processus d’intégrité des données des deux parties couvrant le travail externalisé ou les services fournis… Ces responsabilités s’étendent à tous les fournisseurs de services informatiques, les centres de données, le personnel de maintenance des bases de données et des systèmes informatiques sous contrat, ainsi que les fournisseurs de solutions de “Cloud computing”… Le personnel qui audite et évalue périodiquement la compétence d’un organisme ou d’un fournisseur de services sous contrat devrait posséder les connaissances, les qualifications, l’expérience et la formation appropriées pour évaluer les systèmes de gouvernance de l’intégrité des données et détecter les problèmes de validité. L’évaluation et la fréquence et l’approche de la surveillance ou de l’évaluation périodique de l’accepteur du contrat doivent être fondées sur une évaluation des risques documentée qui comprend une évaluation des processus de données. Enfin, ce document insiste sur l’importance que “les stratégies prévues de contrôle de l’intégrité des données devraient être incluses dans les accords de qualité (“Quality Agreement”) et les dispositions contractuelles et techniques écrites, le cas échéant, entre le donneur d’ordre et l’accepteur du contrat. Celles-ci devraient inclure des dispositions permettant au donneur d’ordre d’avoir accès à toutes les données détenues par l’organisation sous contrat en rapport avec le produit ou le service du donneur d’ordre, ainsi que tous les enregistrements de systèmes de qualité pertinents. Cela devrait inclure l’accès du donneur d’ordre aux dossiers électroniques, y compris les pistes de vérification (“audit trail”), détenus dans les systèmes informatisés de l’organisation, ainsi que tous les rapports imprimés et autres documents papier ou électroniques pertinents.
Lorsque la conservation de données et de documents est confiée à un tiers, une attention particulière devrait être accordée à la compréhension de la propriété et de la récupération des données détenues dans le cadre de cet arrangement. L’emplacement physique dans lequel les données sont conservées, y compris l’impact des lois applicables à cet emplacement géographique, devrait également être pris en compte. Les accords et les contrats devraient établir des conséquences mutuellement convenues si l’accepteur du contrat refuse ou limite l’accès du donneur d’ordre aux enregistrements détenus par l’accepteur du contrat. Lors de l’externalisation des bases de données, le donneur d’ordre doit veiller à ce que les sous-traitants, en particulier les fournisseurs de services Cloud, soient inclus dans l’accord de qualité et soient correctement formés à la gestion des enregistrements et des données. Leurs activités devraient faire l’objet d’un suivi régulier déterminé par l’évaluation des risques.”

• US FDA⁽⁵⁾

Des recommandations intéressantes sur l’utilisation des enregistrements et signatures électroniques dans les études cliniques et plus particulièrement sur l’utilisation des services applicatifs dans le Cloud sont proposées :

Un projet de migration d’infrastructure dans le Cloud à l’échelle d’une société internationale
Baxter Healthcare a initié dès juin 2017, un projet de migration de ses serveurs informatiques sur une architecture “Cloud”ce qui représente environ 450 serveurs et un portefeuille de 20 applications GxP et 80 applications non GxP : finances, ventes…

La phase de préparation a duré 6 mois pour se terminer fin décembre 2017 avec à la clé le choix du prestataire Amazon Web Services (AWS), leader du marché et fournisseur remplissant les critères de l’appel d’offres et disposant des certifications qualité requises pour un tel projet.
Durant cette phase de préparation et compte tenu du nombre important de serveurs à migrer, une évaluation préliminaire a permis de classer les systèmes et de déterminer les options de migration possibles selon les possibilités suivantes :

1. Décommissionnement. L’application est en fin de vie et peut être arrêtée sans difficulté pour le métier. Les utilisateurs en sont informés et l’infrastructure sera décommissionnée selon une procédure préétablie. Pour chaque application identifiée comme GxP, un plan de décommissionnement sera produit avec un archivage des enregistrements GxP requis pour la durée de rétention légale.
2. Rationalisation. Il est possible de combiner plusieurs instances d’une même application afin de réduire la taille de l’instance. Cet effort de mutualisation doit être réalisé selon la procédure de gestion des modifications avec un point d’attention important sur la confidentialité des données.
3. Hébergement simple. L’application peut être hébergée dans une infrastructure Cloud avec un minimum de changement. Le processus de gestion des modifications des applications et des infrastructures sera appliqué lors du déplacement vers le futur Data Center.
4. Conversion “Cloud”. L’application doit être mise à niveau pour être hébergée dans le Cloud. Un projet est initié selon la procédure de gestion du changement des applications intégrant les étapes nécessaires de spécifications et de conception, ainsi que les phases induites de validation.

La sécurité et l’intégrité des données au coeur de la démarche
Dans le cas du décommissionnement des systèmes, les deux options suivantes sont pratiquées :

1. La base de données est conservée en lecture seule et il est possible d’accéder aux données réglementées via des rapports ou requêtes validées.
2. L’application est conservée sur un serveur virtuel afin de conserver l’accès aux données via l’application ; cette machine virtuelle qui est activée uniquement sur demande en cas d’audit ou d’inspection devra faire l’objet d’attention particulière (lien entre la base de données et l’application, nommage ou adressage IP spécifique…). Ce mode de conservation peut être utilisé dans la plupart des cas à l’exception des incompatibilités des systèmes d’exploitation.

Pour chaque système/application concerné par le projet identifié dans la base de données de configuration (CMDB), une analyse de risque Qualité est réalisée pour déterminer le degré de validation requis vis à vis du changement d’infrastructure. Une analyse de risques réglementaire spécifique est conduite pour évaluer l’impact et définir des mesures spécifiques éventuelles pour garantir l’intégrité des données ainsi qu’une analyse de risque sécurité qui va définir les dispositions de sécurisation dans le Cloud (Cloud privé virtuel, authentifications multi-facteurs, configuration de la machine virtuelle (AMI)…).
L’ensemble de ces analyses donne lieu à un rapport qui va consolider les résultats et les moyens de maîtrise des risques pour chaque système concerné.
La démarche projet peut alors se dérouler avec l’écriture des spécifications du futur système (spécifications fonctionnelles et techniques) qui permettront d’identifier l’outil de migration qui sera mis en oeuvre.

L’environnement de développement est réalisé sur la plateforme Cloud et, pour les applications nécessitant une reconstruction, le code de l’application sécurisé dans un gestionnaire de code source est modifié en fonction des spécifications approuvées. Des tests importants sont réalisés sur cet environnement pour éviter l’apparition d’anomalies en phase de validation. Une fois les tests dits de “dry run” finalisés et concluants, une demande de changement est initialisée et pré-approuvée après avoir vérifié l’identification et les spécifications de l’application, le rapport d’analyse de risques et les spécifications de construction de l’environnement de qualification qui doit être identique à celui vérifié en environnement de développement.

L’environnement de qualification est construit selon les spécifications approuvées et l’application est qualifiée sur les fonctionnalités de base et les fonctions critiques : communication, interfaces, impression, accès base de données…). Les tests sont enregistrés et les erreurs éventuelles sont analysées et, après correction, des tests sont ré-exécutés afin de vérifier l’efficacité de l’action corrective.
Les enregistrements de gestion du changement sont mis à jour avec les références des tests effectués et le rapport d’analyse de risque est approuvé avec l’approbation du changement.

L’environnement de production peut alors être construit et des vérifications spécifiques peuvent être réalisées si nécessaire. Une phase de suivi de l’application en production est mise en place et l’approbation finale (clôture) de l’enregistrement de changement est faite.

Points clés
Chaque étape critique du projet est soumise à une gestion stricte de revue et d’approbation. Les transitions des instances de développement vers les instances de vérification (QA) puis celles de migration vers les instances de production sont soumises à l’approbation d’un comité de gestion du changement (“Change Advisory Board” ou CAB).

Le processus de gestion du changement est au coeur du projet. Un changement est initié pour chaque migration de base de données et pour chaque environnement en prenant soin de dissocier les environnements de vérification (Qualité) et de production. Celui-ci doit intégrer un plan de secours (retour arrière possible) et être approuvé par le propriétaire du processus (“Business Process Owner” ou BPO), le responsable de la sécurité (“Chief Security Officier” ou CSO) ainsi que le représentant de l’Assurance Qualité (“Quality System Representative” ou QSR).
Une fois la migration réalisée, un rapport de vérification de l’intégrité des données migrées est attaché à la demande de changement.
L’automatisation de certaines phases permet un gain de temps appréciable dans la mise en œuvre. La vérification (tests), la gestion des écarts ainsi que la gestion du changement sont gérées via des applications dédiées. L’infrastructure proposée par Amazon permet une ségrégation des responsabilités :

• La maintenance de l’infrastructure sous-jacente Cloud est assurée par Amazon (AWS) qui dispose des moyens techniques, du personnel et des certifications qualité requises ; AWS est responsable de la protection de l’infrastructure exécutant tous les services proposés dans le Cloud. Cette infrastructure est composée du matériel, des logiciels, du réseau et des installations exécutant les services Cloud AWS.
• La maintenance dans le Cloud est de la responsabilité de Baxter sans aucun changement par rapport au fournisseur d’infrastructure précédent ; Baxter reste maître de la maintenance et de la sécurité au niveau des systèmes d’exploitation, application, sécurité (antivirus…). Si Baxter déploie une instance Amazon EC2, il est responsable de la gestion du système d’exploitation invité (mises à jour et correctifs de sécurité compris), des logiciels, applications et utilitaires installés par le client sur la ou les instances, ainsi que de la configuration du pare-feu fourni par AWS (groupe de sécurité) sur chaque instance.

Ainsi aucun accès au personnel AWS n’est possible sur l’infrastructure applicative et les données déployées par Baxter préservant ainsi leur intégrité et leur sécurité. La localisation des données est garantie et la gestion du changement est partagée.
Par exemple :

• Gestion des correctifs

AWS est responsable de la correction des défauts liés à l’infrastructure, mais Baxter est responsable de la correction de son ou des systèmes d’exploitation et applications.

• Gestion de la configuration

AWS entretient la configuration de ses infrastructures, mais Baxter doit configurer ses propres systèmes d’exploitation, bases de données et applications invités.

• Connaissance et formation

AWS forme ses collaborateurs et Baxter est responsable de la formation de ses propres collaborateurs.

En conclusion
S’il est difficile d’anticiper des bénéfices financiers à court terme, des économies sont à attendre à moyen terme (3-5 ans) car Baxter n’a plus à supporter l’obsolescence des composants réseau et du matériel informatique. Par ailleurs, l’optimisation progressive des solutions disponibles sur cette plateforme permettra des gains sensibles au niveau des coûts de licences. Ce projet en cours de finalisation démontre la capacité et la faisabilité, à l’échelle d’une société internationale, de migrer sur une architecture Cloud tout en garantissant l’intégrité des données et des applications transférées.