Modèle de déploiement d'application multilocataire sur OCI

Dans le monde d'aujourd'hui, les entreprises et les fournisseurs indépendants de logiciels (ISV) transforment de plus en plus les applications traditionnelles en offres de logiciel-service (SaaS). Un composant essentiel de cette transformation est le modèle de déploiement multilocataire, qui permet à plusieurs clients de partager la même application tout en assurant la sécurité, la performance et l'efficacité des coûts. Oracle Cloud Infrastructure (OCI) fournit un jeu robuste de services qui facilitent la fourniture d'applications SaaS à l'aide d'une location partagée et d'approches hybrides.

À propos des locations

Il est important de ne pas confondre la location OCI avec le concept de locataire dans une application SaaS.

Location OCI : Il s'agit du compte que vous recevez lors de votre inscription aux services OCI. Il représente votre compte racine et sert de partition isolée et sécurisée où vous organisez et gérez vos ressources OCI.

Un locataire (dans un contexte SaaS) : Supposons qu'un fournisseur de services Internet crée une plate-forme SaaS sur OCI. Lorsque l'ISV provisionne ses propres clients dans la plate-forme, chacun de ces clients est considéré comme un locataire. Un locataire dans ce sens représente une organisation client, et chaque locataire peut avoir plusieurs utilisateurs qui lui sont associés.

En bref, une location OCI fait référence au compte OCI lui-même, tandis qu'un locataire fait référence à une organisation (telle qu'un client SaaS) qui utilise une application hébergée sur OCI par une autre entité, telle qu'un fournisseur de services Internet.

Architecture

Cette architecture représente un modèle de déploiement d'applications multilocataires sur OCI, à un niveau élevé.

Le diagramme suivant illustre cette architecture de référence :


Description de multi-tenant-app-oci.png :
Description de l'illustration multi-tenant-app-oci.png

multilocataire-app-oci-oracle.zip

Cette architecture flexible est organisée en trois couches :

Couche Objet Action clé
Authentification initiale (OCI IAM) Vérifier l'identité globale Émettre un jeton Web JSON (JWT) après la validation des données d'identification
Intergiciel d'authentification Vérifier l'identité par demande Extraire le contexte du client et de l'utilisateur à partir de JWT
Crochets de couche d'accès aux données ou ORM Appliquer l'isolement des données Filtrer automatiquement toutes les interrogations par tenant_id

Chaque couche est décrite ci-après :

Établissement de l'authentification initiale et du contexte du locataire

  • Service d'authentification : L'utilisateur se connecte, généralement à l'aide d'une URL propre au locataire (par exemple, mycompany.app.com) ou en sélectionnant un locataire lors de la connexion.
  • OCI Identity and Access Management (OCI IAM) en tant que fournisseur d'identités : OCI IAM (en particulier, un domaine d'identité dédié) valide les données d'identification de l'utilisateur. De manière cruciale, il confirme que l'utilisateur n'est pas seulement valide, mais qu'il est également membre du groupe de locataires spécifique (par exemple, mycompany-users) auquel il tente d'accéder.
  • Émission JWT : Une fois l'authentification réussie, le domaine d'identité OCI IAM émet un jeton Web JSON signé. Ce jeton comprend les revendications critiques suivantes :
    • sub : Identificateur unique de l'utilisateur.
    • groupes : Tableau des OCID des groupes IAM auxquels l'utilisateur appartient. C'est la clé pour identifier le locataire.
    • Une réclamation personnalisée, telle que tenant_id ou tenant_name, peut être ajoutée à l'aide d'attributs personnalisés dans OCI IAM. (Facultatif)

Intergiciel d'authentification - Couche "Qui"

Le serveur dorsal doit être conçu pour extraire et propager le contexte de client en toute sécurité. Cette architecture prend en charge l'utilisation de la passerelle d'API OCI ou de l'équilibreur de charge OCI pour effectuer l'authentification par demande et la propagation du contexte de client.

  • Passerelle d'API OCI : Il s'agit du point d'entrée recommandé. Il peut effectuer lui-même la validation JWT, en déduisant cette responsabilité de votre code d'application. Vous la configurez pour valider la signature par rapport au point d'extrémité JWKS de votre domaine d'identité OCI IAM.
  • Équilibreur de charge OCI : Peut gérer la terminaison et le routage SSL, mais transmet le jeton JWT à l'intergiciel d'authentification pour validation.

