Protéger ou sécuriser le cloud : voilà une thématique d’actualité qui met en lumière un concept devenu réalité – le cloud – et une nécessité – la sécurité. Mais au fond, cela ne représente pas un changement réel de paradigme et cela ne devrait pas être une surprise ou un challenge à surmonter : les processus métier des structures de santé sont informatisés depuis l’arrivée des ordinateurs de bureau dans les années 80, des serveurs Windows et des réseaux locaux dans les années 90 et, puis, Internet existe depuis plus de 25 ans. En toute logique, tout ceci doit être protégé, devrait déjà être protégé.

Alors qu’est-ce qui a fondamentalement changé de nos jours ? La multiplication des cyber-attaques, la pénurie de compétences dans le domaine du cloud et de la cyber-sécurité, la dépendance absolue aux technologies, la complexité croissante des logiciels et des outils, l’obsolescence programmé des systèmes d’informations de santé, l’absence de temps pour s’organiser, l’absence de budget, l’explosion du cloud et des hébergeurs HDS, la pression réglementaire et juridique, le regard médiatique, l’évidence «télétravail», la crise sanitaire, le melting-pot des générations XYZ, la peur du Cloud Act, l’hégémonie des GAFAM, la tentative de souverainisme numérique franco-européen, l’absence de capitaine d’industrie au courage éprouvé… Probablement un peu de tout cela et c’est ce qui rend le contexte anxiogène, à tout le moins, beaucoup plus qu’avant.

 

« A titre privé, les concitoyens font le job : les portes des maisons individuelles sont fermées à clé la nuit et pendant les absences, des caméras de surveillance sont installées, des assurances habitation, des assurances auto, etc. sont souscrites. Tout un chacun effectue une multitude de sauvegardes de ses photos de vacances. Pourquoi ne serions-nous pas capables de reproduire ce modèle au sein de nos hôpitaux, nos cliniques, nos EHPADs, nos maisons médicales, nos officines, nos laboratoires d’analyses… ? Pourquoi ne sommes-nous pas capables de nous organiser, de nous protéger, d’anticiper et de mettre sous surveillance les actifs critiques et sensibles que sont les données de santé ? »

 

Alors que faire ? Ne rien faire et subir une situation qui emmène inexorablement le système d’information dans le mur ou regarder les choses en face avec humilité, sérénité, courage et force de proposition et lacer un vaste programme de cyber-résilience de bout en bout ?

Commençons par le début et projetons-nous demain, en 2030, si loin et si près à la fois, en imaginant comment sera l’IT et les SIS… pour mieux revenir aux fondamentaux et nécessaires travaux préparatoires d’aujourd’hui. C’est ce voyage dans le temps qui va permettre d’apprendre du passé et d’intégrer le futur pour mieux préparer et surmonter les difficultés du présent.

 

Objectif Cloud 2030

De quoi sera faite l’infrastructure de nos systèmes d’informations de santé d’ici 10 ans et quelles en seront leurs architectures matérielles et logicielles ? D’une nouvelle technologie qui n’est pas encore sortie, d’un nouveau concept du Gartner que les industriels auront peine à imposer, d’un retour en arrière complétement souverainiste et assumé dans des « salles informatiques » au sous-sol des établissements de santé, de clouds de confiance « colorés » (bleu, blanc ou rouge) composés de recettes étoilées à base de datacenters français et de technologies américaines ou alors d’un monde fait de stratus, cyrus et autres cumulo-nimbus dont nous serons totalement prisonniers ?

La réponse, tout en étant complexe à résoudre, se trouve en fait dans la question qui contient quelques éléments de réponse. Le système d’information repose, à date, sur quatre piliers :

