Síť do cloudu a VPN do cloudu

Jak vypadá cloud očima sítě: cloud jako cizí datacentrum za sítí a sdílená odpovědnost, otevřený bucket jako otevřená zóna, site-to-site a remote-access VPN do cloudu, publikace služby přes veřejnou IP a DNAT, load balancer před web farmou, cloud DMZ a bezpečnostní skupiny s výchozím zákazem, a odolnost přes multi-WAN, zálohy a regiony.

Lekce 1: Cloud není kouzlo

Cloud je cizí datacentrum za sítí

Slovo „cloud" zní jako něco éterického, ale je to velmi přízemní věc: cizí datacentrum, ke kterému se dostaneš po síti. Když si u poskytovatele založíš cloud, dostaneš v jeho hale kus výpočetního výkonu a k němu virtuální síť – anglicky VPC (virtual private cloud). Z pohledu tvého síťového návrhu to není nic nového pod sluncem: je to prostě další lokalita za routerem, stejně jako pobočka v jiném městě. Má svoje podsítě, svoje IP adresy a je od tebe oddělená sítí, kterou nevlastníš – internetem. A právě proto pro ni platí úplně stejná pravidla, na která jsi zvyklý z fyzické sítě: aby se tvůj počítač dostal na server v cloudu, musí existovat průchodná cesta (směrování) a někdo ji musí povolit (firewall). Nic tam neteče kouzlem. Lidé, kteří cloud znají z aplikační strany – klikli na „vytvořit server" a za minutu běžel – často přeskočí právě tuhle vrstvu a diví se, proč se k databázi nepřipojí. Odpověď je skoro vždycky stejná jako v kterékoli jiné síti: chybí cesta, nebo je zavřený port. V tomto kurzu se na cloud díváme očima sítě, ne očima vývojáře: kudy provoz teče, kde se kontroluje a kdo za co odpovídá.

Krok za krokem

Cloud je cizí datacentrum. Uvnitř máš vlastní virtuální síť (VPC) s podsítěmi a adresami – jako pobočka v jiném městě.
Z firmy jde provoz přes switch a firewall do internetu – úplně stejně jako u kterékoli jiné vzdálené lokality.
Do VPC se vstupuje přes cloudovou bránu (CG). Aby ses dostal na server, musí existovat cesta a někdo ji musí povolit.
Když se v cloudu nic nepřipojí, příčina je skoro vždy stejná jako jinde: chybí cesta, nebo je zavřený port.

Sdílená odpovědnost

Nejdůležitější věc, kterou si o cloudu musíš srovnat v hlavě, není technická – je to otázka odpovědnosti. Když si server postavíš u sebe, hlídáš všechno: budovu, elektřinu, hardware, operační systém i data. V cloudu se ta odpovědnost rozdělí na dva díly a mezi nimi vede hranice, které se říká sdílená odpovědnost. Poskytovatel hlídá to pod čarou: fyzické datacentrum, napájení, hardware a virtualizační vrstvu. Ty hlídáš to nad čarou: svoje data, svoje účty a hesla, nastavení svých serverů a hlavně síťová pravidla – kdo se kam smí připojit. Přesně kudy ta čára vede, závisí na typu služby – u pronajatého serveru (IaaS) hlídáš skoro všechno nad hardwarem, u hotové aplikace (SaaS) už jen svá data a přístupy – ale jedna věc platí vždycky: za svá data a za to, komu je zpřístupníš, odpovídáš ty. Poskytovatel ti dá pevný trezor, ale jestli necháš dveře otevřené, je to na tobě. Tohle je nejčastější zdroj nedorozumění: lidé slyší „cloud je bezpečný" a rozumí tomu jako „o bezpečnost se stará někdo jiný". Poskytovatel se opravdu stará – ale o svoji půlku. Ta druhá, na které stojí většina skutečných průšvihů, je tvoje. A dobrá zpráva zní, že je to přesně ta půlka, kterou už umíš: segmenty, pravidla, nejmenší oprávnění. Cloud tu nevymýšlí nic nového, jen ti to nastavení dá do ruky přes webové rozhraní.

Krok za krokem

Poskytovatel hlídá to pod čarou: fyzické datacentrum, napájení, hardware a virtualizaci. To je jeho půlka.
Ty hlídáš to nad čarou: svá data, účty a hesla, nastavení serverů a hlavně síťová pravidla – kdo se kam smí připojit.
„Cloud je bezpečný" neznamená „stará se o to někdo jiný". Poskytovatel dá trezor – otevřené dveře k datům jsou tvoje chyba.
Tvoje půlka je přitom ta, kterou už znáš: segmenty, pravidla, nejmenší oprávnění. Cloud ti je jen dá do ruky přes web.

Otevřený bucket = otevřená zóna

