Debesų saugos stebėjimas

Duomenų ir programų perkėlimas į debesį yra naujas iššūkis įmonių SOC, kurios ne visada pasiruošusios stebėti kitų žmonių infrastruktūrą. „Netoskope“ duomenimis, vidutinė įmonė (matyt, JAV) naudoja 1246 22 skirtingas debesijos paslaugas, tai yra 1246% daugiau nei prieš metus. 175 debesų paslaugos!!! 170 iš jų susiję su personalo paslaugomis, 110 – su rinkodara, 76 – komunikacijos sritimi, 700 – su finansais ir CRM. „Cisco“ naudoja „tik“ XNUMX išorinių debesies paslaugų. Taigi mane šiek tiek glumina šie skaičiai. Tačiau bet kuriuo atveju problema ne juose, o tame, kad debesiu gana aktyviai pradeda naudotis vis daugiau įmonių, kurios norėtų turėti tokias pačias debesų infrastruktūros stebėjimo galimybes kaip ir savo tinkle. Ir ši tendencija auga – anot pagal Amerikos sąskaitų rūmus Iki 2023 m. JAV ketinama uždaryti 1200 6250 duomenų centrų (XNUMX XNUMX jau uždaryta). Tačiau perėjimas prie debesies nėra tik „perkelkime savo serverius į išorinį teikėją“. Nauja IT architektūra, nauja programinė įranga, nauji procesai, nauji apribojimai... Visa tai įneša reikšmingų pokyčių ne tik IT, bet ir informacijos saugumo darbe. Ir jei tiekėjai išmoko kažkaip susidoroti su paties debesies saugumo užtikrinimu (laimei, yra daug rekomendacijų), tai su debesų informacijos saugos stebėjimu, ypač SaaS platformose, kyla didelių sunkumų, apie kuriuos kalbėsime.

Tarkime, jūsų įmonė dalį infrastruktūros perkėlė į debesį... Stop. Ne šitaip. Jei infrastruktūra buvo perkelta, o jūs tik dabar galvojate, kaip ją stebėsite, vadinasi, jau pralaimėjote. Nebent „Amazon“, „Google“ ar „Microsoft“ (ir tada su išlygomis), tikriausiai neturėsite daug galimybių stebėti savo duomenis ir programas. Gerai, jei jums suteikiama galimybė dirbti su rąstais. Kartais saugos įvykių duomenys bus pasiekiami, bet neturėsite prieigos prie jų. Pavyzdžiui, Office 365. Jei turite pigiausią E1 licenciją, tai saugumo įvykiai jums visiškai neprieinami. Jei turite E3 licenciją, jūsų duomenys saugomi tik 90 dienų, o tik turint E5 licenciją, žurnalų trukmė pasiekiama metus (tačiau tai turi ir savų niuansų, susijusių su būtinybe atskirai prašyti kelių funkcijų, skirtų darbui su žurnalais iš „Microsoft“ palaikymo). Beje, E3 licencija stebėjimo funkcijomis yra daug silpnesnė nei korporatyvinė birža. Norint pasiekti tą patį lygį, jums reikia E5 licencijos arba papildomos išplėstinės atitikties licencijos, kuriai gali prireikti papildomų pinigų, kurie nebuvo įtraukti į jūsų finansinį modelį, skirtą pereiti prie debesies infrastruktūros. Ir tai tik vienas su debesų informacijos saugos stebėjimu susijusių problemų nepakankamo įvertinimo pavyzdys. Šiame straipsnyje, nepretenduodamas į išsamumą, noriu atkreipti dėmesį į kai kuriuos niuansus, į kuriuos reikėtų atsižvelgti renkantis debesų paslaugų teikėją saugumo požiūriu. O straipsnio pabaigoje bus pateiktas kontrolinis sąrašas, kurį verta užpildyti prieš galvojant, kad debesų informacijos saugumo stebėjimo klausimas išspręstas.

Yra keletas tipiškų problemų, dėl kurių debesų aplinkoje įvyksta incidentai, į kuriuos informacijos saugos tarnybos nespėja reaguoti arba jų visai nemato:

• Saugos žurnalai neegzistuoja. Tai gana dažna situacija, ypač tarp pradedančiųjų debesijos sprendimų rinkos žaidėjų. Tačiau neturėtumėte iš karto jų atsisakyti. Smulkūs žaidėjai, ypač buitiniai, yra jautresni klientų reikalavimams ir gali greitai įgyvendinti kai kurias reikalingas funkcijas, pakeisdami patvirtintą savo gaminių planą. Taip, tai nebus „Amazon“ „GuardDuty“ ar „Bitrix“ „Proaktyvios apsaugos“ modulio analogas, bet bent jau kažkas.
• Informacijos saugumas nežino, kur yra saugomi žurnalai arba nėra prieigos prie jų. Čia reikia pradėti derybas su debesijos paslaugų teikėju – galbūt jis tokią informaciją suteiks, jei laikys klientą sau reikšmingu. Tačiau apskritai nėra labai gerai, kai prieiga prie žurnalų suteikiama „specialiu sprendimu“.
• Pasitaiko ir taip, kad debesų tiekėjas turi žurnalus, tačiau juose teikiamas ribotas stebėjimas ir įvykių registravimas, kurių nepakanka visiems incidentams aptikti. Pavyzdžiui, galite gauti tik pakeitimų svetainėje žurnalus arba naudotojo autentifikavimo bandymų žurnalus, bet ne kitus įvykius, pvz., tinklo srautą, kurie nuo jūsų paslėps visą įvykių, apibūdinančių bandymus įsilaužti į debesies infrastruktūrą, sluoksnį.
• Žurnalai yra, bet prieiga prie jų sunkiai automatizuojama, o tai verčia juos stebėti ne nuolat, o pagal grafiką. Ir jei negalite automatiškai atsisiųsti žurnalų, atsisiunčiant žurnalus, pavyzdžiui, „Excel“ formatu (kaip ir daugelio vietinių debesies sprendimų teikėjų atveju), įmonės informacijos saugos tarnyba gali net nenorėti su jais dirbti.
• Nėra žurnalo stebėjimo. Tai bene neaiškiausia priežastis, kodėl debesų aplinkoje įvyksta informacijos saugumo incidentai. Atrodo, kad yra žurnalų, ir galima automatizuoti prieigą prie jų, bet niekas to nedaro. Kodėl?

Bendra debesų saugos koncepcija

Perėjimas prie debesies visada yra pusiausvyros paieška tarp noro išlaikyti infrastruktūros kontrolę ir jos perdavimo į profesionalesnes debesų paslaugų teikėjo rankas, kurios specializuojasi ją prižiūrėti. O debesų saugumo srityje taip pat reikia ieškoti šios pusiausvyros. Be to, priklausomai nuo naudojamo debesies paslaugų teikimo modelio (IaaS, PaaS, SaaS), šis balansas visą laiką skirsis. Bet kuriuo atveju turime atsiminti, kad visi debesų tiekėjai šiandien vadovaujasi vadinamuoju bendros atsakomybės ir bendros informacijos saugumo modeliu. Už vienus dalykus atsakingas debesis, už kitus – klientas, talpinantis savo duomenis, programas, virtualias mašinas ir kitus išteklius debesyje. Neapgalvota būtų tikėtis, kad eidami į debesį visą atsakomybę perkelsime tiekėjui. Tačiau taip pat neprotinga pačiam sukurti visą saugumą pereinant prie debesies. Reikalingas balansas, kuris priklausys nuo daugelio faktorių: - rizikos valdymo strategijos, grėsmės modelio, debesijos tiekėjui prieinamų saugumo mechanizmų, teisės aktų ir kt.

