← Referenční architektury / reference-architecture / architectures

Přechod na architekturu SASE s Cloudflare

Stáhnout si Verze PDF této referenční architektury.

Cloudflare One je platforma secure access service edge (SASE), která chrání podnikové aplikace, uživatele, zařízení a sítě. Postupným zaváděním Cloudflare One se organizace mohou zbavit změti hardwarových zařízení a dalších dílčích řešení a místo toho sloučit funkce zabezpečení a sítí do jedné jednotné řídicí roviny. Taková transformace sítě a zabezpečení pomáhá řešit klíčové výzvy, kterým dnešní firmy čelí, mimo jiné:

• Zabezpečení přístupu libovolného uživatele k libovolnému prostředku pomocí postupů Zero Trust
• Obrana proti kybernetickým hrozbám, včetně vícekanálového phishingu a ransomwarových útoků
• Ochrana dat kvůli souladu s předpisy a prevenci úniků
• Zjednodušení konektivity mezi pobočkami, datovými centry a cloudovými prostředími

Cloudflare One je postaven na cloud pro konektivitu ↗, jednotná inteligentní platforma programovatelných cloud-native služeb, která umožňuje konektivitu typu kdokoli s kýmkoli mezi všemi sítěmi (podnikovými i internetem), cloudovými prostředími, aplikacemi a uživateli. Je jednou z největší globální sítě ↗, s datacentry rozmístěnými napříč stovky měst po celém světě ↗ a propojení s více než 13 000 síťovými partnery (peers). Má také větší pokrytí v klíčové internetové výměnné uzly ↗ než mnoho jiných velkých technologických společností.

Díky tomu se Cloudflare pohybuje ve vzdálenosti přibližně 50 ms od zhruba 95 % světové populace připojené k internetu. Protože jsou navíc všechny služby Cloudflare navržené tak, aby běžely v každé síťové lokalitě, veškerý provoz se připojuje, kontroluje a filtruje v blízkosti zdroje, což zajišťuje nejlepší výkon a konzistentní uživatelský zážitek.

Tento dokument popisuje referenční architekturu pro organizace, které směřují k architektuře SASE, a ukazuje, jak Cloudflare One takovou transformaci zabezpečení a sítě umožňuje.

Tato referenční architektura je určena pracovníkům IT a bezpečnostních týmů, kteří mají na starosti stávající infrastrukturu organizace nebo ji dobře znají. Užitečná je zkušenost s technologiemi důležitými pro zabezpečení hybridní práce, jako jsou poskytovatelé identity (IdP), uživatelské adresáře, jednotné přihlašování (SSO), zabezpečení nebo správa koncových bodů (EPP, XDR, UEM, MDM), firewally, routery a specializovaná řešení, jako je hardware pro kontrolu paketů či obsahu, prevence hrozeb a technologie prevence úniku dat.

Pro hlubší základní pochopení Cloudflare doporučujeme následující zdroje:

• Co je Cloudflare? | Web ↗ (čtení na 5 minut) nebo video ↗ (2 minuty)

• Přehled řešení: Cloudflare One ↗ (čtení na 3 minuty)
• Whitepaper: Přehled internetově nativní architektury SASE ↗ (čtení na 10 minut)
• Blog: Zero Trust, SASE a SSE: základní koncepty pro vaši síť nové generace ↗ (čtení na 14 minut)

Čtenáři této referenční architektury se dozvědí:

• Jak Cloudflare One chrání zaměstnance, zařízení, aplikace, data a sítě organizace
• Jak Cloudflare One zapadá do vaší stávající infrastruktury a jak přistupovat k migraci na architekturu SASE
• Jak naplánovat nasazení Cloudflare One

Tento dokument sice zkoumá Cloudflare One po technické stránce, nenabízí ale podrobný popis každého produktu na platformě. Místo toho se zaměřuje na to, jak všechny služby v rámci Cloudflare One umožňují sloučit síťové služby a zabezpečení sítě do jedné architektury. Navštivte dokumentace pro vývojáře ↗ s dalšími informacemi ke konkrétní oblasti produktu nebo případu použití.

Většina zaměstnanců tradičně pracovala v kanceláři a k firemní síti se připojovala lokálně přes Ethernet nebo Wi-Fi. Většina podnikových systémů (například souborové servery, tiskárny, aplikace) se nacházela v této interní síti a byla přístupná pouze z ní. Po připojení měli uživatelé obvykle široký přístup k lokálním zdrojům. Kolem sítě byl vytvořen bezpečnostní perimetr, který ji chránil před vnějšími hrozbami, přicházejícími nejčastěji z veřejného internetu. Většina podnikových úloh běžela lokálně a byla přístupná jen uvnitř sítě, přičemž na internetu existovalo jen minimum firemních dat nebo aplikací, případně tam neexistovala vůbec.

Tento přístup k IT bezpečnosti typu „hrad a příkop“ ale narušily tři důležité trendy:

1. Zaměstnanci se stali mobilnějšími. Organizace stále více přecházejí na vzdálenou nebo hybridní práci a podporují používání osobních zařízení, tedy takových, která nevlastní firma.
2. Zrychlená cloudová migrace. Organizace přesouvají aplikace, data i infrastrukturu z nákladných on-premises datacenter do veřejných nebo privátních cloudových prostředí, aby zlepšily flexibilitu, škálovatelnost a nákladovou efektivitu.
3. Kybernetické hrozby se vyvinuly. Výše uvedené trendy rozšiřují útočnou plochu organizací. Útočné kampaně jsou dnes například propracovanější a vytrvaleji zneužívají více kanálů k proniknutí do organizací a díky rozšíření černého trhu s takzvaným „cybercrime-as-a-service“ čelí kyberzločinci nižším vstupním bariérám.

Tradiční zabezpečení založené na perimetru se s těmito změnami vyrovnává jen obtížně. Rozšiřování „příkopu“ směrem ven přineslo administrátorům provozní komplikace, uživatelům horší uživatelský zážitek a nekonzistentní uplatňování bezpečnostních kontrol napříč uživateli a aplikacemi.

Diagram výše ukazuje příklad tohoto upraveného přístupu založeného na perimetru, kdy jsou firewally, WAN routery a VPN koncentrátory propojeny vyhrazenými přípojkami WAN tvořenými okruhy MPLS nebo pronajatými linkami. Diagram zároveň znázorňuje typické problémové oblasti. Ve snaze centralizovat zásady organizace někdy protlačují veškerý internetový provoz zaměstnanců přes svou infrastrukturu VPN, což vede k pomalému prohlížení a stížnostem uživatelů. Zaměstnanci pak hledají náhradní řešení, například používání neschválených zařízení, čímž se při práci z domova nebo na veřejné Wi-Fi zvyšuje jejich vystavení internetovým útokům. Týmy IT navíc kvůli složitosti své síťové infrastruktury nedokážou rychle reagovat na měnící se potřeby firmy.

Tyto výzvy nutí řadu organizací upřednostňovat cíle jako:

• Zvýšení obchodní agility díky podpoře vzdálené/hybridní práce s bezpečným přístupem any-to-any
• Zvyšování produktivity zjednodušením správy zásad a zefektivněním uživatelských zkušeností
• Snížení kybernetického rizika díky ochraně uživatelů a dat před phishingem, ransomwarem a dalšími hrozbami napříč všemi kanály
• Sjednocení přehledu a řízení napříč sítěmi a zabezpečením
• Snížení nákladů nahrazením drahých zařízení a infrastruktury (například VPN, hardwarových firewallů a připojení MPLS)

V posledních letech secure access service edge ↗, neboli SASE, se stal architekturou, ke které organizace směřují, aby těchto cílů dosáhly. V architektuře SASE jsou síťová konektivita a zabezpečení sjednoceny na jedné cloudové platformě a v jedné řídicí rovině, což zajišťuje konzistentní viditelnost, řízení a zkušenost pro libovolného uživatele při přístupu k libovolné aplikaci.

Platformy SASE se skládají ze síťových a bezpečnostních služeb, které jsou podepřeny podpůrnými provozními službami a mechanismem pro vyhodnocování zásad:

• Síťové služby přesměrovávají provoz z různých sítí do jedné globální firemní sítě. Tyto služby poskytují funkce jako firewalling, směrování a load balancing.
• Bezpečnostní služby se uplatňují na provoz procházející sítí, což umožňuje filtrovat určité typy provozu a řídit, kdo má k čemu přístup.
• Provozní služby poskytují funkce platné v rámci celé platformy, jako je protokolování, přístup k API a komplexní podpora Infrastructure-as-Code prostřednictvím poskytovatelů jako Terraform.
• Policy engine se integruje se všemi službami a umožňuje administrátorům definovat politiky, které se pak uplatňují ve všech propojených službách.

Většina organizací přechází na architekturu SASE postupně, nikoli najednou: nejprve řeší klíčové případy použití v oblasti zabezpečení a připojení a zavádí služby jako Zero Trust Network Access ↗ (ZTNA) nebo Secure Web Gateway ↗ (SWG). Některé organizace volí služby SASE od více dodavatelů. Většina organizací však usiluje o konsolidaci zabezpečení u jednoho dodavatele, aby dosáhla jednodušší správy, ucelené viditelnosti a konzistentní zkušenosti.

Cloudflare One ↗ je jednododavatelská platforma SASE, ve které jsou všechny služby navrženy tak, aby fungovaly ve všech lokalitách. Veškerý provoz se kontroluje co nejblíže svému zdroji, což zajišťuje konzistentní rychlost a škálovatelnost všude. A díky kombinovatelným a flexibilním on-rampám lze provoz směrovat z jakéhokoli zdroje do jakéhokoli cíle.

