Dans un contexte où les réseaux d’entreprise sont de plus en plus exposés aux menaces internes et externes, le Network Access Control (NAC) s’impose comme un pilier fondamental de la cybersécurité. L’essor du télétravail, du BYOD et des objets connectés a considérablement élargi la surface d’attaque des systèmes d’information. Le NAC permet de reprendre le contrôle sur qui et quoi se connecte au réseau, en appliquant des politiques de sécurité dès la tentative d’accès, qu’il s’agisse d’un utilisateur, d’un poste de travail ou d’un équipement IoT.

Contrôle des accès et conformité des équipements

L’un des principaux intérêts du NAC réside dans sa capacité à authentifier et à évaluer la conformité des équipements avant de leur accorder un accès au réseau. En s’appuyant sur des critères tels que l’identité de l’utilisateur, l’état de sécurité du terminal ou le type d’équipement, le NAC limite les accès non autorisés et réduit significativement les risques de compromission. Les équipements non conformes peuvent être automatiquement isolés ou redirigés vers un réseau restreint.

Segmentation dynamique et réduction des risques

Au-delà du contrôle d’accès, le NAC joue un rôle clé dans la segmentation dynamique du réseau. En attribuant des droits d’accès adaptés au profil de chaque utilisateur ou appareil, il limite les mouvements latéraux en cas d’incident de sécurité. Cette logique s’inscrit pleinement dans une approche Zero Trust, renforçant la protection des ressources critiques et la résilience globale du réseau.

Visibilité, supervision et intégration sécurité

Enfin, le NAC offre une visibilité centralisée et en temps réel sur l’ensemble des connexions réseau, un atout majeur pour les équipes de cybersécurité. Cette supervision facilite la détection des comportements anormaux, l’analyse des incidents et la conformité réglementaire. Intégré à des solutions telles que le SIEM, l’EDR ou l’IAM, le NAC devient un levier stratégique pour améliorer durablement la posture de sécurité de l’entreprise.

Nos solutions

Nous recommandons la solution FortiNAC, de Fortinet ; ainsi que notre solution RadX, selon les besoins. N’hésitez pas à nous contacter pour échanger avec nos experts.

L’article NAC : le gardien invisible du réseau d’entreprise est apparu en premier sur IRONIE.

Le Zero Trust Network Access (ZTNA) est un terme qui, en 2025, n’est plus un simple buzzword. Il rejoint désormais les concepts établis comme le SD‑WAN, l’authentification multi-facteurs (MFA) ou l’IoT.

Il n’existe pas de consensus clair dans l’industrie réseau et sécurité sur la définition exacte du ZTNA. Toutefois, si vous interrogez la plupart des fournisseurs, vous obtiendrez généralement trois principes, exprimés différemment :

• Le client n’est pas considéré comme fiable par défaut et n’a donc accès à rien initialement — c’est le principe du Zero Trust ;
• Les connexions sont établies par application : le client demande l’accès à une ressource spécifique, et non à un sous‑réseau complet ;
• Le client est contrôlé avant et pendant la connexion pour vérifier qu’il est toujours autorisé à accéder à la ressource — c’est le client posturing.

Après cette mise en contexte, voyons comment Fortinet gère les connexions ZTNA en mode transfert TCP.

L’environnement

Nous disposons de :

• Un client externe, appelé FortiClient, qui souhaite accéder à une ressource ;
• Un FortiGate jouant le rôle de proxy d’accès ZTNA : ztnaproxy.ad.labdomain.com ;
• Un serveur FortiClient EMS : ems.ad.labdomain.com, qu’il soit auto-hébergé ou en SaaS ;
• Un serveur LAN : win-server.ad.labdomain.com, accessible via ZTNA, ainsi qu’un serveur win-ad.ad.labdomain.com, utilisé uniquement pour la démonstration.

Versions utilisées : FortiOS 7.4.9, FortiClient 7.4.5, FortiClient EMS 7.4.5.

Commençons par le client, là où tout débute.

Comment FortiClient gère le ZTNA

FortiClient reçoit sa configuration ZTNA depuis EMS. La première étape consiste à déterminer si la ressource demandée correspond à une destination ZTNA. FortiClient vérifie si ce que l’utilisateur tente d’atteindre figure dans sa liste de destinations ZTNA. Si oui, il poursuit le processus.

Qui effectue la résolution DNS des FQDN ZTNA ?

C’est FortiClient lui‑même. C’est le processus FortiTCS (Tunnel Control Service) qui gère :

