← Referenční architektury / reference-architecture / design-guides

Síťově orientovaná migrace z VPN koncentrátorů na Zero Trust Network Access

V posledních letech už tradiční přístup, tedy instalace a údržba hardwaru pro vzdálený přístup k privátním firemním sítím, není ani bezpečný, ani nákladově efektivní. Vzhledem k nárůstu zranitelnosti ↗ u lokálních (on-premises) VPN produktů, bezpečnostní a IT týmy hledají řešení, u kterých nemusí týmy sledovat a reagovat na Upozornění na CVE ↗. Tyto systémy navíc omezují šířku pásma uživatele, protože veškerý jeho internetový provoz směrují přes jedinou infrastrukturu, což vede ke špatné uživatelské zkušenosti. IT týmy si uvědomují, že náklady a úsilí spojené s instalací a údržbou vlastního hardwaru lze nahradit modernějšími a bezpečnějšími cloudovými službami. Nároky uživatelů na výkon aplikací zároveň odhalují limity vlastních VPN řešení omezených šířkou pásma. Provozovat vlastní VPN je tedy nákladné, rizikové a nenabízí dobrou uživatelskou zkušenost.

Řada organizací proto směřuje k zero trust ↗ bezpečnostní stav pomocí Zero Trust Network Access ↗ (ZTNA) v rámci Secure Access Service Edge ↗ (SASE) pro vzdálený přístup k soukromým prostředkům. Díky tomu, že veškerý klíčový software běží jako cloudová služba, organizace už nemusí samy udržovat servery a software aktuální. Cloudové platformy jsou navíc navržené pro obrovské škálování, což výrazně zvyšuje dostupnou šířku pásma pro koncové uživatele a zlepšuje tak jejich zkušenost.

Ve starém modelu měl VPN hardware přímý přístup k sítím, na kterých aplikace běžely, a uživatelé měli obvykle přístup k celé síti. Nové metody vzdáleného přístupu SASE vytvářejí konektivitu z cloudové platformy do sítí, kde aplikace běží, ale zpřístupňují pouze konkrétní aplikaci nebo síťovou adresu. Cloudflare doporučuje instalovat softwarové agenty, podobné těm na zařízeních koncových uživatelů, které vytvářejí zabezpečené tunely z cloudu do privátních sítí. Tato cesta ale není vždy snadná. Síťoví administrátoři, kteří chtějí rychle nahradit starší hardware pro vzdálený přístup, nemusí stihnout v přijatelném čase nasadit nové servery nebo projít zdlouhavým procesem řízení změn potřebným k nasazení softwaru na stávající aplikační servery. Místo toho mohou lépe znát a mít větší kontrolu nad vytvářením zabezpečených tunelů z cloudových platforem SASE do stávajícího síťového hardwaru pomocí známých protokolů, jako je GRE nebo IPsec. To může dokonce znamenat použití stejných hardwarových zařízení, jaká se používala pro přístup VPN, jen se sníženou funkcionalitou na zabezpečené tunelové konektory, přičemž se vypnou (nebo se u nich odeberou licence na) nákladné a zranitelné funkce vzdáleného přístupu.

Tento průvodce návrhem je určen organizacím v této situaci, které potřebují rychlý způsob, jak nahradit nebo omezit používání vlastního hardwaru pro vzdálený přístup a poté postupně přejít, tam kde je to vhodné, na doporučený přístup se softwarovým agentem.

Tento průvodce je určen síťovým a bezpečnostním odborníkům, kteří zvažují náhradu svého současného dodavatele VPN a zároveň připravují organizaci na architekturu zero trust nebo SASE. Předpokládá znalost síťových konceptů, jako jsou tunely IPsec, směrovací tabulky a split tunneling.

Co se dozvíte:

• Jak může Cloudflare nahradit tradiční řešení typu VPN
• Jak získat přehled o síťovém provozu VPN
• Co je třeba zvážit při zavádění řešení Cloudflare ve velkém měřítku
• Kroky k přechodu na doporučenou implementaci Zero Trust Network Access