Connectivity cloud od Cloudflare navíc nabízí mnoho dalších služeb, které zlepšují výkon a zabezpečení aplikací, jako například API Gateway ↗, Web Application Firewall ↗, Doručování obsahu ↗, nebo Zmírnění útoků DDoS ↗, z nichž všechny mohou doplňovat SASE architekturu organizace. Naše funkce Content Delivery Network (CDN) lze například použít ke zlepšení výkonu vlastní firemní intranetové sítě hostované interně. Celá řada služeb Cloudflare je znázorněna níže.

Platforma SASE od Cloudflare těží z toho, že využíváme anycast ↗ Technologie anycast umožňuje Cloudflare inzerovat IP adresy našich služeb z každého datového centra po celém světě, takže provoz je vždy směrován do nejbližšího datového centra Cloudflare od zdroje. To znamená, že kontrola provozu, ověřování a vynucování politik probíhá blízko koncového uživatele, což vede k trvale vysoké kvalitě uživatelské zkušenosti.

Díky anycastu je síť Cloudflare dobře vyvážená. Pokud dojde k náhlému nárůstu provozu v síti, lze zátěž rozložit mezi více datových center, což pomáhá udržet stabilní a spolehlivé připojení pro uživatele. Cloudflare navíc disponuje rozsáhlou kapacita sítě ↗ a Chytré směrování optimalizované pro AI/ML ↗ zároveň pomáhají zajistit, aby byl výkon neustále optimalizovaný.

Naproti tomu řada dalších poskytovatelů SASE používá unicastové směrování, kdy je jedna IP adresa přiřazena jednomu serveru nebo datovému centru. V mnoha takových architekturách je pak jedna IP adresa přiřazena konkrétní aplikaci, což znamená, že požadavky na přístup k této aplikaci mohou mít velmi odlišný průběh směrování v síti podle toho, jak daleko musí provoz cestovat. Výkon tak může být vynikající pro zaměstnance pracující v kanceláři vedle serverů dané aplikace, avšak špatný pro vzdálené zaměstnance nebo ty, kteří pracují v zahraničí. Unicast navíc komplikuje škálování zátěže provozu: dané umístění služby musí při nárůstu zátěže navyšovat zdroje samo, zatímco anycastové sítě dokážou provoz rozložit mezi mnoho datových center a geografických oblastí.

Chcete-li pochopit, jak SASE zapadá do IT infrastruktury organizace, podívejte se na diagram níže, který zobrazuje všechny běžné součásti této infrastruktury. Další části tohoto průvodce budou do diagramu postupně doplňovat, kam zapadají jednotlivé části platformy SASE od Cloudflare.

V horní polovině diagramu je řada internetových zdrojů (např. Facebook), SaaS aplikací (např. ServiceNow) a aplikací běžících v infrastruktura jako služba (IaaS) ↗ platformu (například AWS). Tato příkladová organizace již nasadila cloudové poskytovatelé identity ↗ (IdP), jednotná správa koncových bodů ↗ (UEM) a platformy pro ochranu koncových zařízení (EPP) v rámci iniciativy Zero Trust.

V dolní polovině je řada uživatelů, zařízení, sítí a lokalit. Uživatelé pracují z různých míst: z domova, z centrály a poboček, z letišť a odjinud. Zařízení, která používají, mohou být spravovaná organizací nebo mohou jít o osobní zařízení. Kromě cloudu běží aplikace také v datovém centru v sídle organizace a v kolokačním zařízení provozovatele datového centra (Equinix ↗, v tomto příkladu).

Architektura SASE definuje, zabezpečuje a zjednodušuje způsob, jakým se každý uživatel a zařízení připojuje k jednotlivým zdrojům v diagramu. V následujících částech tento návod ukáže způsoby, jak do výše uvedené infrastruktury integrovat Cloudflare One:

• Aplikace a služby: Umístění přístupu k privátním aplikacím a službám za Cloudflare
• Sítě: Připojení celých sítí ke Cloudflare
• Přeposílání provozu zařízení: Usnadnění přístupu k prostředkům chráněným Cloudflare z libovolného zařízení
• Ověřování uživatelů a zařízení: Identifikace uživatelů, od kterých požadavky na přístup pocházejí, a zařízení, která tito uživatelé používají

Cesta k architektuře SASE obvykle začíná potřebou organizace poskytnout vzdálený přístup k interním webovým aplikacím a službám nedostupným z internetu, například přes SSH nebo RDP. Organizace k propojení uživatelů s firemní sítí, kde tyto aplikace běží, typicky nasazují zařízení VPN. Řada aplikací dnes ale běží na cloudových platformách Infrastructure as a Service, kde se tradiční řešení VPN konfigurují obtížně. To se často projevuje špatným výkonem aplikací a připojení pro uživatele.

Zero Trust Network Access ↗ (ZTNA), služba SASE, která zabezpečuje přístup k samostatně hostovaným aplikacím a službám. Funkce ZTNA lze rozdělit zhruba do dvou kategorií: 1) navázání konektivity mezi sítí Cloudflare a prostředími, kde aplikace běží, a 2) nastavení zásad, které určují, jak k těmto aplikacím uživatelé přistupují. V této části se nejprve podíváme na první bod, tedy jak aplikace připojit ke Cloudflare.

Konektivita k self-hosted aplikacím je zajištěna tunely, které vytváří a spravuje softwarový konektor, cloudflared. cloudflared je lehký daemon nainstalovaný v infrastruktuře organizace, který přes odchozí připojení vytváří tunel do globální sítě Cloudflare. Konektor lze nainstalovat několika způsoby:

• V operačním systému nainstalovaném na bare metal serveru
• V operačním systému běžícím ve virtualizovaném prostředí
• V kontejner ↗ běžící v prostředí Docker nebo Kubernetes

cloudflared běží na operačních systémech Windows, Linux nebo macOS a vytváří šifrovaný tunel pomocí protokolu QUIC, moderního protokolu, který místo TCP využívá UDP pro rychlý výkon tunelu a moderní standardy šifrování. V zásadě existují dva přístupy, jak mohou uživatelé nasadit cloudflared ve svém prostředí:

1. Na stejném serveru a operačním systému, na kterém běží daná aplikace nebo služba. S tím se obvykle setkáte u vysoce rizikových nebo compliance nasazení, kde organizace vyžadují samostatný tunel pro každou aplikaci. cloudflared spotřebovává malé množství CPU a RAM, takže dopad na výkon serveru je zanedbatelný.
2. Na vyhrazeném serveru (serverech) ve stejné síti, kde běží aplikace. Ve většině případů jde o více kontejnerů v prostředí Docker nebo Kubernetes.

cloudflared řídí několik odchozích připojení zpět do Cloudflare a obvykle nevyžaduje žádné změny síťových firewallů. Tato připojení jsou rozložena mezi servery ve více než jednom datovém centru Cloudflare pro zajištění spolehlivosti a failoveru. Provoz určený pro tunel se přesměruje na připojení, které je geograficky nejblíže požadavku, a pokud cloudflared připojení neodpovídá, tunel se automaticky přepne na další dostupné.

Pro větší kontrolu nad provozem směrovaným přes jednotlivá tunelová připojení se uživatelé mohou integrovat s Cloudflare vyvažování zátěže Aby byla zajištěna spolehlivá místní konektivita, měly by organizace nasadit více než jednu instanci cloudflared v rámci infrastruktury svých aplikací. Pokud například provozujete deset front-endových webových serverů v clusteru Kubernetes, můžete nasadit tři služby kubernetes spouštění cloudflared repliky.

Jakmile jsou tunely navázány, existují dvě metody, jak se uživatelský provoz předává vaší aplikaci nebo službě. Každá z níže uvedených metod je chráněna zásadami spravovanými službou ZTNA, které vynucují ověřování a řízení přístupu (podrobněji se jimi budeme zabývat dále v tomto dokumentu).

Každý veřejný hostname je vázaný na konkrétní adresu, protokol a port přiřazené privátní aplikaci, což umožňuje úzce vymezený přístup ke konkrétní službě i v případě, že na stejném hostu běží více aplikací.

Organizace mohou například definovat veřejný hostname (mywebapp.domain.com) aby poskytl přístup k webovému serveru běžícímu na https://localhost:8080, a zároveň zajišťuje, že nedojde k přístupu k lokálním službám Kubernetes.

Klíčové funkce:

• Ve veřejné DNS zóně se vytvoří hostname a veškeré požadavky na tento hostname se nejprve směrují do sítě Cloudflare, kde se ověří proti nakonfigurovaným bezpečnostním a přístupovým politikám, a teprve poté se přes tunel přesměrují k zabezpečenému privátnímu prostředku
• V rámci jednoho tunelu lze definovat více hostname, přičemž každý hostname je namapován na jednu aplikaci (adresu a port služby)
• Podpora protokolů HTTP/HTTPS
• Přístup ke zdrojům vyžaduje pouze prohlížeč
• Když je na uživatelském zařízení nasazen klient zařízení Cloudflare, mohou zásady při vynucování využívat další kontextové signály (například zda je zařízení spravované nebo zda běží nejnovější verze operačního systému)
• Pro přístup ke službám SSH/VNC vykresluje Cloudflare terminál SSH/VNC pomocí WebAssembly přímo v prohlížeči

