Par Jérémy Lanoë, Consultant Infrastructure Security chez Almond

Ce premier article sur le Zero Trust Network Access (ZTNA) a pour but de donner les principes fondamentaux sur lesquels reposent le ZTNA. Nous allons voir une définition du modèle Zero Trust après avoir contextualisé les enjeux actuels sur les accès distants.

Selon le Gartner, en 2023, plus de 60% des entreprises adopteraient une solution ZTNA pour remplacer leur solution VPN. Le ZTNA apporte une nouvelle réponse pour offrir des accès distants aux collaborateurs accentuée pendant la crise de la COVID-19. Les accès distants sont devenus nécessaires pour assurer la continuité d’une entreprise. Le nombre de cyberattaques a d’ailleurs fortement augmenté pendant cette période. La sécurité des accès distants est donc de plus en plus préoccupante

Contexte actuel

Le modèle périmétrique adopté depuis plusieurs années pour sécuriser les infrastructures réseaux ne suffit plus. Le modèle consiste à autoriser ou à bloquer les flux entre une zone réseau définie et une autre. Un attaquant peut se déplacer à l’intérieur du réseau en utilisant les flux autorisés sans qu’aucune vérification supplémentaire ne soit effectuée.

La notion de périmètre a évolué avec l’apparition des solutions d’accès à distance et le Cloud. La solution d’accès à distance la plus répandue est le VPN SSL. A l’origine, seuls les administrateurs y avaient accès. Désormais, les collaborateurs les utilisent aussi depuis des accès internet personnels pour télétravailler.

Le Cloud donne aux entreprises la possibilité d’héberger une partie ou l’ensemble de leurs ressources chez le fournisseur Cloud. Le périmètre à sécuriser n’est plus limité aux ressources hébergées sur site mais aussi chez le fournisseur Cloud. Les accès depuis des réseaux non gérés par l’entreprise sont de plus en plus nombreux et représentent des vecteurs d’attaques potentiels.

Pour répondre à ces problématiques, le ZTNA ne repose plus sur le modèle périmétrique mais sur le modèle Zero Trust.

Une définition du modèle Zero Trust

Les notions de flux autorisés et de périmètres accordent une confiance implicite que le modèle Zero Trust refuse. Dans les années 2000, le Jericho Forum ainsi que le projet Black Core initié par le Département de la Défense des États-Unis proposent des pistes de réflexion sur un nouveau modèle de sécurité. L’accès dépendrait désormais de l’identité de l’utilisateur. En 2010, John Kindervag, analyste chez Forrester, reprend ces idées pour définir le modèle Zero Trust. Ce modèle n’accorde aucune confiance mais des accès en imposant plusieurs vérifications. Ces vérifications forment un contexte.

Le contexte est composé de l’identité de l’utilisateur, du rôle de l’utilisateur et de la vérification de conformité du terminal utilisé, aussi appelée Device Posture. L’authentification multi-facteurs est imposée à l’utilisateur qui doit saisir ses identifiants et effectuer une seconde action :

  *   Saisie du code envoyé par SMS, mail ou généré via une application (OTP)

  *   Validation de la demande d’accès via une application (PUSH)

  *   Utilisation du jeton RSA ou de clé d’authentification

Le rôle de l’utilisateur est analysé pour appliquer un principe de moindres privilèges et un principe de besoin d’en connaître au strict nécessaire limitant la visibilité et l’accès à certaines ressources. Pour s’assurer que l’accès n’expose pas l’infrastructure à des menaces externes, une vérification granulaire du terminal est effectuée.

Aucune distinction n’est faite entre des utilisateurs qui se connectent depuis des réseaux gérés et non gérés par l’entreprise. Les vérifications sont appliquées de la même manière pour ne pas accorder de confiance implicite. Le modèle donne aussi la possibilité à l’ensemble des terminaux et à l’ensemble des réseaux d’accéder aux ressources de l’entreprise.

La vérification est continue et ne s’arrête pas au moment où l’accès à une ressource a été accordé. La conformité du terminal utilisé peut changer, ce qui conduit à une réévaluation de l’accès accordé. Le trafic est aussi surveillé pour détecter une action malveillante.

En 2014, Google intègre le concept du modèle Zero Trust dans un projet de refonte de l’infrastructure. Ce projet s’intitule BeyondCorp en référence au nom de l’architecture à implémenter au sein de Google. BeyondCorp désigne aussi la solution Zero Trust que Google propose à ses clients. Cette décision a été prise à la suite d’une cyberattaque : l’Opération Aurora.

Article sur l’Opération Aurora : https://cyware.com/news/everything-you-need-to-know-about-operation-aurora-5c5f5b99