Action : Le service de passerelle d'API OCI valide la signature et l'expiration du jeton JWT. S'il n'est pas valide, il rejette immédiatement la demande. S'il est valide, il transmet la demande au service en amont, transmettant souvent le jeton validé ou les revendications extraites dans les en-têtes (par exemple, X-USER-ID, X-TENANT-ID).

Si vous utilisez l'équilibreur de charge OCI au lieu du service de passerelle d'API OCI, le premier composant de votre système dorsal d'application doit être l'intergiciel d'authentification.

Action : Extrayez le jeton JWT de l'en-tête Authorization: Bearer <token>, vérifiez sa signature à l'aide des clés publiques d'OCI IAM, décodez les revendications et injectez les valeurs user_id et tenant_id (dérivées de la revendication de groupes) dans le contexte de demande pour toutes les couches suivantes à utiliser.

Couche d'accès aux données ou crochet ORM (Object-Relational Mapper) – " What " Layer

Cette couche insère automatiquement l'ID locataire dans chaque interrogation SQL.

  • Exemple : Un appel à getAllInvoices() est transformé en SELECT * FROM invoices WHERE tenant_id = :tenant_id.
  • Application : Il est préférable de l'appliquer à une couche d'accès aux données centralisée ou à un crochet ORM (comme Hibernate) ou à une réserve de connexions " consciente du locataire " pour éviter les erreurs humaines.
  • Hooks ORM : Mécanisme qui active l'isolement implicite réel des locataires en interceptant et en modifiant les opérations de base de données au niveau du cadre d'application.

Stratégies d'isolement des données des locataires :

Cette architecture prend en charge deux options pour isoler et protéger les données de vos locataires :

Option 1 : Niveau d'application

Hooks/Scopes ORM : Des cadres tels que Hibernate (Java), Django ORM (Python) ou Eloquent (PHP) vous permettent de définir des étendues globales qui ajoutent automatiquement le filtre de locataire à toutes les interrogations pour un modèle spécifique.

ou

Option 2 : Niveau de base de données

Vous pouvez utiliser une colonne de discriminateur, un schéma distinct par client ou une base de données distincte par client :

  • Colonne de discriminateur (la plus courante) :

    Une colonne tenant_id est ajoutée à chaque table ou document propre au locataire.

    La couche d'accès aux données (DAL) ou ORM de l'application est responsable de l'ajout automatique de la clause WHERE tenant_id = ? à chaque interrogation. Pour ce faire, il faut :

    • Modèle de référentiel : Tous les flux d'accès à la base de données passent par une classe centrale ou un jeu de classes. Ce référentiel ajoute automatiquement le filtre de locataire à chaque opération SELECT, INSERT, UPDATE et DELETE en fonction de tenant_id dans le contexte de demande courant.
    • Contexte de connexion : Pour certaines bases de données SQL (telles que Oracle HeatWave MySQL), l'application peut définir une variable de session (par exemple, SET @tenant_id = 'mycompany123';), puis l'utiliser dans des vues ou des procédures stockées. Toutefois, la couche applicative reste responsable de la définition de cette valeur par connexion.
  • Schéma par locataire :

    Chaque client dispose d'un schéma de base de données dédié au sein de la même instance de base de données.

    La logique applicative, basée sur l'ID client, doit changer le schéma courant de la connexion à la base de données.

    • Réserve de connexions par locataire : Conservez une réserve de connexions distincte pour chaque locataire, où chaque connexion est préconfigurée pour utiliser le schéma du locataire (par exemple, USE tenant_mycompany;).
    • Changement dynamique de connexion : Utilisez une réserve de connexions qui définit le schéma lors de l'extraction en fonction de la valeur tenant_id courante (par exemple, à l'aide d'une commande SET search_path TO tenant_mycompany; pour PostgreSQL).
  • Base de données par client :

    Chaque locataire a sa propre instance de base de données physiquement distincte avec le chiffrement à l'aide de sa propre clé pour les entreprises.

    L'application a besoin d'un service de consultation de données de client pour mapper un tenant_id à la chaîne de connexion de base de données correcte.

    • L'application contient des réserves de connexions à plusieurs bases de données.
    • Le DAL utilise l'ID client du contexte de demande pour obtenir la connexion correcte à partir de la réserve et exécuter l'interrogation sur la base de données du client dédié.

    Cette option présente des avantages et des inconvénients :

    • Pros : Isolement, sécurité et performance maximaux. Les locataires peuvent même utiliser des versions de base de données ou des types de moteur différents.
    • Cons : Frais généraux, coûts et complexité opérationnels les plus élevés. Les migrations de base de données et les correctifs doivent être exécutés sur chaque base de données du client.