Aplikace zpřístupněné tímto způsobem využívají všechny výhody předních služeb Cloudflare v oblasti DNS, CDN a DDoS, stejně jako našeho webového aplikačního firewallu (WAF), API a služeb pro ochranu před boty, aniž by bylo nutné vystavit aplikační servery přímo internetu.

V některých případech mohou uživatelé chtít využít zásady ZTNA k zajištění přístupu k mnoha aplikacím v rámci celé privátní sítě. To umožňuje větší flexibilitu ve způsobu připojování klientů a zpřístupňování služeb a zároveň umožňuje komunikaci s prostředky i přes jiné protokoly než HTTP. V tomto scénáři uživatelé specifikují podsíť privátní sítě, kterou chtějí zpřístupnit přes Cloudflare.

Klíčové funkce:

• cloudflared, v kombinaci s agentem zařízení Cloudflare poskytuje přístup k privátním sítím a umožňuje libovolná spojení L4 TCP, UDP nebo ICMP
• Lze nakonfigurovat jednu nebo více sítí pomocí notace CIDR (např. 172.21.0.16/28)
• Přístup ke zdrojům v privátní síti vyžaduje, aby byl na klientech nainstalován agent zařízení Cloudflare a aby v připojované síti běžel alespoň jeden server Cloudflare Tunnel

U obou metod je důležité mít na paměti, že cloudflared pouze zprostředkovává příchozí provoz do privátní aplikace nebo sítě. Nestává se branou ani „vstupním bodem“ zpět do Cloudflare pro síť, do které zprostředkovává příchozí připojení. To znamená, že pokud webový server naváže vlastní připojení k jinému API na internetu, toto připojení nebude směrováno přes Cloudflare Tunnel, ale přes výchozí trasu a bránu hostitelského serveru.

Ve většině síťových topologií jde o žádoucí stav, existují ale případy, kdy síťové služby potřebují komunikovat přímo se vzdáleně připojeným uživatelem nebo se službami v jiných segmentovaných sítích.

Pokud uživatelé potřebují, aby se připojení vycházející ze serveru nebo sítě směrovala přes Cloudflare, existuje pro to několik vstupních bodů, kterým se podrobněji věnuje část „Connecting Networks“.

SaaS aplikace jsou ze své podstaty vždy připojené k veřejnému internetu a přistupuje se k nim právě přes něj. Výše popsaný přístup s tunelem a app connectorem proto nelze použít. Organizace s architekturou SASE místo toho kontrolují a vynucují zásady pro SaaS provoz směřující na internet pomocí zabezpečená webová brána ↗ (SWG), který slouží jako cloudově nativní forward proxy.

SWG zahrnuje zásady, které kontrolují odchozí požadavky a příchozí odpovědi s obsahem a určují, zda má uživatel, zařízení nebo síťová lokalita přístup ke zdrojům na internetu. Organizace mohou pomocí těchto zásad řídit přístup ke schváleným aplikacím SaaS a zároveň odhalovat a blokovat používání neschválených aplikací (také označovaných jako Shadow IT ↗).

Některé aplikace SaaS umožňují organizacím nastavit seznam povolených IP adres (allowlist), který omezuje přístup k aplikaci podle zdrojové IP adresy požadavku. S Cloudflare mohou organizace získat vyhrazené odchozí IP adresa adres, které lze použít jako zdrojovou adresu pro veškerý provoz opouštějící jejich síť. V kombinaci s allowlistem v SaaS aplikaci tak organizace mohou zajistit, že se uživatelé k aplikacím dostanou pouze v případě, že jsou nejprve připojeni k Cloudflare. (Podrobněji je tento přístup popsán v pozdější části o připojování uživatelských zařízení.)

Další metodou zabezpečení přístupu k aplikacím SaaS je nastavení jednotného přihlašování (SSO) tak, aby se Cloudflare stalo identity proxy, tedy fungovalo jako poskytovatel identity (IDP) v rámci procesu ověřování a autorizace.

Klíčové funkce:

• Uplatňujte jednotné zásady přístupu jak pro vlastní hostované aplikace, tak pro aplikace SaaS
• Zahrňte do procesu ověřování i stav zabezpečení zařízení (uživatelé tak mohou zajistit, že k SaaS aplikacím budou mít přístup jen řízená zařízení s nejnovějším operačním systémem, která splní všechny kontroly zabezpečení koncových bodů)
• Zajistěte, aby se pro přístup používaly jen určené síťové trasy (např. lze vyžadovat, aby zařízení byla ke Cloudflare připojena pomocí device agenta, což umožní filtrovat provoz do SaaS aplikace a zabránit stahování chráněných dat)
• Centralizujte SSO aplikace do Cloudflare a vytvořte jedinou SSO integraci mezi Cloudflare a jejich IdP: infrastruktura i zásady přístupu tak budou nezávislé na konkrétním SSO (uživatelé mohou mít povolený přístup ke kritickým aplikacím například jen při použití MFA, bez ohledu na to, který IdP se pro ověření použije)

Když Cloudflare funguje jako služba SSO pro danou aplikaci, ověřování uživatelů stále zajišťuje stávající poskytovatel identity organizace, provoz je ale směrován přes Cloudflare, kde lze uplatnit další omezení přístupu. Diagram níže ukazuje na vysoké úrovni typický průběh požadavku:

Posledním způsobem, jak připojit aplikace SaaS k architektuře SASE od Cloudflare, je řešení založené na API broker zabezpečeného přístupu do cloudu ↗ (CASB). Cloudflare CASB se integruje přes API s oblíbené SaaS balíčky , mezi něž patří Google Workspace, Microsoft 365, Salesforce a další, a průběžně kontroluje tyto aplikace kvůli chybným konfiguracím, neoprávněné aktivitě uživatelů a dalším bezpečnostním rizikům.

Nativní integrace s Cloudflare prevence úniku dat ↗ (DLP) umožňuje službě CASB prohledávat citlivá nebo regulovaná data, která se mohou nacházet v souborech se špatně nastavenými oprávněními, což dále zvyšuje riziko úniku nebo neoprávněného přístupu. CASB o nalezených případech informuje IT tým, mimo jiné o těchto položkách:

• Administrátorské účty bez adekvátního MFA
• Citlivá firemní data v souborech uložených s veřejnými přístupovými oprávněními
• Chybějící konfigurace aplikací (např. domény bez záznamů SPF/DMARC)

Takto může vypadat architektura typické organizace po integraci se službami Cloudflare. Je důležité si uvědomit, že Cloudflare je navržen tak, aby zabezpečoval stávající aplikace a služby organizací následujícími způsoby:

• Všechny samostatně hostované aplikace a služby jsou přístupné pouze přes Cloudflare a řízené zásadami definovanými v Cloudflare ZTNA
• Provoz SaaS aplikací je filtrován a zabezpečen pomocí Cloudflare SWG
• SaaS služby jsou kontrolovány pomocí Cloudflare CASB, který ověřuje konfiguraci a oprávnění u uložených dat

Jakmile jsou aplikace a služby organizace integrovány, je čas propojit Cloudflare s jejími stávajícími sítěmi. Regionální pobočky, sídlo společnosti, maloobchodní prodejny, datová centra i infrastruktura hostovaná v cloudu musí směrovat provoz do nové firemní sítě SASE.

Když veškerý provoz prochází přes Cloudflare, služby SASE provádějí následující činnosti:

• Udělování přístupu k aplikaci
• Filtrování obecného provozu směřujícího na internet (např. blokování přístupu na weby hostující malware)
• Izolace webů, která chrání uživatele před neznámým škodlivým obsahem na internetu, včetně hrozeb nultého dne
• Filtrování provozu za účelem identifikace dat vymezených zásadami DLP a následné blokování stahování nebo nahrávání těchto dat do nezabezpečených zařízení či aplikací
• Poskytování přehledu o používání neschválených aplikací a možnost pro administrátory tyto aplikace buď blokovat, nebo na jejich používání uplatnit zásady

K připojení sítí ke Cloudflare existuje několik přístupů, které organizaci dávají větší flexibilitu v tom, jak zajistí přístup k prostředkům chráněným pomocí SASE:

1. Pomocí softwarových agentů vytvářejte tunely z hostitelských počítačů zpět do Cloudflare. Tuto metodu obvykle volí uživatelé, kteří vlastní své servery i aplikace.
2. Nastavte tunely IPsec nebo GRE ze síťových routerů a firewallů a připojte je ke službě Cloudflare WAN. Tento přístup volí síťoví administrátoři, když chtějí směrovat provoz do celých sítí a z nich.
3. Přímé připojení sítě k Cloudflare. Tato metoda funguje nejlépe, když síť organizace sídlí v podporovaném datacentru, obvykle takovém, které je kolokováno s datacentrem Cloudflare.

Těmto metodám se podrobněji věnují následující části.

V závislosti na typu aplikací, které se v síti aktuálně nacházejí, existují dva softwarové způsoby připojení sítí ke Cloudflare.

Jak bylo popsáno v předchozí části, cloudflared zprostředkovává požadavky do aplikací a služeb v privátních sítích. Instaluje se na servery v privátní síti a vytváří zabezpečené tunely do Cloudflare přes internet. Tato spojení jsou kvůli spolehlivosti vyvažována mezi více datovými centry Cloudflare a lze je navazovat prostřednictvím více konektorů, což pomáhá zvýšit kapacitu tunelů.

Použití cloudflared, Cloudflare Tunnel podporuje připojení klient-server přes tunel. Jakákoli služba nebo aplikace běžící za tunelem použije při navazování odchozí konektivity výchozí směrovací tabulku.

