Changer le domaine d’une application auto-hébergée : liste de dépendances à vérifier avant la migration

Pourquoi un changement de domaine est un changement applicatif, et pas seulement un changement DNS

Pour changer en toute sécurité le domaine d’une application auto-hébergée, traitez l’URL publique comme un paramètre de l’application plutôt que comme un simple détail de routage. Le DNS détermine vers quelle destination un nom d’hôte se résout, et un proxy inverse détermine quel service reçoit une requête. Ni l’un ni l’autre ne modifie automatiquement les URL générées par l’application, les adresses de rappel enregistrées auprès de services externes ou les liens déjà utilisés par les utilisateurs.

Le domaine peut apparaître dans des variables d’environnement, les paramètres d’administration de l’application, les enregistrements de base de données, la configuration du fournisseur d’identité, les abonnements aux webhooks, la configuration des clients API et les modèles d’e-mails. Il peut également être implicite dans les contrôles de sécurité du navigateur : un changement d’hôte crée une origine web différente, car une origine est définie par le schéma, l’hôte et le port.[1] Une intégration basée sur le navigateur qui fonctionnait avec l’ancien nom d’hôte peut donc nécessiter une mise à jour explicite des origines autorisées.

Séparez le travail en deux volets. Les responsables de l’infrastructure gèrent les enregistrements DNS, la validation TLS, le routage du proxy inverse et les redirections depuis l’ancien domaine. Les responsables applicatifs identifient les paramètres d’URL canonique, les services connectés, les liens destinés aux utilisateurs et les flux métier. Les deux volets doivent être finalisés avant le retrait de l’ancien domaine.

• Ne supposez pas qu’une résolution DNS réussie prouve que la migration est terminée.
• Ne supposez pas qu’une règle de nom d’hôte du proxy inverse met à jour l’URL de base interne de l’application.
• Ne retirez pas l’ancien nom d’hôte avant d’avoir testé les redirections, les intégrations et les parcours utilisateur.
• Désignez des responsables nommés pour l’infrastructure, la configuration de l’application, les intégrations d’identité et les tests de recette.

Cartographier l’URL canonique et chaque nom d’hôte utilisé

Commencez par un inventaire des noms d’hôte. L’objectif est de trouver chaque adresse que l’application accepte, publie ou dont elle dépend. Incluez l’URL publique canonique actuelle, la nouvelle URL canonique prévue, toute variante avec ou sans www, les noms d’hôte d’administration, les noms d’hôte d’API, les noms d’hôte d’upload ou de ressources, ainsi que les sous-domaines utilisés par des services intégrés.

Pour chaque nom d’hôte, consignez son rôle, sa cible DNS actuelle, sa cible DNS prévue, son besoin en certificat TLS, sa route de proxy inverse, l’équipe responsable et la décision de retrait. Une route ou un certificat générique ne doit pas être considéré comme une preuve que chaque nom d’hôte fonctionne. Par exemple, un caractère générique à un seul niveau tel que *.example.com ne couvre ni le domaine racine example.com ni un nom à plusieurs niveaux tel que api.eu.example.com.[2]

Déterminez ensuite quelle URL l’application considère comme canonique. C’est l’adresse qu’elle utilise pour générer des liens absolus, des redirections, des URL d’API, des URL de ressources ou des notifications. Si l’URL canonique reste old.example.com alors que les utilisateurs accèdent à new.example.com, l’interface peut sembler fonctionner jusqu’à ce qu’un e-mail, un flux de connexion ou une réponse d’API renvoie un utilisateur vers l’ancien domaine.

• Listez séparément les noms d’hôte de production, de préproduction et d’administration.
• Consignez à la fois le schéma et le port lorsqu’ils sont pertinents : http et https ne sont pas des origines interchangeables.
• Recherchez l’ancien nom d’hôte dans les paramètres applicatifs, les fichiers de déploiement, les gestionnaires de secrets et la documentation.
• Vérifiez les favoris de navigateur, les liens de wiki interne, la documentation publique et les liens intégrés qui peuvent nécessiter un responsable et une date de mise à jour.
• Décidez si chaque ancien nom d’hôte sera redirigé, maintenu temporairement ou retiré.

