Vis daugiau organizacijų savo sistemas ir duomenis laiko ne savo serverinėse, o debesijos platformose, tokiose kaip „Amazon Web Services“ (AWS), „Microsoft Azure“ ar „Google Cloud“. Debesija suteikia lankstumo ir greičio, tačiau keičia ir saugumo logiką: atsiranda naujų rizikų, o daugelis senų apsaugos priemonių tampa nebeaktualios. Didžioji dalis debesijos incidentų kyla ne dėl to, kad paslaugų teikėjas buvo nulaužtas, o dėl klientų pačių padarytų konfigūracijos klaidų. Šioje temoje nagrinėsime, kaip saugiai naudoti debesiją.
Debesijos paslaugų modeliai
Debesijos paslaugos dažniausiai skirstomos į tris modelius.
IaaS (angl. Infrastructure as a Service, infrastruktūra kaip paslauga): klientas nuomojasi virtualius serverius, tinklus ir saugyklas, o operacinę sistemą, programas ir duomenis valdo pats.
PaaS (angl. Platform as a Service, platforma kaip paslauga): teikėjas valdo ir operacinę sistemą, o klientas tik diegia savo programas, pavyzdžiui, valdomą duomenų bazę ar programų talpinimo paslaugą.
SaaS (angl. Software as a Service, programinė įranga kaip paslauga): klientas naudoja jau paruoštą programą, pavyzdžiui, „Microsoft 365“, „Google Workspace“ ar CRM sistemą, o beveik viską kitą valdo teikėjas.
Bendros atsakomybės modelis
Svarbiausia debesijos saugumo sąvoka yra bendros atsakomybės modelis (angl. shared responsibility model). Jis apibrėžia, už ką atsako debesijos teikėjas, o už ką klientas. Paprastai sakoma, kad teikėjas atsako už debesijos saugumą, o klientas už saugumą debesyje.
Teikėjas visada atsako už fizinius duomenų centrus, aparatinę įrangą ir pagrindinę infrastruktūrą. Klientas visada atsako už savo duomenis, naudotojų paskyras ir prieigos teises. Tai, kas yra tarp jų, priklauso nuo modelio: IaaS atveju klientas atsako ir už operacinės sistemos atnaujinimus bei tinklo taisykles, PaaS atveju už programos konfigūraciją, o SaaS atveju daugiausia už tai, kas ir kaip naudojasi paslauga.
Dažna ir pavojinga klaida yra manyti, kad perkėlus sistemas į debesį saugumu pasirūpins teikėjas. Teikėjas nepasirūpins, jei klientas viešai atvers duomenų saugyklą arba suteiks administratoriaus teises visiems darbuotojams.
Dažniausios debesijos rizikos
Konfigūracijos klaidos. Tai pagrindinė debesijos incidentų priežastis. Tipiški pavyzdžiai yra viešai prieinamos saugyklos su jautriais duomenimis, iš interneto pasiekiamos duomenų bazės ar valdymo prievadai, išjungtas žurnalų registravimas ir numatytieji nustatymai, kurie nebuvo peržiūrėti. Debesijoje išteklius sukurti labai lengva, todėl ir klaidą padaryti lengva.
Per plačios teisės. Debesijos tapatybės ir prieigos valdymo politikos gali būti labai detalios, tačiau dėl patogumo dažnai suteikiamos plačiausios teisės. Jei tokią paskyrą ar programą užvaldo užpuolikas, jis gauna prieigą prie visos aplinkos. Gerai žinomas pavyzdys yra 2019 m. „Capital One“ incidentas, kai dėl netinkamai sukonfigūruotos žiniatinklio programų ugniasienės ir per plačių teisių turinčios rolės buvo nutekinti daugiau nei 100 milijonų klientų duomenys.
Nutekėję prieigos raktai. Debesijos API raktai ir slaptažodžiai neretai per klaidą įrašomi į programos kodą ir paskelbiami viešose kodo saugyklose. Automatizuoti robotai tokius raktus suranda per kelias minutes, todėl pasekmės būna greitos, pavyzdžiui, kriptovaliutų kasimas kliento sąskaita.
Šešėliniai ištekliai. Darbuotojai ar komandos sukuria debesijos išteklius, apie kuriuos saugumo komanda nežino, ir jie lieka be priežiūros.
Tapatybė kaip debesijos perimetras
Debesijoje nėra fizinės tinklo ribos, todėl svarbiausia apsauga tampa tapatybė. Pagrindiniai principai yra šie.
Pagrindinė paskyra (angl. root account AWS arba visuotinis administratorius „Azure“) naudojama tik išimtiniais atvejais, apsaugoma sukčiavimui atsparia kelių veiksnių autentifikacija ir stebima. Kasdieniam darbui naudojamos atskiros, mažiau teisių turinčios paskyros.
Mažiausių privilegijų principas taikomas ne tik žmonėms, bet ir programoms bei paslaugoms. Kiekviena funkcija gauna tik tas teises, kurių jai reikia.
Laikini prisijungimo duomenys vietoj ilgalaikių raktų. Programoms debesyje suteikiamos rolės su automatiškai keičiamais trumpalaikiais raktais, o ne nuolatiniai raktai, įrašyti į konfigūracijos failus.
Slaptų duomenų valdymas. Slaptažodžiai, API raktai ir sertifikatai laikomi specialiose saugyklose, tokiose kaip „AWS Secrets Manager“, „Azure Key Vault“ ar „Google Secret Manager“, o ne programos kode.
Duomenų apsauga ir tinklas
Debesijos platformos leidžia šifruoti duomenis ir saugyklose, ir perdavimo metu. Dažniausiai šifravimas įjungtas numatytai, tačiau svarbu valdyti šifravimo raktus: kas gali juos naudoti ir ar jie valdomi teikėjo, ar paties kliento.
Tinklo lygmeniu debesijoje kuriami virtualūs privatūs tinklai su potinkliais, o srautą riboja saugumo grupės ir tinklo taisyklės, veikiančios kaip ugniasienės. Duomenų bazės ir vidinės paslaugos neturėtų būti pasiekiamos iš interneto, o administravimas vyksta per saugius prieigos kanalus.
Svarbu stebėti ir duomenų buvimo vietą: pagal BDAR asmens duomenų perdavimas už ES ribų turi atitikti specialius reikalavimus, todėl organizacijos dažnai renkasi ES regionuose esančius duomenų centrus.
Stebėsena ir saugumo būklės valdymas
Kiekviena debesijos platforma turi administravimo veiksmų žurnalus: AWS tai „CloudTrail“, „Azure“ veiklos žurnalas, „Google Cloud“ audito žurnalai. Juose matyti, kas, kada ir ką pakeitė aplinkoje. Šie žurnalai turi būti įjungti visuose regionuose, apsaugoti nuo ištrynimo ir siunčiami į SIEM sistemą. Taip pat naudojamos integruotos grėsmių aptikimo paslaugos, pavyzdžiui, „Amazon GuardDuty“ ar „Microsoft Defender for Cloud“.
Kadangi konfigūracijos klaidos yra didžiausia rizika, naudojami debesijos saugumo būklės valdymo (angl. Cloud Security Posture Management, CSPM) įrankiai. Jie nuolat tikrina konfigūraciją pagal geriausias praktikas, pavyzdžiui, CIS debesijos standartus, ir praneša apie nukrypimus: viešas saugyklas, išjungtus žurnalus ar paskyras be kelių veiksnių autentifikacijos. Platesni sprendimai, vadinami CNAPP (angl. Cloud-Native Application Protection Platform), sujungia konfigūracijos, darbo krūvių ir tapatybių apsaugą.
Infrastruktūra kaip kodas ir konteineriai
Šiuolaikinėse organizacijose debesijos infrastruktūra dažnai aprašoma kodu, naudojant tokius įrankius kaip „Terraform“ ar „AWS CloudFormation“. Šis požiūris vadinamas infrastruktūra kaip kodas (angl. Infrastructure as Code, IaC). Saugumo požiūriu tai didelis privalumas: konfigūraciją galima patikrinti automatiškai dar prieš ją įdiegiant ir taip klaidas sugauti anksčiau, nei jos pasiekia realią aplinką.
Programos debesyje dažnai veikia konteineriuose, valdomuose „Kubernetes“ platforma. Jų saugumui svarbu naudoti patikimus ir reguliariai skenuojamus konteinerių atvaizdus, nevykdyti konteinerių su root teisėmis ir riboti tinklo srautą tarp jų.
Svarbiausios temos išvados
Debesijos saugumas grindžiamas bendros atsakomybės modeliu: teikėjas saugo infrastruktūrą, o klientas atsako už savo duomenis, tapatybes ir konfigūraciją, o ši atsakomybė priklauso nuo IaaS, PaaS ar SaaS modelio. Dažniausios rizikos yra konfigūracijos klaidos, per plačios teisės ir nutekėję prieigos raktai. Debesijoje pagrindinis perimetras yra tapatybė, todėl taikomi mažiausių privilegijų principas, laikini prisijungimo duomenys ir slaptų duomenų saugyklos. Veiklos žurnalai, grėsmių aptikimo paslaugos ir CSPM įrankiai leidžia pastebėti problemas, o infrastruktūra kaip kodas leidžia klaidas sugauti dar prieš diegimą. Kitoje temoje nagrinėsime saugumo valdymą organizacijos lygmeniu ir karjeros galimybes.
Savikontrolės klausimai
1. Ką reiškia teiginys, kad teikėjas atsako už debesijos saugumą, o klientas už saugumą debesyje?
2. Kaip skiriasi kliento atsakomybė IaaS ir SaaS modeliuose? Pateikite pavyzdį.
3. Kodėl konfigūracijos klaidos yra dažniausia debesijos incidentų priežastis?
4. Kodėl programoms debesyje rekomenduojama naudoti roles su trumpalaikiais raktais, o ne ilgalaikius API raktus?
5. Kaip infrastruktūra kaip kodas padeda išvengti konfigūracijos klaidų?
Visos pamokos
