Zero Trust hybride : sécuriser vos accès entre datacenter, AWS et OVHcloud

Quand le risque se glisse entre les environnements

Imaginons Nova Industrie, une PME fictive de 180 collaborateurs répartis sur trois sites. Son système d'information repose sur Active Directory, plusieurs applications métier hébergées sur site, Microsoft 365, deux comptes AWS utilisés pour des services numériques et plusieurs projets OVHcloud. Le télétravail est courant et une dizaine de prestataires interviennent sur la maintenance, le support et le développement.

L'entreprise a déjà investi dans la sécurité : authentification multifacteur, protection des postes, pare-feu récents, VPN, sauvegardes et centralisation d'une partie des journaux. Sur le papier, chaque brique paraît défendable. Mais un compte prestataire est utilisé depuis un équipement inconnu pour ouvrir une session VPN. L'accès réseau donne de la visibilité sur plusieurs adresses internes. L'attaquant atteint ensuite un serveur de rebond, récupère un secret applicatif et tente d'appeler un service hébergé dans AWS.

Aucun contrôle n'était totalement absent. Le problème venait de leur articulation. Le VPN avait authentifié le compte sans limiter l'utilisateur aux deux applications nécessaires. L'état du terminal, connu du système de protection, n'influençait pas la décision. Le secret applicatif était valable trop longtemps. Enfin, les journaux ne permettaient pas de relier rapidement l'identité du prestataire, son terminal, la session VPN, le serveur intermédiaire et l'appel au cloud.

Cette question change la discussion. Elle éloigne l'entreprise de la recherche d'un « produit Zero Trust » et la rapproche d'un modèle vérifiable. Une solution peut couvrir l'accès utilisateur, une autre les privilèges, une troisième les identités de workloads. Ce qui compte est la cohérence des garanties et la capacité à prouver que la ressource ne possède pas de chemin de contournement.

Pourquoi le SI hybride rend le modèle traditionnel insuffisant

Dans un environnement historique, la sécurité a longtemps reposé sur une distinction simple : l'extérieur était considéré comme hostile et l'intérieur comme relativement fiable. Cette représentation est devenue trop fragile. Un collaborateur peut s'authentifier dans un service SaaS avant d'accéder à une application sur site. Un workload AWS peut appeler une API dans OVHcloud. Un administrateur peut intervenir depuis un poste privilégié sur une console cloud sans que le trafic repasse par le datacenter.

Le Zero Trust expliqué comme une décision, pas comme un produit

Le NIST SP 800-207 décrit une architecture logique dans laquelle un Policy Engine prend la décision, un Policy Administrator traduit cette décision en action de session et un Policy Enforcement Point applique le résultat. Ces rôles sont logiques : un même produit peut en assurer plusieurs, et plusieurs technologies peuvent coopérer pour couvrir un cas d'usage.

Dans un SI hybride, il est rarement réaliste d'avoir un moteur universel. L'accès conditionnel du fournisseur d'identité, le PAM, le ZTNA, les politiques IAM cloud et les contrôles applicatifs prennent chacun une partie des décisions. Le NIST SP 800-207A étend cette logique aux environnements cloud-native et multicloud : l'identité des applications et services, les API gateways, les proxies et les infrastructures d'identité applicative deviennent aussi importantes que l'identité humaine.

L'objectif n'est pas que tous les environnements utilisent la même technologie. Ils doivent produire des garanties comparables : une identité vérifiable, un moindre privilège, un contrôle placé près de la ressource, une politique gouvernée, une journalisation exploitable, une révocation effective et un comportement connu en cas de panne.

Ces principes peuvent être opposés à chaque projet. Une équipe est libre de sélectionner un mécanisme différent dans AWS et dans OVHcloud, mais elle doit démontrer l'identité utilisée, la politique appliquée, le point de contrôle, la télémétrie disponible et le comportement prévu lorsque l'un des signaux ou services devient indisponible.

Placer les contrôles selon les flux réels

Une architecture Zero Trust ne commence pas par un diagramme de produits. Elle commence par les flux critiques : qui accède à quoi, pourquoi, avec quel niveau de privilège et par quelles routes. Le bon point de contrôle dépend de la ressource et du protocole. Un proxy applicatif peut être adapté à un portail web ; il ne remplace ni le PAM pour l'administration ni l'identité de workload pour une API.

