Pratiques de conception multilocataire pour les solutions basées sur le nuage

Un modèle de locataire permet de déterminer le niveau d’isolement requis entre les ressources relatives aux données, au stockage, au réseau et au traitement. Cette approche garantit que les données et les processus de chaque locataire sont sécurisés et que les autres locataires n’y ont pas accès. Il est donc essentiel de choisir le bon modèle de locataire, en fonction des exigences non fonctionnelles en matière de sécurité, d’évolutivité et de rentabilité.

Les divers modèles de locataires ont chacun leurs avantages et leurs inconvénients. Le choix du modèle dépendra de facteurs comme le nombre de locataires, la complexité de l’application et le niveau d’isolement des données requis. Voici deux exemples de modèles contraires : a) l’instance entièrement partagée, où plusieurs locataires partagent les mêmes instances d’application (et d’autres ressources), mais où chacun dispose de son propre environnement virtuel au sein de l’instance, et b) l’instance entièrement isolée, où chaque locataire dispose de ses propres instances dédiées pour l’application, la base de données et l’infrastructure.

Les organisations peuvent déterminer une conception possible en fonction du niveau d’isolement, de personnalisation, d’évolutivité et de complexité requis, de même que du coût total, et ils choisissent souvent une solution de conception qui se situe quelque part entre les deux modèles de locataires, après avoir effectué une analyse de compromis appropriée entre diverses exigences non fonctionnelles.

Pratiques de conception

La conception de systèmes multilocataires pour le nuage nécessite une planification minutieuse, de même que la prise en compte des différents concepts de l’infonuagique et des exigences en matière de ressources.

Organisation des ressources

Les plateformes infonuagiques organisent leurs instanciations de ressources et de services en fonction d’une certaine structure organisationnelle ou hiérarchique. Lors de la planification d’une solution multilocataire, il est recommandé de définir les locataires, les divisions et les organisations qui utiliseront le système, y compris leurs divers besoins fonctionnels et non fonctionnels. En outre, il serait prudent de définir les différents groupes d’utilisateurs qui accéderont à ces ressources infonuagiques et leurs besoins en matière d’accès. Cet exercice permet de dégager un regroupement conceptuel et logique des ressources et des services, sur lequel il est possible de s’appuyer pour établir l’organisation des ressources. Une fois cette organisation établie, les groupes de ressources, les espaces de nommage ou d’autres mécanismes de regroupement propres à chaque plateforme infonuagique permettent d’identifier de manière collective les ressources propres à un locataire donné. Cette façon de faire peut simplifier la gestion des ressources et offrir une meilleure visibilité et un meilleur contrôle sur les ressources propres aux locataires. Enfin, les paramètres de configuration permettent de personnaliser le comportement de l’application ou du service pour chaque locataire, y compris les paramètres liés à la marque, au contrôle d’accès et à d’autres exigences propres au locataire.

Gestion de l’identité et de l’accès

La gestion de l’identité et de l’accès (GIA) désigne la capacité des plateformes infonuagiques à fournir des contrôles d’autorisation et d’authentification pour les utilisateurs et les services qui ont besoin d’accéder à divers services infonuagiques. Dans le cadre de la GIA, le terme « multilocation » désigne la capacité à gérer l’accès aux ressources pour plusieurs organisations ou locataires au sein d’un seul système de GIA. La mise en place d’une multilocation intégrant la GIA nécessite une approche sur plusieurs fronts qui s’appuie sur l’étape précédente de conception de l’organisation et des ressources. Un mécanisme robuste d’authentification et d’autorisation garantit que seuls les utilisateurs autorisés peuvent accéder à l’application et aux données. On peut ensuite utiliser des mécanismes de contrôle d’accès fondés sur le rôle pour accorder des permissions aux ressources, en fonction des rôles et des responsabilités du locataire, garantissant ainsi que chaque locataire n’a accès qu’aux ressources dont il a besoin et empêchant l’accès non autorisé aux ressources des autres locataires. Le système de contrôle d’accès fondé sur le rôle permet d’appliquer des contrôles d’accès stricts et d’empêcher l’accès non autorisé à des données sensibles. Les politiques GIA pour les locataires sont définies en fonction de l’architecture GIA établie; ces politiques définissent les droits d’accès et les autorisations pour les utilisateurs de chaque locataire. En fonction des définitions de ces politiques, on configure par la suite les services GIA pour appliquer les politiques et confirmer que les utilisateurs de chaque locataire ne peuvent accéder qu’aux ressources auxquelles ils sont autorisés à accéder.

