Faut-il faire confiance au cloud public ? La réponse est oui bien sûr. Le cloud public est, à bien des égards, plus sûr que votre propre datacenter. Mais le fait que plusieurs clients partagent le même matériel physique ne crée-t-il pas un problème de sécurité ? Tout système multi tenant n'est-il pas intrinsèquement moins sûr ? Tout d'abord, il convient de s’entendre sur les termes environnement multi tenant et single tenant. Comme vous vous en doutez, la réponse n'est pas aussi tranchée qu'il n'y paraît. Prenons l'exemple d'une application non cloud de base fonctionnant dans un datacenter. Le schéma suivant illustre un tel système.

Schéma 1 : modèle single tenant d'infrastructure. (Crédit : IDG)

Vous voyez ici deux clients, chacun exécutant une instance distincte d'une application sur des serveurs physiques distincts et séparés. Les deux serveurs peuvent se trouver dans le même centre de données et partager la même infrastructure réseau, mais ils ne partagent aucune autre ressource physique. Comme ils exécutent tous deux des instances informatiques distinctes (avec des serveurs, de la mémoire et des baies de stockage séparés), il est très difficile, voire impossible, que les informations du client de gauche interfèrent avec celles du client de droite.

Cependant, si vous souhaitez ajouter un troisième client à cette configuration, vous avez besoin d'une troisième instance de l'application, ce qui nécessite l'achat et la configuration d'un troisième serveur physique, avec le matériel et les logiciels appropriés installés, mis à jour et configurés. En général, l'ajout d'un nouveau client est une tâche lente, fastidieuse et extrêmement coûteuse. D'un autre côté, les clients sont séparés par des murs de matériel physique. C'est le modèle d'application sur un environnement single tenant avec sa propre base données.

La virtualisation multi tenant

Comparez le modèle single tenant ci-dessus avec le modèle illustré dans le second schéma.

Schéma 2 : modèle multi tenant couplé à de la virtualisation de serveurs. (Crédit : IDG)

Dans cette configuration, vous avez les deux mêmes clients qui utilisent deux instances distinctes d'une application. Mais, dans ce cas, elles fonctionnent chacune sur deux serveurs virtuels propres, qui se trouvent en fait sur le même serveur physique. Il s'agit d'un exemple de colocation utilisant la virtualisation des serveurs, qui est utilisée depuis la fin des années 80 et le début des années 90. L'idée est que chaque application réside sur un serveur « logique » distinct, mais que les deux serveurs virtuels se trouvent sur le même matériel physique.

Ce modèle améliore la possibilité de porter des applications et de déplacer des logiciels plus facilement que le modèle à locataire unique. Désormais, lorsqu'un nouveau client vous rejoint, vous n'avez pas besoin de configurer un tout nouveau serveur physique avec le matériel et les logiciels adéquats. Il vous suffit de lancer une nouvelle instance d'un serveur virtuel. Il s'agit d'une simple commande ou d'un appel API, et c'est généralement facile à faire. Tant que le serveur physique a une capacité suffisante, vous pouvez lancer plusieurs serveurs virtuels avec un simple appel API. Un nouveau matériel n'est nécessaire que lorsque des ressources physiques supplémentaires sont requises.

Le multi tenant, un modèle soutenable

En fait, ce modèle est si puissant qu'il a été à la base des débuts du cloud computing. La virtualisation des serveurs a permis aux fournisseurs de cloud computing de vendre des instances de serveurs virtuels directement aux entreprises, et de leur permettre de lancer et d'arrêter des instances à la demande. C'est la base du service EC2 d'AWS, puis des services équivalents de Microsoft Azure, Google Cloud Platform et d'autres clouds publics. De nouvelles instances peuvent être louées aux clients pour une période donnée, puis libérées pour être mises à la disposition d'autres entreprises.

Les clients sont séparés par des murs matériels virtuels. Il s'agit de murs qui ressemblent à des murs matériels, mais qui sont simulés par un logiciel de virtualisation. Et si l'ajout de clients est plus facile, il nécessite toujours le lancement de nouvelles instances de serveurs virtuels, ce qui consomme des ressources. Ce modèle est appelé le modèle « multi tenant physique, single tenant virtuel ». Le nom vient du fait que chaque instance virtuelle est attribuée à un seul client avec sa propre instance de logiciel, tandis que les instances virtuelles fonctionnent toutes sur du matériel physique partagé.

Le modèle SaaS, facile et peu onéreux

Un autre modèle existe : le modèle multi tenant. Dans ce modèle, plusieurs clients partagent la même instance d'application avec une base de données partagée, qui fonctionne sur les mêmes serveurs et la même infrastructure. Dans ce cas, le logiciel assure la séparation d'un client par rapport à un autre - il n'y a pas de séparation physique. Les clients ne sont séparés que par le logiciel. Ce modèle est appelé le modèle multitenant. Il est plus connu sous le nom de modèle SaaS.

Schéma 3 : modèle multi tenant adossé à des applications SaaS. (Crédit : IDG)

Dans ce cas, l'ajout d'un client est très facile. Aucun matériel virtuel ou physique n'est nécessaire. Tant que le matériel sous-jacent dispose de ressources suffisantes, vous pouvez ajouter un client supplémentaire en mettant simplement à jour une base de données ou en ajoutant une entrée dans un fichier de configuration. L'ajout de clients est rapide, facile et peu coûteux.

Le multi tenant est-il sûr ?

