L’architecture réseau des entreprises a longtemps reposé sur un modèle centralisé, aujourd’hui bousculé par la généralisation du SaaS et du cloud public. Comprendre ce déplacement — pourquoi il a eu lieu, ce qu’il résout et ce qu’il risque — éclaire mieux le vocabulaire SASE/SSE/ZTNA que n’importe quelle liste d’acronymes.
Hier : le modèle « hub-and-spoke »
Pendant des années, utilisateurs distants et sites distants établissaient un VPN (IPSec ou SSL) vers le data center de l’entreprise. Le data center jouait le rôle de hub : tous les flux — vers Internet comme vers les applications internes — y transitaient pour être inspectés (pare-feu, proxy, IDS/IPS), avant d’être renvoyés (hairpinés) vers leur destination réelle.
L’avantage était réel : un contrôle centralisé, une politique homogène. Mais l’inconvénient l’était tout autant : un goulot d’étranglement structurel. Si le lien WAN vers le data center tombait ou saturait — sauvegardes, gros transferts —, l’ensemble des utilisateurs se retrouvait bloqué. Pire, acheminer du trafic SaaS (Microsoft 365, Salesforce, GitHub) via ce détour central créait une latence entièrement artificielle.
Aujourd’hui : SASE et SSE
Avec la généralisation du SaaS et du cloud public, la sécurité « monte » dans le cloud et se décentralise au plus près des utilisateurs — à l’edge.
Définition
SASE (Secure Access Service Edge) est un cadre d’architecture combinant réseau et sécurité en périphérie. Côté réseau : SD-WAN, optimisation de chemin, peering, sortie locale (local breakout). Côté sécurité — ce que l’on appelle SSE (Security Service Edge) : NG-SWG, CASB, ZTNA, FWaaS, DLP, filtrage DNS.
L’idée centrale est de porter l’inspection au bord du réseau — un point de présence (PoP) proche — plutôt que d’imposer un détour par le data center. Le plan de contrôle (politiques, identités, journaux) reste centralisé dans le cloud du fournisseur, tandis que l’exécution (l’inspection elle-même) est distribuée sur des PoP en périphérie.
Le risque d'une mauvaise conception
Faire reposer un site entier sur un unique lien reproduit, à une autre échelle, le goulot d’étranglement qu’on cherchait à éliminer. D’où la nécessité de liens multiples, de SD-WAN (MPLS + fibre + 4G/5G), et de PoP redondants chez le fournisseur.
Les trois piliers du SSE
NG-SWG (Next-Gen Secure Web Gateway)
Le NG-SWG filtre et contrôle l’accès au web et au SaaS : catégorisation d’URL, contrôle applicatif fin (YouTube en lecture seule, blocage de l’upload sur WeTransfer), inspection TLS sélective, anti-malware et anti-phishing en ligne, parfois isolement de navigateur à distance. Il se livre le plus souvent as-a-service, via des PoP globaux et un agent endpoint léger.
Il ne faut pas le confondre avec un forward proxy traditionnel. Ce dernier, souvent hébergé sur site, excelle en filtrage d’URL, authentification et cache. Le NG-SWG en est l’évolution cloud-native, orientée identité et application plutôt que simple domaine, avec inspection TLS sélective, DLP intégré, bac à sable anti-malware, politiques contextuelles, et intégration native à CASB/ZTNA/SSE.
Les deux ne sont pas redondants dès lors que la cible est le contrôle applicatif granulaire, les utilisateurs nomades, le SaaS, des politiques identitaires unifiées, et la visibilité sur le Shadow IT. Pour un simple besoin de cache et de blocage basique sur un LAN local fixe, un forward proxy suffit encore. Sur un campus étendu avec des liaisons coûteuses, garder un proxy local pour le seul cache (vidéos, correctifs) tout en déléguant la décision au NG-SWG reste une architecture pertinente — de même qu’un forward proxy break-glass peut servir de sortie minimale si le PoP devient injoignable.
CASB (Cloud Access Security Broker)
Le CASB gouverne la sécurité d’usage des applications cloud et SaaS. Il assure la découverte du Shadow IT (via les journaux proxy/DNS ou des API), des contrôles API (audit des données au repos dans Office 365, Google Workspace, Salesforce — DLP, classification, mise en quarantaine, prévention des partages publics), des contrôles en ligne (blocage d’un envoi de document sensible, filigrane forcé, chiffrement côté client), et vérifie la posture des tenants SaaS (MFA activée, partage externe maîtrisé).
ZTNA (Zero Trust Network Access)
Principe
« Ne jamais faire confiance, toujours vérifier. » Le ZTNA remplace l’accès réseau large qu’offrait un VPN classique par un accès applicatif fin : on expose l’application, pas le réseau qui l’héberge.
La confiance y est dynamique, réévaluée en continu selon l’identité, la posture de l’appareil (système à jour, disque chiffré, EDR actif), l’emplacement, l’heure, et un score de risque. L’accès suit le principe du moindre privilège : on n’ouvre que l’application demandée, jamais le sous-réseau entier. En pratique, le ZTNA s’intègre aux fournisseurs d’identité (Entra ID, Okta), aux solutions de gestion d’appareils (Intune, Jamf, CrowdStrike), et aux passerelles applicatives du fournisseur SSE — remplaçant les ACL fondées sur l’IP par des politiques fondées sur l’identité.
L’edge, périphérie du réseau
L’edge désigne les PoP de sécurité géographiquement proches de l’utilisateur ou du site. On y trouve l’on-ramp (agent sur poste, tunnel IPSec/Anycast, GRE, proxy PAC), l’inspection elle-même (NG-SWG, DLP, FWaaS, filtrage DNS, CASB inline), et une sortie Internet optimisée (peering locaux, CDN). L’intérêt est direct : éviter le hairpinning vers un data center lointain, réduire la latence, et décharger la bande passante des liens privés.
DLP : empêcher la fuite
Le DLP (Data Loss Prevention) vise à empêcher la fuite ou l’exfiltration de données sensibles — données personnelles, secrets, code source, coordonnées bancaires. Ses moteurs combinent motifs (expressions régulières, algorithme de Luhn pour les cartes bancaires), empreintes de documents, classifications par étiquette (MIP), et analyse contextuelle (NLP). Il s’applique à plusieurs points : le poste (agent), le réseau (NG-SWG ou CASB inline), le SaaS (API-CASB), la messagerie (passerelle email). La bonne pratique consiste à démarrer en mode audit, affiner les règles pour limiter les faux positifs, puis expliquer clairement les politiques aux utilisateurs concernés avant tout blocage.
Ce que le modèle centralisé perdait, SASE le récupère
Dans l’ancien modèle, tout transitait par le data center — avec un risque de saturation dès qu’une sauvegarde, une mise à jour ou un pipeline CI/CD sollicitait fortement le lien. Avec SASE/SSE, la sortie locale (local breakout) vers Internet et le SaaS, combinée aux PoP en périphérie, désengorge structurellement ce goulot. Sur site, on complète avec de la QoS (DSCP), un split tunneling maîtrisé, du cache, et si nécessaire de l’optimisation WAN.
Synthèse : comment tout s’imbrique
L’ordre logique d’une architecture SASE mature suit un enchaînement précis : d’abord l’identité (fournisseur d’identité, MFA robuste, idéalement FIDO2) ; puis l’accès applicatif via ZTNA plutôt qu’un accès réseau plat ; l’inspection à l’edge (NG-SWG, CASB, DLP, FWaaS dans le cloud) ; un transport optimisé (SD-WAN multi-liens, sortie locale vers le SaaS) ; et enfin l’annuaire et l’AAA — voir la note sur RADIUS, LDAP et Active Directory — pour ancrer l’identité elle-même. La résilience de l’ensemble repose sur la multiplication des PoP et des liens, un cache de politiques local, et une surveillance continue (journaux, latence, saturation).
Pièges récurrents
Un site avec un seul lien Internet est un point unique de défaillance — prévoir au moins deux liens et un basculement SD-WAN. Une inspection TLS trop agressive nuit à la vie privée et aux flux sensibles (banque, santé) — prévoir un contournement sélectif. Un VPN « réseau » sur-permissif facilite le mouvement latéral — lui préférer le ZTNA, plus granulaire.