Avez-vous encore besoin d’un VPN de site quand l’application utilise mTLS et SSO ?
Parcourez les canaux que la connexion à votre application ne couvre jamais, puis décidez si l’accès au réseau privé est redondant ou reste le seul chemin vers l’hôte.
Vous vous connectez en mTLS, le tableau de bord se charge, et l’affirmation selon laquelle le VPN de site est désormais redondant sonne raisonnable à peu près aussi longtemps qu’il faut pour avoir besoin d’une restauration de base de données à deux heures du matin. La frontière TLS de l’application décrit un seul canal. L’hôte, la base de données, la cible de sauvegarde et le compte cloud portent chacun leur propre chemin d’entrée, leur propre identité et leur propre approbateur, et aucun d’eux n’est exercé par une connexion réussie.
Marchez vers l’extérieur depuis l’écran de connexion
Connectez-vous comme le ferait un utilisateur ordinaire et notez chaque saut que la requête touche : navigateur, périphérie, écouteur de l’application, magasin de sessions, API backend. Chaque saut a un propriétaire et une décision d’authentification. Répétez maintenant le parcours pour la personne qui applique des correctifs à l’hôte, et pour la tâche qui écrit la sauvegarde nocturne. Ces parcours divergent généralement dès le premier saut.
Cette divergence est la question qui vaut la peine d’être tranchée. Un VPN de site n’est redondant que lorsque chaque canal de ce second parcours dispose d’une politique d’entrée et d’autorisation qui tient toute seule.
Cinq canaux que la connexion à l’application ne couvre jamais
Le tableau ci-dessous est un modèle d’inventaire, pas une liste de contrôle de déploiement. Remplissez la deuxième colonne avec ce que votre propre environnement applique réellement aujourd’hui.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Le partage d’un fournisseur d’identité ne fusionne pas ces autorisations. Un utilisateur autorisé à envoyer une requête API n’est pas pour autant autorisé à remplacer un disque de machine virtuelle ni à restaurer une base de données avec les identifiants de l’application. Le NIST, dans le résumé de l’architecture zéro confiance, garde justement pour cette raison l’authentification et l’autorisation des ressources séparées de l’emplacement réseau.
Un ingénieur de support qui peut lire un ticket n’est pas pour autant autorisé à ouvrir une console sur l’hôte qui se trouve derrière.
Un chemin n’est réel que si l’alternative reste fermée
Restreindre l’accessibilité à des écouteurs administratifs privés est un remplacement légitime d’un VPN de site, à condition que la restriction soit appliquée et non simplement dessinée. L’échec habituel est un écouteur alternatif dont personne ne s’est souvenu : un service encore lié à toutes les interfaces, une règle de groupe de sécurité ouverte pour un prestataire, un port de gestion joignable depuis Internet.
Vérifiez les écouteurs plutôt que les schémas. Sur l’hôte, listez ce qui est réellement lié avec ss -ltnp et confirmez que les ports administratifs se trouvent sur une adresse privée. Dans la console cloud, lisez les règles entrantes du sous-réseau de charge de travail et cherchez 0.0.0.0/0 sur tout ce qui est administratif. Essayez ensuite la connexion depuis l’extérieur du chemin privé, car c’est ce test qui répond à la question.
Une seule règle ouverte au monde sur SSH annule tous les arguments qu’a avancés la conception du tunnel.
Écrivez la carte avant de comparer les conceptions
Pour chaque ligne de l’inventaire, notez qui approuve les identités, qui met à jour les règles d’accès, qui supprime les identifiants quand quelqu’un part et qui gère la reprise quand le chemin lui-même casse. Quatre noms par ligne suffisent à révéler les lignes où la réponse est un compte partagé et une page wiki vieille de trois ans.
Validez ensuite une autorisation et un refus par canal. Une autorisation prouve que l’identité prévue peut atteindre la ressource par le chemin prévu. Un refus prouve qu’une identité similaire ne le peut pas, et c’est le test que les gens sautent, ce qui explique pourquoi les écouteurs alternatifs survivent aux audits. Comparez la conception proposée à ces résultats, non à la configuration TLS de l’application, qui n’en a jamais exercé aucun.
Où un VPN de site gagne encore sa place
Un tunnel ou une passerelle étroite est la bonne réponse quand une ressource n’a pas sa propre authentification par requête : ports de maintenance de bases de données, cibles de sauvegarde, consoles d’hyperviseur, gestion hors bande. Ces écouteurs font confiance au réseau, donc le réseau doit être ce qui authentifie l’appelant.
Ce n’est pas la seule réponse. Une passerelle qui termine l’autorisation par ressource peut être plus étroite qu’un tunnel à l’échelle du sous-réseau et laisse une meilleure piste d’audit qu’un hôte de rebond partagé.
Ordre du travail : complétez l’inventaire, fermez les alternatives, validez un refus par ligne, et seulement ensuite retirez le tunnel. Si une ligne ne peut pas produire de refus, gardez le chemin privé jusqu’à ce qu’elle le puisse.