Identifier les dépendances qui se rompent souvent après un changement de nom d’hôte

Les paramètres d’identité et d’intégration sont des points de défaillance fréquents, car ils associent délibérément un client ou un point de terminaison à une adresse précise. Les URI de redirection OAuth méritent une attention précoce : les recommandations de sécurité OAuth actuelles imposent aux serveurs d’autorisation une correspondance exacte de chaîne pour les URI de redirection préenregistrées, à l’exception limitée de localhost pour les applications natives.[3] L’ajout d’un nouveau domaine auprès du fournisseur d’identité est donc une tâche obligatoire avant la bascule, et non une commodité à traiter après le changement.

Examinez les connexions entrantes comme sortantes. Les dépendances entrantes comprennent les rappels du fournisseur d’identité, les rappels de paiement ou de formulaires, ainsi que les webhooks de tiers ciblant l’application. Les dépendances sortantes comprennent les webhooks envoyés par l’application à un autre service, les clients API qui appellent l’ancien nom d’hôte et les widgets ou scripts intégrés qui chargent des ressources depuis l’ancien hôte.

CORS constitue une autre frontière fréquente. Si une API ou un proxy utilise une liste explicite d’origines autorisées, ajoutez la nouvelle origine composée du schéma et de l’hôte avant la bascule.[4] N’élargissez pas les règles d’origine sans discernement uniquement pour faire passer un test ; préservez la frontière d’accès prévue et effectuez le changement justifié le plus limité.

Les communications générées doivent faire l’objet de la même vérification. Les e-mails de réinitialisation de mot de passe, les invitations, les notifications de commentaires, les exports, les rapports planifiés et les modèles marketing ou transactionnels peuvent inclure des liens absolus. Testez avec une boîte aux lettres non privilégiée ainsi qu’avec un compte administrateur, car les chemins de modèles et les autorisations peuvent différer.

• URL de redirection et de déconnexion OAuth et OpenID Connect.
• URL de consommateur d’assertion SAML et références d’entité ou de métadonnées, le cas échéant.
• Destinations des webhooks et listes d’autorisation des émetteurs de webhooks.
• URL de base d’API dans les scripts, les clients mobiles, les extensions de navigateur et les outils internes.
• Listes d’origines CORS autorisées, intégrations navigateur et paramètres d’iframe.
• Modèles d’e-mails, réinitialisations de mot de passe, invitations, liens de calendrier et liens de notification.
• URL codées en dur dans les flux d’automatisation, les tâches planifiées et la documentation.

Vérifier la configuration spécifique à l’application, y compris celle qui parvient réellement au conteneur

Chaque application donne un nom différent à ces paramètres, mais recherchez des notions telles qu’URL de base, URL publique, URL du site, URL externe, URL canonique, hôtes de confiance, hôtes autorisés, origines autorisées, mode proxy et confiance dans les en-têtes transférés. Consultez la documentation de l’éditeur de l’application pour connaître les noms de paramètres exacts et les exigences de redémarrage. Ne déduisez pas qu’un paramètre est facultatif parce que l’application démarre sans lui.

Pour les déploiements Docker, examinez la configuration effective à l’exécution plutôt que de vous fier à un seul fichier ou à une valeur mémorisée. Docker Compose peut fournir la configuration par des variables d’environnement de conteneur, et les valeurs d’un fichier .env peuvent être interpolées dans un fichier Compose. La priorité des variables d’environnement peut modifier la valeur qui parvient au conteneur.[5] Lorsqu’il est approprié pour votre déploiement, docker compose config est utile pour confirmer la configuration Compose résolue, en particulier lorsque plusieurs fichiers Compose ou sources de variables sont impliqués.[6]

