Qu’est-ce que le SSE ? Définition, composants et bonnes pratiques

Qu’est-ce que le SSE ?

Le SSE (Security Service Edge) est une catégorie de marché introduite par Gartner en 2021 qui consolide trois fonctions de sécurité principales, Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) et Zero Trust Network Access (ZTNA), dans une plateforme unifiée fournie depuis le cloud. Comme le définit le guide d’architecture de sécurité cloud de Gartner, le SSE est « un sous-composant du SASE qui sécurise l’accès au web, aux services cloud et aux applications privées. »

Le SSE est important parce que vos utilisateurs ne se trouvent plus derrière un seul réseau de confiance. La sécurité doit les suivre. Au lieu de faire transiter le trafic par un centre de données central, le SSE applique des politiques tenant compte de l’identité à proximité de l’utilisateur et de l’application. Cela réduit la latence, comble les lacunes de visibilité et place l’accès à distance, l’utilisation du SaaS et le trafic internet sous un même ensemble de politiques.

Le SSE a émergé parce que les organisations adoptaient uniquement les composants de sécurité du cadre plus large Secure Access Service Edge (SASE) sans la pile réseau complète. Gartner a identifié ce modèle et a défini le SSE comme le sous-ensemble exclusivement sécurité du SASE. Cela a donné aux équipes une catégorie claire pour consolider la sécurité fournie depuis le cloud sans attendre une transformation du réseau étendu (WAN).

SSE vs. SASE

SASE (Secure Access Service Edge) est le cadre plus large dont est issu le SSE. Gartner a introduit le SASE en 2019 comme une convergence du réseau et de la sécurité dans un service unique fourni depuis le cloud. Le SSE en est le sous-ensemble exclusivement sécurité : il contient les contrôles de sécurité d’accès sans la couche de transformation réseau.

La plupart des organisations parviennent à un SASE complet en commençant par le SSE. Les contrôles de sécurité se déploient plus rapidement, l’argumentaire métier est plus simple et les équipes peuvent démontrer la valeur avant d’entreprendre la transformation du WAN. Si votre feuille de route réseau est encore en évolution ou gérée par une équipe distincte, le SSE est le bon point d’entrée.

Pourquoi les organisations ont besoin du SSE

Le SSE répond à une défaillance structurelle de l’architecture de sécurité traditionnelle. Lorsque vos utilisateurs se connectent directement aux applications cloud, le trafic ne passe jamais par votre pile de sécurité sur site. Vous perdez simultanément la visibilité sur l’accès web, l’utilisation du SaaS et les sessions d’applications privées.

Les adversaires remarquent ces angles morts. En 2023, des attaquants ont utilisé la ingénierie sociale contre le centre d’assistance de MGM Resorts pour obtenir un accès et perturber les opérations hôtelières et de casino. Le dépôt SEC 8-K de l’entreprise a estimé un impact financier négatif d’environ 100 millions de dollars pour le seul troisième trimestre, hors coûts de reprise et effets de l’assurance cyber. Lorsque vos utilisateurs, sous-traitants et administrateurs s’authentifient depuis des bureaux à domicile, des réseaux non gérés et des applications cloud, les contrôles centrés sur le périmètre laissent des lacunes que les attaquants axés sur l’identité exploitent. Le SSE réduit ces lacunes en évaluant l’identité et le contexte à chaque session, ce qui limite jusqu’où un seul compte compromis peut aller.

Le SSE consolide les fonctions de sécurité qui protègent l’accès au cloud et au web en un point d’application unique. Au lieu de gérer des appliances distinctes pour le filtrage web, le contrôle des applications cloud et l’accès à distance, vous appliquez une politique cohérente via une plateforme unique fournie depuis le cloud. Cela réduit directement la prolifération des outils qui génère un volume excessif d’alertes et crée des lacunes de couverture entre des produits de sécurité déconnectés. Le SSE est également l’un des moyens les plus pratiques d’appliquer les principes de la sécurité zero trust à l’accès des utilisateurs.