Ukažme si nejčastější cloudovou chybu na konkrétním případu, protože se opakuje pořád dokola a stála už mnoho firem únik dat. Bucket je cloudové úložiště souborů – představ si sdílenou složku, do které aplikace ukládá zálohy, faktury nebo fotky uživatelů. Ve výchozím stavu je soukromý: dostane se k němu jen ten, komu to dovolíš. Jenže při vývoji se často stane tohle: něco nefunguje, „na chvilku" se úložiště přepne na veřejné, aby se to rozjelo, a už to tam zůstane. Od té chvíle je obsah dostupný komukoli na internetu, kdo zná adresu – a adresy se dají uhodnout nebo najít. Z pohledu sítě je to přesně to samé, co jsi v kurzu Zabezpečení sítě viděl u zón: veřejně otevřený bucket je otevřená zóna. Rozdíl je jen v tom, že v cloudu nemusíš přepojovat kabely – stačí jedno políčko ve webovém rozhraní, a proto se ta chyba udělá tak snadno a tak tiše. Nikde nezačne svítit červená, nic nespadne, aplikace jede dál. Poučení má dvě části. Za prvé: výchozí stav nech soukromý a veřejné dělej jen to, co veřejné opravdu být má (o tom je celá lekce 4). Za druhé: ptej se u každého úložiště úplně stejnou otázkou jako u firewallového pravidla – kdo přesně se k tomu má dostat a proč? Když na to neumíš odpovědět, patří to soukromé.

Krok za krokem

Bucket je cloudové úložiště souborů: zálohy, faktury, fotky. Ve výchozím stavu je soukromý – dostane se k němu jen ten, komu dovolíš.
Při vývoji se úložiště „na chvilku" přepne na veřejné, aby se něco rozjelo – a už to tam zůstane. Jedno políčko ve webu.
Od té chvíle se k obsahu dostane kdokoli z internetu, kdo zná adresu. Nikde nesvítí červená, aplikace jede dál.
Veřejný bucket je otevřená zóna. Nech výchozí stav soukromý a ptej se jako u pravidla: kdo přesně se k tomu má dostat a proč?

▶ Otevřít v simulátoru

Lekce 2: Site-to-site VPN do cloudu

Trvalý tunel mezi firmou a cloudem

Když má firma v cloudu servery, které mají zůstat soukromé – databázi, interní aplikaci, sdílené disky – nechce je vystavovat do internetu. Potřebuje, aby se k nim dostala jen ona, a to bezpečně. Přesně na to slouží site-to-site VPN: trvalý šifrovaný tunel mezi firemní sítí a cloudovou sítí (VPC). „Site-to-site" znamená „síť k síti" – nepropojuje jednoho uživatele, ale celou lokalitu s celou lokalitou. Postaví se jednou, mezi firemním firewallem a cloudovou bránou, a pak jede pořád: zapnutý počítač v kanceláři vidí databázi v cloudu, jako by stála ve vedlejší místnosti. Klíčové je pochopit, co tunel vlastně dělá. Provoz z firmy do cloudu jde fyzicky pořád přes internet – jinou cestou to nejde, poskytovatele nevlastníš. Tunel ho ale zabalí a zašifruje, takže po cestě přes cizí sítě vidí kdokoli jen nesrozumitelný balík, ne obsah. Z pohledu adres a směrování se přitom cloud chová jako běžná vzdálená podsíť: firemní počítače na ni míří stejně, jako by mířily na pobočku připojenou pevnou linkou. Tohle je základní stavební kámen připojení do cloudu a v simulátoru si ho postavíš na úloze „Site-to-site VPN". Detailně, co VPN je a jak šifruje, rozebírá kurz Zabezpečení sítě; tady nás zajímá její role v návrhu: jak spojit firmu s cloudem tak, aby soukromé zůstalo soukromé.

Krok za krokem

Databáze a interní servery v cloudu mají zůstat soukromé. Nechceš je vystavit do internetu, ale musíš se k nim dostat.
Site-to-site VPN je trvalý tunel mezi firemním firewallem a cloudovou bránou. Postaví se jednou a jede pořád.
Zapnutý počítač v kanceláři pak vidí databázi v cloudu, jako by stála ve vedlejší místnosti – cloud je běžná vzdálená podsíť.
Provoz jde fyzicky přes internet, ale tunel ho zabalí a zašifruje – po cestě vidí kdokoli jen nečitelný balík.

Co tunelem teče a co ne

Tunel do cloudu stojí, teď přijde otázka, kterou lidé podceňují: co jím vlastně má téct? Lákavá odpověď je „všechno" – propojím firmu s cloudem a je hotovo. Jenže tunel je pořád jen cesta, ne povolení. To, že mezi firmou a cloudem existuje průchodné spojení, neznamená, že jím má chodit každý ke každému. Platí tu úplně stejné pravidlo jako uvnitř sítě: nejmenší oprávnění. Tunelem má téct jen ten provoz, který k práci opravdu potřebuješ – účetní aplikace na databázi, zálohovací server na úložiště – a nic víc. Zbytek se na obou koncích tunelu zakáže, přesně jako mezi dvěma segmenty. Druhá věc, kterou je potřeba si ujasnit: ne všechno musí do cloudu tunelem. Když zaměstnanec otevře veřejný web nebo cizí službu, nemá důvod cpát ten provoz nejdřív do cloudu a odtud ven – jde rovnou do internetu firemní linkou. Tomu, které cíle se posílají tunelem a které přímo, se říká rozdělené směrování (split tunnel): do cloudu jen adresy cloudu, zbytek napřímo. Opak – hnát všechno přes jeden konec – se někdy dělá schválně (aby veškerý provoz procházel firemní kontrolou), ale platí se za to výkonem a je to volba, kterou máš udělat vědomě. Shrnutí, které si odnes: tunel řeší bezpečné spojení, ale co jím smí je pořád tvoje rozhodnutí – a děláš ho pravidly, ne tím, že tunel prostě otevřeš.

