Un environnement de préproduction plus sûr pour les applications auto-hébergées : isolation, données et effets secondaires

Commencez par définir l’objectif de la préproduction

Un environnement de préproduction pour une application auto-hébergée permet de tester une modification prévue avant sa mise en production. La configuration adaptée dépend de ce que vous devez vérifier : le bon fonctionnement d’une configuration, le comportement attendu d’une intégration, la possibilité de réaliser une mise à jour ou l’adéquation d’un flux de travail pour les utilisateurs.

Définissez l’objectif du test avant de créer ou d’actualiser l’environnement de préproduction. La vérification d’une configuration peut ne nécessiter qu’un petit ensemble d’enregistrements représentatifs. Un test d’intégration peut nécessiter un compte de test auprès du service externe. Un test d’acceptation utilisateur peut demander des rôles et des flux de travail réalistes, mais pas de véritables identités de clients.

Évitez de considérer par défaut la préproduction comme un deuxième système de production. Reproduisez les composants et le comportement nécessaires au test, et isolez ou remplacez tout ce qui pourrait entraîner des effets concrets dans le monde réel.

• Quelle modification ou quel flux de travail est testé ?
• Quel résultat permettra de considérer le test comme réussi ?
• Quelles dépendances de production faut-il représenter pour que ce résultat soit pertinent ?
• Quelles actions la préproduction ne doit-elle jamais effectuer sur de vrais utilisateurs, de l’argent ou des dossiers métier ?

Cartographiez les dépendances avant de copier l’environnement

Dressez la liste des dépendances de l’application et classez chacune comme indispensable, simulée ou volontairement indisponible en préproduction. Pensez à la base de données, au stockage de fichiers, aux services d’identité et de connexion, à l’envoi d’e-mails, au traitement des paiements, aux webhooks, aux tâches planifiées, aux API externes, au DNS et à tout système recevant des données de l’application.

Demandez-vous ensuite ce que signifie la parité avec la production pour le test concerné. Reproduire la configuration de l’application ou la structure du déploiement peut être utile ; copier tous les enregistrements et toutes les connexions de production n’est ni automatiquement utile ni sans risque. Docker documente l’utilisation de configurations Compose propres à chaque environnement, notamment pour la préproduction et la production, avec des ports, des variables d’environnement et des paramètres de services externes différents.

Consignez chaque différence intentionnelle. Par exemple, la préproduction peut utiliser une base de données et un domaine distincts, des identifiants de test, des actions planifiées désactivées ou un substitut à un service externe. Cela facilite l’interprétation des résultats et la réévaluation de ces différences lorsque l’application ou ses dépendances évoluent.

• Dépendance : à quoi l’application se connecte-t-elle ?
• Besoin du test : quel comportement faut-il reproduire ?
• Choix pour la préproduction : service de test réel, substitut contrôlé ou connexion désactivée ?
• Risque en cas de mauvaise configuration : qu’est-ce qu’un test pourrait envoyer, exposer ou modifier ?

Séparez les instances, les domaines, les identifiants et les autorisations

Attribuez à la préproduction sa propre instance applicative et ses propres espaces de stockage persistant, au lieu de la connecter aux ressources de production. Utilisez un domaine ou sous-domaine de préproduction clairement distinct et vérifiez que le routage l’envoie vers le service de préproduction. Par exemple, les routeurs Traefik peuvent faire correspondre les requêtes selon le nom d’hôte et les transmettre à un service configuré ; la règle liée au nom d’hôte doit correspondre à l’environnement visé.

Utilisez des identifiants propres à la préproduction pour la base de données, l’application et les services externes. Ne copiez pas les secrets de production dans l’environnement de préproduction sous prétexte que le reste de la configuration de déploiement est similaire. Les secrets Docker Compose peuvent être attribués explicitement aux services, ce qui permet de limiter les services qui peuvent y accéder.

Examinez les autorisations d’accès avec autant de soin que l’infrastructure. Limitez l’accès à la préproduction aux personnes qui en ont besoin et utilisez, lorsque c’est possible, des comptes et des rôles distincts. Un environnement de préproduction n’est pas automatiquement privé simplement parce qu’il a un nom ou une URL différents. Vérifiez son authentification, son routage et son exposition réseau avant de communiquer son adresse.

Vérifiez comment les ports sont publiés. Docker précise que les ports publiés peuvent être accessibles via les adresses réseau de l’hôte ; lier un port à une interface précise est une décision relative à l’exposition, et pas seulement un réglage pratique. N’exposez l’accès à la préproduction qu’aussi largement que le test l’exige.