• la configuration ZTNA reçue d’EMS,
• l’enregistrement des paramètres,
• l’attribution d’adresses IP factices pour la résolution DNS,
• l’exécution d’un proxy DNS local.

Lors d’une mise à jour ZTNA, on observe la liste des destinations ZTNA. FortiClient intercepte donc les requêtes DNS vers les FQDN ZTNA et renvoie une IP factice, même si la connexion n’est pas destinée à ZTNA. Pour les destinations ZTNA définies en IP, rien de particulier : la connexion est simplement transmise.

Rôle de FortiTCS

FortiTCS établit une connexion sécurisée vers le FortiGate (proxy ZTNA / TFAP / ZTNA gateway) et y transfère le trafic pertinent. Lorsqu’un FQDN ZTNA est contacté, FortiTCS génère une requête HTTP GET vers le FortiGate :

GET /tcp?address=win-server.ad.labdomain.com&port=3389&tls=0 HTTP/1.1

Cette requête indique :

• la ressource demandée,
• le port,
• si un chiffrement supplémentaire est demandé.

Le FortiGate doit ensuite résoudre lui‑même le FQDN, car l’IP fournie par FortiClient est factice.

Comment FortiGate gère le ZTNA

Le FortiGate agit comme un proxy : il reçoit la connexion FortiClient et se connecte au serveur réel à sa place. Le traitement ZTNA est assuré par le processus WAD (Web Application Daemon).

Étapes principales côté FortiGate

1. Vérification du certificat client FortiClient envoie le certificat utilisateur fourni par EMS. Le FortiGate vérifie ce certificat via la CA ZTNA d’EMS.
2. Réception de la requête HTTP ZTNA Le FortiGate lit la requête GET envoyée par FortiTCS.
3. Résolution DNS du FQDN cible Le FortiGate résout le FQDN réel (ex. 192.168.1.241).
4. Correspondance avec une politique proxy Le FortiGate identifie la proxy-policy ZTNA correspondante (ex. policy ID 123).
5. Établissement de la connexion vers le serveur réel Le FortiGate se connecte au serveur cible, en appliquant un SNAT par défaut (IP de l’interface de sortie). Un IP pool peut remplacer ce comportement.
6. Création du tunnel de transfert TCP Le FortiGate renvoie un 101 Switching Protocols et établit le tunnel.

ZTNA et UDP

Depuis FortiOS 7.6.0 et FortiClient 7.4.1, ZTNA supporte également l’UDP. FortiClient encapsule alors l’UDP dans TCP, établit une connexion QUIC, puis transfère le trafic comme pour TCP.

EMS est‑il obligatoire ?

Oui, EMS est indispensable pour :

• distribuer les certificats utilisateurs,
• fournir la configuration ZTNA,
• permettre à FortiClient d’être en mode ZTNA complet.

Sans EMS, pas de destinations ZTNA configurables, donc pas de ZTNA TCP forwarding. Ce serveur FortiClient-EMS peut être :

• Hébergé sur votre infrastructure (on premise) ;
• Hébergé dans le cloud Fortinet (EMS Cloud);
• Embarqué dans la solution FortiSASE.

L’article Fortinet Universal ZTNA est apparu en premier sur IRONIE.

Les équipes IT équipées de NPS se retrouvent avec :

• des règles RADIUS difficiles à maintenir ;
• très peu de visibilité sur les logs ;
• pas de MFA natif ;
• une gestion complexe des environnements hybrides ;
• des risques accrus liés à la dette technique ;
• un produit qui n’évolue plus techniquement (Microsoft envisage une EOL, avec retrait de Windows Server)

C’est pour tout cela et plus encore que nous avons développé un nouvel outil IAM, que nous avons baptisé RadX

Ce que RadX vous apporte :

• Remplacement complet de NPS ;
• Authentification forte 802.1X avec certificats ou login/password ;
• Compatibilité avec les équipements Wi-Fi, VPN, NAC ;
• Une interface d’administration simple et efficace ;
• Intégration native avec Entra ID, Active Directory, LDAP ;
• Support du MFA (Local / Yubico / TrustBuilder) ;
• Déploiement cloud ou on-premise ;
• PKI locale embarquée ;
• IDP Saml 2.0

Les entreprises ne peuvent plus compter sur des outils d’hier pour répondre aux enjeux d’aujourd’hui.
Il est temps de moderniser votre gestion des accès réseau.

L’article Bienvenue à RadX est apparu en premier sur IRONIE.