jeudi, 28 mars 2024

Apprenez à aimer le cloud mutualisé

Pouvez-vous faire confiance au cloud public ? La réponse est, bien évidemment, oui. Le cloud public est, à bien des égards, plus sûr que votre propre centre de données.

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é ? Un système multi-locataire n’est-il pas intrinsèquement moins sécurisé ?

Qu’est-ce que la multilocation ?

Tout d’abord, nous devons discuter de ce que nous entendons par environnements à locataires multiples et de ce que nous entendons par environnements à locataire unique. Comme vous vous en doutez, la réponse n’est pas aussi claire qu’il y paraît.

Examinons une application non cloud de base exécutée dans un centre de données. La figure 1 montre un tel système.

nuage mutualisé 01 IDG

Figure 1. Application à locataire unique.

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 un processeur, une mémoire et un matériel de stockage séparés), il est très difficile, voire impossible, que les informations du client du côté gauche interfèrent avec le client du côté droit.

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 la configuration matérielle et les logiciels appropriés installés, mis à jour et configuré. En règle générale, l’ajout d’un nouveau client est une tâche lente, lourde et extrêmement coûteuse. Du côté positif, les clients sont séparés par des murs matériels physiques.

Il s’agit du modèle d’application à locataire unique.

Virtualisation mutualisée

Comparez le modèle à locataire unique ci-dessus au modèle illustré à la figure 2.

nuage mutualisé 02 IDG

Figure 2. Modèle physique à locataire unique et virtuel à locataire unique.

Dans la figure 2, vous avez les mêmes deux clients distincts utilisant deux instances distinctes d’une application. Mais, dans ce cas, ils tournent chacun sur deux serveurs virtuels distincts, qui se trouvent en fait sur le même serveur physique. Il s’agit d’un exemple de multilocation utilisant la virtualisation de serveur, 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 les deux serveurs virtuels résident sur le même matériel physique.

Ce modèle améliore la capacité de portage des applications et de déplacement des logiciels plus facilement que le modèle à locataire unique. Désormais, lorsqu’un nouveau client embarque, vous n’avez plus besoin de configurer un tout nouveau serveur physique avec le matériel et les logiciels appropriés. Tout ce que vous avez à faire est de lancer une nouvelle instance d’un serveur virtuel. Il s’agit d’une simple commande ou d’un appel d’API, et 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.

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

Les clients sont séparés par des murs matériels virtuels. Ce sont des murs qui ressemblent à des murs matériels, mais qui sont simulés par un logiciel de virtualisation. Et bien que l’ajout de clients soit plus facile, cela nécessite toujours le lancement de nouvelles instances de serveur virtuel, ce qui consomme des ressources.

Ce modèle s’appelle le modèle à locataires multiples physiques, à locataire unique virtuel. Le nom vient du fait que chaque instance virtuelle est attribuée à un seul client avec sa propre instance de logiciel (virtual single-tenant), tandis que les instances virtuelles fonctionnent toutes sur du matériel physique partagé (physical multitenant).

Logiciel mutualisé

À présent, comparez les deux modèles ci-dessus à la figure 3.

multitenant cloud 03 IDG

FIgure 3. Multitenant physique, modèle virtuel mutualisé (alias, modèle SaaS).

Dans ce modèle, plusieurs clients partagent la même instance d’application, tous s’exécutant sur les mêmes serveurs physiques et la même infrastructure physique. Dans ce cas, le logiciel assure la séparation d’un client d’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 multilocataire physique, multilocataire virtuel. Il est mieux connu sous le nom de software en tant que modèle service (SaaS).

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

L’hébergement mutualisé est-il sécurisé ?

Le locataire unique est-il plus sûr que le locataire multiple ? C’est une question courante et une question difficile à répondre. Les deux modèles peuvent être sûrs et les deux peuvent être dangereux. Lorsqu’il s’agit de mauvais acteurs, c’est-à-dire de personnes malveillantes qui tentent d’attaquer votre logiciel, un modèle est aussi sûr que l’autre. Ils ont tous deux besoin de processus et de procédures sécurisés pour se protéger contre les 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 ? Certes, une application SaaS mutualisée mal conçue risque d’exposer les données à d’autres consommateurs qui utilisent le même environnement partagé.

Pour voir cela, jetez un œil à la figure 4.

nuage mutualisé 04 IDG

Figure 4. Les problèmes de sécurité entre clients varient en fonction du type de location.