Tento model je vhodný pro většinu scénářů, kdy externí uživatelé potřebují přistupovat ke zdrojům v privátní síti a komunikace nemusí být iniciována obousměrně.

Pro obousměrnou, respektive meshovou konektivitu by organizace měly používat Cloudflare Mesh.

Cloudflare Mesh (dříve WARP Connector), odlehčené řešení pro obousměrnou konektivitu typu site-to-site i mesh, které nevyžaduje žádné změny ve stávající směrovací infrastruktuře sítě. Cloudflare Mesh se instaluje na server s Linuxem uvnitř sítě organizace, který se pak stává bránou pro další lokální sítě, jež potřebují přivést provoz ke Cloudflare.

Jde o odlehčené řešení pro podporu služeb, jako je Microsoft System Center Configuration Manager (SCCM), aktualizace serverů Active Directory, provoz VOIP a SIP nebo vývojářské workflow s komplexní interakcí CI/CD pipeline. Lze jej provozovat buď jako doplněk k cloudflared a Cloudflare WAN (dříve Magic WAN), nebo může sloužit jako samostatný konektor pro vzdálený přístup a připojení site-to-site k síti Cloudflare.

Cloudflare Mesh dokáže proxy provoz jak pro konektivitu typu user-to-network, tak network-to-network, případně jej lze použít k vytvoření překryvné sítě Carrier Grade NAT (CGNAT ↗) adresovaným koncovým bodům, aby poskytla zabezpečenou přímou konektivitu k existujícím zdrojům pomocí rozsahů CGNAT IP adres. To pomáhá řešit problémy s překrývajícími se rozsahy síťových IP adres, problémy s přístupem u dílčích řešení nebo proces změny návrhu sítě, aniž by to ovlivnilo širší podkladový systém.

Poznámka: popisky na tomto obrázku mohou odpovídat dřívějšímu názvu produktu.

Cloudflare Tunnel přes cloudflared je primární metoda pro připojování uživatelů k aplikacím a službám v privátních sítích, protože jde o jednodušší, podrobnější a agilnější řešení pro řadu vlastníků aplikací (oproti technologii připojení založené na IP tunelech, jako je IPsec ↗ a GRE ↗). Cloudflare Mesh je preferovanou metodou pro mesh nebo jiné softwarově definované sítě, z nichž většina vyžaduje obousměrnou konektivitu, pokud organizace nechtějí měnit stávající směrování sítě nebo edge infrastrukturu.

Tam, kde není instalace softwarových agentů optimální nebo možná, lze sítě ke Cloudflare připojit i pomocí stávajícího síťového vybavení, jako jsou routery a síťové firewally. Organizace k tomu vytvářejí tunely IPsec nebo GRE, které se připojují k cloudově nativní službě Cloudflare WAN ↗ Díky Cloudflare WAN se může stávající síťový hardware připojit a směrovat provoz ze svých síťových lokalit do Cloudflare buď a) přes zabezpečené tunely založené na IPsec vedené přes internet, nebo b) přes Cloudflare Network Interconnect ↗ (CNI): jde o přímá, soukromá připojení, která propojují stávající síťové lokality s nejbližším datovým centrem Cloudflare.

Služba Cloudflare WAN využívá architekturu "light-branch, heavy-cloud", která představuje další vývoj konektivity software-defined WAN (SD-WAN). Jak je vidět na diagramu síťové architektury níže, globální síť Cloudflare funguje u Cloudflare WAN jako centrálně řízený konektivní hub, který bezpečně a efektivně směruje provoz mezi všemi existujícími síťovými lokalitami:

Jak již bylo popsáno, Cloudflare využívá techniku směrování zvanou anycast ↗ ke globální propagaci všech služeb a koncových bodů v síti Cloudflare, včetně koncových bodů pro tunely WAN IP.

S anycast IPsec ↗ nebo anycastové tunely GRE, kdy se každý tunel nakonfigurovaný ze síťového zařízení organizace (například hraničního routeru, firewallového zařízení a podobně) připojuje ke stovkám globálních datových center Cloudflare. Provoz pocházející ze síťové lokality organizace se odesílá přímo přes tyto tunely a vždy je směrován do nejbližšího aktivního datového centra Cloudflare. Pokud není nejbližší datové centrum Cloudflare dostupné, provoz se automaticky přesměruje do dalšího nejbližšího datového centra.

Pro další posílení odolnosti sítě podporuje Cloudflare WAN také směrování Equal Cost Multi-Path (ECMP) mezi sítí Cloudflare a lokalitou (lokalitami) sítě organizace. Díky ECMP lze provoz rozložit mezi více anycastových IP tunelů, což zvyšuje propustnost a maximalizuje spolehlivost sítě. Pokud dojde k výpadku síťové cesty jednoho nebo více tunelů, provoz se automaticky přepne na zbývající funkční tunely.

Nejjednodušším způsobem, jak stávající síťové lokality připojit ke službě Cloudflare WAN, je nasadit Cloudflare One Appliance, lehké zařízení, které lze instalovat ve firemních síťových lokalitách a které automaticky připojuje, směruje a tvaruje veškerý provoz IP přes zabezpečené tunely IPsec. Po instalaci WAN Connector do sítě se automaticky naváže komunikace se sítí Cloudflare, stáhne se a nasadí příslušná konfigurace, vytvoří se odolné tunely IPsec a provoz připojené lokality se začne směrovat do Cloudflare.

WAN Connector lze nasadit jako hardwarové nebo virtuální zařízení, takže je vhodný pro nejrůznější síťová prostředí uživatelů: on-premises, virtuální i veřejný cloud. Správa, konfigurace, sledovatelnost a aktualizace softwaru pro WAN Connector probíhají centrálně z Cloudflare, a to buď přes dashboard, nebo přes Cloudflare API. Od roku 2023 se WAN Connector nejlépe hodí pro připojení malých a středních sítí k Cloudflare (například malých kanceláří a maloobchodních prodejen).

V situacích, kdy nasazení zařízení Cloudflare One Appliance není proveditelné nebo žádoucí, mohou organizace bezpečně připojit své lokální sítě k Cloudflare konfigurací tunelů IPsec ze stávajících síťových zařízení podporujících IPsec, včetně routerů WAN nebo SD-WAN, firewallů a cloudových VPN bran. Další informace najdete v dokumentaci Cloudflare dokumentace s aktuálními příklady ověřených zařízení IPsec.

Mohou nastat i situace, kdy šifrování na síťové vrstvě není nutné, například když je WAN provoz dané pobočky již šifrován na aplikační vrstvě (pomocí TLS), nebo když síťové zařízení IPsec nabízí při šifrování a dešifrování provozu IPsec jen velmi omezenou propustnost. V těchto případech se organizace mohou k síti Cloudflare připojit pomocí Tunely GRE.

Organizace mohou své síťové lokality připojit k síti Cloudflare také přímo prostřednictvím Cloudflare Network Interconnect ↗ (CNI). Cloudflare podporuje celou řadu možností k připojení vaší sítě k Cloudflare:

• Přímé CNI pro Cloudflare WAN a Magic Transit
• Classic CNI pro Magic Transit
• Cloud CNI pro Cloudflare WAN a Magic Transit
• Peering probíhá buď přes internetový uzel, nebo přes privátní síťové propojení (PNI).

Následující tabulka shrnuje jednotlivé způsoby připojení sítí ke Cloudflare:

Všechny tyto metody připojení a směrování provozu lze nasadit současně z libovolné lokality. Následující diagram ukazuje, jak lze různé metody připojení kombinovat v rámci jedné architektury.

Všimněte si následujících toků provozu:

• Veškerý provoz připojený přes uzel Cloudflare Mesh nebo agenta na zařízení může mezi sebou komunikovat přes mesh síť
  • Vývojáři pracující z domova mohou komunikovat s produkčními a staging servery v cloudu
  • Zaměstnanec na prodejně i vývojář pracující z domova mohou přijímat hovory VOIP na svém notebooku
• HPC cluster v AWS představuje proprietární řešení, do kterého nelze instalovat žádné softwarové agenty třetích stran. Proto se pro připojení k Cloudflare WAN používá IPsec
• V maloobchodní pobočce směruje Cloudflare One Appliance veškerý provoz do Cloudflare přes tunel IPsec
  • Notebook zaměstnance se spuštěným agentem na zařízení vytváří vlastní zabezpečené spojení s Cloudflare, které je směrováno přes tunel IPsec
• Vlastník aplikace reportovacího systému udržuje připojení ke Cloudflare pomocí cloudflared a k publikování aplikace pro zaměstnance nepotřebuje žádnou pomoc síťového týmu

Poznámka: popisky na tomto obrázku mohou odpovídat dřívějšímu názvu produktu.

Poznámka: Všem koncovým bodům připojeným přes Cloudflare Mesh nebo device agent jsou automaticky přiřazeny IP adresy z rozsahu 100.96.0.0/12, zatímco koncové body připojené přes Cloudflare WAN si ponechávají své přidělené privátní IP adresy podle RFC1918. cloudflared může vlastník aplikace nasadit na kterémkoli z míst, aby zajistil připojení k aplikaci na základě hostitelského názvu.

Jakmile jsou sítě, aplikace a uživatelská zařízení připojeny ke Cloudflare, lze veškerý provoz bez ohledu na použitou metodu připojení a typ zařízení kontrolovat, ověřovat a filtrovat pomocí služeb Cloudflare SASE a následně ho bezpečně směrovat do cílového místa určení. Napříč veškerým provozem lze navíc uplatňovat jednotné zásady bez ohledu na to, jakým způsobem se ke Cloudflare dostane.

