Une application auto-hébergée ou plusieurs ? Un cadre de décision pour séparer équipes et clients

Un espace de travail, un rôle et un déploiement répondent à des problèmes différents

La question ne consiste pas simplement à savoir si les personnes doivent voir des dossiers, projets ou enregistrements différents. Il s’agit de déterminer quelle limite doit être appliquée, à qui l’on fait confiance pour opérer de chaque côté de cette limite et dans quelle mesure chaque groupe doit pouvoir évoluer et se rétablir de façon indépendante.

Un rôle dans l’application régit généralement ce qu’un utilisateur authentifié peut faire. Un espace de travail, une organisation, un projet ou un conteneur logique similaire peut organiser les enregistrements et limiter les utilisateurs qui peuvent les consulter ou les modifier. Ces contrôles peuvent être efficaces lorsque l’application les met correctement en œuvre et qu’ils sont configurés, vérifiés et testés. Ils restent néanmoins des contrôles au sein d’un seul déploiement applicatif.

Un déploiement distinct constitue une limite d’infrastructure et d’exploitation. Dans une configuration basée sur des conteneurs, un projet Docker Compose (https://docs.docker.com/compose/intro/compose-application-model/) regroupe les ressources d’un déploiement et peut l’isoler d’autres installations qui utilisent des paramètres différents. Un projet distinct peut également disposer de son propre réseau par défaut. Cela n’en fait pas un hôte entièrement indépendant et ne supprime pas l’importance de l’administration de l’hôte, mais la différence est substantielle par rapport à la création d’un espace de travail supplémentaire dans la même application.

N’utilisez pas le nom d’un espace de travail comme raccourci pour désigner une architecture de sécurité. Établissez d’abord ce que l’application isole réellement ; déterminez ensuite si cette isolation correspond à la promesse faite à une équipe, un client, une entité juridique ou une autorité de régulation.

• Limite liée au rôle utilisateur : quels utilisateurs connectés peuvent effectuer quelles actions.
• Limite logique des données : quels enregistrements, projets ou espaces de travail les utilisateurs peuvent consulter dans une application unique.
• Limite de déploiement : quels services applicatifs, quelle configuration, quelles données persistantes, quels identifiants, quels itinéraires et quel calendrier de publication appartiennent ensemble.
• Limite liée à l’administrateur de l’hôte : qui peut administrer le serveur, l’environnement d’exécution des conteneurs, le stockage et la configuration de déploiement.
• Limite de restauration : quelles données peuvent être restaurées indépendamment, par qui et avec quelles conséquences pour les autres utilisateurs.

Commencez par nommer la véritable limite

Une équipe n’est pas toujours l’unité qui doit être séparée. La limite pertinente peut être une organisation cliente, une entité juridique, une unité opérationnelle avec des administrateurs distincts, un environnement de production ou une catégorie de données soumise à des exigences particulières de traitement. Une conception utile commence par une formulation en langage clair de ce qui ne doit pas franchir la limite.

Par exemple : « Le personnel du client A ne doit pas accéder aux enregistrements du client B » relève principalement d’une exigence d’accès dans l’application. « Le client A doit disposer d’un jeu de données restaurable séparément, d’intégrations lui appartenant séparément et ne pas dépendre de l’approbation des mises en production du client B » exige une limite opérationnelle plus forte. « Un client externe ne doit pas avoir à faire confiance à nos administrateurs internes pour l’accès à la configuration de son service et à ses données stockées » soulève une question de confiance en matière d’hébergement et d’administration, et non simplement une question de conception des rôles.

Lorsque des données à caractère personnel sont concernées, la gouvernance doit couvrir à la fois la prévention et la restauration. L’article 5 du RGPD (https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=EN) exige des mesures techniques ou organisationnelles appropriées protégeant contre le traitement non autorisé ou illicite ainsi que contre la perte, la destruction ou les dégâts d’origine accidentelle. Il prévoit également la limitation de la conservation : les données personnelles identifiables ne doivent pas être conservées plus longtemps que nécessaire au regard de leur finalité, sous réserve des exceptions indiquées. Des obligations différentes de conservation ou de suppression constituent souvent une raison pratique d’éviter un patrimoine de données unique et indifférencié.

• Identifiez la population protégée : personnel interne, un client, une entité juridique, une fonction réglementée ou un environnement de production.
• Indiquez la conséquence d’une erreur d’accès : désagrément, violation contractuelle, exposition d’informations confidentielles ou impact réglementaire.
• Recensez les personnes qui nécessitent des accès élevés : administrateurs de l’application, responsables des intégrations, administrateurs de l’infrastructure et personnel de support.
• Consignez si les données doivent être exportées, conservées, supprimées ou restaurées selon un calendrier différent pour chaque groupe.
• Indiquez si la limite est une préférence d’organisation ou une exigence contractuelle, juridique ou de sécurité.

Quand une instance partagée est le choix le plus simple et approprié

Une instance partagée peut être la bonne réponse lorsque les groupes travaillent réellement selon le même modèle de gouvernance. Elle centralise les mises à niveau, la supervision, l’administration de l’authentification, la configuration de l’application, les routines de sauvegarde et le support utilisateur. Elle peut aussi rendre la collaboration et le reporting entre équipes moins fragmentés lorsque le partage est intentionnel et que le modèle d’accès de l’application prend en charge les restrictions nécessaires.

Un modèle partagé est particulièrement pertinent lorsque l’organisation peut décrire et exploiter un domaine administratif unique. Les mêmes administrateurs de confiance peuvent gérer le système, un seul calendrier de publication est acceptable, les intégrations peuvent être gouvernées de manière centralisée et une restauration affectant l’ensemble de l’application constitue un événement de reprise acceptable. C’est souvent un point de départ judicieux pour les services internes d’une même organisation ayant des niveaux de sensibilité et des besoins de cycle de vie comparables.

La contrepartie est le couplage. Une modification de configuration à l’échelle de l’application, un rôle d’administrateur étendu, un identifiant d’intégration partagé ou une restauration de l’instance complète peuvent avoir des conséquences pour tous les groupes. Ce modèle n’est pas dangereux par définition ; il requiert simplement une gouvernance rigoureuse et proportionnée aux données et aux parties prenantes concernées.

• Choisissez une instance partagée lorsque la collaboration entre groupes est attendue et autorisée.
• Vérifiez que l’application possède les rôles requis et les contrôles d’isolation logique nécessaires avant d’intégrer des groupes sensibles.
• Appliquez le principe du moindre privilège aux utilisateurs ordinaires comme aux administrateurs ; n’accordez pas de larges accès administratifs par simple commodité.
• Maintenez un processus régulier de révision des accès, notamment après des changements d’effectif ou le départ d’un client.
• Traitez les mises à niveau, changements de configuration, exportations et restaurations à l’échelle de l’application comme des changements susceptibles d’affecter tous les groupes.

Quand des instances distinctes constituent généralement le choix opérationnel le plus sûr

Des instances distinctes constituent généralement le choix le plus sûr lorsque les groupes disposent de données gouvernées de manière indépendante, d’administrateurs de confiance différents, d’identifiants d’intégration incompatibles ou d’exigences distinctes en matière de cycle de vie et de restauration. Les agences rencontrent fréquemment ce cas lorsque chaque client attend ses propres utilisateurs, son domaine, ses services connectés, ses exportations de données, son processus de désengagement et son circuit d’approbation des changements.

Les instances distinctes peuvent réduire le périmètre d’impact d’une erreur de configuration ou de restauration, car chaque instance peut avoir sa propre configuration applicative et son propre périmètre de données persistantes. Elles facilitent aussi l’explication de la propriété : ce domaine, cet itinéraire, cette instance, cet ensemble d’identifiants, ce périmètre de sauvegarde et ce guide d’exploitation appartiennent à cette organisation. L’avantage n’est pas que les conteneurs éliminent tous les risques. Il réside dans le fait que les contrôles opérationnels peuvent s’aligner plus étroitement sur la véritable limite organisationnelle.

Docker recommande (https://docs.docker.com/engine/security/) que seuls des utilisateurs de confiance contrôlent le démon Docker, car ses capacités peuvent permettre de monter des répertoires de l’hôte dans des conteneurs sans limiter les droits d’accès du conteneur. Par conséquent, des applications distinctes sur un hôte partagé ne dispensent pas de gouverner l’accès des administrateurs de l’infrastructure. Le mode Rootless de Docker (https://docs.docker.com/engine/security/rootless/) peut réduire l’exposition en exécutant le démon et les conteneurs en tant qu’utilisateur non root, mais il s’agit d’une mesure de durcissement de l’hôte, et non d’un substitut à des domaines administratifs indépendants.

• Séparez par organisation lorsqu’un client nécessite des décisions indépendantes concernant la propriété, le désengagement ou la restauration.
• Séparez lorsqu’un administrateur d’un groupe ne doit pas administrer la configuration applicative d’un autre groupe.
• Séparez lorsque les identifiants, webhooks, clés API ou comptes externes doivent être détenus et renouvelés indépendamment.
• Séparez lorsque le calendrier de publication, la configuration personnalisée, la rétention ou l’approbation des changements diffèrent de manière significative.
• Allez au-delà d’instances distinctes sur un même hôte lorsque la limite requise inclut une confiance indépendante envers les administrateurs de l’infrastructure ou une isolation contractuelle plus forte.

Évaluez cinq facteurs de décision avant de choisir le modèle

Utilisez les facteurs suivants comme test pratique. Attribuez à chaque facteur, pour chaque groupe envisagé, un niveau de besoin d’indépendance faible, moyen ou élevé. Une seule exigence à haut risque peut l’emporter sur plusieurs avantages pratiques d’un modèle partagé.

L’essentiel est d’évaluer les contrôles démontrés, non les intitulés. Si l’application indique disposer d’organisations ou d’espaces de travail, testez les actions exactes qui comptent : consultation des enregistrements, recherche, exportation, invitation d’utilisateurs, modification des autorisations, administration des intégrations et suppression de données. Si une exigence ne peut être démontrée dans un environnement de test ou étayée par la documentation de l’application, considérez-la comme non satisfaite jusqu’à preuve du contraire.

• 1. Visibilité des données : les utilisateurs, administrateurs et agents de support ne peuvent-ils voir que les enregistrements qu’ils sont autorisés à traiter ? Testez la navigation directe, la recherche, les rapports, les notifications, les exportations et les actions en masse, et pas seulement l’interface utilisateur habituelle.
• 2. Accès administrateur : qui peut modifier les rôles, la configuration, le stockage, les journaux et les paramètres de déploiement ? Distinguez les rôles applicatifs de l’accès à l’hôte Docker, à l’environnement d’exécution et au stockage persistant. Appliquez la séparation des tâches et le moindre privilège lorsque cela est réalisable.
• 3. Intégrations et secrets : chaque groupe a-t-il besoin de ses propres clés API, compte de messagerie, destination de webhook, configuration d’identité ou connexion à des données externes ? Docker Compose peut accorder un secret (https://docs.docker.com/compose/how-tos/use-secrets/) uniquement aux services qui le déclarent explicitement, et le monte sous forme de fichier. Évitez de traiter les variables d’environnement comme un stockage inoffensif de secrets ; Docker avertit que des mots de passe et clés API qui s’y trouvent peuvent être exposés involontairement, notamment dans les journaux de débogage.
• 4. Indépendance du cycle de vie : chaque organisation peut-elle accepter la même fenêtre de mise à niveau, la même configuration de référence, le même processus de support et le même circuit d’approbation des changements ? Sinon, la mutualisation crée une dette de coordination.
• 5. Limites de sauvegarde et de restauration : un groupe peut-il être restauré sans revenir en arrière, exposer ou perturber un autre groupe ? La question importante est de savoir si la procédure de restauration prévue démontre la limite dont vous avez besoin.

Cartographiez le modèle d’isolation de l’application avant de vous y fier

Chaque application possède son propre modèle et les termes génériques ne suffisent pas. Avant de décider qu’une instance partagée convient, établissez une cartographie factuelle de ses contrôles. Utilisez la version et la documentation pertinentes pour le déploiement prévu, puis validez les hypothèses importantes avec des comptes de test.

Commencez par le comportement des utilisateurs ordinaires, puis élargissez l’analyse. Qu’est-ce qui définit l’appartenance ? Une personne peut-elle appartenir à plusieurs espaces de travail ? Les rôles sont-ils définis globalement ou à l’échelle d’un espace de travail ? Les utilisateurs peuvent-ils découvrir des enregistrements par la recherche, des liens, des rapports, des notifications ou des exportations en dehors du périmètre attendu ? Les écrans d’audit, d’administration et d’intégration sont-ils accessibles à une catégorie d’utilisateurs plus large que les écrans opérationnels ?

Cartographiez ensuite le parcours des données. Identifiez la base de données ou le stockage persistant, les fichiers téléchargés, les journaux applicatifs, les exportations, les destinations d’e-mails ou de webhooks et les sauvegardes. Un conteneur frontal distinct ne constitue pas une limite de restauration indépendante si deux organisations utilisent toujours le même stockage de données ou le même artefact de sauvegarde. Les recommandations de Docker sur les volumes (https://docs.docker.com/engine/storage/volumes/) comprennent des procédures d’archivage et de restauration des volumes nommés, ce qui renforce une règle de planification fondamentale : les données persistantes et une procédure de restauration testée doivent faire partie de la conception de la limite.

• Documentez séparément les rôles globaux et les rôles délimités.
• Testez le retrait d’appartenance, la désactivation d’utilisateurs, les flux d’invitation et le transfert d’administration.
• Testez la visibilité des enregistrements à travers les écrans habituels, la recherche, les API lorsque cela s’applique, les rapports générés, les notifications et les exportations.
• Identifiez où résident les pièces jointes, les journaux, les exportations et les données persistantes.
• Documentez qui peut accéder à la configuration de l’application, aux manifestes de déploiement, au stockage de l’hôte, aux sauvegardes et aux éléments secrets.
• Conservez les éléments de preuve des tests avec le dossier de décision, en particulier pour les engagements clients ou les données sensibles.

Comparez trois modèles de déploiement pratiques

Le premier modèle est une application partagée unique. Il est économiquement avantageux sur le plan opérationnel et peut bien fonctionner pour une organisation unique ou un ensemble étroitement gouverné d’équipes internes. Il repose fortement sur le modèle d’autorisation de l’application et sur une gestion rigoureuse des administrateurs globaux, de la configuration partagée, des intégrations et des procédures de restauration.

Le deuxième modèle consiste en une instance applicative par organisation. Chaque organisation reçoit sa propre configuration de déploiement, son propre périmètre de données persistantes, son nom d’hôte ou sa règle de routage, son administration applicative et son dossier opérationnel. Ce modèle offre généralement une base plus claire pour des identifiants, décisions de publication, exportations, actions de rétention et restaurations distincts. Il introduit un travail opérationnel répétitif qui doit être planifié plutôt qu’improvisé.

Le troisième modèle associe des services d’infrastructure partagés à des instances applicatives séparées. Par exemple, des projets Compose distincts peuvent utiliser (https://docs.docker.com/compose/how-tos/networking/) leurs propres réseaux spécifiques au projet pour des composants internes tels qu’une application et une base de données, tout en se connectant délibérément à un réseau partagé créé extérieurement lorsqu’une communication avec une couche périphérique ou un service de support partagé est nécessaire. Cela peut équilibrer cohérence et connectivité applicative limitée, mais l’appartenance aux réseaux et les itinéraires doivent être explicitement conçus et vérifiés.

• Une instance partagée : la meilleure option lorsque la gouvernance, l’administration, le cycle de vie et la restauration sont réellement partagés.
• Une instance par organisation : la meilleure option lorsque la propriété et les décisions opérationnelles doivent être indépendantes.
• Des services partagés avec des instances applicatives séparées : la meilleure option lorsqu’une organisation peut centraliser en toute sécurité certaines fonctions de plateforme tout en maintenant des limites distinctes pour l’application et le niveau des données.
• Pour chaque modèle, décidez explicitement si l’administration de l’hôte est partagée, restreinte ou nécessite un modèle de séparation plus fort.

Planifiez le travail opérationnel qui se multiplie avec chaque instance

Les instances distinctes réduisent certains couplages de gouvernance, mais elles augmentent l’inventaire opérationnel. Chaque instance nécessite un propriétaire identifié, un modèle d’accès, un domaine ou une règle de routage, une configuration applicative, des identifiants, un périmètre de sauvegarde, des attentes de supervision, un historique des mises à niveau et un circuit de réponse aux incidents. Une agence qui crée rapidement des instances mais ne peut pas identifier leur propriétaire ou leur procédure de restauration a créé un risque évitable.

La gestion des domaines et de TLS fait partie de ce travail. La configuration dynamique de Traefik (https://doc.traefik.io/traefik/reference/routing-configuration/dynamic-configuration-methods/) détermine comment les requêtes entrantes sont acheminées vers les services, et cette configuration peut être fournie par des mécanismes tels que les labels Docker et les fichiers. Chaque instance nécessite donc une correspondance précise et maintenue entre le nom d’hôte ou la règle et son service. Un routeur Traefik configuré pour TLS (https://doc.traefik.io/traefik/v3.2/routing/routers/) traite les requêtes HTTPS et termine TLS avant d’envoyer le trafic déchiffré au service configuré.

L’automatisation des certificats a également un cycle de vie. Let’s Encrypt applique des limites d’émission (https://letsencrypt.org/docs/rate-limits/) aux requêtes passant par son point de terminaison API de nouvelle commande. Utilisez une convention de nommage contrôlée, validez le DNS avant la mise en service, évitez de demander des certificats à répétition pendant des tests improvisés et conservez une procédure claire pour les changements de domaine.

Airbip exécute les instances applicatives comme charges de travail Docker sur des serveurs cloud Airbip et automatise le routage ainsi que les certificats TLS via Traefik et Let’s Encrypt. La plateforme fournit également des vérifications DNS, la gestion du cycle de vie des services, des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables, ainsi qu’un choix entre un sous-domaine Airbip et un domaine personnalisé compatible. Ces capacités de plateforme peuvent réduire le travail d’infrastructure répétitif, mais les clients doivent toujours définir la propriété, les accès, le traitement des données, le périmètre des sauvegardes, les procédures de restauration et le modèle de séparation approprié.

• Tenez un registre des instances : organisation, propriétaire, finalité, domaine, administrateurs, services connectés, classification des données et date de désengagement, le cas échéant.
• Utilisez une convention de domaine prévisible et vérifiez la propriété du routage avant le lancement.
• Suivez les versions de l’application, les changements de configuration et les exigences d’approbation pour chaque instance.
• Définissez des contacts de supervision et de gestion des incidents pour chaque instance ; ne supposez pas qu’une équipe centrale connaît le contexte client pertinent.
• Planifiez des tests de sauvegarde et de restauration au périmètre promis à l’organisation.
• Planifiez le travail de migration avant d’adopter des instances distinctes, notamment la manière dont les données sont déplacées, les accès basculés et les données d’origine conservées ou supprimées.