Krok za krokem

Lákavé je pustit tunelem všechno. Jenže tunel je jen cesta, ne povolení – „všechno" je vypnutá kontrola.
Platí nejmenší oprávnění: tunelem teče jen nutný provoz – účetní na databázi, záloha na úložiště. Zbytek se zakáže.
Rozdělené směrování: veřejný web nemá důvod chodit přes cloud – jde do internetu napřímo. Do tunelu jen adresy cloudu.
Tunel řeší bezpečné spojení, ale co jím smí je pořád tvoje rozhodnutí – a děláš ho pravidly, ne tím, že tunel otevřeš.

Když tunel spadne

Trvalý tunel má jednu vlastnost, na kterou se v nadšení ze zprovoznění zapomíná: je to jediná cesta k soukromým serverům v cloudu – a jednou spadne. Ne možná, ale jistě. Internetová linka vypadne, poskytovatel má údržbu, cloudová brána se restartuje. A ve chvíli, kdy tunel není, se stane přesně tohle: databáze v cloudu je úplně nedostupná, protože jsi ji – správně – nevystavil do internetu, takže jiná cesta k ní neexistuje. Aplikace, které na ní stojí, se zastaví, i když samy běží dál. Tohle je jediný bod selhání a řeší se stejně jako kdekoli jinde v síti (podrobně v kurzu Odolnost a škálování sítě): zdvojením. Buď postavíš druhý tunel přes jinou internetovou linku, nebo přes druhou cloudovou bránu – ideálně obojí, aby výpadek jedné linky ani jedné brány neodřízl firmu od jejích dat. Poskytovatelé s tím počítají a nabízejí bránu ve dvou kusech; ty musíš na svém konci mít dvě linky a nastavit, aby se provoz při výpadku přepnul na záložní tunel. Druhá věc, kterou je potřeba předem promyslet: co dělá aplikace, když data nejsou? Má srozumitelně říct „momentálně nedostupné", ne zamrznout nebo tiše ztrácet objednávky. Střízlivý závěr: připojení do cloudu není hotové tím, že tunel jednou nabolí. Hotové je tehdy, když víš, co se stane, až spadne – a máš na to připravenou druhou cestu.

Krok za krokem

Dokud tunel jede, firemní počítač se přes něj dostane k databázi v cloudu. Zatím je vše v pořádku.
Jednou linka vypadne a tunel spadne. Byla to jediná cesta – databáze jsi správně nevystavil do internetu.
Databáze je úplně nedostupná a aplikace nad ní se zastaví, i když samy běží. To je jediný bod selhání.
Řešení je zdvojení: druhý tunel přes jinou linku nebo bránu. A promysli, co dělá aplikace, když data nejsou.

▶ Otevřít v simulátoru

Lekce 3: Vzdálený přístup do cloudu

Remote-access vs. site-to-site

Site-to-site tunel propojí celou firmu s cloudem – hodí se, když spolu mají trvale mluvit servery a aplikace. Jenže často potřebuješ něco jiného: dostat do cloudu jednoho člověka, který zrovna sedí doma nebo v hotelu. Na to je remote-access VPN (VPN pro vzdálený přístup). Rozdíl je v tom, kdo je na koncích. U site-to-site jsou na obou koncích sítě a tunel drží pořád mezi dvěma krabicemi (firewall a cloudová brána). U remote-access je na jednom konci jeden uživatel se svým notebookem a tunel vzniká na chvíli, když se přihlásí, a zmizí, když skončí. Uživatel spustí klienta VPN, přihlásí se – ideálně s vícefaktorovým ověřením – a jeho notebook se na dobu spojení chová, jako by byl uvnitř cloudové sítě. Druhý rozdíl je v počtu: site-to-site postavíš jednou pro celou pobočku, remote-access řeší desítky nebo stovky jednotlivců, kteří se připojují a odpojují během dne. Proto se u něj řeší věci, které u trvalého tunelu nedávají smysl: silné ověření každého člověka zvlášť, odebrání přístupu při odchodu zaměstnance, a hlavně kam až se přihlášený uživatel dostane. To poslední je nejčastější chyba a věnujeme se jí ve třetím modulu. Zapamatuj si jednoduché rozlišení: site-to-site spojuje místa, remote-access spojuje lidi. Obojí končí ve stejném cloudu, ale řeší jiný problém – a v simulátoru si remote-access postavíš na úloze „Remote-access VPN".

Krok za krokem