Takto vypadá architektura SASE, ve které je veškerý firemní síťový provoz odkudkoli přesměrován do Cloudflare a tam zpracován. V této architektuře lze navázat síťové připojení z jakékoli vzdálené lokality, pobočky nebo datového centra a připojit se k aplikacím a službám v infrastruktuře SaaS, v cloudové infrastruktuře nebo ve vlastních on-premise datových centrech organizace.

Poznámka: popisky na tomto obrázku mohou odpovídat dřívějšímu názvu produktu.

Předchozí části popisují, jak pomocí ZTNA zabezpečit přístup k vlastním hostovaným aplikacím a jak pomocí SWG kontrolovat a filtrovat provoz směřující do internetu. Když uživatel pracuje na zařízení v některé z firemních sítí připojených ke connectivity cloudu Cloudflare, veškerý tento provoz se kontroluje a uplatňují se na něj zásady, aniž by to narušovalo jeho práci. Uživatelé ale nejsou vždy, nebo vůbec, v kanceláři: pracují z domova, na cestách nebo z jiných veřejných sítí. Jak jim zajistit spolehlivý přístup k interním aplikacím? A jak zajistit, aby bylo jejich procházení internetu bezpečné bez ohledu na to, odkud pracují?

Existuje několik způsobů, jak zajistit, aby byl provoz ze zařízení uživatele, které není připojeno k existující síti chráněné Cloudflare, také směrován přes Cloudflare a byl tak chráněn.

• Nainstalujte agenta na zařízení
• Úprava konfigurace proxy v prohlížeči
• Přesměrujte uživatele na instanci remote browseru
• Úprava konfigurace DNS

Doporučeným způsobem, jak zajistit předávání provozu zařízení do Cloudflare, je instalace agenta zařízení (označovaného také jako Cloudflare One Client). Agent běží na Windows, macOS, Linuxu, iOS a Android/ChromeOS a vytváří zabezpečené připojení ke Cloudflare, kam je odesílán veškerý nelokální provoz. Díky tomu, že Cloudflare využívá anycastové sítě, se agent zařízení vždy připojuje k nejbližšímu serveru Cloudflare, aby uživateli zajistil co nejlepší výkon. Agent zařízení také shromažďuje informace o lokálním počítači a síti, které se odesílají v požadavku, aby obohatily zásadu v Cloudflare.

Aby bylo možné flexibilně připojovat různá zařízení a uživatele, existuje více režimy nasazení:

• Plnohodnotná L4 proxy pro provoz
• L7 DNS proxy
• L7 HTTP proxy
• Možnost pouze shromažďovat informace o stavu zařízení

Organizace mohou mít například pobočku, která nadále používá stávající Filtrování DNS ↗ díky čemuž mohou nakonfigurovat agenta tak, aby pouze přeposílal síťový a HTTP provoz.

Agenta lze také nakonfigurovat s flexibilním řízením směrování, které umožňuje scénáře, kdy provoz určený pro kancelářské tiskárny není odesílán do sítě Cloudflare, ale místo toho je směrován do lokální sítě. Tyto konfigurace rozděleného tunelování lze omezit na konkrétní skupiny uživatelů, typy operačních systémů zařízení nebo sítě, přičemž ve výchozím nastavení je veškerý provoz směřující do všech privátních Rozsahy IPv4 a IPv6 ↗ se odesílá na výchozí gateway zařízení. Pokud aplikace, ke které se uživatel snaží dostat, není ve veřejném DNS, můžete nakonfigurovat, aby se hostitelský název a doména překládaly pomocí místní služby DNS, aby se agent zařízení nesnažil tyto adresy přeložit prostřednictvím DNS Cloudflare.

Agent je víc než jen síťová proxy: dokáže zkontrolovat stav zabezpečení zařízení, například zda je operační systém plně aktuální nebo zda je pevný disk zašifrovaný. Integrace Cloudflare s CrowdStrike ↗, SentinelOne ↗, a dalších služeb třetích stran, které rovněž poskytují další údaje o stavu zabezpečení zařízení. Všechny tyto informace jsou přiřazeny ke každému požadavku, a jsou tak k dispozici pro použití ve firemních zásadách, jak je popsáno v části „Unified Management“.

Agenta lze nasazeno na zařízení, a to buď ručně, nebo pomocí stávajících technologií pro správu koncových zařízení (UEM). Pomocí agenta uživatelé registrují a ověřují své zařízení vůči Cloudflare prostřednictvím integrovaných poskytovatelů identity. Informace o identitě, zkombinované s informacemi o lokálním zařízení, se poté používají ve vašich politikách SWG a ZTNA (včetně inline funkcí CASB sdílených napříč těmito službami Cloudflare).

Pokud na zařízení není možné nainstalovat software, existují i přístupy bez agenta.

Jednou z možností je nakonfigurovat prohlížeč tak, aby předával HTTP požadavky do Cloudflare, a to nastavením údajů proxy serveru v prohlížeči nebo operačním systému. Ačkoli to lze provést ručně, organizace obvykle konfiguraci nastavení proxy prohlížeče automatizují pomocí Automatická konfigurace proxy (PAC). Prohlížeč umí umístění souboru PAC zjistit několika způsoby:

• Software MDM konfigurující toto nastavení v prohlížeči
• Ve Windows doménách mohou objekty zásad skupiny (GPO) nakonfigurovat soubor PAC prohlížeče
• Prohlížeče mohou používat Web Proxy Auto-Discovery ↗ (WPAD)

Odtud nakonfigurujte proxy endpoint, na který bude prohlížeč odesílat všechny požadavky HTTP. Pokud tuto metodu použijete, mějte na paměti, že:

• Filtrování provozu HTTPS bude také vyžadovat instalace kořenových certifikátů Cloudflare a jejich označení jako důvěryhodných na zařízeních.
• Proxy koncový bod přeposílá pouze provoz pocházející ze sady známých IP adres, například z fondu veřejných IP adres používaných NAT branou dané lokality, které musí administrátor předem specifikovat.

Další možností, jak zajistit, že provoz ze zařízení směřuje do Cloudflare, je použít vzdálená izolace prohlížeče ↗ (RBI). Když se vzdálený uživatel pokusí navštívit web, odpovídající požadavky a odpovědi zpracovává headless vzdálený prohlížeč běžící v síti Cloudflare, který funguje jako „klon“ lokálního prohlížeče uživatelova zařízení. Zařízení uživatele je tak chráněno před případným škodlivým obsahem a spuštěním kódu, který by se z navštíveného webu mohl stáhnout.

RBI vykresluje přijatý obsah v izolovaném a zabezpečeném cloudovém prostředí. Namísto spouštění webového obsahu lokálně dostává zařízení uživatele pokyny, jak přesně „vykreslit“ výslednou webovou stránku, a to prostřednictvím vysoce optimalizovaného protokolu, který podporují všechny prohlížeče kompatibilní s HTML5 na všech operačních systémech. Protože vzdálený prohlížeč běží na serverech Cloudflare, uplatňují se na všechny požadavky prohlížeče automaticky zásady SWG.

Zabezpečení přístupu k webům pomocí RBI nevyžaduje instalaci žádného lokálního softwaru ani úpravu uživatelova prohlížeče. Níže jsou uvedeny několik způsobů k dosažení tohoto cíle:

• Relace vzdáleného prohlížeče se obvykle spouští v důsledku zásady SWG: uživatel jednoduše požaduje webové stránky, aniž by byl upozorněn, že se obsah načítá ve vzdáleném prohlížeči.
• Organizace mohou uživatelům také poskytnout odkaz, který automaticky zajistí, že každý požadavek vždy zpracuje RBI.
• Organizace se také mohou rozhodnout použít službu ZTNA k přesměrování veškerého provozu z vlastních hostovaných aplikací přes instance RBI.

Všechny požadavky přes vzdálený prohlížeč procházejí přes Cloudflare SWG, díky čemuž mohou zásady vynucovat určitá omezení přístupu na weby. Zásady izolace prohlížeče lze například nastavit tak, aby:

• Zakažte kopírování a vkládání mezi vzdálenou webovou stránkou a lokálním počítačem uživatele. Zabráníte tak zaměstnancům vkládat firemní kód do chatbotů třetích stran.
• Zakažte tisk vzdáleného webového obsahu, aby externí spolupracovníci nemohli vytisknout důvěrné informace
• Zakažte nahrávání a stahování souborů, abyste zajistili, že citlivá firemní data nebudou odesílána na určité weby ani z nich stahována.
• Zakažte vstup z klávesnice (v kombinaci s dalšími zásadami), abyste omezili únik dat, například když někdo zadá heslo na phishingovém webu.

Izolace webových aplikací a uplatňování zásad na rizikové weby pomáhá organizacím omezit únik dat způsobený kybernetickými hrozbami nebo chybou uživatele. Stejně jako mnoho dalších funkcí Cloudflare One lze RBI využít i v dalších oblastech architektury SASE. Řešení Cloudflare zabezpečení e-mailu ↗ může například automaticky přepisovat a izolovat podezřelé odkazy v e-mailech. Tato funkce „izolace e-mailových odkazů“ pomáhá chránit uživatele před potenciálně škodlivou aktivitou, jako je phishing zaměřený na krádež přihlašovacích údajů.

