Ako skutočne vybudovať bezpečnú a spoľahlivú architektúru AWS Cloud bez toho, aby ste prišli o rozum

Úvod

Ak ste sa niekedy pokúšali navrhnúť cloudovú architektúru v AWS od začiatku, pravdepodobne už viete, že je to rovnakým dielom sloboda a chaos. Existuje tisíc spôsobov, ako niečo vytvoriť, a rovnako veľa spôsobov, ako to pokaziť.

Pri krátkom pohľade do dokumentácie AWS si možno pomyslíte: "Super, jednoducho budeme dodržiavať prvotriedne postupy." Ale v reálnych medzinárodných prostrediach prvotriedne postupy často nežijú na prvý dotyk so skutočnými potrebami komerčného podniku, cenovými limitmi alebo ľudskou chybou. To je dôvod, prečo spolupráca s profesionálmi ako perfsys na začiatku môže zabrániť neskoršiemu hazardovaniu s dierami v ochrane a komplikáciami pri škálovaní.

Cieľom nie je len získať niečo, čo beží. Je to vybudovať systém, ktorý sa nezrúti, keď sa zvýši prevádzka alebo sa región vypne - a nenechá si otvorené vstupné dvere do internetu.

Začnime tým, čo je zrejmé: AWS je beštia

Pomocou AWS môžete vytvoriť prakticky čokoľvek. Sú tu všetky stavebné prvky - EC2, Lambda, RDS, S3, IAM, VPC, zoznam je dlhý. Háčik? Čím viac možností máte k dispozícii, tým ľahšie sa vám vytvorí zamotaný chaos.

Nie je to tým, že by bol systém AWS zle navrhnutý. Ide len o to, že ho musíte navrhnúť správne. Inak skončíte s tým, čo niektoré tímy nazývajú "cloudové špagety": vzájomne závislé služby, pevne zakódované tajomstvá, žiadne označovanie, žiadne logovanie a absolútne žiadna predstava o tom, čo koľko stojí.

Spoľahlivosť a bezpečnosť nie sú pekné veci

Je lákavé považovať bezpečnosť a spoľahlivosť za problém budúcnosti. "Zabezpečíme to po spustení prevádzky." "V ďalšom šprinte pridáme monitorovanie." Ale spýtajte sa kohokoľvek, kto sa stretol s únikom údajov alebo niekoľkohodinovým výpadkom - vynechanie týchto krokov je spôsob, ako skončíte s celonočným spánkom.

Čo skutočne znamená spoľahlivosť

Nejde o záruky prevádzkyschopnosti na prezentácii. Ide o inžinierstvo pre prípad zlyhania. Služby vypadávajú. Disky zlyhávajú. Rozhrania API vypovedajú službu. Dôležité je, či váš systém funguje aj po poruche.

Máte redundanciu v zónach dostupnosti? Dokáže váš systém tolerovať zlyhanie databázového uzla bez straty údajov alebo hádzania chýb? Spúšťate kritické pracovné záťaže v jednej oblasti, pretože "to bolo najjednoduchšie nasadiť"? Toto sú otázky, ktoré oddeľujú fungujúce systémy od odolných.

A bezpečnosť? Nie je to len IAM

Áno, správa identít a prístupu (IAM) je prvou stenou. Ale bezpečnosť siaha oveľa ďalej. Verejne prístupné zásobníky S3. Nadmerne oprávnené roly. Tajomstvá natvrdo zakódované do funkcií Lambda. Vypnuté prihlasovanie "kvôli úspore nákladov". To všetko sú časované bomby.

Používanie dobre navrhnutého rámca aws môže pomôcť identifikovať tieto problémy skôr, ako vybuchnú. Rozdeľuje architektúru do piatich kľúčových oblastí - bezpečnosť, spoľahlivosť, prevádzková dokonalosť, efektívnosť výkonu a optimalizácia nákladov - a núti tímy poctivo vyhodnotiť každú z nich. Nie je to strieborná guľka, ale núti vás klásť ťažké otázky.

Stavebné bloky, na ktorých skutočne záleží

Dobre, poďme k podstate veci. Tu je to, na čom záleží pri budovaní bezpečnej a spoľahlivej architektúry na AWS - a kde sa tímy najčastejšie mýlia.

Používanie rolí IAM správnym spôsobom (áno, naozaj)

Roly IAM sú mocné. Niekedy až príliš silné. Je príliš jednoduché dať si "AdministratorAccess", pretože niečo nefunguje, sľúbiť, že to neskôr opravíme... a potom to nikdy neopraviť.

Musíte to včas zablokovať. Princíp najmenších privilégií nie je len osvedčený postup - je to jediný rozumný spôsob fungovania. To znamená:

• Rozsah rolí pre jednotlivé služby

• Vyhýbanie sa zástupným znakom v oprávneniach

• Krátkodobé poverenia

• Povinné MFA pre ľudských používateľov

Znie to ako otrava? Je. Ale rovnako aj vysvetľovanie šéfovi, prečo niekto exfiltroval údaje o zákazníkoch zo zle nakonfigurovanej Lambdy.

Oddeľte svoju sieť tak, ako to myslíte vážne

Toto je ďalšia oblasť, kde sa skratky obracajú proti vám. Nepotrebujete superkomplikované nastavenie siete, ale niektoré základy sú veľmi dôležité:

• Verejné podsiete len pre veci, ktoré musia smerovať do internetu (napr. ALB)

• Súkromné podsiete pre všetko ostatné

• Brány NAT na kontrolovaný odchádzajúci prístup

• Koncové body VPC pre prevádzku služieb AWS bez toho, aby sa dostali do verejného internetu

Plochá sieť VPC so všetkým v rovnakej podsieti sa môže zdať jednoduchá. Kým sa niečo nepokazí a nezoberie so sebou všetko.

Protokolovanie a monitorovanie: Čo nevidíte, nemôžete opraviť

O tomto by sa už nemalo diskutovať. Protokolovanie nie je voliteľné. Ak nezaznamenávate protokoly CloudTrail, metriky CloudWatch a protokoly toku VPC, lietate naslepo.

Ale je tu háčik - samotné protokolovanie nestačí. Na protokoly sa musíte skutočne pozrieť. Vytvorte upozornenia na veci, ktoré sú dôležité. Odfiltrujte šum. A uistite sa, že protokoly sú centralizované v rámci účtov a regiónov. Roztrieštená viditeľnosť nie je žiadna viditeľnosť.

Šifrujte všetko (bez výnimiek)

Používajte KMS pre údaje v pokoji. Na prenášané údaje používajte TLS. Rotujte kľúče. Monitorujte prístup. Toto je jedna z tých oblastí, v ktorých sa lenivosť neskôr veľmi predraží.

A nezabudnite na veci, ako je šifrovanie RDS, nastavenia zväzkov EBS a vynucovanie TLS brány API. Tieto drobnosti sa hromadia.

Infraštruktúra ako kód alebo prepadnutie

Stále nasadzujete pomocou klikania v konzole AWS? To je dobré pre vývojárov, nebezpečné pre predajcov.

Použite Terraform, CloudFormation alebo CDK. Nech už váš tím preferuje čokoľvek - vyberte si jedno a držte sa ho. Kontrolujte verzie svojich šablón. Na nasadenie použite CI/CD. Automatizujte rollbacky. Manuálne nasadenie je otvorenou pozvánkou na chyby.

Tiež: všetko označte. Zdroje bez štítkov sú ako káble bez štítkov - nikto nevie, na čo slúžia, a každý sa ich bojí dotknúť.

Škálovanie bez potápania

Povedzme si to na rovinu: AWS miluje, keď poskytujete nadmerné množstvo zdrojov. Vy dostanete "výkon", oni dostanú vaše peniaze. Efektívne škálovanie spočíva v poznaní svojich modelov - a plánovaní pre ne.

Používajte skupiny s automatickým škálovaním, bodové inštancie (opatrne) a vrstvy vyrovnávacej pamäte. Ale čo je dôležitejšie: testujte pod záťažou. Posledná vec, ktorú chcete, je zistiť, že vaša inštancia RDS sa dva dni po spustení topí pod skutočnou prevádzkou.

Taktiež rezervujte kapacitu, keď to má zmysel. Ušetríte tým peniaze a predídete prekvapivým zlyhaniam pri poskytovaní.

Plány obnovy po havárii nie sú voliteľné

Čo sa stane, ak dôjde k výpadku regiónu? Čo ak sa poškodí vaša primárna databáza? Ak je odpoveď "ehm... budeme mať problémy", potom je čas prepracovať stratégiu DR.

To neznamená vybudovanie identickej kópie vašej infraštruktúry v inom regióne. Znamená to vedieť:

• Čo by ste obnovili

• Ako dlho by to trvalo

• Aké údaje by sa stratili (ak nejaké)

• Kto je za čo zodpovedný počas zlyhania

A áno - mali by ste otestovať svoj plán obnovy. Inak je to len fikcia.

Bežné anti-vzory, ktorým sa treba vyhnúť

Poďme si v rýchlosti vyskúšať niektoré "nie", ktoré sa objavujú príliš často:

• Jeden veľký účet na všetko: použite AWS Organizations. Oddeľte prod, dev, staging atď.

• Ponechanie predvolených VPC a skupín zabezpečenia nedotknutých: uzamknite ich.

• Prílišné spoliehanie sa na inštancie t2.micro "na testovanie" - nakoniec skončia v prod.

• Nezahŕňanie nákladov na CloudWatch do rozpočtu: áno, logovanie stojí peniaze. Nezaznamenávanie stojí viac.

• Poskytovanie prístupu "len to rýchlo opravte": opravte radšej svoj proces.

Záverečné slová? Zostaňte flexibilní, zostaňte pri zmysloch

Cloudová architektúra nie je o hľadaní dokonalého nastavenia. Ide o vytvorenie niečoho, čo je flexibilné, robustné a zrozumiteľné nielen pre toho, kto to napísal.

Nikdy nie ste úplne "hotoví" - a to je v poriadku. Dôležité je byť zámerný. Klásť ťažké otázky hneď na začiatku. Častý audit. Automatizácia tam, kde je to dôležité. A vedieť, kedy zavolať pomoc.

Pretože povedzme si úprimne - systém AWS je výkonný, ale je tiež ľahké sa v ňom stratiť. Spolupráca so skúsenými inžiniermi, ktorí žijú a dýchajú cloudovou architektúrou, môže znamenať rozdiel medzi "väčšinou to funguje" a "v noci spíme".

A to sa oplatí vybudovať.