Cette architecture implémente les composants suivants :

  • Location

    Une location est une partition sécurisée et isolée qu'Oracle configure dans Oracle Cloud lors de votre inscription à OCI. Vous pouvez créer, organiser et administrer vos ressources sur OCI dans votre location. Une location est synonyme d'une société ou d'une organisation. Habituellement, une société aura une seule location et reflétera sa structure organisationnelle au sein de cette location. Une seule location est généralement associée à un seul abonnement, et un seul abonnement ne comporte généralement qu'une seule location.

  • Service de gestion des identités et des accès pour OCI

    Le service Oracle Cloud Infrastructure Identity and Access Management (IAM) fournit un contrôle d'accès utilisateur pour OCI et Oracle Cloud Applications. L'API IAM et l'interface utilisateur vous permettent de gérer les domaines d'identité et les ressources qu'ils contiennent. Chaque domaine d'identité OCI IAM représente une solution autonome de gestion des identités et des accès ou une population d'utilisateurs différente.

  • Équilibreur de charge

    Oracle Cloud Infrastructure Load Balancer assure la répartition automatisée du trafic d'un point d'entrée unique vers plusieurs serveurs.

  • Service de passerelle d'API pour OCI

    Le service Passerelle d'API pour Oracle Cloud Infrastructure API Gateway vous permet de publier des API avec des points d'extrémité privés accessibles à partir de votre réseau et que vous pouvez exposer au réseau Internet public si nécessaire. Les points d'extrémité prennent en charge la validation, la transformation des demandes et des réponses, la CORS, l'authentification et l'autorisation, ainsi que la limitation des demandes pour les API.

  • Services Oracle Key Management Cloud

    Service de gestion des clés OCI Oracle Cloud Infrastructure (OCI) Key Management Service (KMS) est un service en nuage qui fournit une gestion et un contrôle centralisés des clés de chiffrement pour les données stockées dans OCI. OCI KMS est un chiffrement géré par le client et offre OCI Vault (chambre forte virtuelle et chambre forte privée), OCI Dedicated KMS et les services OCI External KMS.

  • Service de calcul pour OCI

    Avec le service de calcul pour Oracle Cloud Infrastructure, vous pouvez provisionner et gérer des hôtes de calcul dans le nuage. Vous pouvez lancer des instances de calcul avec des formes qui répondent à vos besoins en ressources pour l'unité centrale, la mémoire, la bande passante de réseau et le stockage. Après avoir créé une instance de calcul, vous pouvez y accéder en toute sécurité, la redémarrer, attacher et détacher des volumes, et y mettre fin lorsque vous n'en avez plus besoin.

  • Fonctions OCI

    Oracle Cloud Infrastructure Functions est une plate-forme de fonctions-service (FaaS) entièrement gérée, multilocataire, hautement évolutive et sur demande. Il est propulsé par le moteur open source Fn Project. Le service Fonctions pour OCI vous permet de déployer votre code et de l'appeler directement ou de le déclencher en réponse à des événements. Le service Service des fonctions pour OCI utilise des conteneurs Docker hébergés dans Oracle Cloud Infrastructure Registry.

  • Moteur Kubernetes pour OCI

    Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications conteneurisées dans le nuage. Vous spécifiez les ressources de calcul dont vos applications ont besoin et OKE les provisionne sur OCI dans une location existante. OKE utilise Kubernetes pour automatiser le déploiement, l'ajustement et la gestion des applications conteneurisées sur des grappes d'hôtes.

  • Oracle HeatWave MySQL

    Oracle MySQL Database Service est un service de base de données entièrement géré qui permet aux développeurs de développer et de déployer rapidement des applications natives en nuage sécurisées à l'aide de la base de données à code source libre la plus populaire au monde. Oracle HeatWave MySQL est un nouvel accélérateur d'interrogations en mémoire, intégré et haute performance pour Oracle MySQL Database Service, qui accélère la performance de MySQL pour les interrogations analytiques et transactionnelles.

  • Service Oracle NoSQL Database Cloud

    Oracle NoSQL Database Cloud Service permet aux développeurs de créer facilement des applications à l'aide de documents, de schémas fixes et de modèles de base de données clé-valeur, ce qui assure des temps de réponse prévisibles à la milliseconde près avec la réplication des données pour une haute disponibilité. Le service offre une réplication régionale active-active, des transactions ACID, une évolutivité sans serveur, une sécurité complète et une faible facturation à l'usage pour les modes sur demande et de capacité provisionnée, avec une compatibilité à 100 % avec Oracle NoSQL Database sur place.

  • Service de stockage d'objets pour OCI

    Le service de stockage d'objets pour OCI donne accès à de grandes quantités de données structurées et non structurées de tous types, notamment des sauvegardes de base de données, des données analytiques et du contenu enrichi, comme des images et des vidéos. Vous pouvez stocker des données en toute sécurité directement à partir d'applications ou de la plate-forme en nuage. Vous pouvez adapter le stockage sans que la performance ou la fiabilité des services soit affectée.

    Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archives pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.

  • Base de données Oracle Autonomous Database sans serveur

    Oracle Autonomous Database Serverless est une solution Oracle Autonomous Database. Vous disposez d'une base de données entièrement élastique où Oracle gère tous les aspects du cycle de vie de la base de données, du placement à la sauvegarde et aux mises à jour.

  • Chiffrement transparent des données

    Le chiffrement transparent des données (TDE) chiffre de manière transparente les données au repos dans Oracle AI Database. TDE est entièrement intégré à Oracle AI Database et peut chiffrer des sauvegardes de base de données complètes (RMAN), des exportations Data Pump, des espaces-tables d'application complets ou des colonnes sensibles spécifiques. Les données cryptées restent cryptées dans la base de données, qu'il s'agisse de fichiers de stockage de tablespaces, de tablespaces temporaires, de tablespaces d'annulation ou d'autres fichiers tels que les fichiers de journalisation (redo logs). Cela empêche les tentatives non autorisées d'accéder aux données de la base de données sans affecter la façon dont les applications accèdent aux données à l'aide de SQL.

