{"id":13265,"date":"2026-05-22T09:00:05","date_gmt":"2026-05-22T07:00:05","guid":{"rendered":"https:\/\/jimber.io\/?p=13265"},"modified":"2026-05-22T09:00:05","modified_gmt":"2026-05-22T07:00:05","slug":"remplacer-cisco-umbrella-par-un-sase-a-fournisseur-unique-un-plan-de-migration-de-60-jours","status":"publish","type":"post","link":"https:\/\/jimber.io\/fr\/blog\/remplacer-cisco-umbrella-par-un-sase-a-fournisseur-unique-un-plan-de-migration-de-60-jours\/","title":{"rendered":"Remplacer Cisco Umbrella par un SASE \u00e0 fournisseur unique : un plan de migration de 60 jours"},"content":{"rendered":"

Cisco Umbrella a bien servi les \u00e9quipes informatiques du march\u00e9 interm\u00e9diaire en tant que produit de s\u00e9curit\u00e9 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\u00e9. La question n’est plus de savoir s’il faut migrer, mais comment le faire sans rompre la r\u00e9solution DNS, perdre la visibilit\u00e9 SIEM ou cr\u00e9er une faille de protection pendant la transition. <\/p>\n

Ce billet est un guide de 60 jours. Quatre phases : 14 jours de d\u00e9couverte, 21 jours de d\u00e9ploiement parall\u00e8le, 14 jours de basculement DNS et 11 jours de mise hors service. Le moment le plus risqu\u00e9 est le changement de DNS dans la phase 3. Le reste est une gestion de projet m\u00e9thodique. <\/p>\n

Si vous souhaitez savoir pourquoi l’architecture d’Umbrella cr\u00e9e des limites pour les \u00e9quipes du march\u00e9 interm\u00e9diaire, la comparaison Cisco Umbrella vs Jimber<\/a> couvre l’analyse au niveau des fonctionnalit\u00e9s. Cet article suppose que vous avez d\u00e9cid\u00e9 de migrer et que vous avez besoin d’une certitude d’ex\u00e9cution. <\/p>\n

Le calendrier de migration de 60 jours en un coup d’\u0153il<\/h2>\n

Le remplacement de Cisco Umbrella par une plateforme SASE d’un seul fournisseur prend 60 jours r\u00e9partis en quatre phases : d\u00e9couverte et planification (14 jours), d\u00e9ploiement parall\u00e8le (21 jours), basculement et validation DNS (14 jours) et d\u00e9classement (11 jours). Le chemin critique passe par le basculement DNS dans la phase 3, o\u00f9 les changements de r\u00e9solveur se propagent \u00e0 travers votre r\u00e9seau et o\u00f9 toute mauvaise configuration entra\u00eene une perte de connectivit\u00e9 imm\u00e9diate. <\/p>\n

\n\n\n\n\n\n\n\n\n
Phase<\/th>\nJours<\/th>\nPrincipales activit\u00e9s<\/th>\nR\u00e9sultats<\/th>\nNiveau de risque<\/th>\n<\/tr>\n<\/thead>\n
1. D\u00e9couvrir<\/td>\n1-14<\/td>\nExportation des politiques, cartographie de l’int\u00e9gration, s\u00e9lection des fournisseurs<\/td>\nPlan de projet et appel d’offres<\/td>\nFaible<\/td>\n<\/tr>\n
2. D\u00e9ployer<\/td>\n15-35<\/td>\nD\u00e9ploiement parall\u00e8le, d\u00e9ploiement d’agents, \u00e9laboration de politiques<\/td>\nFonctionnement d’une nouvelle pile parall\u00e8lement \u00e0 Umbrella<\/td>\nMoyen<\/td>\n<\/tr>\n
3. D\u00e9coupage<\/td>\n36-49<\/td>\nChangement de DNS, validation, surveillance<\/td>\nMigration de la production termin\u00e9e<\/td>\nHaut<\/td>\n<\/tr>\n
4. D\u00e9classement<\/td>\n50-60<\/td>\nAnnulation du contrat, retrait de l’agent, audit<\/td>\nFerm\u00e9 Locataire parapluie<\/td>\nFaible<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Phase 1 (jours 1 \u00e0 14) : d\u00e9couverte et planification<\/h2>\n

Chaque migration SASE rat\u00e9e est due \u00e0 une phase de d\u00e9couverte incompl\u00e8te. Ces 14 jours permettent d’\u00e9viter les surprises qui transforment une migration contr\u00f4l\u00e9e en exercice d’incendie. <\/p>\n

Audit de votre mise en \u0153uvre actuelle de l’Umbrella<\/h3>\n

Commencez par exporter tout ce que contr\u00f4le Umbrella.<\/p>\n

Politique d’exportation.<\/strong> Utilisez l’API de gestion Umbrella v2 pour obtenir des listes de destination, des strat\u00e9gies DNS, des strat\u00e9gies Web et des r\u00e8gles de pare-feu. Le point de terminaison \/policies\/v2\/destinationlists<\/code> exporte les listes de domaines personnalis\u00e9es sous forme de JSON. La console d’administration permet l’exportation CSV des listes de destination manuellement. Exportez les deux. <\/p>\n

Documentation sur le r\u00e9solveur DNS.<\/strong> Identifiez chaque p\u00e9riph\u00e9rique, port\u00e9e DHCP et objet de strat\u00e9gie de groupe qui fait r\u00e9f\u00e9rence aux r\u00e9solveurs 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\u00e9rifiez les routeurs, les pare-feu, les serveurs DNS Windows avec les redirections conditionnelles et les entr\u00e9es de r\u00e9solveur cod\u00e9es en dur sur les serveurs. L’\u00e9chec le plus courant de la migration est une entr\u00e9e DNS oubli\u00e9e sur un routeur de branche unique qui continue d’envoyer des requ\u00eates \u00e0 Umbrella apr\u00e8s le basculement. <\/p>\n

\u00c9tudiez les int\u00e9grations API.<\/strong> Documentez chaque script, playbook et flux de travail SOAR qui fait appel \u00e0 l’API Investigate. Ces int\u00e9grations n\u00e9cessitent une reconstruction par rapport \u00e0 l’API de renseignement sur les menaces du nouveau fournisseur. <\/p>\n

Connecteurs SIEM.<\/strong> Umbrella exporte g\u00e9n\u00e9ralement les journaux vers un bac Amazon S3 crypt\u00e9 avec AES-256. Splunk utilise le module compl\u00e9mentaire Cisco Umbrella. Microsoft Sentinel utilise une fonction Azure ou un connecteur API REST. Documentez le format des journaux, la p\u00e9riode de r\u00e9tention et les tableaux de bord personnalis\u00e9s \u00e9labor\u00e9s \u00e0 partir des donn\u00e9es d’Umbrella. Les reconstructions de connecteurs SIEM repr\u00e9sentent 15 \u00e0 20 % de l’effort total de migration dans les transitions de plateformes de s\u00e9curit\u00e9 (Gartner, 2025). <\/p>\n

Pages de bloc personnalis\u00e9es et SAML SSO.<\/strong> Exportez toute page HTML personnalis\u00e9e et documentez l’int\u00e9gration de votre fournisseur d’identit\u00e9, qu’il s’agisse de Microsoft Entra ID, d’Okta ou d’AD Connector sur site.<\/p>\n

Cartographier les caract\u00e9ristiques de votre nouvelle plateforme<\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Caract\u00e9ristiques du parapluie<\/th>\n\u00c9quivalent SASE<\/th>\nEffort de migration<\/th>\n<\/tr>\n<\/thead>\n
Filtrage de la couche DNS (phishing, logiciels malveillants, C2)<\/td>\nModule de s\u00e9curit\u00e9 DNS<\/td>\nImportation de listes de destinations basses<\/td>\n<\/tr>\n
Proxy intelligent (inspection du domaine gris)<\/td>\nProxy en ligne SWG complet<\/td>\nMoyenne, couverture plus large<\/td>\n<\/tr>\n
Recherche de renseignements sur les menaces API<\/td>\nFlux de menaces sp\u00e9cifiques aux fournisseurs<\/td>\n\u00c9lev\u00e9, modification du sch\u00e9ma de l’API<\/td>\n<\/tr>\n
Filtrage des cat\u00e9gories de contenu<\/td>\nCat\u00e9gories d’URL du GTS<\/td>\nFaible, r\u00e9vision de la cartographie des cat\u00e9gories<\/td>\n<\/tr>\n
CASB \/ D\u00e9couverte de l’informatique fant\u00f4me<\/td>\nModule CASB<\/td>\nFaible \u00e0 moyen<\/td>\n<\/tr>\n
Pare-feu en nuage (CDFW)<\/td>\nFWaaS<\/td>\nMoyen, traduction des r\u00e8gles<\/td>\n<\/tr>\n
Exportation de journaux S3<\/td>\nJournalisation native de la plateforme<\/td>\nHaut, reconstruction du connecteur SIEM<\/td>\n<\/tr>\n
Connecteur AD \/ SAML<\/td>\nInt\u00e9gration des fournisseurs d’identit\u00e9<\/td>\nFaible<\/td>\n<\/tr>\n
Pages de bloc personnalis\u00e9es<\/td>\n\u00c9diteur de pages de bloc<\/td>\nFaible, syntaxe diff\u00e9rente<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Le changement conceptuel le plus important est le passage du \u00ab\u00a0proxy intelligent\u00a0\u00bb d’Umbrella \u00e0 une passerelle Web s\u00e9curis\u00e9e \u00e0<\/a> part enti\u00e8re. Umbrella ne proxie que le trafic vers des domaines risqu\u00e9s ou inconnus. Une SWG inspecte 100 % du trafic Web en ligne, ce qui n\u00e9cessite le d\u00e9ploiement d’un certificat racine sur chaque point d’extr\u00e9mit\u00e9 g\u00e9r\u00e9 pour l’inspection TLS. <\/p>\n

Constituer l’\u00e9quipe de projet et s\u00e9lectionner un fournisseur<\/h3>\n

Une migration de 200 utilisateurs n\u00e9cessite cinq r\u00f4les (chef de projet, ing\u00e9nieur r\u00e9seau, administrateur d’identit\u00e9, analyste de s\u00e9curit\u00e9, responsable du service d’assistance). Dans les \u00e9quipes informatiques l\u00e9g\u00e8res du march\u00e9 interm\u00e9diaire, une personne en couvre souvent deux. <\/p>\n

Si vous n’avez pas encore choisi une plateforme de remplacement, concentrez-vous sur : l’architecture cloud-native par rapport \u00e0 l’h\u00e9ritage des appliances virtualis\u00e9es, la s\u00e9curit\u00e9 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\u00e9ma de log SIEM, et le d\u00e9lai de mise en \u0153uvre de la premi\u00e8re politique. Le cadre d’\u00e9valuation des fournisseurs SASE, qui repose sur sept crit\u00e8res,<\/a> couvre ces aspects en profondeur. Pour une analyse d\u00e9taill\u00e9e du fonctionnement de l’architecture SASE<\/a>, le guide d’architecture explique l’inspection \u00e0 passage unique, la distribution PoP et les mod\u00e8les d’application des politiques. <\/p>\n

Phase 2 (jours 15 \u00e0 35) : d\u00e9ploiement parall\u00e8le<\/h2>\n

En faisant fonctionner votre nouvelle plateforme SASE avec Umbrella pendant trois semaines, vous pouvez valider les politiques et d\u00e9tecter les probl\u00e8mes d’int\u00e9gration avant qu’ils n’affectent le trafic de production.<\/p>\n

D\u00e9ploiement en parall\u00e8le et migration des politiques DNS<\/h3>\n

Commencez par 10 \u00e0 20 % de vos utilisateurs : le personnel de bureau, les travailleurs \u00e0 distance et au moins une succursale. \u00c9vitez l’\u00e9quipe de direction en tant que pilote. Choisissez des utilisateurs qui signalent les probl\u00e8mes avec pr\u00e9cision et qui tol\u00e8rent des inconv\u00e9nients mineurs pendant la p\u00e9riode de validation. <\/p>\n

La phase parall\u00e8le signifie que les deux plateformes fonctionnent simultan\u00e9ment. Umbrella g\u00e8re la majorit\u00e9 des utilisateurs. Le groupe pilote passe par la nouvelle plateforme. Cette approche \u00e0 double pile n\u00e9cessite un cadrage DNS minutieux afin d’\u00e9viter les fuites de trafic entre les plates-formes. Configurez l’\u00e9tendue DHCP ou le profil MDM du groupe pilote pour utiliser les nouveaux r\u00e9solveurs SASE, tandis que le reste du r\u00e9seau continue d’utiliser Umbrella. <\/p>\n

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\u00e9ploiements en cours depuis des ann\u00e9es accumulent des entr\u00e9es p\u00e9rim\u00e9es : des domaines qui n’existent plus, des blocages temporaires provenant d’incidents pass\u00e9s et des r\u00e8gles de caract\u00e8res g\u00e9n\u00e9riques trop larges. Effectuez une comparaison sur deux semaines : appliquez la m\u00eame politique sur les deux plateformes et comparez ce que chacune bloque. Le delta r\u00e9v\u00e8le les lacunes en mati\u00e8re de traduction. <\/p>\n

La taxonomie des cat\u00e9gories de contenu d’Umbrella ne correspond pas parfaitement \u00e0 celle d’autres fournisseurs. Le blocage de la cat\u00e9gorie \u00ab\u00a0S\u00e9curit\u00e9\u00a0\u00bb dans Umbrella peut couvrir des types de menaces diff\u00e9rents de la cat\u00e9gorie \u00e9quivalente sur votre nouvelle plateforme. Documentez chaque divergence et ajustez les politiques avant la phase 3. <\/p>\n

Mise en place d’int\u00e9grations d’identit\u00e9 et de reconstruction<\/h3>\n

Connectez votre fournisseur d’identit\u00e9. V\u00e9rifiez que le format UPN correspond \u00e0 celui utilis\u00e9 par Umbrella. Un d\u00e9calage entre user@company.com<\/code> et DOMAIN\\user<\/code> interrompt silencieusement l’application de la politique. <\/p>\n

Pour les reconstructions SIEM, remplacez enti\u00e8rement la source de donn\u00e9es Umbrella. Splunk a besoin d’un nouveau module compl\u00e9mentaire ou d’une entr\u00e9e HEC. Sentinel a besoin d’un nouveau connecteur de donn\u00e9es et de r\u00e8gles d’analyse reconstruites. Pr\u00e9voyez 3 \u00e0 5 jours pour Sentinel, 2 \u00e0 4 jours pour Elastic ou QRadar. Les playbooks SOAR faisant appel \u00e0 l’API d’application d’Umbrella n\u00e9cessitent une r\u00e9\u00e9criture compl\u00e8te par rapport \u00e0 l’API de la nouvelle plateforme. <\/p>\n

D\u00e9ployez le certificat racine du nouveau fournisseur via GPO, Intune ou Jamf. Pr\u00e9voyez une fen\u00eatre compl\u00e8te de sept jours. N’activez pas l’inspection TLS tant que le d\u00e9ploiement du certificat n’a pas atteint une couverture de plus de 95 %, sinon les utilisateurs seront confront\u00e9s \u00e0 des avertissements du navigateur sur chaque site HTTPS. <\/p>\n

Les plateformes SASE \u00e0 fournisseur unique avec architecture multi-tenant, y compris Jimber, g\u00e8rent l’acc\u00e8s des partenaires de service de mani\u00e8re native. V\u00e9rifiez que l’acc\u00e8s administrateur de votre partenaire correspond bien \u00e0 la nouvelle console. <\/p>\n

Phase 3 (jours 36 \u00e0 49) : Passage au DNS et validation<\/h2>\n

C’est la phase la plus risqu\u00e9e. Le DNS est \u00e0 la base de toute connexion internet. Un transfert mal configur\u00e9 signifie que les utilisateurs ne peuvent rien atteindre. <\/p>\n

Strat\u00e9gies de passage au DNS<\/h3>\n
\n\n\n\n\n\n\n\n
Strat\u00e9gie<\/th>\nMeilleur pour<\/th>\nTemps de recul<\/th>\nRisque<\/th>\n<\/tr>\n<\/thead>\n
Rotation progressive<\/td>\nPlus de 200 utilisateurs<\/td>\nMinutes par sous-r\u00e9seau<\/td>\nFaible<\/td>\n<\/tr>\n
Coupure brutale<\/td>\nMoins de 50 utilisateurs<\/td>\n15 \u00e0 30 minutes<\/td>\nMoyenne<\/td>\n<\/tr>\n
Transition \u00e0 double r\u00e9solveur<\/td>\nNon recommand\u00e9<\/td>\nImpr\u00e9visible<\/td>\nHaute<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Une rotation progressive est recommand\u00e9e. Modifiez les champs d’application DHCP un sous-r\u00e9seau \u00e0 la fois, en commen\u00e7ant par le sous-r\u00e9seau qui s’est le mieux comport\u00e9 pendant le projet pilote. Attendez 24 heures entre chaque sous-r\u00e9seau. Les configurations \u00e0 double r\u00e9solveur semblent s\u00fbres mais ont un comportement impr\u00e9visible : la plupart des syst\u00e8mes d’exploitation pr\u00e9f\u00e8rent le r\u00e9solveur qui r\u00e9pond le plus rapidement, et non celui qui est list\u00e9 en premier. <\/p>\n

Le manuel de transition<\/h3>\n
    \n
  1. Abaissez le TTL DNS<\/strong> \u00e0 300 secondes une semaine avant le basculement.<\/li>\n
  2. Validation avant le passage \u00e0 l’euro.<\/strong> \u00c0 partir d’une machine de test sur les nouveaux r\u00e9solveurs, r\u00e9solvez 50 domaines repr\u00e9sentatifs. Confirmez que la r\u00e9solution est inf\u00e9rieure \u00e0 50 ms et que les domaines bloqu\u00e9s renvoient des pages de blocage personnalis\u00e9es. <\/li>\n
  3. Mettez \u00e0 jour les champs d’application DHCP<\/strong> avec les nouveaux r\u00e9solveurs SASE. Poussez via la strat\u00e9gie de groupe ou le MDM pour les points d’extr\u00e9mit\u00e9. <\/li>\n
  4. Attendez la propagation des baux DHCP<\/strong> (8-24 heures). Ne forcez pas le renouvellement de tous les baux simultan\u00e9ment. <\/li>\n
  5. Surveillez pendant 48 heures.<\/strong> Suivez le taux de r\u00e9ussite de la r\u00e9solution (objectif 99,9 %+), la latence (moins de 50 ms) et les r\u00e9ponses NXDOMAIN pour les domaines qui devraient \u00eatre r\u00e9solus.<\/li>\n
  6. Validez l’application de la politique<\/strong> sur trois segments du r\u00e9seau.<\/li>\n
  7. Point de d\u00e9cision.<\/strong> Si les donn\u00e9es m\u00e9triques restent stables pendant 48 heures, cela signifie que le basculement est termin\u00e9. Une d\u00e9gradation d\u00e9clenche un retour en arri\u00e8re. <\/li>\n<\/ol>\n

    Pi\u00e8ges courants<\/h3>\n

    R\u00e9solution \u00ab\u00a0cerveau divis\u00e9\u00a0\u00bb.<\/strong> Tout appareil pointant encore vers les r\u00e9solveurs d’Umbrella fonctionne selon les anciennes politiques, tandis que le reste du r\u00e9seau utilise la nouvelle plateforme. Cela cr\u00e9e une faille de protection invisible. Proc\u00e9dez \u00e0 une analyse du r\u00e9seau apr\u00e8s le basculement, en v\u00e9rifiant notamment les param\u00e8tres DNS sur les routeurs, les serveurs et les appareils r\u00e9seau. <\/p>\n

    Rupture de la cha\u00eene DNSSEC.<\/strong> Si la nouvelle plateforme SASE g\u00e8re la validation DNSSEC diff\u00e9remment d’Umbrella, certains domaines s\u00e9curis\u00e9s peuvent devenir inaccessibles. Testez les domaines sign\u00e9s DNSSEC pendant la phase pilote, et non pendant le passage \u00e0 la production. <\/p>\n

    Les cas limites de l’IPv6.<\/strong> Les r\u00e9solveurs IPv6 d’Umbrella (2620:119:35::35) peuvent exister sur des dispositifs que votre audit ax\u00e9 sur IPv4 a manqu\u00e9s. Les serveurs \u00e0 double pile et les \u00e9quipements de r\u00e9seau sont les coupables habituels. <\/p>\n

    Conflits d’agents.<\/strong> Le Cisco Secure Client et le nouvel agent SASE ne doivent jamais \u00eatre actifs simultan\u00e9ment sur le m\u00eame terminal. Ils sont en concurrence pour le contr\u00f4le de la table de routage et des param\u00e8tres DNS, ce qui entra\u00eene un comportement de r\u00e9solution impr\u00e9visible. La phase parall\u00e8le devrait avoir valid\u00e9 ce point, mais v\u00e9rifiez \u00e0 nouveau \u00e0 l’\u00e9chelle. <\/p>\n

    Entr\u00e9es mises en cache.<\/strong> M\u00eame apr\u00e8s les changements DHCP, les terminaux mettent en cache les r\u00e9ponses DNS jusqu’\u00e0 l’expiration du TTL. L’abaissement du TTL \u00e0 300 secondes \u00e0 l’avance (\u00e9tape 1) limite cette fen\u00eatre \u00e0 cinq minutes au lieu de plusieurs heures. <\/p>\n

    Strat\u00e9gie de retour en arri\u00e8re<\/h3>\n

    R\u00e9initialiser les champs d’application DHCP aux r\u00e9solveurs Umbrella (208.67.222.222, 208.67.220.220). Forcez le renouvellement du DHCP sur les serveurs critiques. V\u00e9rifiez la r\u00e9solution par Umbrella. Ne supprimez pas les identit\u00e9s r\u00e9seau d’Umbrella et n’annulez pas l’abonnement tant que la phase 4 n’est pas termin\u00e9e. <\/p>\n

    Phase 4 (jours 50-60) : d\u00e9mant\u00e8lement<\/h2>\n

    Valider, supprimer les agents, cl\u00f4turer le contrat<\/h3>\n

    Confirmez qu’aucun trafic DNS n’atteint Umbrella en v\u00e9rifiant la recherche d’activit\u00e9 du tableau de bord pour les 72 derni\u00e8res heures. Toute requ\u00eate apparaissant signifie qu’un p\u00e9riph\u00e9rique ou un segment de r\u00e9seau a \u00e9t\u00e9 omis lors de la conversion. Lancez un scan du r\u00e9seau pour identifier les terminaux ou les appareils dont les entr\u00e9es DNS cod\u00e9es en dur pointent encore vers 208.67.222.222. <\/p>\n

    Comparez les statistiques de blocage des menaces de la nouvelle plateforme aux donn\u00e9es de r\u00e9f\u00e9rence ant\u00e9rieures \u00e0 la migration. Les chiffres ne correspondront pas exactement car la logique de la politique diff\u00e8re, mais l’ordre de grandeur devrait \u00eatre coh\u00e9rent. Une organisation de 200 utilisateurs bloquant 500 menaces par jour sur Umbrella devrait voir des chiffres comparables ou sup\u00e9rieurs sur la nouvelle plateforme. Une baisse significative sugg\u00e8re un \u00e9cart de traduction de la politique qui doit \u00eatre examin\u00e9. <\/p>\n

    Supprimez le client itin\u00e9rant Umbrella de chaque point d’extr\u00e9mit\u00e9. Il se lie au port 53 sur l’adresse loopback et intercepte les requ\u00eates m\u00eame apr\u00e8s l’arr\u00eat du service. D\u00e9ployez un script MDM qui arr\u00eate le service Umbrella_RC<\/code>, ex\u00e9cute le programme de d\u00e9sinstallation, efface les cl\u00e9s de registre sous HKLM\\SOFTWARE\\OpenDNS<\/code> et r\u00e9initialise les param\u00e8tres DNS de l’adaptateur. Supprimez le certificat racine d’Umbrella des magasins de confiance. <\/p>\n

    Notifiez par \u00e9crit \u00e0 Cisco le non-renouvellement de votre contrat. La plupart des contrats se renouvellent automatiquement avec des p\u00e9riodes de pr\u00e9avis de 30 \u00e0 60 jours. Exportez les rapports de conformit\u00e9 finaux et les journaux d’activit\u00e9 avant la d\u00e9sactivation du locataire. Pour les organisations r\u00e9glement\u00e9es par la NIS2 qui ont besoin de 12 \u00e0 24 mois de journaux consultables, transf\u00e9rez les donn\u00e9es historiques vers votre SIEM avant de fermer le locataire. <\/p>\n

    Planifiez un examen 30 jours apr\u00e8s la migration pour comparer les menaces bloqu\u00e9es, la latence de r\u00e9solution, 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\u00e9 \u00e0 l’article 21 de la NIS2 et servir de mod\u00e8le pour les futures transitions de plate-forme. <\/p>\n

    Ce qui prend la plupart des \u00e9quipes au d\u00e9pourvu<\/h2>\n

    Des politiques personnalis\u00e9es dont personne ne se souvient.<\/strong> Les d\u00e9ploiements qui durent depuis plus de trois ans accumulent des listes de destination cr\u00e9\u00e9es par le personnel qui a quitt\u00e9 l’entreprise. Examinez chaque liste en fonction des besoins actuels. <\/p>\n

    Int\u00e9grations API cach\u00e9es.<\/strong> Les analystes de s\u00e9curit\u00e9 \u00e9crivent des scripts rapides appelant l’API Investigate qui se trouvent dans des dossiers personnels ou des playbooks SOAR. Envoyez un courriel cibl\u00e9 demandant des informations sur l’utilisation de l’API Umbrella. <\/p>\n

    Les lacunes en mati\u00e8re d’enregistrement pendant la p\u00e9riode de transition.<\/strong> Lors d’un fonctionnement en parall\u00e8le, les \u00e9v\u00e9nements de s\u00e9curit\u00e9 se r\u00e9partissent entre les plates-formes. Aucune des deux n’a une visibilit\u00e9 compl\u00e8te. Communiquez la r\u00e9duction de la couverture SIEM \u00e0 votre \u00e9quipe de s\u00e9curit\u00e9 et aux parties prenantes charg\u00e9es de la conformit\u00e9. <\/p>\n

    Sous-estimation de la reconstruction du SIEM.<\/strong> La reconstruction des tableaux de bord, des alertes et des flux de travail automatis\u00e9s pour un nouveau sch\u00e9ma de journalisation prend de 30 \u00e0 40 heures pour un d\u00e9ploiement moyen typique. Pr\u00e9voyez un budget explicite \u00e0 cet effet. <\/p>\n

    Retard dans le d\u00e9ploiement des certificats.<\/strong> Les appareils qui sont \u00e9teints ou d\u00e9connect\u00e9s peuvent mettre des jours \u00e0 recevoir le nouveau certificat racine via MDM. N’activez l’inspection TLS qu’\u00e0 partir d’une couverture de 95 %. Les appareils utilisant des connexions VPN lentes ou ceux qui sont rarement red\u00e9marr\u00e9s sont les derniers \u00e0 recevoir les certificats pouss\u00e9s par les GPO. Suivez l’\u00e9volution du d\u00e9ploiement gr\u00e2ce \u00e0 vos rapports MDM avant d’activer l’inspection TLS. <\/p>\n

    Questions fr\u00e9quemment pos\u00e9es<\/h2>\n

    Puis-je faire fonctionner Cisco Umbrella et une nouvelle plateforme SASE en parall\u00e8le pendant la migration ?<\/h3>\n

    Oui. La phase parall\u00e8le fait fonctionner les deux plates-formes simultan\u00e9ment. Umbrella g\u00e8re la majorit\u00e9 des utilisateurs tandis que le groupe pilote passe par la nouvelle plateforme. Les deux plateformes resteront actives jusqu’au d\u00e9mant\u00e8lement de la phase 4. <\/p>\n

    Qu’advient-il de mes int\u00e9grations API d’Investigate ?<\/h3>\n

    L’enqu\u00eate sur l’acc\u00e8s s’arr\u00eate \u00e0 la fin de votre abonnement \u00e0 Umbrella. Il n’y a pas d’\u00e9quivalent entre les fournisseurs. Reconstruisez les flux de travail de chasse aux menaces \u00e0 l’aide de l’API de renseignements sur les menaces de votre nouvelle plateforme au cours de la phase 2. <\/p>\n

    Mon contrat Umbrella sera-t-il automatiquement renouvel\u00e9 si je ne respecte pas la date limite de r\u00e9siliation ?<\/h3>\n

    La plupart des contrats pr\u00e9voient un renouvellement automatique avec une p\u00e9riode de pr\u00e9avis de 30 \u00e0 60 jours. Soumettez la notification de non-renouvellement par \u00e9crit au cours de la phase 4 et conservez la confirmation. Si vous ne respectez pas ce d\u00e9lai, vous risquez d’\u00eatre engag\u00e9 pour une nouvelle p\u00e9riode de 12 \u00e0 36 mois. <\/p>\n

    Quel est le temps d’arr\u00eat habituel lors d’un basculement DNS ?<\/h3>\n

    Z\u00e9ro, s’il est ex\u00e9cut\u00e9 correctement. La rotation progressive modifie les champs d’application DHCP un sous-r\u00e9seau \u00e0 la fois. Les utilisateurs ressentent le changement de mani\u00e8re transparente lors du prochain renouvellement de leur bail DHCP. <\/p>\n

    Dois-je supprimer le client itin\u00e9rant Umbrella de chaque point d’extr\u00e9mit\u00e9 ?<\/h3>\n

    Oui, le client itin\u00e9rant se lie au port 53 sur l’adresse de bouclage et intercepte les requ\u00eates DNS m\u00eame apr\u00e8s l’arr\u00eat du service. Une suppression incompl\u00e8te entra\u00eene des \u00e9checs de r\u00e9solution intermittents. <\/p>\n

    Puis-je migrer vers une plateforme SASE autre que celle de Cisco sans avoir \u00e0 reformer mon \u00e9quipe ?<\/h3>\n

    Les concepts sont directement transf\u00e9rables. Le filtrage DNS, les politiques web, l’acc\u00e8s bas\u00e9 sur l’identit\u00e9 et l’int\u00e9gration SIEM fonctionnent selon les m\u00eames principes. Pr\u00e9voyez 2 \u00e0 3 jours pour la formation des administrateurs. Certaines plateformes SASE \u00e0 fournisseur unique, dont Jimber, r\u00e9duisent la courbe d’apprentissage en consolidant toute la gestion des politiques dans une console unique plut\u00f4t que dans des tableaux de bord distincts pour les politiques DNS, web et de pare-feu. <\/p>\n

    Comment la capacit\u00e9 CASB se compare-t-elle entre Umbrella et une plateforme SASE ?<\/h3>\n

    Les niveaux sup\u00e9rieurs d’Umbrella comprennent un CASB de base pour la d\u00e9couverte de l’informatique fant\u00f4me. La plupart des plates-formes SASE unifi\u00e9es offrent un CASB plus complet dans SASE<\/a>, y compris une DLP en ligne, des contr\u00f4les de politiques au niveau des applications et une int\u00e9gration avec la m\u00eame source d’identit\u00e9 qui r\u00e9git tous les autres acc\u00e8s. <\/p>\n

    Dans soixante jours, votre locataire Umbrella peut \u00eatre ferm\u00e9, votre trafic DNS circuler \u00e0 travers une plateforme SASE unifi\u00e9e, et votre SIEM reconstruit avec une visibilit\u00e9 compl\u00e8te. Le calendrier de mise en \u0153uvre de SASE<\/a> couvre la fa\u00e7on dont cette migration s’inscrit dans le cadre d’un d\u00e9ploiement plus large de la plateforme. Si votre \u00e9quipe pr\u00e9voit une migration au troisi\u00e8me ou quatri\u00e8me trimestre, Jimber propose une configuration de d\u00e9ploiement parall\u00e8le o\u00f9 vous utilisez la plateforme en m\u00eame temps qu’Umbrella d\u00e8s le premier jour, sans engagement jusqu’\u00e0 ce que vous soyez pr\u00eat \u00e0 passer \u00e0 autre chose. R\u00e9servez une d\u00e9monstration<\/a> pour \u00e9valuer votre migration. <\/p>\n","protected":false},"excerpt":{"rendered":"

    Manuel de jeu de 60 jours, \u00e9tape par \u00e9tape, pour migrer de Cisco Umbrella \u00e0 SASE, un fournisseur unique. Quatre phases, une strat\u00e9gie de basculement DNS, un plan de retour en arri\u00e8re et une liste de contr\u00f4le pour le d\u00e9mant\u00e8lement. <\/p>\n","protected":false},"author":3,"featured_media":13262,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[9],"tags":[],"class_list":["post-13265","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-categorise"],"acf":[],"_links":{"self":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts\/13265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/comments?post=13265"}],"version-history":[{"count":1,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts\/13265\/revisions"}],"predecessor-version":[{"id":13276,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts\/13265\/revisions\/13276"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/media\/13262"}],"wp:attachment":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/media?parent=13265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/categories?post=13265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/tags?post=13265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}