Jak skutečně vytvořit bezpečnou a spolehlivou cloudovou architekturu AWS, aniž byste přišli o rozum?

Úvodní stránka

Pokud jste se někdy pokoušeli navrhnout cloudovou architekturu v AWS od nuly, pravděpodobně už víte, že je to rovným dílem svoboda a chaos. Existuje tisíc způsobů, jak něco vytvořit, a stejně tolik způsobů, jak to pokazit.

Krátký pohled do dokumentace AWS vás může opustit s myšlenkou: "Super, prostě budeme dodržovat prvotřídní postupy." Tohle je ale jen takový příklad. Ale v reálném mezinárodním prostředí se prvotřídní postupy často nedočkají prvního kontaktu se skutečnými potřebami komerčního podniku, cenovými limity nebo lidskou chybou. To je důvod, proč spolupráce s profesionály, jako je perfsys, na začátku může zabránit pozdějšímu hazardu s dírami v ochraně a komplikacemi při škálování.

Cílem není jen získat něco, co běží. Jde o to vybudovat systém, který se nezhroutí, když dojde k prudkému nárůstu provozu nebo k výpadku regionu - a nenechá si dokořán otevřené vstupní dveře do internetu.

Začněme tím, co je zřejmé: AWS je bestie

Na AWS můžete postavit prakticky cokoli. Od startupů pro dva lidi až po rozsáhlé podnikové platformy, všechny stavební kameny jsou k dispozici - EC2, Lambda, RDS, S3, IAM, VPC, seznam je dlouhý. Háček? Čím více možností máte, tím snáze vytvoříte zamotaný chaos.

Ne že by byl systém AWS špatně navržený. Jde jen o to, že ho musíte navrhnout správně. Jinak skončíte s tím, čemu některé týmy říkají "cloudové špagety": vzájemně závislé služby, pevně zakódovaná tajemství, žádné označování, žádné protokolování a absolutně žádná představa o tom, co kolik stojí.

Spolehlivost a zabezpečení nejsou příjemné věci

Je lákavé považovat bezpečnost a spolehlivost za problém budoucnosti. "Zabezpečíme to, až to spustíme do provozu". "V příštím sprintu přidáme monitorování." Ale zeptejte se kohokoli, kdo se potýkal s únikem dat nebo několikahodinovým výpadkem - přeskočení těchto kroků vede k tomu, že si nakonec vyžádá celonoční spaní.

Co skutečně znamená spolehlivost

Tady nejde o záruky doby provozu na prezentaci. Jde o inženýrství pro případ selhání. Služby vypadávají. Selhávají disky. Rozhraní API vypovídají službu. Záleží na tom, zda váš systém funguje, i když se něco porouchá.

Máte redundanci napříč zónami dostupnosti? Snese váš systém výpadek databázového uzlu, aniž by došlo ke ztrátě dat nebo k chybám? Provozujete kritické pracovní zátěže v jediné oblasti, protože "to bylo nejjednodušší nasadit"? To jsou otázky, které oddělují fungující systémy od odolných.

A bezpečnost? Nejde jen o IAM

Ano, správa identit a přístupu (IAM) je první zdí. Ale bezpečnost sahá mnohem dál. Veřejně přístupné buffety S3. Role s nadměrným oprávněním. Tajemství natvrdo zakódovaná do funkcí Lambda. Vypnuté přihlašování "kvůli úspoře nákladů". To vše jsou časované bomby.

Použití dobře navrženého rámce aws může pomoci tyto problémy identifikovat dříve, než explodují. Rozděluje architekturu do pěti klíčových oblastí - zabezpečení, spolehlivost, provozní dokonalost, efektivita výkonu a optimalizace nákladů - a nutí týmy poctivě vyhodnotit každou z nich. Není to stříbrná kulka, ale nutí vás klást si těžké otázky.

Stavební prvky, na kterých skutečně záleží

Dobrá, přejděme k jádru věci. Zde je popis toho, na čem záleží při budování bezpečné a spolehlivé architektury na AWS - a kde se týmy nejčastěji mýlí.

Používejte role IAM správným způsobem (ano, opravdu)

Role IAM jsou mocné. Někdy až příliš mocné. Je příliš snadné nasadit "AdministratorAccess", protože něco nefunguje, slíbit, že to později opravíme... a pak už to nikdy neopravit.

Je třeba to včas uzamknout. Princip nejmenších oprávnění není jen osvědčený postup - je to jediný rozumný způsob, jak fungovat. To znamená:

• Rozsah rolí pro jednotlivé služby

• Vyhýbání se zástupným znakům v oprávněních

• Pověření s krátkou dobou platnosti

• Povinné MFA pro lidské uživatele

Zní to jako otrava? Je. Ale stejně tak vysvětlování šéfovi, proč někdo exfiltroval data zákazníků ze špatně nakonfigurované lambdy.

Oddělte síť, jako byste to mysleli vážně