Pavyzdžiui, už debesyje talpinamų duomenų klasifikavimą visada atsako klientas. Debesijos tiekėjas ar išorinis paslaugų teikėjas jam gali padėti tik įrankiais, kurie vienu ar kitu būdu padės pažymėti duomenis debesyje, nustatyti pažeidimus, ištrinti įstatymus pažeidžiančius duomenis ar užmaskuoti. Kita vertus, už fizinį saugumą visada atsako debesų paslaugų teikėjas, kurio jis negali dalytis su klientais. Tačiau viskas, kas yra tarp duomenų ir fizinės infrastruktūros, yra šio straipsnio diskusijų objektas. Pavyzdžiui, už debesies prieinamumą atsako teikėjas, o už ugniasienės taisyklių nustatymą arba šifravimo įjungimą – klientas. Šiame straipsnyje pabandysime pažvelgti, kokius informacijos saugos stebėjimo mechanizmus šiandien teikia įvairūs Rusijoje populiarūs debesų tiekėjai, kokios jų naudojimo ypatybės ir kada verta pažvelgti į išorinių perdangų sprendimus (pavyzdžiui, Cisco E- pašto sauga), kurios išplečia jūsų debesies galimybes kibernetinio saugumo požiūriu. Kai kuriais atvejais, ypač jei laikotės kelių debesų strategijos, jums neliks nieko kito, kaip naudoti išorinius informacijos saugos stebėjimo sprendimus keliose debesų aplinkose vienu metu (pavyzdžiui, Cisco CloudLock arba Cisco Stealthwatch Cloud). Na, o kai kuriais atvejais suprasite, kad jūsų pasirinktas (ar jums primestas) debesų tiekėjas visiškai nesiūlo informacijos saugumo stebėjimo galimybių. Tai nemalonu, bet ir ne mažai, nes leidžia tinkamai įvertinti rizikos, susijusios su darbu su šiuo debesiu, lygį.

Debesų saugos stebėjimo gyvavimo ciklas

Norėdami stebėti naudojamų debesų saugumą, turite tik tris parinktis:

• pasikliaukite debesijos paslaugų teikėjo pateiktais įrankiais,
• naudoti sprendimus iš trečiųjų šalių, kurios stebės jūsų naudojamas IaaS, PaaS arba SaaS platformas,
• sukurti savo debesų stebėjimo infrastruktūrą (tik IaaS / PaaS platformoms).

Pažiūrėkime, kokias savybes turi kiekviena iš šių parinkčių. Tačiau pirmiausia turime suprasti bendrą sistemą, kuri bus naudojama stebint debesų platformas. Išskirčiau 6 pagrindinius informacijos saugos stebėjimo debesyje proceso komponentus:

• Infrastruktūros paruošimas. Reikalingų programų ir infrastruktūros nustatymas informacijos saugumui svarbiems įvykiams surinkti į saugyklą.
• Kolekcija. Šiame etape saugos įvykiai sujungiami iš įvairių šaltinių, kad vėliau būtų perduodami apdoroti, saugoti ir analizuoti.
• Gydymas. Šiame etape duomenys transformuojami ir praturtinami, kad būtų lengviau atlikti tolesnę analizę.
• Sandėliavimas. Šis komponentas yra atsakingas už trumpalaikį ir ilgalaikį surinktų apdorotų ir neapdorotų duomenų saugojimą.
• Analizė. Šiame etape jūs turite galimybę aptikti incidentus ir reaguoti į juos automatiškai arba rankiniu būdu.
• Ataskaitų teikimas. Šis etapas padeda suformuluoti pagrindinius rodiklius suinteresuotoms šalims (vadybai, auditoriams, debesijos tiekėjams, klientams ir kt.), kurie padeda priimti tam tikrus sprendimus, pavyzdžiui, keisti tiekėją ar stiprinti informacijos saugumą.

Suprasdami šiuos komponentus galėsite greitai nuspręsti, ką galite pasiimti iš savo paslaugų teikėjo ir ką turėsite padaryti patys arba pasitelkę išorės konsultantus.

Integruotos debesies paslaugos

Jau rašiau aukščiau, kad daugelis debesų paslaugų šiandien nesuteikia jokių informacijos saugumo stebėjimo galimybių. Apskritai jie nekreipia daug dėmesio į informacijos saugumo temą. Pavyzdžiui, viena iš populiarių Rusijos paslaugų, skirtų ataskaitoms vyriausybinėms įstaigoms siųsti internetu (konkrečiai neminėsiu jos pavadinimo). Visas skyrius apie šios paslaugos saugumą sukasi apie sertifikuoto CIPF naudojimą. Kitos vietinės debesies paslaugos, skirtos elektroninių dokumentų valdymui, informacijos saugos skyrius nesiskiria. Jame kalbama apie viešojo rakto sertifikatus, sertifikuotą kriptografiją, interneto spragų šalinimą, apsaugą nuo DDoS atakų, užkardų naudojimą, atsargines kopijas ir net reguliarius informacijos saugumo auditus. Tačiau nėra nė žodžio apie stebėjimą, nei apie galimybę patekti į informacijos saugumo įvykius, kurie gali sudominti šio paslaugų teikėjo klientus.

Apskritai, debesijos paslaugų teikėjas aprašo informacijos saugos problemas savo svetainėje ir dokumentuose, galite suprasti, kaip rimtai jis vertina šią problemą. Pavyzdžiui, jei skaitote „Mano biuro“ produktų vadovus, apie saugumą nėra nė žodžio, o atskiro produkto „Mano biuras“ dokumentacijoje. KS3“, skirtas apsisaugoti nuo neteisėtos prieigos, yra įprastas FSTEC 17 eilės punktų sąrašas, kurį „Mano biuras.KS3“ įgyvendina, tačiau neaprašyta, kaip tai įgyvendina ir, svarbiausia, kaip tai padaryti. integruoti šiuos mechanizmus su įmonės informacijos saugumu. Galbūt tokia dokumentacija yra, bet aš jos neradau viešai, „Mano biuro“ svetainėje. Nors gal aš tiesiog neturiu prieigos prie šios slaptos informacijos?..

„Bitrix“ situacija yra daug geresnė. Dokumentacijoje aprašomi įvykių žurnalų formatai ir, kas įdomu, įsibrovimų žurnalas, kuriame pateikiami įvykiai, susiję su galimomis grėsmėmis debesų platformai. Iš ten galite ištraukti IP, vartotojo ar svečio vardą, įvykio šaltinį, laiką, vartotojo agentą, įvykio tipą ir kt. Tiesa, su šiais įvykiais galite dirbti arba iš paties debesies valdymo pulto, arba įkelti duomenis MS Excel formatu. Dabar sunku automatizuoti darbą su Bitrix žurnalais ir dalį darbų turėsite atlikti rankiniu būdu (įkelti ataskaitą ir įkelti ją į savo SIEM). Bet jei prisiminsime, kad dar palyginti neseniai tokios galimybės nebuvo, tai yra didelė pažanga. Tuo pat metu norėčiau pastebėti, kad daugelis užsienio debesų paslaugų teikėjų siūlo panašias funkcijas „pradedantiesiems“ - arba pažiūrėkite į žurnalus akimis per valdymo skydelį, arba įkelkite duomenis sau (tačiau dauguma duomenų įkelia . csv formatu, o ne Excel).

