Síťová architektura aneb rozplétáme cloudové sítě

 

Firemní síťová architektura v cloudu bývá různě komplexní. Jak se v cloudových sítích nezamotat?

Jakub Procházka

 

Síťová architektura v cloudu může být různě komplexní, a to v závislosti na provozovaných službách a potřebách společnosti – provozních, bezpečnostních, legislativních a dalších. Důležité je se v těchto sítích příliš nezamotat, k tomu vám, jak doufám, pomůže tento článek.

 

Virtuální sítě

Elementárním síťovým prvkem v cloudu je virtuální síť neboli virtual network. V Azure bývá zkráceně označována pouze jako VNet, v AWS zase VPC (virtual private cloud). Tento základní stavební kámen síťové infrastruktury, jak už název napovídá, představuje virtuální ekvivalent tradiční sítě spojující systémy do ní zapojené (podobný jako známe z on-premise prostředí).

V některých ohledech se virtuální síť oproti on-premise trochu liší, celkově je ale její tvoření a správa výrazně usnadněné. Již není potřeba běhat do datacentra a zapojovat kabeláž, ani komplikovaně konfigurovat switche a routery. Vše jsme schopni provádět přímo z portálu, případně z CLI (command line), doslova okamžitě.

V případě virtuálních sítí se pohybujeme na úrovni třetí vrstvy (L3) ISO/OSI modelu. To znamená, že nemůžeme například používat VLANy, které jsou na druhé (L2) vrstvě. V cloudu pracujeme od L3 výše (s nutností použít IP protokol).

V průběhu tohoto článku budu popisovat technologie pracující na různých vrstvách, proto je vhodné si OSI model připomenout na obrázku níže.

 

 

IP adresy ve virtuálních sítích

 

Virtuální sítě utvářejí izolovanou, bezpečnou, vysoce dostupnou privátní síť uvnitř cloudového prostředí. Jako každá interní síť i této musí být přiřazen privátní adresní rozsah, konkrétně IPv4 CIDR blok.

Je dobré myslet na to, že vždy přijdeme o pět IP adres z rozsahu – oproti dvěma IP adresám (třem včetně gateway), na které jsme zvyklí z on-premise. Kromě tradiční adresy sítě, broadcastu a gateway nám totiž AWS i Azure rezervuje vždy další dvě IP adresy pro DNS a „budoucí užití“. Nejmenší podporovaná síť je s prefixem /29 (dostaneme tři volné IP) a největší pak /8 (16 777 211 volných IP adres).

Oba zmiňovaní provideři rovněž podporují i IPv6, resp. dual stack (IPv4/IPv6). Dual stack virtuální sítě umožňuje aplikacím připojení přes IPv4 i IPv6 ke zdrojům uvnitř sítě nebo i do internetu. U obou poskytovatelů také platí, že IPv6 rozsah musí být přesně /64.

 

 

Jedná se o privátní adresní rozsahy, nemusíme s nimi tedy šetřit. I tak je vhodné si celkovou architekturu předem naplánovat a rozmyslet. To probíhá v rámci příprav tzv. landing zone.

Přestože virtuální sítě jsou izolované prvky, neměli bychom adresní rozsahy překrývat (to platí i pro adresy nacház

ející se na on-premise). Je to především kvůli plánování do budoucna. Ve chvíli, kdy bychom propojili stejné adresní rozsahy mezi sebou, došlo by k nevyzpytatelnému chování, až k celkovému výpadku.

 

Jmenné konvence a segmentace sítě

Pro virtuální sítě je vždy vhodné definovat si jmennou konvenci a tu pak dodržovat. Obecné doporučení je uvádět typ zdroje, jméno aplikace, prostředí, region, samotné pořadí. VNet v Azure by se tak mohl jmenovat například vnet-shared-eastus2-001.

 

 

Adresní rozsah musí vždy obsahovat subnety, a to minimálně jeden. To samozřejmě většinou není optimální řešení. Na segmentaci sítě aplikujeme obdobnou logiku, jakou známe z on-premise. Tu většinou definuje network tým společně se security týmem.

Musíme pouze pamatovat na to, že nepoužíváme VLANy. Typicky tak pro aplikaci máme minimálně nějaký frontend a backend subnet. Dále můžeme mít vlastní subnet pro storage, AKS a další.

Zlaté pravidlo je nechávat si při adresaci dostatečnou rezervu, přeadresovaní totiž může být problematické. Raději přiřadíme více adres a nevyužijeme je, než bychom jich přiřadili méně, a zadělali si tak v budoucnu na potíže. Pokud si nejste jisti, s adresním rozsahem /16 a subnety /24 většinou chybu neuděláte.

 

 

