Comment mettre en œuvre le SASE : Architecture, plan de migration et liste de contrôle pour l’évaluation des fournisseurs
Que trouverez-vous ici ?
- 1. Définir les objectifs commerciaux et de sécurité
- 2. Réaliser un inventaire du réseau et des applications
- 3. Choisir le bon modèle d'architecture SASE
- 4. Contrôle de la conception et plan de données pour l'application des politiques
- 5. Planifier et exécuter une migration SASE par étapes
- 6. Optimisez et mesurez les performances en continu
- 7. Considérations clés sur l'architecture et l'exploitation
- 8. Liste de contrôle d'évaluation des fournisseurs pour la sélection SASE
- 9. Foire aux questions
Le SASE, abréviation de Secure Access Service Edge, combine le SD-WAN, le Zero Trust Network Access (ZTNA), la passerelle Web sécurisée (SWG), le courtier de sécurité d’accès au cloud (CASB) et le pare-feu en tant que service (FWaaS) au sein d’une architecture fournie par le cloud. L’objectif est simple : offrir aux utilisateurs un accès sécurisé et fiable aux applications sans forcer le trafic à passer par un assemblage hétéroclite d’outils réseau et de sécurité hérités.
De nombreux projets SASE échouent pour des raisons qui n’ont que peu à voir avec des lacunes fonctionnelles. Les problèmes habituels sont une mauvaise cartographie des identités, une conception de politique faible, un inventaire incomplet, un mauvais séquençage et une visibilité limitée une fois que le trafic commence à circuler. Il ne s’agit pas d’un simple remplacement de produit. Cela modifie la manière dont le trafic est acheminé, dont l’accès est appliqué et dont les équipes réseau et sécurité travaillent. Ce guide couvre les aspects pratiques : comment définir des objectifs, choisir une architecture, planifier la migration et évaluer les fournisseurs.
Définir les objectifs commerciaux et de sécurité
Commencez par les problèmes que vous essayez réellement de résoudre. Si l’objectif est vague, le déploiement le devient généralement aussi.
La plupart des équipes cherchent à améliorer trois aspects : la posture de sécurité, la simplicité opérationnelle et l’expérience utilisateur. La posture de sécurité signifie réduire les chemins d’accès exposés, renforcer l’application des politiques et améliorer le contrôle de l’accès des utilisateurs aux applications. La simplicité opérationnelle signifie remplacer les outils redondants, réduire la prolifération des consoles et faciliter la gestion des modifications de politiques. L’expérience utilisateur signifie améliorer les performances des applications, supprimer les goulots d’étranglement des VPN et offrir aux utilisateurs distants et hybrides un accès plus cohérent.
Les objectifs courants incluent :
- Consolider des outils de sécurité distincts en une seule plateforme
- Remplacer l’accès VPN traditionnel par ZTNA
- Réduire les coûts WAN grâce au SD-WAN et à l’accès direct à Internet
- Répondre aux exigences de résidence des données ou de conformité sectorielle
- Améliorer la visibilité pour les utilisateurs, les sites et les applications distribués
Transformez ces objectifs en cibles mesurables dès le début. Les indicateurs clés de performance utiles incluent la latence, le temps moyen de résolution (MTTR), la conformité aux politiques et les économies réalisées grâce au retrait d’appliances ou à la réduction de l’utilisation de MPLS. Faites correspondre chaque objectif à une capacité SASE. ZTNA aide à remplacer l’accès basé sur VPN. CASB aide à régir l’utilisation des SaaS. SD-WAN améliore le routage et réduit la dépendance vis-à-vis de circuits privés coûteux. Les cas d’utilisation doivent définir le plan, et non l’inverse. Pour un examen plus approfondi de la planification de projet, consultez le guide Path to SASE de Cato.
Réaliser un inventaire du réseau et des applications
Avant de prendre des décisions architecturales, obtenez une image exploitable de l’environnement dont vous disposez déjà. L’inventaire n’est pas une tâche inutile. Il détermine si votre plan de migration est ancré dans la réalité.
Extrayez les données de votre fournisseur d’identité, de vos outils VPN, de vos proxys, de la télémétrie WAN, de NetFlow et des analyses SD-WAN. Observez quels utilisateurs accèdent à quelles applications, où la latence apparaît, comment le trafic circule aujourd’hui et quels sites ou groupes dépendent encore de chemins hérités.
Documentez également ce que vous ne pouvez pas voir clairement. Cela inclut l’informatique fantôme, les appareils non gérés, l’utilisation non autorisée de SaaS et le trafic qui contourne vos contrôles actuels. Incluez également les outils et systèmes hérités dans l’inventaire. S’ils restent en place pendant la migration, ils affectent toujours les choix de conception.
Un inventaire faible conduit généralement à de mauvaises hypothèses sur les modèles de trafic, à une mauvaise définition de la portée des politiques et à des attentes erronées concernant l’emplacement des PoP des fournisseurs. Ces dommages apparaissent plus tard, pas immédiatement, c’est pourquoi les équipes les sous-estiment souvent.
Choisir le bon modèle d’architecture SASE
Le modèle d’architecture est important car il façonne les opérations quotidiennes après le déploiement. Il affecte le dépannage, la cohérence des politiques, la visibilité et la quantité de travail d’intégration que votre équipe doit absorber.
De manière générale, les organisations ont tendance à choisir parmi quatre approches : une plateforme intégrée unique, une conception multi-fournisseurs construite à partir d’outils de réseau et de sécurité distincts, un service SASE géré, ou une approche modulaire qui commence par un composant et s’étend au fil du temps. Le bon choix dépend des compétences internes, de la tolérance à la complexité opérationnelle et de l’importance accordée à la flexibilité par rapport à la simplicité.
Approches fournisseur unique vs multi-fournisseurs
Le SASE à fournisseur unique est généralement plus facile à gérer. La politique réside en un seul endroit, le dépannage est plus direct et il y a moins de place pour des lacunes entre les contrôles réseau et de sécurité.
Un modèle multi-fournisseurs peut préserver les investissements existants et vous permettre de conserver vos outils préférés, mais il transfère la charge de l’intégration à votre équipe. Cette charge n’est pas seulement technique. Elle se manifeste dans le contrôle des changements, la visibilité, la responsabilité du support et la dérive des politiques au fil du temps.
Pour les organisations qui se soucient avant tout de la simplicité opérationnelle et de l’application unifiée des politiques, un seul fournisseur est souvent la voie la plus claire. Cato soutient cela directement dans sa position « Le SASE n’est pas SD-WAN + SSE » : combiner des produits distincts n’est pas la même chose que d’exploiter une architecture convergée. La plateforme de Cato est conçue autour du modèle à fournisseur unique, mais elle prend également en charge une adoption progressive.
SASE géré et options de déploiement modulaire
Le SASE géré est une option pratique pour les équipes qui n’ont pas la capacité interne de gérer la plateforme elles-mêmes. Il réduit la charge opérationnelle et est judicieux pour les organisations qui souhaitent un contrôle des politiques sans assumer l’administration complète de la plateforme.
Un déploiement modulaire offre plus de contrôle, mais suppose des capacités réseau et de sécurité internes plus solides. Certaines entreprises le souhaiteront. De nombreuses équipes du marché intermédiaire ne le souhaiteront pas.
Le modèle d’adoption modulaire de Cato est construit autour de cette idée. Les organisations peuvent commencer par la modernisation de la connectivité ou la consolidation de la sécurité, puis étendre vers un déploiement plus large au sein de la même plateforme et du même modèle de tarification. Pour en savoir plus sur l’adoption progressive, consultez le guide de Cato sur le déploiement graduel du SASE.
Contrôle de la conception et plan de données pour l’application des politiques
La conception SASE ne concerne pas seulement les fonctionnalités incluses dans une plateforme. Il s’agit également de la manière dont la politique est créée, distribuée et appliquée.
Le plan de contrôle gère la création et la mise à jour des politiques. Le plan de données gère l’inspection, le chiffrement et le transfert du trafic. La conception entre les deux affecte la rapidité avec laquelle les changements de politique prennent effet et la cohérence avec laquelle ces changements sont appliqués. Un plan de contrôle centralisé facilite la cohérence, mais les équipes doivent tout de même se demander à quelle vitesse les mises à jour atteignent les points d’application. Une approche distribuée peut améliorer la réactivité locale, mais elle place la barre plus haut en matière de synchronisation et de dépannage.
Lors de la comparaison des plateformes, concentrez-vous sur quelques questions pratiques :
- Combien de temps faut-il pour qu’un changement de politique prenne effet à l’échelle mondiale ?
- Le trafic est-il inspecté une seule fois ou passe-t-il par plusieurs moteurs séquentiels ?
- Un administrateur peut-il retracer une décision de politique, de sa création à son application, dans une seule interface ?
Les conseils de conception SASE de Cisco couvrent les questions de sécurité, de résilience et d’évolutivité liées à ces choix. Cato met l’accent sur son moteur d’inspection à passage unique et son modèle d’application distribué comme moyen de réduire la latence et de simplifier les opérations.
Planifier et exécuter une migration SASE par étapes
Un basculement complet est généralement une mauvaise décision. Le SASE change trop de choses à la fois : routage, politique d’accès, chemins d’inspection, expérience utilisateur et responsabilité opérationnelle. Une migration par étapes réduit le rayon d’impact.
Un déploiement pratique suit généralement quatre phases :
- Découverte – Terminer l’inventaire, l’analyse des écarts et la sélection de l’architecture
- Pilote – Tester un ensemble limité de cas d’utilisation avec des utilisateurs et un trafic réels
- Déploiement – Étendre par site, groupe d’utilisateurs et type d’application
- Optimisation – Ajuster le routage, la politique et les performances après le déploiement
Piloter des cas d’usage à fort impact
Commencez par des cas d’usage qui résolvent des problèmes visibles sans créer de retour arrière ingérable. Les bons candidats pour un projet pilote incluent :
- Remplacer l’accès VPN existant par le ZTNA pour les travailleurs distants
- Activer l’accès direct à Internet pour les succursales qui utilisent encore le backhauling via MPLS
- Sécuriser l’accès distant aux applications privées
- Appliquer les contrôles SWG et CASB au trafic SaaS pour une unité commerciale
Le projet pilote doit tester les conditions réelles d’exploitation, et pas seulement vérifier si une fonctionnalité existe. Cela signifie vérifier l’intégration de l’identité, l’expérience utilisateur, le comportement des politiques, la visibilité administrative et la cohérence entre les sites. Un projet pilote de 30 à 60 jours est généralement suffisant pour faire apparaître des problèmes significatifs si les critères de réussite sont clairs et les procédures de retour arrière documentées.
Déploiement par site et par segment d’utilisateurs
Une fois le projet pilote stable, procédez par étapes. L’objectif n’est pas d’avancer lentement pour le plaisir. L’objectif est d’isoler les variables.
Une séquence de déploiement courante ressemble à ceci :
- Géographie – Commencez dans les régions déjà bien desservies par les points de présence (PoP) du fournisseur
- Type d’utilisateur – Les travailleurs distants d’abord, suivis des succursales, puis du siège social
- Niveau d’application – Commencez par le trafic SaaS et le trafic vers Internet, puis étendez aux applications privées et aux charges de travail des centres de données
Il est également utile d’aligner le déploiement sur les dates de renouvellement des contrats MPLS, VPN et pare-feu. Cela réduit les chevauchements et rend les économies plus visibles. Tenez les parties prenantes informées tout au long du processus, surtout lorsque les flux de travail des utilisateurs changent.
Optimisez le routage pour éviter la latence et le backhaul
L’une des erreurs les plus courantes dans les déploiements SASE est de conserver les mêmes anciens modèles de trafic sous une nouvelle étiquette. Les équipes passent au SASE, puis continuent de faire transiter le trafic cloud via des points d’inspection centralisés. Cela annule une grande partie des avantages en termes de performances.
Le SD-WAN devrait vous permettre de séparer directement le trafic Internet et SaaS lorsque la politique le permet. Le routage basé sur l’intention commerciale doit refléter les exigences des applications, et non les habitudes réseau héritées. À chaque phase, vérifiez le chemin réel du trafic. Recherchez le backhaul inutile, évitez les chaînes d’inspection qui ajoutent de la latence et confirmez que le comportement de routage correspond à la conception de la politique.
L’épine dorsale privée et la conception des PoP de Cato sont positionnées autour de ce problème : réduire le backhaul et maintenir des performances constantes sur les sites des utilisateurs et des applications.
Optimisez et mesurez les performances en continu
La mise en service n’est pas la ligne d’arrivée. C’est le moment où la plateforme commence à produire les données dont vous avez besoin pour l’améliorer.
Établissez une cadence d’examen régulière, mensuelle ou trimestrielle, et examinez la télémétrie de routage, l’efficacité des politiques, les mesures de l’expérience utilisateur et les indicateurs de performance clés de l’entreprise que vous avez définis au départ. Si la migration était censée réduire la latence, diminuer la complexité opérationnelle ou supprimer des appliances, mesurez cela directement. Certaines charges de travail peuvent encore nécessiter des contrôles locaux, en particulier dans les environnements sur site ou lorsque les exigences de conformité sont strictes.
L’optimisation continue doit inclure :
- L’affinement des politiques Zero Trust à mesure que les modèles d’accès changent
- L’ajustement du routage à mesure que les sites, les utilisateurs et les régions cloud se développent
- La surveillance des performances SaaS et du routage du trafic
- Examen des nouvelles fonctionnalités de la plateforme à mesure qu’elles deviennent disponibles
- Suivi du retrait des appliances et des économies qui y sont liées
La console de gestion et les analyses de Cato sont conçues pour offrir aux équipes un lieu unique pour examiner la télémétrie réseau et de sécurité, ce qui est utile si la simplification est l’un des objectifs du projet.
Considérations clés sur l’architecture et l’exploitation
Empreinte des PoP et SLA de latence
Ne jugez pas un fournisseur uniquement sur le nombre total de PoP. La couverture ne compte que si elle correspond à vos utilisateurs, vos succursales, vos régions cloud et votre empreinte applicative.
Un fournisseur ayant une large présence en Amérique du Nord et en Europe peut tout de même être un choix peu pertinent si vos utilisateurs critiques se trouvent en Asie-Pacifique ou en Amérique latine. Validez la couverture réelle, la latence attendue, la redondance et la connectivité multi-cloud. L’épine dorsale et le modèle de PoP mondial de Cato font partie de ses arguments en faveur d’une performance d’entreprise cohérente.
Intégration de l’identité et application du Zero Trust
L’identité est au cœur du SASE. Si l’intégration de l’identité est superficielle, l’application des politiques le devient généralement aussi.
Vérifiez si la plateforme prend en charge votre pile d’identité existante, y compris le SSO, la MFA, les API et les connecteurs pour des fournisseurs tels qu’Azure AD, Okta ou Ping Identity. L’application du Zero Trust doit également s’étendre au-delà de la connexion.
Une liste de contrôle pratique comprend :
- Intégration SSO et MFA avec l’IdP actuel
- Vérifications de la posture de l’appareil avant l’octroi de l’accès
- Contrôle d’accès au niveau de l’application plutôt qu’un accès réseau étendu
- Validation continue de la session
- Prise en charge des appareils gérés et non gérés
Précision de l’inventaire et observabilité
L’inventaire n’est pas un exercice ponctuel. Les utilisateurs, les applications et les flux de trafic ne cessent de changer, et la migration devient plus difficile à gérer si l’inventaire reste figé dans le temps.
L’observabilité devrait couvrir plus que le temps de disponibilité ou la bande passante. Les équipes devraient être en mesure de corréler les événements de sécurité, de voir les taux de réussite des politiques, de retracer les problèmes d’expérience utilisateur et de comprendre comment le trafic s’est réellement déplacé à travers la plateforme. Cette visibilité est ce qui rend la simplification possible plutôt que simplement théorique. Cato présente son modèle d’analyse et de télémétrie comme un moyen de maintenir l’inventaire, la politique et la performance alignés au fil du temps.
Liste de contrôle d’évaluation des fournisseurs pour la sélection SASE
Une bonne évaluation des fournisseurs doit tester l’architecture, les opérations, la tarification et l’adéquation à long terme, et pas seulement la couverture des fonctionnalités.
Intégration native et gestion unifiée
La première question est de savoir si la plateforme a été conçue comme un système unique ou assemblée à partir de produits distincts. Cette différence se manifeste généralement dans l’expérience de gestion.
Demandez :
- Existe-t-il une console de gestion unique pour toutes les fonctions SASE ?
- Les politiques de réseau et de sécurité sont-elles traitées dans le même moteur de politique ?
- Les administrateurs peuvent-ils retracer les problèmes de l’utilisateur à l’application en un seul endroit ?
L’argument de Cato est clair : une architecture cloud native conçue comme une plateforme unique plutôt qu’intégrée après acquisition.
Échelle mondiale et garanties de performance
La couverture mondiale et les garanties de performance sont primordiales pour les organisations ayant des utilisateurs et des sites distribués. Demandez ce qui se passe lorsqu’un PoP tombe en panne, comment le trafic est redirigé et si le fournisseur garantit contractuellement ses engagements en matière de latence.
Les critères clés incluent :
- Répartition géographique des PoP
- SLA de latence publiés
- Prise en charge des accès AWS, Azure et GCP
- Conception du réseau fédérateur, qu’il s’agisse de l’internet public ou d’un réseau privé
- Comportement en cas de basculement et haute disponibilité
Profondeur des capacités d’identité et de ZTNA
De nombreux fournisseurs prétendent prendre en charge le Zero Trust, mais les détails pratiques varient. Évaluez :
- La rapidité avec laquelle les terminaux peuvent être intégrés
- Si la politique d’accès est au niveau de l’application ou toujours orientée réseau
- Si les tiers peuvent utiliser un accès sans client
- Si la confiance est évaluée en continu pendant les sessions
Cato positionne son modèle ZTNA universel autour d’une politique cohérente pour les utilisateurs distants, les succursales et le siège social, sans outils distincts.
Modèle de tarification et support à la migration
La tarification et le support à la migration sont les domaines où de nombreuses erreurs d’achat sont commises. Demandez des devis détaillés et exigez que le fournisseur indique ce qui est inclus et ce qui est facturé en supplément.
- Les fonctionnalités principales sont-elles incluses, ou des fonctions majeures telles que DLP, CASB ou la protection avancée contre les menaces sont-elles des modules complémentaires ?
- La tarification est-elle basée sur les utilisateurs, les sites, la bande passante ou une combinaison des trois ?
- Les services de migration sont-ils inclus ?
- Quelles économies sont attendues du retrait des pare-feu, du matériel VPN ou des circuits MPLS ?
Le support à la migration compte presque autant que la tarification. Demandez si le fournisseur fournit des équipes d’intégration, des manuels et une cogestion pendant la transition. La position de Cato est que sa tarification est transparente et que son modèle modulaire réduit le besoin de retravail architectural ultérieur.
Tests de scénarios et alignement de la feuille de route
Ne vous fiez pas uniquement aux démonstrations. Testez la plateforme en utilisant des scénarios qui reflètent votre environnement réel.
- Un utilisateur distant accédant à une application privée via ZTNA pendant une utilisation de pointe
- Une succursale de 200 utilisateurs exécutant du trafic de collaboration tel que Teams ou Zoom
- Une mise à jour de politique qui doit se propager à travers les régions
- Un événement de basculement où un PoP principal devient indisponible
Regardez ensuite au-delà de l’ensemble des fonctionnalités actuelles. Vérifiez si la feuille de route du produit s’aligne sur les besoins futurs probables tels que la sécurité pilotée par l’IA, le support IoT ou OT, et une intégration cloud plus large. Cato souligne la sécurité IA, les contrôles de l’IA fantôme et la gouvernance des agents IA comme exemples de cette orientation.
Pour les équipes qui commencent le processus, la ressource de Cato « comment adopter le SASE en 6 étapes faciles » peut servir de liste de contrôle d’accompagnement.
Foire aux questions
Quelle est la bonne architecture SASE pour notre organisation ?
Cela dépend de la disposition de votre réseau, de votre empreinte cloud, de votre maturité en matière de sécurité et de vos exigences d’accès à distance. En pratique, de nombreuses organisations bénéficient d’une plateforme cloud native convergée avec un contrôle de politique centralisé et une large couverture PoP. Cato est un exemple de ce modèle.
Devrions-nous choisir une plateforme SASE à fournisseur unique ou une approche multi-fournisseurs ?
Si la simplicité, la visibilité unifiée et la cohérence des politiques sont primordiales, le modèle à fournisseur unique est généralement le plus facile à exploiter. Si la préservation des investissements existants est plus importante, une approche multi-fournisseurs peut fonctionner, mais votre équipe devra absorber une charge d’intégration plus importante.
Comment élaborer un plan de migration SASE pratique ?
Commencez par l’inventaire et l’analyse des écarts, testez un petit nombre de cas d’utilisation à fort impact, puis étendez par site et par segment d’utilisateurs. Définissez tôt les critères de réussite et documentez les procédures de retour en arrière.
Que devrait inclure une preuve de concept SASE ?
Testez l’intégration de l’identité, l’expérience utilisateur, l’application des politiques, la visibilité administrative et la cohérence entre les sites. Exécutez la preuve de concept assez longtemps pour exposer les problèmes opérationnels, et pas seulement pour confirmer que la plateforme fonctionne en laboratoire.
Comment mesurer si la mise en œuvre du SASE est réussie ?
Utilisez les KPI définis au départ : latence, effort opérationnel, expérience utilisateur, conformité aux politiques, vitesse d’intégration, temps de réponse aux incidents et économies réalisées grâce au retrait de l’infrastructure existante. Examinez-les régulièrement et ajustez le déploiement en fonction des résultats.
This page was machine-translated. If you notice any inaccuracies or have feedback, please feel free to send it to us here.