Řešení popsané v tomto návodu vyžaduje, abyste měli s Cloudflare smlouvu, která zahrnuje:

• Licence Cloudflare One pro počet uživatelů, které chcete začlenit
• Cloudflare WAN (dříve Magic WAN)

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

1. Co je Cloudflare? | Web ↗ (čtení na pět minut) nebo video ↗ (dvě minuty)
2. Blog: Co je SASE? | Secure access service edge (bezpečný přístup ke službám) | Cloudflare ↗ (čtení na 14 minut)
3. Referenční architektura: Přechod na architekturu SASE s Cloudflare (čtení na tři hodiny)

Tradiční přístupy k VPN obvykle poskytují následující typy přístupu.

• Umožnění vzdáleným uživatelům přístup k samostatně hostovaným privátním aplikacím běžícím v firemní síti
• Směrování veškerého internetového provozu uživatelů přes jediný centralizovaný přístupový bod VPN, kde se uplatňují bezpečnostní zásady

Platforma SASE nahrazuje tradiční VPN hardware tím, že nabízí dvě klíčové služby. Za prvé mapuje přístup uživatelů přímo na interní aplikace hostované v podnikových sítích nebo v cloudu, na rozdíl od provozování vlastní VPN služby, která obvykle poskytuje široký přístup k celé podnikové síti. Za druhé umožňuje filtrovat internetový provoz blízko uživatele, takže uživatelé mohou bezpečně přistupovat k internetu bez nutnosti směrovat veškerý provoz přes podnikovou síť, čímž se zvyšuje efektivita a zároveň zachovává bezpečnost.

Vzdálení uživatelé se ověřují a připojují ke cloudové službě Zero Trust Network Access (ZTNA), která má následně konektivitu do sítí, kde se nacházejí soukromé aplikace. Cloudflare Referenční architektura SASE popisuje tři způsoby, jak propojit Cloudflare s vašimi stávajícími aplikacemi a sítěmi:

1. Softwarové konektory (cloudflared nebo Cloudflare Mesh)
2. Tunely IPsec nebo GRE pomocí Cloudflare WAN
3. Přímá síťová připojení pomocí Cloudflare Network Interconnect

Všechny tři metody mají své specifické výhody, avšak při zavádění moderní architektury Zero Trust se obvykle dává přednost softwarovým konektorům, a to ze tří důvodů.

1. Přinášejí model síťové konektivity, který je flexibilní a snadno replikovatelný napříč prostředími. Aplikace a servery můžete přesouvat prakticky bez úprav konfigurace.
2. Architektura softwarového daemonu zjednodušuje škálování při zvýšených nárokách na provoz, stačí nainstalovat další agenty na další servery.
3. Protože daemony běží v blízkosti vašich aplikací, a ne na okraji vaší sítě, můžete vytvářet izolované síťové nebo aplikační segmenty, ve kterých se vynucují zásady. To brání laterálnímu pohybu útočníka a přináší plné výhody modelu zero trust.

Provoz směřující do obecného internetu je směrován přes cloudovou Secure Web Gateway (SWG). Jsou vytvořeny zásady, které filtrují požadavky na škodlivé weby a povolují přístup k aplikacím SaaS na základě identity uživatele a stavu zabezpečení zařízení.

Cloudflare Referenční architektura SASE popisuje různé způsoby, jak připojit uživatelská zařízení ke Cloudflare. Některé vyžadují instalaci agentů zařízení, jiné stačí, aby uživatel zadal adresu URL do webového prohlížeče. Protože většina tradičních VPN vyžaduje na zařízení nějaký klientský software, popíšeme v tomto dokumentu řešení využívající Cloudflare agent zařízení.

V situacích, kdy je stávající hardware pro vzdálený přístup zranitelný a je nutné jej urychleně nahradit, je klíčová rychlost. Tým pověřený odchodem od stávajícího VPN hardwaru navíc může být obeznámenější se sítěmi než s instalací softwaru na servery. Pokus o realizaci celého projektu nahrazení stávajícího hardwaru radikálně odlišným modelem, tedy nasazením softwarových agentů, může trvat týdny místo dnů. Tento návod popisuje, jak rychle odstranit nebo zmírnit stávající VPN řešení a poté navrhuje další kroky pro plné využití všech možností platformy SASE.