Inspectez également les paramètres stockés hors de la définition Compose : interfaces d’administration de l’application, configuration stockée en base de données, fichiers de configuration montés, systèmes de gestion des secrets et scripts de démarrage. Conservez une trace avant et après de chaque valeur modifiée. Cette trace accélère considérablement la revue par les pairs et le retour arrière.

Si l’application se trouve derrière un proxy inverse, confirmez ses attentes concernant l’hôte et le protocole d’origine. Un proxy peut transmettre ces informations en amont, mais la confiance accordée aux en-têtes transférés doit être configurée délibérément.[7] Une gestion incorrecte peut entraîner la génération de liens http, des boucles de redirection ou un écart entre le nom d’hôte public et celui que l’application pense servir.

• L’URL canonique ou externe correspond au nom d’hôte HTTPS prévu.
• La liste des hôtes de confiance ou autorisés inclut le nouveau nom d’hôte et, pendant la transition, l’ancien nom d’hôte s’il reste servi.
• Les paramètres d’origine liés à CORS et CSRF n’incluent que les origines nécessaires.
• Les paramètres de proxy et de protocole transféré correspondent à l’architecture réelle du proxy.
• Les paramètres OAuth, SSO, webhook et SMTP sont vérifiés dans l’application et chez le fournisseur externe.
• La configuration de conteneur résolue est vérifiée avant le redémarrage ou le redéploiement.
• Une copie sécurisée des paramètres antérieurs est disponible pour le retour arrière.

Planifier le DNS, TLS et le proxy inverse sans les confondre avec la configuration applicative

Les changements d’infrastructure doivent être planifiés comme une séquence contrôlée distincte. Créez les nouveaux enregistrements DNS, assurez-vous que le proxy inverse dispose d’une route correspondant au nouveau nom d’hôte et vérifiez que le bon service backend est sélectionné. Dans Traefik, les routeurs HTTP utilisent des règles de correspondance de requêtes, telles que les règles Host, pour relier les requêtes aux services.[2] Les règles qui se chevauchent exigent une vigilance accrue : l’ordre par défaut des règles peut être influencé par leur longueur, de sorte qu’une règle large peut capter le trafic si les priorités ne sont pas explicitement conçues.[2]

Provisionnez et validez TLS avant de déclarer que le nouveau domaine est prêt. L’émission d’un certificat requiert une validation du contrôle du domaine. Avec le défi ACME HTTP-01, le jeton de validation doit être accessible sur le nouveau nom d’hôte sous /.well-known/acme-challenge/ via le port 80.[8] Vérifiez le pare-feu, le DNS, le routage du proxy et tout comportement de redirection susceptible d’empêcher la validation.

Les clients Airbip peuvent utiliser un sous-domaine Airbip ou un domaine personnalisé compatible. Airbip gère les instances applicatives en tant que charges de travail Docker sur les serveurs cloud d’Airbip et automatise le routage et les certificats TLS via Traefik et Let’s Encrypt, avec des vérifications DNS incluses dans le service. Ce support d’infrastructure ne remplace pas la revue par le responsable applicatif des URL de base, des enregistrements d’identité, des webhooks, des modèles et des flux métier.

Utilisez une fenêtre de modification DNS permettant l’observation, plutôt qu’un simple basculement rapide. Confirmez le nouveau nom d’hôte depuis un réseau externe, inspectez le certificat et testez la route prévue. Gardez l’ancien chemin disponible jusqu’à ce que les contrôles de l’application et des intégrations démontrent qu’il peut être retiré sans risque.

• Créez et vérifiez le DNS pour chaque nouveau nom d’hôte, y compris le nom racine lorsque nécessaire.
• Confirmez que le nouveau nom d’hôte dispose d’une route de proxy inverse explicite et non ambiguë.
• Confirmez l’émission TLS et le nom de certificat présenté aux clients.
• Vérifiez les redirections HTTPS et évitez de détourner le chemin de validation ACME de la réponse de défi requise.
• Testez le comportement proxy-vers-application avec l’hôte attendu et le protocole HTTPS.
• Documentez la configuration DNS et proxy antérieure avant d’effectuer des changements irréversibles.