Pour les secteurs réglementés, Security Service Edge a obtenu une validation formelle. Un briefing de la CISA sur les directives fédérales de confiance zéro identifie SASE/SSE comme une architecture acceptable pour répondre aux exigences Trusted Internet Connection (TIC) 3.0, avec une plus grande flexibilité que les modèles traditionnels.

Chaque composant de SSE comble une lacune d’accès spécifique qu’a ouverte le travail distribué.

Composants principaux de SSE

Les plateformes Security Service Edge font converger trois services de sécurité fondamentaux. Chacun répond à un modèle d’accès distinct que votre main-d’œuvre distribuée crée chaque jour.

Passerelle web sécurisée (SWG)

Passerelle Web sécurisée sécurise l’accès à Internet et au web en appliquant le filtrage d’URL, la protection antimalware, l’inspection du contenu et les politiques d’utilisation acceptable. Dans SSE, les capacités de passerelle web sécurisée doivent être fournies depuis le cloud, et non basées sur des appliances. Une exigence architecturale fondamentale de SSE est que l’inspection s’effectue dans une infrastructure cloud distribuée proche des utilisateurs, plutôt qu’au moyen d’une pile centralisée d’appliances. Cela élimine la pénalité de latence liée au routage du trafic web via un centre de données central.

Courtier de sécurité d’accès au cloud (CASB)

Courtier de sécurité d’accès au cloud offre visibilité et contrôle sur l’utilisation des applications cloud, applique des politiques de sécurité des données sur les plateformes SaaS et surveille les violations de conformité. Dans SSE, les fonctions de courtier de sécurité d’accès au cloud fonctionnent selon deux modes : inline, pour le blocage en temps réel, et basé sur API, pour la découverte rétrospective d’applications cloud non approuvées.

La distinction entre les deux modes est importante sur le plan opérationnel. Le CASB basé sur API détecte le shadow IT que l’inspection inline manque, car le trafic vers des applications non approuvées ne passe jamais par le proxy SSE. Si vous comparez les bases du CASB à des contrôles cloud plus larges, cette séparation est l’une des principales raisons pour lesquelles les plateformes SSE incluent à la fois des méthodes inline et basées sur API.

Accès réseau zero trust (ZTNA)

Zero Trust Network Access remplace le VPN hérité en appliquant les principes zero trust du NIST à l’accès à distance. Chaque requête est vérifiée en fonction de l’identité et du contexte, avec un accès à privilège minimal accordé uniquement à des applications spécifiques plutôt qu’à de larges segments réseau. En pratique, l’accès réseau zero trust est souvent le cas d’usage SSE le plus rapide à déployer, car il correspond clairement à l’accès distant aux applications.

Composants supplémentaires

Au-delà des trois services principaux, les plateformes SSE intègrent généralement :

• Firewall-as-a-Service: Capacités de pare-feu réseau fournies depuis le cloud sans appliances sur site
• Data Loss Prevention (DLP): Intégré au CASB pour appliquer les politiques de traitement des données dans les applications cloud
• Remote Browser Isolation: Exécute les sessions web dans des environnements isolés afin de contenir les menaces basées sur le navigateur
• Cloud Security Posture Management (CSPM): Découverte continue des mauvaises configurations dans les environnements cloud

Ensemble, ces composants remplacent le modèle traditionnel de trafic en hairpin par une application distribuée des contrôles dans le cloud. La manière dont ils fonctionnent ensemble en tant que système est ce qui façonne les véritables décisions de déploiement.

Fonctionnement de SSE

Security Service Edge remplace l’inspection centralisée basée sur des appliances par une application distribuée des contrôles dans le cloud. SSE achemine le trafic vers des Points of Presence cloud distribués, ou PoP, situés à proximité des utilisateurs et des destinations.

• L’ancien chemin : User → VPN → Data Center → Internet → Data Center → VPN → User
• Le chemin SSE: User → Nearest Cloud PoP (inspection + enforcement) → Destination