Examinons d’abord une véritable application à locataire unique, comme illustré dans le coin supérieur gauche de la figure 4. Pour que les données d’un client soient accidentellement exposées à un autre client, les données doivent se déplacer entre les serveurs physiques. Ce n’est pas facile, et il est difficile d’imaginer comment cela pourrait arriver accidentellement. Un système à locataire unique est moins susceptible d’avoir des problèmes de sécurité accidentels.

Regardons maintenant l’application mutualisée de serveur virtuel, comme illustré dans le coin supérieur droit de la figure 4. Pour que les données soient accidentellement exposées dans ce modèle, les données doivent traverser une frontière de virtualisation forte. 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 révélé une faille dans la virtualisation des serveurs qui pourrait ont causé ce type d’exposition, mais ce défaut a été rapidement trouvé et corrigé.

Dans une véritable application multilocataire, une application SaaS, telle qu’illustrée au bas de la figure 4, il y a plus de chances qu’une erreur logicielle expose des données entre les clients. En effet, la séparation entre les clients existe entièrement dans la couche d’application, sans séparation dans le matériel sous-jacent ou la virtualisation. En théorie, un bogue logiciel pourrait exposer les données d’un autre client de manière inattendue.

C’est un risque que vous prenez. Mais en réalité, lorsque vous utilisez des applications SaaS de haute qualité d’entreprises réputées, ce risque n’est pas aussi important qu’il n’y paraît. Certes, toutes les vulnérabilités liées à l’exposition accidentelle des données entre les locataires seraient corrigées très rapidement. Beaucoup d’attention est accordée à cette question spécifique. Mais c’est une préoccupation que les clients doivent prendre en compte lorsqu’ils sélectionnent une entreprise SaaS et décident des données à leur fournir.

Pourquoi utiliser le multitenant ?

Si le locataire unique est théoriquement plus sûr que le multi-locataire, pourquoi utiliser le multi-locataire ?

Tout d’abord, comme vous pouvez le déduire des cas d’utilisation ci-dessus, les systèmes multilocataires sont plus faciles à développer et facilitent l’ajout de nouveaux clients. Le coût supplémentaire de l’ajout d’un nouveau client dans un système à locataire unique 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 supplémentaire pour 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 d’ajouter une seule ligne à une base de données. Les systèmes SaaS multi-locataires permettent aux fournisseurs d’intégrer la fonctionnalité « essayer avant d’acheter » dans leurs applications et de mettre en œuvre des niveaux vraiment gratuits tout en maintenant la rentabilité. C’est pratiquement impossible dans une application et un matériel à locataire unique.

Un système mutualisé facilite également l’ajout de ressources à une application en cours d’exécution lorsqu’elle doit gérer une charge supplémentaire. Si votre application nécessite un certain nombre de serveurs pour gérer la charge et que vous avez un pic de trafic, que faites-vous ? Pour un système avec du matériel virtuel mutualisé, vous pouvez facilement ajouter une capacité de serveur supplémentaire à la volée, en quelques secondes. Pour une véritable application à locataire unique, l’achat, l’installation et la configuration des serveurs physiques peuvent prendre des jours ou des semaines.

Étant donné que l’augmentation de la capacité d’une application à locataire unique prend tellement de temps, vous devez planifier la capacité des mois à l’avance. Vous devez deviner quels seront vos besoins et vous devez disposer d’une capacité excédentaire suffisante pour répondre aux pics inhabituels ou inattendus que vous pourriez avoir. Cette capacité excédentaire est laissée inutilisée la plupart du temps, ce qui augmente les coûts d’exploitation de votre application.

Avec un système mutualisé, vous pouvez ajouter de la capacité supplémentaire à la volée, uniquement en cas de besoin, en faisant tourner davantage de serveurs virtuels. Étant donné que le matériel d’une infrastructure mutualisée est partagé, la capacité excédentaire est amortie sur plusieurs clients.

L’avenir est multilocataire

L’avenir des applications modernes réside dans les applications mutualisées s’exécutant dans des environnements virtuels mutualisés sur des environnements matériels mutualisés. Les applications à locataire unique deviendront de moins en moins nombreuses et seront principalement réservées aux environnements de centre de données sur site. Les problèmes de sécurité des systèmes multi-locataires font simplement partie du cadre de sécurité global de toutes les applications.

L’architecture mutualisée est la base du cloud public. C’est l’épine dorsale de tous les principaux environnements d’exploitation de production, et il définit comment les applications sont construites et déployées aujourd’hui et à l’avenir.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici