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

Referenční architektura zabezpečení a výkonu aplikací s více dodavateli

S postupem času a rychlým vývojem odvětví zabezpečení a výkonu aplikací začaly firmy pro poskytování služeb nasazovat více dodavatelů. Zákazníci se pro více dodavatelů rozhodují například z důvodu regulatorní nebo firemní compliance, odolnosti, výkonu nebo nákladů.

Ačkoli se někteří zákazníci z různých důvodů popsaných v tomto dokumentu rozhodují pro řešení od více dodavatelů, nasazení s více dodavateli může přinést vyšší komplexnost, vyšší provozní náklady kvůli více dashboardům a konfiguracím a náročnější zaškolení. Při snaze o vytvoření základní úrovně funkcí podporovaných všemi dodavateli navíc mohou zákazníci skončit u nejmenšího společného jmenovatele, aniž by využili nejnovější možnosti a inovace konkrétního dodavatele. Zákazníci by měli před nasazením řešení s více dodavateli pečlivě zvážit cíle a požadavky a se všemi zúčastněnými stranami zvážit výhody a nevýhody.

Tento dokument zkoumá, proč někteří zákazníci volí přístup s více dodavateli nebo dvěma dodavateli a jak lze do takového řešení začlenit Cloudflare. Konkrétně popisuje, jak lze přístup s více dodavateli realizovat pro zabezpečení a výkon aplikací. Dokument je určen architektům a všem, kdo se zajímají o cloudová řešení zabezpečení a výkonu s více dodavateli.

Tato referenční architektura je určena pracovníkům IT, bezpečnostních nebo síťových týmů, kteří mají na starosti stávající síťovou infrastrukturu organizace nebo ji dobře znají. Užitečná je zkušenost s technologiemi a koncepty důležitými pro zabezpečení a výkon aplikací, jako jsou proxy, DNS a firewally.

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

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

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

• Jak mohou funkce Cloudflare pro zabezpečení a výkon aplikací spolupracovat se stávajícími technologickými dodavateli
• Pochopení rozhodnutí, která je třeba učinit při použití více dodavatelů

Než se budeme věnovat řešením zabezpečení a výkonu od více dodavatelů, je důležité vysvětlit, jak taková cloudová řešení obecně fungují a jak jimi prochází provoz.

Cloudoví poskytovatelé zabezpečení a výkonu, jako je Cloudflare, fungují jako reverzní proxy. Reverzní proxy je server, který stojí před webovými servery a předává jim klientské požadavky. Reverzní proxy se obvykle nasazují proto, aby zvýšily zabezpečení, výkon a spolehlivost.

Běžný tok provozu bez reverzní proxy vypadá tak, že klient odešle DNS dotaz, obdrží IP adresu origin serveru (origin serverů) a komunikuje přímo s ním (s nimi). Znázorňuje to obrázek 1.

Po zavedení reverzní proxy klient stále odesílá požadavek na vyhledání DNS svému resolveru, což je první krok při vyhledávání DNS. V tomto případě resolver DNS vrátí klientovi IP adresu reverzní proxy dodavatele a klient poté odešle požadavek na tuto reverzní proxy. Cloudové proxy řešení pak může poskytovat další služby zabezpečení, výkonu a spolehlivosti, jako například CDN ↗, WAF ↗, DDoS ↗, API Shield ↗, Bot Management ↗ a další možnosti, než na základě bezpečnostní politiky rozhodne, zda daný požadavek klienta nasměrovat na příslušný origin server (servery). Znázorňuje to obrázek 2.

V některých případech poskytuje reverse proxy i DNS služby od stejného poskytovatele, což znázorňuje obrázek 3 níže. To může být výhodné pro správu všech služeb z jediného dashboardu a pro provozní jednoduchost.

Cloudflare poskytuje architekturu reverzní proxy pomocí své globální síť anycast ↗ pro příslušné služby zabezpečení, výkonu a spolehlivosti, které poskytuje. Anycast je metoda adresování a směrování v síti, při které mohou být příchozí požadavky směrovány do různých lokalit neboli „uzlů“ inzerujících stejný rozsah IP adres. Cloudflare je díky anycastu i své globální přítomnosti v stovky měst po celém světě ↗. Cloudflare je navíc přímo propojena s 12 000 sítěmi, včetně všech významných poskytovatelů internetového připojení, cloudových poskytovatelů a firem, a nachází se do ~50 ms od 95 % světové populace připojené k internetu.

Cloudflare provozuje jednu globální síť, ve které běží každá služba na každém serveru v každém datovém centru Cloudflare. Protože síť Cloudflare využívá anycast, na požadavek klienta odpovídá nejbližší datové centrum. To snižuje latenci a zároveň zlepšuje odolnost sítě, dostupnost a zabezpečení díky rovnoměrnějšímu rozložení provozu napříč sítí Cloudflare.

Globální anycast síť Cloudflare ↗ poskytuje následující výhody:

• Příchozí provoz je směrován do nejbližšího datového centra, které má kapacitu efektivně zpracovat požadavky.
• Dostupnost a redundance jsou zajištěny automaticky. Protože stejnou IP adresu inzeruje více uzlů, v případě výpadku jednoho z nich se požadavky jednoduše přesměrují na jiný uzel v blízkém okolí.
• Anycast rozprostírá provoz mezi více datovými centry, čímž zlepšuje celkové rozložení provozu v síti Cloudflare a brání tomu, aby byla některá lokalita zahlcena požadavky. Díky tomu jsou sítě s anycastem velmi odolné vůči útokům DDoS.

Tato část stručně shrnuje možnosti onboardingu Cloudflare, které je dobré znát před tím, než se ponoříte do podrobností řešení s více dodavateli. Způsob onboardingu ovlivňuje, jak se dané řešení nasazuje a konfiguruje. Pokud možnosti onboardingu Cloudflare již znáte, můžete přejít rovnou k další části věnované řešením s více dodavateli.

Cloudflare poskytuje více možností, jak snadno provést onboarding a začít využívat služby zabezpečení, výkonu a spolehlivosti. Jednou z výhod cloudových řešení nabízených formou nastavení přes proxy je snadnost onboardingu a začátku používání, protože v zásadě jde o konfiguraci DNS, díky které se požadavky klientů směrují přes proxy. I v rámci onboardingu prostřednictvím konfigurace DNS ale Cloudflare nabízí řadu možností a flexibilitu.

Základním požadavkem je, aby byl provoz proxovaný přes Cloudflare: tomu se také říká „oranžový mrak“ (orange-clouded), protože provoz na web je proxovaný přes Cloudflare. V dashboardu uvidíte u konkrétního záznamu DNS stav „Proxied“ a ikonu oranžového mraku, jak je znázorněno na obrázku 5 níže.

Provoz lze přes Cloudflare proxovat několika způsoby a volba konkrétní metody závisí na požadavcích zákazníka.

1. Úplné nastavení DNS: Cloudflare jako primární poskytovatel DNS

Cloudflare je nakonfigurován jako primární poskytovatel DNS a záznamy A jsou nastaveny tak, aby provoz procházel přes proxy Cloudflare. Když je u záznamu DNS zapnutá proxy, odpovědí jsou anycast IP adresy Cloudflare, díky nimž Cloudflare funguje jako proxy.

2. Nastavení sekundárního DNS s přepsáním sekundárního DNS

Cloudflare je nakonfigurován jako sekundární poskytovatel a všechny záznamy DNS jsou přeneseny z primárního poskytovatele. Cloudflare k tomu nabízí funkci s názvem Přepsání sekundárního DNS která zákazníkům umožňuje přepsat odpověď poskytovanou sekundárními nameservery Cloudflare. Zákazníci tak mohou využívat přenosy zón (zone transfers) k automatické synchronizaci mezi poskytovateli DNS. Zároveň poskytuje flexibilitu při aktualizaci vybraných záznamů v Cloudflare DNS, aby bylo možné přesměrovat určitý provoz k jinému poskytovateli služby, jako je Cloudflare. V takovém případě bude odpovědí anycast IP adresa Cloudflare, díky čemuž může Cloudflare fungovat jako proxy.

3. Částečné nastavení / CNAME

V tomto nastavení není Cloudflare autoritativním poskytovatelem DNS a zákazník spravuje záznamy DNS externě.

Přechod na nastavení CNAME zajistí, že se název hostitele nakonec přeloží na IP adresy Cloudflare. To se hodí, když zákazníci nechtějí měnit své současné nastavení DNS, ale přesto chtějí využívat další služby Cloudflare.

Pokud aktuální poskytovatel DNS zákazníka nepodporuje CNAME na vrcholu zóny (někdy nazývaném „kořenová doména“ nebo „nahá doména“), jak to umí Cloudflare pomocí Zploštění CNAME, musíte si od Cloudflare zakoupit statické IP adresy (Static IP) a v DNS u poskytovatele k nim vytvořit záznam A. V Cloudflare pak můžete vytvořit záznam A, který na origin server nasměruje kořen zóny (zone apex).

Mnoho zákazníků využívajících služby Cloudflare těží z propojení jednotlivých produktů a inovací i z jednoduchosti jediného rozhraní pro správu a provoz a používá společně více služeb Cloudflare, jako jsou CDN a WAF. I když to není doporučeno, je také možné používat bezpečnostní služby jako WAF s jinými poskytovateli CDN tak, že se DNS nastaví na přesměrování provozu přes Cloudflare pomocí CNAME a cachování Cloudflare se vypne pomocí Cache Rules.

Zákazníci se obvykle přiklánějí k přístupu s více dodavateli, a to z důvodu regulatorního nebo firemního souladu, odolnosti, výkonu a nákladů.

Někteří klienti musí dodržovat regulatorní nebo firemní politiku, která zakazuje závislost na jediném dodavateli pro veškeré služby zabezpečení, výkonu a spolehlivosti. Důvodem může být firemní politika zmírňování rizika výpadků nebo problémů konkrétního dodavatele, případně snaha o vyjednávací páku proti zvyšování cen či nákladů dodavatele. Pro dodržení těchto politik je nutná strategie s více dodavateli.

Pokud jeden dodavatel zajišťuje všechny služby zabezpečení a výkonu, může to působit jako jediný bod selhání. Důvodem bývá regulatorní tlak na vyšší spolehlivost všech kritických systémů, výpadky u stávajícího dodavatele nebo nejistota ohledně dlouhodobé spolehlivosti jediného dodavatele.

V mnoha případech může být jeden poskytovatel velmi dobře propojen a poskytovat očekávanou úroveň výkonu v určitém regionu, ale v jiných regionech už méně. Může to mít různé důvody, včetně investic, omezených zdrojů nebo geopolitických faktorů. Řada zákazníků chce plně optimalizovat rychlost u výkonnostně kritických aplikací a médií zavedením přístupu s více poskytovateli, který se často kombinuje s monitorováním výkonu v reálném čase pro směrování provozu k nejvhodnějšímu poskytovateli na základě těchto dat.

Stejně jako se výkon konkrétního dodavatele může lišit podle obsahu, denní doby a lokality, liší se i náklady, a směrování konkrétního provozu přes konkrétního dodavatele může pomoct optimalizovat celkové náklady na doručení. Tyto přínosy obvykle vedou ke strategii více dodavatelů jen ve velmi specifických případech, například u vysokoobjemového mediálního provozu, protože náklady na zapojení a správu více dodavatelů mimo tyto úzce vymezené případy obvykle finanční i zdrojové náklady spíše zvyšují. Přístup s více dodavateli navíc pomáhá vyhnout se závislosti na jediném poskytovateli a nabízí větší flexibilitu a vyjednávací sílu vůči dodavatelům.

Každá vícedodavatelská architektura obsahuje řadu komponent, o kterých se organizace musí rozhodnout ještě před implementací, a to jak na obchodní, tak na technické úrovni. Kromě toho je dobré mít na paměti několik dalších zásad, díky nimž své nastavení co nejlépe sladíte se silnými stránkami a jedinečnými přednostmi Cloudflare.

Optimalizujte podle rozsahu funkcí a metodiky doručování. Cloudflare dokáže nabídnout funkční paritu s většinou hlavních dodavatelů a vlastní funkce lze snadno realizovat prostřednictvím naší bezserverové výpočetní služby. Pokud jde o metodiku doručování, architektura Cloudflare typu anycast je jedinečná v tom, že každý server dokáže poskytovat všechny služby, které Cloudflare nabízí, což z ní dělá ideálního kandidáta pro přístup active/active.

Kde je to možné, využívejte API Cloudflare a jeho možnosti rychlého nasazení. Cloudflare nabízí všechny funkce nejdříve přes API a změny konfigurace se obvykle projeví během několika sekund, takže týmy mohou změny snadno testovat a nasazovat programově, aniž by čekaly na dlouhé nasazovací cykly.

Vyhněte se takzvanému „vrstvenému“ přístupu, tedy situaci, kdy je Cloudflare v toku požadavků zařazen za jiného dodavatele. Firmy často uvažují o skládání více dodavatelů za sebe v naději, že tím dosáhnou hloubkové obrany, protože stejný provoz prochází lineárně každou vrstvou. Teoreticky by tak mohly platit zásady obou dodavatelů a škodlivý provoz, který nezachytí jeden z nich, by měl zachytit ten druhý. V praxi však toto uspořádání funguje jinak. Hlavní nevýhodou je ztráta úplné viditelnosti provozu, pokud Cloudflare stojí za jiným dodavatelem, což omezuje řadu služeb Cloudflare založených na threat intelligence, jako je Bot Management, Rate Limiting, ochrana proti DDoS útokům a databáze reputace IP adres. Toto uspořádání je také velmi nevýhodné z hlediska výkonu, protože provoz musí projít dvěma sítěmi, z nichž každá má vlastní režii na zpracování a navazování spojení, než dorazí zpět na origin server. Navíc přináší zbytečnou složitost do provozu, správy i podpory.

K vrstvenému přístupu je třeba poznamenat, že u některých konkrétních bodových řešení může dávat smysl umístit řešení jednoho dodavatele před řešení druhého, například konkrétní řešení pro správu botů a API gateway, zvláště při přechodu na nového dodavatele nebo poskytovatele. V těchto scénářích je důležité rozumět tomu, kde se v toku požadavků jednotlivá řešení nacházejí, aby byla zajištěna jejich maximální účinnost.

Cloudflare a řada dalších poskytovatelů sice udržuje vysokou dostupnost a robustní architekturu odolnou proti chybám, někteří zákazníci ale chtějí dál omezit závislost na jediném dodavateli a s tím spojený bod selhání. Je důležité počítat i s nejhorším scénářem, kdy část nebo všechny služby dodavatele nefungují, a naplánovat, jak se s tím v krátké době vypořádat. Zákazníci musí zvážit, jak zajistit redundanci napříč poskytovateli DNS, sítěmi a připojením k původním serverům, aby se vyloučilo riziko, že selhání jednoho dodavatele nebo komponenty přeroste v rozsáhlý výpadek.

Konkrétní podrobnosti se sice mohou výrazně lišit v závislosti na dodavateli a obchodním případu, technická hlediska nasazení s víc dodavateli ale lze rozdělit do tří oblastí: logika směrování, správa konfigurace a připojení k původním serverům.

Prvním a pravděpodobně nejdůležitějším rozhodnutím při úvahách o strategii s více poskytovateli je způsob směrování provozu k jednotlivým poskytovatelům. To závisí jak na obchodní logice, která strategii s více poskytovateli řídí, tak na technických možnostech jednotlivých poskytovatelů. Provoz k jednotlivým poskytovatelům se směruje pomocí DNS a mění se podle aktuálních podmínek a potřeb firmy. Cloudflare podporuje konfigurace zóny jako autoritativní poskytovatel DNS, sekundární poskytovatel DNS nebo nastavení DNS mimo Cloudflare (CNAME).

Zde lze využít vyvažování zátěže založené na DNS a kontroly stavu (health checks), díky nimž jsou požadavky klientů na doménu nebo web rozdělovány mezi funkční origin servery. Poskytovatel DNS sleduje stav serverů a na požadavek klienta odpovídá metodou round-robin s příslušnými IP adresami.

Pokud je pro odolnost na úrovni DNS žádoucí i přístup s více poskytovateli DNS, existuje zde řada možných konfigurací s více autoritativními nameservery od různých dodavatelů. Další podrobnosti najdete v části „Multi-vendor DNS setup options“ v tomto dokumentu. Klíčové je zde zajistit konzistentní konfiguraci napříč jednotlivými poskytovateli. V závislosti na nastavení/konfiguraci DNS lze této konzistence dosáhnout různými způsoby, například přenosy zón, automatizací pomocí nástrojů jako Terraform nebo OctoDNS, monitorováním či automatizací prostřednictvím skriptů, nebo i ruční konfigurací.

Řada dodavatelů sice dokáže poskytnout podobný uživatelský zážitek, konfigurace a správa se ale mezi poskytovateli mohou výrazně lišit, což zvyšuje náklady na úspěšnou implementaci. To v konečném důsledku znamená, že se firma musí seznámit s konfigurační logikou každého dodavatele a vytvořit systém pro jejich vzájemné mapování. Kdykoli je to možné, hledejte dodavatele, kteří kladou důraz na jednoduchost správy, podporu automatizace a rychlé nasazení, což pomáhá snížit náklady a zátěž spojenou se správou.

