Environnements de production et sandbox : pourquoi une URL distincte n’est qu’un début

Isolation des environnements, tests réalistes et choix d’ingénierie pour des mises en production plus sûres des sites web et applications.

Mettre en place un environnement sandbox peut sembler simple.

On crée un second déploiement, on lui attribue une URL différente, on connecte une base de données de test et les essais peuvent commencer.

Mais que se passe-t-il lorsqu’une inscription de test envoie un e-mail à un vrai client ? Ou lorsqu’une tâche planifiée dans la sandbox modifie des enregistrements dans un système métier en production ?

Le site web peut fonctionner séparément alors que certains de ses effets continuent d’atteindre la production.

Une URL distincte identifie un environnement. Elle ne définit pas l’ensemble des ressources auxquelles il peut accéder ni ce qu’il peut modifier.

Créer une sandbox utile demande donc davantage que dupliquer un site web. Il faut prendre des décisions sur les données, les identifiants d’accès, les intégrations, les autorisations et la manière dont les changements arrivent en production.

Que sont les environnements de production, sandbox et de préproduction ?

Un environnement réunit l’application, sa configuration et les services dont elle dépend.

Cela peut inclure les bases de données, le stockage de fichiers, l’authentification, l’envoi d’e-mails, les prestataires de paiement et les processus de traitement en arrière-plan.

Les équipes n’utilisent pas toutes les mêmes noms pour leurs environnements. Pour cet article, les distinctions suivantes sont utiles :

Un petit projet peut utiliser un même environnement pour les essais en sandbox et la validation en préproduction. Un système plus important peut nécessiter plusieurs environnements aux objectifs différents.

La terminologie compte moins qu’un accord clair sur le contenu de chaque environnement, les personnes qui peuvent y accéder et les actions qu’il peut effectuer.

Le problème de l’URL distincte

Prenons un site web avec deux adresses :

• www.example.com
• sandbox.example.com

La sandbox dispose de son propre déploiement de l’application et de sa propre base de données.

À première vue, la séparation semble complète.

Cependant, sa configuration contient encore les identifiants du service d’e-mail de production, un emplacement dans le stockage de fichiers de production et un webhook pointant vers le CRM opérationnel de l’entreprise.

Un développeur envoie une demande de contact de test.

La demande est enregistrée dans la base de données de la sandbox, mais l’application effectue aussi les actions suivantes :

1. Elle envoie un e-mail à un destinataire réel.
2. Elle téléverse une pièce jointe dans le stockage de production.
3. Elle crée un prospect dans le CRM de production.

L’application a respecté sa configuration. Les limites entre environnements étaient incomplètes.

L’isolation doit couvrir l’ensemble du processus, y compris les actions effectuées en dehors de l’application elle-même.

Quels éléments faut-il séparer ?

Le niveau de séparation approprié dépend des risques et de la complexité du système.

Des comptes ou projets cloud distincts peuvent renforcer les limites administratives, mais ils ne constituent pas la seule solution. Des systèmes plus modestes peuvent utiliser une infrastructure partagée avec des ressources et des autorisations soigneusement restreintes.

La question essentielle est de savoir si l’activité de test peut atteindre les ressources de production.

Une base de données distincte ne suffit pas si un processus de la sandbox consomme les messages d’une file de production.

De même, un dossier de stockage distinct protège peu si l’identité de service de la sandbox peut supprimer des fichiers dans l’ensemble du compte de stockage de production.

Les autorisations doivent faire respecter les limites prévues. Les conventions de nommage ne peuvent pas le faire à elles seules.

Intégrations externes : quand les actions de test deviennent réelles

Les intégrations externes méritent une attention particulière, car leurs effets peuvent être difficiles à annuler.

Supprimer un enregistrement de test ne rappelle pas un e-mail, ne retire pas une notification du téléphone de quelqu’un et n’annule pas automatiquement une modification dans un autre système.

E-mails et notifications

Pour de nombreux tests, un service de capture d’e-mails permet aux développeurs d’examiner les messages sans les distribuer à des destinataires externes.

Lorsque le test de distribution est nécessaire, les destinataires peuvent être limités à des adresses contrôlées. L’application doit aussi générer des liens qui renvoient vers le bon environnement.

Un e-mail de réinitialisation de mot de passe envoyé depuis la sandbox qui pointe vers le site en production constitue une erreur de configuration, même si seul un testeur reçoit le message.