Site-to-site: na obou koncích jsou sítě a tunel drží pořád mezi firewallem a cloudovou bránou. Spojuje místa.
Remote-access: na jednom konci je jeden uživatel s notebookem. Tunel vzniká při přihlášení a mizí při odhlášení.
Po přihlášení – ideálně s vícefaktorovým ověřením – se notebook chová, jako by byl uvnitř cloudové sítě.
Jednoduché rozlišení: site-to-site spojuje místa, remote-access spojuje lidi. Obojí končí ve stejném cloudu.

Uživatel z internetu do cloudu

Projděme si krok za krokem, co se stane, když se vzdálený uživatel připojí do cloudu – protože je v tom pár míst, kde se dá chybovat. Uživatel je někde na internetu: doma, v kavárně, na cizí Wi-Fi, o které nic nevíš. Spustí klienta VPN a ten se ozve na veřejnou adresu cloudové brány – to je jediný bod cloudu, který musí být vidět z internetu, aby se vůbec dalo přihlásit. Následuje ověření identity: uživatel prokáže, kdo je (heslo a druhý faktor), a teprve pak brána tunel otevře. Do téhle chvíle se přes bránu nedostane nic jiného než samotné přihlášení – to je důležité, protože veřejná adresa brány je terč, na který se pořád někdo pokouší. Po úspěšném přihlášení dostane notebook adresu z cloudové sítě a od té chvíle se v ní pohybuje jako místní zařízení: může na servery, na které má povoleno. A přesně tady číhá past, kterou uvidíme podrobně v příštím modulu: na které servery vlastně má? Když se po přihlášení dostane na všechno, právě jsi z pohodlného vzdáleného přístupu udělal širokou vstupní bránu do celého cloudu. Dvě věci si z tohoto průchodu odnes. Za prvé: veřejná je jen brána, ne servery – databáze ani interní aplikace nikdy nemají svou vlastní veřejnou adresu, chodí se k nim až tunelem. Za druhé: tunel bez ověření je jen otevřené dveře – u vzdáleného přístupu je silné ověření každého člověka to, co drží celý model pohromadě.

Krok za krokem

Uživatel je někde na internetu a klient VPN se ozve na veřejnou adresu cloudové brány – jediný bod cloudu vidět zvenčí.
Následuje ověření identity: heslo a druhý faktor. Teprve pak brána tunel otevře – do té chvíle neprojde nic jiného.
Po přihlášení dostane notebook adresu z cloudové sítě a chodí na servery, na které má povoleno. Ale na které vlastně?
Odnes si dvě věci: veřejná je jen brána, ne servery, a tunel bez ověření jsou jen otevřené dveře.

Rozdíl přístupů

Teď oba druhy VPN postavme vedle sebe a řekněme, kdy použít který – a jaké chyby se u nich dělají. Site-to-site zvol, když spolu mají trvale mluvit systémy: firemní aplikace s cloudovou databází, zálohy do cloudu, propojení pobočky. Postaví se jednou, běží bez zásahu člověka a nikdo se u něj nepřihlašuje. Remote-access zvol, když se do cloudu (nebo do firmy) potřebují dostat lidé odjinud než z kanceláře. Obě mají společné jádro – šifrovaný tunel – ale liší se v tom, co u nich musíš hlídat. U site-to-site je hlavní riziko, že tunelem pustíš víc, než je potřeba; hlídáš tedy pravidla na obou koncích. U remote-access je hlavní riziko u lidí: slabé heslo, chybějící druhý faktor, nezrušený přístup po odchodu zaměstnance – a hlavně příliš široká oprávnění po přihlášení. Tady platí přesně to, co říká Zero Trust a co znáš z kurzu Zabezpečení sítě: VPN sama o sobě není bezpečnost. Když tunel doručí uživatele do sítě, kde smí na všechno, jen jsi útočníkovi prodloužil kabel až domů. Vzdálený uživatel má mít stejně úzká oprávnění jako v kanceláři, ne širší – tunel řeší jen bezpečný vstup, ne to, co smíš uvnitř. Praktické shrnutí: nejdřív si ujasni, jestli propojuješ místa, nebo lidi; podle toho vyber druh VPN; a v obou případech nezapomeň, že za bezpečné spojení pořád musí přijít pravidlo, které říká kam.

Krok za krokem

Site-to-site zvol, když spolu mají trvale mluvit systémy. Hlavní riziko: pustíš tunelem víc, než je potřeba.
Remote-access zvol pro lidi odjinud než z kanceláře. Hlavní riziko je u lidí: slabé ověření a příliš široká oprávnění.
VPN sama není bezpečnost: když tunel končí tam, kde smíš na všechno, jen jsi útočníkovi prodloužil kabel až domů.
Vzdálený uživatel má mít stejně úzká oprávnění jako v kanceláři. Za spojení musí přijít pravidlo, které říká kam.

▶ Otevřít v simulátoru

Lekce 4: Publikace služby

Veřejná IP a DNAT