Zásadní roli zde hraje podpora API pro veškeré funkce produktů daného poskytovatele. Zachování konzistentní konfigurace je důležité nejen pro směrování v určitých DNS nastaveních s více poskytovateli, ale i pro udržení konzistence mezi jednotlivými službami, jako je WAF nebo zabezpečení API, protože provoz může být směrován k libovolnému z poskytovatelů. Nástroje pro automatizaci, jako je Terraform nebo vlastní skriptované automatizační nástroje, využívají API k udržení této konzistence mezi poskytovateli.

Další důležité rozhodnutí, které je třeba učinit, se týká toho, jak se každý poskytovatel připojí zpět do vaší organizace. To bude z velké části záležet na možnostech dodavatele a na technických a bezpečnostních požadavcích vaší organizace.

Klienti odesílají požadavky přes internet a ty jsou směrovány do proxy služby příslušného poskytovatele v jeho cloudu. V nejjednodušším scénáři proxy pouze směruje provoz přes internet do originu; jde o výchozí nastavení.

Pokud zákazník požaduje vyšší zabezpečení nebo další výkonnostní výhody, může se rozhodnout využít i možnosti připojení nabízené dodavatelem, například šifrované tunely k origin serveru nebo přímé připojení z datových center zákazníka přímo do datových center Cloudflare prostřednictvím cross connectu ze zákaznického zařízení do Cloudflare. Dodavatelé mohou také nabízet zrychlené směrování, při kterém aktivně sledují nejrychlejší cesty přes internet, aby k origin serveru vždy vedla ta nejoptimálnější trasa.

Cloudflare nabízí všechny tyto možnosti konektivity spolu se Smart Routing, které zajišťuje použití nejrychlejších cest k origin serveru. Těmto možnostem konektivity se podrobněji věnuje část „Možnosti konektivity Cloudflare“ v tomto dokumentu.

Provoz a řešení problémů

Při návrhu řešení s více dodavateli je důležité zvážit provoz a řešení problémů. Řešení s více dodavateli může zvýšit provozní náklady a také ztížit řešení problémů, protože nyní musíte spravovat a diagnostikovat dvě různá prostředí.

Cloudflare se vždy zaměřoval na provozní jednoduchost a přehlednost. Poskytuje jeden jednotný dashboard, ze kterého lze přistupovat ke všem službám zabezpečení, výkonu a spolehlivosti v rámci konzistentního a provozně jednoduchého uživatelského rozhraní.

Cloudflare dále nabízí logování, analytiku a dashboardy bezpečnostní analytiky. Podrobnější logy jsou dostupné také přímo v uživatelském rozhraní. Klienti tak mají k dispozici granulární data, která lze využít pro analýzu a řešení problémů.

Obrázek 7 níže ukazuje pohled na Cloudflare Security Analytics, které na jednom místě shromažďuje veškeré detekční schopnosti Cloudflare. Bezpečnostním inženýrům a administrátorům tak poskytuje rychlý přehled o aktuálním provozu a bezpečnostních poznatcích týkajících se jejich webu.

Kromě analytiky pro jednotlivé produkty a bezpečnostní analytiky uvedené výše si můžete v rozhraní zobrazit i logy a exportovat je do Cloudflare nebo do cloudů či produktů třetích stran pro další analýzu.

Na obrázku 8 níže se konfiguruje Logpush pro automatický export logů do externího cíle.

Při výběru dodavatelů pro řešení s více dodavateli byste měli zajistit, aby vybraní dodavatelé splňovali níže uvedená kritéria:

• Dodavatel zajišťuje provozní jednoduchost díky jednotnému rozhraní pro všechny operace, ve kterém mohou uživatelé vše snadno spravovat a vyřídit na jednom místě.
• Dodavatel nabízí užitečnou bezpečnostní analytiku, díky které lze porozumět provozu webu, získat bezpečnostní přehledy a data užitečná pro řešení problémů.
• Dodavatel umožňuje exportovat protokoly nebo data požadavků do cloudů či aplikací třetích stran.
• Dodavatel uplatňuje přístup API first a poskytuje API pro všechny operace, takže úlohy lze snadno automatizovat.
• Dodavatel má dobrou pověst a dokáže v případě potřeby poskytnout účinnou podporu a pomoc.
• Zaměstnanci jsou proškolení, mají odborné znalosti nebo se s produkty daného dodavatele cítí komfortně.

Diagram níže popisuje typické nastavení s více poskytovateli, kdy jsou oba poskytovatelé „aktivní“, což znamená, že oba obsluhují provoz pro stejný zdroj (www.example.com) a provoz je rozdělen mezi oba.

Z hlediska směrování tento příklad ukazuje autoritativní DNS umístěnou mimo oba poskytovatele, která mezi nimi rozkládá zátěž. Tento poskytovatel DNS může být provozován samostatně nebo u jiného externího poskytovatele. Provoz se ke každému poskytovateli směruje na základě odpovědí na dotazy na www.example.com se záznamem CNAME specifickým pro daného poskytovatele nebo statickou IP adresou pro provoz apex domény. K dosažení tohoto rozdělení provozu musí mít externí poskytovatel DNS určitou schopnost provádět vyvažování zátěže provozu. Většina hlavních poskytovatelů DNS disponuje nějakým mechanismem pro vyvažování zátěže na základě DNS, s různou mírou složitosti a konfigurovatelnosti. V nejjednodušším případě to může znamenat střídání záznamů metodou round robin, případně obměňování odpovědi na základě polohy klienta, dat z kontroly stavu (health check) a dalších faktorů.