Paiements

Les tests de paiement doivent utiliser les dispositifs de test documentés par le prestataire.

Par exemple, Stripe prend en charge des transactions en sandbox qui simulent des paiements sans mouvement de fonds, à l’aide d’identifiants de test et de valeurs de test documentées. Ses recommandations distinguent également ces opérations des paiements réels. Documentation des tests Stripe ↗ (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)

Le reste du processus demande également de l’attention. Un paiement réussi simulé ne doit pas déclencher l’exécution réelle d’une commande, émettre une facture opérationnelle ou activer un abonnement en production.

Webhooks et tâches en arrière-plan

Un événement de test peut avoir des conséquences réelles s’il atteint un système destinataire en production.

Examinez ensemble les destinations des webhooks, les identifiants d’accès, les secrets de vérification, les tâches planifiées et le comportement des nouvelles tentatives.

Désactiver les tâches planifiées peut convenir pendant les tests exploratoires. Avant une mise en production, ces tâches doivent toutefois être validées dans un cadre contrôlé. Sinon, une partie importante de l’application reste non testée.

Des tests réalistes sans accès à la production

Une sandbox doit être suffisamment proche de la production pour que ses résultats soient utiles.

Si l’application en production utilise un autre moteur de base de données, un autre processus d’authentification ou une autre méthode de déploiement, des tests réussis en sandbox peuvent laisser passer des incompatibilités importantes.

Les recommandations de Twelve-Factor App sur la parité entre développement et production soulignent ce problème, notamment pour les services sous-jacents tels que les bases de données, les files de messages et les caches. Parité entre développement et production ↗ (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)

Cela ne signifie pas qu’il faut copier toutes les caractéristiques de la production.

Une sandbox peut fonctionner avec moins de ressources, des enregistrements synthétiques et des services externes simulés. L’équipe doit comprendre quelles différences peuvent influencer le comportement testé.

Par exemple :

• Un petit jeu de données peut masquer des requêtes lentes.
• Une réponse de paiement simulée peut masquer des problèmes de délai et de nouvelles tentatives.
• Une configuration d’authentification différente peut masquer des erreurs d’URL de retour ou d’autorisation.
• Un processus de traitement désactivé peut masquer des erreurs dans les traitements asynchrones.

Chaque différence délibérée limite ce qu’un test réussi permet de démontrer.

Configuration : une application similaire, des ressources différentes

Maintenir un code applicatif distinct pour la production et la sandbox peut les faire diverger.

Lorsque c’est possible, utilisez le même artefact applicatif avec une configuration fournie pour chaque déploiement. Les connexions aux bases de données, les points de terminaison des services, les identifiants d’accès et les URL publiques peuvent varier sans modifier le code de l’application.

Cette approche suit la séparation entre code et configuration propre à chaque déploiement décrite dans Twelve-Factor App. Recommandations sur la configuration ↗ (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)

La configuration doit elle aussi être validée.

Une sandbox ne doit pas utiliser silencieusement les identifiants de production lorsqu’un paramètre de test manque. Selon le composant, elle doit refuser de démarrer ou désactiver explicitement l’intégration concernée.

Dans la mesure du possible, les secrets de production doivent être inaccessibles aux applications et processus de la sandbox. Restreindre l’accès réduit la dépendance à la détection d’un mauvais paramètre par une personne. Les recommandations de l’OWASP abordent le moindre privilège et le contrôle des accès tout au long du cycle de vie des secrets. Guide OWASP de gestion des secrets ↗ (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)

Les données de test font partie de la conception

Copier la base de données de production peut sembler être le moyen le plus simple de créer des tests réalistes.

Cela peut aussi transférer des informations clients, des empreintes de mots de passe, des jetons actifs, des documents privés et des coordonnées réelles vers un environnement dont les conditions d’accès sont différentes.

Les données synthétiques constituent souvent un meilleur point de départ.

Des données de test utiles doivent comprendre davantage que quelques cas de réussite :

• Des comptes avec différentes autorisations.
• Des sessions expirées et révoquées.
• Des transactions échouées et en attente.
• Des enregistrements volumineux et des saisies inhabituelles.
• Des soumissions en double et des événements traités à nouveau.
• Différentes langues et différents jeux de caractères.

Si des données issues de la production sont nécessaires, définissez ce qui est copié, comment les champs sensibles sont transformés, qui peut accéder au résultat et pendant combien de temps il est conservé.