Recommandations

Utilisez les recommandations suivantes comme point de départ pour concevoir votre architecture. Vos exigences peuvent différer de l'architecture décrite ici.
  • VCN

    Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard.

    Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur place ou un autre fournisseur de services infonuagiques) auquel vous avez l'intention de configurer des connexions privées.

    Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.

    Lorsque vous concevez les sous-réseaux, tenez compte du flux de trafic et des exigences de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.

  • Listes de sécurité

    Utilisez des listes de sécurité pour définir des règles de trafic entrant et sortant qui s'appliquent à l'ensemble du sous-réseau.

  • Groupes de sécurité de réseau

    Vous pouvez utiliser des groupes de sécurité de réseau pour définir un jeu de règles de trafic entrant et sortant qui s'appliquent à des cartes vNIC spécifiques. Il est recommandé d'utiliser des groupes de sécurité de réseau plutôt que des listes de sécurité, car ces derniers vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.

  • Protection d'infrastructure en nuage

    Cloner et personnaliser les recettes par défaut fournies par Oracle pour créer des recettes de détecteur et de répondant personnalisées. Ces recettes vous permettent de spécifier le type de violation de la sécurité qui génère un avertissement et les actions autorisées. Par exemple, vous pouvez détecter les seaux de stockage d'objets OCI dont la visibilité est réglée à Public.

    Appliquez Oracle Cloud Guard au niveau de la location pour couvrir la portée la plus large et réduire le fardeau administratif lié à la maintenance de plusieurs configurations.

    Vous pouvez également utiliser la fonction Liste gérée pour appliquer certaines configurations aux détecteurs.

  • Zones de sécurité

    Pour les ressources nécessitant une sécurité maximale, Oracle recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de politiques de sécurité définie par Oracle et basée sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles par l'Internet public et doivent être chiffrées à l'aide de clés gérées par le client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, OCI valide les opérations par rapport aux politiques de la recette et empêche les opérations qui violent l'une des politiques.