Tento přístup umožňuje síťovým a bezpečnostním týmům rychle začít pracovat a zároveň získávat zkušenosti s moderním nasazením zero trust pro vzdálený přístup k interním aplikacím. Vyšší viditelnost síťového provozu navíc týmům umožní lépe porozumět využívání aplikací a naplánovat úspěšný a bezpečný přechod na zero trust.

Tento průvodce popisuje následující fáze na obecné úrovni. Pokud potřebujete pomoc s konkrétními detaily vašeho prostředí, kontaktujte Cloudflare ↗.

• Fáze 1: Rychlá náhrada stávajícího tradičního nebo zranitelného VPN hardwaru cloudovým vzdáleným přístupem při současném získání přehledu o provozu aplikací.
• Fáze 2: Škálování a odlehčení tradičních tunelů IPsec.
• Fáze 3: Zlepšení úrovně zabezpečení segmentací přístupu k aplikacím a zavedením bezklientského přístupu.

Představte si organizaci s globální IT infrastrukturou, konkrétně se třemi datovými centry v Evropě, USA a Asii, z nichž každé provozuje vlastní VPN službu. Aby dosáhli nejlepšího výkonu, musí se zaměstnanci sami rozhodnout, ke kterému VPN clusteru se podle své polohy připojí. Veškerý internetový provoz uživatelů v tomto příkladu prochází přes VPN službu, kde firewally uplatňují určitou úroveň zabezpečení a chrání uživatele před riziky běžného internetu.

V této první fázi se vytvoří síťové připojení mezi uživatelskými zařízeními a privátními sítěmi, ke kterým aktuálně přistupují prostřednictvím stávající síťové infrastruktury. Docílit toho lze dvěma způsoby.

• Do zařízení zaměstnanců nainstalujte aplikaci Cloudflare agent zařízení. Tím se nahrazuje dosavadní použití klientského softwaru VPN.
• Pomocí stávajícího síťového hardwaru v datovém centru lze vytvořit tunely IPsec ke Cloudflare, které jsou spravovány prostřednictvím služby Cloudflare WAN.

Zařízení zaměstnanců i sítě datových center se připojí k nejbližšímu serveru Cloudflare. To je možné díky Anycast architektura Cloudflare ↗, a zajišťuje nejoptimálnější trasu pro uživatelský provoz bez jakéhokoli úsilí ze strany zaměstnanců či IT podpory. Uživatelé si už nemusí vybírat, ke kterému regionu služby VPN se připojí, protože Cloudflare vždy zajistí připojení k nejbližší a nejrychlejší dostupné službě pro co nejlepší výkon přístupu k jejich privátním aplikacím.

Obrázek 4 znázorňuje provoz od koncových zařízení uživatelů ke Cloudflare a tunely směrující provoz do privátních datových center. Jakmile uživatelský provoz dosáhne nejbližšího přístupového bodu Cloudflare, provoz určený pro privátní aplikace se směruje přímo do datových center, zatímco provoz směřující na internet se zpracovává prostřednictvím Cloudflare Secure Web Gateway (SWG). Lze využít stávající DNS služby k překladu požadavků na soukromé adresy pomocí Cloudflare Zásady DNS Gateway. Cloudflare WAN se používá k vytváření tunelů IPsec mezi Cloudflare a datovými centry a je nakonfigurováno se statickými trasami, které určují, jak provoz dosahuje jednotlivých existujících sítí a aplikací.

Použitím stávajících síťových nebo bezpečnostních zařízení k ukončení tunelů IPsec lze vytvořit bezpečné odbočky s omezeným dopadem na současnou infrastrukturu. Tyto tunely IPsec zároveň umožňují, aby odchozí provoz iniciovaný serverem mohl dál plynule procházet. V závislosti na rozsahu nasazení však mohou stávající zařízení narazit na omezení šířky pásma. Tuto první fázi je nejlepší chápat jako „pilotní“ nebo nízkorozsahové nasazení, jehož cílem je rychlý start a ověření konektivity mezi uživateli a aplikacemi. Další fáze pak návrh vylepší na základě poznatků získaných v této fázi.