V závislosti na autoritativním DNS poskytovateli lze provoz mezi oběma stranami rozdělovat rovnoměrně, nebo jej upravovat dynamicky. Zákazníci často řídí DNS směrování na základě dat o výkonu a dostupnosti od monitorovací služby třetí strany, jako je Thousandeyes nebo Catchpoint, a podle nich upravují DNS odpovědi. Monitorovací služby třetích stran se také často používají k zachycení kompletních metrik HTTP požadavků a odpovědí, aby bylo možné směrovat provoz podle výkonu v reálném čase. Provoz lze od poskytovatele snadno přesměrovat aktualizací autoritativního DNS a vyčkáním, než vyprší TTL záznamu.

Je důležité zmínit, že služby třetích stran sledují metriky výkonu aplikace mezi koncovými body (end to end), nejen dobu odezvy DNS nebo omezená data používaná resolvery DNS. Záznamy DNS se pak na základě těchto výkonnostních dat aktualizují tak, aby ukazovaly na proxy správného poskytovatele zabezpečení.

Konfigurace obou poskytovatelů udržují administrátoři synchronizované tak, že změny nasazují přes Terraform, který volá API každého poskytovatele. Mějte na paměti, že ačkoli Cloudflare nabízí plnou podporu API pro každou funkci, u jiných poskytovatelů to nemusí platit.

Pokud se používá jen jeden externí poskytovatel DNS, vzniká tím jediný bod selhání pro případ jeho výpadku. Toto riziko lze zmírnit zavedením řešení DNS s více dodavateli; podrobněji se tomu věnuje Možnosti DNS s více dodavateli v tomto dokumentu.

Další výzvou paralelního přístupu je udržování synchronizace konfigurací mezi poskytovateli tak, aby byla zajištěna konzistentní zkušenost koncového uživatele. To znamená, že administrátoři musí znát správu konfigurace obou dodavatelů a chápat, jak lze dosáhnout parity funkcí.

Jakmile je provoz pomocí DNS nasměrován k poskytovateli bezpečnostních a výkonnostních služeb, uplatní se všechny bezpečnostní a výkonnostní služby i příslušné zásady a provoz se poté přes internet přesměruje zpět k origin serveru, kde firewall zákazníka povoluje IP adresy specifikované jednotlivými poskytovateli.

Příklad níže popisuje nastavení, kdy jsou poskytovatelé DNS zároveň poskytovateli zabezpečovací proxy a záznamy DNS jsou synchronizovány pomocí přenosů zóny. Jako preferované a nejodolnější řešení se doporučuje řešení DNS s více poskytovateli.

Mezi jednotlivými poskytovateli DNS existují různá možná nastavení, kterým se podrobněji věnuje část tohoto dokumentu nazvaná ‘Vícedodavatelské nastavení DNS’, včetně výhod a nevýhod jednotlivých řešení.

V tomto příkladu se používá více autoritativních poskytovatelů DNS, přičemž jeden je primární a druhý sekundární. Při použití sekundárního DNS a příslušného standardu umožňují přenosy zón snadno udržovat konfigurace DNS mezi různými poskytovateli synchronizované.

Aby bylo v tomto modelu možné směrovat požadavky k oběma poskytovatelům (pro stejné hostitele), musí poskytovatel nastavený jako sekundární umět přepisovat záznamy určené k průchodu přes proxy. Bez možnosti přepisovat záznamy jako sekundární poskytovatel by cíl všech primárních záznamů zůstal statický, což by omezilo flexibilitu a odolnost celého nastavení. Cloudflare tuto možnost poskytuje pomocí Přepsání sekundárního DNS. Pokud je například jako sekundární server nastaven poskytovatel typu Cloudflare, DNS se do něj automaticky synchronizuje z primárního serveru prostřednictvím přenosu zóny (zone transfer) a pomocí funkce Secondary DNS override lze aktualizovat záznam A tak, aby ukazoval na vlastní proxy či služby.

Vyvažování zátěže založené na DNS zde sice není nutné, u každého poskytovatele se ale hodí, protože díky němu lze požadavky předvídatelně rozdělovat mezi víc dodavatelů. V opačném případě rozdělení provozu do značné míry určuje výběr jmenného serveru resolverem klienta.

U autoritativního poskytovatele DNS má každý dodavatel uvedeny vlastní záznamy NS a klient si na základě svého resolveru vybere konkrétní nameserver. Resolver po vyžádání obdrží kompletní seznam autoritativních nameserverů. Logika většiny resolverů obvykle zohledňuje jak dobu překladu, tak dostupnost. V tomto scénáři tedy o tom, který nameserver se použije, rozhodují resolvery na základě dat o výkonu a dostupnosti, která už mají k dispozici.

Je důležité zmínit, že resolvery DNS obvykle už dotazy a odpovědi spojené s použitými nameservery znají. Nameserver, který dodavatel přidělí zákazníkovi, mohou pro svou autoritativní DNS už používat i jiné weby, takže resolvery mají k dispozici bohatá historická data o výkonu, která lze ihned využít.

V tomto příkladu vidíme také záznamy synchronizované pomocí pravidelných přenosů zón. Cloudflare podporuje jak odchozí, tak příchozí přenosy zón. Provoz je ke každé proxy směrován buď pomocí záznamu CNAME specifického pro daného poskytovatele, nebo pomocí statické IP adresy.

Konfigurace na straně DNS se může lišit: jednotlivé možnosti jsou podrobněji popsány v další části. DNS lze nastavit tak, že jeden poskytovatel funguje jako primární a druhý jako sekundární. U primárního poskytovatele DNS probíhá veškerá konfigurace DNS a sekundární DNS získává kopii konfigurace prostřednictvím přenosu zóny.