Choisir une approche de bascule : valider en parallèle, rediriger délibérément et conserver l’ancien domaine pendant une période définie

L’approche la moins risquée consiste généralement à établir le nouveau nom d’hôte avant de le rendre canonique. Acheminez-le vers l’application, obtenez TLS et réalisez des tests contrôlés tandis que l’ancien domaine reste disponible. La possibilité de servir les deux noms d’hôte en toute sécurité au même moment dépend de la validation des hôtes par l’application, du comportement des sessions, du comportement de génération de liens et des contraintes de licence ou d’intégration. Validez cela avec la documentation de l’application et, lorsque possible, dans un environnement contrôlé.

Une fois le nouveau nom d’hôte accepté comme canonique, redirigez les anciennes URL publiques vers leurs URL nouvelles correspondantes lorsqu’il est approprié de préserver les chemins. HTTP 308 est un statut de redirection permanente qui utilise un en-tête Location et préserve la méthode de requête.[9] Cette propriété peut être importante pour les requêtes autres que GET, mais elle ne constitue pas une instruction générale de rediriger chaque point de terminaison. Pour les API, les webhooks, les URL signées, les chemins d’upload et les clients machine, déterminez si une redirection est prise en charge et sûre avant de l’activer.

Définissez une période explicite de maintien du domaine historique au lieu de laisser les deux domaines actifs indéfiniment par accident. Durant cette période, surveillez les accès à l’ancien hôte, corrigez les liens codés en dur restants et informez les utilisateurs ou responsables d’intégrations concernés. La conservation d’un domaine a des implications opérationnelles et de gouvernance ; cette décision doit donc être intentionnelle et réexaminée.

• Phase 1 : ajoutez le nouveau domaine, acheminez-le, émettez TLS et testez-le sans modifier les paramètres applicatifs canoniques là où l’accès parallèle est sûr.
• Phase 2 : mettez à jour l’URL canonique et les dépendances de l’application, puis testez les flux critiques sur le nouveau nom d’hôte.
• Phase 3 : redirigez le trafic navigateur approprié de l’ancien domaine tout en validant séparément le comportement des API et webhooks.
• Phase 4 : observez l’utilisation de l’ancien domaine, corrigez les dépendances restantes et approuvez le retrait selon des critères définis.
• Ne supposez pas qu’une redirection préserve les requêtes signées, la validation des rappels ou le comportement des clients tiers.

Exécuter un script de test après changement qui reflète le travail réel

La vérification de la page d’accueil est nécessaire, mais insuffisante. Utilisez un script de test écrit avec les résultats attendus, les résultats réels, les horodatages et un testeur nommé. Exécutez-le depuis un compte utilisateur ordinaire et un compte administrateur, et testez depuis une session de navigateur propre afin de ne pas dépendre de sessions ou d’autorisations mises en cache.

Donnez la priorité aux flux qui créent des liens externes, franchissent des frontières d’identité ou écrivent des données importantes. Capturez des preuves telles que des captures d’écran de l’adresse du navigateur, des liens reçus par e-mail, des enregistrements de livraison de webhooks et les journaux pertinents de l’application ou du proxy. Les preuves sont plus utiles qu’une confirmation verbale lorsqu’il s’agit de décider de maintenir une redirection ou de retirer le domaine historique.

En cas d’échec d’un test, classez-le avant de modifier la configuration : résolution DNS, certificat, route de proxy, URL canonique de l’application, politique d’origine du navigateur, enregistrement d’intégration externe ou URL codée en dur côté client. Cela évite une réaction fréquente consistant à affaiblir les contrôles de sécurité ou à appliquer de larges redirections pour masquer un manque de responsabilité ou de configuration.