Modifier uniquement les noms et les adresses e-mail ne supprime pas nécessairement les informations sensibles des champs de texte libre, des pièces jointes ou des enregistrements associés.

Accès, identification de l’environnement et indexation

Les personnes doivent pouvoir reconnaître l’environnement qu’elles utilisent.

Une bannière sandbox permanente, une présentation distincte de l’administration et des libellés d’environnement dans les journaux et les alertes peuvent réduire la confusion.

Ces indicateurs complètent les contrôles d’accès. Ils ne les remplacent pas.

Les environnements de test privés doivent exiger une authentification appropriée ou des restrictions réseau.

L’indexation par les moteurs de recherche est une question distincte. Google prend en charge les directives noindex, mais son robot doit pouvoir accéder à une page pour les lire. Bloquer l’exploration avec robots.txt peut empêcher Google de voir la directive, et l’URL peut tout de même apparaître dans les résultats. Google Search Central : bloquer l’indexation avec noindex ↗ (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)

Aucun de ces deux mécanismes n’empêche une personne d’ouvrir une page autrement accessible.

Des sandboxes publiques de démonstration peuvent volontairement accueillir des visiteurs. Dans ce cas, leurs données, autorisations, mécanismes de réinitialisation et effets externes doivent être encadrés de manière adaptée à un usage public.

Recommandations pratiques pour les développeurs

1. Définir l’objectif de l’environnement

Déterminez s’il sert à l’expérimentation, aux démonstrations clients, aux tests d’intégration ou à la validation d’une version. Précisez ses limites.

2. Cartographier les processus complets

Suivez une action depuis le navigateur à travers les bases de données, les processus de traitement, le stockage, les notifications et les services externes. Identifiez chaque point où elle peut produire un effet.

3. Faire respecter les limites entre ressources

Utilisez des ressources distinctes et des identités de service aux autorisations restreintes lorsque cela convient. Vérifiez que les identifiants de la sandbox ne permettent pas d’accéder aux données de production.

4. Tester l’isolation autant que le fonctionnement

Vérifiez qu’une inscription fonctionne et qu’elle ne peut pas envoyer d’e-mail à un destinataire non prévu, écrire dans le stockage de production ou publier un événement destiné à un processus de production.

5. Rendre le déploiement reproductible

Utilisez des artefacts et des procédures de déploiement cohérents entre les environnements. Les recommandations de Microsoft sur le déploiement présentent cette cohérence comme un élément de fiabilité des mises en production. Recommandations sur le déploiement et les tests ↗ (s’ouvre dans un nouvel onglet ou une nouvelle fenêtre)

6. Planifier la mise en production

Validez les paramètres propres à la production, surveillez les processus essentiels après le déploiement et définissez les étapes de reprise.

Revenir à une version précédente de l’application peut ne pas annuler les changements de base de données ni les actions déjà effectuées par des services externes.

Questions fréquentes

Une sandbox est-elle la même chose que la préproduction ?

Pas nécessairement. Une sandbox sert généralement à expérimenter, tandis que la préproduction valide habituellement une version candidate. Un projet peut combiner ces objectifs si les limites et les contraintes sont claires.

Tous les sites web ont-ils besoin de ces différents environnements ?

Non. Un site d’information statique a des besoins différents de ceux d’une application qui gère des comptes, des paiements et des traitements planifiés. La configuration doit tenir compte des défaillances possibles et de leurs conséquences.

La production et la sandbox peuvent-elles partager une infrastructure ?

Oui, mais une infrastructure partagée introduit des risques communs. L’accès aux ressources, la capacité, les autorisations et les limites administratives doivent être conçus avec soin.

Un test réussi en sandbox garantit-il le succès en production ?

Non. Il fournit des éléments de validation dans les conditions testées. La configuration de production, le trafic, les données et le comportement des services externes peuvent encore différer.

Renforcer la confiance avant la mise en production

Une sandbox utile permet à une équipe d’explorer les défaillances, d’examiner le comportement de l’application et de valider les changements avant que les clients ne les rencontrent.

Sa valeur dépend de deux éléments : l’efficacité avec laquelle elle contient l’activité de test et la fidélité avec laquelle elle représente les comportements importants.

Une URL distincte est un point de départ utile. La confiance vient de la connaissance des ressources que l’environnement peut atteindre, des effets qu’il peut produire et de ce que ses tests démontrent réellement.