Méně je někdy více

Virtuální sítě jsou zdarma – nezáleží na jejich počtu, adresním rozsahu, ani na počtu subnetů. Doporučení je však to s nimi nepřehánět, protože více sítí se hůře spravuje a celkově bychom prostředí znepřehlednili či zkomplikovali.

Obecně lze doporučit dělení VNet/VPC například dle regionu, prostředí, oddělení či aplikace. Pokud spolu mají zdroje komunikovat, mohou být ve stejné síti, a vyhnou se tak zbytečnému peeringu.

Izolaci a bezpečnost lze do určité míry řídit pomocí security group, které podrobněji popíšu v další části článku. Pokud mají naopak aplikace spravovat různé týmy a potřebují konfigurovat síť, bude vhodnější je rozdělit.

Limity počtu virtuálních sítí se u poskytovatelů výrazně liší: Azure má limit 1000 virtuálních sítí per předplatné a 3000 subnetů per VNet. AWS má defaultní limit 5 VPC per region (může být navýšen na 100) a 200 subnetů per VPC.

 

Network design

U obou poskytovatelů platí, že virtuální sítě jsou region dependent. To znamená, že není možné roztáhnout jednu síť přes více regionů. Zdroje připojené do VNet/VPC musí být vždy ve stejném regionu. Výjimkou jsou některé globální služby typu CDN, které nemají definovaný region, případně jen pro metadata.

Pokud chceme komunikovat se zdroji mimo region/VNet, můžeme mezi sítěmi nastavit peering. Peering samotný je zdarma, ale platí se za data, která přes něj protékají.

Integrace sítí a PaaS

Až na výjimky potřebuje většina služeb ke svému provozu zmiňované virtuální sítě, do kterých se připojí. PaaS služby v drtivé většině rovněž podporují integraci s VNet/VPC, ale některé jsou schopné fungovat i bez jejího připojení.

V takovém případě se připojují na interní virtuální síť, kterou v portálu uživatel nevidí a nemá možnost ji ani nijak spravovat. Dle konkrétních PaaS služeb mohou být dostupné další funkcionality jako firewall, dns apod. Komunikace pak probíhá po backbone síti cloud poskytovatele, případně přes internet a umožní službě například přístup do internetu, připojení veřejné IP adresy a ochranu před DDoS. Příkladem takové služby je App service/Elastic Beanstalk, kam se uživatelé připojují pouze z internetu.

Služby nepřipojené do zákaznické sítě jsou však spíše ojedinělé případy a ve spoustě z nich bych i tak zvážil komunikaci v rámci VNet kvůli bezpečnosti. Té můžeme dosáhnout pomocí service a private endpointů, o kterých budu psát detailněji dále.

Integrace cloudových sítí a on-premise prostředí

Pro propojení s on-premise uvažujeme buď o Site-to-site VPN nebo v lepším případě o Express route/Direct connect (nebo o kombinací obojího).

S2S VPN jako šifrovaný tunel internetem představovat nemusím, Express route (Azure) a Direct connect (AWS) jsou služby pro vytvoření privátní dedikované linky mezi on-premise datacentrem a datacentrem poskytovatele. Tyto linky jsou více spolehlivé, rychlejší a poskytují nižší latence než v případě komunikace po internetu.

Pokud jde traffic přes Express route/Direct connect, platí se dle ceníku služby. Jinak se platí klasicky za datový provoz z cloudu, tzv. egress. Za ingress (upload dat do Azure) se neplatí, jak bylo zmíněno v mém předchozím článku.

 

Jak je to s izolací sítě a subnetů?

Díky vlastnosti izolace na sebe VNets/VPC ve výchozím stavu nevidí – zdroje spolu nekomunikují, nebo komunikují méně bezpečně mimo VNet (internet, interní Azure síť).

To lze v případě potřeby „obejít“ nastavením již zmiňovaného peeringu mezi VNety. Provoz přes peering není zadarmo, zpoplatněn je jak egress z odchozí VNet, tak i ingress do cílové. Ceny se liší i podle toho, zda je peering v rámci regionu nebo mezi regiony. Peering v rámci regionu je levnější, ale ani v případě globálního peeringu se nejedná o závratné částky (nicméně je dobré na to pamatovat).

Subnety slouží k rozdělení adresního rozsahu do více bloků pro lepší přehlednost, segmentaci, ale i bezpečnost. Na rozdíl od VNet/VPC není komunikace mezi subnety v rámci jedné virtuální sítě nijak defaultně omezena. Zdroje nejsou subnety izolovány a mohou mezi sebou komunikovat. Tuto komunikaci lze omezit pomocí security group.