Další možností zabezpečení provozu přes síť Cloudflare je nastavit zařízení tak, aby přeposílalo provoz DNS do Cloudflare ke kontrole a filtrování. Nejprve Lokality DNS se vytvářejí tak, aby bylo možné uplatňovat zásady podle různých síťových lokalit. Lze je určit buď podle zdrojové IP adresy požadavku, nebo lze použít "DNS over TLS ↗" nebo "DNS over HTTPS ↗".

Při použití zdrojových IP adres je nutné buď zařízení nastavit, které servery DNS má používat, nebo zajistit, aby místní server DNS v síti, k níž je zařízení připojeno, přeposílal všechny dotazy DNS na Cloudflare. Pro podporu DNS over TLS nebo DNS over HTTPS je nutné zařízení nakonfigurovat a míra podpory se liší. Doporučujeme používat DNS over HTTPS, které má širší podporu napříč operačními systémy.

Všechny výše uvedené metody mají za důsledek to, že se do Cloudflare odesílají pouze požadavky DNS, nikoli veškerý provoz. Zásady SWG DNS se pak uplatňují na této úrovni a řídí přístup k firemním síťovým zdrojům.

Následující tabulka shrnuje možnosti SWG pro jednotlivé způsoby předávání provozu do Cloudflare (stav k říjnu 2023):

Poznámky:

1. Provoz agenta zařízení v režimu DNS over HTTP poskytuje navíc i informace o identitě uživatele, a to při zachování stejných možností jako u připojení přes DNS.
2. Pro filtrování provozu HTTPS Cloudflare certifikát je nutné nainstalovat na každé zařízení. Při použití agenta zařízení to lze automatizovat.
3. Při konfiguraci DNS over HTTPS je možné vložit token služby do požadavku, což dotaz přiřadí k ověřenému uživateli.

Připojením celých sítí nebo jednotlivých zařízení mohou organizace nyní směrovat uživatelský provoz do Cloudflare, a zajistit tak bezpečný přístup k privátně hostovaným aplikacím i k veřejnému internetu.

Jakmile je provoz ze všech uživatelských zařízení směrován do sítě Cloudflare, je čas, aby organizace přehodnotily svou architekturu SASE na vysoké úrovni:

Poznámka: popisky na tomto obrázku mohou odpovídat dřívějšímu názvu produktu.

V této fázi zavádění architektury SASE už organizace dokážou směrovat a zabezpečovat provoz od okamžiku, kdy požadavek vznikne v prohlížeči na zařízení uživatele, až po jeho cestu sítí Cloudflare k firemní privátní aplikaci či službě, nebo k veřejnému internetu.

Než ale organizace definují zásady pro správu tohoto přístupu, potřebují vědět, kdo požadavek podává, a určit bezpečnostní stav daného zařízení.

Prvním krokem při jakémkoli rozhodování o přístupu je zjistit, kdo požadavek vytváří, tedy ověřit uživatele.

Cloudflare se integruje s poskytovateli identity, kteří spravují zabezpečený přístup k prostředkům pro zaměstnance, dodavatele, partnery a další uživatele organizací. To zahrnuje podporu integrace s jakýmkoli SAML - nebo OpenID Connect (OIDC) vyhovující službou. Cloudflare One také obsahuje předpřipravené integrace s Okta, Microsoft Entra ID (dříve Azure Active Directory), Google Workspace, a také spotřebitelské poskytovatele identity (IdP), jako například Facebook, GitHub a LinkedIn.

Integrovat lze více IdP, díky čemuž mohou organizace uplatňovat zásady na širokou škálu interních i externích uživatelů. Když se uživatel pokusí přistoupit k aplikaci nebo službě zabezpečené Cloudflare, je přesměrován k ověření prostřednictvím jednoho z integrovaných IdP. Při použití device agenta se uživatelé musí ověřit i vůči jednomu z IdP nakonfigurovaných v jejich organizaci.

Jakmile je uživatel ověřen, Cloudflare obdrží jeho informace, například uživatelské jméno, členství ve skupinách, metodu ověření (heslo, zda a jaký typ MFA byl použit) a další přidružené atributy (např. roli uživatele, oddělení nebo umístění kanceláře). Tyto informace z IdP jsou poté zpřístupněny modulu zásad (policy engine).

Kromě uživatelských identit obsahuje většina firemních adresářů i skupiny, jejichž jsou tyto identity členy. Cloudflare podporuje import informací o skupinách, které se pak využívají jako součást zásad. Členství ve skupině je klíčovým prvkem pro agregaci jednotlivých identit tak, aby zásady mohly být méně složité. Je totiž mnohem jednodušší nastavit zásadu umožňující všem zaměstnancům z obchodního oddělení přístup k Salesforce, než identifikovat každého jednotlivého uživatele v obchodní organizaci.

Cloudflare také podporuje autentizaci zařízení, která obvykle nejsou spojena s konkrétním uživatelem, například zařízení IoT sledující povětrnostní podmínky v továrně. Pro tato zabezpečená spojení mohou organizace vygenerovat service tokeny nebo vytvořit Mutual TLS ↗ (mTLS), které lze nasadit do takových zařízení nebo aplikací typu machine-to-machine.

Je potřeba ověřit nejen identitu uživatele, ale posoudit i bezpečnostní stav jeho zařízení. Device agent dokáže poskytnout řadu informací o zařízení, které Cloudflare využívá k sestavení komplexních bezpečnostních zásad.

K dispozici jsou tyto vestavěné kontroly stavu zařízení (posture checks):

• Kontrola aplikace: Kontroluje, zda běží konkrétní proces aplikace
• File check: Kontroluje přítomnost souboru
• Firewall: Kontroluje, zda běží firewall
• Šifrování disku: Kontroluje, zda a kolik disků je zašifrovaných
• Domain Joined: Kontroluje, zda je zařízení připojeno k doméně Microsoft Active Directory
• Verze OS: Kontroluje, jaká verze operačního systému běží
• Unique Client ID: Při použití nástroje MDM mohou organizace přiřadit mobilnímu, stolnímu nebo přenosnému zařízení ověřitelné UUID
• Sériové číslo zařízení: Kontroluje, zda sériové číslo zařízení odpovídá seznamu firemních stolních nebo přenosných počítačů

Cloudflare One lze také integrovat s libovolným nasazeným řešením zabezpečení koncových bodů, například s Microsoft Endpoint Manager, Tanium, Carbon Black, CrowdStrike, SentinelOne, a dalších. Data z těchto produktů lze předat Cloudflare a využít je při rozhodování o přístupu.

Všechny výše uvedené informace o zařízení, spolu s údaji o identitě uživatele a síti, ve které se zařízení nachází, jsou v Cloudflare k dispozici jako součást firemní zásady. Organizace se například mohou rozhodnout povolit administrátorům přístup k serverům přes SSH pouze tehdy, když jsou splněny všechny tyto podmínky: zařízení je bez hrozeb, používá nejnovější operační systém a je připojeno k firemní doméně.

Protože jsou tyto informace k dispozici u každého síťového požadavku, jakákoli změna device posture okamžitě ovlivní možnost zařízení připojit se ke zdrojům organizace.

E-mail, nejpoužívanější komunikační nástroj mnoha organizací a nejčastější kanál pro phishingové útoky, je dalším důležitým firemním prostředkem, který by měl být zabezpečený prostřednictvím architektury SASE. Phishing stojí za více než 90 % úniků dat, které vedou k finančním ztrátám a poškození značky.

Služba zabezpečení e-mailu od Cloudflare vyhledává známky škodlivého obsahu nebo příloh dříve, než se dostanou do schránky, a zároveň proaktivně prochází internet a hledá infrastrukturu útočníků a mechanismy pro doručování útoků, včetně programově vytvářených domén používaných k hostování obsahu v rámci plánovaného útoku. Všechna tato data naše služba využívá také k ochraně před napadením firemní a dodavatelské e-mailové komunikace (BEC ↗ / VEC ↗), které je notoricky obtížné odhalit, protože neobsahují žádný škodlivý obsah a dokážou vypadat jako legitimní e-mailový provoz.

Místo nasazování tunelů pro správu a řízení provozu k e-mailovým serverům nabízí Cloudflare dvě metody zabezpečení e-mailu nastavení:

• Inline: Přesměrování veškeré příchozí e-mailové komunikace přes Cloudflare ještě před doručením do schránky uživatele, a to úpravou záznamů MX
• API: Přímá integrace Cloudflare s poskytovatelem e-mailu, jako je Microsoft 365 nebo Gmail

Úprava záznamů MX (nasazení inline) vynutí, aby veškerý příchozí e-mailový provoz procházel přes naši cloudovou službu zabezpečení e-mailu, kde je skenován a v případě, že je vyhodnocen jako škodlivý, zablokován ještě před doručením do schránky uživatele. Protože služba funguje na úrovni záznamů MX, je možné službu zabezpečení e-mailu použít s jakýmkoli kompatibilní se SMTP ↗ e-mailové služby.

Organizace se také mohou rozhodnout integrovat zabezpečení e-mailu přímo se svou e-mailovou službou prostřednictvím API. Tento přístup má dvě nevýhody: Cloudflare pro něj podporuje méně integrací a mezi doručením e-mailu do služby a jeho zjištěním ze strany Cloudflare přes API vždy vzniká malé zpoždění.

Výše uvedené kroky dávají ucelený přehled o přechodu na architekturu SASE pomocí Cloudflare One. Jak ukazuje diagram níže, zabezpečený přístup ke všem privátním aplikacím, službám a sítím, stejně jako zabezpečení běžného přístupu uživatelů k internetu, se nyní vztahuje na všechny uživatele organizace, interní i externí.