Réseau

Il est essentiel de garantir l’isolement des locataires au niveau du réseau, afin d’empêcher tout accès non autorisé aux données des locataires et de garantir la sécurité du système multilocataire. Plusieurs mécanismes réseau peuvent être utilisés pour atteindre cet objectif. Les réseaux virtuels et les nuages privés virtuels (NPV) fournissent un isolement logique entre les locataires en créant un réseau virtuel pour chaque locataire, chaque NPV étant isolé des autres et présentant ses propres règles de sécurité et contrôles d’accès. En outre, les méthodes de segmentation de réseau, comme les sous-réseaux et les réseaux locaux virtuels (VLAN), permettent d’isoler davantage le trafic des locataires au sein des NPV et d’empêcher les mouvements latéraux entre les locataires. Les adresses IP privées définies au sein des NPV permettent de confiner le trafic des locataires dans leur NPV et de le garder isolé de l’Internet public.

Au-delà de la conception des NPV, les connexions à des réseaux privés virtuels (RPV) permettent une connectivité sécurisée entre les NPV et les réseaux des locataires, et garantissent que le trafic des locataires demeure sûr et isolé du trafic sur l’Internet public. Des règles de pare-feu contrôlent l’accès à chaque NPV et depuis chaque NPV, et doivent être configurées de manière à n’autoriser que le trafic autorisé et à bloquer tout autre trafic. Enfin, les règles de contrôle des accès au réseau permettent d’accorder l’accès uniquement aux appareils et aux utilisateurs autorisés et de confiance, grâce à des politiques de sécurité définies.

Application

Il existe plusieurs façons d’assurer l’isolement des ressources informatiques, en fonction du modèle de locataire et de la conception. La technologie de conteneurisation est une excellente approche pour que les processus de chaque locataire s’exécutent dans une ressource informatique distincte (ou dans des conteneurs). Les conteneurs fournissent des environnements d’exécution légers et isolés qui peuvent facilement être déployés et gérés, et être mis à la disposition d’un locataire donné en fonction des identifiants qui lui sont attribués. Les conteneurs constituent une approche de niveau intermédiaire pour l’isolement des locataires. Si toutefois un isolement complet du locataire est requis, des ressources informatiques dédiées (comme des machines virtuelles) peuvent être mises à disposition pour un seul locataire. Dans le cas d’une instance partagée, une seule application en cours d’exécution pourrait servir plusieurs locataires en répondant à toutes les demandes d’utilisateurs et de systèmes, grâce à l’inclusion d’un identifiant de locataire dans les demandes. De cette façon, l’application sait de quel locataire provient la demande et exécute la logique propre à ce locataire tout en mettant à jour les emplacements de données propres au locataire.

Au-delà des pratiques qui sous-tendent la conception des applications, il existe également des considérations propres à la mise en œuvre. La mise en œuvre de quotas de ressources vient restreindre les ressources informatiques des locataires (comme l’unité centrale et la mémoire) selon des critères prédéfinis, ce qui empêche un locataire de consommer toutes les ressources disponibles et d’avoir une incidence sur les performances des autres locataires. De plus, l’utilisation d’une approche de « bac à sable » permet d’isoler les processus de chaque locataire des autres processus s’exécutant sur le même système et d’empêcher les processus d’accéder sans autorisation à des données ou à des ressources sensibles.