Při takovém návrhu dokáže Cloudflare filtrovat provoz podle identity požadujícího uživatele. Uživatelé ověření u firemního poskytovatele identity a patřící do skupiny „Engineering“ tak například získají přístup pouze k interně hostovanému repozitáři zdrojového kódu. Zařízení uživatele navíc může být nutné, aby prošlo určité kontroly stavu zařízení před připojením. Existují příklady síťových zásad v dokumentaci k zero trust, kterou můžete použít jako referenci. V podstatě vám to umožní definovat zásady síťového přístupu na základě identity uživatelů místo přidružených rozsahů IP adres. Odstranění tradičních 5tuple ACL bude prvním krokem směrem k modelu zero trust.

Nyní, když jsou vaše sítě připojené k Cloudflare, je potřeba dostat provoz ze zařízení zaměstnanců do sítě Cloudflare, k čemuž je potřeba agent zařízení. Při první instalaci agenta jsou uživatelé vyzváni k ověření přes poskytovatele identity (IdP) nakonfigurovaného v Cloudflare. IdP zajistí, že se uživatelé ověří pomocí existující identity, a může také importovat informace o členství ve skupinách, které se pak používají v zásadách přístupu. Zásady registrace zařízení zajišťují, že k instanci Cloudflare Zero Trust vaší organizace mohou nová zařízení připojit pouze správní uživatelé, ověření správnými metodami a používající zabezpečená zařízení, a to ještě předtím, než získají přístup k jakýmkoli aplikacím.

Použijte profily zařízení k použití různých konfigurací agenta zařízení pro různé uživatele, případně pro stejné uživatele v různých lokalitách, pomocí Spravované sítě. Pro společnosti, které nesměrují internetový provoz přes svůj server VPN, umožňují profily zařízení nakonfigurovat agenta zařízení tak, aby vylučoval internetový provoz z tunelu Cloudflare a připojit se přímo k internetu. Tento návod přitom důrazně doporučuje směrovat provoz mířící na internet přes Cloudflare, kde máte nad zabezpečením tohoto provozu větší kontrolu. Cloudflare ale můžete selektivně obejít u provozu náročného na šířku pásma, například u videokonferenčních hovorů.

Provoz zaměstnanců, kteří používají agenta zařízení a směřuje k interním zdrojům, bude mít zdrojovou IP adresu z rozsahu 100.96.0.0/12. Jde o rozsah z Prostor Carrier-grade NAT podle RFC 6598 ↗ kterou je třeba přidat jako trasu v regionech datových center, aby se provoz mohl vracet zpět k těmto uživatelům. Další informace naleznete v Cloudflare WAN s integrací WARP dokumentace.

Ačkoli se tato fáze zaměřuje na využití služby Cloudflare WAN a tunelů IPsec pro většinu provozu zaměstnanců, softwarové konektory Cloudflare hrají klíčovou roli při překladu interních hostname přes DNS. Zkušenosti s používáním těchto softwarových konektorů se vám budou hodit i v další fázi, proto by úsilí zaměřené na definování procesů jejich nasazení a správy mělo začít už v této první fázi.

Cloudflare nabízí dva typy softwarových konektorů:

• cloudflared
• Cloudflare Mesh (dříve WARP Connector)

Jak již bylo zmíněno v úvodu, cloudflared je preferovaná metoda pro Zero Trust Network Access, podporuje ale pouze příchozí připojení k vašim sítím a aplikačním serverům; jakékoli připojení iniciované serverem nepůjde přes tunel a použije výchozí síťovou cestu serveru. Cloudflare Mesh je navržen tak, aby vytvářel tunely umožňující jak příchozí, tak odchozí připojení, momentálně ale nenabízí stejnou úroveň podpory failoveru a snadnosti konfigurace. V tomto průvodci se budeme věnovat použití cloudflared protože podporuje popsaný případ užití interního DNS.

