Vous pouvez avoir le meilleur système d’identification au monde, mais si votre couche de trafic est en désordre, les pirates se contenteront de passer par une porte latérale. Le véritable zéro confiance nécessite de verrouiller la « plomberie » de votre réseau.
Le zéro confiance est devenu l’un des modèles de sécurité les plus largement adoptés dans les environnements d’entreprise. Les organisations investissent massivement dans les systèmes d’identité, les politiques d’accès et les outils de sécurité modernes. Sur le papier, ces environnements semblent bien protégés.
Pourtant, lors d’incidents, une réalité différente émerge souvent.
J’ai travaillé avec des organisations où les initiatives Zero Trust étaient pleinement mises en œuvre du point de vue de l’identité et de la politique. Des contrôles d’accès ont été définis. Les flux d’authentification étaient forts. Les exigences de conformité ont été respectées. Mais quand quelque chose n’allait pas, la même question revenait sans cesse.
Comment le trafic s’est-il passé en premier lieu ?
La réponse est souvent inconfortable. La stratégie était solide, mais son application au niveau du trafic était incohérente. C’est là que la plupart des architectures Zero Trust échouent.
Là où la confiance zéro s’effondre dans la pratique
Le zéro confiance repose sur une idée simple : ne jamais faire confiance, toujours vérifier. En pratique, la plupart des implémentations se concentrent fortement sur l’identité. Les utilisateurs s’authentifient. Les appareils sont validés. Les politiques déterminent l’accès.
Ce qui est souvent négligé, c’est la manière dont le trafic entre et circule dans l’environnement avant que ces contrôles ne soient appliqués.
La couche de trafic comprend les chemins d’entrée, les équilibreurs de charge, les passerelles API, l’application TLS, la validation des demandes et la communication de service à service. C’est là que la confiance s’établit ou s’assume.
Dans plusieurs environnements dans lesquels j’ai travaillé, ces lacunes n’étaient pas dues à un manque d’outils. Ils provenaient d’une appropriation incohérente entre les équipes réseau, sécurité et applications.
L’un des modèles les plus courants est celui d’une stricte surveillance de l’identité combinée à des points d’entrée permissifs. Les organisations déploient des fournisseurs d’identité modernes et une authentification multifacteur, tout en autorisant des versions TLS obsolètes ou des configurations de chiffrement faibles en périphérie. Les directives du National Institute of Standards and Technology recommandent des bases de protocole sécurisées.
Un autre problème récurrent est l’entrée fragmentée. Les applications sont exposées via différents chemins tels que les CDN, les équilibreurs de charge directs, les anciens points de terminaison ou les API nouvellement déployées. Chaque chemin se comporte légèrement différemment.
Mutual TLS n’est également souvent mis en œuvre que partiellement. Les connexions sont interrompues et rétablies en interne avec des hypothèses plus faibles.
Le trafic est-ouest introduit un autre écart. Une fois à l’intérieur, la circulation est souvent considérée comme sûre.
Enfin, il y a la question de la visibilité. Lors de la réponse aux incidents, les équipes ne peuvent souvent pas répondre au chemin emprunté par une demande.
Beaucoup de ces problèmes correspondent aux modèles décrits par l’OWASP.
Pourquoi la couche de trafic est le véritable point d’application
Les programmes de sécurité réussissent souvent à définir des politiques. Ils ont du mal à les appliquer de manière cohérente.
C’est au niveau du trafic que l’application devient réelle.
Du point de vue du leadership, il ne s’agit pas d’un problème d’outillage. C’est une question architecturale.
Les principes de la Cloud Security Alliance mettent l’accent sur la mise en place de contrôles à l’entrée.
Ce qui fonctionne dans des environnements réels
Les organisations qui réussissent traitent la couche de trafic comme le principal point d’application.
Ils standardisent les chemins d’entrée, appliquent des lignes de base TLS strictes et éliminent les exceptions héritées.
Ils définissent des règles claires pour le TLS mutuel et garantissent que la confiance est continuellement validée.
Ils normalisent et valident les requêtes avant la logique applicative.
Ils mettent en œuvre une télémétrie cohérente afin que les équipes de sécurité puissent suivre les demandes de bout en bout.
Pensée finale
La confiance zéro est souvent décrite comme un changement de mentalité. C’est vrai, mais l’état d’esprit à lui seul ne garantit pas la sécurité des systèmes.
La sécurité est une question d’application. Et l’application commence par la manière dont le trafic est géré.
C’est pourquoi la plupart des architectures Zero Trust échouent au niveau de la couche trafic.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