Comme le NIST SP 1800-35 le décrit, les architectures modernes zero trust et alignées sur SSE dirigent le trafic vers des points d’application distribués situés plus près de l’utilisateur final ou du terminal, plutôt que de le renvoyer vers un centre de données central pour inspection et chiffrement.

Flux de trafic et application des politiques

Sur la base du NIST 1800-35, SSE traite le trafic selon une séquence définie :

1. Votre utilisateur ou client s’authentifie auprès du fournisseur d’identité, et les politiques d’accès conditionnel sont évaluées.
2. SSE établit un tunnel authentifié vers le PoP cloud le plus proche, et non vers votre centre de données.
3. Le trafic passe par le service cloud SSE pour inspection : filtrage d’URL, analyse des menaces, DLP et contrôle d’accès.
4. SSE applique les politiques d’accès conditionnel pendant toute la session, et pas seulement lors de la connexion.
5. SSE transfère le trafic vers la destination : Internet public via SWG, applications SaaS via CASB ou ressources privées via un connecteur ZTNA.

L’étape quatre constitue la distinction architecturale critique. Le VPN hérité authentifie une seule fois lors de l’établissement du tunnel. SSE évalue la politique en continu sur la base de signaux contextuels évolutifs, notamment l’état de conformité de l’appareil, le score de risque utilisateur, la localisation géographique, la sensibilité de l’application et les restrictions temporelles.

Cette évaluation continue repose sur une chose : l’identité. C’est la base sur laquelle repose l’ensemble du modèle d’application.

Contrôle basé sur l’identité

SSE utilise l’identité vérifiée comme principal mécanisme de contrôle d’accès. La politique suit l’utilisateur, l’appareil et le contexte de session, remplaçant l’approche fondée sur l’emplacement réseau (adresse IP ou appartenance à un VLAN) dont dépendaient les architectures héritées.

La manière la plus claire de voir la politique sensible à l’identité en action se trouve dans les environnements où l’ancien périmètre a échoué en premier.

Cas d’usage de SSE

SSE traite quatre scénarios dans lesquels la sécurité basée sur le périmètre montre le plus clairement ses limites.

Main-d’œuvre à distance et hybride

Lorsque votre personnel se connecte depuis des bureaux à domicile et des réseaux non gérés, un VPN traditionnel accorde un large accès réseau à toute personne qui s’authentifie avec succès. SSE remplace ce modèle par un accès au niveau des applications via ZTNA, une protection contre les menaces web via SWG et l’application des politiques SaaS via CASB. Chaque session est évaluée en continu plutôt que considérée comme fiable après une seule connexion.

Environnements applicatifs cloud-first

Les organisations qui exécutent la plupart des charges de travail dans le SaaS ou le cloud public n’ont pas de périmètre sur site pour appliquer des contrôles. Le trafic circule directement des utilisateurs vers les applications cloud, contournant entièrement toute pile d’inspection sur site. SSE déplace l’application des contrôles vers des PoP cloud distribués, en appliquant des politiques sur chaque session SaaS via CASB et sur chaque requête web via SWG, quel que soit l’endroit où se trouve l’utilisateur ou l’appareil qu’il utilise.

Secteurs réglementés

Les soins de santé, les services financiers et les agences fédérales sont soumis à des exigences spécifiques en matière de traitement des données, de journalisation des accès et d’architecture réseau. Les directives de la CISA reconnaissent les architectures alignées sur SSE comme acceptables pour satisfaire aux exigences fédérales de TIC 3.0. CASB fournit la classification des données et l’application de la DLP requises par ces environnements, avec des pistes d’audit qui satisfont aux obligations de reporting de conformité.

Shadow IT et prolifération du cloud