Pro rozsáhlé případy užití vzdáleného přístupu Cloudflare doporučuje nasadit konektory na vyhrazené hostitele. Více informací najdete v Dokumentace k systémovým požadavkům s dalšími doporučeními k nasazení a dimenzování serverů. Umístění těchto serverů závisí na tom, jaký přístup potřebují, a na interních pravidlech firewallu a segmentaci sítě. Někteří zákazníci začínají první nasazení v DMZ, jiní je instalují hlouběji ve své síti a odtud dále rozvíjejí.

Instalace cloudflared se nejlépe provádí automatizovaně, proto doporučujeme nasazení pomocí virtualizační technologie, jako je Docker, nebo jako hosty VMware s konfigurací přes Ansible. Provoz využívající cloudflared tunelů zvyšuje, mohou tyto systémy automaticky škálovat nasazení na základě metrik v reálném čase shromažďovaných z hostitelů. cloudflared instance lze monitorovat pomocí Koncový bod metrik Prometheus. Prometheus je monitorovací a alertovací systém založený na HTTP, funkčně podobný SNMP, který zpřístupňuje metriky, jež lze z monitorovaného prostředku dotazovat (poll). Prometheus jako formát pro sběr metrik potřebných pro alerting a automatické škálování nasazení dnes podporuje většina monitorovacích systémů na trhu.

Další informace o nasazení cloudflared konektorů ve velkém měřítku:

• Různé návody k nasazení a aktualizaci konektorů v prostředích, jako je Ansible, Terraform nebo Kubernetes
• Vysoká dostupnost pomocí repliky
• Monitorování tunelů pomocí Grafana

Jak ukazuje obrázek 4, ze zařízení zaměstnance do Cloudflare proudí jak DNS, tak běžný síťový provoz. Agent zařízení ve výchozím nastavení přeposílá všechny DNS dotazy do Cloudflare ke kontrole a filtrování na základě Zásady DNS. To je výhodné, protože to administrátorům umožní nakonfigurovat Zásady DNS pro blokování potenciálních bezpečnostních hrozeb a okamžitě začít chránit zaměstnance při připojení k internetu. To platí i pro situace, kdy internetový provoz jde tunelem do Cloudflare, ale klient dotazy na názvy hostitelů stále překládá přes DNS služby Cloudflare.

U interních domén ale bude Cloudflare potřebovat vědět, jak je přeložit. Zde přichází na řadu zásady resolveru přicházejí ke slovu. Poté, co se zásady DNS uplatní na příchozí požadavky DNS, si zákazníci mohou zvolit předávání požadavků na interní hostitelské názvy DNS na své interní servery DNS. Například doména example.local může být hostováno na DNS serveru běžícím na 10.10.10.123. Zásada resolveru zajistí, že požadavky na hostitelské názvy patřící do této domény se odešlou na tuto IP adresu.

Je potřeba tunel, který zpřístupní trasu k internímu DNS serveru. cloudflared by měl být nasazen na hostiteli, který dokáže směrovat provoz DNS na IP adresu 10.10.10.123. Požadavky na interní domény přes bránu DNS budou poté přesměrovány tunelem na tento server DNS.

Jakmile podniknete kroky v této první fázi a první uživatelé začnou přistupovat k aplikacím, ukáže se potřeba řádného monitorování a logování. Přehled o provozu procházejícím přes Cloudflare vám pomůže s:

• Provozní činnosti, jako je řešení problémů vaším podpůrným týmem.
• Monitorování potenciálních hrozeb ze strany SOC, případně s využitím systému pro správu bezpečnostních informací a událostí (SIEM ↗) služba.
• Přehled o provozu aplikací umožňující zjistit, kde lze zlepšit zabezpečení a výkon (viz také fáze 2).