Pour chaque ressource critique, le propriétaire doit pouvoir répondre à une question simple : par quel mécanisme toutes les routes vers cette ressource sont-elles contrôlées ? Une application protégée par un proxy mais encore joignable directement par son adresse privée possède un chemin de contournement. Cette vérification doit être testée techniquement, et non déduite du schéma.

Trois modèles d'architecture possibles

Le choix d'architecture dépend de la maturité, des compétences disponibles, de la diversité du patrimoine et du niveau de dépendance acceptable. Trois familles reviennent régulièrement. Aucune n'est parfaite ; la décision doit être motivée par les cas d'usage, la résilience et le modèle d'exploitation.

Traduire le modèle dans chaque environnement

Applications anciennes : avancer sans bloquer l'activité

Le Zero Trust n'exige pas de remplacer immédiatement toutes les applications historiques. Il exige de rendre les exceptions visibles, limitées et temporaires. Une application web ancienne peut être placée derrière un reverse proxy. Un client lourd utilisé par un prestataire peut être présenté dans un poste virtuel. Une console sensible peut passer par un bastion ou un PAM. Une application totalement incompatible peut conserver un VPN, à condition que celui-ci soit segmenté et limité au strict nécessaire.

Le VPN résiduel n'est donc pas automatiquement un échec. Il le devient lorsqu'il n'a ni périmètre, ni propriétaire, ni mesure compensatoire, ni date de sortie. Chaque exception devrait être inscrite dans un registre avec la ressource concernée, le risque accepté, les contrôles temporaires, la personne responsable et la prochaine date de révision.

Concevoir la résilience avant de bloquer

Les composants de décision deviennent critiques pour l'activité. Une architecture qui bloque toutes les opérations lors d'une panne mineure sera contournée par les équipes. À l'inverse, une architecture qui autorise tout dès qu'un signal disparaît annule sa propre sécurité. Le comportement de panne doit être défini par ressource et par action, puis testé avant généralisation.

L'indisponibilité du fournisseur d'identité peut conduire à refuser les nouvelles sessions sensibles tout en maintenant pendant une durée bornée certaines sessions déjà validées. L'absence d'un signal EDR récent peut imposer un poste virtuel ou un accès en lecture seule. L'indisponibilité du moteur de politique peut déclencher une règle locale restrictive ou utiliser une décision mise en cache pour un cas courant. Une coupure entre clouds peut mettre en file les opérations rejouables et arrêter proprement les transactions non rejouables.

Le choix entre fail-open et fail-closed ne se résume pas à une préférence de sécurité. Consulter un catalogue, éditer une donnée sensible et modifier une production n'ont pas le même impact. La décision doit intégrer la criticité métier, la capacité à détecter l'abus, la durée du mode dégradé et les contrôles compensatoires. Les comptes d'urgence, lorsqu'ils sont nécessaires, doivent être protégés, surveillés et testés ; un compte « de secours » inconnu du processus réel n'est pas une garantie.

Une trajectoire réaliste en quatre vagues

La transformation doit livrer un cas d'usage complet avant de chercher une couverture globale. Chaque vague possède des critères d'entrée, un pilote, une période d'observation avant blocage, un retour arrière et des critères de sortie. Cette discipline réduit les interruptions et permet de démontrer une réduction réelle du risque.

Gouverner les politiques et répartir les responsabilités

Une politique Zero Trust n'est pas une règle technique laissée à un administrateur isolé. Elle traverse le métier, l'architecture sécurité, l'identité, le réseau, les équipes cloud, le support et le SOC. Le propriétaire métier définit la criticité et les usages légitimes. L'architecture sécurité définit le cadre. Les plateformes IAM, ZTNA ou PAM configurent les mécanismes. Les équipes cloud et réseau appliquent les contrôles dans leurs domaines. Le SOC surveille et demande la révocation lorsque le risque évolue.

Le cycle de vie d'une politique comprend au minimum la conception, la simulation, l'approbation, le pilote, le déploiement, l'observation et la révision. Un registre doit préciser le moteur concerné, la ressource, les attributs utilisés, la version, le propriétaire, les exceptions et les tests. Sans ce registre, plusieurs règles techniquement correctes peuvent devenir contradictoires ou continuer à s'appliquer après la disparition du besoin.

