Déplacer une application web d'entreprise derrière le VPN : guide de bascule

Imaginez le changement du point de vue de l'utilisateur. Quelqu'un clique sur un signet, s'attend à la page de connexion habituelle et reçoit à la place une erreur de connexion, car le nom d'hôte ne répond plus que dans le tunnel. Cet instant unique contient tout ce que le plan de migration doit réussir : le nom, le chemin, le certificat, le compte et l'opération qui se trouve derrière. Déroulez les étapes ci-dessous dans cet ordre et la bascule cesse d'être un saut.

Étape 1 : notez ce que font les utilisateurs aujourd'hui

Commencez par le nom d'hôte dans la barre d'adresse, le port, les opérations que les gens effectuent et les comptes qu'ils utilisent. Si vous ne pouvez pas nommer les trois opérations principales, vous n'êtes pas prêt à fermer l'entrée publique, car vous ne reconnaîtrez pas une opération cassée pendant la recette.

Décidez ensuite qui est le public privé. Les salariés sur le VPN d'entreprise sont un début, pas une réponse. Les prestataires, l'équipe de support et l'équipe financière peuvent tous avoir besoin de l'application et ne pas tous se trouver derrière la même passerelle.

Étape 2 : séparez le tunnel de la connexion

Lorsque l'utilisateur atteint l'application via le VPN, le navigateur ouvre toujours une connexion TLS vers le point de terminaison propre à l'application. Le certificat doit correspondre à ce nom, et l'application authentifie toujours le compte. Rien dans le tunnel ne remplace l'un ou l'autre.

C'est ici que les migrations dérapent en silence. Quelqu'un décide que l'adresse privée n'a plus besoin d'un certificat valide, les utilisateurs apprennent à traverser un avertissement, et l'organisation a échangé une exposition publique contre une formation à ignorer les alertes de sécurité. Si l'application a réellement besoin d'un certificat interne, émettez-en un auprès de l'autorité interne et distribuez la confiance correctement. C'est un changement maîtrisé ; une page d'avertissement ne l'est pas.

Gardez l'autorisation là où elle vit déjà. Le résumé de l'architecture zéro confiance du NIST le dit directement : l'emplacement réseau n'est pas une raison d'accorder une opération sensible. Être dans le tunnel ne devrait pas transformer un compte en lecture seule en administrateur.

Étape 3 : trouvez les appelants qui ne sont pas des salariés

Ouvrez la configuration de l'application et listez tout ce qui lui parle : l'URL de rappel du fournisseur d'identité, le webhook d'un fournisseur de paiement, un import planifié, une sonde de supervision, le client API d'un partenaire. Chacun est une dépendance avec un propriétaire, et chacun cassera à un moment différent.

Décidez d'un chemin pris en charge pour chacun de ceux qui doivent rester. Un fournisseur de webhook ne peut pas rejoindre votre VPN salariés : soit vous exposez un point de terminaison d'intégration étroitement délimité avec sa propre authentification, soit vous changez le modèle d'intégration. Laisser toute l'application publique parce qu'un rappel existe est un choix, et généralement le mauvais.

Notez chaque exception avec la destination, l'opération autorisée, l'authentification et le propriétaire. Un compte VPN générique remis à une intégration est la façon dont une exception devient permanente. Revoyez la liste lors de la prochaine revue des accès, car les intégrations survivent aux projets qui les ont ajoutées. Une exception sans date d'expiration est une décision de conception permanente que personne n'a prise.

Étape 4 : retirez la route publique, pas seulement l'enregistrement DNS

Parcourez la chaîne de publication : DNS, écouteurs du répartiteur de charge, règles du proxy inverse, pare-feu de l'hôte et tout nom alternatif qui pointe encore vers l'ancienne adresse. Vérifiez les deux familles d'adresses. Changer l'enregistrement A principal ne prouve presque rien si un CNAME plus ancien ou un écouteur IPv6 sert encore l'application.

En parallèle, confirmez que le nom privé se résout dans le tunnel et que le certificat couvre le nom que les utilisateurs saisiront. Un utilisateur qui doit coller une adresse numérique a trouvé un symptôme, pas un contournement.

Limitez le public du VPN au chemin de l'application. Un accès large au réseau du bureau échange une décision d'exposition contre une plus grande, et les interfaces d'administration ont besoin de leurs propres sources autorisées plutôt que d'hériter de la règle utilisateur.

Étape 5 : faites la recette vous-même

Connectez-vous en tant qu'utilisateur approuvé, ouvrez le signet, vérifiez le certificat, connectez-vous et effectuez une opération réelle. Essayez ensuite un compte qui ne devrait pas avoir cette opération et confirmez qu'il est refusé. Puis essayez depuis un appareil hors du VPN et confirmez que l'application est inaccessible.

Répétez pour chaque intégration conservée, et lisez le journal de livraison du fournisseur au lieu de supposer qu'un 200 de votre propre outil de test est la même chose. Une connexion VPN réussie n'est pas une preuve pour l'un de ces résultats.

Étape 6 : répétez le mauvais jour

Décidez de ce qui se passe lors d'une panne du tunnel : le travail s'arrête, ou une autre méthode d'accès approuvée prend le relais. Quel que soit votre choix, notez-le et testez-le une fois, car la réouverture publique d'urgence comme mécanisme de reprise non documenté finira par être exécutée par quelqu'un sous pression.

Conservez l'accès de reprise pour les administrateurs qui maintiennent la passerelle et l'application, avec un propriétaire et une date de retrait. Enregistrez le changement et ses conditions d'annulation au même endroit, afin qu'une migration échouée ne verrouille pas les personnes qui la répareraient.

Après la bascule, les correctifs, le cycle de vie des comptes, l'autorisation applicative et l'audit restent à votre charge. Le tunnel a rétréci l'entrée ; il n'a repris aucune de ces tâches.