• Utilisez une instance, une base de données et un emplacement de stockage distincts.
• Choisissez un domaine de préproduction impossible à confondre avec celui de la production.
• Créez des identifiants propres à la préproduction et n’accordez l’accès qu’aux services qui en ont besoin.
• Vérifiez l’authentification et l’exposition réseau avant d’inviter des testeurs.
• Vérifiez que la configuration propre à l’environnement ne peut pas basculer silencieusement vers des points de terminaison de production.

Utilisez des données de test représentatives sans copier par défaut les dossiers sensibles

Les données de test doivent être assez réalistes pour mettre à l’épreuve le comportement examiné, mais cela ne nécessite pas de copier intégralement les données de production. Commencez par des enregistrements générés ou sélectionnés spécifiquement pour le test. Incluez les cas particuliers dont le test dépend, comme différents rôles de compte, des dossiers incomplets ou des valeurs limites, sans importer inutilement d’informations permettant d’identifier des clients.

Si des données proches de celles de la production sont vraiment nécessaires, déterminez quels champs sont indispensables et comment les champs sensibles seront supprimés, masqués ou anonymisés avant leur utilisation. Le DevSecOps Maturity Model de l’OWASP décrit l’intérêt de données de test proches de celles de la production et précise que les informations personnelles identifiables sont souvent anonymisées. Traitez l’actualisation des données comme une opération encadrée : définissez qui peut la demander, qui peut accéder au résultat et quand celui-ci doit être supprimé.

N’oubliez pas qu’une base de données n’est pas le seul endroit où des informations peuvent persister. Dans le cadre de votre plan de gestion des données, examinez aussi les fichiers téléversés, les exports, les journaux de l’application, les comptes de test et les sauvegardes. Fixez des règles de conservation avant de charger les données, et non après la fin d’un test.

• Privilégiez les enregistrements de test générés ou créés à cette fin.
• N’importez que les champs et les dossiers nécessaires au test.
• Anonymisez les informations personnelles ou protégez-les d’une autre manière avant de les utiliser.
• Désignez un responsable et fixez une date de conservation pour les données de préproduction et leurs copies.
• Vérifiez les journaux, les fichiers et les sauvegardes, ainsi que la base de données.

Évitez les effets secondaires liés aux e-mails, paiements, webhooks et tâches

Considérez chaque action sortante comme un incident de production potentiel tant que vous n’avez pas vérifié qu’elle est contenue. Un test qui semble correct dans l’application pourrait tout de même envoyer un e-mail à un client, créer un paiement réel, mettre à jour un CRM connecté ou déclencher un autre système par l’intermédiaire d’un webhook.

Dans la mesure du possible, utilisez le mode test ou bac à sable du fournisseur externe, ainsi que des identifiants propres à la préproduction. Stripe documente des valeurs de test permettant de simuler des scénarios de paiement sans transférer d’argent et recommande d’utiliser des clés API de test plutôt que de véritables données de carte bancaire. Pour les scénarios d’e-mail, Amazon SES propose un simulateur de boîtes aux lettres qui permet de tester des résultats tels que la remise, le rebond, la plainte et les réponses automatiques.

Pour les services qui ne disposent pas d’un mode de test adapté, utilisez un substitut contrôlé ou désactivez la connexion pendant la préproduction. Pour les webhooks, dirigez-les vers un récepteur de test ou un autre point de terminaison explicitement approuvé pour la préproduction. Examinez les actions planifiées et les tâches en arrière-plan : désactivez-les, limitez leur portée ou redirigez-les vers des services de test afin qu’une exécution habituelle ne puisse pas affecter la production.

Testez également les mesures de protection. Vérifiez qu’un e-mail de préproduction reste dans le circuit de test, qu’un paiement utilise des identifiants de test et qu’un webhook atteint le récepteur prévu. Ne vous fiez pas uniquement à une bannière d’avertissement ou à une convention de nommage.

• Remplacez les clés API et identifiants de compte de production par leurs équivalents de test.
• Utilisez les environnements de test ou les simulateurs du fournisseur lorsqu’ils sont disponibles.
• Redirigez les e-mails et les webhooks vers des destinations de test contrôlées.
• Désactivez ou limitez les actions planifiées susceptibles de contacter des systèmes réels.
• Effectuez un petit test de vérification et contrôlez la destination avant de lancer des tests plus étendus.

Limitez l’accès réseau aux besoins du test

L’isolation concerne aussi les connexions sortantes de l’environnement de préproduction, et pas seulement l’accès entrant à son interface web. Dressez la liste des services externes nécessaires au test, puis limitez ou omettez les autres intégrations lorsque votre modèle de déploiement le permet. Cela réduit le risque qu’une mauvaise configuration, des identifiants copiés ou une tâche en arrière-plan atteignent un système non prévu.