Někteří poskytovatelé DNS, jako Cloudflare nabízejí možnost, kdy sekundární DNS může přepsat záznamy A a AAAA. To umožňuje poskytovateli přepsat záznam A/AAAA tak, aby podle potřeby směroval provoz přes jiného dodavatele. V takovém případě poskytuje sekundární DNS server pro stejný hostitelský název jinou odpověď než primární server. To znamená, že v závislosti na tom, který nameserver klientský resolver dotazuje, bude požadavek směrován do příslušné sítě daného dodavatele. To umožňuje flexibilitu a snižuje složitost tím, že se řízení provozu a failover spoléhá na klientský resolver, pokud jsou nameservery pomalé nebo nedostupné. Za to se platí ztrátou přímé kontroly a předvídatelnosti nad tím, kterého poskytovatele si klient zvolí.

Jinou variantou je hostovat konkrétní aplikace nebo hostname u konkrétních poskytovatelů. Ve výše uvedeném příkladu by to mohlo znamenat, že primární i sekundární DNS server mají www.example.com mapované na adresu Cloudflare, bez ohledu na to, který poskytovatel překládá počáteční dotaz DNS.

Klíčové rozhodnutí o směrování určuje DNS. Jak již bylo zmíněno, pro konfiguraci s více poskytovateli DNS existuje několik možných uspořádání. Níže se předpokládá, že používáte dva poskytovatele DNS, kteří zároveň poskytují i bezpečnostní řešení.

1. Dva autoritativní servery: jeden primární a jeden sekundární

Toto nastavení spočívá v tom, že jeden poskytovatel funguje jako primární a druhý jako sekundární. Účelem sekundárního DNS je podpořit řešení s více DNS, kde probíhá automatická synchronizace konfigurace mezi primárním a sekundárním serverem.

V tomto nastavení jsou oba poskytovatelé DNS autoritativní, ale pouze jeden je primární a je zdrojem pravdy, kde se provádějí změny a aktualizace konfigurace DNS. Změny a aktualizace konfigurace na primárním poskytovateli se synchronizují se sekundárním poskytovatelem DNS pomocí přenosů zón řízených poskytovatelem. Na DNS dotazy odpovídají servery obou poskytovatelů.

Výhodou a hlavním případem použití tohoto modelu nasazení je, že využívá standard pro synchronizaci DNS mezi více poskytovateli, který byl přesně za tímto účelem vytvořen, přičemž za přenosy zóny odpovídá poskytovatel DNS. Tato možnost zjednodušuje udržování synchronizace DNS mezi poskytovateli.

Klienti se někdy mohou rozhodnout pro jinou možnost z následujících důvodů:

• Potřeba aktualizovat záznamy DNS ve chvíli, kdy nefunguje pipeline pro správu záznamů a přenos zóny.
• Nechuť spoléhat se na třetí stranu či dodavatele při synchronizaci DNS a snaha získat větší kontrolu.
• Existují konkrétní omezení či předpisy, které tuto možnost vylučují.

Toto nastavení doporučujeme zákazníkům, kteří oceňují jednoduchost sekundárního DNS a poskytovatele, který udržuje synchronizaci.

Výhody:

• Pro synchronizaci DNS používá standardní protokoly (AXFR, IXFR) a probíhá automaticky prostřednictvím Zone Transfers.
• Jednoduchost, protože za synchronizaci DNS odpovídá poskytovatel DNS.

Nevýhody:

• Pokud je proces správy záznamů a přenosu zón nedostupný, záznamy DNS nelze aktualizovat.
• Někteří klienti nechtějí být závislí na dodavateli nebo třetí straně při synchronizaci DNS a chtějí mít větší kontrolu a flexibilitu.

2. Dva autoritativní servery: oba primární

Někteří klienti mohou chtít i jistotu, že budou moci aktualizovat záznamy DNS i ve chvíli, kdy nefunguje kanál pro správu záznamů a přenos zóny. Zároveň nechtějí být závislí na třetí straně nebo dodavateli při synchronizaci DNS a chtějí mít větší kontrolu. V takovém případě lze oba poskytovatele DNS použít jako primární.

V tomto nastavení je každý poskytovatel DNS autoritativní a zároveň primární. Neexistuje žádný sekundární DNS a změny či aktualizace DNS lze provádět u kteréhokoli poskytovatele, přičemž na DNS dotazy odpovídají oba poskytovatelé DNS.

Synchronizace konfigurace DNS mezi poskytovateli je zásadní a v tomto nastavení se nyní stává odpovědností zákazníka udržovat DNS synchronizované u obou poskytovatelů. Zákazníci tuto synchronizaci obvykle provádějí pomocí automatizačních nástrojů, jako jsou OctoDNS, Terraform, nebo prostřednictvím vlastní automatizace využívající API dodavatelů.

Toto nastavení doporučujeme zákazníkům, kteří chtějí co nejflexibilnější a nejodolnější řešení umožňující aktualizovat záznamy DNS i v případě výpadku systému pro správu záznamů a přenos zóny, případně zákazníkům, kteří chtějí mít nad synchronizací DNS větší kontrolu.

Výhody:

• Pokud je řídicí rovina u jednoho poskytovatele nedostupná, záznamy DNS lze stále aktualizovat u druhého.
• Větší kontrola a žádná závislost na poskytovateli DNS při synchronizaci DNS.

Nevýhody:

• Vyšší složitost udržování synchronizace DNS mezi poskytovateli.
• Za synchronizaci DNS odpovídá zákazník, a to buď pomocí automatizačních nástrojů, automatizovaně přes API dodavatele, nebo ručně.

3. Jeden nebo více autoritativních serverů: skrytý primární a více sekundárních

Při konfiguraci se skrytým primárním serverem uživatelé zřídí neveřejně uvedený primární server pro ukládání všech souborů zón a jejich změn a poté povolí jeden nebo více sekundárních serverů, které přijímají a zodpovídají dotazy. I když je primární server ve většině případů autoritativní, nemusí tomu tak být vždy. V této variantě není primární server uveden u registrátora. Primární server na dotazy neodpovídá a jeho hlavním účelem je být jediným zdrojem pravdy.

