Miten rakentaa turvallinen ja luotettava AWS-pilviarkkitehtuuri menettämättä järkeään?

Intro

Jos olet koskaan yrittänyt suunnitella pilviarkkitehtuuria AWS:ssä tyhjästä, tiedät jo varmasti, että se on yhtä paljon vapautta ja kaaosta. On tuhansia tapoja rakentaa jotain, ja yhtä monta tapaa mokata se.

Lyhyt vilkaisu AWS:n dokumentaatioon saattaa jättää sinut ajattelemaan: "Siistiä, noudatamme yksinkertaisesti ensiluokkaisia käytäntöjä." Mutta todellisissa kansainvälisissä ympäristöissä ensiluokkaiset käytännöt eivät useinkaan elä ensimmäisessä kosketuksessa todellisten kaupallisten yritysten tarpeiden, hintaluokkarajojen tai inhimillisten virheiden kanssa. Siksi perfsysin kaltaisten ammattilaisten kanssa työskentely varhaisessa vaiheessa voi ehkäistä suoja-aukkojen ja skaalautumiskomplikaatioiden kanssa pelaamista myöhemmin.

Tavoitteena ei ole vain saada jotain, joka toimii. Tavoitteena on rakentaa järjestelmä, joka ei kaadu, kun liikenne kasvaa tai jokin alue sammuu - eikä jätä etuovea auki internetille.

Aloitetaan ilmeisestä: AWS on peto.

AWS:llä voi rakentaa käytännössä mitä tahansa. Rakennuspalikat ovat kaikki olemassa kahden henkilön startup-yrityksistä laajoihin yritysalustoihin: EC2, Lambda, RDS, S3, IAM, VPC:t ja niin edelleen. Mutta mikä on ongelma? Mitä enemmän vaihtoehtoja sinulla on, sitä helpompi on luoda sekasotku.

Kyse ei ole siitä, että AWS olisi huonosti suunniteltu. Kyse on vain siitä, että se on suunniteltava oikein. Muuten päädyt siihen, mitä jotkut tiimit kutsuvat "pilvispagetiksi": toisistaan riippuvaisia palveluita, kovakoodattuja salaisuuksia, ei merkintöjä, ei lokitusta, eikä mitään käsitystä siitä, mikä maksaa kuinka paljon.

Luotettavuus ja tietoturva eivät ole Nice-to-Haves-ominaisuuksia.

On houkuttelevaa pitää turvallisuutta ja luotettavuutta tulevaisuuden ongelmana. "Turvaamme sen sen jälkeen, kun olemme ottaneet sen käyttöön." "Lisäämme valvonnan seuraavassa sprintissä." Mutta kysy keneltä tahansa, joka on ollut tekemisissä tietomurron tai monituntisen käyttökatkoksen kanssa - näiden vaiheiden ohittaminen on se tapa, jolla päädyt vetämään yöunia.

Mitä luotettavuus todella tarkoittaa

Kyse ei ole diakannessa esitetyistä käytettävyystakuista. Kyse on vikasietoisesta suunnittelusta. Palvelut kaatuvat. Levyt vikaantuvat. API-rajapintojen toiminta-aika loppuu. Olennaista on se, toimiiko järjestelmäsi, kun jotakin hajoaa.

Onko käytössäsi redundanssia eri saatavuusalueilla? Kestääkö järjestelmäsi tietokantasolmun vikaantumisen menettämättä tietoja tai aiheuttamatta virheitä? Käytätkö kriittisiä työkuormia yhdellä alueella, koska "se oli helpointa ottaa käyttöön"? Nämä kysymykset erottavat toimivat järjestelmät joustavista järjestelmistä.

Entä turvallisuus? Se ei ole vain IAM

Kyllä, henkilöllisyyden ja pääsynhallinta (IAM) on ensimmäinen muuri. Mutta turvallisuus ulottuu paljon pidemmälle. Julkisesti saatavilla olevat S3-säiliöt. Ylivaltuutetut roolit. Lambda-funktioihin kovakoodatut salaisuudet. Kirjautuminen pois päältä "kustannusten säästämiseksi". Kaikki nämä ovat aikapommeja.