L’objectif est de protéger l’accès aux services web et SSH depuis des terminaux gérés par Google. La même année, la Cloud Security Alliance présente le Software-Defined Perimeter pour proposer un second modèle d’architecture Zero Trust.

L’architecture Zero Trust

Le modèle Zero Trust est un concept et ne représente pas une solution qu’une entreprise peut appliquer en tant que tel. Néanmoins, le NIST a déterminé les composants logiques permettant d’obtenir un début d’architecture Zero Trust dans son état de l’art. Une architecture Zero Trust est divisée en deux parties : le Control Plane et le Data Plane.

Le Control Plane

Le Control Plane représente l’ensemble des composants chargés de collecter les informations nécessaires à la retranscription du contexte et chargés de la prise de décision. Il est composé du Policy Decision Point, lui-même composé du Policy Engine et du Policy Administrator. Le Policy Engine applique les politiques d’accès en s’appuyant sur les données collectées : le contexte. Le Policy Administrator génère les identifiants nécessaires à la communication entre le terminal et la ressource.

Dans le Control Plane, d’autres éléments sont aussi présents pour compléter la constitution d’un contexte comme les logs d’activité, les inventaires d’identité pour les utilisateurs et les terminaux ou encore la PKI pour vérifier l’authenticité d’un certificat. La centralisation des logs et la remontée d’alertes assurent la surveillance continue de l’ensemble du trafic avec le SIEM. Pour protéger le dispositif mis en place, la Threat Intelligence peut aussi être utilisée.

Le Data Plane

Le reste des composants se trouve dans le Data Plane. Le Data Plane représente l’ensemble des composants avec lesquels l’utilisateur peut interagir. L’utilisateur peut interagir avec le Policy Enforcement Point mais pas avec le Policy Decision Point qui est dans le Control Plane.

Lorsqu’un utilisateur veut accéder à une ressource, il est obligé de passer par le Policy Enforcement Point. Le Policy Enforcement Point envoie une demande au Policy Decision Point qui va renvoyer la décision prise. Ce composant ne collecte que l’information transmise par le Policy Decision Point et applique la décision renvoyée.

Pour revenir à BeyondCorp et au Software-Defined Perimeter (SDP), les architectures sont différentes mais utilisent ces composants logiques. BeyondCorp utilise un portail pour imposer les décisions renvoyées par le Data Plane et imposer l’authentification à l’utilisateur. Pour l’authentification, BeyondCorp utilise aussi un serveur RADIUS et le SSO. Le SDP utilise un autre système pour authentifier l’utilisateur avec l’envoi de Single-Packets Authorization.

Le Single-Packet Authorization

Le Single-Packet Authorization (SPA) s’appuie sur le principe du port-knocking. Le port-knocking consiste à ouvrir un port lorsqu’une séquence d’envoi de paquets sur certains ports est réalisée. Un port est un numéro unique codé sur 16 bits pour indiquer que l’information envoyée ou reçue est destinée à une application en particulier. Le port répond à un besoin de distinguer une information d’une autre pour une même machine ayant la même adresse IP. De cette manière, une connexion en SSH est possible sur le port 22 à un serveur Web pour l’administrer, et l’accès au service web est possible sur le port 80 depuis un navigateur web.

Avec le port-knocking, le service est inaccessible et aucune preuve de son fonctionnement n’est visible tant que la séquence n’a pas été exécutée. Par exemple pour ouvrir le port 22 correspondant au SSH, l’utilisateur doit d’abord envoyer un paquet TCP ou UDP sur le port 800, 400 puis 6523. Un utilisateur qui ne connaît pas la séquence ne peut pas ouvrir le port. De cette manière, le pare-feu a des règles dynamiques avec une politique default-drop. Le pare-feu n’accepte aucune connexion entrante à part celles qui sont déjà établies par défaut et ajoute une règle lorsque la séquence est respectée.

Le projet open-source fwknop implémente le SPA en suivant le principe du port-knocking pour donner un accès à un ou plusieurs services. La seule différence entre le SPA et le port-knocking est la génération du paquet authentifié et chiffré remplaçant l’usage de l’envoi de paquets sur une séquence de ports spécifiques. De cette manière, le SPA porte les informations permettant d’authentifier l’utilisateur et le terminal contrairement au port-knocking. Dans ce premier article, nous avons donné une définition du modèle Zero Trust et le contexte historique derrière ses principes. Nous avons ensuite vu les composants d’une architecture Zero Trust et un projet open-source permettant d’implémenter le SPA utilisé par l’architecture Software-Defined Perimeter (SDP).