Neatsižvelgdami į parinktį neprisijungti, debesų paslaugų teikėjai paprastai siūlo tris saugumo įvykių stebėjimo parinktis – prietaisų skydelius, duomenų įkėlimą ir API prieigą. Pirmoji tarsi išsprendžia daugybę problemų už jus, tačiau tai nėra visiškai tiesa – jei turite kelis žurnalus, turite perjungti juos rodančius ekranus, prarandant bendrą vaizdą. Be to, mažai tikėtina, kad debesies paslaugų teikėjas suteiks jums galimybę susieti saugos įvykius ir apskritai juos analizuoti saugumo požiūriu (dažniausiai jūs susiduriate su neapdorotais duomenimis, kuriuos turite suprasti patys). Yra išimčių ir apie jas kalbėsime toliau. Galiausiai verta paklausti, kokius įvykius įrašo jūsų debesų paslaugų teikėjas, kokiu formatu ir kaip jie atitinka jūsų informacijos saugumo stebėjimo procesą? Pavyzdžiui, vartotojų ir svečių identifikavimas ir autentifikavimas. Ta pati Bitrix leidžia, remiantis šiais įvykiais, įrašyti įvykio datą ir laiką, vartotojo ar svečio vardą (jei turite „Web Analytics“ modulį), pasiekiamą objektą ir kitus svetainei būdingus elementus. . Tačiau įmonės informacijos saugos tarnyboms gali prireikti informacijos apie tai, ar vartotojas pasiekė debesį iš patikimo įrenginio (pavyzdžiui, įmonės tinkle šią užduotį įgyvendina Cisco ISE). O kaip su tokia paprasta užduotimi kaip geo-IP funkcija, kuri padės nustatyti, ar debesies paslaugos vartotojo abonementas nebuvo pavogtas? Ir net jei debesies paslaugų teikėjas jums tai suteikia, to nepakanka. Tas pats „Cisco CloudLock“ ne tik analizuoja geografinę vietą, bet tam naudoja mašininį mokymąsi ir analizuoja kiekvieno vartotojo istorinius duomenis bei stebi įvairias identifikavimo ir autentifikavimo bandymų anomalijas. Tik MS Azure turi panašias funkcijas (jei turite atitinkamą prenumeratą).

Yra dar vienas sunkumas – kadangi daugeliui debesų paslaugų teikėjų informacijos saugumo stebėjimas yra nauja tema, su kuria jie tik pradeda domėtis, jie nuolat kažką keičia savo sprendimuose. Šiandien jie turi vieną API versiją, rytoj – kitą, poryt – trečią. Tam taip pat reikia pasiruošti. Tas pats pasakytina ir apie funkcionalumą, kuris gali keistis, į ką būtina atsižvelgti kuriant informacijos saugumo stebėjimo sistemą. Pavyzdžiui, iš pradžių „Amazon“ turėjo atskiras debesies įvykių stebėjimo paslaugas – „AWS CloudTrail“ ir „AWS CloudWatch“. Tada atsirado atskira informacijos saugumo įvykių stebėjimo paslauga – AWS GuardDuty. Po kurio laiko „Amazon“ pristatė naują valdymo sistemą „Amazon Security Hub“, kuri apima duomenų, gautų iš „GuardDuty“, „Amazon Inspector“, „Amazon Macie“ ir kelių kitų, analizę. Kitas pavyzdys yra Azure žurnalo integravimo įrankis su SIEM – AzLog. Jį aktyviai naudojo daugelis SIEM pardavėjų, kol 2018 m. „Microsoft“ paskelbė nutraukianti jos kūrimą ir palaikymą, o tai susidūrė su problema daugeliui klientų, naudojusių šį įrankį (apie tai, kaip ji buvo išspręsta, kalbėsime vėliau).

Todėl atidžiai stebėkite visas stebėjimo funkcijas, kurias jums siūlo debesijos paslaugų teikėjas. Arba pasikliaukite išoriniais sprendimų teikėjais, kurie veiks kaip tarpininkai tarp jūsų SOC ir debesies, kurią norite stebėti. Taip, tai kainuos brangiau (nors ir ne visada), bet visą atsakomybę perkelsite ant kažkieno pečių. Ar ne visą?.. Prisiminkime bendro saugumo sampratą ir supraskime, kad nieko pakeisti negalime – turėsime savarankiškai suprasti, kaip skirtingi debesų tiekėjai užtikrina Jūsų duomenų, programų, virtualių mašinų ir kitų išteklių informacijos saugumo stebėjimą priglobtas debesyje. Ir pradėsime nuo to, ką šioje dalyje siūlo „Amazon“.

Pavyzdys: informacijos saugos stebėjimas IaaS, pagrįstas AWS

Taip, taip, aš suprantu, kad „Amazon“ nėra geriausias pavyzdys dėl to, kad tai yra amerikietiška paslauga ir ji gali būti blokuojama kaip dalis kovos su ekstremizmu ir Rusijoje uždraustos informacijos sklaida. Tačiau šioje publikacijoje tiesiog noriu parodyti, kuo skirtingos debesų platformos skiriasi savo informacijos saugumo stebėjimo galimybėmis ir į ką reikėtų atkreipti dėmesį perkeliant pagrindinius procesus į debesis saugumo požiūriu. Na, o jei kai kurie Rusijos debesų sprendimų kūrėjai išmoks ką nors naudingo sau, tai bus puiku.

Pirmiausia reikia pasakyti, kad „Amazon“ nėra neįveikiama tvirtovė. Su jo klientais nuolat nutinka įvairių incidentų. Pavyzdžiui, iš „Deep Root Analytics“ buvo pavogti 198 milijonų rinkėjų vardai, adresai, gimimo datos ir telefono numeriai. Izraelio bendrovė „Nice Systems“ pavogė 14 milijonų „Verizon“ abonentų įrašų. Tačiau AWS integruotos galimybės leidžia aptikti daugybę incidentų. Pavyzdžiui:

• poveikis infrastruktūrai (DDoS)
• mazgo pažeidimas (komandos įpurškimas)
• paskyros pažeidimas ir neteisėta prieiga
• neteisinga konfigūracija ir pažeidžiamumas
• nesaugios sąsajos ir API.

Šis neatitikimas atsiranda dėl to, kad, kaip išsiaiškinome aukščiau, už kliento duomenų saugumą atsakingas pats klientas. O jei jis nepasivargino įjungti apsauginių mechanizmų ir neįjungė stebėjimo priemonių, tai apie įvykį sužinos tik iš žiniasklaidos arba iš savo klientų.

Norėdami nustatyti incidentus, galite naudoti daugybę skirtingų stebėjimo paslaugų, kurias sukūrė „Amazon“ (nors jas dažnai papildo išoriniai įrankiai, pvz., osquery). Taigi AWS yra stebimi visi vartotojo veiksmai, neatsižvelgiant į tai, kaip jie atliekami – per valdymo konsolę, komandinę eilutę, SDK ar kitas AWS paslaugas. Visi kiekvienos AWS paskyros veiklos įrašai (įskaitant vartotojo vardą, veiksmą, paslaugą, veiklos parametrus ir rezultatą) ir API naudojimą pasiekiami per AWS CloudTrail. Šiuos įvykius (pvz., AWS IAM konsolės prisijungimus) galite peržiūrėti naudodami „CloudTrail“ pultą, analizuoti juos naudodami „Amazon Athena“ arba „perduoti“ išoriniams sprendimams, pvz., „Splunk“, „AlienVault“ ir kt. Patys AWS CloudTrail žurnalai dedami į jūsų AWS S3 kibirą.

Dvi kitos AWS paslaugos suteikia daugybę kitų svarbių stebėjimo galimybių. Pirma, „Amazon CloudWatch“ yra AWS išteklių ir programų stebėjimo paslauga, kuri, be kita ko, leidžia nustatyti įvairias debesies anomalijas. Visos įmontuotos AWS paslaugos, tokios kaip „Amazon Elastic Compute Cloud“ (serveriai), „Amazon Relational Database Service“ (duomenų bazės), „Amazon Elastic MapReduce“ (duomenų analizė) ir 30 kitų „Amazon“ paslaugų, naudoja „Amazon CloudWatch“ savo žurnalams saugoti. Kūrėjai gali naudoti atvirą API iš „Amazon CloudWatch“, kad pridėtų žurnalo stebėjimo funkciją prie pasirinktinių programų ir paslaugų, leidžiančių išplėsti įvykių analizės apimtį saugos kontekste.

