Debesijos infrastruktūros saugumo testavimas
Debesijos saugumo testavimas – tai debesijos infrastruktūros įsilaužimų testas: jis parodo, kaip toli AWS, Azure ar Google Cloud aplinkoje nueina užpuolikas, kai į jo rankas patenka vienas raktas ar viena paskyra. Ieškome klaidingų konfigūracijų, kelių į aukštesnes teises ir pamirštų viešai pasiekiamų paslaugų – netrikdydami kasdienio darbo.
Tikriname, kam kas prieinama: IAM roles ir politikas, ugniasienės taisykles, virtualius tinklus, prieigos nustatymus duomenų saugyklose bei federuotos tapatybės ir vieningo prisijungimo (SSO) silpnąsias vietas. Atskirai peržiūrime viską, kas matoma iš interneto.
Darbo pabaigoje gausite ne tik klaidų sąrašą, bet ir eiliškumą: ką verta pakeisti dar tą pačią dieną, o kas gali palaukti iki artimiausio planinio atnaujinimo.
Mumis pasitiki
Kas yra debesijos saugumo testavimas ir kodėl jis svarbus?
Debesijos paslaugų teikėjas atsako už savo infrastruktūrą, bet ne už tai, kaip ji sukonfigūruota organizacijos paskyroje. Būtent šią atsakomybės pusę ir tikriname: IAM politikas, tinklo segmentavimą bei saugyklų nustatymus AWS, Microsoft Azure ir Google Cloud aplinkose – ten, kur dažniausiai prasideda duomenų nutekėjimas ir teisių plėtimas.
Konfigūracijos peržiūra palygina nustatymus su gerosios praktikos rekomendacijomis. Tai naudinga, tačiau neatsako į svarbiausią klausimą – ar rasta klaida iš tiesų išnaudojama. Tai patikriname praktiškai, o ataskaitoje radinius surikiuojame pagal taisymo prioritetą.
Patirtis
Testuojame realias debesijos aplinkas, o ne pildome kontrolinį sąrašą. Kiekvieną radinį patikrina žmogus, ir į ataskaitą patenka tik tai, kas patvirtinta praktiškai.
Skaidrumas
Viso testavimo metu žinosite, kur esame priėję ir kurias sistemas tuo metu tikriname. Apie kritinį pažeidžiamumą pranešame iš karto, o ne galutinėje ataskaitoje.
Bendradarbiavimas
Kalbamės tiesiogiai su infrastruktūros komanda. Ataskaitą parengiame taip, kad taisymo darbus būtų galima pradėti jau kitą dieną.
Profesionalumas
Dirbame pagal rašytinį užsakovo leidimą ir sutartą apimtį. Susirašinėjimas ir duomenys lieka konfidencialūs ir pasibaigus darbams.
Testavimo eiga
Kaip vyksta debesijos aplinkos patikra
Pirmiausia perskaitome konfigūraciją, tada rankiniu būdu patikriname, ar užpuolikas iš tiesų gali ja pasinaudoti. Taip ataskaitoje nelieka radinių, kurie praktiškai rizikos nekelia.
Konsultacija ir apimtis
Sutariame dėl tikslų, tikrinamų AWS paskyrų, Azure prenumeratų ir GCP projektų bei dėl to, kurios sistemos yra kritinės.
Konfigūracijos apžvalga
Peržiūrime IAM politikas, įjungtas paslaugas, tinklus ir saugumo nustatymus.
Rizikų patvirtinimas
Atkuriame atakų scenarijus: paaiškėja, kurią klaidą galima išnaudoti ir kaip toli užpuolikas nueina su viena gauta prieiga.
Ataskaita ir rekomendacijos
Radinius surikiuojame pagal rizikos lygį ir kiekvienam surašome konkretų taisymo žingsnį.
Apimtis
Ką tikriname debesijoje
Nesustojame ties prieigos valdymu – į apimtį patenka ir tinklas, saugomi duomenys bei įvykių žurnalai.
Kelios debesijos platformos
Testuojame AWS, Azure ir GCP, įskaitant kiekvienos platformos integruotas paslaugas. Organizacijose debesija dažnai prasideda nuo Microsoft 365 ir Entra ID, todėl ir jie patenka į apimtį.
IAM ir rolės
Atsekame, kam kokios teisės suteiktos, ar veikia mažiausių teisių principas ir kur atsiveria kelias į aukštesnes teises.
Tinklo segmentavimas
Tikriname VPC ir VNet nustatymus, saugumo grupes bei ugniasienės taisykles.
Saugyklos ir duomenys
Vertiname S3 ir Blob Storage talpyklas, šifravimą ir prieigos prie duomenų teises – taip pat ir prie asmens duomenų, kurių nutekėjimo atveju gali tekti pranešti Valstybinei duomenų apsaugos inspekcijai.
Viešai pasiekiamos paslaugos
Randame atvirus galinius taškus ir valdymo sąsajas, pasiekiamas iš interneto.
Žurnalai ir aptikimas
Išsiaiškiname, ką užrašo įvykių žurnalai, apie ką sistema įspėja ir ar ataka apskritai tampa pastebima.
Palyginimas
Debesijos saugumo testavimas ar automatizuota konfigūracijos patikra?
Automatizuota patikra greitai išvardija nukrypimus nuo rekomenduojamų nustatymų. Testavimas parodo, kuris nukrypimas veda į realų incidentą ir ką užpuolikas juo pasiekia.
| Aspektas | Automatizuota konfigūracijos patikra | Debesijos saugumo testavimas |
|---|---|---|
| Tikslas | Aptikti klaidingas konfigūracijas ir nukrypimus nuo gerosios praktikos. | Patvirtinti, ar klaidą galima išnaudoti ir kokia yra rizika. |
| Metodas | Automatizuotas skenavimas ir palyginimas su bazine konfigūracija. | Rankinis testavimas ir atakų scenarijų atkūrimas. |
| Gylis | Plati aprėptis be įrodymo, kad klaidą galima išnaudoti. | Detali patikra su įrodymu, kad klaidą pavyko išnaudoti. |
| Rezultatas | Klaidų sąrašas ir rekomendacijos. | Pagal riziką surikiuota ataskaita su konkrečiais taisymo žingsniais. |
Nežinote, kuris būdas tinka jūsų aplinkai? Parašykite mums.
Klientų atsiliepimai
Ką apie mus sako klientai
Dažnai užduodami klausimai (DUK)
01 Kiek trunka debesijos aplinkos patikra?
Priklauso nuo aplinkos dydžio ir sudėtingumo. Nedidelės aplinkos su keliomis paslaugomis patikra paprastai trunka 3–5 dienas, plačios gamybinės aplinkos su keliomis paskyromis – 1–3 savaites. Apimtį ir terminą raštu fiksuojame dar prieš sudarant sutartį.
02 Ar prireiks prieigos prie debesijos paskyrų?
Didžiąją darbo dalį galima atlikti tik iš vidaus, todėl prašome naudotojo arba rolės su skaitymo teisėmis; rizikingesnius žingsnius deriname iš anksto. Testuojame ir iš išorės, be prieigos – taip paaiškėja, ką užpuolikas pasiekia dar nepatekęs į aplinką. Dirbame nuotoliniu būdu iš Slovakijos, o debesijos patikrai fizinis buvimas vietoje nereikalingas.
03 Nuo ko priklauso debesijos patikros kaina?
Lemia apimtis: kiek paskyrų, prenumeratų ir paslaugų peržiūrime, kiek sudėtingas yra teisių modelis ir ar aplinka veikia vienoje, ar keliose debesijose. Po trumpo pokalbio parengiame fiksuotą, neįpareigojantį pasiūlymą.
04 Kaip dažnai patikrą reikėtų kartoti?
Bent kartą per metus ir po kiekvieno didesnio pokyčio – įdiegus naują paslaugą, perkėlus sistemą į debesiją ar pertvarkius teisių modelį. Įsilaužimų testavimas pagal Lietuvos teisės aktus nėra privalomas, tačiau kibernetinio saugumo subjektams Kibernetinio saugumo reikalavimų apraše nustatyti savi reikalavimai – pavyzdžiui, išsamus pažeidžiamumų skenavimas ne rečiau kaip kas šešis mėnesius. Debesijoje veikiančios sistemos iš tos apimties neiškrenta vien todėl, kad serveris priklauso kitam.
05 Ką gausite po patikros?
Ataskaitą, kurioje yra santrauka vadovybei, radinių aprašymas, rizikos lygiai ir konkretūs taisymo žingsniai. Rezultatus aptariame baigiamajame pokalbyje su komanda. Ištaisius klaidas atliekame pakartotinį patikrinimą.