Zatím jsme řešili, jak se do cloudu dostaneš ty. Teď obráceně: máš v cloudu web, který má vidět celý svět – zákazníci, kdokoli. Tady VPN nepomůže; web má být veřejný. Jak to funguje? Server v cloudu má vnitřní adresu z tvé VPC, kterou zvenčí nikdo nevidí – je to soukromá adresa jako každá jiná v interní síti. Aby na něj mohl někdo z internetu, přidělíš službě veřejnou IP adresu: jednu adresu, která je vidět z celého světa a kterou si zapíšeš do DNS pod jméno (třeba shop.firma.cz). Když teď přijde návštěvník, míří na tuhle veřejnou adresu – a na hranici cloudu se stane překlad, který znáš z kurzu Zabezpečení sítě: DNAT (překlad cílové adresy). Cloudová brána vezme paket mířící na veřejnou adresu a přepíše cíl na vnitřní adresu web serveru – je to stejný princip jako port forwarding, který znáš z kurzu Router do hloubky, jen na hranici cloudu; odpověď se cestou zpět přeloží zpátky. Návštěvník o vnitřní adrese nikdy neví a web server o veřejné taky ne – každý mluví se svou stranou. Dvě věci jsou tu klíčové. Za prvé: veřejná IP a DNAT samy o sobě nic nechrání – jen otevírají cestu dovnitř. Co je za nimi dostupné, rozhoduje pravidlo (o tom je lekce 5), a špatně nastavený DNAT umí vystavit i to, co nemělo být vidět. Za druhé: veřejnou adresu dává jen ta služba, která má být venku. Databáze za webem žádnou veřejnou adresu nemá a mít nesmí – chodí se k ní jen zevnitř. Přesně tak vypadá zdravý poměr: jedna veřejná tvář, zbytek schovaný.

Krok za krokem

Web server má vnitřní adresu z tvé VPC – soukromou, jako v interní síti. Zvenčí ji nikdo nevidí.
Aby na web mohl svět, přidělíš službě veřejnou IP a zapíšeš ji do DNS pod jméno (shop.firma.cz).
Návštěvník míří na veřejnou adresu; na hranici DNAT přepíše cíl na vnitřní adresu webu. Každý mluví se svou stranou.
Veřejnou adresu dává jen služba, co má být venku. Databáze za webem veřejnou adresu nemá a mít nesmí.

Load balancer před web farmou

Jeden web server zvládne jen určitý počet návštěvníků naráz – a když spadne, je web pryč. Obojí řeší load balancer (rozdělovač zátěže): zařízení nebo služba, která stojí před více stejnými servery a rozděluje mezi ně příchozí požadavky. Skupině těch serverů se říká web farma. Funguje to takhle: veřejnou IP a jméno v DNS nemá jednotlivý server, ale load balancer. Návštěvník přijde na něj a on požadavek pošle jednomu z web serverů za sebou – dalšího návštěvníka pošle druhému, a tak střídá. Tím získáš dvě věci najednou, které jsou v cloudu obzvlášť cenné. Za prvé škálování (scale-out, znáš z kurzu Odolnost a škálování sítě): když návštěvníků přibývá, přidáš další server do farmy a load balancer ho začne používat – nemusíš kupovat jeden větší stroj. Za druhé odolnost: load balancer průběžně kontroluje, jestli servery za ním žijí (health check), a spadlý server prostě přeskočí. Návštěvník výpadek jednoho serveru vůbec nepozná, protože ho obslouží ostatní. Přesně tuhle sestavu si postavíš v simulátoru na úloze „Load balancer": uvidíš, jak provoz proudí přes rozdělovač na víc backendů a jak se chová, když jeden vypadne. Dva háčky na závěr. Load balancer se sám může stát jediným bodem selhání – v reálném provozu proto bývá taky zdvojený. A rozděluje jen to, co je za ním opravdu stejné: servery ve farmě musí zvládnout kterýkoli požadavek, jinak dostane návštěvník jednou tohle a podruhé něco jiného.

Krok za krokem

Jeden web server zvládne jen tolik návštěvníků – a když spadne, je web pryč. To chceš vyřešit.
Load balancer stojí před web farmou. Veřejnou IP a jméno v DNS má on, ne jednotlivé servery za ním.
Požadavky střídá mezi servery farmy (WEB, WEB2). Přibývá návštěvníků? Přidáš server – to je scale-out.
Health check: load balancer hlídá, které servery žijí, a spadlý přeskočí. Návštěvník výpadek jednoho serveru nepozná.

Jen to, co má být venku

Lekce o publikaci má jedno hlavní poučení a je natolik důležité, že si zaslouží vlastní modul: ven dávej jen to, co venku opravdu má být – a nic víc. Zní to samozřejmě, ale v praxi se to poruší pořád, protože vystavit službu je v cloudu snadné a schovat ji dá o kousek víc práce. Typický příběh: potřebuješ se dostat na správu serveru, tak mu „na chvíli" přidělíš veřejnou adresu a otevřeš port pro vzdálenou správu. Funguje to, na správu se dostaneš – a zároveň jsi ji vystavil celému internetu, kde ji do pár minut najdou automatické skenery a začnou zkoušet hesla. Správa serveru nikdy nemá mít veřejnou tvář; chodí se k ní tunelem (lekce 2 a 3), přesně proto jsme ho stavěli. Stejné pravidlo platí pro databáze, interní API, administrační rozhraní: vnitřní věci zůstávají vnitřní. Praktický test, který si vezmi ke každé veřejné adrese a otevřenému portu: musí tohle vidět cizí člověk z internetu, aby moje služba fungovala? U webového obchodu je odpověď u portu 443 „ano". U databáze, u SSH na server, u administrace „ne" – a když je odpověď „ne", nepatří to ven. A poslední připomenutí, které spojuje celou lekci s tím buketem z lekce 1: veřejné se nestává omylem jen úložiště, ale i servery a porty. Poměr, o který jde, je pořád stejný: co nejmenší veřejná plocha. Každá veřejná adresa a každý otevřený port je dveře, které musíš hlídat – a nejlíp se hlídají ty, které vůbec neexistují.