Antra, „VPC Flow Logs“ paslauga leidžia analizuoti jūsų AWS serverių (išoriškai arba viduje) siunčiamą arba gautą tinklo srautą, taip pat tarp mikro paslaugų. Kai kuris nors iš jūsų AWS VPC išteklių sąveikauja su tinklu, VPC srauto žurnalai įrašo informaciją apie tinklo srautą, įskaitant šaltinio ir paskirties tinklo sąsają, taip pat IP adresus, prievadus, protokolą, baitų skaičių ir jūsų paketų skaičių. pamačiau. Tie, kurie yra patyrę su vietinio tinklo saugumu, atpažins, kad tai panašu į gijas „NetFlow“, kurią gali sukurti komutatoriai, maršrutizatoriai ir įmonės lygio ugniasienės. Šie žurnalai yra svarbūs informacijos saugumo stebėjimo tikslais, nes, skirtingai nei įvykiai apie vartotojų ir programų veiksmus, jie taip pat leidžia nepraleisti tinklo sąveikos AWS virtualioje privačioje debesies aplinkoje.

Apibendrinant, šios trys AWS paslaugos – „AWS CloudTrail“, „Amazon CloudWatch“ ir „VPC Flow Logs“ – kartu suteikia gana galingą įžvalgą apie jūsų paskyros naudojimą, vartotojų elgesį, infrastruktūros valdymą, taikomųjų programų ir paslaugų veiklą bei tinklo veiklą. Pavyzdžiui, jie gali būti naudojami aptikti šias anomalijas:

• Bandymai nuskaityti svetainę, ieškoti užpakalinių durų, ieškoti pažeidžiamumų per „404 klaidų“ serijas.
• Įpurškimo atakos (pvz., SQL įpurškimas) per „500 klaidų“ serijas.
• Žinomi atakos įrankiai yra sqlmap, nikto, w3af, nmap ir kt. analizuodami vartotojo agento lauką.

„Amazon Web Services“ taip pat sukūrė kitas kibernetinio saugumo paslaugas, kurios leidžia išspręsti daugybę kitų problemų. Pavyzdžiui, AWS turi integruotą strategijų ir konfigūracijų audito paslaugą – AWS Config. Ši paslauga užtikrina nuolatinį jūsų AWS išteklių ir jų konfigūracijų auditą. Paimkime paprastą pavyzdį: tarkime, kad norite įsitikinti, kad vartotojų slaptažodžiai yra išjungti visuose jūsų serveriuose ir kad prieiga galima tik remiantis sertifikatais. AWS Config leidžia lengvai tai patikrinti visuose jūsų serveriuose. Yra ir kitų strategijų, kurios gali būti taikomos jūsų debesies serveriams: „Nė vienas serveris negali naudoti 22 prievado“, „Tik administratoriai gali keisti ugniasienės taisykles“ arba „Tik vartotojas Ivashko gali kurti naujas vartotojo paskyras, o jis gali tai padaryti tik antradieniais. “ 2016 metų vasarą AWS Config paslauga buvo išplėsta siekiant automatizuoti sukurtų strategijų pažeidimų aptikimą. AWS konfigūravimo taisyklės iš esmės yra nuolatinės jūsų naudojamų „Amazon“ paslaugų konfigūracijos užklausos, kurios generuoja įvykius, jei pažeidžiamos atitinkamos strategijos. Pavyzdžiui, užuot periodiškai vykdžiusias AWS konfigūravimo užklausas, kad patikrintų, ar visi virtualiame serveryje esantys diskai yra užšifruoti, AWS konfigūravimo taisyklės gali būti naudojamos nuolat tikrinti serverio diskus, siekiant užtikrinti, kad ši sąlyga būtų įvykdyta. Ir, svarbiausia, šio leidinio kontekste bet kokie pažeidimai generuoja įvykius, kuriuos gali išanalizuoti jūsų informacijos saugos tarnyba.

AWS taip pat turi atitikmenį tradiciniams įmonės informacijos saugos sprendimams, kurie taip pat generuoja saugos įvykius, kuriuos galite ir turėtumėte analizuoti:

• Įsibrovimo aptikimas – AWS GuardDuty
• Informacijos nutekėjimo valdymas – AWS Macie
• EDR (nors apie galinius taškus debesyje kalbama šiek tiek keistai) - AWS Cloudwatch + atvirojo kodo osquery arba GRR sprendimai
• Netflow analizė – AWS Cloudwatch + AWS VPC Flow
• DNS analizė – AWS Cloudwatch + AWS Route53
• AD – AWS katalogų paslauga
• Sąskaitos valdymas – AWS IAM
• SSO – AWS SSO
• saugumo analizė – AWS inspektorius
• konfigūracijos valdymas – AWS Config
• WAF – AWS WAF.

Detaliai neaprašysiu visų „Amazon“ paslaugų, kurios gali būti naudingos informacijos saugumo kontekste. Svarbiausia yra suprasti, kad visi jie gali generuoti įvykius, kuriuos galime ir turėtume analizuoti informacijos saugumo kontekste, naudodamiesi šiuo tikslu tiek pačios „Amazon“ integruotomis galimybėmis, tiek išoriniais sprendimais, pavyzdžiui, SIEM, kurie gali nuneškite saugos įvykius į savo stebėjimo centrą ir ten analizuokite juos kartu su įvykiais iš kitų debesies paslaugų arba iš vidinės infrastruktūros, perimetro ar mobiliųjų įrenginių.

Bet kuriuo atveju viskas prasideda nuo duomenų šaltinių, kurie teikia jums informacijos saugumo įvykius. Šie šaltiniai apima, bet jais neapsiribojant:

• „CloudTrail“ – API naudojimas ir naudotojo veiksmai
• Patikimas patarėjas – saugumo patikrinimas pagal geriausią praktiką
• Config – paskyrų ir paslaugų nustatymų inventorius ir konfigūracija
• VPC Flow Logs – prisijungimai prie virtualių sąsajų
• IAM – identifikavimo ir autentifikavimo paslauga
• ELB prieigos žurnalai – apkrovos balansavimo priemonė
• Inspektorius – programos pažeidžiamumas
• S3 – failų saugykla
• „CloudWatch“ – programų veikla
• SNS yra pranešimų paslauga.

„Amazon“, siūlydama tokį įvairių įvykių šaltinių ir įrankių jiems generuoti, yra labai ribota savo galimybėmis analizuoti surinktus duomenis informacijos saugumo kontekste. Turėsite savarankiškai išstudijuoti turimus žurnalus, ieškant juose atitinkamų kompromiso rodiklių. „AWS Security Hub“, kurį neseniai paleido „Amazon“, siekia išspręsti šią problemą tapdamas AWS debesies SIEM. Tačiau kol kas jis tik savo kelionės pradžioje ir yra ribojamas tiek šaltinių, su kuriais jis dirba, tiek kitų apribojimų, nustatytų pačios Amazon architektūros ir prenumeratos.

Pavyzdys: informacijos saugos stebėjimas IaaS, pagrįstas Azure

Nenoriu veltis į ilgas diskusijas, kuris iš trijų debesų tiekėjų (Amazon, Microsoft ar Google) yra geresnis (juolab, kad kiekvienas iš jų vis dar turi savo specifinę specifiką ir yra tinkamas savo problemoms spręsti); Sutelkime dėmesį į informacijos saugumo stebėjimo galimybes, kurias suteikia šie grotuvai. Reikia pripažinti, kad „Amazon AWS“ šiame segmente buvo viena pirmųjų, todėl pasiekusi toliausiai pagal savo informacijos saugumo funkcijas (nors daugelis pripažįsta, kad jomis naudotis sunku). Tačiau tai nereiškia, kad ignoruosime „Microsoft“ ir „Google“ mums teikiamas galimybes.