Hyvin arkkitehtuurin mukaisen aws-kehyksen käyttäminen voi auttaa tunnistamaan nämä ongelmat ennen kuin ne räjähtävät. Se jakaa arkkitehtuurin viiteen keskeiseen osa-alueeseen - turvallisuus, luotettavuus, toiminnallinen erinomaisuus, suorituskyvyn tehokkuus ja kustannusten optimointi - ja pakottaa tiimit arvioimaan jokaisen osa-alueen rehellisesti. Se ei ole hopealuoti, mutta se pakottaa kysymään vaikeita kysymyksiä.

Rakennuspalikat, joilla on oikeasti merkitystä

No niin, mennäänpäs nyt asiaan. Seuraavassa kerrotaan, millä on merkitystä, kun rakennat turvallista ja luotettavaa arkkitehtuuria AWS:lle - ja missä tiimit tekevät useimmiten väärin.

Käytä IAM-rooleja oikein (kyllä, oikeasti).

IAM-roolit ovat tehokkaita. Joskus liian voimakkaita. On aivan liian helppoa käyttää "AdministratorAccess" -roolia, koska jokin asia ei toimi, luvata korjata se myöhemmin... eikä korjata sitä sitten koskaan.

Tämä on lukittava jo varhaisessa vaiheessa. Pienimpien oikeuksien periaate ei ole vain paras käytäntö - se on ainoa järkevä tapa toimia. Se tarkoittaa:

• Palvelukohtaiset roolit

• Jokerimerkkien välttäminen käyttöoikeuksissa

• Lyhytikäiset valtuudet

• Pakollinen MFA ihmiskäyttäjille

Kuulostaako hankalalta? Se on sitä. Mutta niin on myös selittää pomollesi, miksi joku on salakuljettanut asiakastietoja väärin konfiguroidusta Lambdasta.

Erottele verkko niin kuin tarkoitat sitä

Tämä on toinen alue, jossa oikotiet kostautuvat. Et tarvitse superkompleksisia verkkoasetuksia, mutta perusasioilla pääsee pitkälle:

• Julkiset aliverkot vain niille asioille, joiden on oltava yhteydessä internetiin (esim. ALB:t).

• Yksityiset aliverkot kaikkea muuta varten

• NAT-yhdyskäytävät valvottua ulospäin suuntautuvaa pääsyä varten

• VPC-päätepisteet AWS-palveluliikennettä varten ilman, että se joutuu julkiseen internetiin.

Tasainen VPC, jossa kaikki on samassa aliverkossa, saattaa tuntua helpolta. Kunnes jokin rikkoutuu ja vie kaiken mukanaan.

Kirjaaminen ja valvonta: Seuranta: Et voi korjata sitä, mitä et näe.

Tästä ei pitäisi enää edes keskustella. Kirjaaminen ei ole valinnaista. Jos et kirjaa CloudTrail, CloudWatch-metriikat ja VPC-virtauslokit, lennät sokkona.

Mutta tässä on juju - pelkkä kirjaaminen ei riitä. Sinun on todella katsottava lokeja. Luo hälytyksiä tärkeistä asioista. Suodata kohina pois. Ja varmista, että lokit on keskitetty tileille ja alueille. Hajanainen näkyvyys ei ole näkyvyyttä.

Salaa kaikki (ilman poikkeuksia)

Käytä KMS:ää levossa oleviin tietoihin. Käytä TLS:ää siirrettäviin tietoihin. Pyöritä avaimia. Valvo pääsyä. Tämä on yksi niistä aloista, joilla laiskottelu nyt tulee myöhemmin kalliiksi.

Äläkä unohda sellaisia asioita kuin RDS-salaus, EBS-tilavuusasetukset ja API Gateway TLS:n valvonta. Nämä pienet yksityiskohdat kasaantuvat.

Infrastruktuuri koodina tai ei