Cloudflare poskytuje přehled na různých úrovních, dostupný přes dashboard nebo exportovatelný pomocí Logpush. U provozu procházejícího tunely Cloudflare WAN IPsec Network Analytics najdete na dashboardu a prostřednictvím GraphQL API. Zobrazí se tak vzorkované statistiky provozu, které lze využít k analýze trendů a toku provozu.

Následují podrobnější protokoly síťových relací které shromažďují informace o všech síťových připojeních/relacích procházejících zabezpečenou webovou bránou Cloudflare, včetně neúspěšných požadavků. Po nich následují Protokoly aktivity Gateway, které obsahují informace o zásadách spuštěných při kontrole provozu enginem gateway. Kombinace těchto protokolů poskytuje kompletní přehled o veškerém síťovém provozu včetně identity uživatelů. Síťové a bezpečnostní týmy pak na základě těchto informací mohou analyzovat, jaký provoz kam směřuje, a naplánovat podle toho další kroky.

Nakonec, pokud jde o upozorňování v reálném čase, Cloudflare Notifications lze nakonfigurovat pro události, jako je IPsec a cloudflared stav tunelu i celkový stav infrastruktury Cloudflare.

Ve většině prostředí jsou koncové body IPsec omezeny svou propustností, což dříve či později může představovat problém při škálování provozu napříč celou firmou. Poslední krok fáze 1 vám poskytne přehled o toku provozu aplikací. I když se vám možná nepodaří kompletně zmapovat celé prostředí vašich aplikací, pravděpodobně najdete některé aplikace, které způsobují výrazné zatížení stávajících tunelů IPsec.

Naštěstí lze většinu těchto aplikací migrovat postupně, jednu po druhé, na lépe škálovatelné tunely založené na softwarovém konektoru. Pro tento typ migrace je vhodná každá aplikace, která nezávisí na provozu iniciovaném serverem. Se zkušenostmi získanými během počátečního nasazení cloudflared ve fázi 1:

1. Nasaďte dva nebo více cloudflared instance v příslušném prostředí, v uvedeném příkladu datové centrum v USA.
2. Přidejte Privátní sítě k tunelu k definování směrování a přístupu, které jsou úžeji zaměřené na síť a aplikace, pro něž zpracovávají provoz. Můžete například zpřístupnit subnet 10.20.56.0/24 prostřednictvím softwarového konektorového tunelu, místo většího subnetu 10.20.0.0/16 zpřístupněného spravovaným tunelem IPsec Cloudflare WAN.
3. Provoz zaměstnanců pro podsíť /24 bude nyní směrován přes tunel softwarového konektoru místo přes trasu /16 vedoucí tunelem IPsec, čímž se sníží závislost na zařízení pro ukončení IPsec.

V některých případech (jako u výše uvedeného datacentra v Asii) to může znamenat, že tunely IPsec už nejsou potřeba a jedinou spojnicí do infrastruktury jsou softwaroví konektoři. V takovém případě lze celou podsíť 10.30.0.0/16 spravovat pomocí cloudflared a tunel IPsec (spolu se souvisejícím hardwarem) vyřazen z provozu. Tato fáze bude pravděpodobně probíhat průběžně: jak se budou mapovat další aplikace a provozní toky vhodné pro tunely založené na softwarovém konektoru, budou se podle potřeby postupně migrovat.

První dvě fáze tohoto průvodce vedly k návrhu velmi podobnému tradičním VPN s VPN koncentrátory, kde se vynucování zásad odehrává na perimetru. I když jsme k tomu přistoupili z důvodů uvedených v úvodu, smyslem architektury zero trust je zlepšit stav zabezpečení definováním menších segmentů aplikací a sítě, na které se bezpečnostní zásady uplatňují co nejblíže danému zdroji.

Cílem této fáze je zmenšit a lépe izolovat zdroje zpřístupněné za tunely, aby se zabránilo laterálnímu pohybu ve vnitřních sítích. Díky přehledu získanému v předchozích fázích budete moci vybrat aplikaci (nebo sadu aplikací) a související IP adresy a nasadit vyhrazenou instanci softwarového konektoru. Viz dokumentaci o nasazení konektorů a zpřístupnění soukromých sítí a v kroku 3 nakonfigurovat IP adresy aplikace.