„Microsoft“ produktai visada išsiskyrė „atvirumu“, o „Azure“ situacija yra panaši. Pavyzdžiui, jei AWS ir GCP visada remiasi sąvoka „kas neleidžiama, yra draudžiama“, „Azure“ turi visiškai priešingą požiūrį. Pavyzdžiui, kuriant virtualų tinklą debesyje ir virtualią mašiną jame, visi prievadai ir protokolai yra atidaryti ir leidžiami pagal numatytuosius nustatymus. Todėl turėsite skirti šiek tiek daugiau pastangų pradiniam prieigos kontrolės sistemos nustatymui debesyje iš Microsoft. Tai taip pat kelia griežtesnius reikalavimus, susijusius su veiklos stebėjimu Azure debesyje.

AWS ypatumas yra susijęs su tuo, kad kai stebite savo virtualius išteklius, jei jie yra skirtinguose regionuose, jums kyla sunkumų derinant visus įvykius ir jų vieningą analizę, o tai pašalinti reikia pasitelkti įvairius triukus, pvz. Sukurkite savo AWS Lambda kodą, kuris perkels įvykius tarp regionų. „Azure“ neturi šios problemos – jo veiklos žurnalo mechanizmas be apribojimų seka visą veiklą visoje organizacijoje. Tas pats pasakytina ir apie AWS Security Hub, kurį neseniai sukūrė „Amazon“, siekdama sujungti daugelį saugumo funkcijų viename saugumo centre, bet tik jo regione, tačiau tai nėra aktualu Rusijai. „Azure“ turi savo saugos centrą, kuris nėra saistomas regioninių apribojimų ir suteikia prieigą prie visų debesų platformos saugos funkcijų. Be to, skirtingoms vietinėms komandoms jis gali suteikti savo apsauginių galimybių rinkinį, įskaitant jų valdomus saugos įvykius. „AWS Security Hub“ vis dar siekia tapti panašiu į „Azure Security Center“. Tačiau verta pridėti musę – galite išspausti iš Azure daug to, kas anksčiau buvo aprašyta AWS, tačiau tai patogiausia padaryti tik „Azure AD“, „Azure Monitor“ ir „Azure Security Center“. Visi kiti „Azure“ saugos mechanizmai, įskaitant saugos įvykių analizę, dar nėra valdomi pačiu patogiausiu būdu. Problemą iš dalies išsprendžia API, kuri persmelkia visas Microsoft Azure paslaugas, tačiau tam reikės papildomų pastangų integruoti debesį su SOC ir kvalifikuotų specialistų buvimo (iš tikrųjų, kaip ir su bet kuria kita SIEM, kuri veikia su debesies API). Kai kurie SIEM, apie kuriuos bus kalbama vėliau, jau palaiko Azure ir gali automatizuoti jo stebėjimo užduotį, tačiau tai turi ir savų sunkumų – ne visi gali surinkti visus Azure turimus žurnalus.

Įvykių rinkimas ir stebėjimas „Azure“ teikiamas naudojant „Azure Monitor“ paslaugą, kuri yra pagrindinis įrankis duomenims rinkti, saugoti ir analizuoti „Microsoft“ debesyje ir jo ištekliais – „Git“ saugyklose, konteineriuose, virtualiose mašinose, programose ir kt. Visi „Azure Monitor“ surinkti duomenys yra suskirstyti į dvi kategorijas – metriką, renkamą realiuoju laiku ir apibūdinančią pagrindinius „Azure“ debesies našumo rodiklius, ir žurnalus, kuriuose yra duomenys, suskirstyti į įrašus, apibūdinančius tam tikrus „Azure“ išteklių ir paslaugų veiklos aspektus. Be to, naudodama Data Collector API, „Azure Monitor“ paslauga gali rinkti duomenis iš bet kurio REST šaltinio, kad sukurtų savo stebėjimo scenarijus.

Štai keli saugos įvykių šaltiniai, kuriuos jums siūlo „Azure“ ir kuriuos galite pasiekti naudodami „Azure Portal“, CLI, „PowerShell“ arba REST API (o kai kuriuos tik per „Azure Monitor“ / „Insight“ API):

• Veiklos žurnalai – šis žurnalas atsako į klasikinius klausimus „kas“, „kas“ ir „kada“ dėl bet kokios rašymo operacijos (PUT, POST, DELETE) debesies ištekliuose. Įvykiai, susiję su skaitymo prieiga (GET), neįtraukti į šį žurnalą, kaip ir daugelis kitų.
• Diagnostikos žurnalai – juose yra duomenys apie operacijas su konkrečiu ištekliu, įtrauktu į prenumeratą.
• Azure AD ataskaitos – apima ir naudotojo veiklą, ir sistemos veiklą, susijusią su grupės ir vartotojų valdymu.
• „Windows“ įvykių žurnalas ir „Linux Syslog“ – yra įvykių iš virtualių mašinų, priglobtų debesyje.
• Metrika – apima telemetriją apie debesies paslaugų ir išteklių našumą ir sveikatos būklę. Matuojamas kas minutę ir saugomas. per 30 dienų.
• Tinklo saugos grupės srauto žurnalai – yra duomenys apie tinklo saugos įvykius, surinktus naudojant Network Watcher paslaugą ir išteklių stebėjimą tinklo lygiu.
• Sandėliavimo žurnalai – juose yra įvykių, susijusių su prieiga prie saugyklų.

Stebėti galite naudoti išorinius SIEM arba integruotą Azure Monitor ir jo plėtinius. Apie informacijos saugumo įvykių valdymo sistemas kalbėsime vėliau, bet dabar pažiūrėkime, ką pati Azure mums siūlo duomenų analizei saugumo kontekste. Pagrindinis „Azure Monitor“ visų su sauga susijusių dalykų ekranas yra „Log Analytics“ saugos ir audito informacijos suvestinė (nemokama versija palaiko ribotą įvykių saugyklos kiekį tik vieną savaitę). Ši prietaisų skydelis suskirstytas į 5 pagrindines sritis, kuriose vizualizuojama suvestinė statistika apie tai, kas vyksta jūsų naudojamoje debesies aplinkoje:

• Saugumo domenai – pagrindiniai kiekybiniai rodikliai, susiję su informacijos saugumu – incidentų skaičius, pažeistų mazgų, nepataisytų mazgų, tinklo saugumo įvykių ir kt.
• Svarbios problemos – rodo aktyvių informacijos saugos problemų skaičių ir svarbą
• Aptikimai – rodo prieš jus naudojamų atakų modelius
• Grėsmių žvalgyba – rodo geografinę informaciją apie jus puolančius išorinius mazgus
• Įprastos saugos užklausos – įprastos užklausos, kurios padės geriau stebėti informacijos saugumą.

„Azure Monitor“ plėtiniai apima „Azure Key Vault“ (kriptografinių raktų apsauga debesyje), „Malware Assessment“ (apsaugos nuo kenkėjiško kodo virtualiose mašinose analizė), „Azure Application Gateway Analytics“ (be kita ko, debesies užkardos žurnalų analizė) ir kt. . Šie įrankiai, praturtinti tam tikromis įvykių apdorojimo taisyklėmis, leidžia vizualizuoti įvairius debesijos paslaugų veiklos aspektus, įskaitant saugumą, ir nustatyti tam tikrus nukrypimus nuo veikimo. Tačiau, kaip dažnai nutinka, bet kokiam papildomam funkcionalumui reikalinga atitinkama mokama prenumerata, kuri pareikalaus iš jūsų atitinkamų finansinių investicijų, kurias turite planuoti iš anksto.

„Azure“ turi daugybę integruotų grėsmių stebėjimo galimybių, kurios yra integruotos į „Azure AD“, „Azure Monitor“ ir „Azure Security Center“. Tarp jų, pavyzdžiui, virtualių mašinų sąveikos su žinomais kenkėjiškais IP aptikimas (dėl integracijos su „Microsoft Threat Intelligence“ paslaugomis), kenkėjiškų programų aptikimas debesų infrastruktūroje gavus pavojaus signalus iš debesyje priglobtų virtualių mašinų, slaptažodis. spėlioti atakas “ prieš virtualias mašinas, vartotojų identifikavimo sistemos konfigūracijos spragas, prisijungimą prie sistemos iš anonimizatorių ar užkrėstų mazgų, paskyros nutekėjimą, prisijungimą prie sistemos iš neįprastų vietų ir kt. „Azure“ šiandien yra vienas iš nedaugelio debesies paslaugų teikėjų, siūlančių integruotas grėsmių žvalgybos galimybes, kad praturtintų surinktus informacijos saugos įvykius.

