{"id":13264,"date":"2026-05-22T09:00:05","date_gmt":"2026-05-22T07:00:05","guid":{"rendered":"https:\/\/jimber.io\/?p=13264"},"modified":"2026-05-22T09:00:05","modified_gmt":"2026-05-22T07:00:05","slug":"cisco-umbrella-vervangen-door-single-vendor-sase-een-60-daags-migratieplan","status":"publish","type":"post","link":"https:\/\/jimber.io\/nl\/blog\/cisco-umbrella-vervangen-door-single-vendor-sase-een-60-daags-migratieplan\/","title":{"rendered":"Cisco Umbrella vervangen door single-vendor SASE: een 60-daags migratieplan"},"content":{"rendered":"

Cisco Umbrella was voor IT-teams in het middensegment een goed beveiligingsproduct voor de DNS-laag. Nu de oude Umbrella SKU’s in september 2025 uit de verkoop gaan en het softwareonderhoud in september 2026 afloopt, loopt de migratieklok. De vraag is niet langer \u00f3f er moet worden overgeschakeld, maar hoe dit moet gebeuren zonder DNS-resolutie te verbreken, SIEM-zichtbaarheid te verliezen of een beschermingsgat te cre\u00ebren tijdens de overgang. <\/p>\n

Deze post is een 60-dagen-playbook. Vier fasen: 14 dagen ontdekking, 21 dagen parallelle implementatie, 14 dagen DNS cutover en 11 dagen ontmanteling. Het moment met het hoogste risico is de DNS-switch in fase 3. De rest is methodisch projectmanagement. <\/p>\n

Als je achtergrondinformatie nodig hebt over waarom de architectuur van Umbrella beperkingen oplevert voor teams in het middensegment, kun je terecht bij de vergelijking tussen Cisco Umbrella en Jimber<\/a>. Deze post gaat ervan uit dat je hebt besloten te migreren en zekerheid over de uitvoering nodig hebt. <\/p>\n

De migratietijdlijn van 60 dagen in \u00e9\u00e9n oogopslag<\/h2>\n

Het vervangen van Cisco Umbrella door een single-vendor SASE-platform neemt 60 dagen in beslag, verdeeld over vier fasen: ontdekking en planning (14 dagen), parallelle implementatie (21 dagen), DNS cutover en validatie (14 dagen) en buitengebruikstelling (11 dagen). Het kritieke pad loopt door de DNS cutover in Fase 3, waar resolverwijzigingen zich over uw netwerk verspreiden en elke verkeerde configuratie onmiddellijk verlies van connectiviteit veroorzaakt. <\/p>\n

\n\n\n\n\n\n\n\n\n
Fase<\/th>\nDagen<\/th>\nBelangrijkste activiteiten<\/th>\nOutput<\/th>\nRisiconiveau<\/th>\n<\/tr>\n<\/thead>\n
1. Ontdek<\/td>\n1-14<\/td>\nBeleidsexport, integratie in kaart brengen, leveranciersselectie<\/td>\nProjectplan en RFP<\/td>\nLaag<\/td>\n<\/tr>\n
2. Zet in.<\/td>\n15-35<\/td>\nParallel uitrollen, agent uitrollen, beleid bouwen<\/td>\nFunctionerende nieuwe stack naast Umbrella<\/td>\nMiddelgroot<\/td>\n<\/tr>\n
3. Cutover<\/td>\n36-49<\/td>\nDNS-omschakeling, validatie, bewaking<\/td>\nProductiemigratie voltooid<\/td>\nHoog<\/td>\n<\/tr>\n
4. Buitengebruikstelling<\/td>\n50-60<\/td>\nContractontbinding, agentverwijdering, audit<\/td>\nGesloten Parapluhuurder<\/td>\nLaag<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Fase 1 (dagen 1-14): ontdekken en plannen<\/h2>\n

Elke mislukte SASE-migratie is terug te voeren op een onvolledige ontdekkingsfase. Deze 14 dagen voorkomen de verrassingen die van een gecontroleerde migratie een brandoefening maken. <\/p>\n

Uw huidige Umbrella-implementatie doorlichten<\/h3>\n

Begin met een export van alles wat Umbrella controleert.<\/p>\n

Beleidsexport.<\/strong> Gebruik de Umbrella Management API v2 om bestemmingslijsten, DNS-beleid, webbeleid en firewallregels op te halen. Het \/policies\/v2\/destinationlists<\/code> eindpunt exporteert aangepaste domeinlijsten als JSON. Met de beheerconsole kunt u handmatig CSV-bestemmingslijsten exporteren. Exporteer beide. <\/p>\n

Documentatie over DNS-resolver.<\/strong> Identificeer elk apparaat, DHCP scope en Group Policy Object dat verwijst naar de resolvers van Umbrella: 208.67.222.222 en 208.67.220.220 voor IPv4, 2620:119:35::35 en 2620:119:53::53 voor IPv6. Controleer routers, firewalls, Windows DNS-servers met conditionele forwarders en hardcoded resolver-vermeldingen op servers. De meest voorkomende migratiefout is een vergeten DNS-vermelding op een enkele branchrouter die query’s naar Umbrella blijft sturen na de cutover. <\/p>\n

Onderzoek API-integraties.<\/strong> Documenteer elk script, playbook en SOAR-workflow die de Investigate API aanroept. Voor deze integraties moet de threat intelligence-API van de nieuwe leverancier opnieuw worden gebouwd. <\/p>\n

SIEM-aansluitingen.<\/strong> Umbrella exporteert logs meestal naar een Amazon S3 bucket die is versleuteld met AES-256. Splunk gebruikt de Cisco Umbrella Add-on. Microsoft Sentinel gebruikt een Azure Function of REST API-connector. Documenteer het logformaat, de bewaarperiode en aangepaste dashboards die zijn gebouwd op Umbrella-gegevens. Het herbouwen van SIEM-connectoren is goed voor 15-20% van de totale migratie-inspanning bij de overgang naar een beveiligingsplatform (Gartner, 2025). <\/p>\n

Aangepaste blokpagina’s en SAML SSO.<\/strong> Exporteer elke aangepaste blokpagina HTML en documenteer uw identiteitsleverancierintegratie, of het nu gaat om Microsoft Entra ID, Okta of on-premises AD Connector.<\/p>\n

Breng functies in kaart op je nieuwe platform<\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Paraplufunctie<\/th>\nSASE-equivalent<\/th>\nMigratie inspanning<\/th>\n<\/tr>\n<\/thead>\n
DNS-laagfiltering (phishing, malware, C2)<\/td>\nDNS-beveiligingsmodule<\/td>\nLaag, bestemmingslijst importeren<\/td>\n<\/tr>\n
Intelligente proxy (inspectie van grijze domeinen)<\/td>\nVolledige SWG inline proxy<\/td>\nMedium, bredere dekking<\/td>\n<\/tr>\n
Onderzoek bedreigingsinformatie-API<\/td>\nLeverancierspecifieke bedreiging feed<\/td>\nHoog, API schema wijzigen<\/td>\n<\/tr>\n
Inhoudscategorie filteren<\/td>\nSWG URL-categorie\u00ebn<\/td>\nLaag, categorie mapping herziening<\/td>\n<\/tr>\n
CASB \/ schaduw IT ontdekken<\/td>\nCASB-module<\/td>\nLaag tot gemiddeld<\/td>\n<\/tr>\n
Cloud-delivered firewall (CDFW)<\/td>\nFWaaS<\/td>\nMedium, regelvertaling<\/td>\n<\/tr>\n
S3 log export<\/td>\nPlatform-native logging<\/td>\nHoog, herbouw SIEM-connector<\/td>\n<\/tr>\n
AD-connector \/ SAML<\/td>\nIntegratie identiteitsprovider<\/td>\nLaag<\/td>\n<\/tr>\n
Aangepaste blokpagina’s<\/td>\nBlokpagina-editor<\/td>\nLaag, andere syntaxis<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

De grootste conceptuele verschuiving is van Umbrella’s “Intelligent Proxy” naar een volledige Secure Web Gateway<\/a>. Umbrella proxioneert alleen verkeer naar risicovolle of onbekende domeinen. Een SWG inspecteert 100% van het webverkeer inline, waarvoor een rootcertificaat moet worden ingezet op elk beheerd eindpunt voor TLS-inspectie. <\/p>\n

Stel het projectteam samen en selecteer een leverancier<\/h3>\n

Voor een migratie van 200 gebruikers zijn vijf rollen nodig (projectmanager, netwerkengineer, identiteitsbeheerder, beveiligingsanalist, helpdeskleider). In slanke IT-teams in het middensegment neemt \u00e9\u00e9n persoon er vaak twee voor zijn rekening. <\/p>\n

Als je nog geen vervangend platform hebt gekozen, richt je dan op: cloud-native architectuur versus gevirtualiseerde appliance erfenis, DNS en webbeveiliging in \u00e9\u00e9n policy engine, agentless apparaatondersteuning voor IoT en OT, SIEM log schema documentatie, en time-to-first-policy. Het SASE-leverancier evaluatieraamwerk met zeven criteria<\/a> gaat hier dieper op in. Voor een gedetailleerd overzicht van hoe de SASE-architectuur werkt<\/a>, geeft de architectuurgids uitleg over single-pass inspectie, PoP-distributie en modellen voor beleidshandhaving. <\/p>\n

Fase 2 (dagen 15-35): parallelle uitrol<\/h2>\n

Door uw nieuwe SASE-platform drie weken lang naast Umbrella te laten draaien, kunt u beleidsregels valideren en integratieproblemen opsporen voordat ze het productieverkeer be\u00efnvloeden.<\/p>\n

Parallel implementeren en DNS-beleid migreren<\/h3>\n

Begin met 10-20% van je gebruikers: kantoorpersoneel, telewerkers en ten minste \u00e9\u00e9n filiaal. Vermijd het directieteam als pilot. Kies gebruikers die problemen nauwkeurig rapporteren en kleine ongemakken tolereren tijdens de validatieperiode. <\/p>\n

De parallelle fase betekent dat beide platformen tegelijkertijd draaien. Umbrella behandelt de meerderheid van de gebruikers. De pilotgroep routeert via het nieuwe platform. Deze dual-stack aanpak vereist een zorgvuldige DNS scoping om te voorkomen dat verkeer tussen de platformen weglekt. Configureer de DHCP scope of het MDM profiel van de pilootgroep om de nieuwe SASE resolvers te gebruiken, terwijl de rest van het netwerk Umbrella blijft gebruiken. <\/p>\n

Exporteer Umbrella-bestemmingslijsten als CSV en importeer ze in het nieuwe platform. Bekijk elke lijst handmatig voordat u deze importeert. Implementaties die al jaren lopen, accumuleren oudbakken items: domeinen die niet meer bestaan, tijdelijke blokkades van eerdere incidenten en te brede wildcardregels. Voer een twee weken durende vergelijking uit: pas hetzelfde voorgenomen beleid toe op beide platformen en vergelijk wat elk platform blokkeert. De delta onthult vertaalkloven. <\/p>\n

De taxonomie voor inhoudscategorie\u00ebn van Umbrella is niet perfect afgestemd op andere leveranciers. Het blokkeren van de categorie “Beveiliging” in Umbrella kan betrekking hebben op andere bedreigingstypen dan de gelijkwaardige categorie op uw nieuwe platform. Documenteer elke discrepantie en pas het beleid aan v\u00f3\u00f3r Fase 3. <\/p>\n

Identiteit en herbouw integraties opzetten<\/h3>\n

Maak verbinding met uw identity provider. Controleer of het UPN-formaat overeenkomt met wat Umbrella gebruikt. Een mismatch tussen user@company.com<\/code> en DOMAIN\\user<\/code> breekt de handhaving van het beleid in stilte af. <\/p>\n

Vervang voor SIEM-herbouwingen de Umbrella-gegevensbron volledig. Splunk heeft een nieuwe add-on of HEC-invoer nodig. Sentinel heeft een nieuwe dataconnector en herbouwde analyseregels nodig. Budget 3-5 dagen voor Sentinel, 2-4 dagen voor Elastic of QRadar. SOAR playbooks die Umbrella’s Enforcement API aanroepen, moeten volledig worden herschreven tegen de API van het nieuwe platform. <\/p>\n

Implementeer het hoofdcertificaat van de nieuwe leverancier via GPO, Intune of Jamf. Zorg voor een volledig venster van zeven dagen. Schakel TLS-inspectie pas in als het certificaat voor meer dan 95% is ge\u00efmplementeerd, anders krijgen gebruikers op elke HTTPS-site te maken met browserwaarschuwingen. <\/p>\n

Single-vendor SASE-platforms met een multi-tenantarchitectuur, waaronder Jimber, behandelen toegang voor servicepartners van nature. Controleer of de beheerderstoegang van je partner correct is toegewezen aan de nieuwe console. <\/p>\n

Fase 3 (dagen 36-49): DNS cutover en validatie<\/h2>\n

Dit is de fase met het hoogste risico. DNS ondersteunt elke internetverbinding. Een verkeerd geconfigureerde cutover betekent dat gebruikers niets kunnen bereiken. <\/p>\n

DNS cutover-strategie\u00ebn<\/h3>\n
\n\n\n\n\n\n\n\n
Strategie<\/th>\nBest voor<\/th>\nTerugdraaitijd<\/th>\nRisico<\/th>\n<\/tr>\n<\/thead>\n
Geleidelijke rotatie<\/td>\n200+ gebruikers<\/td>\nMinuten per subnet<\/td>\nLaag<\/td>\n<\/tr>\n
Harde omschakeling<\/td>\nMinder dan 50 gebruikers<\/td>\n15-30 minuten<\/td>\nMiddelmatig<\/td>\n<\/tr>\n
Overgang met twee oplossers<\/td>\nNiet aanbevolen<\/td>\nOnvoorspelbaar<\/td>\nHoog<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Geleidelijke rotatie wordt aanbevolen. Wijzig de DHCP-scopes \u00e9\u00e9n subnet per keer, te beginnen met het subnet dat het beste presteerde tijdens de pilot. Wacht 24 uur tussen subnetten. Instellingen met twee resolvers lijken veilig, maar zorgen voor onvoorspelbaar gedrag: de meeste besturingssystemen geven de voorkeur aan de resolver die het snelst reageert, niet aan de resolver die het eerst op de lijst staat. <\/p>\n

Het draaiboek voor een cutover<\/h3>\n
    \n
  1. Verlaag DNS TTL<\/strong> naar 300 seconden een week voor de overgang.<\/li>\n
  2. Pre-cutover validatie.<\/strong> Zet vanaf een testmachine op de nieuwe resolvers 50 representatieve domeinen om. Controleer of de resolutie minder dan 50 ms is en of geblokkeerde domeinen aangepaste blokpagina’s retourneren. <\/li>\n
  3. Werk DHCP-scopes bij<\/strong> naar de nieuwe SASE-resolvers. Push via Groepsbeleid of MDM voor eindpunten. <\/li>\n
  4. Wacht op DHCP lease propagatie<\/strong> (8-24 uur). Verleng niet alle leases tegelijkertijd. <\/li>\n
  5. Gedurende 48 uur controleren.<\/strong> Volg het succespercentage van de resolutie (doel 99,9%+), latentie (onder 50 ms) en NXDOMAIN reacties voor domeinen die moeten worden opgelost.<\/li>\n
  6. Valideer beleidshandhaving<\/strong> over drie netwerksegmenten.<\/li>\n
  7. Beslissingspunt.<\/strong> Schone statistieken gedurende 48 uur betekent dat de cutover voltooid is. Degradatie triggert rollback. <\/li>\n<\/ol>\n

    Veelvoorkomende valkuilen<\/h3>\n

    Oplossing voor gedeelde hersenen.<\/strong> Elk apparaat dat nog naar de resolvers van Umbrella wijst, werkt onder het oude beleid terwijl de rest van het netwerk het nieuwe platform gebruikt. Dit cre\u00ebert een onzichtbare beschermingskloof. Voer na de overgang een netwerkscan uit om specifiek de DNS-instellingen op routers, servers en netwerkapparaten te controleren. <\/p>\n

    DNSSEC-keten breekt.<\/strong> Als het nieuwe SASE-platform DNSSEC-validatie anders verwerkt dan Umbrella, kunnen bepaalde beveiligde domeinen onbereikbaar worden. Test DNSSEC-ondertekende domeinen tijdens de proeffase, niet tijdens de productie cutover. <\/p>\n

    IPv6-randgevallen.<\/strong> De IPv6-resolvers van Umbrella (2620:119:35::35) kunnen aanwezig zijn op apparaten die tijdens je IPv4-gerichte audit over het hoofd zijn gezien. Dual-stack servers en netwerkapparatuur zijn de gebruikelijke boosdoeners. <\/p>\n

    Conflicten tussen agenten.<\/strong> De Cisco Secure Client en de nieuwe SASE agent mogen nooit tegelijkertijd actief zijn op hetzelfde eindpunt. Ze concurreren om de controle over de routeringstabel en DNS-instellingen, waardoor onvoorspelbaar oplossingsgedrag ontstaat. De parallelle fase zou dit gevalideerd moeten hebben, maar controleer dit opnieuw op schaal. <\/p>\n

    Gecacheerde items.<\/strong> Zelfs na DHCP wijzigingen cachen eindpunten DNS antwoorden totdat TTL verloopt. Door TTL vooraf te verlagen naar 300 seconden (stap 1) wordt dit venster beperkt tot vijf minuten in plaats van uren. <\/p>\n

    Terugdraaien strategie<\/h3>\n

    DHCP-scopes terugdraaien naar Umbrella resolvers (208.67.222.222, 208.67.220.220). Forceer DHCP-vernieuwing op kritieke servers. Controleer de resolutie via Umbrella. Verwijder geen Umbrella netwerk identiteiten of annuleer het abonnement niet totdat Fase 4 is voltooid. <\/p>\n

    Fase 4 (dagen 50-60): ontmanteling<\/h2>\n

    Valideren, agenten verwijderen, het contract afsluiten<\/h3>\n

    Controleer of er geen DNS-verkeer de Umbrella bereikt door op het dashboard te zoeken naar de activiteit van de afgelopen 72 uur. Als er query’s verschijnen, betekent dit dat een apparaat of netwerksegment werd gemist tijdens de cutover. Voer een netwerkscan uit om eindpunten of apparaten te identificeren met hardgecodeerde DNS-vermeldingen die nog steeds naar 208.67.222.222 wijzen. <\/p>\n

    Vergelijk de dreigingsblokkeringsstatistieken van het nieuwe platform met die van voor de migratie. De cijfers zullen niet exact overeenkomen omdat de beleidslogica verschilt, maar de orde van grootte zou consistent moeten zijn. Een organisatie met 200 gebruikers die 500 bedreigingen per dag blokkeert op Umbrella zou vergelijkbare of hogere cijfers moeten zien op het nieuwe platform. Een significante daling suggereert een hiaat in de vertaling van het beleid dat moet worden onderzocht. <\/p>\n

    Verwijder de Umbrella Roaming Client van elk eindpunt. Deze bindt aan poort 53 op het loopback-adres en onderschept query’s, zelfs nadat de service is gestopt. Implementeer een MDM-script dat de service Umbrella_RC<\/code> stopt, de uninstaller uitvoert, registersleutels wist onder HKLM\\SOFTWARE\\OpenDNS<\/code> en DNS-instellingen voor adapters opnieuw instelt. Verwijder het hoofdcertificaat van Umbrella uit de vertrouwensopslag. <\/p>\n

    Breng Cisco schriftelijk op de hoogte van het feit dat u het contract niet wilt verlengen. De meeste contracten worden automatisch verlengd met een opzegtermijn van 30-60 dagen. Exporteer definitieve nalevingsrapporten en activiteitenlogboeken voordat u de huurder deactiveert. Voor NIS2-gereguleerde organisaties die 12-24 maanden doorzoekbare logboeken nodig hebben, zet u historische gegevens over naar uw SIEM voordat u de huurder afsluit. <\/p>\n

    Plan een 30-daagse evaluatie na de migratie waarbij geblokkeerde bedreigingen, oplossingslatentie, fout-positieve percentages en dekking van SIEM-waarschuwingen worden vergeleken met de basislijn van voor de migratie. Documenteer de gehele migratie voor naleving van NIS2 Artikel 21 en als sjabloon voor toekomstige platformovergangen. <\/p>\n

    Wat de meeste teams verrast<\/h2>\n

    Aangepast beleid dat niemand onthoudt.<\/strong> Implementaties die langer dan 3 jaar lopen, accumuleren bestemmingslijsten die zijn gemaakt door personeel dat is vertrokken. Vergelijk elke lijst met de huidige vereisten. <\/p>\n

    Verborgen API-integraties.<\/strong> Beveiligingsanalisten schrijven snelle scripts die de Investigate API aanroepen en die in persoonlijke mappen of SOAR playbooks staan. Stuur een gerichte e-mail met vragen over het gebruik van de Umbrella API. <\/p>\n

    Loggen van hiaten tijdens de overgang.<\/strong> Tijdens parallelle werking worden beveiligingsgebeurtenissen verdeeld tussen platforms. Geen van beide heeft volledig overzicht. Communiceer de verminderde SIEM-dekking met uw beveiligingsteam en compliance belanghebbenden. <\/p>\n

    Onderschatting van de herbouw van SIEM.<\/strong> Het opnieuw opbouwen van dashboards, waarschuwingen en geautomatiseerde workflows voor een nieuw logschema neemt 30-40 uur in beslag voor een typische implementatie in het middensegment van de markt. Budgetteer dit expliciet. <\/p>\n

    Vertraging bij de implementatie van certificaten.<\/strong> Apparaten die zijn uitgeschakeld of losgekoppeld, kunnen dagen nodig hebben om het nieuwe basiscertificaat via MDM te ontvangen. Schakel TLS-inspectie alleen in boven 95% dekking. Apparaten met langzame VPN-verbindingen of apparaten die zelden opnieuw worden opgestart, ontvangen als laatste GPO-pushed certificaten. Volg de voortgang van de implementatie via uw MDM-rapportage voordat u TLS-inspectie op “afdwingen” zet. <\/p>\n

    Veelgestelde vragen<\/h2>\n

    Kan ik Cisco Umbrella en een nieuw SASE-platform parallel laten draaien tijdens de migratie?<\/h3>\n

    Ja. In de parallelle fase worden beide platforms tegelijkertijd gebruikt. Umbrella handelt de meeste gebruikers af terwijl de pilotgroep de routes via het nieuwe platform afhandelt. Houd beide actief tot fase 4 buiten gebruik wordt gesteld. <\/p>\n

    Wat gebeurt er met mijn Investigate API-integraties?<\/h3>\n

    De toegang stopt wanneer uw Umbrella-abonnement eindigt. Er is geen equivalent voor meerdere leveranciers. Herbouw threat hunting-workflows op basis van de threat intelligence-API van uw nieuwe platform tijdens fase 2. <\/p>\n

    Wordt mijn Umbrella contract automatisch verlengd als ik de opzegtermijn niet respecteer?<\/h3>\n

    De meeste contracten voorzien in automatische verlenging met een opzegtermijn van 30-60 dagen. Dien een niet-verlenging schriftelijk in tijdens fase 4 en bewaar de bevestiging. Als je de deadline niet haalt, ben je mogelijk gebonden aan nog een termijn van 12-36 maanden. <\/p>\n

    Wat is de typische downtime tijdens een DNS-overgang?<\/h3>\n

    Nul, als het correct wordt uitgevoerd. Geleidelijke rotatie wijzigt DHCP-scopes \u00e9\u00e9n subnet per keer. Gebruikers ervaren de verandering transparant bij hun volgende DHCP-leasevernieuwing. <\/p>\n

    Moet ik de Umbrella Roaming Client van elk eindpunt verwijderen?<\/h3>\n

    Ja. De Roaming Client bindt aan poort 53 op het loopback-adres en onderschept DNS-query’s zelfs nadat de service is gestopt. Onvolledige verwijdering veroorzaakt intermitterende mislukte resoluties. <\/p>\n

    Kan ik migreren naar een niet-Cisco SASE platform zonder mijn team opnieuw op te leiden?<\/h3>\n

    De concepten zijn direct overdraagbaar. DNS-filtering, webbeleid, identiteitsgebaseerde toegang en SIEM-integratie werken volgens dezelfde principes. Budget 2-3 dagen voor beheerderstraining. Sommige SASE-platforms van \u00e9\u00e9n leverancier, waaronder Jimber, verminderen de leercurve door al het beleidsbeheer te consolideren in \u00e9\u00e9n console in plaats van aparte dashboards voor DNS-, web- en firewallbeleid. <\/p>\n

    Hoe verhoudt de capaciteit van een CASB zich tussen Umbrella en een SASE-platform?<\/h3>\n

    De hogere niveaus van Umbrella omvatten basis-CASB voor schaduw-IT-detectie. De meeste unified SASE-platforms bieden uitgebreidere CASB in SASE<\/a>, inclusief inline DLP, beleidscontroles op app-niveau en integratie met dezelfde identiteitsbron die alle andere toegang regelt. <\/p>\n

    Over zestig dagen kan uw Umbrella-tenant worden afgesloten, uw DNS-verkeer door een uniform SASE-platform stromen en uw SIEM opnieuw worden opgebouwd met volledige zichtbaarheid. De bredere SASE implementatie tijdlijn<\/a> laat zien hoe deze migratie past in een grotere uitrol van het platform. Als je team een migratie in Q3 of Q4 plant, biedt Jimber een parallelle implementatie aan waarbij je het platform vanaf dag \u00e9\u00e9n naast Umbrella gebruikt, zonder enige verplichting totdat je klaar bent om over te stappen. Boek een demo<\/a> om je migratie te bekijken. <\/p>\n","protected":false},"excerpt":{"rendered":"

    60-dagen stapsgewijs draaiboek om te migreren van Cisco Umbrella naar single-vendor SASE. Vier fasen, DNS cutover strategie, rollback plan en decommission checklist. <\/p>\n","protected":false},"author":3,"featured_media":13261,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-13264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ongecategoriseerd"],"acf":[],"_links":{"self":[{"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/posts\/13264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/comments?post=13264"}],"version-history":[{"count":1,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/posts\/13264\/revisions"}],"predecessor-version":[{"id":13275,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/posts\/13264\/revisions\/13275"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/media\/13261"}],"wp:attachment":[{"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/media?parent=13264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/categories?post=13264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jimber.io\/nl\/wp-json\/wp\/v2\/tags?post=13264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}