Publicité en cours de chargement...
Mon camembert dans le Cloud
19 avril 2022 - 10:58,
Tribune
- Cédric CartauImaginons que je veuille me lancer dans la fabrication du camembert : je dispose d’une recette à tomber par terre, ne reste plus qu’à fabriquer, à distribuer et à vendre – ça va faire un tabac. Pour cela, il me faut un pré, des vaches, une usine pour transformer le lait en camembert et un circuit de distribution. On peut voir tous ces éléments selon une pile verticale : en bas le pré, en haut le circuit de distribution. Chaque élément de la pile (couche) fournit un service à la couche du dessus et utilise les services de la couche du dessous. Les vaches (deuxième couche) ont besoin du pré et fournissent le lait, l’usine a besoin du lait des vaches, le circuit de distribution a besoin des camemberts sortis de l’usine[1]. Les deux questions fondamentales sont : qui possède chaque couche (au sens de qui en a la propriété), et qui la manage (au sens de qui la fait fonctionner) ? Et il faut bien comprendre que toutes les solutions (combinaisons) existent.
Je peux louer un pré, y mettre mes propres vaches, contractualiser avec un fermier qui s’en occupera, utiliser ma propre usine et y faire intervenir une entreprise sous contrat, utiliser le circuit de distribution d’une entreprise tierce et y faire travailler mes propres employés (j’ai volontairement alterné dans l’exemple les couches que je possède avec celles que je « loue » : le management interne et externe). Autre solution, je peux tout posséder du sol au plafond (du pré aux magasins), ou alors je peux absolument tout louer (y compris les vaches). Ou encore tout posséder (matériel, bêtes et locaux) et tout faire opérer par des entreprises extérieures sous contrat. Toutes les combinaisons existent, chacune avec ses avantages et ses inconvénients.
Le concept de l’architecture en couches est fondamental pour comprendre le Cloud. On a tendance à considérer qu’il existe a minima, partant du bas, les couches (ou éléments techniques) suivants : le serveur (la boîte en acier ou en aluminium qui renferme les circuits électroniques), la couche de virtualisation (hyperviseur), le système d’exploitation (en général macOS, Windows ou Linux), le middleware (souvent la base de données, DB) et le couple données/application métier. Et toujours, dans ce découpage, chaque couche utilise celle du dessous et fournit des services à celle du dessus : l’OS s’installe sur un hyperviseur et permet de supporter la DB, le couple données/application s’installe sur la DB, etc.
Là encore, toutes les combinaisons existent. Je peux acheter mes propres serveurs, les stocker dans le datacenter d’une entreprise A, les faire opérer (installation hyperviseur + OS + DB) par une entreprise B, acheter une application chez une entreprise C et faire superviser le tout par une entreprise D. Ou je peux tout louer. Ou tout posséder moi-même et tout faire (opérer) moi-même (ce qui dans la terminologie usuelle s’appelle « on-premise »).
Dans les faits, c’est un peu différent : les combinaisons ne sont pas aussi variées, d’une part pour des questions de faisabilité technique et contractuelle (dans l’exemple ci-dessus, il faut contractualiser avec quatre entreprises différentes ; la simple question des frontières de responsabilité va être un cauchemar), mais surtout parce que le jour où survient un problème technique, bon courage pour l’attribution des responsabilités (dans le jeu de la patate chaude, c’est vous la patate). En pratique, on trouve principalement trois combinaisons.
Dans la première, le IaaS (infrastructure as a service), le client achète une prestation de service qui va jusqu’à la couche hyperviseur incluse, et qui comprend donc la salle informatique, le serveur et l’hyperviseur. Charge au client d’installer par dessus l’OS de son choix et les couches additionnelles qui l’intéressent (DB et applications). Dans la deuxième, le PaaS (Plateform as a service), le client achète une prestation qui va jusqu’à la base de données, charge à lui d’installer l’application de son choix. Enfin dans la troisième, le client achète une prestation qui va jusqu’à l’application incluse : c’est le SaaS (software as a service). Le client n’est même pas supposé avoir vu le datacenter, ni la marque des serveurs ni même la version de l’hyperviseur : il achète un service applicatif, point.
Il existe des variantes de ces solutions, assez courantes d’ailleurs. Si une entreprise est en rupture de mètres carrés dans son propre datacenter, rien ne l’empêche d’aller louer un local (qui sera ou non un datacenter, auquel cas elle pourra elle-même le mettre aux normes) et ensuite procéder avec ses serveurs comme avec ceux stockés dans son propre DC. Stricto sensu, ce n’est pas du Cloud, mais avec un léger parfum de Cloud tout de même : jusqu’à quelle couche faut-il remonter dans les services pour que cela soit considéré comme du Cloud ? Juste pour rire deux minutes, une SSII qui louerait des mètres carrés au sein de son DC à un hôpital pour qu’il y stocke ses serveurs (et les couches du dessus) ne relèverait pas de l’HDS : en effet les mètres carrés en question feraient l’objet d’un bail de location (il faudrait a minima une séparation physique du reste du DC, par exemple avec des grilles fermées à clé), et sur le plan strictement juridique ils seraient la propriété de l’hôpital ! Comme quoi, avec le bon découpage des couches et les bons contrats, il est possible de tordre les textes dans le sens qui vous arrange.
On trouve assez souvent des éditeurs qui proposent leurs logiciels en mode SaaS, tout en externalisant et en contractualisant eux-mêmes une prestation de type PaaS (ils gèrent les couches hautes, et le client n’est d’ailleurs même pas supposé se préoccuper de ce montage contractuel qui concerne des couches qu’il ne voit pas). On trouve assez souvent des contrats de type IaaS pour lesquels le client externalise une partie du maintien en condition opérationnelle des couches hyperviseur, OS et DB. Mais clairement, plus nombreux sont les acteurs et plus une recherche de panne va être complexe.
Il faut enfin mentionner les certifications de type HDS ou SecNumCloud, qui dans l’esprit reviennent à garantir un certain niveau de service. La logique est cependant assez différente puisque la certification HDS revient à certifier des processus internes délivrés par la DSI (l’ISO 27001 et les suivantes ainsi que l’ISO 20000 impactent des processus métiers, même si la notion de couche existe), alors que la logique SecNumCloud est plutôt de garantir un niveau de sécurité sur les couches prises en charge par l’hébergeur certifié (même si la notion de processus existe bien entendu). La certification SecNumCloud[2] est découpée selon les niveaux SaaS, PaaS, IaaS, et les chapitres collent à la certification ISO 27001 avec des ajouts de type PSSIE, etc.
Ces référentiels vont de toute manière évoluer, ne serait-ce que parce qu’ils garantissent les couches prises en charge par l’hébergeur, mais pas ce que le client met par-dessus : ils autorisent donc potentiellement la vente du camembert sorti d’une usine propre comme une salle de bloc opératoire par des vendeurs avec les mains sales. Cela étant, la démarche est tout à fait logique, autant que celle qui conduit à mettre à disposition un réseau routier sûr et à laisser aux constructeurs automobiles la responsabilité de produire des véhicules sécurisés.
Bref, le terme de Cloud recouvre des réalités très diverses, et le lecteur intéressé pourra se reporter au guide Apssis dédié à la sécurisation du Cloud[3].
[1] Les experts me pardonneront les raccourcis sur la notion de « couches », utilisée pour le besoin de la démonstration.
[2] https://www.ssi.gouv.fr/uploads/2014/12/secnumcloud-referentiel-exigences-v3.2.pdf
L'auteur
Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.