Kaip minėta aukščiau, saugos funkcionalumas ir dėl to jo generuojami saugos įvykiai nėra vienodai prieinami visiems vartotojams, tačiau reikalinga tam tikra prenumerata, apimanti jums reikalingą funkcionalumą, kuri generuoja atitinkamus įvykius informacijos saugumo stebėjimui. Pavyzdžiui, kai kurios ankstesnėje pastraipoje aprašytos paskyros anomalijų stebėjimo funkcijos pasiekiamos tik „Azure AD“ paslaugos P2 aukščiausios kokybės licencijoje. Be jo jūs, kaip ir AWS atveju, surinktus saugos įvykius turėsite analizuoti „rankiniu būdu“. Be to, atsižvelgiant į Azure AD licencijos tipą, ne visi įvykiai bus prieinami analizei.

„Azure“ portale galite tvarkyti jus dominančių žurnalų paieškos užklausas ir nustatyti prietaisų skydelius, kad būtų galima vizualizuoti pagrindinius informacijos saugos rodiklius. Be to, ten galite pasirinkti „Azure Monitor“ plėtinius, kurie leidžia išplėsti „Azure Monitor“ žurnalų funkcionalumą ir gauti gilesnę įvykių analizę saugumo požiūriu.

Jei jums reikia ne tik galimybės dirbti su žurnalais, bet ir visapusiško „Azure“ debesies platformos saugos centro, įskaitant informacijos saugos politikos valdymą, tuomet galite kalbėti apie poreikį dirbti su „Azure Security Center“, kurio dauguma naudingų funkcijų. yra prieinami už tam tikrus pinigus, pavyzdžiui, grėsmių aptikimas, stebėjimas už Azure ribų, atitikties įvertinimas ir kt. (nemokamoje versijoje turite prieigą tik prie saugumo įvertinimo ir rekomendacijų, kaip pašalinti nustatytas problemas). Jis sujungia visas saugumo problemas vienoje vietoje. Tiesą sakant, galime kalbėti apie aukštesnį informacijos saugos lygį, nei jums suteikia „Azure Monitor“, nes šiuo atveju debesų gamykloje surinkti duomenys yra praturtinami naudojant daugybę šaltinių, tokių kaip „Azure“, „Office 365“, „Microsoft CRM online“, „Microsoft Dynamics AX“. , outlook .com, MSN.com, „Microsoft Digital Crimes Unit“ (DCU) ir „Microsoft Security Response Center“ (MSRC), ant kurių dedami įvairūs sudėtingi mašininio mokymosi ir elgesio analizės algoritmai, kurie galiausiai turėtų pagerinti grėsmių aptikimo ir reagavimo į jas efektyvumą. .

Azure taip pat turi savo SIEM – jis pasirodė 2019 m. pradžioje. Tai „Azure Sentinel“, kuri remiasi duomenimis iš „Azure Monitor“ ir gali būti integruota su. išorinių saugos sprendimų (pavyzdžiui, NGFW ar WAF), kurių sąrašas nuolat auga. Be to, integravę „Microsoft Graph Security“ API, turite galimybę prijungti savo Threat Intelligence informacijos santraukas prie „Sentinel“, o tai praturtina galimybes analizuoti incidentus jūsų Azure debesyje. Galima teigti, kad „Azure Sentinel“ yra pirmasis „vietinis“ SIEM, pasirodęs iš debesų tiekėjų (to paties „Splunk“ arba „ELK“, kurie gali būti talpinami debesyje, pavyzdžiui, AWS, vis dar nesukūrė tradiciniai debesų paslaugų teikėjai). „Azure Sentinel“ ir saugos centras galėtų būti vadinami „Azure“ debesies SOC ir gali būti apriboti (su tam tikromis išlygomis), jei nebeturėtumėte jokios infrastruktūros ir visus skaičiavimo išteklius perkeltumėte į debesį ir tai būtų „Microsoft“ debesis Azure.

Tačiau kadangi integruotų „Azure“ galimybių (net jei užsiprenumeravote „Sentinel“) dažnai nepakanka informacijos saugumui stebėti ir šio proceso integravimui su kitais saugos įvykių šaltiniais (ir debesyje, ir vidiniais), yra surinktus duomenis reikia eksportuoti į išorines sistemas, kurios gali apimti SIEM. Tai atliekama tiek naudojant API, tiek naudojant specialius plėtinius, kurie šiuo metu oficialiai prieinami tik šiems SIEM – Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ir ELK. Dar visai neseniai tokių SIEM buvo daugiau, tačiau nuo 1 m. birželio 2019 d. „Microsoft“ nustojo palaikyti „Azure Log Integration Tool“ (AzLog), kuris „Azure“ egzistavimo aušroje ir nesant įprasto darbo su žurnalais standartizacijos („Azure“). Monitorius dar net neegzistavo) palengvino išorinio SIEM integravimą su „Microsoft“ debesimi. Dabar situacija pasikeitė ir „Microsoft“ rekomenduoja „Azure Event Hub“ platformą kaip pagrindinį kitų SIEM integravimo įrankį. Daugelis jau įdiegė tokią integraciją, tačiau būkite atsargūs – jie gali užfiksuoti ne visus „Azure“ žurnalus, o tik kai kuriuos (ieškokite savo SIEM dokumentacijoje).

Baigdamas trumpą ekskursiją po Azure, norėčiau pateikti bendrą rekomendaciją dėl šios debesies paslaugos – prieš ką nors sakydami apie informacijos saugos stebėjimo funkcijas Azure, turėtumėte jas labai atidžiai sukonfigūruoti ir patikrinti, ar jos veikia taip, kaip parašyta dokumentacijoje ir kaip jums pasakė konsultantai „Microsoft“ (ir jie gali turėti skirtingą požiūrį į „Azure“ funkcijų funkcionalumą). Jei turite finansinių išteklių, galite iš „Azure“ išspausti daug naudingos informacijos, susijusios su informacijos saugos stebėjimu. Jei jūsų ištekliai riboti, tuomet, kaip ir AWS atveju, turėsite pasikliauti tik savo jėgomis ir neapdorotais duomenimis, kuriuos jums teikia „Azure Monitor“. Ir atminkite, kad daugelis stebėjimo funkcijų kainuoja, todėl geriau iš anksto susipažinti su kainų politika. Pavyzdžiui, nemokamai galite saugoti 31 dienos duomenis iki ne daugiau kaip 5 GB vienam klientui – viršijus šias vertes turėsite sumokėti papildomų pinigų (maždaug 2 USD už kiekvieno papildomo GB saugojimą iš kliento ir 0,1 USD už saugoti 1 GB kiekvieną papildomą mėnesį). Darbui su taikomųjų programų telemetrija ir metrika taip pat gali prireikti papildomų lėšų, taip pat dirbant su įspėjimais ir pranešimais (tam tikras limitas yra nemokamas, kurio gali nepakakti jūsų poreikiams).

Pavyzdys: informacijos saugos stebėjimas IaaS, pagrįstas Google Cloud Platform