Lorsque les employés adoptent des outils SaaS non autorisés, l’équipe de sécurité n’a aucune visibilité sur les flux de données ni sur leur destination. Le CASB à double mode de SSE (inline pour le blocage en temps réel et basé sur API pour la découverte rétrospective) détecte à la fois l’usage cloud autorisé et non autorisé sur une plateforme unique, sans exiger que tout le trafic passe par un proxy traditionnel.

Dans ces quatre scénarios, les avantages opérationnels de SSE vont bien au-delà de la simple réduction des failles de sécurité.

Principaux avantages de l’adoption de SSE

La consolidation de la sécurité web, SaaS et de l’accès à distance dans une plateforme unique fournie depuis le cloud génère des gains en matière de posture de sécurité, de charge opérationnelle et de charge de travail des analystes, souvent simultanément.

1. Amélioration mesurable de la posture de sécurité : La valeur principale de SSE réside dans la cohérence architecturale. Les politiques de sécurité suivent les utilisateurs et les applications quel que soit leur emplacement, ce qui réduit les écarts créés lorsque l’accès à distance, la sécurité SaaS et le filtrage web sont gérés séparément. Cette cohérence explique pourquoi security service edge convient aux organisations ayant des utilisateurs distribués et un accès cloud-first aux applications.
2. Consolidation des outils et réduction des coûts : Si vous gérez des appliances distinctes pour le filtrage web, le contrôle des applications cloud, l’accès à distance et la prévention des pertes de données, SSE les regroupe dans une plateforme unique. Moins de fournisseurs signifie moins de contrats de licence, moins de contrats de support et moins de moteurs de politique à maintenir.
3. Réduction des alertes SOC et efficacité opérationnelle : La consolidation SSE réduit le nombre de sources d’alerte distinctes alimentant votre SOC. Lorsque vous combinez cela avec une plateforme d’extended detection and response (XDR) qui améliore le ratio signal/bruit, l’impact opérationnel se cumule : votre équipe passe moins de temps à trier les alertes redondantes et plus de temps à enquêter sur les menaces réelles.
4. Élimination de la surface d’attaque VPN : Le remplacement du VPN par le zero trust network access supprime les larges autorisations d’accès réseau qui permettent les mouvements latéraux après la compromission des identifiants. Vos utilisateurs ne reçoivent qu’un accès spécifique aux applications, ce qui réduit le rayon d’impact de toute identité compromise. Pour de nombreuses organisations, le remplacement du VPN constitue le point d’entrée le plus pratique et le moins contraignant vers SSE. Si votre équipe évalue encore la sécurité VPN, il s’agit souvent du premier cas d’usage métier qui obtient une approbation budgétaire.

Ces gains sont réels. Le travail nécessaire pour les atteindre l’est aussi.

Défis de l’adoption de SSE

La plupart des organisations rencontrent le même ensemble d’obstacles, quel que soit le choix de la plateforme ou la taille de l’équipe.

1. Pénurie de compétences en cybersécurité : Le déploiement de SSE exige une expertise en architectures de sécurité cloud, en migration des politiques et en intégration multiplateforme. SSE promet une simplification opérationnelle, mais y parvenir nécessite une planification, une conception architecturale et une discipline des politiques que de nombreuses organisations sont encore en train de développer.
2. Intégration de l’infrastructure héritée : Vous ne pouvez pas simplement abandonner une infrastructure sur site fonctionnelle. La plupart des entreprises ont réalisé des investissements importants dans une variété d’outils et de fournisseurs, dont beaucoup restent déployés sur site. La plupart des migrations fonctionnent pendant un certain temps selon un modèle hybride, et ce modèle entraîne sa propre charge de gestion.
3. Résistance organisationnelle et dette de cybersécurité : Les workflows existants et les connaissances institutionnelles construits autour des outils hérités créent une friction de migration plus difficile à quantifier que la complexité technique, mais tout aussi perturbatrice pour les calendriers.
4. Lacunes de visibilité de bout en bout : SSE accroît les dépendances externes que vous ne possédez ni ne contrôlez. Lorsque des problèmes surviennent, vous disposez d’une visibilité limitée sur les réseaux des FAI, les performances des applications SaaS et les autres dépendances cloud. Cela complique la réponse aux incidents et nécessite des approches de surveillance que vos runbooks actuels ne couvrent peut-être pas.