Ačkoli sekundární servery v podstatě plní funkci primárního serveru, skryté nastavení umožňuje uživatelům skrýt IP adresu originu a chránit ji před útoky. Primární server lze navíc odstavit pro údržbu, aniž by tím byla narušena služba DNS.

Toto nastavení doporučujeme zákazníkům, kteří oceňují jednoduchost sekundárního DNS a poskytovatele, který udržuje synchronizaci. Toto řešení navíc umožňuje v případě potřeby odstavit primární server s menším dopadem.

Výhody:

• Umožňuje zákazníkům udržovat správu DNS záznamů na vlastní infrastruktuře a používat standardní přenosy zón (Zone Transfers) k automatické synchronizaci DNS.
• Primární server slouží pouze jako zdroj pravdy a ke správě záznamů DNS, a proto ho lze na dobu údržby nebo administrace odpojit.

Nevýhody:

• Pokud je proces správy záznamů a přenosu zón nedostupný, záznamy DNS nelze aktualizovat.
• Někteří klienti nechtějí být závislí na dodavateli nebo třetí straně při synchronizaci DNS a chtějí mít větší kontrolu.

Obrázek 11 znázorňuje typický vzor správy konfigurací současně u Cloudflare i u dalších poskytovatelů. V tomto příkladu předpokládáme, že stejná zátěž je rozdělena mezi oba poskytovatele a administrátorský tým aktualizuje obě konfigurace přes API pomocí Terraformu. Tento postup lze zapojit i do interního CI/CD pipeline, aby odpovídal běžnému vývojářskému workflow. Všechny funkce Cloudflare lze konfigurovat přes API a jsou přes API dostupné jako první. Diagram dále znázorňuje, jak jsou protokoly odesílány do společného SIEM a jak nativní funkce pro upozorňování doručují alerty e-mailem, webhookem nebo přes PagerDuty na základě kritérií výkonu, zabezpečení nebo správy.

Díky široké škále možností přizpůsobení, které Cloudflare nabízí (Ruleset Engine, nativní funkce, úpravy Workerů), dokáže Cloudflare funkčně obvykle dohnat většinu ostatních významných dodavatelů na trhu, není však zaručeno, že se dané funkce budou konfigurovat stejným způsobem. Proto je zásadní úzce spolupracovat s vaším account týmem Cloudflare, abyste pochopili klíčové rozdíly ve fungování a osvědčené postupy pro sladění vašeho workflow s Cloudflare.

U řešení od více dodavatelů je důležité zvážit metody, které každý poskytovatel nabízí pro připojení k originu (originům), a kompromisy v zabezpečení, výkonu a odolnosti. Cloudflare nabízí několik možností, které pokrývají většinu případů užití a lze je nasadit souběžně s granularitou na úrovni jednotlivých aplikací (hostname/DNS záznam) tak, aby vyhovovaly hybridnímu prostředí zákazníka.

V nejzákladnějším scénáři proxy jednoduše směruje provoz přes internet k origin serveru, což je výchozí nastavení u všech poskytovatelů. V tomto nastavení jsou klient i origin server koncové body přímo připojené k internetu přes svého poskytovatele internetových služeb. Požadavek je od klienta směrován přes internet k proxy poskytovatele (na základě konfigurace DNS) a teprve poté jej proxy přesměruje přes internet na origin server zákazníka.

Diagram níže popisuje výchozí připojení k originům, jak požadavky procházejí sítí Cloudflare. Když požadavek dorazí na proxovaný záznam DNS a potřebuje se dostat k originu, Cloudflare odešle provoz ze sítě přes internet z množiny adres vlastněných Cloudflare.

Zákazníci mohou volitelně také využít Dedicated CDN Egress IPs, která přiděluje IP adresy specifické pro daného zákazníka, jež Cloudflare používá pro zpětné připojení k vašim origin serverům. Doporučujeme do allowlistu zařadit provoz pouze z těchto sítí, abyste zabránili přímému přístupu. Kromě blokování IP adres na firewallu origin serveru důrazně doporučujeme provoz dodatečně ověřovat, a to buď pomocí nastavení SSL „Full (Strict)“, nebo pomocí ověřování mTLS, aby bylo jisté, že veškerý provoz pochází z požadavků procházejících přes zákazníkem nakonfigurované zóny.

Cloudflare také podporuje Bring Your Own IP (BYOIP). Po nakonfigurování BYOIP bude globální síť Cloudflare oznamovat vlastní IP prefixy zákazníka a tyto prefixy pak lze používat s příslušnými službami Cloudflare na vrstvě 7.

Další možností je mít privátní tunel nebo připojení přes internet pro vyšší zabezpečení. Někteří dodavatelé nabízejí privátní konektivitu přes tunely nebo VPN, které mohou být šifrované nebo nešifrované; tyto možnosti se liší složitostí správy a vyžadují další úpravy zabezpečení či firewallu, aby bylo možné se připojit. Tradiční nastavení VPN je navíc omezeno centralizovanou lokalitou dodavatele směrem k originu.

Cloudflare nabízí Cloudflare Tunnel což je software pro tunelování, který vytváří šifrovaný tunel mezi vaším origin serverem (servery) a sítí Cloudflare. Cloudflare navíc ve své globální síti využívá anycast, takže se origin server (servery) stejně jako klienti připojí k nejbližšímu datovému centru (centrům) Cloudflare.

Když spustíte tunel, lehký démon ve vaší infrastruktuře, cloudflared, naváže mezi původním serverem a sítí Cloudflare čtyři výhradně odchozí připojení. Tato čtyři připojení směřují na čtyři různé servery rozmístěné alespoň ve dvou různých datacentrech, což zajišťuje vysokou odolnost. Pro zvýšení odolnosti mezi vašimi původními servery a sítí Cloudflare můžete nainstalovat i víc instancí cloudflared.