„Google Cloud Platform“ atrodo kaip jaunas, palyginti su AWS ir Azure, tačiau tai iš dalies gerai. Skirtingai nuo AWS, kuri palaipsniui didino savo galimybes, įskaitant saugumo, ir turėjo problemų dėl centralizacijos; GCP, kaip ir Azure, yra daug geriau valdomas centralizuotai, o tai sumažina klaidų skaičių ir diegimo laiką visoje įmonėje. Saugumo požiūriu GCP, kaip bebūtų keista, yra tarp AWS ir Azure. Jis taip pat turi vieną visos organizacijos renginio registraciją, tačiau ji yra neišsami. Kai kurios funkcijos vis dar veikia beta versijos režimu, tačiau palaipsniui šis trūkumas turėtų būti pašalintas ir GCP taps brandesne informacijos saugumo stebėjimo platforma.

Pagrindinis GCP įvykių registravimo įrankis yra „Stackdriver Logging“ (panašus į „Azure Monitor“), kuris leidžia rinkti įvykius visoje debesų infrastruktūroje (taip pat ir iš AWS). GCP saugos požiūriu kiekviena organizacija, projektas ar aplankas turi keturis žurnalus:

• Administratoriaus veikla – apima visus su administracine prieiga susijusius įvykius, pavyzdžiui, virtualios mašinos kūrimą, prieigos teisių keitimą ir pan. Šis žurnalas visada rašomas, nepaisant jūsų noro, ir jo duomenys saugomi 400 dienų.
• Prieiga prie duomenų – apima visus įvykius, susijusius su debesies naudotojų darbu su duomenimis (kūrimas, keitimas, skaitymas ir kt.). Pagal numatytuosius nustatymus šis žurnalas nėra rašomas, nes jo tūris labai greitai išsipučia. Dėl šios priežasties jo tinkamumo laikas yra tik 30 dienų. Be to, šiame žurnale ne viskas parašyta. Pavyzdžiui, įvykiai, susiję su ištekliais, kurie yra viešai prieinami visiems vartotojams arba pasiekiami neprisijungus prie GSP, į jį neįrašomi.
• Sistemos įvykis – apima sistemos įvykius, nesusijusius su vartotojais arba administratoriaus, kuris keičia debesies išteklių konfigūraciją, veiksmais. Jis visada rašomas ir saugomas 400 dienų.
• Prieigos skaidrumas yra unikalus žurnalo pavyzdys, kuriame fiksuojami visi „Google“ darbuotojų veiksmai (bet dar ne visoms GSP paslaugoms), kurie, vykdydami savo pareigas, pasiekia jūsų infrastruktūrą. Šis žurnalas saugomas 400 dienų ir pasiekiamas ne kiekvienam GSP klientui, bet tik tuo atveju, jei tenkinamos kelios sąlygos (auksinio arba platininio lygio palaikymas arba 4 tam tikro tipo vaidmenys, kaip įmonės palaikymo dalis). Panaši funkcija taip pat galima, pavyzdžiui, „Office 365“ – „Lockbox“.

Žurnalo pavyzdys: Prieigos skaidrumas

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Prieiga prie šių žurnalų galima keliais būdais (panašiai, kaip buvo aptarta anksčiau Azure ir AWS) – naudojant žurnalų peržiūros programos sąsają, API, „Google Cloud SDK“ arba projekto, kurio veikla, puslapį. domisi renginiais. Tokiu pat būdu jie gali būti eksportuojami į išorinius sprendimus papildomai analizei. Pastaroji atliekama eksportuojant žurnalus į „BigQuery“ arba „Cloud Pub/Sub“ saugyklą.

Be „Stackdriver Logging“, GCP platforma taip pat siūlo „Stackdriver Monitoring“ funkciją, kuri leidžia stebėti pagrindines debesijos paslaugų ir programų metrikas (našumą, MTBF, bendrą būklę ir kt.). Apdoroti ir vizualizuoti duomenys gali padėti lengviau rasti debesų infrastruktūros problemas, įskaitant saugumo kontekste. Tačiau reikia pažymėti, kad ši funkcija nebus labai turtinga informacijos saugumo kontekste, nes šiandien GCP neturi to paties AWS GuardDuty analogo ir negali nustatyti blogų tarp visų registruotų įvykių (Google sukūrė įvykių grėsmių aptikimą, tačiau jis vis dar kuriamas beta versijoje ir dar per anksti kalbėti apie jo naudingumą). „Stackdriver Monitoring“ galėtų būti naudojama kaip anomalijų aptikimo sistema, kuri vėliau būtų tiriama siekiant nustatyti jų atsiradimo priežastis. Tačiau atsižvelgiant į tai, kad rinkoje trūksta kvalifikuotų GCP informacijos saugumo srityje darbuotojų, ši užduotis šiuo metu atrodo sudėtinga.

Taip pat verta pateikti kai kurių informacijos saugos modulių, kurie gali būti naudojami jūsų GCP debesyje ir kurie yra panašūs į tai, ką siūlo AWS, sąrašą:

• „Cloud Security Command Center“ yra „AWS Security Hub“ ir „Azure Security Center“ analogas.
• Debesis DLP – automatinis debesyje esančių duomenų aptikimas ir redagavimas (pvz., maskavimas), naudojant daugiau nei 90 iš anksto nustatytų klasifikavimo strategijų.
• „Cloud Scanner“ yra žinomų „App Engine“, „Compute Engine“ ir „Google Kubernetes“ spragų (XSS, „Flash Injection“, nepataisytų bibliotekų ir kt.) skaitytuvas.
• Cloud IAM – valdykite prieigą prie visų GCP išteklių.
• Cloud Identity – tvarkykite GCP naudotojų, įrenginių ir programų paskyras iš vienos konsolės.
• Cloud HSM – kriptografinių raktų apsauga.
• Cloud Key Management Service – kriptografinių raktų valdymas GCP.
• VPC paslaugų valdymas – sukurkite saugų perimetrą aplink savo GCP išteklius, kad apsaugotumėte juos nuo nutekėjimo.
• Titan saugos raktas – apsauga nuo sukčiavimo.

Daugelis šių modulių generuoja saugos įvykius, kurie gali būti siunčiami į „BigQuery“ saugyklą analizei arba eksportuojami į kitas sistemas, įskaitant SIEM. Kaip minėta aukščiau, GCP yra aktyviai besivystanti platforma, o „Google“ dabar kuria daug naujų informacijos saugos modulių savo platformai. Tarp jų yra įvykių grėsmių aptikimas (dabar pasiekiamas beta versijoje), kuris nuskaito „Stackdriver“ žurnalus, ieškodamas neteisėtos veiklos pėdsakų (panašiai kaip „GuardDuty“ AWS), arba Policy Intelligence (pasiekiama alfa versijoje), kuri leis kurti išmaniąsias strategijas prieigą prie GSP išteklių.

Trumpai apžvelgiau integruotas stebėjimo galimybes populiariose debesų platformose. Bet ar turite specialistų, galinčių dirbti su „neapdorotais“ IaaS teikėjo žurnalais (ne visi yra pasirengę įsigyti pažangias AWS ar Azure ar Google galimybes)? Be to, daugelis žino posakį „pasitikėkite, bet patikrinkite“, kuris saugumo srityje yra teisingesnis nei bet kada anksčiau. Kiek pasitikite integruotomis debesų paslaugų teikėjo galimybėmis, kurios siunčia jums informacijos saugos įvykius? Kiek jie apskritai skiria dėmesio informacijos saugumui?

Kartais verta pažvelgti į perdangos debesų infrastruktūros stebėjimo sprendimus, kurie gali papildyti integruotą debesų apsaugą, o kartais tokie sprendimai yra vienintelė galimybė gauti informacijos apie debesyje talpinamų duomenų ir programų saugumą. Be to, jie tiesiog patogesni, nes atlieka visas užduotis analizuoti reikalingus žurnalus, sugeneruotus skirtingų debesies paslaugų iš skirtingų debesies paslaugų teikėjų. Tokio perdangos sprendimo pavyzdys yra „Cisco Stealthwatch Cloud“, kuris yra orientuotas į vieną užduotį – informacijos saugos anomalijų stebėjimą debesų aplinkose, įskaitant ne tik „Amazon AWS“, „Microsoft Azure“ ir „Google Cloud Platform“, bet ir privačius debesis.