Základní síťový firewalling

Když dojde na první filtrování a omezování provozu, začneme se bavit o bezpečnostních skupinách (security groups). Ty se v AWS nazývají AWS Security groups a v případě Azure Network security groups (NSG). Jedná se o základní firewall, který lze připojit na celý subnet nebo na konkrétní VM/EC2, resp. na jejich síťovou kartu (NIC). Zjednodušeně jde o seznam pravidel pro odchozí a příchozí traffic. Tato pravidla mají různé priority, podle kterých se následně vyhodnocují (podobný princip jako např. iptables).

Pro představu: v Azure musí security pravidlo obsahovat vždy zdroj, rozsah portu, cíl, protokol (any/tcp/udp/icmp), akci (deny/allow) a prioritu. Zdroj může mít hodnotu Any, IP adresu, service tag anebo Application security groupu. Service tag je označení skupiny definovaných skupin, jako například internet, virtual network atp. Cíl může být Any, IP, VNet, Application security groupa.

Příklad: Zakázán všechen (ANY) inbound s prioritou 1000 a povolen port 80 z internetu s prioritou 500. Pokud v takovém případě přijde na NSG packet z internetu na port 80 cílové IP, bude povolen, cokoli jiného bude zahozeno. Pokud by měl zákaz inboundu větší prioritu (nižší číslo), komunikace na port 80 by byla rovněž zahazována.

Síťové topologie

Asi nejčastější topologie, se kterou se v cloudu setkáváme i my v ORBITu, je hub and spoke. V této topologii je jedna centrální VNet/VPC, která slouží pro připojení VPN (ať už S2S nebo P2S) a ve které jsou připojeny sdílené služby pro ostatní sítě.

Tato síť má pak nastaven peering mezi ostatní. Tím, že není nastaven peering mezi jednotlivými VNet (vždy pouze mezi hub sítí a spoke sítí) a není na peeringu hub sítě povolen forwarding, jednotlivé VNet zůstávají navzájem izolované. Drobná nevýhoda je, že v případě přidání nové sítě je vždy nutné nastavovat i její peering s hub sítí.

 

 

Kromě hub to spoke topologie se ještě často setkáváme s konceptem single NVA (network virtual appliances), kdy je provoz směrován přes bezpečnostní appliance pro kontrolu odchozího i příchozího provozu. NVA je v tomto případě single point of failure, proto se musí nasazovat v HA režimu. NVA zajišťuje, že projde pouze provoz splňující jasně definovaná kritéria.

 

 

Servisní a privátní linky

V předchozích odstavcích jsem zmínil možnou integraci PaaS služeb s klientskými sítěmi. Tu lze provést dvěma způsoby, které se liší z hlediska bezpečnosti. Prvním způsobem je service endpoint, kterým povoluji připojení do subnetu určité skupině služeb. Druhou variantou je private endpoint, který mapuje konkrétní resource přímo do VNet – vytvoří se pro něj nová NIC (podobně jako pro VM).

Zatímco service endpoint se nastavuje na subnet, private endpoint se nastavuje přímo na PaaS službě.

 

 

Obě varianty snižují riziko vystavení zdrojů přímo do internetu a umožňují napojení security group (u PEP dokonce na úrovni NIC). Ani v jednom případě komunikace neprochází mimo síť poskytovatele.

Jsou zde ale dva zásadní rozdíly. Jeden spočívá v rozsahu: private endpoint připojí konkrétní zdroj a vytvoří mu NIC, service endpoint povolí připojení pro všechny zdroje stejného typu (např. všechny storage accounty v daném tenantu).

Druhý je ve způsobu připojení: zatímco service endpoint v podstatě „rozšíří“ existující adresní rozsah dané sítě o service (komunikace zůstává na backbone poskytovatele), private endpoint rozšíří konkrétní service do dané VNet.

 

Ochrana před DDoS útoky

Všechny Azure i AWS zdroje jsou chráněny základní DDoS ochranou, která je zdarma a bez nutnosti konfigurace. V Azure je to DDoS Basic, v AWS Shield Standard. Dále existují placené varianty – v Azure DDoS Standard a v AWS Shield Advanced. Placené varianty nepatří mezi nejlevnější služby, ale přinášejí oproti základnímu plánu některé přidané funkcionality – viz následující obrázek.

 

 