• Ouvrez la nouvelle URL dans une session de navigateur propre et confirmez HTTPS, le nom d’hôte attendu et l’accès normal à l’application.
• Connectez-vous via chaque parcours d’authentification local, OAuth, SSO ou administrateur pris en charge.
• Effectuez les parcours de réinitialisation de mot de passe, d’invitation et de vérification de compte ; inspectez le nom d’hôte dans les liens reçus par e-mail.
• Créez du contenu ou des enregistrements qui génèrent des liens, puis ouvrez ces liens dans une nouvelle session.
• Testez l’envoi, le téléchargement, les aperçus de fichiers et le contenu stocké ou intégré en externe, le cas échéant.
• Exercez les clients API, les intégrations navigateur et les requêtes front-end inter-origines qui utilisent le service.
• Déclenchez des webhooks entrants et sortants, et confirmez le point de terminaison attendu, la gestion des signatures et le comportement de réponse.
• Effectuez les principaux flux administratifs, notamment la gestion des utilisateurs et les modifications de configuration adaptées au processus de modélisation des rôles de l’application. Veillez à ne pas exposer de secrets dans les preuves de test ou les journaux pendant ce processus.

Définir la responsabilité, les conditions de retour arrière et les preuves de retrait avant la fenêtre de changement

Une migration de domaine est plus facile à gouverner lorsque les points de décision sont établis avant toute modification d’enregistrement ou de paramètre. Désignez un responsable technique du changement, un responsable applicatif, un responsable identité et intégrations, un responsable des communications et un approbateur du retrait de l’ancien domaine. Dans une petite équipe, une même personne peut remplir plusieurs rôles, mais les responsabilités doivent néanmoins rester explicites.

Définissez le retour arrière en termes opérationnels. Par exemple, il peut consister à restaurer l’URL canonique antérieure, à réactiver la route de proxy précédente, à restaurer la cible DNS antérieure ou à suspendre une redirection pendant la correction d’un enregistrement d’identité externe. Identifiez les changements rapidement réversibles et ceux qui nécessitent une propagation ou une action d’un tiers. Conservez un enregistrement sécurisé des valeurs précédentes et de l’ordre dans lequel elles doivent être restaurées.

Enfin, exigez des preuves avant le retrait. Parmi les preuves appropriées figurent des tests réussis des parcours critiques sur le nouveau nom d’hôte, des rappels OAuth ou SSO confirmés, des liens e-mail vérifiés, des tests de webhooks réussis, l’absence de trafic non résolu sur l’ancien domaine nécessitant une action durant la période d’observation convenue, ainsi que l’approbation des responsables des intégrations à fort impact. Le retrait est une décision métier et de gouvernance autant que technique ; il doit prendre en compte les communications aux utilisateurs, les favoris conservés et les exigences contractuelles ou réglementaires de votre organisation.

Une plateforme gérée peut réduire la charge opérationnelle liée au routage, aux certificats, aux vérifications DNS, à la gestion du cycle de vie des services et aux sauvegardes. Elle ne peut pas décider quels fournisseurs d’identité, applications clientes, liens ou engagements de traitement des données sont importants pour votre organisation. Conservez cette responsabilité au niveau applicatif auprès des personnes propriétaires du service.

• Publiez un enregistrement de changement avec le nom d’hôte prévu, la fenêtre horaire, les responsables, les dépendances et le plan de communication client ou utilisateur.
• Consignez de manière sécurisée la configuration DNS, proxy et applicative antérieure.
• Définissez des déclencheurs de retour arrière mesurables, tels qu’une connexion échouée, une réinitialisation de mot de passe défaillante, l’échec d’un webhook critique ou des liens canoniques incorrects.
• Décidez qui peut autoriser le retour arrière et comment les utilisateurs concernés seront informés.
• Définissez les critères de retrait du domaine historique et une période d’observation.
• Archivez les preuves de test et l’inventaire final de configuration après achèvement.