Kuidas tegelikult ehitada turvaline ja usaldusväärne AWS-i pilvearhitektuur ilma mõistust kaotamata

Intro

Kui olete kunagi püüdnud AWSis nullist pilvearhitektuuri projekteerida, siis teate ilmselt juba, et see on võrdselt vabadus ja kaos. On tuhat võimalust, kuidas midagi ehitada, ja sama palju võimalusi, kuidas seda ära rikkuda.

Lühike pilk AWS-i dokumentatsiooni võib teid jätta mõtlema: "Lahe, me lihtsalt järgime esmaklassilisi tavasid". Kuid reaalsetes rahvusvahelistes keskkondades ei ela esmaklassilised tavad sageli esmakordselt kokku puutuda reaalsete äriettevõtete vajaduste, hinnapiirangute või inimlike vigadega. That`s miks töötab koos professionaalidega nagu perfsys varakult võib vältida mängimine whack-a-mole kaitse auke ja skaalamine tüsistused hiljem.

Eesmärk ei ole lihtsalt saada midagi, mis töötab. See on ehitada süsteem, mis ei kuku ümber, kui liiklus piiksub või mõni piirkond vilgub välja - ja ei jäta interneti ees ust laialt lahti.

Alustame ilmselgest: AWS on koletis

AWSiga saab ehitada praktiliselt mida iganes. Alates kahe inimese idufirmadest kuni laialivalguvate ettevõtete platvormideni on kõik ehituskivid olemas - EC2, Lambda, RDS, S3, IAM, VPC-d, nimekiri jätkub. Mis on konks? Mida rohkem on võimalusi, seda lihtsam on luua segadust.

Asi ei ole selles, et AWS oleks halvasti disainitud. Asi on lihtsalt selles, et seda tuleb kujundada korralikult. Vastasel juhul on tulemuseks see, mida mõned meeskonnad nimetavad "pilvespagetiks": üksteisest sõltuvad teenused, kõvasti kodeeritud saladused, puuduvad märgistamine, logimine ja absoluutselt puudub ettekujutus sellest, mis maksab kui palju.

Usaldusväärsus ja turvalisus ei ole Nice-to-Haves

On ahvatlev käsitleda turvalisust ja usaldusväärsust kui tulevikuprobleemi. "Me kindlustame selle pärast seda, kui me hakkame tööle." "Järgmisel sprindil lisame jälgimise." Kuid küsige kõigilt, kes on olnud seotud andmekaitserikkumise või mitmetunnise katkestusega - nende sammude vahelejätmine on see, kuidas te lõpuks kogu öö läbi töötate.

Mida usaldusväärsus tegelikult tähendab

Küsimus ei ole diapasoonil esitatud käideldavuse garantiides. See on ebaõnnestumise jaoks projekteerimine. Teenused lähevad katki. Kettad lähevad katki. API-de tööaeg langeb. Oluline on see, kas teie süsteem toimib ka siis, kui midagi katkeb.

Kas teil on olemas koondamine eri kättesaadavustsoonide vahel? Kas teie süsteem suudab taluda andmebaasisõlme rikkeid ilma andmete kaotamise või vigade tekkimiseta? Kas te kasutate kriitilisi töökoormusi ühes piirkonnas, sest "seda oli kõige lihtsam kasutusele võtta"? Need on küsimused, mis eristavad töötavaid süsteeme töökindlatest süsteemidest.

Ja turvalisus? See ei ole ainult IAM

Jah, identiteedi ja juurdepääsu haldamine (IAM) on esimene müür. Kuid turvalisus ulatub kaugemale. Avalikult ligipääsetavad S3-ämbrid. Liigselt lubatud rollid. Lambda-funktsioonidesse kõvasti sisse kodeeritud saladused. Logimine välja lülitatud "kulude kokkuhoiu eesmärgil". Kõik need on ajapommid.

Kasutades aws'i hästi arhiveeritud raamistikku, saab neid probleeme tuvastada enne nende plahvatamist. See jaotab arhitektuuri viide võtmevaldkonda - turvalisus, usaldusväärsus, töökindlus, jõudluse tõhusus ja kulude optimeerimine - ning sunnib meeskondi igaüht ausalt hindama. See ei ole hõbedane lahendus, kuid see sunnib teid esitama raskeid küsimusi.

Ehitusplokid, mis on tegelikult olulised

Olgu, asume asja sisusse. Siin on kirjas, mis on AWSi turvalise ja usaldusväärse arhitektuuri loomisel oluline - ja kus meeskonnad kõige sagedamini valesti toimivad.

Kasutage IAM-rolle õigesti (jah, tõesti)

IAM-rollid on võimsad. Mõnikord liiga võimsad. Liiga lihtne on lisada "AdministratorAccess", sest midagi ei tööta, lubada, et see hiljem parandatakse... ja siis ei parandata seda kunagi.

Sa pead selle varakult lukustama. Väikseimate privileegide põhimõte ei ole lihtsalt parim tava - see on ainus mõistlik viis tegutsemiseks. See tähendab:

• Teenusepõhised rollid

• Vältimine õiguste metsikute kaartide kasutamisel

• Lühiajalised volitused

• Kohustuslik MFA inimkasutajatele

Kõlab nagu valusalt? See ongi nii. Aga nii on ka seletada oma ülemusele, miks keegi eksfiltreeris kliendiandmeid valesti konfigureeritud Lambdast.

Eraldage oma võrk nii, nagu te seda mõtlete

See on veel üks valdkond, kus otseteed tagasilöögi. Te ei pea olema väga keerukas võrgu seadistus, kuid mõned põhitõed aitavad kaugele jõuda:

• Avalikud alamvõrgud ainult nende asjade jaoks, mis peavad olema suunatud internetti (nt ALB-d).

• privaatsed alamvõrgud kõige muu jaoks

• NAT-väravad kontrollitud väljamineva juurdepääsu jaoks

• VPC-pääsupunktid AWS-i teenuste liikluse jaoks, ilma et see puutuks kokku avaliku internetiga.

Lame VPC, kus kõik on samas alamvõrgus, võib tunduda lihtne. Kuni midagi läheb katki ja võtab kõik kaasa.

Logimine ja seire: Mida ei saa parandada, mida ei näe, seda ei saa parandada.

Selle üle ei tohiks enam isegi vaielda. Logimine ei ole vabatahtlik. Kui te ei salvesta CloudTraili, CloudWatchi mõõdikuid ja VPC voolu logisid, siis lendate pimesi.

Aga siin on konks - logimine üksi ei ole piisav. Te peate logisid ka tegelikult vaatama. Looge hoiatusi oluliste asjade kohta. Filtreerige müra välja. Ja veenduge, et logid on tsentraliseeritud kõigis kontodes ja piirkondades. Killustatud nähtavus ei ole nähtavus.

Krüpteerige kõik (ilma eranditeta)

Kasutage KMS-i puhkeolekus olevate andmete jaoks. Kasutage TLS-i andmete edastamiseks. Pöörake võtmeid. Jälgige juurdepääsu. See on üks neist valdkondadest, kus praegu laiskus läheb hiljem väga kalliks maksma.

Ja ärge unustage selliseid asju nagu RDS-i krüpteerimine, EBS-i mahtude seaded ja API Gateway TLS-i jõustamine. Need väikesed detailid on väga olulised.

Infrastruktuur kui kood või ebaõnnestumine

Kas ikka veel AWS-i konsooliga ringi klõpsates? See on hea dev jaoks, ohtlik prod jaoks.

Kasutage Terraformi, CloudFormationi või CDK-d. Mida iganes teie meeskond eelistab - valige üks neist ja jääge selle juurde. Kontrollige oma mallide versiooni. Kasutage kasutuselevõtuks CI/CD-d. Automatiseerige tagasivõtmised. Manuaalne juurutamine on avatud kutse vigade tegemiseks.

Samuti: märgistage kõik. Ressursid ilma siltideta on nagu kaablid ilma siltideta - keegi ei tea, mille jaoks need mõeldud on, ja kõik kardavad neid puudutada.

Skaalumine ilma uppumiseta

Olgem ausad: AWS armastab, kui te ülevarustate. Sa saad "jõudluse", nemad saavad sinu raha. Tõhus skaleerimine tähendab oma mustrite tundmist - ja nende planeerimist.

Kasutage automaatse skaleerimise gruppe, spot-instantse (ettevaatlikult) ja vahemälukihti. Aga mis veelgi olulisem: testige koormuse all. Viimane asi, mida te soovite, on avastada, et teie RDS-instants sulab tegeliku liikluse all kaks päeva pärast käivitamist.

Samuti reserveerige võimsust, kui see on mõistlik. See säästab raha ja hoiab ära ootamatuid reservatsioonihäireid.

Katastroofide taastamise plaanid ei ole vabatahtlikud

Mis juhtub, kui piirkond läheb katki? Mis siis, kui teie esmane andmebaas rikneb? Kui vastus on "äh... me oleksime hädas", siis on aeg oma DR-strateegia üle vaadata.

See ei tähenda teie infrastruktuuri identse koopia loomist teises piirkonnas. See tähendab teadmist:

• Mida te taastate

• Kui kaua see võtaks aega

• Millised andmed läheksid kaduma (kui üldse)

• Kes vastutab mille eest vea ajal.

Ja jah - te peaksite oma taastamisplaani testima. Vastasel juhul on see lihtsalt väljamõeldis.

Üldised antimustrid, mida tuleks vältida

Toon kiiresti mõned eitavatest käitumisviisidest, mis ilmnevad liiga sageli:

• Üks suur konto kõige jaoks: kasutage AWS Organizations. Eraldi prod, dev, staging jne.

• Vaikimisi VPC-de ja turvarühmade puutumata jätmine: lukusta need.

• T2.micro instantside liigne usaldamine "testimiseks" - need satuvad lõpuks prod'i.

• CloudWatchi kulude mittearvestamine eelarves: jah, logimine maksab raha. Logimise puudumine maksab rohkem.

• Juurdepääsu andmine "lihtsalt kiiresti parandada": parandage hoopis oma protsess.

Viimased sõnad? Jääge paindlikuks, jääge mõistlikuks

Pilvearhitektuur ei ole täiusliku seadistuse leidmine. Küsimus on selles, et ehitada midagi, mis on paindlik, tugev ja arusaadav rohkematele kui ainult sellele, kes selle kirjutas.

Sa ei ole kunagi päris "valmis" - ja see on ka okei. Oluline on olla tahtlik. Küsime varakult raskeid küsimusi. Auditeerimine sageli. Automatiseerimine seal, kus see on oluline. Ja teadmine, millal tuleb abi kutsuda.

Sest olgem ausad - AWS on võimas, kuid selles on ka lihtne eksida. Koostöö kogenud inseneridega, kes elavad ja hingavad pilvearhitektuuris, võib teha vahet "enamasti töötab" ja "me magame öösel" vahel.

Ja see on väärt ehitamist.