Secure Web Gateway Migration : liste de contrôle pour la mise en production et la restauration en arrière
- Une migration SWG nécessite, comme toute mise en production, un état des lieux, une phase pilote, des tests, un déploiement progressif et une procédure de retour en arrière validée.
- L'authentification, les certificats TLS et les exceptions, l'acheminement du trafic, ainsi que les intégrations ICAP ou DLP présentent les risques les plus importants.
- Faites fonctionner la nouvelle passerelle en parallèle et transférez les utilisateurs par vagues plutôt que de procéder à la migration en une seule fois.
- Définissez les déclencheurs de retour en arrière et les critères d'acceptation avant la première vague de mise en production, et non pas lors d'un incident.
- La migration est l'occasion idéale de supprimer des règles inutilisées depuis des années et des exceptions obsolètes.
Une migration « secure web gateway » consiste à transférer l'inspection du trafic Web et les politiques d'une plateforme proxy vers une autre, qu'il s'agisse d'un passage d'un appareil sur site vers un nouvel appareil, vers un service cloud ou vers un modèle hybride. Cette liste de contrôle couvre l'ensemble du processus : inventaire, conception de la solution cible, conversion des politiques, préparation de la restauration, phase pilote, tests, basculement progressif et réception.
Cet article fait partie du guide consacré à la sécurité du cloud hybride. Pour plus d'informations spécifiques à Blue Coat ProxySG et Symantec Edge SWG, veuillez consulter les pages « Blue Coat » et « Fin de vie de ProxySG : planification de la migration ».
Phase 1 : État des lieux
La phase 1 consiste à recenser l'état actuel du parc de passerelles, la gestion du trafic, l'authentification, l'inspection TLS, les politiques et les intégrations avant toute phase de conception.
Infrastructures
- Chaque passerelle : modèle, version logicielle, emplacement, rôle et dates de fin de vie (pour ProxySG et Edge SWG, veuillez consulter l'article de Broadcom consacré au cycle de vie)
- Volume de trafic et débit maximal par site, avec pourcentage de décryptage TLS
- Nombre d'utilisateurs par site et pour l'accès à distance
- Enchaînement de proxys en amont et en aval, équilibreurs de charge et conception du basculement
Acheminement du trafic
- Paramètres de proxy explicites, fichiers PAC et WPAD
- Points d'interception transparents (WCCP, routage basé sur des règles)
- Tunnels provenant des succursales (IPsec, GRE)
- Agents sur les terminaux
- Exceptions relatives à la vente directe sur Internet
Identité
- Domaines d'authentification (SAML, Kerberos/IWA, LDAP, certificats clients)
- Correspondances de groupes utilisées dans la politique
- Le trafic non authentifié (serveurs, IoT, OT) et sa gestion
Contrôle TLS
- Certificat d'authentification (CA), emplacement de la clé, date d'expiration et mode de distribution
- Liste des exceptions au déchiffrement, avec justification et noms des responsables
Politique
- Exportation complète de la politique, y compris l'ordre des règles, les catégories, les listes personnalisées et les exceptions
- Règles n'ayant fait l'objet d'aucune consultation au cours des 90 derniers jours (candidates à la suppression)
Intégrations
- Connexions ICAP aux systèmes DLP, antivirus et de sandboxing
- Transmission des journaux vers le SIEM et les outils de reporting
- Surveillance et alertes
Phase 2 : Conception de la cible
La phase 2 permet de déterminer quels sites et groupes d'utilisateurs feront l'objet d'une inspection, ainsi que la manière dont le trafic, les certificats et les journaux seront traités.
- Déterminez où chaque site et chaque groupe d'utilisateurs fera l'objet d'une inspection : sur site, dans le cloud ou en environnement hybride
- Définissez la méthode d'acheminement du trafic pour chaque cas : proxy explicite ou PAC pour les réseaux gérés, agents ou contrôles de navigateur pour les utilisateurs en itinérance, tunnels pour les succursales
- Vérifiez l'emplacement de l'inspection TLS afin que chaque flux ne soit déchiffré qu'une seule fois. Les recommandations de la NSA conseillent de n'effectuer l'inspection qu'une seule fois au sein du réseau d'entreprise et d'éviter toute inspection redondante par des proxys en chaîne (NSA)
- Capacité en termes de débit de pointe après décryptage, en tenant compte de la croissance
- Conception de la haute disponibilité et du comportement en cas de défaillance
- Déterminez où seront stockés les journaux et les éléments de preuve relatifs à la prévention des fuites de données (DLP)
- Planifiez la mise en place d'une nouvelle autorité de certification (CA) ou le transfert de celle existante, et vérifiez la prise en charge du stockage des clés ainsi que toute intégration HSM requise
Phase 3 : Mise en œuvre des politiques
La phase 3 transpose la politique existante dans la nouvelle plateforme au moyen d'une mise en correspondance structurée et validée, plutôt que par une conversion directe des fichiers.
- Mettez en correspondance chaque règle source avec son équivalent cible, ou marquez-la pour suppression
- Mettez en correspondance les catégories d'URL entre les fournisseurs et examinez les différences pour les catégories à fort impact
- Recréer des listes personnalisées, des listes d'autorisation et des listes de blocage
- Traduisez les règles dépendantes de l'authentification et validez les mappages de groupes
- Recréez les méthodes permettant de contourner le déchiffrement et examinez chacune d'entre elles afin de déterminer si elles restent nécessaires
- Remplacer, dans la mesure du possible, les transferts DLP basés sur ICAP par le service de protection des données propre à la plateforme, en vérifiant où l'inspection a lieu, ou rétablir les intégrations
- Consignez chaque modification et chaque règle supprimée en précisant le motif, conformément à votre processus de contrôle des modifications de configuration (la norme NIST SP 800-128 décrit les pratiques de gestion de configuration axées sur la sécurité)
Certaines plateformes proposent une importation assistée des politiques existantes. Considérez toute importation comme un point de départ qui doit encore faire l'objet d'une révision et de tests.
Phase 4 : Préparation de la restauration
La phase 4 définit les déclencheurs et les mécanismes de retour en arrière avant le projet pilote. Testez le retour en arrière pendant le projet pilote et vérifiez que tout est prêt avant chaque vague de mise en production.
Déclencheurs de restauration (exemples)
- Échecs d'authentification dépassant un seuil convenu
- Une application essentielle à l'activité indisponible pendant une durée supérieure à celle convenue
- Tickets du service d'assistance dépassant un multiple défini de la valeur de référence
- Il a été confirmé que les contrôles de sécurité n'étaient pas appliqués
Mécanismes de retour en arrière
- Maintenez les anciennes passerelles en service et assurez-vous qu'elles soient mises à jour jusqu'à la réception définitive
- Veillez à enregistrer les modifications apportées aux fichiers PAC, au DNS et au routage dans un système de gestion de versions afin de pouvoir les annuler
- Tenez compte des durées de mise en cache DNS et PAC dans vos estimations de restauration
- Vérifiez que l'ancienne autorité de certification d'inspection reste considérée comme fiable sur les appareils pendant la transition
- Déterminez qui est habilité à autoriser une restauration en arrière et consignez les étapes à suivre
- Effectuez une restauration de test pendant la phase pilote et vérifiez que tout est prêt avant chaque vague de basculement
Phase 5 : Projet pilote
La phase 5 consiste à faire fonctionner un groupe pilote représentatif sur la nouvelle passerelle, en parallèle de l'ancienne, pendant au moins un cycle d'activité.
- Sélectionnez des utilisateurs pilotes représentant les services clés, les types d'appareils et les sites, notamment le personnel informatique et quelques utilisateurs expérimentés issus des différents services
- Faites fonctionner la nouvelle passerelle en parallèle avec l'ancienne
- Acheminez le trafic des pilotes vers la nouvelle passerelle via le PAC, un agent ou des modifications de routage pouvant être annulées rapidement
- Mettez à la disposition des utilisateurs pilotes un moyen simple de signaler les problèmes
- Menez le projet pilote pendant au moins un cycle complet d'activité, y compris la fin du mois le cas échéant
Phase 6 : Tests
La phase 6 teste tous les domaines dans lesquels les utilisateurs remarqueront une différence, de l'authentification aux performances en passant par la bascule.
| Zone de test | Ce qu'il convient de vérifier |
|---|---|
| Authentification | Les utilisateurs et les groupes sont correctement identifiés ; l'authentification unique (SSO) fonctionne ; le trafic système non authentifié se comporte conformément à la conception |
| Politique relative aux catégories et aux URL | Les catégories « autorisées », « bloquées » et « signalées » se comportent comme dans la source |
| Contrôle TLS | Certificats reconnus comme fiables sur tous les appareils gérés ; contournement des restrictions professionnelles ; fonctionnement des applications épinglées |
| Protection contre les menaces | Les échantillons de logiciels malveillants de test et les URL connues pour être malveillantes sont bloqués |
| DLP | Les documents de test associés à chaque classe de données sont détectés lors du téléchargement |
| Applications professionnelles | Les 50 meilleures applications web et solutions SaaS essentielles à l'activité, de bout en bout |
| Performances | Les temps de chargement des pages et le débit aux heures de pointe sont acceptables |
| Exploitation forestière | Les événements parviennent au SIEM avec les champs attendus |
| Basculement | La défaillance d'un nœud passerelle est gérée sans incidence pour l'utilisateur |
Phase 7 : Mise en service progressive
La phase 7 prévoit le transfert progressif des utilisateurs et des sites vers la nouvelle passerelle, en commençant par les sites présentant le moins de risques.
- Regroupez les utilisateurs et les sites en vagues en fonction du risque et de la complexité, en commençant par les sites à faible risque
- Veuillez nous informer à l'avance de chaque vague, en indiquant un interlocuteur de référence
- Planifiez les vagues en dehors des périodes critiques pour l'activité
- Mettez en place une cellule de crise pendant les premières heures de chaque vague
- Suivre les tickets du service d'assistance, les taux de blocage et les taux d'erreur par rapport aux valeurs de référence
- Faites une pause entre chaque vague pour résoudre les problèmes avant de passer à la suivante
Phase 8 : Réception et mise hors service
La phase 8 permet de vérifier que les critères d'acceptation sont respectés, puis de mettre hors service les anciennes passerelles, les anciens certificats et les anciens contrats.
Critères d'acceptation (exemples)
- Tous les utilisateurs et tous les sites ont été migrés
- Le volume d'appels au service d'assistance est revenu à son niveau habituel depuis deux semaines
- Tous les cas de test sont réussis en production
- Journaux et rapports vérifiés par les équipes chargées de la sécurité et de la conformité
- Liste des exceptions examinée et approuvée
Mise hors service
- Supprimez les anciennes passerelles des fichiers PAC, de la configuration du routage et du DNS
- Si l'autorité de certification d'inspection a été remplacée, révoquez-la et supprimez-la des appareils.
- Archiver les anciens journaux conformément à la politique de conservation
- Effacer et mettre au rebut le matériel en toute sécurité
- Clôturer les contrats de licence et d'assistance
Calendrier type
Les délais dépendent de la taille de la succession et de la complexité de la police d'assurance.
Une organisation disposant d'un seul site peut mener à bien une migration en quelques semaines. Les grandes entreprises disposant de plusieurs sites procèdent souvent à un déploiement en parallèle et à une adoption progressive sur une période de six à douze mois, selon Skyhigh Security.
Comment Skyhigh facilite la migration vers SWG
Skyhigh facilite la migration vers SWG grâce à un déploiement parallèle, à l'importation validée des politiques CPL et à des modèles de déploiement flexibles.
Skyhigh Hybrid SSE Mesh est déployé parallèlement aux passerelles existantes afin que les politiques puissent être validées sur le trafic en parallèle avant tout basculement. Skyhigh reformule les politiques CPL existantes d’ Blue Coat s dans sa console de politiques unifiée via un processus d’importation validé, et les politiques sont définies dans la console cloud de Skyhigh. Les politiques relatives aux applications Web et privées peuvent être appliquées sur la passerelle sur site, tandis que le trafic nécessitant une protection des données appliquée dans le cloud est redirigé vers le cloud Skyhigh. Les utilisateurs distants sont desservis via des points de présence dans le cloud. Skyhigh SWG fonctionne sur site, en mode hybride ou dans le cloud ; la migration n’impose donc pas de changement de modèle de déploiement. Le programme de modernisation «Blue Coat » offre une prise en charge des services et une compensation financière pour les clients éligibles.
Sources
- NSA. Gestion des risques liés à l'inspection du protocole SSL (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- NIST. SP 800-128 : Guide pour la gestion de la configuration des systèmes d'information axée sur la sécurité. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
- Broadcom. Fin de vie et cycle de vie des produits Edge SWG (ProxySG) et Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
- Skyhigh Security. « Moderniser votre infrastructure Symantec Edge Secure Web Gateway , grâce à Skyhigh Hybrid SSE Mesh » (15 juillet 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- Skyhigh Security. « L'adoption de l'hybride est désormais plus simple grâce à la plateforme Skyhigh SSE » (3 octobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html