Pourquoi une landing zone échoue souvent après six mois
Les erreurs les plus courantes des landing zones cloud et les actions pour les rendre pérennes au-delà des premiers mois.
Faut-il supprimer le VPN pour sécuriser les accès distants ? La question utile est d’abord : qui doit accéder à quelle ressource, depuis quel appareil et pour combien de temps ? Zero Trust, VPN et bastion répondent à des besoins différents. Ils peuvent coexister dans une architecture cohérente, à condition de préciser leurs responsabilités.
En résumé
- Zero Trust est une démarche d’architecture qui évite d’accorder une confiance implicite au seul emplacement réseau.
- Un VPN chiffre une connexion ; la segmentation et les autorisations déterminent ensuite ce qu’elle permet.
- Un bastion organise les accès d’administration, tandis qu’une solution ZTNA peut restreindre l’accès à des applications.
- Apache Guacamole fournit un accès distant par navigateur, mais ne couvre pas à lui seul toutes les fonctions d’un PAM.
- La révocation, les accès de secours et les tests de refus comptent autant que la connexion réussie.
Comprendre les quatre notions
Imaginez un bâtiment : le tunnel sécurisé qui vous y conduit ne vous donne pas nécessairement les clés de toutes les pièces. Un VPN protège le transport entre deux points. Une politique d’accès détermine ensuite les destinations autorisées. Un VPN segmenté et bien administré peut donc être utile ; le problème apparaît lorsqu’une connexion ouvre un réseau trop large.
Le Zero Trust, tel que décrit par le NIST SP 800-207, demande de ne pas déduire la confiance de la seule localisation ou propriété d’un appareil. L’identité, la ressource et le contexte alimentent la décision d’accès. Ce principe dépasse le choix d’un produit et concerne aussi les comptes de services.
| Notion | Ce qu’elle apporte | Ce qu’il reste à organiser |
|---|---|---|
| VPN | Transport chiffré et connectivité | Segmentation, identité, permissions et suivi |
| ZTNA | Accès conditionnel à des ressources définies | Couverture des protocoles, dépendances et disponibilité |
| Bastion / PAM | Contrôle des accès privilégiés selon les fonctions du produit | Comptes cibles, accès directs, approbations et reprise |
| Zero Trust | Principes pour concevoir les décisions d’accès | Mise en œuvre progressive et mesure de l’efficacité |
Deux parcours à séparer
Un salarié qui consulte l’intranet n’a pas le même besoin qu’un administrateur qui modifie un serveur. Le premier parcours doit rendre l’application disponible avec les contrôles d’identité nécessaires. Le second demande un compte d’administration distinct, un périmètre restreint, une durée adaptée et une traçabilité renforcée. Réutiliser un compte bureautique privilégié mélange ces deux risques.
- Identité nominativeAuthentification forte et mission autorisée
- Décision d’accèsRôle, appareil et créneau vérifiés
- Bastion ou passerelleAccès limité aux cibles prévues
- Serveur autoriséDroits nécessaires à l’intervention
- Fin de missionRévocation, traces et contrôle des exceptions
Les journaux rejoignent un dispositif de supervision avec des droits d’accès séparés. Les flux d’administration directs doivent être limités, sinon le bastion peut être contourné. Prévoyez toutefois un chemin de secours explicitement contrôlé pour les indisponibilités : un accès oublié ouvert en permanence n’est pas un plan de continuité.
Guacamole, Teleport et WALLIX : comparer par fonction
La documentation Apache Guacamole décrit une passerelle permettant notamment des sessions RDP, VNC et SSH via navigateur. Le projet est open source. La passerelle ne dispense pas de protéger son frontal, son composant guacd, ses identifiants et les machines cibles. Un accès SSH vers une machine qui possède des outils Kubernetes n’est pas un contrôle natif des autorisations Kubernetes.
Teleport et WALLIX peuvent aussi entrer dans une étude d’accès privilégiés. Les fonctions, protocoles, licences et intégrations doivent être vérifiés dans l’édition effectivement proposée. Évitez une comparaison par logos : demandez la démonstration de vos parcours, les limites d’enregistrement des sessions et les conditions de restauration. Une qualification éventuelle porte sur un périmètre et une version précis ; elle ne rend pas automatiquement votre organisation conforme à NIS2.
Pour chaque solution, posez cinq questions : comment se connecte un utilisateur, comment son droit est limité, comment il est retiré, quelles traces sont disponibles et comment travailler en cas de panne ? Le coût d’exploitation et les compétences nécessaires font partie de la décision.
Migrer sans bloquer le métier
Commencez par cartographier les applications et leurs dépendances. Un logiciel ancien peut appeler plusieurs serveurs, utiliser une résolution DNS interne ou nécessiter un protocole mal couvert par la solution envisagée. Un petit pilote représentatif est plus instructif qu’un remplacement simultané de tous les accès.
- Choisir une population pilote et un propriétaire métier joignable.
- Définir la liste des ressources et les droits réellement nécessaires.
- Tester une connexion autorisée, une cible interdite et un compte révoqué.
- Vérifier les journaux, la synchronisation des horloges et le traitement d’une alerte.
- Simuler une panne d’identité ou de passerelle et appliquer le retour au parcours précédent.
- Fermer les accès historiques seulement après validation des nouveaux parcours.
Mesurez les refus justifiés, les blocages métier, les délais de révocation et les exceptions persistantes. Le nombre de comptes migrés ne prouve pas, seul, que le risque diminue.
Un exemple de choix raisonnable
Une structure peut conserver un VPN limité pour une application patrimoniale, utiliser un accès applicatif pour ses services web et imposer un bastion pour l’administration. Ce scénario fictif ne prétend pas être universel. Il permet de réduire progressivement les accès larges sans promettre qu’un produit remplacera tous les autres.
Le livrable attendu est un schéma des flux, une matrice utilisateurs-ressources et une procédure de départ ou d’incident. Si un prestataire quitte une mission, la coupure doit porter sur ses sessions, ses comptes, ses clés et ses accès indirects. C’est cette cohérence qui rend l’architecture défendable.
Sources et références
Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.
Cadrer votre besoin
Besoin de relier ces contrôles à votre environnement ? Parler de votre projet avec Kenawek.