Krok za krokem

Web na portu 443 venku být má – to je jeho práce. U něj je odpověď na „musí to vidět svět?" jasné ano.
Vystavíš správu serveru „na chvíli" veřejně – a za pár minut ji najdou skenery a začnou zkoušet hesla.
Ke správě, k databázi a k administraci se chodí tunelem – proto jsme ho stavěli. Vnitřní věci zůstávají vnitřní.
Cíl je co nejmenší veřejná plocha. Každá veřejná adresa a port jsou dveře – nejlíp se hlídají ty, co neexistují.

▶ Otevřít v simulátoru

Lekce 5: Cloud DMZ a bezpečnostní skupiny

Bezpečnostní skupina = zónový firewall

V cloudu nikde neuvidíš krabici s nápisem firewall – a přesto tam firewall je, jen se jmenuje jinak: bezpečnostní skupina (security group). Je to sada pravidel, kterou přilepíš k serveru (nebo ke skupině serverů) a která říká, kdo se na něj smí připojit a na jaký port. Nic víc, nic míň – přesně to, co dělá zónový firewall z kurzu Zabezpečení sítě, jen zapsané ve webovém rozhraní místo v konfiguraci krabice. Pravidlo v bezpečnostní skupině má stejné části, jaké už znáš: odkud (zdroj – konkrétní adresa, rozsah, nebo dokonce jiná bezpečnostní skupina), kam a na co (port a protokol) a povolit. Dvě věci jsou tu jiné než u fyzického firewallu a stojí za zapamatování. Za prvé: bezpečnostní skupina není jedna centrální krabice, kterou provoz cestou míjí – je připnutá přímo k serveru, takže platí, ať přijde provoz odkudkoli, i od souseda ve stejné podsíti. To je vlastně mikrosegmentace zadarmo. Za druhé – a to je nejdůležitější rozdíl od zvyků z fyzické sítě: bezpečnostní skupina má výchozí zákaz pro příchozí provoz. Dokud nepřidáš povolující pravidlo, na server se nikdo nedostane, a to je dobře. Nemůžeš tedy udělat chybu „zapomněl jsem zavřít"; můžeš udělat jen chybu „otevřel jsem víc, než bylo potřeba". A přesně na tu druhou si dej pozor: povoluj úzce (konkrétní zdroj, konkrétní port), ne „odkudkoli na všechno" – to už bys byl zpátky u děravého firewallu z první lekce zabezpečení.

Krok za krokem

Bezpečnostní skupina je sada pravidel připnutá přímo k serveru. Je to cloudová obdoba zónového firewallu.
Pravidlo má stejné části jako vždy: odkud (zdroj), na jaký port a povolit. Zapsané ve webu místo v krabici.
Skupina je připnutá k serveru, takže platí i pro provoz od souseda ve stejné podsíti. To je mikrosegmentace zadarmo.
Bezpečnostní skupina má výchozí zákaz: dokud nepřidáš povolení, nikdo se nedostane. Chyba je jen „otevřel jsem víc".

Segmentace v cloudu

Bezpečnostní skupina řeší jeden server. Teď o patro výš: jak rozdělit celou cloudovou síť, aby se v ní útočník po prvním průniku nerozešel všude. Odpověď je stejná jako ve fyzické síti a znáš ji z kurzu Zabezpečení sítě: segmentace. Ve VPC ji děláš dvěma nástroji, které spolu spolupracují. Za prvé podsítě: cloudovou síť rozdělíš na oddíly a servery rozmístíš podle role – veřejná podsíť pro to, co má vidět svět (web, load balancer), a soukromá podsíť pro to, co má zůstat schované (databáze, interní aplikace). Klíčové je, že soukromá podsíť nemá cestu ven do internetu pro příchozí spojení; server v ní může volat ven (třeba pro aktualizace), ale zvenčí ho nikdo neosloví. Za druhé bezpečnostní skupiny z minulého modulu: ty určují, kdo přesně smí mezi podsítěmi mluvit. Typický zdravý návrh vypadá takhle: load balancer ve veřejné podsíti přijímá provoz z internetu na 443; web servery přijímají jen od load balanceru; databáze v soukromé podsíti přijímá jen od web serverů na svém portu – a od nikoho jiného. Vznikne řetěz, ve kterém každý článek mluví jen se sousedem, kterého k práci potřebuje. Veřejná podsíť je tak cloudovou podobou DMZ, kterou znáš z kurzu Zabezpečení sítě – jen místo jedné zóny před firewallem máš podsítě rozdělené podle role. Když teď útočník obsadí web server (ten je nejvíc na ráně, protože je vidět zvenku), narazí u databáze na skupinu, která ho pustí jen na jeden port – a na zbytek cloudu vůbec. To je blast radius v cloudu: první průnik nezastavíš, ale rozhodneš, jestli z něj bude incident na jeden server, nebo na celou VPC.