Le locataire unique est-il plus sûr que le colocataire multiple ? Il s'agit d'une question courante à laquelle il est difficile de répondre. Les deux modèles peuvent être sûrs et les deux peuvent être dangereux. Lorsqu'il s'agit d'acteurs malveillants, de personnes mal intentionnées qui tentent d'attaquer le logiciel, les deux modèles se valent. Ils nécessitent tous deux la mise en place de processus et de procédures sécurisés pour se protéger des mauvais acteurs. Mais qu'en est-il des failles de sécurité accidentelles ? Qu'en est-il, par exemple, de l'exposition accidentelle des données d'un client à un autre client ? Il est certain qu'une application SaaS multi tenant mal conçue risque d'exposer les données à d'autres consommateurs qui utilisent le même environnement partagé. Pour s'en convaincre, il suffit de jeter un coup d'œil au schéma suivant.

Schéma 4 présentant les problèmes de sécurité inter-clients varient en fonction du type de location. (Crédit : IDG)

Examinons tout d'abord une véritable application à locataire unique, comme celle illustrée dans la partie supérieure gauche du schéma ci-dessus. Pour que les données d'un client soient accidentellement exposées à un autre client, elles doivent être déplacées entre les serveurs physiques. Ce n'est pas facile, et il est difficile d'imaginer comment cela pourrait se produire accidentellement. Un système à locataire unique est moins susceptible d'avoir des problèmes de sécurité accidentels.

L'application multi tenant sur serveur virtuel, illustrée dans la partie supérieure droite du schéma diffère légèrement. Pour que les données soient accidentellement exposées dans ce modèle, elles doivent traverser une frontière de virtualisation solide. Bien qu'il soit difficile d'imaginer que cela se produise, ce n'est pas impossible. En fait, il y a quelques années, les vulnérabilités Meltdown et Spectre ont mis en évidence une faille dans la virtualisation des serveurs qui aurait pu provoquer ce type d'exposition, mais cette faille a été corrigée.

Le Saas entraîne plus de risques

Dans une véritable application multitenant - une application SaaS - comme celle illustrée au bas du schéma, il y a plus de chances qu'une erreur logicielle expose les données entre les clients. En effet, la séparation entre les clients se situe entièrement dans la couche applicative, sans séparation dans le matériel sous-jacent ou la virtualisation. En théorie, un bug logiciel pourrait exposer les données d'un autre client de manière inattendue.

C'est un risque à prendre. Mais en réalité, lorsqu’un client utilise des applications SaaS de haute qualité provenant d'entreprises réputées, ce risque n'est pas aussi important qu'il n'y paraît. Il est certain que toute vulnérabilité liée à l'exposition accidentelle de données entre locataires sera corrigée très rapidement. On accorde beaucoup d'attention à ce problème spécifique. Mais il s'agit d'une préoccupation que les clients doivent prendre en compte lorsqu'ils choisissent une société SaaS et décident des données à lui confier.

Pourquoi utiliser le multi tenant ?

Si le  single tenant est théoriquement plus sûr que le multi tenant, pourquoi utiliser le multi tenant ? Tout d'abord, au vu des cas d'utilisation ci-dessus, les systèmes multi tenant sont plus faciles à développer et permettent d'ajouter plus facilement de nouveaux clients. Le coût différentiel de l'ajout d'un nouveau client dans un système single tenant est très élevé, car il comprend le coût du nouveau matériel, de l'installation, de la configuration, de la maintenance, des logiciels, des mises à niveau, etc. En revanche, le coût marginal d'un nouveau client dans un véritable système SaaS multi tenant est presque nul ; l'intégration peut littéralement être aussi simple que l'ajout d'une seule ligne dans une base de données. Les systèmes SaaS multi tenant permettent aux fournisseurs d'intégrer à leurs applications la fonctionnalité « essayer avant d'acheter » et de mettre en place des niveaux réellement gratuits tout en maintenant la rentabilité. Ceci est pratiquement impossible dans une application et un matériel single tenant.

Un système multi tenant permet également d'ajouter beaucoup plus facilement des ressources à une application en cours d'exécution lorsqu'elle doit gérer une charge supplémentaire. Si une application nécessite un certain nombre de serveurs pour gérer la charge et que l’utilisateur note un pic de trafic, il est possible d’ajouter une capacité de serveur supplémentaire à la volée, en quelques secondes dans le cas d'un système doté d'un matériel multi tenant virtuel. Pour une véritable application à locataire unique, il faut parfois des jours ou des semaines pour acheter, installer et configurer des serveurs physiques. Comme il faut beaucoup de temps pour augmenter la capacité d'une application à locataire unique, il faut planifier la capacité des mois à l'avance. L’utilisateur doit deviner quels seront ses besoins et doit disposer d'une capacité excédentaire suffisante pour faire face à tout pic inhabituel ou inattendu. Cette capacité excédentaire reste inutilisée la plupart du temps, ce qui augmente les coûts d'exploitation de l’application. Avec un système multitenant, il est possible d’ajouter de la capacité supplémentaire à la volée, uniquement en cas de besoin, en faisant tourner plus de serveurs virtuels. Comme le matériel d'une infrastructure multitenant est partagé, la capacité excédentaire est amortie sur plusieurs clients.

L'avenir est au multi tenant

L'avenir des applications modernes est fait d'applications multi tenant fonctionnant dans des environnements virtuels. Les applications à locataire unique deviendront de plus en plus rares et seront principalement réservées aux environnements de centres de données sur site, généralement en mode bare metal pour optimiser les performances. Les problèmes de sécurité des systèmes multi tenant font simplement partie du cadre de sécurité global de toutes les applications. La colocation est la base du cloud public. C'est l'épine dorsale de tous les principaux environnements d'exploitation de production, et elle définit la manière dont les applications sont créées et déployées aujourd'hui et à l'avenir. enfin, depuis plus de 15 ans, un débat fait rage autour du cloud : certains puristes considèrent que le vrai cloud ne peut être que multi tenant, et le mode single tenant un simple service managé.