Poznámka: popisky na tomto obrázku mohou odpovídat dřívějšímu názvu produktu.

Pro snadné použití lze celou platformu Cloudflare One nakonfigurovat prostřednictvím API; a s Cloudflare Terraform provider ↗, organizace mohou spravovat globální síť Cloudflare pomocí stejných nástrojů, jaké používají k automatizaci zbytku své infrastruktury. Díky tomu mohou IT týmy plně spravovat svou infrastrukturu Cloudflare One, včetně všech zásad popsaných v další části, pomocí kódu. K dispozici je také (k říjnu 2023) více než 500 GitHub ↗ repozitářů, z nichž mnohé umožňují IT týmům používat a vytvářet nástroje pro správu jejich nasazení Cloudflare.

Jakmile jsou všichni uživatelé, zařízení, aplikace, sítě a další komponenty plně integrováni do architektury SASE, poskytuje Cloudflare One centralizovanou platformu pro jejich komplexní správu. Díky přehledu, který má Cloudflare napříč celou IT infrastrukturou, dokáže agregovat signály z různých zdrojů, včetně zařízení, uživatelů a sítí. Tyto signály pak mohou sloužit jako podklad pro tvorbu zásad, které řídí přístup k prostředkům organizace.

Než se pustíme do podrobností o tom, jak psát zásady pro řízení přístupu k aplikacím, službám a sítím připojeným k Cloudflare, stojí za to podívat se na dva hlavní kontrolní body platformy SASE od Cloudflare, které přístup řídí: SWG a služby ZTNA. Obě tyto služby se konfigurují přes jediný administrativní dashboard, což zjednodušuje správu zásad v celém nasazení SASE.

Následující diagram znázorňuje průběh požadavku jednotlivými službami, včetně uplatnění zásad a zdroje dat pro tyto zásady. Na diagramu níže může požadavek uživatele vstupovat buď přes SWG, nebo přes ZTNA, podle typu požadované služby. Obě služby lze také kombinovat, například zavedením zásady SWG HTTP, která využívá službu DLP k inspekci provozu směřujícího k privátně hostované aplikaci za Cloudflare Tunnel typu ZTNA. Taková konfigurace umožňuje organizacím blokovat stahování citlivých dat z interních aplikací, k nimž povolily externí přístup.

V následujících částech uvádíme příklady, jak lze nakonfigurovat různé zásady pro konkrétní případy použití. Tyto příklady nejsou vyčerpávající, jejich cílem je ukázat běžné způsoby konfigurace Cloudflare One při řešení problémů, se kterými se organizace potýkají při přechodu na architekturu SASE.

Připojení IdP ke Cloudflare umožňuje rozhodovat o přístupu na základě faktorů, jako je členství ve skupině, metoda ověřování nebo konkrétní atributy uživatele. Agent zařízení Cloudflare navíc poskytuje další signály pro posuzování zásad, například kontrolu operačního systému nebo ověření sériového čísla zařízení oproti zařízením spravovaným firmou. Existují však funkce, díky nimž mohou uživatelé do nasazení zapojit další data a vytvářet tak účinnější zásady.

Rozsáhlá inteligentní síť Cloudflare nepřetržitě monitoruje miliardy webových zdrojů a kategorizuje je na základě našich informací o hrozbách (threat intelligence) a obecných znalostí o obsahu internetu. Můžete použít náš bezplatný Cloudflare Radar ↗ ke zjištění, jaké kategorie lze přiřadit ke konkrétní doméně. Politiky pak mohou tyto kategorie využít k blokování známých i potenciálních bezpečnostních rizik na veřejném internetu i konkrétních kategorií obsahu.

SWG od Cloudflare navíc nabízí flexibilitu při vytváření a správě vlastních seznamy dat. Tyto seznamy lze nahrát pomocí souborů CSV, spravovat ručně nebo integrovat s dalšími procesy a aplikacemi prostřednictvím Cloudflare API. Seznam může obsahovat tato data:

• Adresy URL
• Hostname
• Sériová čísla (macOS, Windows, Linux)
• E-maily
• IP adresy
• ID zařízení (iOS, Android)

Organizace si mohou například vést seznam IP adres všech vzdálených poboček, e-mailových adres krátkodobých dodavatelů nebo důvěryhodných firemních domén. Tyto seznamy lze použít v zásadách k tomu, aby dodavatelům umožnily přístup ke konkrétní aplikaci, pokud jejich provoz přichází ze známé IP adresy pobočky.

Cloudflare posuzuje různé aspekty požadavku, včetně zdrojové IP adresy, požadované domény a identity ověřeného uživatele, který požadavek zadal. Cloudflare také nabízí službu DLP, která dokáže detekovat a blokovat požadavky na základě přítomnosti citlivého obsahu. Služba obsahuje vestavěné profily DLP pro běžné typy dat, jako jsou finanční informace, osobní údaje (PII) a API klíče.

K dispozici je dokonce profil pro zdrojový kód, díky kterému lze detekovat a blokovat přenos souborů C++ nebo Python. Organizace si mohou vytvořit vlastní profily DLP a pomocí regulárních výrazů definovat vzory dat, která hledají. Pro data, u kterých je obtížné vzor definovat, lze použít datové sady, které porovnávají přesné hodnoty dat. Do těchto datových sad lze hromadně nahrát libovolná data k porovnání, například seznamy ID zákaznických účtů nebo názvy citlivých projektů. Tyto profily a datové sady lze zapracovat do zásad, které uživatelům zabrání stahovat velké soubory obsahující důvěrná data zákazníků.

Ke snížení rizika falešně pozitivních výsledků mohou interní uživatelé u profilu nastavit minimální počet shod. To znamená, že k aktivaci profilu je zapotřebí určitý počet shod v datech. Tento přístup zabraňuje situacím, kdy by profil zbytečně spustil náhodný řetězec podobný osobním údajům (PII) nebo číslu platební karty. Díky nastavení minimálního počtu shod zásada vyžaduje, aby profilu odpovídalo více datových prvků současně, čímž se výrazně zvyšuje její přesnost.

Organizace mohou přesnost profilu DLP dále zvýšit povolením kontextové analýzy. Tato funkce vyžaduje, aby se v okruhu přibližně 1000 znaků od shody nacházela určitá klíčová slova. Například řetězec "123-45-6789" se bude počítat jako detekce pouze v případě, že se nachází v blízkosti klíčových slov jako "ssn". Tento kontextový požadavek zvyšuje přesnost procesu detekce.

Služba DLP se bez problémů integruje jak se službou Cloudflare SWG, tak se službami CASB řízenými přes API. V případě API CASB se profily DLP vybírají pro skenování každé integrace s jednotlivými aplikacemi SaaS. Toto přizpůsobení umožňuje nastavit kritéria detekce na míru podle typu dat, která chcete v dané aplikaci chránit.

U služby SWG lze do libovolné zásady zahrnout profily DLP, které v jakémkoli požadavku procházejícím branou detekují přítomnost citlivých dat. Nejběžnější akcí spojenou s touto detekcí je zablokování požadavku, což poskytuje silnou vrstvu zabezpečení.

Access Groups jsou v rámci služby ZTNA výkonným nástrojem pro sdružování uživatelů nebo zařízení do jednotné entity, na kterou lze odkazovat v rámci politiky. V Cloudflare lze do jedné Access Group zkombinovat více informací, což umožňuje efektivně opakovaně využívat data ve více politikách a přitom je udržovat na jednom centralizovaném místě.

Představte si skupinu Access Group určenou ke správě přístupu ke kritické serverové infrastruktuře. Stejnou skupinu Access Group lze použít i v zásadě agenta zařízení, která administrátorům znemožní vypnout připojení ke Cloudflare. Tento přístup zjednodušuje správu zásad a zajišťuje jejich jednotné uplatnění napříč různými implementacemi.

Níže je diagram s Access Group nazvanou "Secure Administrators", která pomocí řady atributů definuje vlastnosti zabezpečených administrátorů. Diagram ukazuje přidání dvou dalších Access Group do skupiny "Secure Administrators". Tyto skupiny zahrnují zařízení s nejnovější verzí Windows nebo macOS a požadavek, aby zařízení mělo povolený FileVault nebo Bitlocker.

V souladu s celkovou flexibilitou Cloudflare lze skupiny Access Groups vytvářet, upravovat a přiřazovat k zásadám přes Cloudflare API nebo pomocí Terraformu. Díky tomu se snadno integrují se stávajícími IT systémy a procesy a zajišťují jednotný přístup ke správě přístupu.

Nyní, když máme jasnou představu o všech dostupných komponentách, se blíže podíváme na několik běžných případů použití a na to, jak se konfigurují. Mějte na paměti, že mechanismy zásad Cloudflare jsou nesmírně výkonné a flexibilní, takže tyto příklady představují jen zlomek možností platformy Cloudflare SASE.

Jedním z běžných důvodů přechodu na architekturu SASE je nahrazení stávajícího VPN připojení flexibilnějším a bezpečnějším řešením. Architektura Cloudflare One SASE umožňuje vysoce výkonný a bezpečný přístup k vlastním hostovaným aplikacím odkudkoli na světě. Dalším krokem je ale definování zásad, které řídí přístup k prostředkům.

