- Nulinio pasitikėjimo modelio ir mažiausių privilegijų principo įgyvendinimas, siekiant sumažinti atakų paviršių.
- Gynybos strategijos, apimančios giluminę gynybą, ir tinklo segmentavimas, siekiant užkirsti kelią grėsmių judėjimui horizontaliai.
- Bendras atsakomybės valdymas pagal paslaugų modelį (IaaS, PaaS, SaaS) ir infrastruktūros naudojimas kaip kodo.
Šiandien debesijos aplinkos kūrimas nėra tiesiog kelių madingų paslaugų pasamdymas ir jų prijungimas, siekiant pamatyti, kas bus. Tai iš tikrųjų yra strateginis procesas, kuriame kiekvienas techninis sprendimas tiesiogiai veikia informacijos apsaugos galimybes ir tai, kaip sistema susidoros su didžiausiomis apkrovomis be gedimų. Kai projektas gerai įgyvendintas, sistema veikia sklandžiai; bet jei jis atliktas prastai, problemos paprastai iškyla ne iš karto, o būtent tada, kai verslas pradeda plėstis ir platforma tampa itin svarbi.
Įmonės dažnai daro klaidą, pirmiausia susitelkdamos į įrankį ir diskutuodamos, ar konteineriai, ar virtualios mašinos yra geresni, prieš suprasdamos tikruosius verslo poreikius . Prieš renkantis tokį tiekėją kaip AWS, „Azure“ ar „Google Cloud“, labai svarbu išanalizuoti riziką, numatomą tęstinumo lygį ir tai, ar komanda turi reikiamą brandą valdyti tai, kas kuriama. Tvirta architektūra visų pirma turi būti patikima, efektyvi ir stebima , neleisdama administratoriams nuolat gesinti gaisrų.
Debesų infrastruktūros projektavimo pagrindai
Paprastai tariant, debesijos architektūra nėra paslaugų katalogas, o darni tinklų , tapatybių, skaičiavimo ir saugojimo organizacija. Jei vienas iš šių sluoksnių sugenda, visa sistema susilpnėja; pavyzdžiui, galite turėti geriausiai pasaulyje užprogramuotą programą, bet jei leidimų yra per daug arba tinklas prastai suprojektuotas, turite atviras duris bet kokiai atakai.
Projektavimas turėtų prasidėti gerokai prieš diegimą. Vidinis įrankis nėra tas pats, kas vieša API, prieinama tūkstančiams vartotojų . Naudojimo modelis ir kritiškumas lemia, ar mums reikia labai automatizuoto monolito, ar mikropaslaugų architektūros. Turėkite omenyje: mikropaslaugos puikiai tinka mastelio keitimui, tačiau jos padidina operacinį sudėtingumą, kuris gali panaikinti privalumus, jei komanda nežino, kaip jų valdyti.
Kalbant apie saugumą, auksinė taisyklė – įdiegti kontrolės priemones nuo pirmos dienos . Debesų saugumo ir duomenų apsaugos palikimas pabaigai paprastai kainuoja labai brangiai, nes priklausomybių ir techninių praktikų taisymas, kai sistema jau veikia gamyboje, yra tikras košmaras.
Debesų saugumo ramsčiai: tapatybė, tinklas ir duomenys
Pirmoji gynybos linija yra tapatybė. Čia įsijungia mažiausių privilegijų principas , pagal kurį suteikiama tik griežtai būtina prieiga, taikant aiškiai apibrėžtas debesies prieigos politikas . Labai dažnai pasitaiko spąstai, kai suteikiami visi leidimai, siekiant išspręsti avarinę situaciją, o vėliau pamirštama juos atšaukti, taip sukuriant trapų ir pavojingą pagrindą.
Tinklas yra antrasis kritinis sluoksnis. Svarbu ne viską užrakinti saugiai pozicijai nustatyti, o pateisinti kiekvieną įėjimo tašką . Tvirta architektūra naudoja tinklo segmentavimą ir VPC, kad izoliuotų vidinius komponentus nuo viešųjų, taip apribodama atakos paviršių ir trukdydama potencialiam užpuolikui judėti į šoną.
Galiausiai, duomenų apsauga turi būti visapusiška. Nepakanka vien užšifruoti duomenų bazę; taip pat reikia stebėti saugomus objektus, atsargines kopijas ir konfidencialią informaciją. Duomenų šifravimas debesyje tiek perdavimo, tiek saugojimo metu, kartu su griežta informacijos jautrumo klasifikacija yra esminiai žingsniai siekiant išvengti katastrofiškų duomenų nutekėjimų.
Atsakomybės modeliai ir pažangios strategijos
Labai svarbu suprasti bendros atsakomybės modelį . Debesijos paslaugų teikėjas užtikrina fizinės infrastruktūros (duomenų centro) saugumą, tačiau klientas yra atsakingas už tai, ką į ją įdeda. Tai priklauso nuo modelio: IaaS atveju jūs valdote viską nuo operacinės sistemos; PaaS atveju jūs sutelkiate dėmesį į programą ir duomenis; o SaaS atveju nauda ir rizika skiriasi – nors paslaugų teikėjas atlieka beveik viską, jūs vis tiek esate atsakingi už prieigos valdymą ir atitiktį reglamentams.
Kita novatoriška koncepcija – „Zero Trust“ architektūra. Remiantis principu „ niekada nepasitikėti ir visada tikrinti “, šis požiūris panaikina „saugaus perimetro“ sąvoką. Nebereikia svarbu, ar vartotojas yra įmonės tinkle; kiekviena prieigos užklausa turi būti nuolat patvirtinama ir autentifikuojama.
Siekiant tai sustiprinti, rekomenduojama taikyti išsamią apsaugą , sukuriant kelis saugumo sluoksnius. Jei užkarda sugenda, duomenis apsaugo šifravimas; jei slaptažodis nuteka, MFA sustabdo įsilaužėlį. Šis perteklius yra tai, kas iš tikrųjų daro sistemą atsparią sudėtingoms grėsmėms.
Mastelio keitimas, operacijos ir dažniausios klaidos
Mastelio keitimas nėra tiesiog papildomo procesoriaus ar atminties pridėjimas, kai sistema lėta. Tikrasis mastelio keitimas apima komponentų atjungimą , kad jie galėtų vystytis savarankiškai. Kuriant paslaugas be būsenos, skaičiavimo sluoksnis gali būti keičiamas ir lengvai atkartojamas pagal poreikį.
Kritinė klaida yra tradicinės vietinės architektūros perkėlimas į debesį be jokio pertvarkymo. Vien virtualių mašinų „pakėlimas ir perkėlimas“ neužtikrina elastingumo ar saugumo; tai tik perkelia problemą kitur . Panašiai, per didelis techninis sudėtingumas (pvz., paslaugų tinklo diegimas, kai jis nereikalingas) tik padidina eksploatavimo sąnaudas, nepridėdamas realios vertės.
Stebimumas yra paskutinė dėlionės detalė. Be tikslių metrikų ir įspėjimų komanda yra akla ir gali reaguoti tik tada, kai sistema jau sugenda. Brandi architektūra naudoja infrastruktūrą kaip kodą (IaC), kad užtikrintų, jog diegimai būtų nuoseklūs, audituojami ir lengvai atkuriami klaidos atveju.
Sistema, kuri gali būti plečiama be nuolatinio pertvarkymo, kurioje aiškiai apibrėžti leidimai ir aiški dokumentacija, yra neabejotinas patikimo dizaino požymis. Saugumas nėra produktas, kurį perkate; tai nuolatinio stebėjimo ir nuoseklių techninių sprendimų disciplina, apsauganti skaitmeninį turtą nuolat besikeičiančioje aplinkoje.