Aucun de ces obstacles n’est une raison d’attendre. Chacun est prévisible, et les pratiques ci-dessous y répondent directement.

Bonnes pratiques SSE

Les équipes qui déploient SSE avec le plus de succès partagent quelques habitudes constantes : elles commencent de manière ciblée, alignent les parties prenantes dès le départ et mesurent avant et après. Ces pratiques s’appliquent que vous déployiez pour 500 utilisateurs ou 50 000.

• Migrer par phases, pas tout d’un coup : Migrer simultanément toutes les fonctions de sécurité introduit un risque cumulatif : interruptions de service, tests de politique inadéquats et complexité qui dépasse la capacité de votre équipe. Commencez par un seul cas d’usage (ZTNA pour l’accès à distance ou SWG pour le trafic internet), démontrez la valeur, puis étendez. Cela s’applique aussi au parcours SASE plus large : déployer SSE avant de tenter une convergence SASE complète avec la transformation WAN réduit le risque et préserve la flexibilité de votre feuille de route réseau.
• Commencer par ZTNA pour une main-d’œuvre distribuée : ZTNA est souvent le point d’entrée le plus efficace, car il répond aux lacunes immédiates de sécurité de l’accès à distance, remplace les VPN hérités problématiques, apporte des améliorations de l’expérience utilisateur qui renforcent l’adhésion de l’organisation et fournit une journalisation granulaire des accès qui améliore la visibilité du SOC sur des tunnels VPN opaques.
• Mettre en place tôt une gouvernance conjointe sécurité-réseau : Avant le déploiement, définissez la gouvernance de l’administration de la plateforme, de l’autorité sur les politiques et des chemins d’escalade du SOC. Sans attribution claire des responsabilités, la migration de la plateforme dépasse votre modèle opérationnel et crée des lacunes de sécurité pendant la transition.
• Évaluer la prestation gérée vs autogérée : Si votre équipe est déjà contrainte en ressources, évaluez les services SSE gérés pour le déploiement initial, l’optimisation continue des politiques et la surveillance continue. Cette approche peut permettre de capter les bénéfices de la consolidation sans aggraver l’épuisement de l’équipe, en particulier pour les organisations du mid-market sans forte capacité d’ingénierie de sécurité.
• Établir des références avant le déploiement : Documentez votre volume d’alertes actuel, la répartition du temps de triage des analystes et la prolifération des politiques avant de déployer SSE. Suivez ensuite ces métriques afin de constituer les preuves dont votre direction a besoin pour poursuivre l’investissement.

Avec les bonnes pratiques en place, SSE apporte des gains de consolidation mesurables. Associez-le à une couche XDR qui améliore la qualité des alertes sur l’ensemble de l’environnement, et ces gains se multiplient.

Démonstration de la sécurité de l'informatique en nuage

Découvrez comment la sécurité du cloud alimentée par l'IA peut protéger votre organisation lors d'une démonstration individuelle avec un expert produit de SentinelOne.

Obtenir une démonstration

Conclusion

SSE consolide SWG, CASB et ZTNA dans une plateforme de sécurité unifiée, fournie depuis le cloud, conçue pour les main-d’œuvre distribuées. Il remplace l’inspection centralisée basée sur des appliances par une application continue des politiques, sensible à l’identité, au niveau de PoP cloud distribués. 

SSE couvre la sécurité de l’accès réseau et cloud, et l’associer à XDR étend la protection aux endpoints, aux workloads et à l’identité. Commencez par ZTNA, effectuez votre migration par phases et mettez en place la gouvernance tôt. Faites cela, et chaque utilisateur accède exactement à ce dont il a besoin, depuis n’importe où, et à rien de plus.