Dans une PME, une même personne peut cumuler plusieurs rôles. Cela ne supprime pas la nécessité de les distinguer. Un prestataire qui propose une règle ne devrait pas être le seul à valider le risque métier. Une équipe qui administre la plateforme ne devrait pas être la seule à interpréter les alertes. L'objectif est d'éviter les zones grises, pas de créer une bureaucratie lourde.

Les indicateurs qui parlent à la direction

Le nombre d'applications « intégrées » est insuffisant. Une application peut être comptée comme protégée tout en restant accessible par une route directe. Les indicateurs doivent mesurer la qualité de la décision, la couverture des ressources critiques, la capacité de révocation et la friction créée pour les utilisateurs.

• Couverture des ressources critiques par un point de contrôle sans route de contournement.
• Part des décisions sensibles utilisant un signal de posture suffisamment récent.
• Pourcentage des accès privilégiés réalisés avec une identité séparée, temporaire et tracée.
• Délai de révocation de bout en bout, mesuré dans les conditions réelles.
• Taux de faux refus et délai médian de résolution par le support.
• Part des workloads utilisant une identité courte plutôt qu'un secret statique.
• Disponibilité du plan de contrôle et résultat des tests de mode dégradé.
• Nombre, âge et criticité des exceptions, avec leur propriétaire et leur date de sortie.

Chaque indicateur doit posséder une source, une formule, une fréquence, une cible et un responsable. La direction n'a pas besoin de suivre chaque événement technique. Elle doit pouvoir constater si les accès critiques deviennent plus explicables, si la propagation potentielle diminue, si les privilèges sont plus courts et si la transformation reste supportable pour les équipes.

Les erreurs qui fragilisent le projet

Mini-diagnostic : votre architecture est-elle réellement cohérente ?

Ce diagnostic ne produit pas un score de conformité. Il aide à déterminer si l'entreprise possède les bases nécessaires pour lancer un pilote ou si elle doit d'abord améliorer la visibilité. Répondez par Oui, Partiellement, Non ou Je ne sais pas.

1. Pouvez-vous nommer les ressources dont l'indisponibilité ou la compromission aurait le plus d'impact ?
2. Savez-vous quelles identités humaines et techniques peuvent atteindre chacune de ces ressources ?
3. Les accès des prestataires sont-ils limités aux applications nécessaires, à une durée et à une plage approuvée ?
4. L'état du terminal ou du workload influence-t-il réellement les décisions sensibles ?
5. Les connexions privées entre sites et clouds sont-elles encore soumises à une authentification et une autorisation applicatives ?
6. Pouvez-vous démontrer qu'une ressource protégée ne possède pas de route de contournement ?
7. Le délai de révocation d'un accès ou d'une session est-il mesuré de bout en bout ?
8. Les modes dégradés de l'identité, des politiques et de la journalisation ont-ils été testés ?

Plusieurs réponses « Non » ou « Je ne sais pas » ne signifient pas qu'il faut immédiatement acheter une nouvelle plateforme. Elles indiquent généralement la priorité : clarifier les ressources, les flux, les identités et les propriétaires avant de choisir le premier cas d'usage. Une bonne trajectoire commence par la visibilité et une décision de risque partagée.

Conclusion : rechercher la cohérence, pas l'uniformité

Une architecture Zero Trust hybride réussie ne reproduit pas le même outil dans chaque environnement. Elle organise une cohérence de décision. Le datacenter, AWS et OVHcloud peuvent utiliser des mécanismes différents si chacun sait identifier le sujet, évaluer les bons signaux, protéger la ressource avec un point de contrôle, produire une preuve et réagir à la révocation ou à la panne.

Le rôle de l'architecte est de rendre cette cohérence explicite : définir les principes, choisir les points d'application, arbitrer la centralisation, traiter les applications anciennes, concevoir les modes dégradés et attribuer les responsabilités. Pour une PME, une architecture fédérée et progressive permet d'obtenir des résultats concrets sans lancer un programme disproportionné ni dépendre d'une transformation globale du système d'information.

Le résultat attendu n'est pas un diagramme définitif. C'est une capacité opérationnelle : chaque accès critique peut être expliqué, appliqué, observé, révoqué et testé, quel que soit l'environnement qui héberge la ressource. C'est cette capacité qui réduit le risque de propagation, sécurise les interventions de tiers et donne à la direction une vision plus fiable de son exposition.

FAQ