1. Numérique en « on-premise » : il s’agit de maintenir les applications legacy (les vieilles applications dont il faut accompagner l’inexorable fin de vie et qu’il ne faut pas chercher à moderniser tant cela pourrait paraître coûteux et fastidieux). Ce legacy est par nature non cloudifiable. La gestion des investissements (CAPEX) et notamment des amortissements en cours est également un élément à prendre en compte pour le maintien des sites client. Ensuite, une dimension politique se dessine en ce sens qu’elle impose à certains clients de localiser les données produites au sein même du site de production afin de pouvoir bénéficier d’un tampon régional par exemple.
2. Numérique en « edge computing » : il s’agit de traiter les données au plus près du lieu de production afin d’obtenir un traitement quasi-immédiat, en s’affranchissant des latences des réseaux. Pourquoi traiter une donnée dans une voiture avec un cloud à l’autre bout de la France ? Les données issues d’une voiture connectée se doivent d’être traitées en local dans l’objet même de sa production afin de pouvoir donner une information enrichie au conducteur qui ne saura/pourra attendre 10 secondes le retour de l’information pour prendre une décision. Un autre cas d’usage se trouve dans les salles d’opérations chirurgicales avec de véritables ordinateurs embarqués dans les dispositifs médicaux et restitution sur le casque virtuel du chirurgien. L’« edge computing » est la solution pour désengorger les réseaux WAN. L’enjeu des cinq ans à venir va être de le sécuriser.
3. Numérique en « cloud privé » : il s’agit ici de la possibilité de disposer d’un environnement privatif sur des infrastructures souveraines (Datacenters français et serveur français) soit en mode dédié, soit en mode mutualisé. C’est le recours aux fournisseurs de cloud disposant de capacité de sur-mesure avec une sécurité non déléguée et un service de maintien en condition opérationnelle très poussé en engagement de résultat. C’est l’assurance tranquillité pour un établissement qui va pouvoir disposer de ressources de type IaaS et/ou PaaS avec une arrivée télécom de son réseau MPLS en cœur de Datacenter, une sortie Internet dédiée ou mutualisée, un système dédié de messagerie… C’est également la possibilité d’externaliser tout ou partie de sa production et de mixer les trois modèles de cloud (IaaS, PaaS et SaaS) avec le legacy on-premise.
4. Numérique en « cloud public » : c’est la promesse de basculer des workloads applicatifs au sein d’une infrastructure mondiale mutualisée avec une puissance de calcul considérable, une richesse fonctionnelle inégalée et inégalable, l’assurance de disposer de toutes les certifications de conformité (PCI-DSS, HDS, ISO27001, …) et de consommer à la demande. C’est également le passage d’un modèle de financement de mode CAPEX (investissement avec amortissement, pas toujours simple à budgéter) en mode OPEX (fonctionnement) qu’il est possible de stopper à tout moment. Même si certaines ressources sont provisionnables sur 1, 2 ou 3 ans (Reserve Instance chez Azure) avec des ristournes importantes jusqu’à 50%, il est tout à fait possible de commander.

 

A l’instar de la fusée d’Objectif Lune, tous les éléments constitutifs du cloud hybride doivent être sécurisés, éléments techniques et humains, sous peine d’explosion en vol. Si le voyage est bien préparé, que les risques ont été mesurés, que les systèmes de décollage et d’atterrissage ont été testés, que l’équipage s’est surentraîné, que les scénarios improbables ont été imaginés et que des solutions de secours ont été mises en place et testées, le voyage sera alors une réussite.

 

L’avènement du modèle CPSP (Cloud Public Souverain de Proximité)

Les GHTs peuvent être exempts de la certification HDS ! Oui et depuis le début de l’année 2021, mais sous certaines conditions qui s’inscrivent dans un contexte encore une fois hybride et teinté de prise de risques :

• Les établissements composant le GHT doivent être considérés comme responsables conjoints, avec mention explicite dans une convention constitutive du GHT
• Le GHT (via un de ses membres, probablement l’établissement support) doit assurer lui-même au sein de ses locaux les activités d’hébergeur d’infrastructure (équivalent des niveaux 1 et 2 de la certification HDS)
• Le GHT (via l’intégralité de ses membres) doit respecter les exigences du référentiel HDS 1.0 sur les activités 1 et 2, étant entendu que ces exigences sont considérées comme les « mesures techniques et organisationnelles appropriées » au sens de l’article 32 RGPD

Cet exemple pourrait bien illustrer un beau cas d’usage de cloud hybride, voire d’un concept de cloud public souverain de proximité. En effet, les établissements seront considérés comme hébergeur d’infrastructure IT avec la possibilité de proposer une infrastructure avancée de provisionning de services IT (portail self-service, facturation à la minute, scalabilité, élasticité, métrologie, sécurité by design…). Imaginons que le matériel et l’hyperviseur soient fournis et maintenus par un prestataire qui va donc effectuer des prestations de fourniture d’infrastructure et d’infogéreur HDS. Il s’agit là d’un nouveau modèle basé sur un mélange « on-premise + edge computing + technologie cloud + services managés ». Le Maintien en Conditions de Sécurité (MCS) devient alors l’enjeu majeur de ce mélange explosif si le RACI n’est pas clairement établi et les tâches associées assumées et maîtrisées par les parties prenantes.

 

Vers une sécurité opérée et raisonnée du cloud

Externalisation du SI dans le cloud : la promesse d’un transfert du risque