Krok za krokem

Veřejná podsíť: load balancer a web servery – to, co má vidět svět. Přijímá provoz z internetu.
Soukromá podsíť: databáze a interní aplikace. Nemá cestu zvenčí – server může volat ven, ale nikdo ho neosloví.
Vznikne řetěz: balancer pustí web, web pustí databázi na jejím portu – a nikdo jiný. Každý mluví jen se sousedem.
Když útočník obsadí web, u databáze narazí na skupinu, která ho pustí jen na jeden port. To je blast radius v cloudu.

Default deny i v cloudu

Cloud dělá jednu věc lépe než většina fyzických sítí: bezpečnostní skupiny startují s výchozím zákazem. Nový server je ve výchozím stavu zavřený – z internetu se na něj nikdo nedostane, dokud výslovně nepovolíš, kdo a na co. To je přesně ten postoj, ke kterému se ve fyzické síti pracně proklikáváš (kurz Zabezpečení sítě), a v cloudu ho dostaneš zadarmo. Špatná zpráva je, že se dá stejně snadno zahodit – a lidé to dělají pořád. Nejčastější způsob je pravidlo, které povolí „odkudkoli" (0.0.0.0/0) na správcovský port. Vzniká z nejlepších úmyslů: něco nefunguje, tak se zdroj „dočasně" rozšíří na celý internet, aby se zjistilo, jestli je problém v pravidle – a pak to tam zůstane. Od té chvíle máš výchozí zákaz nadobro pohřbený jedním širokým povolením, které pustí celý svět. Druhý častý omyl je povolit celou skupinu portů „ať to nemusím řešit po jednom". Léčba je pořád stejná trojice, kterou znáš z pravidel firewallu: úzký zdroj (konkrétní adresa nebo bezpečnostní skupina, nikdy 0.0.0.0/0 na správu), úzký port (jen ten, co služba potřebuje) a popis (proč to pravidlo je, ať se za rok někdo odváží ho smazat). A protože cloud usnadňuje i kontrolu, přidej si návyk: projdi si pravidla, která pouštějí odkudkoli, a u každého se zeptej, jestli tam opravdu patří. Většinou zjistíš, že půlka z nich je „dočasných" už půl roku. Shrnutí celé lekce: cloud ti dává lepší výchozí bod než fyzická síť – ale výchozí zákaz je jen tak silný, jak silná jsou pravidla, kterými ho děruješ.

Krok za krokem

Cloud startuje s výchozím zákazem: nový server je zavřený, dokud nepovolíš kdo a na co. Lepší výchozí bod než fyzická síť.
Nejčastější chyba: pravidlo „odkudkoli" (0.0.0.0/0) na správcovský port. Jedno široké povolení pustí celý svět.
Léčba je stejná trojice: úzký zdroj, úzký port a popis, proč pravidlo je – ať ho za rok někdo odváží smazat.
Návyk: projdi pravidla, která pouštějí odkudkoli. Půlka „dočasných" tam bývá už půl roku. Výchozí zákaz je tak silný jako pravidla.

▶ Otevřít v simulátoru

Lekce 6: Odolnost a návrh

Redundantní připojení (multi-WAN)

Poslední lekce je o tom, aby ti to celé vydrželo. Začneme u nejslabšího místa, které si lidé u cloudu neuvědomují: připojení k němu. Všechno, co jsme postavili – tunel, publikovaný web, přístup k databázi – stojí a padá s tím, že se z firmy vůbec dostaneš do internetu. Máš-li jednu internetovou linku, máš jeden kabel, na kterém visí spojení s celým cloudem. Když ho bagr přetrhne nebo poskytovatel spadne, firma je od svých cloudových serverů odříznutá – a nezáleží na tom, jak dobře jsou ty servery uvnitř navržené. Řešení se jmenuje multi-WAN (víc připojení do internetu) a je to přesně ta odolnost z kurzu Odolnost a škálování sítě, jen aplikovaná na bránu do cloudu. Máš dvě linky od dvou různých poskytovatelů – ideálně vedené i jinudy fyzicky, ať je nepřetrhne stejný bagr – a firewall je nastavený tak, že když primární vypadne, provoz se přepne na záložní. Tomu přepnutí se říká failover. Dvě věci se u toho dělají špatně. Za prvé: dvě linky od téhož poskytovatele vedené stejnou trasou nejsou dvě linky – je to jedna linka, která spadne naráz. Nezávislost je celý smysl. Za druhé: failover, který nikdo nikdy nevyzkoušel, obvykle v pravou chvíli nefunguje – přepnutí se musí otestovat nanečisto, ne až při skutečném výpadku. Přesně to si zkusíš v simulátoru na úloze „Multi-WAN failover": shodíš primární linku a uvidíš, jestli se provoz sám přesune na záložní.

Krok za krokem