Références

  *   Avis scientifique et technique : le modèle Zero Trust, publié le 15 avril 2021 par l’ANSSI : https://www.ssi.gouv.fr/uploads/2021/04/anssi-avis_scientifiques_et_techniques-modele_zero_trust.pdf

  *   Special Publication Zero Trust Architecture, publié le 10 août 2020 par le NIST : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

  *   Documentation sur le Single-Packet Authorization, mis à jour en 2016 : http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

  *   Everything You Need To Know About Operation Aurora, publié le 08 août 2016 par Cyware Hacker News :https://cyware.com/news/everything-you-need-to-know-about-operation-aurora-5c5f5b99

Les cyberattaques ne concernent plus uniquement les grandes entreprises. Aujourd’hui, les PME figurent parmi les cibles les plus fréquentes des hackers, souvent parce qu’elles pensent à tort ne pas être exposées. Pourtant, un vol de données, un ransomware ou une simple faille non corrigée peut paralyser une activité, générer des pertes financières importantes et nuire durablement à la confiance des clients.

Face à ces risques, l’audit de cybersécurité PME est bien plus qu’une formalité technique. C’est un levier de protection, de conformité, mais aussi de performance. En identifiant les failles, en évaluant les dispositifs de sécurité et en sensibilisant les équipes, cet audit permet aux dirigeants d’agir avant qu’un incident ne survienne et n’impacte le business.

 

Les PME : premières visées des cybercriminels 

 

En France, 37% des attaques ont visé des TPE/PME en 2024 selon un rapport de l’ANSSI publié en 2025, ce qui en font la première cible d’attaque des cybercriminels.

Les PME sont des cibles prioritaires, souvent en raison de ressources limitées et d’une sensibilisation inadéquate.

 

Des coûts potentiellement catastrophiques

 

Ces coûts incluent les aspects visibles (restauration, notifications RGPD…) et cachés (impact réputation, perte de clients, hausse de la dette…)

L’audit : une réduction proactive des risques

Un audit de cybersécurité permet de :

• D’identifier les vulnérabilités techniques et organisationnelles du système d’information
• De définir des mesures de correction par rapport aux risques mis en lumière par les vulnérabilités relevées préalablement
• De disposer d’une estimation du coût des mesures (financier et humain)
• D’implémenter selon son budget les mesures ciblées
• De valider les améliorations avec un contre-audit ou des tests unitaires

 

Conformité réglementaire et assurance

 

Un audit de cybersécurité joue un rôle central dans la conformité aux réglementations en vigueur. Qu’il s’agisse du RGPD, du NIS, de DORA ou de certaines normes qu’on souhaite s’appliquer, ces cadres exigent une connaissance précise des risques, une cartographie des données sensibles et un plan d’action formel. L’audit permet  d’avoir une vue synthétique de son niveau de conformité et de ce à quoi elle s’expose.

Car à défaut de conformité, les conséquences peuvent être lourdes. Les amendes prévues par le RGPD peuvent atteindre jusqu’à 4 % du chiffre d’affaires annuel, sans compter les conséquences sur la réputation et la perte de confiance des clients.

Par ailleurs, pour souscrire une assurance cyber, la plupart des assureurs exigent un état des lieux préalable du niveau de sécurité. Là encore, l’audit sert de base solide pour évaluer les garanties à mettre en place et justifier d’une démarche proactive de maîtrise du risque.

 

Sensibilisation : le facteur humain

 

• 95 % des incidents proviennent d’erreurs humaines.
• Seulement 51 % des PME forment leurs employés et 22 % disposent d’un plan de réaction.

 

ROI et renforcement de la performance

 

Pour une entreprise, réaliser un audit de cybersécurité représente bien plus qu’un simple diagnostic technique : c’est un véritable investissement stratégique. En détectant en amont les failles de sécurité, l’audit permet de limiter les risques d’incident et de réduire le coût moyen d’une cyberattaque, souvent estimé à plusieurs dizaines de milliers d’euros pour une PME.

C’est aussi un levier d’optimisation budgétaire, en réorientant les ressources vers les priorités réelles identifiées, plutôt que de multiplier des solutions parfois redondantes ou mal adaptées.

En renforçant la posture de sécurité, l’audit contribue également à améliorer la réputation de l’entreprise. Il instaure un climat de confiance avec les clients et partenaires, ce qui devient un avantage concurrentiel déterminant, notamment dans les environnements B2B sensibles aux enjeux de cybersécurité.

 

Bonnes pratiques pour les PME

-Audits annuels :  il est conseillé d’alterner les audits de cybersécurité qui vont donner une feuille de route court/moyen terme et les tests de pénétration

-Budget dédié : entre 4 000 € et 15 000 € selon la taille, la criticité, la maturité et l’objectif de conformité visé.

-Impliquer la direction, communiquer les résultats et suivre les recommandations.

Par Cédric Boucly, Directeur Cybersécurité chez Tenexa