Protože je každá instance softwarového konektoru vyhrazena konkrétní aplikaci, lze ji nastavit jako jediný vstupní bod. Provoz do síťového segmentu, kde se aplikace nachází, a z něj tak lze zcela zablokovat, čímž se zabrání jakémukoli internímu laterálnímu pohybu. Jediné, co je potřeba, je platná odchozí trasa do internetu, aby softwarový konektor mohl vytvořit tunel, a aby síť či aplikace mohly dosáhnout na server, na kterém je konektor nasazen. Řízení přístupu přitom neprobíhá jen na úrovni směrování IP, ale i na úrovni protokolu. Díky tomuto přístupu tak můžete povolit přístup jen k HTTPS na daném serveru, i když na něm běží třeba i SSH nebo jiné služby, protože přístup chcete definovat výhradně pro port dané aplikace.

V příkladu výše jsou podsítě X a Y zcela oddělené od zbytku datového centra. Provoz do aplikací běžících v těchto podsítích (10.10.45.1, respektive 10.20.56.1) může procházet pouze přes Cloudflare s uplatněním příslušných zásad ověřování a autorizace. Nasazení softwarových konektorů v poměru jedna ku jedné nemusí být vždy správným přístupem. V privátní síti můžete mít spuštěno několik aplikací a nasadit více serverů se spuštěným cloudflared ke zpracování provozu pro dané aplikace.

Kromě směrování provozu pro privátní IP adresy cloudflared může zpřístupnit interní aplikace prostřednictvím veřejně přeložitelných hostitelských názvů. Díky tomu je možné se k takovým aplikacím připojit bez nutnosti instalovat na zařízení jakýkoli software. To se hodí zejména v případech, kdy software na zařízení nainstalovat nelze, například když poskytujete přístup k aplikaci dodavatelům nebo partnerům.

V příkladu níže erp.example.com se přidá jako Public Hostname k tunelu a směruje provoz na portu 80 a/nebo 443 na konkrétní IP adresu ve vnitřní podsíti Y. Přístup k tomuto prostředku z internetu je poté chráněn pomocí Bezpečnostní zásady Cloudflare Access které rovněž využívají připojení k IdP, jež jste nastavili pro onboarding svých zaměstnanců.

Tento typ přístupu není vhodný pro všechny aplikace. Vhodné jsou pouze aplikace HTTP(S) nebo aplikace, které lze vykreslit v prohlížeči jako SSH a VNC. Další informace o takovém nasazení a o pokročilých možnostech, jako je nastavení cookies, izolace prohlížeče a použití tokenu Access pro ověřování ve vaší aplikaci, najdete v dokumentace k self-hosted aplikacím.

Tento průvodce návrhem vycházel z poměrně tradičního prostředí VPN s jeho běžnými funkcemi, omezeními a riziky. Kombinací Cloudflare na zařízeních uživatelů a Cloudflare WAN směrem k sítím datacenter popisovaly fáze jedna a dva návrh migrace s nízkým rizikem, který využívá stávající technologie a znalosti. Již to přineslo výhody v podobě odstavení VPN koncentrátorů, lepší viditelnosti sítě a vyššího výkonu při přístupu uživatelů k interním prostředkům.

Třetí fáze návrh vylepšila zavedením síťových zásad založených na identitě a menších síťových segmentů se softwarovými konektory. To dále otevřelo možnost nabízet další modely přístupu zero trust, například bezklientský přístup k webovým aplikacím nebo relace VNC a SSH vykreslované v prohlížeči.

Flexibilita Cloudflare connectivity cloud, díky které lze propojit libovolné zařízení, aplikaci a síť, umožňuje provádět tuto migraci na zero trust postupně krok za krokem. Tím se snižuje riziko a síťové i bezpečnostní týmy mohou přizpůsobovat své znalosti a architektury tempu, které jejich organizace vyžaduje.

• Integrace Cloudflare WAN: Připojení WARP do sítě Cloudflare WAN
• Konfigurace zásad: Gateway Network policies