Cena placené varianty DDoS ochrany, která kryje až 100 veřejných IP adres, je u obou poskytovatelů cca 3000 USD za měsíc. Každý další zdroj, resp. chráněná veřejná IP adresa nad limit, stojí 30 USD měsíčně. Dobré je, že pod tenantem je možné mít jeden Standard plán pro celý tenant napříč subskripcemi.

 

Aplikační load balancing

Nezanedbatelnou součást sítí jsou i load balancery. Kromě těch klasických, které pracují na L4 vrstvě, cloud provideři rovněž poskytují i pokročilejší aplikační load balacery (v Azure application gateway), které pracují na sedmé vrstvě (L7) OSI modelu, a podporují tak některé další funkce, jako například cookie-based session affinity.

Tradiční load balancery na čtvrté transportní vrstvě pracují na úrovni TCP/UDP a směrují traffic dle zdrojové IP adresy a portu na cílovou IP adresu a port. Oproti tomu aplikační load balancery mohou provádět rozhodnutí na základě konkrétního HTTP požadavku. Dalším příkladem může být směrování dle příchozí URL.

Aplikační load balancery mohou fungovat i jako aplikační firewall neboli web firewall. Díky tomu, že fungují na aplikační vrstvě, se jedná o výrazně pokročilejší ochranu oproti například zmiňovaným security grupám. Web application firewall (WAF) představuje centralizovanou ochranu proti různým explotům a dalším zranitelnostem (příkladem útoků mohou být SQL injection nebo cross-site scripting).

 

 

Zrychlení a vyrovnání výkonu webových aplikací

Azure FrontDoor a AWS Global Accelerator jsou globální služby pracující na sedmé vrstvě (L7), jejichž cílem je zvýšení výkonu pro cílové uživatele po celém světě. Uvádí se, že tyto služby dovedou vylepšit výkonnost až o 60 %.

Některé výhody Azure Front Door:

• akcelerace výkonu aplikací využitím split TCP-based anycast protokolu
• inteligentní monitoring zdraví backend zdrojů
• URL-path based směrování
• hosting více webových stránek pro efektivní aplikační infrastrukturu
• cookie-based session affinity
• SSL offloading a certifikační management
• definování vlastní domény
• aplikační bezpečnost s integrovaným Web Application Firewallem (WAF)
• přesměrování HTTP provozu na HTTPS s URL redirect
• URL rewrite
• nativní podpora end-to-end IPv6 připojení a HTTP/2 protokolu

 

 

Traffic manager & Route 53

Nyní se dostáváme mimo OSI model. Služby Traffic manager (Azure) nebo Route 53 (AWS) totiž nepracují na žádné jeho vrstvě, ale jsou založené na DNS.

Traffic manager je DNS-based load balancer, který umožňuje distribuovat provoz pro aplikace dostupné z internetu napříč regiony. Zároveň poskytuje pro tyto veřejné endpointy vysokou dostupnost a rychlou odezvu.

Co to všechno znamená? Zjednodušeně jde o způsob, jak směrovat klienty na odpovídající endpointy. Traffic manager má několik možností, jak toho docílit:

• Priority routing
• Weight routing
• Performance routing
• Geographic routing
• Multivalue routing
• Subnet routing

Tyto metody lze kombinovat pro zvýšení komplexnosti výsledného scénáře tak, aby byl co nejvíce flexibilní a sofistikovaný.

Zároveň je automaticky monitorováno zdraví jednotlivých regionů a pokud dojde k výpadku, je provoz přesměrován.

 

 

Závěrem

Dnešní článek byl trochu techničtější a obsáhlejší než předchozí. Prošli jsme si ale společně všemi klíčovými součástmi cloudových sítí a korespondujících služeb, které umí pracovat na různých vrstvách OSI modelu (konkrétně L3–L7).

Cílový koncept cloudových sítí se může velmi různit v závislosti na aplikaci, firemních a bezpečnostních politikách, ale i na limitovaném budgetu. I pro sítě platí, využívat pouze to, co nám dává smysl a přináší dostatečné benefity s ohledem na svou cenu. Placený DDoS plán se nám může líbit, ale pokud jsme začínající startup, pravděpodobně se bez něj obejdeme a raději 3000 USD (cca 65 tis. Kč) měsíčně uspoříme.

Ať už se v oblasti sítí a cloudu pohybujete více či méně, věřím, že vám dnešní článek poodhalil benefity, na které můžete správnou architekturou sítí dosáhnout.

Pokud vás v souvislosti s cloudem zajímají i jiná témata, přečtěte si náš seriál Encyklopedie cloudu – stručný průvodce cloudovým prostředím.