Tohle je další oblast, kde se zkratkovité řešení vymstí. Nepotřebujete superkomplexní nastavení sítě, ale některé základy se hodí:

• Veřejné podsítě pouze pro věci, které musí směřovat do internetu (např. ALB).

• Soukromé podsítě pro vše ostatní

• Brány NAT pro řízený odchozí přístup

• Koncové body VPC pro provoz služeb AWS bez přístupu do veřejného internetu

Plochá síť VPC se vším na stejné podsíti se může zdát snadná. Dokud se něco nerozbije a nevezme všechno s sebou.

Protokolování a monitorování: Co nevidíte, to neopravíte.

O tomhle by se už nemělo ani diskutovat. Protokolování není volitelné. Pokud nezaznamenáváte protokoly CloudTrail, metriky CloudWatch a protokoly toku VPC, letíte naslepo.

Ale je tu háček - samotné protokolování nestačí. Na protokoly se musíte skutečně podívat. Vytvářejte upozornění na věci, na kterých záleží. Odfiltrujte šum. A ujistěte se, že jsou protokoly centralizovány napříč účty a regiony. Roztříštěný přehled není žádný přehled.

Šifrujte vše (bez výjimek)

Pro data v klidu používejte KMS. Pro data při přenosu používejte TLS. Rotujte klíče. Monitorujte přístup. Toto je jedna z těch oblastí, kde se lenost nyní velmi prodraží později.

A nezapomeňte na věci, jako je šifrování RDS, nastavení svazků EBS a vynucení protokolu TLS brány API. Tyto drobnosti se sčítají.

Infrastruktura jako kód nebo krach

Stále nasazujete pomocí klikání v konzoli AWS? To je dobré pro vývojáře, nebezpečné pro prod.

Použijte Terraform, CloudFormation nebo CDK. Ať už váš tým preferuje cokoli - vyberte si jedno a držte se ho. Řiďte své šablony podle verzí. K nasazení použijte CI/CD. Automatizujte rollbacky. Ruční nasazení je otevřenou pozvánkou k chybám.

A také: všechno označujte. Zdroje bez štítků jsou jako kabely bez štítků - nikdo neví, k čemu jsou, a všichni se jich bojí dotknout.

Škálování bez potopení

Řekněme si to na rovinu: AWS miluje, když přeplňujete zásoby. Vy dostanete "výkon", oni dostanou vaše peníze. Efektivní škálování spočívá v tom, že znáte své modely - a plánujete je.

Používejte skupiny s automatickým škálováním, bodové instance (opatrně) a vrstvy mezipaměti. Ale hlavně: testujte pod zátěží. Poslední věc, kterou chcete, je zjistit, že se vaše instance RDS dva dny po spuštění rozpouští pod skutečným provozem.

Také rezervujte kapacitu, pokud to dává smysl. Ušetříte tím peníze a zabráníte nečekaným selháním při poskytování.

Plány obnovy po havárii nejsou volitelné

Co se stane, když dojde k výpadku regionu? Co když dojde k poškození primární databáze? Pokud je odpověď "ehm... měli bychom problém", pak je čas přepracovat strategii DR.

To neznamená vybudovat identickou kopii vaší infrastruktury v jiném regionu. Znamená to vědět:

• Co byste obnovili

• Jak dlouho by to trvalo

• Jaká data by se ztratila (pokud vůbec nějaká)

• Kdo je za co zodpovědný během převzetí služeb při selhání

A ano - měli byste svůj plán obnovy otestovat. Jinak je to jen fikce.

Obvyklé anti-vzory, kterým je třeba se vyhnout

Pojďme si v rychlosti ukázat několik ne-vzorů, které se objevují až příliš často:

• Jeden velký účet pro všechno: použijte AWS Organizations. Oddělte prod, dev, staging atd.

• Ponechání výchozích VPC a skupin zabezpečení nedotčených: uzamkněte je.

• Přílišné spoléhání na instance t2.micro "pro testování" - nakonec skončí v prod.

• Nezařazení nákladů na CloudWatch do rozpočtu: ano, logování stojí peníze. Neprovádění logování stojí více.

• Poskytování přístupu "jen to rychle opravte": opravte raději svůj proces.

Závěrečná slova? Zůstaňte flexibilní, zůstaňte při smyslech

Cloudová architektura není o hledání dokonalého nastavení. Jde o to vytvořit něco, co je flexibilní, robustní a srozumitelné nejen pro toho, kdo to napsal.

Nikdy nejste skutečně "hotovi" - a to je v pořádku. Důležité je být záměrný. Kladení těžkých otázek na začátku. Časté provádění auditů. Automatizace tam, kde je to důležité. A vědět, kdy zavolat pomoc.

Protože buďme upřímní - AWS je mocný, ale také se v něm dá snadno ztratit. Spolupráce se zkušenými inženýry, kteří cloudovou architekturou žijí a dýchají, může znamenat rozdíl mezi "většinou to funguje" a "v noci spíme".

A pro to stojí za to stavět.