Tunel, web i databáze stojí na tom, že se z firmy vůbec dostaneš do internetu. Ta linka je nejslabší místo.
S jednou linkou visí celý cloud na jednom kabelu. Bagr ho přetrhne – a firma je od svých serverů odříznutá.
Multi-WAN: druhá linka od jiného poskytovatele, vedená i fyzicky jinudy. Když primární vypadne, provoz se přepne (failover).
Dvě linky od téhož poskytovatele stejnou trasou jsou jedna linka. A failover se musí vyzkoušet nanečisto, ne až při výpadku.

Kam s daty: zálohy a regiony

Odolnost připojení je jedna půlka; druhá je osud dat. Cloud svádí k nebezpečné pohodlnosti: „data jsou v cloudu, tak jsou přece v bezpečí". Nejsou – nebo přesněji, jsou v bezpečí jen před tím, před čím se poskytovatel zavázal je chránit, a to není všechno. Dvě věci je potřeba promyslet. První jsou zálohy. Poskytovatel se stará o svůj hardware, ale nesmaže za tebe data omylem a neochrání je před tvojí chybou: když někdo smaže databázi, spustí špatný skript nebo tě zašifruje ransomware, cloud tu změnu poslušně uloží. Záloha proto musí existovat a musí být oddělená – jiný účet, jiné místo, ideálně tak, aby ji nešlo smazat stejným přístupem, kterým se smazala data. Klasické pravidlo zní mít víc kopií na víc místech a alespoň jednu mimo dosah běžného provozu. A záloha, kterou jsi nikdy nezkusil obnovit, není záloha – je to naděje. Druhá věc jsou regiony. Poskytovatel má datacentra v různých částech světa a tvoje data leží fyzicky v tom, který sis vybral (nebo který ti vybrali za tebe). To má dva dopady. Bezpečnostní: celý region může mít výpadek, takže opravdu kritické služby se rozkládají do dvou regionů, aby je nepoložila jedna havárie. A právní: kde data leží, tam platí tamní zákony – u osobních údajů je region rozhodnutí, ne detail. Konceptuálně si odnes tohle: cloud přesouvá, kde data leží, ale nesnímá z tebe odpovědnost za to, že přežijí.

Krok za krokem

Cloud svádí k pohodlnosti „data jsou v cloudu, tak jsou v bezpečí". Před tvojí vlastní chybou tě ale nechrání.
Když někdo smaže databázi nebo tě zašifruje ransomware, cloud tu změnu poslušně uloží. Záloha musí existovat.
Záloha musí být oddělená – jiné místo a účet, mimo dosah běžného provozu. A nezkoušená obnova není záloha, je to naděje.
Regiony: celý region může vypadnout, tak kritické služby rozlož do dvou. A kde data leží, tam platí tamní zákony.

Kontrolní seznam cloud sítě

Na závěr kontrolní seznam, který si vezmi ke každému návrhu sítě do cloudu – shrnuje celý kurz do otázek, na které musíš umět odpovědět. Připojení: Jak se firma dostane k soukromým serverům – tunelem, ne přes internet? Je tunel zdvojený a víš, co se stane, když spadne? Máš víc než jednu internetovou linku a vyzkoušel jsi failover? Vstup lidí: Chodí vzdálení uživatelé remote-access VPN se silným ověřením? Odebírá se přístup při odchodu? Mají po přihlášení stejně úzká oprávnění jako v kanceláři? Publikace: Má veřejnou adresu jen to, co venku být má? U každého otevřeného portu si odpověz: musí to vidět cizí člověk z internetu? Je před web farmou load balancer? Segmentace: Jsou veřejné a soukromé podsítě oddělené? Je databáze v soukromé, bez cesty zvenčí? Platí u serverů výchozí zákaz a jsou pravidla úzká a popsaná? Nepouští něco „odkudkoli" na správu? Data: Existuje oddělená záloha a zkusil jsi ji obnovit? Rozhodl jsi vědomě o regionu? A poslední, spojující otázka, kterou znáš ze zabezpečení: kdybych obsadil web server, kam se odsud dostanu? Když je odpověď „na jeden port databáze a nic víc", máš cloud navržený dobře. Poslední rada: vyber si jednu odpověď, která tě dnes nejvíc zabolela, a sprav ji. Cloud se nezabezpečí naráz – zabezpečí se tím, že ten seznam bude příště o jednu chybějící hranici kratší. Gratuluju k dokončení; teď si to zkus v simulátoru na úloze s multi-WAN failoverem.

Krok za krokem

Připojení: k soukromým serverům tunelem, ne přes internet. Je zdvojený? Máš víc linek a vyzkoušel jsi failover?
Vstup lidí: remote-access se silným ověřením, přístup se odebírá při odchodu, oprávnění po přihlášení úzká.
Publikace a segmentace: veřejnou adresu má jen web, před farmou load balancer, databáze v soukromé podsíti bez cesty zvenčí.
Spojující otázka: kdybych obsadil web, kam se odsud dostanu? Na jeden port databáze a nic víc = dobrý návrh. Vyber jednu věc a sprav ji.

▶ Otevřít v simulátoru