V tomto příkladu uvažujme dvě služby: aplikaci pro správu databáze (pgadmin ↗ například) a démon SSH běžící na databázovém serveru. Následující diagram znázorňuje tok provozu a zvýrazňuje službu ZTNA. Je důležité poznamenat, že všechny ostatní služby si i nadále zachovávají schopnost daný požadavek zkontrolovat. Dodavatel používající svůj osobní mobilní telefon v Německu by tak měl mít přístup pouze ke správcovskému nástroji databáze, zatímco zaměstnanec na spravovaném zařízení může přistupovat jak ke správcovskému nástroji databáze, tak se připojit přes SSH k databázovému serveru.

Zásady, které přístup umožňují, se opírají o dvě Access Groups.

• Dodavatelé
  • Uživatelé, kteří se ověřují přes Okta a jsou součástí skupiny Okta označené „Contractors“
  • Ověření vyžaduje použití hardwarového tokenu
• Databázoví a IT administrátoři
  • Uživatelé, kteří se ověřují přes Okta a jsou ve skupinách Okta „IT administrators“ nebo „Database administrators“
  • Ověření vyžaduje použití hardwarového tokenu
  • Uživatelé by měli mít zařízení se sériovým číslem v seznamu „Managed Devices“

Obě tyto skupiny se pak používají ve dvou různých zásadách přístupu.

• Přístup k nástroji pro správu databází
  • Databázoví a IT administrátoři mají povolený přístup
  • Členové přístupové skupiny "Contractor" mají přístup povolen, ale každá ověřená relace vyžaduje, aby uživatel vyplnil žádost o zdůvodnění
  • Administrační nástroj se vykresluje v izolovaném prohlížeči v edge síti Cloudflare a stahování souborů je zakázáno
• SSH přístup k databázovému serveru
  • Skupina "Database and IT administrators" má povolený přístup
  • Jejich zařízení musí splňovat minimální rizikové skóre Crowdstrike ve výši 80
  • Přístup musí pocházet ze zařízení, na kterém běží náš agent zařízení a které je připojené k Cloudflare

Tyto zásady ukazují, že dodavatelé mají přístup pouze k nástroji pro správu databáze a nemají přístup k serveru přes SSH. IT administrátoři a správci databáze mohou ke službě SSH přistupovat pouze tehdy, pokud jsou jejich zařízení bezpečně připojena ke Cloudflare přes agenta zařízení. Každý prvek skupin přístupu a zásad se vyhodnocuje při každém přihlášení, takže IT administrátorovi s kompromitovaným notebookem nebo dodavateli, který se nedokáže ověřit hardwarovým tokenem, bude přístup zamítnut.

Obě skupiny uživatelů se připojí ke Cloudflare přes nejbližší a nejrychlejší přístupový bod globálně distribuované sítě Cloudflare, což zajišťuje kvalitní zážitek pro všechny uživatele bez ohledu na to, kde se nacházejí.

Dalším důvodem pro použití řešení SASE je jednotné uplatňování firemních bezpečnostních zásad u všech uživatelů (ať jde o zaměstnance, nebo dodavatele) v organizaci, bez ohledu na to, kde pracují. Architektura Cloudflare One SASE ukazuje, že veškerý provoz uživatelů, ať je směrován přímo ze zařízení, nebo přes připojenou síť, prochází přes Cloudflare. Kontrolu tohoto provozu pak provádí SWG Cloudflare. V závislosti na metodě připojení lze zásady uplatňovat buď na požadavky HTTP, nebo DNS. Například:

To lze následně uplatnit v jedné zásadě k zabezpečení a ochraně všech uživatelů. Cloudflare může vytvořit další zásadu, která povolí přístup na weby sociálních sítí a zároveň izoluje všechny relace ve vzdáleném prohlížeči hostovaném v síti Cloudflare.

Při tomto nastavení zajišťuje každý požadavek na web sociální sítě následující bezpečnostní opatření:

• Jakýkoli obsah na webu sociální sítě obsahující škodlivý kód se na lokálním zařízení nespustí
• Externí uživatelé nemohou z webu stahovat obsah, který by mohl být infikován malwarem nebo spywarem

Cloudflare One má přehled o každém síťovém požadavku, díky čemuž může Cloudflare vytvářet zásady platné pro data v daném požadavku. Služby DLP tak lze použít k detekci stahování obsahu z aplikace a k jeho blokování pro konkrétní skupiny uživatelů. Podívejme se na následující zásadu.

Tato zásada by externím dodavatelům zabránila stáhnout soubor s informacemi o zákaznických účtech. Cloudflare navíc umožňuje nastavit další zásadu, která totéž stažení zablokuje, pokud zařízení uživatele nesplňuje konkrétní požadavky na stav zabezpečení. Tím se důsledně prosazuje jednotné pravidlo: citlivá zákaznická data nelze stáhnout na zařízení, které nesplňuje požadované bezpečnostní standardy.

Zásady DLP lze uplatnit i opačným směrem, aby citlivé firemní dokumenty nebyly nahrávány do neschváleného cloudového úložiště nebo na sociální sítě.

V této fázi cesty k SASE už uživatelé přebudovali síťovou a bezpečnostní infrastrukturu IT tak, aby naplno využívali všechny možnosti platformy Cloudflare One SASE. Klíčovým prvkem dlouhodobého nasazení je zajištění úplné přehlednosti napříč organizací a schopnost problémy rychle diagnostikovat a řešit.

Pro rychlou analýzu poskytuje Cloudflare vestavěné dashboardy a analytiku, které nabízejí denní přehled provozního stavu nasazení. Jakmile provoz prochází přes Cloudflare, dashboard upozorní interní uživatele na nejčastěji používané SaaS aplikace, což umožňuje rychle zasáhnout, pokud k neautorizovaným aplikacím přistupují externí uživatelé. Veškeré protokolové informace ze všech služeb Cloudflare One jsou navíc dostupné a prohledávatelné přímo v dashboardu administrátora. Díky tomu lze efektivně filtrovat konkrétní blokované požadavky, přičemž každý záznam obsahuje užitečné informace, jako je identita uživatele, informace o zařízení a konkrétní pravidlo, které blokování vyvolalo. To se hodí zejména v raných fázích nasazení, kdy je často potřeba pravidla doladit.

Řada organizací se však při dlouhodobém sledování výkonu své infrastruktury spoléhá na již zavedené specializované nástroje. Cloudflare to podporuje tím, že umožňuje export veškerých protokolových informací do těchto nástrojů. Každý aspekt Cloudflare One se zaznamenává a lze jej exportovat. Cloudflare nabízí vestavěné integrace pro průběžný přenos malých dávek dat do řady platforem, včetně AWS, Google Cloud Storage, SumoLogic, Azure, Splunk, Datadog a libovolné služby kompatibilní s S3. Díky této flexibilitě si organizace mohou vybrat konkrétní pole, a tak řídit typ a objem dat začleňovaných do stávajících nástrojů.

Kromě protokolů týkajících se provozu a zásad Cloudflare auditu podléhá také správní činnost. Zaznamenávají se všechny administrativní úkony a změny v Cloudflare Tunnels. To umožňuje audit řízení změn a stejně jako u ostatních protokolů je lze exportovat do dalších nástrojů jako součást širšího řešení pro monitorování řízení změn.

Cloudflare má podrobný přehled ↗ do výkonu internetu a připojených sítí a zařízení. Tyto znalosti dávají IT administrátorům přehled o zkušenostech koncových uživatelů v jednotlivých minutách a umožňují rychle řešit problémy, které ovlivňují produktivitu.

Služba Digital Experience Monitoring (DEM) umožňuje IT oddělení průběžně testovat uživatelská zařízení a zjišťovat kvalitu připojení k firemním prostředkům. Výsledky těchto testů jsou dostupné na dashboardu Cloudflare One, což IT administrátorům umožňuje zjišťovat a řešit příčiny potíží, se kterými se konkrétní uživatel setká při přístupu k aplikaci. Tyto potíže mohou pramenit z lokálního poskytovatele internetu uživatele nebo z konkrétní nedostatečně výkonné služby SaaS. Tato data jsou pro administrátory neocenitelná při diagnostice a řešení špatné uživatelské zkušenosti, což vede k rychlejšímu vyřešení problémů.

Dashboard zobrazuje komplexní přehled celé flotily zařízení a zobrazuje metriky připojení v reálném čase i historické metriky pro všechna zařízení organizace. Správci IT se poté mohou u konkrétních zařízení ponořit do podrobnější analýzy.

Nyní, když důkladně rozumíte platformě Cloudflare SASE, jste dobře připraveni na její integraci se stávající infrastrukturou. Tento systém efektivně zabezpečuje přístup k aplikacím jak pro zaměstnance, tak pro externí uživatele, a to od prvotního požadavku na zařízení až po jeho doručení k aplikaci bez ohledu na její umístění. Tento výkonný nový model zabezpečení sítí, aplikací, zařízení a uživatelů staví na rozsáhlé síti Cloudflare a spravuje se prostřednictvím přehledného správcovského rozhraní.

Za zmínku stojí, že mnohé z funkcí popsaných v tomto dokumentu lze pro až 50 uživatelů používat zdarma a bez časového omezení. Zaregistrovat se ↗ pro účet a přejděte do Cloudflare One ↗ sekci. Tento dokument poskytl přehled platformy jako celku, a pokud se chcete blíže věnovat konkrétním oblastem, doporučujeme prostudovat následující zdroje.

Pokud byste chtěli podrobněji probrat své požadavky na SASE a spojit se s jedním z našich architektů, navštivte https://www.cloudflare.com/cloudflare-one/ ↗ a požádejte o konzultaci.