Bases de données

Il est essentiel de garantir l’isolement des magasins de données au niveau des locataires, afin d’empêcher tout accès non autorisé aux données des locataires et d’assurer la sécurité et l’intégrité du système multilocataire. Le modèle de conception des locataires fournit des indications sur l’approche à adopter lors de la mise en place de la base de données. Selon l’approche de la base de données partagée, plusieurs locataires partagent le même schéma de base de données, mais chacun possède ses propres données au sein de ce schéma. Ce modèle permet d’isoler suffisamment les données entre les locataires, l’isolement étant souvent établi par l’existence de tableaux distincts pour chaque locataire ou par la mise en place d’une sécurité au niveau des lignes basée sur les identifiants des locataires. Selon l’approche du schéma partagé, plusieurs locataires partagent le même schéma de base de données et les mêmes données, mais les données sont logiquement séparées en fonction de chaque identifiant. Ce modèle assure un bon isolement des données, mais il peut être complexe à mettre en œuvre. Enfin, l’approche de la base de données séparée (pour chaque locataire) permet à chaque locataire de disposer d’un isolement complet des données, ce qui garantit le niveau le plus élevé qui soit de confidentialité et de sécurité des données. Les approches de base de données partagée et de schéma partagé sont plus rentables que l’approche de la base de données distincte, mais leur mise en œuvre est plus complexe et nécessite des tests et une validation plus exigeants.

Traitement et stockage des données

La plupart des solutions conçues pour le nuage disposent de services d’ingestion, de transformation et de stockage des données qui permettent d’extraire des données de systèmes externes pour les utiliser dans l’environnement infonuagique. Dans le contexte des pipelines d’ingestion et de transformation de données, l’isolement doit être fondé sur le locataire, y compris en ce qui a trait à l’emplacement de stockage du locataire dans les services de stockage de données. La séparation du pipeline d’ingestion et de transformation de données peut être obtenue grâce à des approches de paramétrage et de configuration, où chaque tâche d’ingestion se voit attribuer une configuration qui fournit une source spécifique au locataire, une destination et d’autres informations nécessaires. Au chapitre du stockage de données, il est possible d’utiliser des unités de stockage distinctes pour isoler complètement les données des locataires, ce qui permet d’assurer un niveau optimal de confidentialité et de sécurité des données. Comme c’était le cas auparavant, il faut faire des compromis au chapitre de la complexité et du coût de la solution, par rapport à la nécessité d’isoler complètement les locataires et de contrôler l’accès. 

Quelle que soit l’approche adoptée, la sécurité et la protection des données des locataires peuvent être renforcées par la mise en œuvre d’un chiffrement, chaque plateforme infonuagique offrant divers mécanismes de chiffrement granulaire des données. Le chiffrement des données au repos et des données en transit garantit que les données du locataire sont protégées contre tout accès non autorisé. En outre, il peut prévenir les violations de données et éviter la compromission de données sensibles et confidentielles.

Conclusions

Dans l’ensemble, la multilocation est une caractéristique importante des applications conçues pour le nuage, qui permet un partage efficace et sécurisé des ressources entre plusieurs locataires, tout en préservant la confidentialité et la sécurité des données et des processus de chacun. La multilocation permet aux fournisseurs de services d’offrir une seule application à plusieurs clients, réduisant ainsi les coûts opérationnels liés à la gestion et à la maintenance de plusieurs instances de la même application. Cette approche permet également aux clients d’adapter leur utilisation de l’application en fonction de leurs besoins, sans nécessiter des investissements importants en termes d’infrastructure ou de personnel. Les lignes directrices fournies dans cet article ne sont pas exhaustives, mais visent plutôt à lancer une discussion sur les options de conception envisageables, en fonction des besoins du locataire et du modèle de locataire établi.

Pour plus d’informations sur les pratiques de conception multi-locataires pour les solutions basées sur le cloud et sur la manière dont nous pouvons vous aider, contactez-nous.