Įsilaužta į debesijos platformą „Railway“: klientus ragina skubiai pakeisti visus slaptus raktus

Sekite TechNaujienos Google

Debesijos programų prieglobos bendrovė „Railway“ perspėjo apie kibernetinį incidentą, kurio metu pašaliniai asmenys įgijo neteisėtą prieigą prie dalies jos vidinių sistemų. Platforma paragino klientus atnaujinti prieigos raktus ir slaptažodžius, naudojamus jungiantis prie duomenų bazių, API bei kitų paslaugų. Tokia rekomendacija aktuali net tiems kūrėjams, kurių programos incidento metu nebuvo išjungtos.

„Railway“ naudojasi programinės įrangos komandos, kurios nori greitai paleisti internetines programas ir duomenų bazes, neprižiūrėdamos visos serverių infrastruktūros. Tokiose aplinkose įprasta saugoti aplinkos kintamuosius, tarp kurių gali būti išorinių paslaugų prisijungimo raktai. Jei prie jų prieina užpuolikas, rizika gali išplisti už pačios prieglobos platformos ribų.

Oficialioje pirminėje incidento ataskaitoje bendrovė teigia, kad potencialiai paveikta iki 1,85 proc. klientų darbo erdvių. Tai rizikos apimties įvertinimas, o ne įrodymas, kad kiekvienos tokios erdvės slapti duomenys tikrai buvo panaudoti.

Kompromituoto rakto vertė užpuolikui priklauso nuo jam suteiktų teisių. Raktas, galintis tik skaityti viešus duomenis, paprastai sukelia mažesnę riziką už tokį, kuris leidžia keisti mokėjimo sąskaitą, išsiųsti el. laiškus ar valdyti duomenų bazę. Todėl vienodos rekomendacijos visiems klientams ne visada yra pakankamai tikslios. Organizacijoms pravartu taikyti mažiausių būtinų teisių principą ir atskirti testavimo bei gamybinių sistemų prisijungimus. Taip sumažinama tikimybė, kad vienas nutekėjęs raktas leis pasiekti visą infrastruktūrą. Taip pat svarbu iš anksto suplanuoti raktų keitimą be ilgos prastovos, nes kritinio incidento metu laikas tampa vienu svarbiausių veiksnių. Nors „Railway“ šiuo atveju yra pagrindinis įvykio dalyvis, panašios rizikos egzistuoja įvairiose debesijos platformose. Tyrimas dar gali atskleisti naujų aplinkybių.

Naujausi straipsniai

4 min. skaitymo • prieš 4 minutės

Buvę „Meta“ inžinieriai sukūrė DI pakabuką, kuris klausosi tik savo savininko: pritraukė 33 mln. dolerių

4 min. skaitymo • prieš 24 minutės

„Rivian“ įsigijo DI bendrovę: automobilius mokys vairuoti virtualiuose pasauliuose

4 min. skaitymo • prieš 44 minutės

Kinijai priskiriami programišiai įsilaužė į IT milžinę: atakoms naudojo DI agentus

Visi naujausi straipsniai →

Pasak bendrovės, užpuolikai galėjo pasiekti dalį saugotų aplinkos kintamųjų. Tarp jų būna duomenų bazių slaptažodžių, debesijos paslaugų tokenų ir DI modelių API raktų. Dėl to vien paskyros slaptažodžio pakeitimas nebūtinai išsprendžia visą problemą: kiekvienai išorinei paslaugai kartais reikia atskirai panaikinti seną prieigą ir sugeneruoti naują.

Kodėl vieno tiekėjo incidentas svarbus daugybei programų

Šiuolaikinės skaitmeninės paslaugos kuriamos iš tarpusavyje sujungtų komponentų. Vienos įmonės internetinė svetainė gali būti talpinama „Railway“, mokėjimai vykdomi kitoje bendrovėje, el. laiškai siunčiami per trečią, o vartotojų prisijungimai tvarkomi per ketvirtą. Tokia architektūra leidžia sparčiai kurti produktus, bet kartu atsiranda pasitikėjimo grandinė.

Jei viena grandis pažeidžiama, užpuolikas gali mėginti pasiekti kitas naudodamas pavogtą raktą. Todėl saugumo incidentų metu itin svarbu iš anksto žinoti, kur konkretūs raktai naudojami, kokias teises jie suteikia ir kaip greitai galima juos pakeisti nepaveikiant paslaugos veikimo.

„Railway“ tyrėjai taip pat nurodė, kad viena galimų užpuolikų interesų sričių galėjo būti DI paslaugų API raktai. Tačiau tai dar nėra galutinai įrodytas kiekvieno užpuoliko tikslas. Kol nepaskelbta visa techninė ataskaita, reikėtų vengti tvirtinimo, kad būtent konkreti DI bendrovė ar modelis buvo pagrindinis atakos taikinys.

Praktikoje raktų keitimas turi būti vykdomas apgalvotai, kad nebūtų sukelta nauja prastova. Pirmiausia galima sukurti naują prieigos raktą, jį įdiegti sistemoje ir patikrinti, ar paslauga toliau veikia, o tuomet atšaukti senąjį. Tačiau kai kurios platformos nepalaiko dviejų aktyvių raktų, todėl toks procesas turi būti pritaikytas konkrečiai paslaugai. Jei programą prižiūri kelios komandos, būtina dokumentuoti pakeitimus ir užtikrinti, kad visi žinotų, kuris raktas galioja. Įmonėms verta patikrinti ir tai, ar atsarginių kopijų sistemos nenusaugojo senų prisijungimų, kurie vėliau galėtų netyčia būti atkurti. Šios procedūros nėra išskirtinai „Railway“ klientų problema – panašiai turėtų ruoštis bet kuris verslas, kurio paslaugos veikia debesijoje.

Ką turi padaryti platformos naudotojai

Pirmiausia reikia patikrinti oficialų „Railway“ pranešimą ir asmeninės darbo erdvės perspėjimus. Tada sudaryti sąrašą slaptų duomenų, kuriuos programa laikė aplinkos kintamuosiuose. Svarbiausias veiksmas – atšaukti potencialiai paveiktus raktus jų tiekėjo pusėje ir sugeneruoti naujus, nepaliekant senojo veikiančio.

Atnaujinus raktus pravartu peržiūrėti prisijungimų žurnalus bei neįprastas duomenų bazių užklausas. Jeigu raktas suteikė plačias administratoriaus teises, reikėtų įvertinti, ar nebuvo pakeistos prieigos taisyklės, sukurti nauji naudotojai arba eksportuoti duomenys. Pažeidimų tyrimo apimtis turi atitikti konkrečias naudojamas paslaugas.

„TechNaujienos.lt“ anksčiau aprašė kibernetinio saugumo krizę Japonijoje ir saugumo pataisų diegimo sunkumus. „Railway“ atvejis skiriasi tuo, kad kyla pavojus ne vien programų kodui, bet ir pasitikėjimui bendros infrastruktūros valdytoju.

Incidentas primena svarbų principą: net tinkamai veikiančia debesijos programa negalima laikyti automatiškai saugios vien todėl, kad ji yra prieinama lankytojams. Saugumas priklauso ir nuo nematomų jos jungčių su kitomis paslaugomis, todėl tvarkingi prieigos žurnalai bei periodinis raktų keitimo planas tampa būtinybe.