Hogyan építsünk biztonságos és megbízható AWS-felhőarchitektúrát anélkül, hogy elveszítenénk az eszünket?

Intro

Ha valaha is próbáltál már felhőarchitektúrát tervezni az AWS-en a semmiből, valószínűleg már tudod: ez egyenlő mértékben szabadság és káosz. Ezerféleképpen lehet valamit felépíteni, és ugyanennyi módon el is lehet cseszni.

Egy rövid pillantás az AWS dokumentációjára azt gondolhatja, hogy "Király, egyszerűen csak betartjuk az elsőrendű gyakorlatokat". De a valódi nemzetközi környezetekben az elsőrangú gyakorlatok nem gyakran élnek első érintésre a valódi kereskedelmi vállalati igényekkel, az árkategória korlátaival vagy az emberi hibákkal. Ezért a perfsys-hez hasonló szakemberekkel való korai együttműködés megakadályozhatja, hogy később védelmi lyukakkal és skálázási bonyodalmakkal játsszon.

A cél nem csak az, hogy valami működőképes legyen. Hanem egy olyan rendszer kiépítése, amely nem dől össze, amikor a forgalom megugrik vagy egy régió kiesik - és nem hagyja nyitva a bejárati ajtót az internet előtt.

Kezdjük a nyilvánvalóval: az AWS egy fenevad

Az AWS-szel gyakorlatilag bármit megépíthetünk. A kétszemélyes startupoktól a kiterjedt vállalati platformokig minden építőelem megtalálható - EC2, Lambda, RDS, S3, IAM, VPC-k, VPC-k, a lista folytatható. A bökkenő? Minél több lehetőséged van, annál könnyebb egy kusza zűrzavart létrehozni.

Nem arról van szó, hogy az AWS rosszul van megtervezve. Csak arról van szó, hogy megfelelően kell megtervezni. Ellenkező esetben az lesz a vége, amit egyes csapatok "felhőspagettinek" neveznek: egymástól függő szolgáltatások, keményen kódolt titkok, nincs címkézés, nincs naplózás, és egyáltalán nincs fogalmunk arról, hogy mi mennyibe kerül.

A megbízhatóság és a biztonság nem "szépségek

Csábító a biztonságot és a megbízhatóságot a jövő problémájaként kezelni. "Majd az éles üzembe helyezés után biztosítjuk." "Majd a következő sprintben hozzáadjuk a felügyeletet." De kérdezzen meg bárkit, aki már megtapasztalta az adatok megsértését vagy egy többórás kiesést - ha kihagyja ezeket a lépéseket, akkor a végén egész éjszakákat kell töltenie.

Mit jelent valójában a megbízhatóság

Ez nem a diaképeken szereplő üzemidőgaranciákról szól. Hanem a meghibásodásra való felkészülésről. A szolgáltatások leállnak. A lemezek meghibásodnak. Az API-k leállnak. Az számít, hogy a rendszered akkor is működőképes marad-e, amikor a dolgok elromlanak.

Van redundancia a rendelkezésre állási zónák között? Képes-e a rendszere elviselni egy meghibásodott adatbázis-csomópontot adatvesztés vagy hibaüzenet nélkül? A kritikus munkaterheléseket egyetlen régióban futtatja, mert "azt volt a legkönnyebb telepíteni"? Ezek a kérdések választják el a működő rendszereket a rugalmas rendszerektől.

És a biztonság? Nem csak az IAM

Igen, az azonosság- és hozzáférés-kezelés (IAM) az első fal. De a biztonság ennél jóval többre terjed ki. Nyilvánosan elérhető S3 vödrök. Túlzottan engedélyezett szerepkörök. Lambda függvényekbe keményen kódolt titkok. Kikapcsolt naplózás "költségtakarékossági okokból". Ezek mind időzített bombák.

Az aws jól architektúrázott keretrendszerének használata segíthet azonosítani ezeket a problémákat, mielőtt felrobbannának. Az architektúrát öt kulcsfontosságú területre bontja - biztonság, megbízhatóság, működési kiválóság, teljesítményhatékonyság és költségoptimalizálás -, és arra kényszeríti a csapatokat, hogy mindegyik területet őszintén értékeljék. Ez nem egy csodaszer, de arra késztet, hogy kemény kérdéseket tegyen fel.

A valóban fontos építőelemek

Rendben, térjünk rá a lényegre. Íme, mi számít, amikor biztonságos, megbízható architektúrát építünk az AWS-en - és hol rontják el leggyakrabban a csapatok.

Az IAM-szerepkörök helyes használata (igen, tényleg)

Az IAM-szerepek nagy teljesítményűek. Néha túlságosan is erősek. Túlságosan könnyű felrakni a "AdministratorAccess" szerepkört, mert valami nem működik, megígérni, hogy később megjavítjuk... és aztán soha nem javítjuk meg.

Ezt korán le kell zárni. A legkisebb kiváltság elve nem csak a legjobb gyakorlat - ez az egyetlen ésszerű működési mód. Ez azt jelenti:

• Szolgáltatásonkénti szerepkörök

• A vadkártyák elkerülése a jogosultságokban

• Rövid életű hitelesítő adatok

• Kötelező MFA az emberi felhasználók számára

Fájdalmasan hangzik? Az is. De az is, ha elmagyarázod a főnöködnek, hogy valaki miért szivárogtatott ki ügyféladatokat egy rosszul konfigurált Lambdából.

Szétválasztani a hálózatot, mintha komolyan gondolnád

Ez egy másik terület, ahol a rövidítések visszafelé sülnek el. Nincs szükséged szuperkomplex hálózati beállításokra, de néhány alapelemmel sokat lehet elérni:

• Nyilvános alhálózatok csak olyan dolgok számára, amelyeknek az internet felé kell nézniük (pl. ALB-k).

• Privát alhálózatok minden máshoz

• NAT-átjárók a kimenő hozzáférés ellenőrzéséhez

• VPC végpontok az AWS-szolgáltatások forgalmához anélkül, hogy a nyilvános internetre kerülne.

Egy lapos VPC, ahol minden egy alhálózaton van, könnyűnek tűnhet. Egészen addig, amíg valami el nem törik, és magával nem visz mindent.

Naplózás és felügyelet: Amit nem lát, azt nem tudja megjavítani.

Ez már nem is kellene, hogy vita tárgya legyen. A naplózás nem opcionális. Ha nem rögzíti a CloudTrail, a CloudWatch metrikákat és a VPC áramlási naplókat, akkor vakon repül.

De itt van a bökkenő - a naplózás önmagában nem elég. Valójában meg kell néznie a naplókat. Hozzon létre riasztásokat a fontos dolgokról. Szűrje ki a zajt. És győződjön meg róla, hogy a naplófájlok központosítva vannak a fiókok és régiók között. A széttöredezett láthatóság nem láthatóság.

Titkosít mindent (kivétel nélkül)

Használjon KMS-t a nyugalmi adatokhoz. Használjon TLS-t az átmenő adatokhoz. Forgassa a kulcsokat. Figyelje a hozzáférést. Ez az egyik olyan terület, ahol a mostani lustaság később nagyon sokba fog kerülni.

És ne feledkezzen meg az olyan dolgokról sem, mint az RDS titkosítás, az EBS kötetbeállítások és az API Gateway TLS-kényszerítés. Ezek az apró részletek összeadódnak.

Infrastruktúra mint kód vagy bukta

Még mindig az AWS-konzolon kattintgatva telepít? Ez jó a fejlesztőknek, de veszélyes a prod számára.

Használja a Terraformot, a CloudFormationt vagy a CDK-t. Bármelyiket is részesíti előnyben a csapata - csak válasszon egyet, és ragaszkodjon hozzá. Változatvezérelje a sablonokat. Használjon CI/CD-t a telepítéshez. Automatizáld a visszaállításokat. A kézi telepítések nyíltan hibázásra invitálnak.

Továbbá: címkézzen fel mindent. A címkék nélküli erőforrások olyanok, mint a címkék nélküli kábelek - senki sem tudja, mire valók, és mindenki fél hozzájuk nyúlni.

Méretezés süllyedés nélkül

Tisztázzuk: az AWS szereti, ha túlbiztosítjuk a rendszereket. Te "teljesítményt" kapsz, ők pedig a pénzedet. A hatékony skálázás arról szól, hogy ismerjük a mintáinkat - és tervezzünk velük.

Használj automatikus skálázási csoportokat, spot példányokat (óvatosan) és gyorsítótárazási rétegeket. De ami még fontosabb: teszteljen terhelés alatt. Az utolsó dolog, amit szeretnél, hogy az RDS-példányod két nappal az indítás után valódi forgalom alatt elolvadjon.

Emellett tartalékoljon kapacitást, ha van értelme. Ez pénzt takarít meg, és megelőzi a meglepetésszerű tartalékolási hibákat.

A katasztrófa-visszaállítási tervek nem opcionálisak

Mi történik, ha egy régió leáll? Mi történik, ha az elsődleges adatbázis megsérül? Ha a válasz az, hogy "uh... bajban lennénk", akkor ideje átdolgozni a DR-stratégiát.

Ez nem azt jelenti, hogy egy másik régióban kell létrehozni az infrastruktúrájának egy azonos másolatát. Azt jelenti, hogy tudnunk kell:

• Mit kell visszaállítani

• Mennyi ideig tartana

• Milyen adatok vesznének el (ha lennének)

• Ki miért felelős a hibaelhárítás során?

És igen - tesztelnie kell a helyreállítási tervet. Ellenkező esetben ez csak kitaláció.

Kerülendő gyakori anti-minták

Gyorsan lőjjünk le néhány nem-nem-et, amelyek túl gyakran fordulnak elő:

• Egy nagy fiók mindenre: használjon AWS-szervezeteket. Külön prod, dev, staging stb.

• Az alapértelmezett VPC-k és biztonsági csoportok érintetlenül hagyása: zárjuk le őket.

• Túlságosan támaszkodni a t2.micro példányokra "tesztelés céljából" - ezek végül a prod-ban kötnek ki.

• A CloudWatch költségeinek nem tervezése a költségvetésbe: igen, a naplózás pénzbe kerül. A nem naplózás még többe kerül.

• Hozzáférés megadása a "csak gyorsan javítsd meg": javítsd meg inkább a folyamatodat.

Utolsó szavak? Maradjon rugalmas, maradjon józan

A felhőarchitektúra nem a tökéletes beállítás megtalálásáról szól. Hanem arról, hogy olyasmit építsünk, ami rugalmas, robusztus és nem csak az azt író személy számára érthető.

Soha nem vagy igazán "kész" - és ez így van rendjén. Ami számít, az a szándékosság. Korán fel kell tenni a nehéz kérdéseket. Gyakori auditálás. Automatizálás ott, ahol számít. És tudni, mikor kell segítséget hívni.

Mert legyünk őszinték - az AWS nagy teljesítményű, de könnyen el is lehet veszni benne. A tapasztalt mérnökökkel való együttműködés, akik a felhőarchitektúrában élnek és lélegzik, jelentheti a különbséget a "többnyire működik" és az "éjjelente alszunk" között.

És erre érdemes építeni.