Vieläkö otat käyttöön napsauttamalla AWS-konsolia? Se sopii hyvin deville, mutta on vaarallista prodille.

Käytä Terraformia, CloudFormationia tai CDK:ta. Mitä tahansa tiimisi pitääkin parempana - valitse yksi ja pysy siinä. Versiohallitse malleja. Käytä CI/CD:tä käyttöönotossa. Automatisoi palautukset. Manuaaliset käyttöönotot ovat avoin kutsu virheille.

Lisäksi: merkitse kaikki. Resurssit ilman tunnisteita ovat kuin kaapelit ilman etikettejä - kukaan ei tiedä, mitä varten ne ovat, ja kaikki pelkäävät koskea niihin.

Skaalautuminen ilman uppoamista

Tehdään tämä nyt selväksi: AWS rakastaa, kun ylivaraus tehdään. Sinä saat "suorituskykyä", he saavat rahasi. Tehokkaassa skaalautumisessa on kyse mallien tuntemisesta - ja niiden suunnittelusta.

Käytä automaattisia skaalausryhmiä, spot-instansseja (varovasti) ja välimuistikerroksia. Mutta mikä tärkeintä: testaa kuormitettuna. Viimeinen asia, mitä haluat, on huomata, että RDS-instanssisi sulaa todellisen liikenteen alla kaksi päivää käynnistyksen jälkeen.

Varaa kapasiteettia silloin, kun se on järkevää. Se säästää rahaa ja estää yllättävät varaushäiriöt.

Katastrofien palautussuunnitelmat eivät ole vapaaehtoisia

Mitä tapahtuu, jos jokin alue kaatuu? Entä jos ensisijainen tietokanta vioittuu? Jos vastaus on "ööh... olisimme pulassa", on aika muokata DR-strategiaa.

Tämä ei tarkoita identtisen kopion rakentamista infrastruktuuristasi toiselle alueelle. Se tarkoittaa, että on tiedettävä:

• Mitä palautat

• Kuinka kauan se kestäisi

• Mitä tietoja menetettäisiin (jos menetettäisiin)

• Kuka on vastuussa mistäkin viansiirron aikana?

Ja kyllä - sinun pitäisi testata toipumissuunnitelmaasi. Muuten se on pelkkää fiktiota.

Yleiset vältettävät antikuviot

Kerrotaanpa nopeasti muutamia ei-ei-käytäntöjä, joita esiintyy aivan liian usein:

• Yksi iso tili kaikkeen: käytä AWS Organizations -tiliä. Erilliset prod, dev, staging jne.

• Oletusarvoisten VPC:iden ja suojausryhmien jättäminen koskemattomiksi: lukitse ne.

• Liiallinen turvautuminen t2.micro-instansseihin "testausta varten" - ne päätyvät lopulta prodiin.

• CloudWatch-kustannusten budjetoimatta jättäminen: kyllä, kirjaaminen maksaa. Kirjaamatta jättäminen maksaa enemmän.

• Pääsyn antaminen "korjaa se vain nopeasti": korjaa sen sijaan prosessisi.

Loppusanat? Pysy joustavana, pysy järjissäsi

Pilviarkkitehtuurissa ei ole kyse täydellisen asetelman löytämisestä. Kyse on siitä, että rakennetaan jotain, joka on joustava, kestävä ja ymmärrettävä muullekin kuin sen kirjoittajalle.

Et ole koskaan oikeastaan "valmis" - ja se on ihan okei. Tärkeintä on olla tarkoituksellinen. Vaikeiden kysymysten esittäminen varhaisessa vaiheessa. Auditointi usein. Automaatio siellä, missä se on tärkeää. Ja tietää, milloin on syytä pyytää apua.

AWS on tehokas, mutta siihen on myös helppo eksyä. Työskentely kokeneiden insinöörien kanssa, jotka elävät ja hengittävät pilviarkkitehtuuria, voi tehdä eron "se toimii enimmäkseen" ja "nukumme yömme" välillä.

Ja sitä varten kannattaa rakentaa.