Points à considérer

Lorsque vous déployez cette architecture, tenez compte de ces options.

  • Performance :
    • Définir la limitation de débit basée sur le locataire pour les API
    • Utiliser des quotas de ressource Kubernetes par espace de noms dans OKE pour limiter les pods, l'UC et la mémoire par locataire
    • Tirer parti de groupes de noeuds dédiés pour les locataires à forte demande
    • Définir une taille de groupe par client sur la connexion à la base de données
  • Sécurité :
    • Les groupes OCI IAM contrôlent le locataire auquel un utilisateur peut accéder. Ceci est appliqué par le JWT.
    • Activer Oracle Cloud Guard pour détecter les configurations incorrectes
  • Coût :

    Évaluez en fonction de vos besoins d'affaires, que vous ayez besoin d'un niveau de table, de schéma ou d'une base de données dédiée pour les clients au niveau de l'entreprise. Par exemple :

    • Niveau 1 : Standard (colonne de discriminateur) : Les locataires partagent les mêmes tables/schéma.
    • Niveau 2 : Premium (Schéma par locataire) : Les locataires obtiennent un schéma dédié dans la même base de données.
    • Niveau 3 : Entreprise (base de données par locataire) : Les locataires obtiennent une instance de base de données dédiée.
  • Correctifs et mises à jour d'application

    Dans une architecture SaaS à instance unique et multilocataire, vous ne pouvez pas appliquer de correctifs à un locataire sans les appliquer à tous. Tous vos clients partagent la même base de code d'application, la même exécution et la même infrastructure. Cette réalité crée un défi important : comment déployer les mises à jour en toute sécurité, efficacement et sans causer de temps d'arrêt perturbateur pour l'ensemble de votre base d'utilisateurs? La réponse réside dans les stratégies de déploiement DevOps modernes conçues spécifiquement à cette fin : utilisez des stratégies de déploiement sans temps d'arrêt pour permettre des transitions transparentes entre les versions sans forcer les utilisateurs à se déconnecter.

    • Déploiement bleu/vert : Il s'agit de gérer deux environnements de production identiques : un environnement "bleu" (exécution de la version courante) et un environnement "vert" (exécution de la nouvelle version). Après avoir déployé et testé la nouvelle version dans Green, vous passez de manière transparente de Blue à Green. Si quelque chose ne va pas, vous revenez instantanément, faisant du repositionnement un non-événement. L'ancien environnement bleu est ensuite mis hors service.
    • Déploiement de test canari : Cette stratégie réduit les risques en effectuant un déploiement progressif. La nouvelle version est déployée sur un petit sous-ensemble contrôlé d'utilisateurs (les "canaries"). Vous surveillez de près ce groupe pour détecter les erreurs ou les problèmes de performance. Si les mesures ont l'air correctes, vous déployez progressivement la mise à jour pour plus d'utilisateurs jusqu'à ce que tout le monde soit sur la nouvelle version.

    Vous avisez les utilisateurs d'une fenêtre de mise à niveau obligatoire (par exemple, "Si aucune date de mise à niveau n'est spécifiée, la mise à niveau aura lieu automatiquement à 12h00 le dimanche, mm/dd/yyyy"). Après la fenêtre, vous arrêtez les sessions pour l'ancienne version et redirigez tout le trafic vers la nouvelle version. L'ancien code d'application est alors complètement arrêté.

  • Considérations relatives à la base de données

    Vous ne pouvez pas changer de schéma de base de données au moment exact où vous changez de version de l'application. La plupart des entreprises SaaS évitent cela en utilisant :

    • Modifications de schéma de base de données rétrocompatibles
    • Drapeaux et lunettes
    • Contrôle de version basé sur les métadonnées du client

    Cela permet au nouveau code de fonctionner en toute sécurité sur les anciennes versions du schéma pendant le déploiement, ce qui permet des migrations sans temps d'arrêt et un repositionnement instantané.

Informations complémentaires

En savoir plus sur le déploiement d'applications multilocataires.

Vérifiez ces ressources supplémentaires :

Remerciements

  • Auteur : Gururaj Mohan, architecte en nuage d'entreprise
  • Contributeurs : Joshua Stanley