Pavyzdys: informacijos saugos stebėjimas naudojant Stealthwatch Cloud

AWS suteikia lanksčią skaičiavimo platformą, tačiau šis lankstumas leidžia įmonėms lengviau padaryti klaidas, dėl kurių kyla saugumo problemų. O bendras informacijos saugumo modelis tik prie to prisideda. Debesyje veikianti programinė įranga su nežinomais pažeidžiamumais (su žinomomis gali kovoti, pavyzdžiui, AWS Inspector arba GCP Cloud Scanner), silpnais slaptažodžiais, neteisinga konfigūracija, viešai neatskleista informacija ir pan. Ir visa tai atsispindi debesų išteklių elgsenoje, kurią gali stebėti „Cisco Stealthwatch Cloud“, kuri yra informacijos saugumo stebėjimo ir atakų aptikimo sistema. viešieji ir privatūs debesys.

Viena iš pagrindinių „Cisco Stealthwatch Cloud“ savybių yra galimybė modeliuoti objektus. Su juo galite sukurti kiekvieno debesies išteklių programinės įrangos modelį (ty beveik realiojo laiko modeliavimą) (nesvarbu, ar tai AWS, Azure, GCP ar kažkas kita). Tai gali būti serveriai ir vartotojai, taip pat išteklių tipai, būdingi jūsų debesies aplinkai, pvz., saugos grupės ir automatinio mastelio grupės. Šiuose modeliuose kaip įvestis naudojami struktūrizuoti duomenų srautai, kuriuos teikia debesies paslaugos. Pavyzdžiui, AWS tai būtų VPC srauto žurnalai, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ir AWS IAM. Objektų modeliavimas automatiškai atranda bet kurio jūsų išteklių vaidmenį ir elgesį (galite kalbėti apie visos debesies veiklos profiliavimą). Šie vaidmenys apima Android arba Apple mobilųjį įrenginį, Citrix PVS serverį, KPP serverį, pašto šliuzą, VoIP klientą, terminalo serverį, domeno valdiklį ir kt. Tada ji nuolat stebi jų elgesį, kad nustatytų, kada įvyksta rizikingas ar saugai pavojingas elgesys. Galite nustatyti slaptažodžio spėjimą, DDoS atakas, duomenų nutekėjimą, nelegalią nuotolinę prieigą, kenkėjiško kodo veiklą, pažeidžiamumo nuskaitymą ir kitas grėsmes. Pavyzdžiui, taip atrodo nuotolinės prieigos bandymo iš jūsų organizacijai netipinės šalies (Pietų Korėjos) į Kubernetes klasterį aptikimas naudojant SSH:

Štai kaip atrodo tariamas informacijos nutekėjimas iš Postgress duomenų bazės į šalį, su kuria anksčiau nesusidūrėme:

Galiausiai taip atrodo per daug nesėkmingų SSH bandymų iš Kinijos ir Indonezijos iš išorinio nuotolinio įrenginio:

Arba tarkime, kad serverio egzempliorius VPC pagal politiką niekada negali būti nuotolinio prisijungimo paskirties vieta. Darykime prielaidą, kad šiame kompiuteryje įvyko nuotolinis prisijungimas dėl klaidingo ugniasienės taisyklių politikos pakeitimo. Objektų modeliavimo funkcija aptiks ir praneš apie šią veiklą („Neįprasta nuotolinė prieiga“) beveik realiuoju laiku ir nukreips į konkretų AWS „CloudTrail“, „Azure Monitor“ arba „GCP Stackdriver Logging“ API iškvietimą (įskaitant vartotojo vardą, datą ir laiką, be kitos informacijos ). Dėl to buvo pakeista ITU taisyklė. Ir tada ši informacija gali būti siunčiama į SIEM analizei.

Panašios galimybės įdiegtos bet kuriai debesies aplinkai, kurią palaiko Cisco Stealthwatch Cloud:

Objektų modeliavimas yra unikali saugos automatizavimo forma, kuri gali atskleisti anksčiau nežinomą jūsų žmonių, procesų ar technologijų problemą. Pavyzdžiui, tai leidžia, be kita ko, aptikti saugumo problemas, tokias kaip:

• Ar kas nors aptiko užpakalinių durų mūsų naudojamoje programinėje įrangoje?
• Ar mūsų debesyje yra trečiosios šalies programinės įrangos ar įrenginio?
• Ar įgaliotasis vartotojas piktnaudžiauja privilegijomis?
• Ar įvyko konfigūracijos klaida, leidžianti pasiekti nuotolinę prieigą arba kitaip netyčia naudoti išteklius?
• Ar yra duomenų nutekėjimo iš mūsų serverių?
• Ar kažkas bandė prisijungti prie mūsų iš netipiškos geografinės vietos?
• Ar mūsų debesis užkrėstas kenkėjišku kodu?

Aptiktas informacijos saugos įvykis gali būti išsiųstas atitinkamo bilieto forma į „Slack“, „Cisco Spark“, „PagerDuty“ incidentų valdymo sistemą, taip pat į įvairias SIEM, įskaitant „Splunk“ arba „ELK“. Apibendrinant galima teigti, kad jei jūsų įmonė naudoja kelių debesų strategiją ir neapsiriboja vienu debesų paslaugų teikėju, aukščiau aprašytomis informacijos saugos stebėjimo galimybėmis, tada naudojant Cisco Stealthwatch Cloud yra geras pasirinkimas norint gauti vieningą stebėjimo rinkinį. pirmaujančių debesų žaidėjų – „Amazon“, „Microsoft“ ir „Google“ – galimybes. Įdomiausia tai, kad jei palyginsite „Stealthwatch Cloud“ kainas su pažangiomis informacijos saugumo stebėjimo licencijomis AWS, Azure ar GCP, gali pasirodyti, kad „Cisco“ sprendimas bus net pigesnis už „Amazon“, „Microsoft“ integruotas galimybes. ir Google sprendimai. Paradoksalu, bet tai tiesa. Ir kuo daugiau debesų ir jų galimybių naudosite, tuo akivaizdesnis bus konsoliduoto sprendimo pranašumas.

Be to, „Stealthwatch Cloud“ gali stebėti jūsų organizacijoje įdiegtus privačius debesis, pavyzdžiui, pagal „Kubernetes“ konteinerius arba stebėdama „Netflow“ srautus arba tinklo srautą, gautą per atspindėjimą tinklo įrangoje (net gaminama šalyje), AD duomenis ar DNS serverius ir pan. Visi šie duomenys bus papildyti Threat Intelligence informacija, kurią surinko Cisco Talos – didžiausia pasaulyje nevyriausybinė kibernetinio saugumo grėsmių tyrinėtojų grupė.

Tai leidžia įdiegti vieningą viešųjų ir hibridinių debesų stebėjimo sistemą, kurią gali naudoti jūsų įmonė. Tada surinkta informacija gali būti analizuojama naudojant „Stealthwatch Cloud“ integruotas galimybes arba siunčiama į jūsų SIEM („Splunk“, „ELK“, „SumoLogic“ ir keletas kitų palaikomi pagal numatytuosius nustatymus).

Tuo užbaigsime pirmąją straipsnio dalį, kurioje apžvelgiau integruotus ir išorinius IaaS/PaaS platformų informacijos saugumo stebėjimo įrankius, leidžiančius greitai aptikti ir reaguoti į debesų aplinkose vykstančius incidentus. mūsų įmonė pasirinko. Antroje dalyje tęsime temą ir apžvelgsime SaaS platformų stebėjimo galimybes Salesforce ir Dropbox pavyzdžiu, taip pat pabandysime viską apibendrinti ir sudėti kurdami vieningą informacijos saugumo stebėjimo sistemą skirtingiems debesų tiekėjams.

Šaltinis: www.habr.com