Puisque les profils techniques sont rares et plus particulièrement en province, le recours à l’externalisation du SI ou de partie de SI devient inéluctable. Le client y gagne également d’un point de vue gestion et transfert des risques. Il est rassuré puisqu’il ne porte plus à lui seul la responsabilité du bon fonctionnement des locaux, des serveurs physiques… Il confie son SI en mode infogérance selon une matrice de responsabilité contractuelle. Passer à 100% cloud, c’est reporter la responsabilité ailleurs qu’au sein de l’établissement et c’est un problème de point de vue ! Seul l’analyse de risques et la position de la Direction Générale vont permettre de positionner le curseur financier et le pourcentage d’externalisation de la responsabilité. En travaillant avec un fournisseur de cloud, l’établissement de santé est-il obligé d’adopter les solutions de sécurité du fournisseur ?

• Oui si le modèle de RACI fait que le fournisseur soit en responsabilité de cette brique : la couche de sécurité impose son modèle de firewall, d’EDR, de WAF, de scanner de vulnérabilités, le tout managé; le client paie la prestation de Maintien en Conditions de Sécurité (MCS).
• Non si le client achète uniquement du IaaS et qu’il fait son affaire des briques de sécurité mais à quel prix ?!

 

La complexité de la sécurisation du cloud

En achetant un service de sécurité managé ou opéré, est-ce suffisant ? Probablement pas. L’établissement aurait intérêt à comprendre des éléments basiques de sécurité afin d’être en capacité de juger la prestation de son fournisseur, ne pas être dépendant, pouvoir et savoir analyser les configurations de sécurité sur demande (en principe, tout contrat de prestations cloud digne de ce nom prévoit la possibilité de diligenter des audits auprès du fournisseur). Dans le cas contraire, le client subit et tout peut rapidement devenir opaque. La pénurie de compétences cyber-sécurité ne joue évidemment pas en faveur de l’établissement; si trouver une compétence WAF à Paris reste encore envisageable sur du court terme, c’est carrément mission impossible en province.

 

La sécurité opérée : un choix raisonné

Même s’il elle reste une option, l’infogérance devient vite une évidence pour la structure de santé qui n’a d’autre choix que de faire confiance au fournisseur de cloud et aux prestataires d’infogérance du SI (technique, middleware, applicatif). Il faut accepter d’acheter du rêve pour se débarrasser des problèmes et accepter de ne rien pouvoir vérifier.

Quel est l’état d’esprit des établissements face à la situation de l’hébergement ? Sont-ils désabusés et/ou résignés face aux hébergeurs ? Que ce soit en mode opéré ou non, la sécurité n’est pas une option et les mécanismes de MCS sont obligatoires. Encore une fois, tout est une question de maturité, de compétences, de recette et de gestion de risques. En cas de crypto-virus paralysant complétement l’activité médicale, est-ce que la prestation de remédiation est chère ou pas ? Est-ce que cela vaut la peine d’investir ? Si, en effet, le coût de la perte de productivité se chiffre à plusieurs millions d’euros par heure d’interruption, toute interruption est critique et il n’y a pas vraiment à se poser de question sur l’investissement dans la cyber-résilience.

Si par contre, l’analyse de risques a montré que l’interruption n’avait pas de conséquence financière immédiate et que le SI peut repartir sans soucis avec les sauvegardes de la veille et au bout de 5 jours au maximum, alors là, il faut pondérer les investissements. Il faut être vigilant, voire intransigeant, à l’égard de la pression des directions métier sinon des erreurs majeures sont commises comme l’ouverture du SI à tout-va et/ou la création de fonctionnalités à l’encontre des best practices de sécurité informatique.

 

Les sept erreurs pour rater son projet cloud et sa protection

1. Faire l’impasse sur une vraie analyse de risques : « L’analyse de risques ? Pas vraiment le temps, je veux que tout soit disponible tout le temps. Et puis, chez un hébergeur de cloud HDS, c’est lui qui porte l’entière responsabilité du bon fonctionnement de mon SI. Il y a même des pénalités pour cela ! ».

Conseil n°1 : Définir le périmètre de l’externalisation, mener une analyse de risques avec une méthodologie éprouvée comme EBIOS et penser à … l’impensable.

 

2. Ne pas connaître son patrimoine IT : « Si on me demande une cartographie de mon système d’information ? Pas de soucis, j’ai un fichier Excel quasi à jour contenant la liste de mes serveurs, le nombre de vCPUs, la taille de la mémoire, la taille des disques, et la version du système d’exploitation. C’est bien suffisant dans un premier temps ! ».

