Cisco Umbrella a bien servi les équipes informatiques du marché intermédiaire en tant que produit de sécurité de la couche DNS. Les UGS d’Umbrella arrivant en fin de vente en septembre 2025 et la maintenance logicielle se terminant en septembre 2026, le temps de la migration est compté. La question n’est plus de savoir s’il faut migrer, mais comment le faire sans rompre la résolution DNS, perdre la visibilité SIEM ou créer une faille de protection pendant la transition.
Ce billet est un guide de 60 jours. Quatre phases : 14 jours de découverte, 21 jours de déploiement parallèle, 14 jours de basculement DNS et 11 jours de mise hors service. Le moment le plus risqué est le changement de DNS dans la phase 3. Le reste est une gestion de projet méthodique.
Si vous souhaitez savoir pourquoi l’architecture d’Umbrella crée des limites pour les équipes du marché intermédiaire, la comparaison Cisco Umbrella vs Jimber couvre l’analyse au niveau des fonctionnalités. Cet article suppose que vous avez décidé de migrer et que vous avez besoin d’une certitude d’exécution.
Le calendrier de migration de 60 jours en un coup d’œil
Le remplacement de Cisco Umbrella par une plateforme SASE d’un seul fournisseur prend 60 jours répartis en quatre phases : découverte et planification (14 jours), déploiement parallèle (21 jours), basculement et validation DNS (14 jours) et déclassement (11 jours). Le chemin critique passe par le basculement DNS dans la phase 3, où les changements de résolveur se propagent à travers votre réseau et où toute mauvaise configuration entraîne une perte de connectivité immédiate.
| Phase | Jours | Principales activités | Résultats | Niveau de risque |
|---|---|---|---|---|
| 1. Découvrir | 1-14 | Exportation des politiques, cartographie de l’intégration, sélection des fournisseurs | Plan de projet et appel d’offres | Faible |
| 2. Déployer | 15-35 | Déploiement parallèle, déploiement d’agents, élaboration de politiques | Fonctionnement d’une nouvelle pile parallèlement à Umbrella | Moyen |
| 3. Découpage | 36-49 | Changement de DNS, validation, surveillance | Migration de la production terminée | Haut |
| 4. Déclassement | 50-60 | Annulation du contrat, retrait de l’agent, audit | Fermé Locataire parapluie | Faible |
Phase 1 (jours 1 à 14) : découverte et planification
Chaque migration SASE ratée est due à une phase de découverte incomplète. Ces 14 jours permettent d’éviter les surprises qui transforment une migration contrôlée en exercice d’incendie.
Audit de votre mise en œuvre actuelle de l’Umbrella
Commencez par exporter tout ce que contrôle Umbrella.
Politique d’exportation. Utilisez l’API de gestion Umbrella v2 pour obtenir des listes de destination, des stratégies DNS, des stratégies Web et des règles de pare-feu. Le point de terminaison /policies/v2/destinationlists exporte les listes de domaines personnalisées sous forme de JSON. La console d’administration permet l’exportation CSV des listes de destination manuellement. Exportez les deux.
Documentation sur le résolveur DNS. Identifiez chaque périphérique, portée DHCP et objet de stratégie de groupe qui fait référence aux résolveurs d’Umbrella : 208.67.222.222 et 208.67.220.220 pour IPv4, 2620:119:35::35 et 2620:119:53::53 pour IPv6. Vérifiez les routeurs, les pare-feu, les serveurs DNS Windows avec les redirections conditionnelles et les entrées de résolveur codées en dur sur les serveurs. L’échec le plus courant de la migration est une entrée DNS oubliée sur un routeur de branche unique qui continue d’envoyer des requêtes à Umbrella après le basculement.
Étudiez les intégrations API. Documentez chaque script, playbook et flux de travail SOAR qui fait appel à l’API Investigate. Ces intégrations nécessitent une reconstruction par rapport à l’API de renseignement sur les menaces du nouveau fournisseur.
Connecteurs SIEM. Umbrella exporte généralement les journaux vers un bac Amazon S3 crypté avec AES-256. Splunk utilise le module complémentaire Cisco Umbrella. Microsoft Sentinel utilise une fonction Azure ou un connecteur API REST. Documentez le format des journaux, la période de rétention et les tableaux de bord personnalisés élaborés à partir des données d’Umbrella. Les reconstructions de connecteurs SIEM représentent 15 à 20 % de l’effort total de migration dans les transitions de plateformes de sécurité (Gartner, 2025).
Pages de bloc personnalisées et SAML SSO. Exportez toute page HTML personnalisée et documentez l’intégration de votre fournisseur d’identité, qu’il s’agisse de Microsoft Entra ID, d’Okta ou d’AD Connector sur site.
Cartographier les caractéristiques de votre nouvelle plateforme
| Caractéristiques du parapluie | Équivalent SASE | Effort de migration |
|---|---|---|
| Filtrage de la couche DNS (phishing, logiciels malveillants, C2) | Module de sécurité DNS | Importation de listes de destinations basses |
| Proxy intelligent (inspection du domaine gris) | Proxy en ligne SWG complet | Moyenne, couverture plus large |
| Recherche de renseignements sur les menaces API | Flux de menaces spécifiques aux fournisseurs | Élevé, modification du schéma de l’API |
| Filtrage des catégories de contenu | Catégories d’URL du GTS | Faible, révision de la cartographie des catégories |
| CASB / Découverte de l’informatique fantôme | Module CASB | Faible à moyen |
| Pare-feu en nuage (CDFW) | FWaaS | Moyen, traduction des règles |
| Exportation de journaux S3 | Journalisation native de la plateforme | Haut, reconstruction du connecteur SIEM |
| Connecteur AD / SAML | Intégration des fournisseurs d’identité | Faible |
| Pages de bloc personnalisées | Éditeur de pages de bloc | Faible, syntaxe différente |
Le changement conceptuel le plus important est le passage du « proxy intelligent » d’Umbrella à une passerelle Web sécurisée à part entière. Umbrella ne proxie que le trafic vers des domaines risqués ou inconnus. Une SWG inspecte 100 % du trafic Web en ligne, ce qui nécessite le déploiement d’un certificat racine sur chaque point d’extrémité géré pour l’inspection TLS.
Constituer l’équipe de projet et sélectionner un fournisseur
Une migration de 200 utilisateurs nécessite cinq rôles (chef de projet, ingénieur réseau, administrateur d’identité, analyste de sécurité, responsable du service d’assistance). Dans les équipes informatiques légères du marché intermédiaire, une personne en couvre souvent deux.
Si vous n’avez pas encore choisi une plateforme de remplacement, concentrez-vous sur : l’architecture cloud-native par rapport à l’héritage des appliances virtualisées, la sécurité DNS et web dans un moteur de politique unique, la prise en charge des appareils sans agent pour l’IoT et l’OT, la documentation du schéma de log SIEM, et le délai de mise en œuvre de la première politique. Le cadre d’évaluation des fournisseurs SASE, qui repose sur sept critères, couvre ces aspects en profondeur. Pour une analyse détaillée du fonctionnement de l’architecture SASE, le guide d’architecture explique l’inspection à passage unique, la distribution PoP et les modèles d’application des politiques.
Phase 2 (jours 15 à 35) : déploiement parallèle
En faisant fonctionner votre nouvelle plateforme SASE avec Umbrella pendant trois semaines, vous pouvez valider les politiques et détecter les problèmes d’intégration avant qu’ils n’affectent le trafic de production.
Déploiement en parallèle et migration des politiques DNS
Commencez par 10 à 20 % de vos utilisateurs : le personnel de bureau, les travailleurs à distance et au moins une succursale. Évitez l’équipe de direction en tant que pilote. Choisissez des utilisateurs qui signalent les problèmes avec précision et qui tolèrent des inconvénients mineurs pendant la période de validation.
La phase parallèle signifie que les deux plateformes fonctionnent simultanément. Umbrella gère la majorité des utilisateurs. Le groupe pilote passe par la nouvelle plateforme. Cette approche à double pile nécessite un cadrage DNS minutieux afin d’éviter les fuites de trafic entre les plates-formes. Configurez l’étendue DHCP ou le profil MDM du groupe pilote pour utiliser les nouveaux résolveurs SASE, tandis que le reste du réseau continue d’utiliser Umbrella.
Exportez les listes de destination d’Umbrella au format CSV et importez-les dans la nouvelle plateforme. Avant d’importer, passez chaque liste en revue manuellement. Les déploiements en cours depuis des années accumulent des entrées périmées : des domaines qui n’existent plus, des blocages temporaires provenant d’incidents passés et des règles de caractères génériques trop larges. Effectuez une comparaison sur deux semaines : appliquez la même politique sur les deux plateformes et comparez ce que chacune bloque. Le delta révèle les lacunes en matière de traduction.
La taxonomie des catégories de contenu d’Umbrella ne correspond pas parfaitement à celle d’autres fournisseurs. Le blocage de la catégorie « Sécurité » dans Umbrella peut couvrir des types de menaces différents de la catégorie équivalente sur votre nouvelle plateforme. Documentez chaque divergence et ajustez les politiques avant la phase 3.
Mise en place d’intégrations d’identité et de reconstruction
Connectez votre fournisseur d’identité. Vérifiez que le format UPN correspond à celui utilisé par Umbrella. Un décalage entre user@company.com et DOMAIN\user interrompt silencieusement l’application de la politique.
Pour les reconstructions SIEM, remplacez entièrement la source de données Umbrella. Splunk a besoin d’un nouveau module complémentaire ou d’une entrée HEC. Sentinel a besoin d’un nouveau connecteur de données et de règles d’analyse reconstruites. Prévoyez 3 à 5 jours pour Sentinel, 2 à 4 jours pour Elastic ou QRadar. Les playbooks SOAR faisant appel à l’API d’application d’Umbrella nécessitent une réécriture complète par rapport à l’API de la nouvelle plateforme.
Déployez le certificat racine du nouveau fournisseur via GPO, Intune ou Jamf. Prévoyez une fenêtre complète de sept jours. N’activez pas l’inspection TLS tant que le déploiement du certificat n’a pas atteint une couverture de plus de 95 %, sinon les utilisateurs seront confrontés à des avertissements du navigateur sur chaque site HTTPS.
Les plateformes SASE à fournisseur unique avec architecture multi-tenant, y compris Jimber, gèrent l’accès des partenaires de service de manière native. Vérifiez que l’accès administrateur de votre partenaire correspond bien à la nouvelle console.
Phase 3 (jours 36 à 49) : Passage au DNS et validation
C’est la phase la plus risquée. Le DNS est à la base de toute connexion internet. Un transfert mal configuré signifie que les utilisateurs ne peuvent rien atteindre.
Stratégies de passage au DNS
| Stratégie | Meilleur pour | Temps de recul | Risque |
|---|---|---|---|
| Rotation progressive | Plus de 200 utilisateurs | Minutes par sous-réseau | Faible |
| Coupure brutale | Moins de 50 utilisateurs | 15 à 30 minutes | Moyenne |
| Transition à double résolveur | Non recommandé | Imprévisible | Haute |
Une rotation progressive est recommandée. Modifiez les champs d’application DHCP un sous-réseau à la fois, en commençant par le sous-réseau qui s’est le mieux comporté pendant le projet pilote. Attendez 24 heures entre chaque sous-réseau. Les configurations à double résolveur semblent sûres mais ont un comportement imprévisible : la plupart des systèmes d’exploitation préfèrent le résolveur qui répond le plus rapidement, et non celui qui est listé en premier.
Le manuel de transition
- Abaissez le TTL DNS à 300 secondes une semaine avant le basculement.
- Validation avant le passage à l’euro. À partir d’une machine de test sur les nouveaux résolveurs, résolvez 50 domaines représentatifs. Confirmez que la résolution est inférieure à 50 ms et que les domaines bloqués renvoient des pages de blocage personnalisées.
- Mettez à jour les champs d’application DHCP avec les nouveaux résolveurs SASE. Poussez via la stratégie de groupe ou le MDM pour les points d’extrémité.
- Attendez la propagation des baux DHCP (8-24 heures). Ne forcez pas le renouvellement de tous les baux simultanément.
- Surveillez pendant 48 heures. Suivez le taux de réussite de la résolution (objectif 99,9 %+), la latence (moins de 50 ms) et les réponses NXDOMAIN pour les domaines qui devraient être résolus.
- Validez l’application de la politique sur trois segments du réseau.
- Point de décision. Si les données métriques restent stables pendant 48 heures, cela signifie que le basculement est terminé. Une dégradation déclenche un retour en arrière.
Pièges courants
Résolution « cerveau divisé ». Tout appareil pointant encore vers les résolveurs d’Umbrella fonctionne selon les anciennes politiques, tandis que le reste du réseau utilise la nouvelle plateforme. Cela crée une faille de protection invisible. Procédez à une analyse du réseau après le basculement, en vérifiant notamment les paramètres DNS sur les routeurs, les serveurs et les appareils réseau.
Rupture de la chaîne DNSSEC. Si la nouvelle plateforme SASE gère la validation DNSSEC différemment d’Umbrella, certains domaines sécurisés peuvent devenir inaccessibles. Testez les domaines signés DNSSEC pendant la phase pilote, et non pendant le passage à la production.
Les cas limites de l’IPv6. Les résolveurs IPv6 d’Umbrella (2620:119:35::35) peuvent exister sur des dispositifs que votre audit axé sur IPv4 a manqués. Les serveurs à double pile et les équipements de réseau sont les coupables habituels.
Conflits d’agents. Le Cisco Secure Client et le nouvel agent SASE ne doivent jamais être actifs simultanément sur le même terminal. Ils sont en concurrence pour le contrôle de la table de routage et des paramètres DNS, ce qui entraîne un comportement de résolution imprévisible. La phase parallèle devrait avoir validé ce point, mais vérifiez à nouveau à l’échelle.
Entrées mises en cache. Même après les changements DHCP, les terminaux mettent en cache les réponses DNS jusqu’à l’expiration du TTL. L’abaissement du TTL à 300 secondes à l’avance (étape 1) limite cette fenêtre à cinq minutes au lieu de plusieurs heures.
Stratégie de retour en arrière
Réinitialiser les champs d’application DHCP aux résolveurs Umbrella (208.67.222.222, 208.67.220.220). Forcez le renouvellement du DHCP sur les serveurs critiques. Vérifiez la résolution par Umbrella. Ne supprimez pas les identités réseau d’Umbrella et n’annulez pas l’abonnement tant que la phase 4 n’est pas terminée.
Phase 4 (jours 50-60) : démantèlement
Valider, supprimer les agents, clôturer le contrat
Confirmez qu’aucun trafic DNS n’atteint Umbrella en vérifiant la recherche d’activité du tableau de bord pour les 72 dernières heures. Toute requête apparaissant signifie qu’un périphérique ou un segment de réseau a été omis lors de la conversion. Lancez un scan du réseau pour identifier les terminaux ou les appareils dont les entrées DNS codées en dur pointent encore vers 208.67.222.222.
Comparez les statistiques de blocage des menaces de la nouvelle plateforme aux données de référence antérieures à la migration. Les chiffres ne correspondront pas exactement car la logique de la politique diffère, mais l’ordre de grandeur devrait être cohérent. Une organisation de 200 utilisateurs bloquant 500 menaces par jour sur Umbrella devrait voir des chiffres comparables ou supérieurs sur la nouvelle plateforme. Une baisse significative suggère un écart de traduction de la politique qui doit être examiné.
Supprimez le client itinérant Umbrella de chaque point d’extrémité. Il se lie au port 53 sur l’adresse loopback et intercepte les requêtes même après l’arrêt du service. Déployez un script MDM qui arrête le service Umbrella_RC, exécute le programme de désinstallation, efface les clés de registre sous HKLM\SOFTWARE\OpenDNS et réinitialise les paramètres DNS de l’adaptateur. Supprimez le certificat racine d’Umbrella des magasins de confiance.
Notifiez par écrit à Cisco le non-renouvellement de votre contrat. La plupart des contrats se renouvellent automatiquement avec des périodes de préavis de 30 à 60 jours. Exportez les rapports de conformité finaux et les journaux d’activité avant la désactivation du locataire. Pour les organisations réglementées par la NIS2 qui ont besoin de 12 à 24 mois de journaux consultables, transférez les données historiques vers votre SIEM avant de fermer le locataire.
Planifiez un examen 30 jours après la migration pour comparer les menaces bloquées, la latence de résolution, les taux de faux positifs et la couverture des alertes SIEM par rapport aux lignes de base avant la migration. Documenter l’ensemble de la migration pour assurer la conformité à l’article 21 de la NIS2 et servir de modèle pour les futures transitions de plate-forme.
Ce qui prend la plupart des équipes au dépourvu
Des politiques personnalisées dont personne ne se souvient. Les déploiements qui durent depuis plus de trois ans accumulent des listes de destination créées par le personnel qui a quitté l’entreprise. Examinez chaque liste en fonction des besoins actuels.
Intégrations API cachées. Les analystes de sécurité écrivent des scripts rapides appelant l’API Investigate qui se trouvent dans des dossiers personnels ou des playbooks SOAR. Envoyez un courriel ciblé demandant des informations sur l’utilisation de l’API Umbrella.
Les lacunes en matière d’enregistrement pendant la période de transition. Lors d’un fonctionnement en parallèle, les événements de sécurité se répartissent entre les plates-formes. Aucune des deux n’a une visibilité complète. Communiquez la réduction de la couverture SIEM à votre équipe de sécurité et aux parties prenantes chargées de la conformité.
Sous-estimation de la reconstruction du SIEM. La reconstruction des tableaux de bord, des alertes et des flux de travail automatisés pour un nouveau schéma de journalisation prend de 30 à 40 heures pour un déploiement moyen typique. Prévoyez un budget explicite à cet effet.
Retard dans le déploiement des certificats. Les appareils qui sont éteints ou déconnectés peuvent mettre des jours à recevoir le nouveau certificat racine via MDM. N’activez l’inspection TLS qu’à partir d’une couverture de 95 %. Les appareils utilisant des connexions VPN lentes ou ceux qui sont rarement redémarrés sont les derniers à recevoir les certificats poussés par les GPO. Suivez l’évolution du déploiement grâce à vos rapports MDM avant d’activer l’inspection TLS.
Questions fréquemment posées
Puis-je faire fonctionner Cisco Umbrella et une nouvelle plateforme SASE en parallèle pendant la migration ?
Oui. La phase parallèle fait fonctionner les deux plates-formes simultanément. Umbrella gère la majorité des utilisateurs tandis que le groupe pilote passe par la nouvelle plateforme. Les deux plateformes resteront actives jusqu’au démantèlement de la phase 4.
Qu’advient-il de mes intégrations API d’Investigate ?
L’enquête sur l’accès s’arrête à la fin de votre abonnement à Umbrella. Il n’y a pas d’équivalent entre les fournisseurs. Reconstruisez les flux de travail de chasse aux menaces à l’aide de l’API de renseignements sur les menaces de votre nouvelle plateforme au cours de la phase 2.
Mon contrat Umbrella sera-t-il automatiquement renouvelé si je ne respecte pas la date limite de résiliation ?
La plupart des contrats prévoient un renouvellement automatique avec une période de préavis de 30 à 60 jours. Soumettez la notification de non-renouvellement par écrit au cours de la phase 4 et conservez la confirmation. Si vous ne respectez pas ce délai, vous risquez d’être engagé pour une nouvelle période de 12 à 36 mois.
Quel est le temps d’arrêt habituel lors d’un basculement DNS ?
Zéro, s’il est exécuté correctement. La rotation progressive modifie les champs d’application DHCP un sous-réseau à la fois. Les utilisateurs ressentent le changement de manière transparente lors du prochain renouvellement de leur bail DHCP.
Dois-je supprimer le client itinérant Umbrella de chaque point d’extrémité ?
Oui, le client itinérant se lie au port 53 sur l’adresse de bouclage et intercepte les requêtes DNS même après l’arrêt du service. Une suppression incomplète entraîne des échecs de résolution intermittents.
Puis-je migrer vers une plateforme SASE autre que celle de Cisco sans avoir à reformer mon équipe ?
Les concepts sont directement transférables. Le filtrage DNS, les politiques web, l’accès basé sur l’identité et l’intégration SIEM fonctionnent selon les mêmes principes. Prévoyez 2 à 3 jours pour la formation des administrateurs. Certaines plateformes SASE à fournisseur unique, dont Jimber, réduisent la courbe d’apprentissage en consolidant toute la gestion des politiques dans une console unique plutôt que dans des tableaux de bord distincts pour les politiques DNS, web et de pare-feu.
Comment la capacité CASB se compare-t-elle entre Umbrella et une plateforme SASE ?
Les niveaux supérieurs d’Umbrella comprennent un CASB de base pour la découverte de l’informatique fantôme. La plupart des plates-formes SASE unifiées offrent un CASB plus complet dans SASE, y compris une DLP en ligne, des contrôles de politiques au niveau des applications et une intégration avec la même source d’identité qui régit tous les autres accès.
Dans soixante jours, votre locataire Umbrella peut être fermé, votre trafic DNS circuler à travers une plateforme SASE unifiée, et votre SIEM reconstruit avec une visibilité complète. Le calendrier de mise en œuvre de SASE couvre la façon dont cette migration s’inscrit dans le cadre d’un déploiement plus large de la plateforme. Si votre équipe prévoit une migration au troisième ou quatrième trimestre, Jimber propose une configuration de déploiement parallèle où vous utilisez la plateforme en même temps qu’Umbrella dès le premier jour, sans engagement jusqu’à ce que vous soyez prêt à passer à autre chose. Réservez une démonstration pour évaluer votre migration.