Pensez aussi aux dépendances faciles à oublier : bases de données de production, espaces de stockage partagés, fournisseurs d’identité, enregistrements DNS, ainsi que destinations de surveillance ou de notification. Si un test nécessite réellement une dépendance connectée à la production, documentez-en la raison, les actions autorisées et les mesures de protection avant de l’activer.

Les tests TLS demandent eux aussi de la prudence. Let’s Encrypt recommande d’utiliser son environnement de préproduction avant la production, mais les certificats délivrés dans cet environnement ne sont pas approuvés par les magasins de confiance habituels des navigateurs et des clients. Le projet indique également que les requêtes externes vers l’API de préproduction peuvent entraîner de l’instabilité et présente Pebble comme un serveur ACME destiné aux tests en intégration continue et en développement. Choisissez une méthode adaptée à la tâche au lieu de supposer qu’un certificat de préproduction convient à une utilisation normale dans un navigateur.

• N’autorisez que les accès entrants nécessaires aux testeurs et aux vérifications automatisées.
• Répertoriez les destinations sortantes nécessaires et réexaminez-les après chaque modification de configuration.
• Éloignez la préproduction des bases de données de production et des espaces de stockage partagés, sauf si un test précis exige le contraire.
• Documentez toute connexion inévitable à la production et limitez ses autorisations.
• Distinguez les tests de certificats des attentes habituelles en matière de confiance des navigateurs.

Faites évoluer la préproduction avec la production

La préproduction devient trompeuse lorsque ses différences avec la production ne sont pas documentées ou ne sont plus à jour. Conservez une courte note sur l’environnement précisant la configuration de l’application, l’approche adoptée pour les données, les substitutions de services externes, les règles d’accès et les limites connues. Lorsque la production évolue, vérifiez que la préproduction représente toujours le comportement que le prochain test doit évaluer.

Docker Compose permet d’appliquer une configuration propre à un environnement au moyen d’un fichier Compose supplémentaire. Cela peut rendre les différences plus explicites, mais ne détermine pas quelles différences sont sûres ou adaptées à votre application. Examinez la configuration et les secrets avant chaque cycle de test, surtout après avoir modifié des domaines, des intégrations ou des paramètres de déploiement.

Un environnement de préproduction utile n’a pas nécessairement besoin d’être identique à la production. Il doit être suffisamment représentatif pour un test défini, tout en restant isolé des données et des effets secondaires de la production. Si vous ne pouvez pas reproduire sans risque une dépendance critique, consignez cette limite et ne considérez pas le résultat comme une preuve du comportement qui n’a pas été testé.

• Tenez à jour une liste concise des différences intentionnelles par rapport à la production.
• Réexaminez cette liste après toute modification de l’application, des intégrations ou de l’infrastructure.
• Vérifiez que l’environnement de test couvre toujours le comportement évalué.
• Consignez les limites afin que les testeurs ne surestiment pas ce que prouve la réussite d’un test.

Définissez des règles de conservation et planifiez une suppression maîtrisée

Avant de commencer les tests, décidez quand les comptes de préproduction, les enregistrements de test, les journaux, les fichiers téléversés et les sauvegardes devront être examinés ou supprimés. Désignez un responsable et précisez quelles ressources doivent être conservées pour un test de suivi. Un environnement de préproduction qui n’est jamais nettoyé peut accumuler des données sensibles, d’anciens identifiants et des artefacts de test source de confusion.

Planifiez la suppression comme une vérification, et non comme l’exécution d’une simple commande. Docker précise que la commande Compose down ne supprime pas les volumes nommés par défaut ; l’option --volumes supprime les volumes nommés déclarés dans le fichier Compose ainsi que les volumes anonymes attachés aux conteneurs. Comme les volumes peuvent contenir des données applicatives persistantes, examinez la configuration et vérifiez que vous ciblez bien l’environnement de préproduction avant de les supprimer.

Si un fournisseur d’hébergement gère la préproduction, clarifiez les tâches d’infrastructure dont il s’occupe et les choix qui vous incombent. Airbip gère le déploiement des applications sous forme de charges de travail Docker sur ses serveurs cloud et automatise le routage et les certificats TLS, avec des contrôles DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces fonctionnalités d’infrastructure ne déterminent pas les données que vous placez dans la préproduction, les personnes qui peuvent y accéder ni les intégrations qu’elle peut contacter. Définissez ces règles pour votre application et votre équipe.

• Désignez la personne responsable des données de préproduction et de leur nettoyage.
• Décidez quoi conserver, pendant combien de temps et pour quelle raison.
• Avant la suppression, vérifiez que le projet, le domaine, la base de données et les volumes appartiennent à la préproduction.
• Vérifiez si les sauvegardes ou les fichiers exportés contiennent des données qui doivent elles aussi être supprimées.
• Après la suppression, confirmez que les services et les données de production sont restés intacts.