Conseil n°2 : Effectuer une cartographie exhaustive des composants du SI à externaliser en commençant par la vue infrastructure pour aller jusqu’à la vue processus. Et tenir à jour cette cartographie.

 

3. Migrer son système d’information de santé à isopérimètre : « Le projet va aller vite ! C’est de toute façon pour hier… Je fais une copie de mes 20 VMs sur un NAS et l’hébergeur les intégrera dans son infrastructure. Ensuite, on passera en production. Encore un souci en moins à gérer de mon côté ».

Conseil n°3 : Profiter de l’externalisation pour mettre à niveau tout ou partie des éléments du système d’information de santé.

4. Ne pas s’intéresser à la mesure de l’expérience utilisateur : « En migrant mes applications de santé dans le cloud chez un hébergeur HDS, aux vues de la puissance des machines que j’ai commandée, cela ne pourra jamais être pire que ce que j’ai aujourd’hui dans ma salle informatique. J’ai tout prévu, augmentation de la bande passante réseau, utilisation de baies de stockage avec disques ultra rapides, migration de la base de données en Oracle 19c. C’est sûr, ça va pulser ! Les tests applicatifs, une vraie usine à gaz. ».

Conseil n°4 : Lancer un projet de mesure de l’expérience utilisateur avant, pendant et après la migration en cloud. Adopter une approche par cas d’usage métier en se focalisant sur l’application la plus visible au sein de votre structure.

 

5. Penser que c’est uniquement un projet technique : « En externalisant mes applications de santé chez un hébergeur HDS, rien ne va vraiment changer en fait. J’ai vu avec lui, je peux continuer de gérer mes VMs comme avant. Cool ! C’est un projet avant tout technique : vCPU, RAM, disques SAN, firewalls, sauvegarde, débit internet, système d’exploitation, reverse proxy… ».

Conseil n°5 : Piloter un projet Cloud en participant à la rédaction des exigences métier et en impliquant toutes les parties prenantes, à commencer par les Directions métier concernées.

 

6. Vouloir tout faire seul en pensant que c’est une source d’économie : « Je vais faire au moins cinq devis et je présenterai à ma Direction la proposition la moins chère. Les prix des services d’infogérance proposés par les hébergeurs HDS sont prohibitifs. Je vais former mes équipes à s’occuper de la sécurité, des sauvegardes, du patching des systèmes d’exploitation… et comme cela, je vais réduire mes coûts d’hébergement ! ».

Conseil n°6 : Choisir un partenaire-conseil et non un simple deviseur. Exiger un véritable contrat de confiance !

 

7. Ne pas investir au moins 10% du coût total du projet à la cyber-sécurité : « Je suis chez un hébergeur HDS, la sécurité est forcément au top, je ne crains aucune cyber-attaque donc pas besoin d’investir dans des dispositifs coûteux. J’ai l’assurance que mon hôpital ne sera pas victime de ransomwares et que je ne ferai pas la une des journaux !»

Conseil n°7 : Faire confiance en son hébergeur HDS tout en doublant la prestation d’hébergement par une prestation spécifique de cyber-sécurité avec des services de protection/détection/remédiation des menaces avancées avec des tableaux de bord de pilotage et un service d’intervention rapide en cas de cyber-attaques. Penser à l’impensable (par exemple, un Datacenter qui prend feu) et investir 10% du projet cloud dans la cyber-sécurité.

 

En 2025, le cloud (les datacenters) sera devenu banal, nous n’en parlerons plus, il sera caché ! De même que le Fog (les serveurs, les plateformes, les bases de données, la supervision, …).

Du point de vue utilisateur, seuls seront visibles deux choses : le edge (les devices) et les applications (l’usage).

 

Sébastien DEON, Directeur de l’offre santé au sein d’Adista

 

Pour découvrir le livre blanc « GUIDE D’ACCÉLÉRATION DE CONFIANCE EN SANTÉ NUMÉRIQUE »

https://www.adista.fr/guide-dacceleration-de-confiance-en-sante-numerique/

 

Pour découvrir le livre blanc « CYBERSÉCURITÉ : DE L’HYGIÈNE À LA RÉSILIENCE »

https://www.adista.fr/cybersecurite-envisager-le-meilleur-se-preparer-au-pire/

 

Pour découvrir le LIVRE BLANC « DU PRA À LA RÉSILIENCE AS A SERVICE AVEC LA MÉTHODE M.E.R.C.I. »

https://www.adista.fr/du-pra-a-la-resilience-as-a-service-avec-la-methode-m-e-r-c-i/