Cloudflared vytváří šifrovaný tunel mezi vaším origin webovým serverem (servery) a nejbližším datovým centrem (centry) Cloudflare, a to bez otevírání jakýchkoli veřejných příchozích portů. Díky tomu je implementace jednoduchá a rychlá, protože nejsou nutné žádné změny zabezpečení na firewallu. Toto řešení také snižuje riziko chybné konfigurace firewallu, která by mohla vaši firmu vystavit útokům.

Zabezpečení firewallu se posiluje uzamčením všech portů a protokolů originového serveru prostřednictvím vašeho firewallu. Jakmile je zavedený Cloudflare Tunnel a uplatněno příslušné zabezpečení, veškeré požadavky na portech HTTP/S se zahazují, včetně objemových útoků DDoS. Pokusy o únik dat, jako je odposlech dat při přenosu nebo útoky hrubou silou na přihlašování, jsou zcela blokovány.

Výše uvedený diagram popisuje model připojení prostřednictvím Cloudflare Tunnel. Tato možnost umožňuje bezpečně připojit vaše zdroje ke Cloudflare bez veřejně směrovatelné IP adresy. Cloudflare Tunnel dokáže bezpečně připojit ke Cloudflare webové servery HTTP, servery SSH, vzdálené plochy a další protokoly.

Většina dodavatelů také nabízí možnost přímého připojení ke své síti. Přímá připojení přinášejí oproti využívání veřejného internetu výhody v podobě vyšší bezpečnosti, spolehlivosti a výkonu. Realizují se v peeringových centrech, internetových výměnných uzlech (Internet Exchange, IX), kde se mohou vzájemně propojovat poskytovatelé internetových služeb (ISP) a internetové sítě, nebo prostřednictvím partnerů dodavatele.

Výše uvedený diagram popisuje připojení k originu prostřednictvím Cloudflare Network Interconnect (CNI) ↗ což vám umožňuje připojit vaši síťovou infrastrukturu přímo ke Cloudflare a komunikovat pouze prostřednictvím těchto přímých spojení. CNI umožňuje zákazníkům propojit pobočky a centrálu přímo se Cloudflare. Se Cloudflare se lze propojit jedním ze tří způsobů: prostřednictvím privátního síťového propojení (private network interconnect, PNI), dostupného na Peeringová zařízení Cloudflare ↗, prostřednictvím IX na kterékoli z mnoho globálních výměnných uzlů, kterých se Cloudflare účastní ↗, nebo prostřednictvím jednoho z našich partneři propojovacích platforem ↗.

Globální síť Cloudflare umožňuje snadné připojení k síti bez ohledu na to, kde se nachází vaše infrastruktura a zaměstnanci.

Většina dodavatelů navíc nabízí další možnosti vylepšeného či optimalizovaného směrování a doplňkové zabezpečení při komunikaci s origin serverem. Pokud očekáváte srovnatelný výkon a úroveň zabezpečení, ověřte si podporu v dokumentaci příslušného dodavatele.

Cloudflare nabízí Argo Smart Routing k hledání a využívání optimalizovaných tras v síti Cloudflare pro rychlejší doručování odpovědí uživatelům a Authenticated Origin Pulls (mTLS) k ověření, že požadavky na váš origin server pocházejí ze sítě Cloudflare

Argo Smart Routing je služba, která v síti Cloudflare hledá optimalizované trasy, aby uživatelům doručovala odpovědi rychleji.

Argo Smart Routing zrychluje provoz díky tomu, že zohledňuje data v reálném čase a síťové poznatky získané ze směrování více než 28 milionů HTTP požadavků za sekundu; zajišťuje tak, že provoz sítí Cloudflare k origin serveru prochází nejrychlejšími a nejspolehlivějšími cestami. Argo Smart Routing v průměru zrychluje výkon webových prostředků o 30 %.

Cloudflare CDN navíc využívá Argo Smart Routing k určení nejlepších datacenter vyšší vrstvy pro Argo Tiered Cache. Argo Smart Routing lze zapnout, aby se mezi datacentry vyšší vrstvy a origin servery vždy volily nejrychlejší cesty v síti Cloudflare. Bez Argo Smart Routing je komunikace mezi datacentry vyšší vrstvy a origin servery i tak inteligentně směrována kolem problémů na internetu, aby byla zajištěna dosažitelnost originu. Další informace o Argo Smart Routing ve vztahu k CDN najdete v Cloudflare CDN Reference Architecture.

Authenticated Origin Pulls pomáhá zajistit, že požadavky na váš origin server pocházejí ze sítě Cloudflare, což poskytuje další vrstvu zabezpečení nad rámec Full nebo Full (strict) Režimy šifrování SSL/TLS, které Cloudflare nabízí.

Toto ověření nabývá na významu zejména u Cloudflare Web Application Firewall (WAF). Spolu s WAF tak můžete zajistit, že se veškerý provoz vyhodnotí ještě před tím, než dorazí odpověď z vašeho origin serveru.

Pokud chcete, aby vaše doména byla FIPS ↗ kompatibilní, musíte nahrát vlastní certifikát. Tato možnost je dostupná pro obě na úrovni zóny a pro jednotlivé hostitele authenticated origin pulls.

Shrnuto, úspěšná multidodavatelská strategie pro zabezpečení a výkon aplikací vyžaduje pečlivé zvážení obchodních cílů, požadavků na infrastrukturu a možností jednotlivých dodavatelů. Při nasazování multidodavatelské strategie máte na výběr z několika možností, z nichž každá má své výhody i omezení. Cloudflare dokáže tyto konfigurace podpořit tím, že prostřednictvím Cloudflare Global Network poskytuje vysoce odolné, výkonné a nákladově efektivní služby, které odpovídají multidodavatelské strategii vaší organizace.