Transferimi i tĂ« dhĂ«nave dhe aplikacioneve nĂ« mbĂ«shtetje paraqet njĂ« sfidĂ« tĂ« re pĂ«r SOC-tĂ« e korporatave, tĂ« cilat nuk janĂ« gjithmonĂ« tĂ« gatshme pĂ«r tĂ« monitoruar infrastrukturĂ«n e huaj. Sipas Netoskope, njĂ« ndĂ«rmarrje mesatare (pĂ«r sa duket nĂ« SHBA) pĂ«rdor 1246 shĂ«rbime tĂ« ndryshme nĂ« mbĂ«shtetje, qĂ« Ă«shtĂ« 22% mĂ« shumĂ« se njĂ« vit mĂ« parĂ«. 1246 shĂ«rbime mbĂ«shtetje!!! 175 prej tyre lidhen me shĂ«rbimet HR, 170 me marketingun, 110 â nĂ« fushĂ«n e komunikimeve dhe 76 nĂ« financa dhe CRM. NĂ« Cisco pĂ«rdoren "vetĂ«m" 700 shĂ«rbime tĂ« jashtme tĂ« mbĂ«shtetjes. Prandaj, mĂ« shqetĂ«sojnĂ« kĂ«to numra. Por nĂ« çdo rast, problemi nuk Ă«shtĂ« te ata, por te fakti se mbĂ«shtetja po fillon tĂ« aplikohet gjithnjĂ« e mĂ« aktivisht nga njĂ« numĂ«r gjithnjĂ« e nĂ« rritje kompanish, tĂ« cilat do tĂ« dĂ«shironin tĂ« kishin tĂ« njĂ«jtat mundĂ«si pĂ«r monitorimin e infrastrukturĂ«s sĂ« mbĂ«shtetjes, si nĂ« rrjetin e tyre tĂ« brendshĂ«m. Dhe kjo tendencĂ« po rritet â sipas nĂ« vitin 2023 SHBA priten tĂ« mbyllin 1200 Qendrat e tĂ« DhĂ«nave (6250 tashmĂ« janĂ« mbyllur). Por kalimi nĂ« mbĂ«shtetje nuk Ă«shtĂ« vetĂ«m "o le tĂ« transferojmĂ« serverat tanĂ« te njĂ« ofrues tĂ« jashtĂ«m". NjĂ« arkitekturĂ« tĂ« re IT, njĂ« software tĂ« ri, procese tĂ« reja, kufizime tĂ« reja⊠TĂ« gjitha kĂ«to sjellin ndryshime tĂ« konsiderueshme nĂ« funksionimin e jo vetĂ«m IT, por edhe tĂ« sigurisĂ« informative. Dhe nĂ«se ofruesit kanĂ« mĂ«suar si tĂ« sigurojnĂ« sigurinĂ« e mbĂ«shtetjes vetĂ« (sigurisht ka rekomandime tĂ« mjaftueshme), monitorimi i sigurisĂ« informative nĂ« mbĂ«shtetje, veçanĂ«risht nĂ« platformat SaaS, ka sfida tĂ« konsiderueshme, pĂ«r tĂ« cilat do tĂ« flasim.
Supozoni që kompania juaj ka transferuar një pjesë të infrastrukturës së saj në cloud... Ndalo. Jo kështu. Nëse infrastruktura është transferuar dhe ju po mendoni tani se si do ta monitoroni, atëherë tashmë keni humbur. Nëse nuk është Amazon, Google ose Microsoft (edhe ato me disa përjashtime), është e mundshme që të mos keni shumë mundësi për monitorimin e të dhënave dhe aplikacioneve tuaja. E mira është nëse ju jepet mundësia për të punuar me log-et. Ndërsa ndonjëherë të dhënat për ngjarjet e sigurisë janë të aksesueshme, ndonjëherë ju nuk keni qasje në to. Për shembull, Office 365. Nëse keni licencën më të lartë E1, atëherë ngjarjet e sigurisë nuk janë të aksesueshme fare. Me licencën E3, të dhënat ruhen vetëm për 90 ditë, dhe vetëm me E5 - për një vit (përveç se këtu ka disa nuanca të tjera, që lidhen me nevojën për të kërkuar veçmas disa funksione për punën me log-et nga mbështetja e Microsoft). Përveç kësaj, licenca E3 është shumë më e dobët në lidhje me funksionet e monitorimit krahasuar me Exchange-in e korporatës. Për të arritur të njëjtin nivel, ju nevojitet licenca E5 ose një licencë shtesë Advanced Compliance, të cilat mund të kërkojnë para shtesë që nuk ishin parashikuar në modelin tuaj financiar për kalimin në infrastrukturën cloud. Dhe ky është vetëm një shembull i nënvlerësimit të çështjeve të lidhura me monitorimin e sigurisë në cloud. Në këtë artikull, duke mos pretenduar për plotësinë e përshkrimit, dëshiroj të tërheq vëmendjen në disa nuanca që duhen marrë parasysh kur zgjidhni ofruesin e cloud në aspektin e sigurisë. Në fund të artikullit, do të jap një listë kontrolli që duhet të përmbushni përpara se të mendoni se pyetja e monitorimit të sigurisë në cloud është zgjidhur.
Mund të identifikohen disa probleme tipike që çojnë në incidente në mjediset cloud, ndaj të cilave shërbimet e sigurisë nuk arrijnë të reagojnë ose nuk i shohin fare:
- Log-et e sigurisĂ« nuk ekzistojnĂ«. Kjo Ă«shtĂ« njĂ« situatĂ« mjaft e zakonshme, veçanĂ«risht pĂ«r lojtarĂ«t e rinj nĂ« tregun e zgjidhjeve cloud. Por nuk duhet tĂ« hedhim menjĂ«herĂ« njĂ« cross mbi ta. LojtarĂ«t mĂ« tĂ« vegjĂ«l, sidomos ata vendas, janĂ« mĂ« tĂ« ndjeshĂ«m ndaj kĂ«rkesave tĂ« klientĂ«ve dhe mund tĂ« zbatohen me shpejtĂ«si disa funksione tĂ« kĂ«rkuara duke ndryshuar planin e miratuar pĂ«r produktet e tyre. Po, nuk do tĂ« jetĂ« njĂ« analog i GuardDuty nga Amazon ose moduli i âMbrojtjes Proaktiveâ nga Bitrix, por Ă«shtĂ« diçka.
- IB nuk e di se ku ruhen logĂ«t ose nuk ka qasje nĂ« to. KĂ«tu Ă«shtĂ« e nevojshme tĂ« fillohen negociatat me ofruesin e shĂ«rbimeve cloud â ndoshta ai do t'ia ofrojĂ« tĂ« tillĂ« informacion, nĂ«se e sheh klientin si tĂ« rĂ«ndĂ«sishĂ«m pĂ«r vetĂ«. Por nĂ« pĂ«rgjithĂ«si, nuk Ă«shtĂ« shumĂ« mirĂ« qĂ« aksesin nĂ« logĂ« e ofrojnĂ« "me njĂ« vendim tĂ« veçantĂ«".
- Ndonjëherë ndodh që logët tek ofruesi i cloud-it janë, por ata ofrojnë monitorim dhe regjistrim të kufizuar të ngjarjeve, të pamjaftueshme për zbulimin e të gjitha incidenteve. Për shembull, ata mund t'ju japin vetëm logët e ndryshimeve në faqe ose logët e përpjekjeve të autentikimit të përdoruesve, por ngjarje të tjera, si për shembull rreth trafikut të rrjetit, nuk i jepni, gjë që do të fshehë një pjesë të madhe të ngjarjeve që karakterizojnë përpjekjet për të komprometuar infrastrukturën tuaj cloud.
- Logët ekzistojnë, por është e vështirë të automatizohet qasja në to, gjë që i detyron ata të monitorohen jo vazhdimisht, por sipas një programi. Dhe nëse për më tepër, logët nuk mund të shkarkohen në mënyrë automatike, atëherë eksportimi i logëve, për shembull në formatin Excel (siç ndodh me disa ofrues të brendshëm të zgjidhjeve cloud), mund ta bëjë atë të papëlqyeshëm për shërbimin korporativ të IB.
- Nuk ka monitorim të logëve. Kjo, ndoshta, është arsyeja më e paqartë e shfaqjes së incidenteve të IB në ambientet cloud. Duket se logët janë dhe mund të automatizohet qasja në to, por askush nuk e bën këtë. Pse?
Koncepti i sigurisë së ndarë në cloud
Kalimi nĂ« re Ă«shtĂ« gjithmonĂ« njĂ« kĂ«rkim balancimi midis dĂ«shirĂ«s pĂ«r tĂ« mbajtur kontrollin mbi infrastrukturĂ«n dhe transferimin e saj nĂ« duar mĂ« profesionale tĂ« ofruesit tĂ« shĂ«rbimeve nĂ« re, i cili specializohet nĂ« mbĂ«shtetje. Edhe nĂ« fushĂ«n e sigurisĂ« sĂ« mjediseve nĂ« re, ky balancim duhet tĂ« kĂ«rkohet. Sidomos, qĂ« balanci do tĂ« ndryshojĂ« vazhdimisht nĂ« varĂ«si tĂ« modelit tĂ« ofrimit tĂ« shĂ«rbimeve nĂ« re (IaaS, PaaS, SaaS). NĂ« çdo rast, duhet tĂ« mbani mend se tĂ« gjithĂ« ofruesit e shĂ«rbimeve nĂ« re sot ndjekin tĂ« ashtuquajturin model tĂ« pĂ«rgjegjĂ«sisĂ« tĂ«ndĂ«rruar dhe tĂ« sigurisĂ« sĂ« ndarĂ«. Diçka pĂ«rgjigjet reja, diçka pĂ«rgjigjet klienti, i cili ka vendosur nĂ« re tĂ« dhĂ«nat e tij, aplikacionet e tij, makinat e tij virtuale dhe burimet e tjera. Do tĂ« ishte e paarsyeshme tĂ« mendohej se, duke shkuar nĂ« re, ne do tĂ« transferonim gjithĂ« pĂ«rgjegjĂ«sinĂ« te ofruesi. Por Ă«shtĂ« gjithashtu e pamundur tĂ« ndĂ«rtojmĂ« tĂ« gjithĂ« sigurinĂ« vetĂ« gjatĂ« kalimit nĂ« re. Nevojitet njĂ« balancim, i cili do tĂ« varet nga shumĂ« faktorĂ«: â strategjia e menaxhimit tĂ« rreziqeve, modeli i kĂ«rcĂ«nimeve, mekanizmat e mbrojtjes qĂ« ka ofruesi i shĂ«rbimeve nĂ« re, legjislacioni etj.
Për shembull, klasifikimi i të dhënave të vendosura në re është gjithmonë përgjegjësi e klientit. Ofruesi i shërbimeve në re ose një ofrues i jashtëm mund të ndihmojë vetëm me mjetet që do të ndihmojnë në etiketimin e të dhënave në re, zbulojën e shkeljeve, fshirjen e të dhënave që shkelin legjislacionin ose maskimin e tyre me ndonjë metodë. Nga ana tjetër, siguria fizike është gjithmonë përgjegjësi e ofruesit të shërbimeve në re, e cila nuk mund të shpërndahet me klientët. Ndërsa gjithçka që ndodhet mes të dhënave dhe infrastrukturës fizike është pikërisht ajo që është objekt i diskutimit të këtij artikulli. Për shembull, disponueshmëria e re është përgjegjësi e ofruesit, ndërsa konfigurimi i rregullave të MSà ose aktivizimi i enkriptimit është tashmë përgjegjësi e klientit. Në këtë artikull do të përpiqemi të shikojmë se cilat mekanizma monitorimi të sigurisë ofrojnë sot ofruesit popullorë të shërbimeve në re në Rusi, cilat janë karakteristikat e përdorimit të tyre, dhe kur është mirë të shikoni drejt zgjidhjeve të jashtme (përdorimi i Cisco E-mail Security), që zgjeron mundësitë e re në aspektin e sigurisë kibernetike. Në disa raste, veçanërisht kur ndiqni një strategji multi-re, nuk do të keni zgjedhje tjetër përveçse të përdorni zgjidhje të jashtme për monitorimin e sigurisë në disa mjedise re (për shembull, Cisco CloudLock ose Cisco Stealthwatch Cloud). Por në disa raste, do të kuptoni se ofruesi i shërbimeve në re që keni zgjedhur (apo që ju është imponuar) nuk ofron fare mundësi për monitorimin e sigurisë. Kjo është e pakëndshme, por gjithashtu shumë e rëndësishme, pasi lejon të vlerësohet në mënyrë të arsyeshme niveli i rrezikut që lidhet me përdorimin e kësaj re.
Cikli i jetës së monitorimit të sigurisë së re
Për të monitoruar sigurinë e reve që po përdorni, keni vetëm tre mundësi:
- të mbështeteni në mjetet e ofruara nga ofruesi juaj i shërbimeve në re,
- të përdorni zgjidhjet e kompanive të treta, të cilat do të monitorojnë platformat tuaja IaaS, PaaS ose SaaS,
- të ndërtoni infrastrukturën tuaj të monitorimit të mjediseve të re (vetëm për platformat IaaS/PaaS).
Le të shohim se cilat janë veçoritë e secilës nga këto mundësi. Por para se të fillojmë, është e nevojshme të kuptojmë skemën e përgjithshme që do të përdoret për monitorimin e platformave cloud. Unë do të veçoja 6 komponentët kryesorë të procesit të monitorimit të sigurisë në cloud:
- Pregatisja e infrastrukturës. Përcaktimi i aplikacioneve dhe infrastrukturës së nevojshme për mbledhjen e ngjarjeve të rëndësishme për sigurinë, në magazinë.
- Mbledhja. Në këtë fazë, ngjarjet e sigurisë grumbullohen nga burime të ndryshme për t'u transferuar më pas për përpunim, ruajtje dhe analizë.
- Përpunimi. Në këtë fazë, të dhënat transformohen dhe pasurohen për të lehtësuar analizën e mëvonshme.
- Ruajtja. Ky komponent është përgjegjës për ruajtjen afatshkurtër dhe afatgjatë të të dhënave të mbledhura, të përpunuara dhe "të papërpunuara".
- Analiza. Në këtë fazë keni mundësinë të zbuloni incidentet dhe të reagoni ndaj tyre në mënyrë automatike ose manuale.
- Raportimi. Kjo fazë ndihmon në formimin e treguesve kyç për palët e interesuara (menaxhimi, auditorët, ofruesi i cloud, klientët etj.) që na ndihmojnë të marrim vendime të caktuara, siç është ndërrimi i ofruesit ose forcimi i sigurisë.
Kuptimi i këtyre komponentëve do t'ju lejojë të përcaktoni shpejt se çfarë mund të merrni nga ofruesi juaj, dhe çfarë do t'ju duhet ta bëni vetë ose me ndihmën e konsultantëve të jashtëm.
Kapacitetet e ndërtuara të shërbimeve cloud
Më parë kam shkruar se shumë shërbime të cloud sot nuk ofrojnë asnjë mundësi për monitorimin e sigurisë së informacionit. Në përgjithësi, tema e sigurisë së informacionit nuk i kushtohet shumë vëmendje. Për shembull, një nga shërbimet e njohura ruse për dërgimin e raporteve në organet shtetërore përmes Internetit (nuk do ta përmend emrin e tij). E gjithë seksioni për sigurinë e këtij shërbimi qendron rreth përdorimit të SKZ-së me certifikatë. Seksioni për sigurinë e informacionit të një shërbimi tjetër vendas të cloud për menaxhimin elektronik të dokumenteve është shumë më i madh. Aty flitet për certifikatat e çelive publike, kriptografinë e certifikuar, elimimin e dobësive në web, mbrojtjen nga sulmet DDoS, përdorimin e MSE-së, kopjimin rezervë dhe madje kryerjen e rregullt të auditit të sigurisë së informacionit. Por për monitorimin nuk thuhet asnjë fjalë, as për mundësinë e marrjes së aksesit në ngjarjet e sigurisë së informacionit, të cilat mund të jenë të rëndësishme për klientët e këtij ofruesi shërbimi.
Në përgjithësi, nga mënyra si e përshkruan ofruesi i cloud çështjet e sigurisë së informacionit në faqen e tij dhe në dokumentacion, mund të kuptohet se sa seriozisht e merr ai këtë çështje. Për shembull, nëse lexoni udhëzimet për produktet "Moy Ofis", atje nuk ka asnjë fjalë për sigurinë, ndërsa në dokumentacionin për produktin e veçantë "Moy Ofis. KS3", i cili është i destinuar për mbrojtjen nga akseset e paautorizuara, ka vetëm një renditje të zakonshme të pikave të urdhrit të 17-të të FSTEK që përmbush "Moy Ofis.KS3", por nuk përshkruhet si i realizon dhe, më e rëndësishmja, si të integroni këto mekanizma me sigurinë e informacionit të kompanisë. Ndoshta një dokumentacion i tillë ekziston, por në akses publik, në faqen e "Moy Ofis" nuk e kam gjetur. Megjithatë, ndoshta thjesht nuk kam akses në këtë informacion sekret...
Situata tek Bitrix Ă«shtĂ« ndjeshĂ«m mĂ« e mirĂ«. Dokumentacioni pĂ«rshkruan formatet e regjistrave tĂ« ngjarjeve dhe, çudi, regjistrin e sulmeve, i cili pĂ«rmban ngjarje tĂ« lidhura me kĂ«rcĂ«nimet potenciale pĂ«r platformĂ«n cloud. Nga atje mund tĂ« nxirrni IP-nĂ«, emrin e pĂ«rdoruesit ose mikut, burimin e ngjarjes, kohĂ«n, User Agent, tipin e ngjarjes, etj. MegjithatĂ«, puna me kĂ«to ngjarje mund tĂ« bĂ«het ose nga paneli i kontrollit tĂ« cloud-it, ose tĂ« shkarkoni tĂ« dhĂ«nat nĂ« formatin MS Excel. Tani Ă«shtĂ« e vĂ«shtirĂ« tĂ« automatizoni punĂ«n me regjistrat e Bitrix, dhe do t'ju duhet tĂ« bĂ«ni njĂ« pjesĂ« tĂ« punĂ«s manualisht (shkarkimi i raportit dhe ngarkimi i tij nĂ« SIEM-in tuaj). Por nĂ«se e kujtojmĂ« se edhe para pak kohĂ«sh nuk kishte njĂ« mundĂ«si tĂ« tillĂ«, kjo Ă«shtĂ« njĂ« pĂ«rparim i madh. Dua tĂ« theksoj gjithashtu se shumĂ« ofrues tĂ« huaj tĂ« cloud-it ofrojnĂ« funksionalitete tĂ« ngjashme "pĂ«r fillestarĂ«t" â ose shiko regjistrat me sy pĂ«rmes panelit tĂ« kontrollit, ose shkarkoni tĂ« dhĂ«nat tĂ« tuajat (meqĂ« tĂ« shumtĂ«t shkarkojnĂ« tĂ« dhĂ«nat nĂ« formatin .csv, e jo Excel).
NĂ«se nuk e merrni nĂ« konsideratĂ« zgjedhjen pa regjistra, ofruesit e cloud zakonisht ju ofrojnĂ« tri mundĂ«si pĂ«r tĂ« monitoruar ngjarjet e sigurisĂ« â panellet e kontrollit, eksportin e tĂ« dhĂ«nave dhe aksesin pĂ«rmes API. E para duket se zgjidh shumĂ« probleme pĂ«r ju, por nuk Ă«shtĂ« krejtĂ«sisht e tillĂ«, â kur ka disa regjistra duhet tĂ« kaloni ndĂ«rmjet ekraneve qĂ« i shfaqin ato, duke humbur pamjen e pĂ«rgjithshme. PĂ«r mĂ« tepĂ«r, Ă«shtĂ« e vĂ«shtirĂ« qĂ« ofruesi i cloud tĂ« ofrojĂ« mundĂ«sinĂ« pĂ«r korrelacionin e ngjarjeve tĂ« sigurisĂ« dhe pĂ«r analizimin e tyre nga pikĂ«pamja e sigurisĂ« (zakonisht jeni duke u marrĂ« me tĂ« dhĂ«na tĂ« papĂ«rpunuara, nĂ« tĂ« cilat duhet tĂ« merret vesh vetĂ«). Ka pĂ«rjashtime dhe pĂ«r to do tĂ« flasim mĂ« vonĂ«. NĂ« fund, ia vlen tĂ« pyesim se cilat ngjarje regjistron ofruesi juaj i cloud, nĂ« çfarĂ« formati, dhe sa i pĂ«rshtaten ato procesit tuaj tĂ« monitorimit tĂ« sigurisĂ« sĂ« informacionit? PĂ«r shembull, identifikimi dhe autentifikimi i pĂ«rdoruesve dhe mysafirĂ«ve. Po ashtu, Bitrix ju lejon tĂ« regjistroni datĂ«n dhe orĂ«n e kĂ«saj ngjarjeje, emrin e pĂ«rdoruesit apo tĂ« mysafirit (nĂ«se ka modulin "Web-Analitika"), objektin tĂ« cilit iu qas dhe elemente tĂ« tjera tipike pĂ«r njĂ« faqe web. Por shĂ«rbimet e korporatave tĂ« sigurisĂ« sĂ« informacionit mund t'i nevojitet informacion nĂ«se pĂ«rdoruesi hyri nĂ« cloud nga njĂ« pajisje e besueshme (p.sh., nĂ« rrjetin korporativ, kĂ«tĂ« detyrĂ« e realizon Cisco ISE). Dhe njĂ« detyrĂ« kaq e thjeshtĂ«, si funksioni geo-IP, i cili do tĂ« ndihmojĂ« tĂ« pĂ«rcaktoni nĂ«se llogaria e pĂ«rdoruesit tĂ« shĂ«rbimit tĂ« cloud Ă«shtĂ« vjedhur? Dhe madje edhe nĂ«se ofruesi i cloud ju ofron kĂ«tĂ«, kjo Ă«shtĂ« e pamjaftueshme. Cisco CloudLock nuk analizon thjesht gjeolokacionin, por pĂ«rdor mĂ«simin e makinerive dhe analizon tĂ« dhĂ«nat historike pĂ«r çdo pĂ«rdorues dhe ndjek anomalitĂ« e ndryshme nĂ« pĂ«rpjekjet pĂ«r identifikim dhe autentifikim. NjĂ« funksionalitet tĂ« ngjashĂ«m ka vetĂ«m MS Azure (nĂ«se ka njĂ« abonim pĂ«rkatĂ«s).
Ka njĂ« vĂ«shtirĂ«si tjetĂ«r â pĂ«r shumĂ« ofrues tĂ« shĂ«rbimeve nĂ« re, monitorimi i sigurisĂ« Ă«shtĂ« njĂ« temĂ« e re, me tĂ« cilĂ«n ata sapo kanĂ« filluar tĂ« merren, ndonjĂ«herĂ« ata vazhdojnĂ« tĂ« ndryshojnĂ« zgjidhjet e tyre. Sot kanĂ« njĂ« version API, nesĂ«r njĂ« tjetĂ«r, pasnesĂ«r njĂ« tĂ« tretĂ«. Kjo duhet gjithashtu tĂ« merret parasysh. E njĂ«jta gjĂ« vlen edhe pĂ«r funksionalitetin, i cili mund tĂ« ndryshojĂ«, dhe qĂ« duhet tĂ« konsiderohet nĂ« sistemin e monitorimit tĂ« sigurisĂ«. PĂ«r shembull, Amazon fillimisht kishte shĂ«rbime tĂ« veçanta pĂ«r monitorimin e ngjarjeve nĂ« re â AWS CloudTrail dhe AWS CloudWatch. MĂ« pas u shfaq njĂ« shĂ«rbim i veçantĂ« pĂ«r monitorimin e ngjarjeve tĂ« sigurisĂ« â AWS GuardDuty. Pas njĂ« kohe, Amazon launchoi sistemin e ri tĂ« menaxhimit Amazon Security Hub, i cili pĂ«rfshin analizĂ«n e tĂ« dhĂ«nave tĂ« marra nga GuardDuty, Amazon Inspector, Amazon Macie dhe disa tĂ« tjerĂ«. NjĂ« shembull tjetĂ«r, Ă«shtĂ« mjeti i integrimit tĂ« logĂ«ve Azure me SIEM â AzLog. Ai u pĂ«rdor nga shumĂ« ofrues SIEM, derisa nĂ« vitin 2018 Microsoft shpalli ndalimin e zhvillimit dhe mbĂ«shtetjes sĂ« tij, çka la shumĂ« klientĂ«, qĂ« e pĂ«rdornin kĂ«tĂ« mjet, para njĂ« problemi (si u zgjidh kjo, do tĂ« flasim mĂ« vonĂ«).
Prandaj, monitoroni me kujdes tĂ« gjitha funksionalitetet e monitorimit qĂ« ofron ofruesi juaj i shĂ«rbimeve nĂ« re. Ose besoni te ofruesit e jashtĂ«m tĂ« zgjidhjeve, tĂ« cilĂ«t do tĂ« veprojnĂ« si ndĂ«rmjetĂ«s midis SOC tuaj dhe reja qĂ« dĂ«shironi tĂ« monitoroni. Po, do tĂ« jetĂ« mĂ« shtrenjtĂ« (edhe pse jo gjithmonĂ«), por kĂ«shtu do t'i kaloni tĂ« gjitha pĂ«rgjegjĂ«sitĂ« mbi shpatullat e tĂ« tjerĂ«ve. Ose jo tĂ« gjitha? Duke kujtuar konceptin e sigurisĂ« sĂ« ndarĂ«, do tĂ« kuptojmĂ« se nuk do tĂ« mund tĂ« kalojmĂ« asgjĂ« â do tĂ« duhet tĂ« merremi vetĂ« me mĂ«nyrĂ«n sesi ofruesit e ndryshĂ«m tĂ« shĂ«rbimeve nĂ« re e sigurojnĂ« monitorimin e sigurisĂ« sĂ« tĂ« dhĂ«nave tuaja, aplikacioneve, makinave virtuale dhe burimeve tĂ« tjera tĂ« vendosura nĂ« re. Dhe do tĂ« fillojmĂ« me atĂ« qĂ« ofron Amazon nĂ« kĂ«tĂ« aspekt.
Shembulli: Monitorimi i sigurisë në IaaS në bazë të AWS
Po, po, e kuptoj se Amazon nuk është shembulli më i mirë për shkak se është një shërbim amerikan dhe mund të bllokohet në kuadër të luftës kundër ekstremizmit dhe shpërndarjes së informacionit të ndaluar në territorin e Rusisë. Në këtë publikim do të doja thjesht të tregoj se sa ndryshojnë platformat e ndryshme cloud në mundësitë e monitorimit të sigurisë së informacionit dhe ndaj çfarë duhet të kushtohet vëmendje kur transferoni proceset tuaja kryesore në cloud nga pikëpamja e sigurisë. Dhe nëse ndonjë nga zhvilluesit rusë të zgjidhjeve cloud merr ndonjë gjë të dobishme për vete, atëherë kjo do të ishte shkëlqyer.
Së pari, duhet thënë se Amazon nuk është një forte e paprekshme. Klientëve të tij u ndodhin rregullisht incidente të ndryshme. Për shembull, Deep Root Analytics patën të dhëna të vjedhura që përfshinin emrat, adresat, datat e lindjes, dhe numrat e telefonit të 198 milion votuesve. Një kompani izraelite si Nice Systems pati vjedhje të 14 milion regjistrimeve për abonentët e Verizon. Megjithatë, mundësitë e integruara të AWS ju lejojnë të zbuloni një gamë të gjerë incidentsh. Për shembull:
- ndikimi në infrastrukturë (DDoS)
- kompromitimi i nyjës (injektimi i komandave)
- kompromitimi i llogarisë dhe akses i paautorizuar
- konfigurim i gabuar dhe dobësi
- ndërfaqe dhe API të pa mbrojtura.
Ky mos përputhje është e lidhur me faktin se për sigurinë e të dhënave të klientit, siç e zbuluam më lart, është përgjegjës vetë klienti. Dhe nëse ai nuk është kujdesur për aktivizimin e mekanizmave të mbrojtjes dhe nuk ka aktivizuar mjetet e monitorimit, ai do të mësojë për incidentin vetëm nga mediat ose nga klientët e tij.
PĂ«r identifikimin e incidenteve, mund tĂ« pĂ«rdoren njĂ« gamĂ« tĂ« gjerĂ« shĂ«rbimesh pĂ«r monitorim tĂ« zhvilluara nga Amazon (edhe pse ato shpesh plotĂ«sohen nga mjete tĂ« jashtme, siç Ă«shtĂ« osquery). NĂ« AWS, ndiqen tĂ« gjitha veprimet e pĂ«rdoruesve, pavarĂ«sisht se si kryhen ato - pĂ«rmes konsolĂ«s sĂ« menaxhimit, komandĂ«s, SDK-sĂ« ose shĂ«rbimeve tĂ« tjera tĂ« AWS. TĂ« gjitha regjistrimet e veprimeve tĂ« çdo llogarie AWS (pĂ«rfshirĂ« emrin e pĂ«rdoruesit, veprimin, shĂ«rbimin, parametrat e aktiviteteve dhe rezultatin e saj) dhe pĂ«rdorimi i API-t janĂ« tĂ« disponueshme pĂ«rmes shĂ«rbimit AWS CloudTrail. Ju mund tĂ« shikoni kĂ«to ngjarje (p.sh., hyrjen nĂ« konsolĂ«n AWS IAM) nga konsola CloudTrail, tâi analizonit me Amazon Athena ose tâi âdoniâ ato nĂ« zgjidhje tĂ« jashtme, siç janĂ« Splunk, AlienVault etj. Regjistrimet e AWS CloudTrail ruhen nĂ« bucket-in tuaj AWS S3.
Dy shërbime të tjera të AWS ofrojnë një sërë mundësish të rëndësishme për monitorim. Së pari, Amazon CloudWatch është një shërbim monitorimi për burimet dhe aplikacionet e AWS, i cili lejon, ndër të tjera, identifikimin e anomalive të ndryshme në cloud-in tuaj. Të gjitha shërbimet e integruara të AWS, si Amazon Elastic Compute Cloud (servera), Amazon Relational Database Service (baza të dhënash), Amazon Elastic MapReduce (analizë të dhënash) dhe më shumë se 30 shërbime të tjera të Amazon, përdorin Amazon CloudWatch për ruajtjen e regjistrimeve të tyre. Zhvilluesit mund të përdorin API-në e hapur nga Amazon CloudWatch për të shtuar funksionin e monitorimit të regjistrave në aplikacionet dhe shërbimet e tyre, gjë që lejon zgjerimin e gamës së ngjarjeve që analizohet në kontekstin e sigurisë informatike.
Së dyti, shërbimi VPC Flow Logs lejon analizimin e trafikut rrjetor që dërgohet ose merret nga serverat tuaj AWS (nga jashtë ose brenda), si dhe midis mikrosherbimeve. Kur ndonjë prej burimeve tuaja AWS VPC ndërvepron me rrjetin, shërbimi VPC Flow Logs regjistron informacion rreth trafikut rrjetor, duke përfshirë ndërfaqen rrjetore të burimit dhe destinacionit, si dhe adresat IP, portet, protokollin, numrin e bajtave dhe numrin e pakove që keni parë. Ata që kanë përvojë në sigurinë e rrjeteve lokale e njohin këtë si ekuivalentin e rrjedhave. , të cilat mund të krijohen nga switch-e, router-e dhe firewalle të nivelit të korporatave. Këto log-e janë të rëndësishme për qëllime monitorimi të sigurisë, sepse, ndryshe nga ngjarjet e veprimeve të përdoruesve dhe aplikacioneve, lejojnë që të mos humbasim edhe ndërveprimin më rrjet në mjedisin virtual privat të cloud-it AWS.
Pra, kĂ«to tre shĂ«rbime AWS â AWS CloudTrail, Amazon CloudWatch dhe VPC Flow Logs â sĂ« bashku ofrojnĂ« njĂ« pĂ«rfaqĂ«sim mjaft efikas mbi pĂ«rdorimin e llogarisĂ« tuaj, sjelljen e pĂ«rdoruesve, menaxhimin e infrastrukturĂ«s, aktivitetin e aplikacioneve dhe shĂ«rbimeve, si dhe aktiviteten rrjet. PĂ«r shembull, me ndihmĂ«n e kĂ«tyre shĂ«rbimeve mund tĂ« zbulojmĂ« anomalitĂ« e mĂ«poshtme:
- Përpjekjet për të skanuar faqen, për të kërkuar backdoor-e, për të kërkuar dobësi përmes shpërthimeve të "gabimeve 404".
- Sulmet me injection (për shembull, SQL injection) përmes shpërthimeve të "gabimeve 500".
- Mjetet e njohura për sulme si sqlmap, nikto, w3af, nmap etj. përmes analizës së fushës User Agent.
Amazon Web Services ka zhvilluar gjithashtu shĂ«rbime tĂ« tjera pĂ«r qĂ«llime tĂ« sigurisĂ« kibernetike, tĂ« cilat lejojnĂ« zgjidhjen e shumĂ« problemeve tĂ« tjera. PĂ«r shembull, nĂ« AWS ka njĂ« shĂ«rbim tĂ« integruar pĂ«r auditimin e politikave dhe konfigurations â AWS Config. Ky shĂ«rbim siguron auditim tĂ« vazhdueshĂ«m tĂ« burimeve tuaja AWS dhe tĂ« konfigurimeve tĂ« tyre. Le tĂ« shqyrtojmĂ« njĂ« shembull tĂ« thjeshtĂ«: supozoni se dĂ«shironi tĂ« siguroheni qĂ« fjalĂ«kalimet e pĂ«rdoruesve tĂ« jenĂ« tĂ« çaktivizuara nĂ« tĂ« gjitha serverat tuaj dhe qasja tĂ« jetĂ« e mundur vetĂ«m nĂ« bazĂ« tĂ« certifikatave. AWS Config lejon qĂ« ta kontrolloni lehtĂ«sisht kĂ«tĂ« pĂ«r tĂ« gjithĂ« serverat tuaj. EkzistojnĂ« edhe politika tĂ« tjera qĂ« mund tĂ« aplikohen nĂ« serverat tuaj nĂ« cloud: "AsnjĂ« server nuk mund tĂ« pĂ«rdorĂ« portin 22", "VetĂ«m administratorĂ«t mund tĂ« ndryshojnĂ« rregullat e firewall-it" ose "VetĂ«m pĂ«rdoruesi Ivashko mund tĂ« krijojĂ« llogari tĂ« reja pĂ«rdoruesish, dhe ai mund ta bĂ«jĂ« kĂ«tĂ« vetĂ«m tĂ« martĂ«n". NĂ« verĂ«n e vitit 2016, shĂ«rbimi AWS Config u zgjerua pĂ«r tĂ« automatizuar zb discovery e shkeljeve tĂ« politikave tĂ« dizajnuara. AWS Config Rules janĂ«, nĂ« thelb, kĂ«rkesa tĂ« vazhdueshme pĂ«r konfigurimin e shĂ«rbimeve qĂ« po pĂ«rdorni nga Amazon, tĂ« cilat gjenerojnĂ« ngjarje nĂ« rast shkeljesh tĂ« politikave pĂ«rkatĂ«se. PĂ«r shembull, nĂ« vend qĂ« tĂ« ekzekutoni herĂ« pas here kĂ«rkesat AWS Config pĂ«r tĂ« kontrolluar qĂ« tĂ« gjithĂ« diskĂ«t e serverit virtual tĂ« jenĂ« tĂ« enkriptuar, AWS Config Rules mund tĂ« pĂ«rdoren pĂ«r kontrollin e vazhdueshĂ«m tĂ« diskĂ«ve tĂ« serverit pĂ«r tĂ« verifikuar pĂ«rmbushjen e kĂ«tij kushti. Dhe, çfarĂ« Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja, nĂ« kontekstin e kĂ«tij publikimi, çdo shkelje gjeneron ngjarje qĂ« mund tĂ« analizohen nga shĂ«rbimi juaj tĂ« sigurisĂ« informative.
Po ashtu, në AWS ka ekuivalente për zgjidhjet tradicionale të sigurisë së informacionit të korporatave, të cilat gjithashtu gjenerojnë ngjarje sigurie që ju mund dhe duhet t'i analizoni:
- zbulimi i sulmeve â AWS GuardDuty
- kontrolli i rrjedhjes sĂ« informacionit â AWS Macie
- EDR (ndonĂ«se duket paksa e çuditshme tĂ« flasĂ«sh pĂ«r terminale nĂ« cloud) â AWS Cloudwatch + zgjidhje open source si osquery ose GRR
- analiza Netflow â AWS Cloudwatch + AWS VPC Flow
- analiza DNS â AWS Cloudwatch + AWS Route53
- AD â AWS Directory Service
- menaxhimi i llogarive â AWS IAM
- SSO â AWS SSO
- analiza e sigurisĂ« â AWS Inspector
- menaxhimi i konfigurimeve â AWS Config
- WAF â AWS WAF.
Nuk e do të përshkruaj në detaje të gjitha shërbimet e Amazon që mund të jenë të dobishme në kontekstin e sigurisë informative. E rëndësishme është të kuptohet se të gjitha ato mund të gjenerojnë ngjarje, të cilat ne mund dhe duhet të analizojmë në kontekstin e ISH, duke angazhuar si mundësitë e brendshme të vetë Amazonit, ashtu edhe zgjidhje të jashtme, për shembull, SIEM, të cilat mund të mbledhin ngjarjet e sigurisë në qendrën tuaj të monitorimit dhe t'i analizojnë ato aty, së bashku me ngjarjet nga shërbime të tjera cloud ose nga infrastruktura e brendshme, perimetrin ose pajisjet mobile.
Në çdo rast, gjithçka fillon me burimet e të dhënave që ju ofrojnë ngjarjet e ISH. Midis këtyre burimeve mund të përfshihen:
- CloudTrail â pĂ«rdorimi i API-ve dhe veprat e pĂ«rdoruesve
- Trusted Advisor â kontrolli i sigurisĂ« pĂ«r pĂ«rputhshmĂ«rinĂ« me praktikat e mira
- Config â inventarizimi dhe konfigurimi i llogarive dhe cilĂ«simeve tĂ« shĂ«rbimeve
- VPC Flow Logs â lidhjet me ndĂ«rfaqet virtuale
- IAM â shĂ«rbimi i identifikimit dhe autentikimit
- ELB Access Logs â regjistrat e balancuesit tĂ« ngarkesĂ«s
- Inspector â dobĂ«sitĂ« nĂ« aplikacione
- S3 â depoja e skedarĂ«ve
- CloudWatch â aktiviteti i aplikacioneve
- SNS â shĂ«rbimi i njoftimeve.
Amazon, duke ofruar një gamë të tillë burash ngjarjesh dhe mjete për gjenerimin e tyre, është shumë i kufizuar në mundësitë për të analizuar të dhënat e mbledhura në kontekstin e ISH. Do t'ju duhet të studioni vetë regjistrat ekzistues, duke kërkuar aty tregues të përputhshmërisë. AWS Security Hub, i cili është lanceruar së fundmi nga Amazon, ka për qëllim të zgjidhë këtë problem, duke u bërë një lloj SIEM cloud për AWS. Por aktualisht, ai është vetëm në fillim të rrugës së tij dhe është i kufizuar si në numrin e burimeve me të cilat puna, ashtu edhe nga kufizime të tjera të vendosura nga arkitektura dhe abonimet e vetë Amazonit.
Shembulli: Monitorimi i ISH në IaaS bazuar në Azure
Nuk dua tĂ« hyj nĂ« njĂ« polemikĂ« tĂ« gjatĂ« se cili nga tre ofruesit e shĂ«rbimeve cloud (Amazon, Microsoft ose Google) Ă«shtĂ« mĂ« i mirĂ« (pĂ«r mĂ« shumĂ«, secili prej tyre ka specifikĂ«n e tij dhe Ă«shtĂ« i pĂ«rshtatshĂ«m pĂ«r zgjidhjen e detyrave tĂ« caktuara); le tĂ« pĂ«rqendrohemi te mundĂ«sitĂ« e monitorimit tĂ« sigurisĂ« informacionit qĂ« ofrojnĂ« kĂ«ta lojtarĂ«. ĂshtĂ« e vĂ«rtetĂ« qĂ« Amazon AWS ka qenĂ« njĂ« nga tĂ« parĂ«t nĂ« kĂ«tĂ« segment dhe ka ecur mĂ« pĂ«rpara nĂ« aspektin e funksioneve tĂ« sigurisĂ« informacionit (ndonĂ«se shumĂ« e pranojnĂ« se pĂ«rdorimi i tyre Ă«shtĂ« paksa i komplikuar). Por kjo nuk do tĂ« thotĂ« se ne do tĂ« injorojmĂ« mundĂ«sitĂ« qĂ« na ofrojnĂ« Microsoft dhe Google.
Produktet e Microsoft gjithmonë janë karakterizuar nga "hapja" e tyre dhe situata në Azure është e ngjashme. Për shembull, nëse AWS dhe GCP gjithmonë i qasën konceptit "gjithçka që nuk lejohet, është e ndaluar", Azure ka një qasje krejt të kundërt. Për shembull, duke krijuar një rrjet virtual në cloud dhe një makinë virtuale brenda tij, të gjitha portat dhe protokollet janë të hapura dhe të lejuara si parazgjedhje. Prandaj, do t'ju duhet të shpenzoni pak më shumë përpjekje për konfigurimin fillestar të sistemit të kontrollit të aksesit në cloud nga Microsoft. Dhe kjo gjithashtu vë përpara kërkesa më të rrepta për monitorimin e aktivitetit në cloud Azure.
AWS ka njĂ« veçori qĂ« lidhet me monitorimin e burimeve tuaja virtuale; nĂ«se ato ndodhen nĂ« regjione tĂ« ndryshme, pĂ«rballeni me vĂ«shtirĂ«si nĂ« konsolidimin e ngjarjeve dhe analizimin e tyre tĂ« njĂ«kohshĂ«m. Kjo do t'ju detyrojĂ« tĂ« pĂ«rdorni truke tĂ« ndryshme, siç Ă«shtĂ« krijimi i kodit tuaj pĂ«r AWS Lambda, i cili do tĂ« transferojĂ« ngjarjet midis regjioneve. NĂ« Azure nuk ka njĂ« problem tĂ« tillĂ« â mekanizmi i tij Activity Log monitoron tĂ« gjitha aktivitetet brenda organizatĂ«s pa kufizime. E njĂ«jta gjĂ« vlen pĂ«r AWS Security Hub, i cili u zhvillua sĂ« fundmi nga Amazon pĂ«r tĂ« konsoliduar shumĂ« funksione sigurie nĂ« njĂ« qendĂ«r tĂ« vetme sigurie, por vetĂ«m brenda regjionit tĂ« tij, gjĂ« qĂ«, megjithatĂ«, nuk Ă«shtĂ« relevante pĂ«r RusinĂ«. Azure ka QendrĂ«n e SigurisĂ« e cila nuk lidhet me kufizime regjioni, duke ofruar akses nĂ« tĂ« gjitha funksionet e sigurisĂ« sĂ« platformĂ«s cloud. MĂ« tej, pĂ«r ekipe tĂ« ndryshme lokale, ajo mund tĂ« ofrojĂ« grupin e vet tĂ« mundĂ«sive tĂ« mbrojtjes, duke pĂ«rfshirĂ« dhe ngjarjet e sigurisĂ« tĂ« menaxhuara prej tyre. AWS Security Hub ende po pĂ«rpiqet tĂ« ngjajĂ« me Azure Security Center. Por duhet tĂ« shtojmĂ« njĂ« nuancĂ« negative â mund tĂ« nxirrni shumĂ« nga Azure nga ato qĂ« u pĂ«rmendĂ«n mĂ« parĂ« pĂ«r AWS, por kjo Ă«shtĂ« mĂ« e lehtĂ« vetĂ«m pĂ«r Azure AD, Azure Monitor dhe Azure Security Center. TĂ« gjitha mekanizmat e tjerĂ« tĂ« mbrojtjes nĂ« Azure, duke pĂ«rfshirĂ« analizimin e ngjarjeve tĂ« sigurisĂ«, aktualisht menaxhohen nĂ« njĂ« mĂ«nyrĂ« qĂ« nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme. PjesĂ«risht problemi zgjidhet nga API, i cili ndĂ«rlidh tĂ« gjitha shĂ«rbimet e Microsoft Azure, por do tĂ« kĂ«rkojĂ« pĂ«rpjekje shtesĂ« pĂ«r tĂ« integruar cloud-in tuaj me SOC-in tuaj dhe pĂ«r tĂ« pasur specialistĂ« tĂ« kualifikuar (ashtu si me çdo SIEM tjetĂ«r qĂ« punon me API tĂ« clouds). Disa SIEM, pĂ«r tĂ« cilat do flasim mĂ« tutje, tashmĂ« e mbĂ«shtesin Azure dhe mund tĂ« automatizojnĂ« detyrĂ«n e monitorimit tĂ« tij, por edhe me ta ka disa vĂ«shtirĂ«si â nuk janĂ« tĂ« gjithĂ« nĂ« gjendje tĂ« marrin tĂ« gjitha log-Ă«t qĂ« ka Azure.
Koleksioni i ngjarjeve dhe monitorimi i tyre nĂ« Azure ofrohet pĂ«rmes shĂ«rbimit Azure Monitor, i cili Ă«shtĂ« mjeti kryesor pĂ«r mbledhjen, ruajtjen dhe analizĂ«n e tĂ« dhĂ«nave nĂ« re tĂ« Microsoft dhe burimeve tĂ« tij â depozitave Git, kontejnerĂ«ve, mashinave virtuale, aplikacioneve etj. TĂ« gjitha tĂ« dhĂ«nat, tĂ« mbledhura nga Azure Monitor, ndahen nĂ« dy kategori â metrika, tĂ« mbledhura nĂ« kohĂ« reale dhe qĂ« pĂ«rshkruajnĂ« treguesit kyç tĂ« aktivitetit tĂ« tij, dhe logjet e regjistrimit, qĂ« pĂ«rmbajnĂ« tĂ« dhĂ«na tĂ« organizuara nĂ« regjistrime, karakterizues tĂ« aspekteve tĂ« ndryshme tĂ« aktiviteteve tĂ« burimeve dhe shĂ«rbimeve tĂ« Azure. PĂ«r mĂ« tepĂ«r, pĂ«rmes API-t tĂ« Kolektorit tĂ« tĂ« DhĂ«nave, shĂ«rbimi Azure Monitor mund tĂ« mbledhĂ« tĂ« dhĂ«na nga çdo burim REST pĂ«r tĂ« ndĂ«rtuar skenarĂ«t e vet tĂ« monitorimit.
Ja disa burime ngjarjesh të sigurisë që Azure ofron dhe të cilat mund t'i qaseni përmes Azure Portal, CLI, PowerShell ose REST API (disa vetëm përmes Azure Monitor / Insight API):
- Aktiviteti Logs â ky regjistĂ«r pĂ«rgjigjet pĂ«r pyetje klasike si âkushâ, âçfarĂ«â dhe âkurâ nĂ« lidhje me çdo operacion regjistrimi (PUT, POST, DELETE) mbi burimet nĂ« re. Ngjarjet, qĂ« lidhen me aksesin pĂ«r tĂ« lexuar (GET), nuk pĂ«rfshihen nĂ« kĂ«tĂ« regjistĂ«r, ashtu si njĂ« numĂ«r i caktuar tjetĂ«r.
- Diagnostic Logs â pĂ«rmban tĂ« dhĂ«na mbi operacionet me ndonjĂ« burim qĂ« hyn nĂ« abonimin tuaj.
- Raportimi i Azure AD â pĂ«rmban si aktiviteten e pĂ«rdoruesve ashtu edhe aktivitetin sistemor, tĂ« lidhur me menaxhimin e grupeve dhe pĂ«rdoruesve.
- Windows Event Log dhe Linux Syslog â pĂ«rmban ngjarjet nga makinat virtuale tĂ« strehuara nĂ« re.
- Metrikat â pĂ«rmban telemetri mbi gjendjen e performancĂ«s dhe âshĂ«ndetitâ tĂ« shĂ«rbimeve dhe burimeve tuaja nĂ« re. Ato matĂ«n çdo minutĂ« dhe ruajnĂ« deri nĂ« 30 ditĂ«.
- Network Security Group Flow Logs â pĂ«rmban tĂ« dhĂ«na mbi ngjarjet e sigurisĂ« nĂ« rrjet, tĂ« mbledhura pĂ«rmes shĂ«rbimit Network Watcher dhe monitorimit tĂ« burimeve nĂ« nivelin e rrjetit.
- Storage Logs â pĂ«rmban ngjarje nĂ« lidhje me aksesin nĂ« depozitĂ«.
Për monitorimin, mund të përdorni SIEM të jashtëm ose Azure Monitor të integruar dhe shtesat e tij. Ne do të diskutojmë për sistemet e menaxhimit të ngjarjeve të sigurisë, por për tani le të shohim se çfarë ofron Azure për analizimin e të dhënave në kontekstin e sigurisë. Ekrani kryesor për të gjitha ato që lidhen me sigurinë në Azure Monitor është Log Analytics Security and Audit Dashboard (versioni falas mbështet ruajtjen e një sasi të kufizuar ngjarjesh për vetëm një javë). Ky panel është i ndarë në 5 zona kryesore, të cilat vizualizojnë statistikat përmbledhëse mbi atë që ndodh në mjedisin tuaj të re të cloud-it:
- Fushat e SigurisĂ« â treguesit kryesorĂ« tĂ« sasisĂ« lidhur me sigurinĂ« â numri i incidenteve, numri i nodave tĂ« komprometuar, nodet e papatchuara, ngjarjet e sigurisĂ« nĂ« rrjet etj.
- ĂĂ«shtjet e Dukshme â shfaq numrin dhe rĂ«ndĂ«sinĂ« e problemeve aktive me sigurinĂ«
- Zbulimet â shfaq modelet e sulmeve qĂ« janĂ« pĂ«rdorur kundĂ«r jush
- Inteligjenca pĂ«r KĂ«rcĂ«nimet â shfaq informacionin gjeografik pĂ«r nodet e jashtme qĂ« po ju sulmojnĂ«
- KĂ«rkesat e zakonshme pĂ«r siguri â kĂ«rkesa tipike qĂ« do t'ju ndihmojnĂ« tĂ« monitoroni mĂ« mirĂ« sigurinĂ« tuaj.
Si shtesa të Azure Monitor, mund të përmendim Azure Key Vault (mbrojtja e çelësave kriptografikë në cloud), Malware Assessment (analiza e mbrojtjes nga kodet e dëmshme në makinat virtuale), Azure Application Gateway Analytics (analiza, ndër të tjera, e logeve të firewall-it në cloud) etj. Këto mjete, të pasuruara me rregulla të caktuara për përpunimin e ngjarjeve, lejojnë vizualizimin e aspekteve të ndryshme të aktiviteteve të shërbimeve cloud, duke përfshirë sigurinë, dhe identifikimin e devijimeve nga puna. Por, siç ndodh shpesh, çdo funksionalitet shtesë kërkon një abonim përkatës të paguar, që do t'ju kërkojë investime financiare, të cilat duhet t'i planifikoni paraprakisht.
Azure ka njĂ« sĂ«rĂ« mundĂ«sish tĂ« ndĂ«rtuara pĂ«r monitorimin e kĂ«rcĂ«nimeve, tĂ« cilat janĂ« tĂ« integrora nĂ« Azure AD, Azure Monitor dhe Azure Security Center. NdĂ«r to, pĂ«r shembull, zbulimi i ndĂ«rveprimit tĂ« makinave virtuale me IP tĂ« njohura si tĂ« dĂ«mshme (falĂ« integrimit me shĂ«rbimet e InteligjencĂ«s mbi KĂ«rcĂ«nimet nga Microsoft), zbulimi i viruseve nĂ« infrastrukturĂ«n nĂ« re duke marrĂ« sinjale alarmi nga makinat virtuale qĂ« janĂ« tĂ« vendosura nĂ« re, sulmet e tipit âpĂ«rputhje e fjalĂ«kalimitâ ndaj makinave virtuale, dobĂ«sitĂ« nĂ« konfigurimin e sistemit tĂ« identifikimit tĂ« pĂ«rdoruesve, hyrja nĂ« sistem nga anĂ«n e anonimizuar ose nga nodet e infektuara, rrjedhja e llogarive, hyrja nĂ« sistem nga vende tĂ« pazakonta etj. Sot, Azure Ă«shtĂ« njĂ« nga pak ofruesit e shĂ«rbimeve cloud qĂ« ofron mundĂ«si tĂ« ndĂ«rtuara pĂ«r InteligjencĂ«n mbi KĂ«rcĂ«nimet pĂ«r tĂ« pasuruar ngjarjet e mbledhura tĂ« sigurisĂ«.
Siç u tha më parë, funksionaliteti mbrojtës dhe, si pasojë, ngjarjet e sigurisë që ai gjeneron, nuk janë të disponueshme për të gjithë përdoruesit në të njëjtën mënyrë, por kërkojnë një abonim të caktuar që përfshin funksionalitetin që ju nevojitet, i cili gjeneron ngjarjet për monitorimin e sigurisë. Për shembull, disa nga funksionet e përshkruara në paragrafin e kaluar për monitorimin e abnormaliteteve në llogaritë janë të disponueshme vetëm në licencën premium P2 për shërbimin Azure AD. Nëse nuk e keni atë, siç ndodh edhe në rastin e AWS, do t'ju duhet të analizoni ngjarjet e mbledhura të sigurisë "duke e bërë manualisht". Gjithashtu, në varësi të llojit të licencës për Azure AD, nuk do t'ju jenë në dispozicion të gjitha ngjarjet për analizë.
Në portalin Azure, ju mund të menaxhoni si kërkesat për regjistrat e regjistrimit që ju interesojnë, ashtu edhe të konfiguroni panele për vizualizimin e treguesve kryesorë të sigurisë. Për më tepër, aty gjithashtu mund të zgjidhni shtesa të Azure Monitor që ju lejojnë të zgjeroni funksionalitetin e logeve të Azure Monitor dhe të merrni një analizë më të thellë të ngjarjeve nga perspektiva e sigurisë.
Nëse ju nevojitet jo vetëm mundësia për të punuar me log-et, por një qendër gjithëpërfshirëse sigurie për platformën tuaj cloud Azure, duke përfshirë menaxhimin e politikave të sigurisë, atëherë mund të flasim për nevojën për të punuar me Azure Security Center, shumica e funksioneve të dobishme të të cilit janë të aksesueshme për një tarifë shtesë, për shembull, zbulimi i kërcënimeve, monitorimi jashtë Azure, vlerësimi i përputhshmërisë etj. (në versionin falas ju është e aksesueshme vetëm vlerësimi i sigurisë dhe rekomandimet për zgjidhjen e problemeve të identifikuara). Ai konsolidon të gjitha çështjet e sigurisë në një vend. Në thelb, mund të flasim për një nivel më të lartë sigurie se sa ajo që ju ofron Azure Monitor, pasi në këtë rast të dhënat e mbledhura nga e gjithë fabrika juaj cloud pasurohen me ndihmën e shumë burimeve, si Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) dhe Microsoft Security Response Center (MSRC), mbi të cilat aplikohen algoritme të avancuara të mësimit të makinerive dhe analizës së sjelljes, që në fund duhet të rrisin efikasitetin e zbulimit të kërcënimeve dhe reagimin ndaj tyre.
Azure ka edhe njĂ« SIEM tĂ« tijin â ai u shfaq nĂ« fillim tĂ« vitit 2019. Ky Ă«shtĂ« Azure Sentinel, i cili mbĂ«shtetet nĂ« tĂ« dhĂ«na nga Azure Monitor, dhe gjithashtu mund tĂ« integtohet me zgjidhje tĂ« jashtme pĂ«r sigurinĂ« (pĂ«r shembull, NGFW ose WAF), lista e tĂ« cilave vazhdimisht plotĂ«sohet. PĂ«rveç kĂ«saj, falĂ« integrimit tĂ« Microsoft Graph Security API, ju keni mundĂ«sinĂ« tĂ« lidhni feed-e tĂ« vetĂ« tuaj pĂ«r Threat Intelligence me Sentinel, duke pasuruar mundĂ«sitĂ« pĂ«r analizimin e incidenteve nĂ« cloud-in tuaj Azure. Mund tĂ« konstatoni se Azure Sentinel Ă«shtĂ« SIEM-i i parĂ« "nativ" qĂ« Ă«shtĂ« shfaqur pĂ«r ofruesit e cloud-it (tĂ« njĂ«jtit Splunk ose ELK, tĂ« cilat mund tĂ« vendosen nĂ« cloud, pĂ«r shembull, AWS, nĂ« fakt janĂ« zhvilluar nga ofrues tĂ« shĂ«rbimeve tradicionale cloud). Azure Sentinel dhe Security Center mund tĂ« quhen si SOC-i pĂ«r cloud-in Azure, dhe ato mund tĂ« mjaftojnĂ« pĂ«r ju (me disa rezervime) nĂ«se nuk keni mĂ« asnjĂ« infrastrukturĂ« dhe i keni transferuar tĂ« gjitha burimet tuaja kompjuterike nĂ« cloud dhe kjo do tĂ« ishte cloud Microsoft Azure.
MegjithatĂ«, pasi mundĂ«sitĂ« e integruara tĂ« Azure (edhe nĂ«se keni njĂ« abonim pĂ«r Sentinel) shpesh nuk janĂ« tĂ« mjaftueshme pĂ«r qĂ«llimet e monitorimit tĂ« sigurisĂ« sĂ« informacionit dhe integrimit tĂ« kĂ«tij procesi me burime tĂ« tjera tĂ« ngjarjeve tĂ« sigurisĂ« (si nĂ« cloud ashtu edhe brenda), lind nevoja pĂ«r eksportimin e tĂ« dhĂ«nave tĂ« mbledhura nĂ« sisteme tĂ« jashtme, tĂ« cilat mund tĂ« pĂ«rfshijnĂ« edhe SIEM. Kjo bĂ«het si nĂ«pĂ«rmjet API-ve, ashtu edhe me ndihmĂ«n e zgjatjeve speciale, tĂ« cilat aktualisht janĂ« nĂ« dispozicion vetĂ«m pĂ«r kĂ«to SIEM â Splunk (Azure Monitor Add-On pĂ«r Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight dhe ELK. SĂ« fundmi, kishte mĂ« shumĂ« SIEM tĂ« tillĂ«, por qĂ« nga 1 qershori 2019, Microsoft ndaloi mbĂ«shtetje pĂ«r Azure Log Integration Tool (AzLog), i cili nĂ« fillim tĂ« ekzistencĂ«s sĂ« Azure dhe nĂ« mungesĂ« tĂ« standardizimit tĂ« duhur tĂ« punĂ«s me log-et (Azure Monitor ende nuk kishte ekzistuar), lejonte lehtĂ«sisht integrimin e SIEM-ve tĂ« jashtme me cloud-in e Microsoft. Tani situata ka ndryshuar dhe Microsoft rekomandon platformĂ«n Azure Event Hub si mjetin kryesor tĂ« integrimit pĂ«r SIEM-tĂ« e tjerĂ«. ShumĂ« tashmĂ« kanĂ« realizuar njĂ« integrim tĂ« tillĂ«, por kini kujdes â ato mund tĂ« kapin jo tĂ« gjitha log-et e Azure, por vetĂ«m disa (shikoni nĂ« dokumentacionin pĂ«r SIEM-in tuaj).
Duke përfunduar një përmbledhje të shkurtër mbi Azure, dua të jap një rekomandim të përgjithshëm për këtë shërbim cloud - para se të pretendoni për funksionet e monitorimit të sigurisë në Azure, është e rëndësishme të konfiguroni me kujdes dhe ta provoni që ato funksionojnë siç është shkruar në dokumentacion dhe siç ju thanë konsultantët e Microsoft (sepse ata mund të kenë pikëpamje të ndryshme mbi funksionalitetin e funkcioneve të Azure). Nëse keni mundësi financiare, mund të nxirrni shumë të dobishme nga Azure në aspektin e monitorimit të sigurisë. Nëse ka burime të kufizuara, siç ndodh edhe me AWS, do t'ju duhet të mbështeteni vetëm në forcat tuaja dhe në të dhënat bruto që ju ofron Azure Monitor. Dhe mbani mend se shumë funksione monitorimi kanë kosto dhe është mirë të informoheni paraprakisht për politikën e çmimeve. Për shembull, mund të ruani të dhëna deri në 31 ditë deri në një maksimum prej 5 GB për klientin pa pagesë; tejkalimi i këtyre vlerave do t'ju kërkojë të shpenzoni shtesë (rreth 2+ dollarë për ruajtjen e çdo GB shtesë nga klienti dhe 0,1 dollarë për ruajtjen e 1 GB për çdo muaj të mëtejshëm). Puna me telemetrinë e aplikacioneve dhe metrikat gjithashtu mund të kërkojë fonde shtesë, ashtu si puna me alarmin dhe njoftimet (një limit i caktuar është në dispozicion pa pagesë, i cili mund të mos mjaftojë për nevojat tuaja).
Shembulli: Monitorimi i sigurisë në IaaS në bazë të Google Cloud Platform
Google Cloud Platform, krahasuar me AWS dhe Azure, duket si një i ri, por kjo është për një pjesë të mirë. Ndryshe nga AWS, i cili ka zhvilluar gradualisht mundësitë e tij, përfshirë ato mbrojtëse, GCP, si Azure, menaxhohet shumë më mirë në mënyrë centrale, çka ul numrin e gabimeve dhe kohën e implementimit në kompani. Në aspektin e sigurisë, GCP është, ndoshta befasueshëm, midis AWS dhe Azure. Ka gjithashtu një regjistrim të ngjarjeve të unifikuar për të gjithë organizatën, por ai nuk është i plotë. Disa funksione janë ende në fazën beta, por gradualisht ky defekt do të eliminohet dhe GCP do të bëhet një platformë më e pjekur në aspektin e monitorimit të sigurisë.
Instrumenti kryesor për regjistrimin e ngjarjeve në GCP është Stackdriver Logging (analog i Azure Monitor), që ju lejon të mbledhni ngjarje në mbarë infrastrukturën tuaj cloud (si dhe nga AWS). Nga pikëpamja e sigurisë në GCP, çdo organizatë, projekt ose dosje ka katër log-e regjistrimi:
- Admin Activity â pĂ«rmban tĂ« gjitha ngjarjet qĂ« lidhen me aksesin administrativ, si krijimi i njĂ« makine virtuale, ndryshimi i tĂ« drejtave tĂ« aksesit, etj. Ky log shkruhet gjithmonĂ«, pavarĂ«sisht dĂ«shirĂ«s tuaj dhe ruan tĂ« dhĂ«nat e tij pĂ«r 400 ditĂ«.
- Data Access â pĂ«rmban tĂ« gjitha ngjarjet qĂ« lidhen me punĂ«n me tĂ« dhĂ«nat nga pĂ«rdoruesit cloud (krijimi, ndryshimi, leximi, etj.). Sapo fillimisht, ky log nuk shkruhet, pasi volumi i tij rritet shumĂ« shpejt. PĂ«r kĂ«tĂ« arsye, koha e ruajtjes sĂ« tij Ă«shtĂ« vetĂ«m 30 ditĂ«. PĂ«r mĂ« tepĂ«r, nĂ« kĂ«tĂ« log nuk shkruhen tĂ« gjitha ngjarjet. P.sh., ngjarjet qĂ« lidhen me burimet e aksesueshme publikisht pĂ«r tĂ« gjithĂ« pĂ«rdoruesit ose ato qĂ« janĂ« tĂ« aksesueshme pa u identifikuar nĂ« GCP, nuk shkruhen nĂ« tĂ«.
- System Event â pĂ«rmban ngjarje sistemike qĂ« nuk lidhen me pĂ«rdoruesit, ose veprime tĂ« administratorit qĂ« ndryshon konfigurimin e burimeve cloud. Shkruhet gjithmonĂ« dhe ruhet pĂ«r 400 ditĂ«.
- Access Transparency â Ă«shtĂ« njĂ« shembull unik i log-ut tĂ« regjistrimit, i cili regjistron tĂ« gjitha veprimet e punonjĂ«sve tĂ« Google (por pĂ«r momentin jo pĂ«r tĂ« gjitha shĂ«rbimet GCP), tĂ« cilĂ«t qasen nĂ« infrastrukturĂ«n tuaj nĂ« kuadĂ«r tĂ« kryerjes sĂ« detyrave tĂ« tyre profesionale. Ky log ruhet pĂ«r 400 ditĂ« dhe nuk Ă«shtĂ« i aksesueshĂ«m pĂ«r çdo klient GCP, vetĂ«m nĂ« pĂ«rputhje me disa kushte (ose mbĂ«shtetje e nivelit Gold ose Platinum, ose praninĂ« e 4 roleve tĂ« caktuar brenda mbĂ«shtetjes korporative). NjĂ« funksion i ngjashĂ«m ka gjithashtu, p.sh., nĂ« Office 365 â Lockbox.
Shembulli i log-ut: Access Transparency
{
 insertId:  "abcdefg12345"
 jsonPayload: {
 @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
  principalOfficeCountry:  "SHBA"
  principalEmployingEntity:  "Google LLC"
  principalPhysicalLocationCountry:  "CA"
 }
 product: [
  0:  "Cloud Storage"
 ]
 reason: [
  detail:  "Numri i rastit: 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.comaccess_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"
}Q akses nĂ« log-et e pĂ«rmendura Ă«shtĂ« i mundshĂ«m nĂ« disa mĂ«nyra (afĂ«rsisht ashtu siç u shqyrtua mĂ« parĂ« me Azure dhe AWS) â pĂ«rmes ndĂ«rfaqes sĂ« Shikuesit tĂ« LogĂ«ve, pĂ«rmes API, pĂ«rmes Google Cloud SDK, ose pĂ«rmes faqes Aktiviteti tĂ« projektit tuaj, pĂ«r tĂ« cilin jeni tĂ« interesuar pĂ«r ngjarje. Po ashtu, ato mund tĂ« eksportohen nĂ« zgjidhje tĂ« jashtme pĂ«r analizĂ« tĂ« mĂ«tejshme. Kjo bĂ«het pĂ«rmes eksportimit tĂ« logĂ«ve nĂ« ruajtjen BigQuery ose Cloud Pub/Sub.
Përveç Stackdriver Logging, platforma GCP ofron gjithashtu funksionalitetin Stackdriver Monitoring, i cili lejon të gjurmoni metrika kyçe (performancën, qëndrueshmërinë, gjendjen e përgjithshme etj.) të shërbimeve dhe aplikacioneve në cloud. Të dhënat e përpunuara veçmas dhe vizualizuar mund të lehtësojnë identifikimin e problemeve në infrastrukturën tuaj cloud, përfshirë kontekstin e sigurisë. Por duhet të theksohet se ky funksionalitet nuk do të jetë shumë i pasur pikërisht në kontekstin e sigurisë kibernetike, pasi deri më sot GCP nuk ka një ekuivalent të AWS GuardDuty dhe nuk mund të veçojë mes të gjitha ngjarjeve të regjistruara ato që janë të këqija (Google zhvilloi Event Threat Detection, por për momentin është në beta dhe është herët për të folur për dobishmërinë e tij). Stackdriver Monitoring mund të përdoret si një sistem për zbuluar anomalitë, të cilat do të hetohen më pas për të gjetur shkakun e shfaqjes së tyre. Por në kushtet e mungesës së stafit të kualifikuar në fushën e sigurisë kibernetike në GCP, ky detyrë duket e vështirë për momentin.
Po ashtu, është e rëndësishme të përmendim një listë disa moduleve për sigurinë kibernetike, të cilat mund të aplikohen brenda cloud-it tuaj GCP dhe të cilat janë të ngjashme me ato që ofron AWS:
- Cloud Security Command Center â Ă«shtĂ« ekuivalenti i AWS Security Hub dhe Azure Security Center.
- Cloud DLP â zbulimi dhe redaktimi automatik (p.sh., maskimi) i tĂ« dhĂ«nave tĂ« vendosura nĂ« cloud, sipas mĂ« shumĂ« se 90 politikave tĂ« paracaktuar tĂ« klasifikimit.
- Cloud Scanner â skaneri i dobĂ«sive tĂ« njohura (XSS, Flash Injection, biblioteka tĂ« papatchuara etj.) nĂ« App Engine, Compute Engine dhe Google Kubernetes.
- Cloud IAM â menaxhimi i aksesit nĂ« tĂ« gjitha resurset e GCP.
- Cloud Identity â menaxhimi i llogarive tĂ« pĂ«rdoruesve, pajisjeve dhe aplikacioneve GCP nga njĂ« konsolĂ« e vetme.
- Cloud HSM â mbrojtja e çelĂ«save kriptografikĂ«.
- Cloud Key Management Service â menaxhimi i çelĂ«save kriptografikĂ« nĂ« GCP.
- VPC Service Control â krijimi i njĂ« perimetri tĂ« sigurt rreth resurseve tuaja GCP pĂ«r t'i mbrojtur ato nga rrjedhjet.
- Titan Security Key â mbrojtje kundĂ«r phishing.
Shumë nga këto module gjenerojnë ngjarje sigurie, të cilat mund të dërgohen në depozitin BigQuery për analizë ose eksport në sisteme të tjera, përfshirë edhe SIEM. Siç e përmendëm më sipër, GCP është një platformë që po zhvillohet aktivisht dhe tani Google po zhvillon një sërë modulash të rinj për sigurimin e informacionit për platformat e tij. Ndër to është Event Threat Detection (tani në beta), e cila skanon logët e Stackdriver për shenjat e aktivitetit të paautorizuar (analoge me GuardDuty në AWS), ose Policy Intelligence (në alfa), e cila do të lejojë zhvillimin e politikave inteligjente të aksesit në resurset e GCP.
Kam bërë një përmbledhje të vogël të mundësive të ndërtuara për monitorim në platformat e njohura cloud. Por a keni specialistë që mund të punojnë me logët 'të papërpunuara' të ofruesit IaaS (jo të gjithë janë të gatshëm të blejnë mundësi të avancuara nga AWS, Azure apo Google)? Për më tepër, një proverb i njohur thotë: 'beso, por kontrollo', e cila në fushën e sigurisë është më e vërtetë se kurrë. Sa besoni te mundësitë e ndërtuara të ofruesit cloud që ju japin ngjarje sigurie? Sa shumë përqendrohen ato në siguri?
Ndonjëherë është e dobishme të shqyrtohen zgjidhjet e jashtme për monitorimin e infrastrukturave në cloud, të cilat mund të plotësojnë sigurinë e ndërtuar në cloud, dhe herë pas here këto zgjidhje janë opsioni i vetëm për të marrë të dhëna mbi sigurinë e të dhënave dhe aplikacioneve tuaja të vendosura në cloud. Për më tepër, ato janë më të përshtatshme, pasi merret me të gjitha detyrat e analizës së log-ëve të nevojshme, të gjeneruara nga shërbime të ndryshme cloud nga ofrues të ndryshëm cloud. Një shembull i tillë i një zgjidhjeje të jashtme mund të jetë Cisco Stealthwatch Cloud, e cila fokusohet në një detyrë të vetme - monitorimin e anomalisë së sigurisë në mjediset cloud, të cilat përfshijnë jo vetëm Amazon AWS, Microsoft Azure dhe Google Cloud Platform, por edhe cloud privat.
Shembuj: Monitorimi i Sigurisë me Stealthwatch Cloud
AWS ofron një platformë fleksibile për përpunim, por kjo fleksibilitet sjell atë që kompanitë bëjnë më lehtë gabime që çojnë në probleme të sigurisë. Dhe modeli i ndarë i sigurisë vetëm e nxit këtë. Ekzekutimi në cloud i aplikacioneve me vulnerabilitete të panjohura (me ato të njohura mund të përballet, për shembull, AWS Inspector ose GCP Cloud Scanner), fjalëkalime të dobëta, konfigurime të pasakta, insajderë etj. Dhe të gjitha këto reflektohen në sjelljen e burimeve cloud, pas të cilave mund të monitorohet Cisco Stealthwatch Cloud, i cili është një sistem monitorimi të sigurisë dhe zbërthimi të sulmeve në cloud publik dhe privat.
Një nga veçoritë kyçe të Cisco Stealthwatch Cloud është aftësia për të modeluar entitete. Me të, mund të krijoni një model programor (dmth, një imitim pothuajse në kohë reale) të çdo burimi tuajin në cloud (pavarësisht nëse është AWS, Azure, GCP apo diçka tjetër). Këtu përfshihen serverët dhe përdoruesit, si dhe llojet e burimeve specifike për mjedisin tuaj cloud, si grupet e sigurisë dhe grupet e shërbimeve për auto-skalim. Këto modele përdorin si input rrjedha të dhënash të strukturuara, të ofruara nga shërbimet cloud. Për shembull, për AWS, këto do të ishin VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda dhe AWS IAM. Modelimi i entiteteve zbulon automatikisht rol dhe sjelljen e çdonjërit nga burimet tuaja (mund të flasim për profili i gjithë aktivitetit cloud). Ndër këto role janë: pajisja mobile Android ose Apple, serveri Citrix PVS, serveri RDP, gateway-i i postës, klienti VoIP, serveri terminal, kontrolluesi i domenit, etj. Pastaj, ai monitoron vazhdimisht sjelljen e tyre për të përcaktuar kur ndodh një sjellje e rrezikshme ose kërcënuese për sigurinë. Ju mund të identifikoni provat e fjalëkalimit, sulmet DDoS, rrjedhjet e të dhënave, aksesin e paligjshëm në distancë, veprimet e malware-it, skanimin e dobësive dhe kërcënime të tjera. Për shembull, ky është një shembull i zbulesës së një përpjekjeje për qasje të largët nga një vend i pazakontë për organizatën tuaj (Korea e Jugut) në një kluster Kubernetes përmes SSH:
Këtu është mënyra si duket një dyshim për rrjedhje informacioni nga databaza Postgress në një vend, me të cilin nuk është bërë ndonjëherë ndërveprim:
Së fundi, këtu është një shembull i numrit të madh të përpjekjeve të dështuara për qasje përmes SSH nga Kina dhe Indonezia nga një pajisje e largët:
Ose, supozoni se qĂ« njĂ« instancĂ« e serverit nĂ« VPC, sipas politikĂ«s, nuk duhet kurrĂ« tĂ« jetĂ« njĂ« destinacion pĂ«r hyrje tĂ« largĂ«t nĂ« sistem. Supozoni mĂ« tej se nĂ« kĂ«tĂ« kompjuter ka ndodhur njĂ« hyrje e largĂ«t pĂ«r shkak tĂ« njĂ« ndryshimi tĂ« gabuar tĂ« politikĂ«s sĂ« rregullave tĂ« firewall-it. Funksioni i modelimit tĂ« entiteteve do tĂ« zbulojĂ« dhe do tĂ« raportojĂ« kĂ«tĂ« aktivitet (âHyrje e pazakontĂ« nga largâ) nĂ« njĂ« kohĂ« reale pothuajse dhe do tĂ« tregojĂ« thirrjen specifike API nga AWS CloudTrail, Azure Monitor ose GCP Stackdriver Logging (duke pĂ«rfshirĂ« emrin e pĂ«rdoruesit, datĂ«n dhe orĂ«n, ndĂ«r detaje tĂ« tjera), tĂ« cilat shkaktuan ndryshimin nĂ« rregullin e MCSE. Pastaj, kĂ«to informacione mund tĂ« dĂ«rgohen nĂ« SIEM pĂ«r analizĂ«.
Aftësi të ngjashme realizohen për çdo ambient në re, të mbështetur nga Cisco Stealthwatch Cloud:
Modelimi i entiteteve është një formë unike e automatizimit të sigurisë, e cila mund të zbulojë një problem të panjohur më parë me njerëzit, proceset ose teknologjitë tuaja. Për shembull, ajo lejon të zbulojë ndër të tjera probleme sigurie si:
- A ka dikush zbuluar një backdoor në programin që ne përdorim?
- Ka ndonjë program ose pajisje të jashtme në re tonë?
- Apo abuzon përdoruesi i autorizuar me privilegjet?
- A është bërë një gabim konfigurimi që lejon hyrje të largët ose përdorim tjetër të paqëllimshëm të burimeve?
- A ka ndonjë rrjedhje të të dhënave nga serverët tanë?
- A po përpiqet ndonjë person të lidhet me ne nga një vend jo tipik gjeografik?
- A është reja jonë e infektuar me kode të dëmshme?
NjĂ« ngjarje e zbuluar e sigurisĂ« mund tĂ« dĂ«rgohet si njĂ« biletĂ« pĂ«rkatĂ«se nĂ« Slack, Cisco Spark, sistemin e menaxhimit tĂ« incidenteve PagerDuty, si dhe tĂ« dorĂ«zohet nĂ« disa SIEM, pĂ«rfshirĂ« Splunk ose ELK. NĂ« pĂ«rmbledhje, mund tĂ« thuhet se nĂ«se kompania juaj pĂ«rdor njĂ« strategji multi-cloud dhe nuk kufizohet nĂ« njĂ« ofrues tĂ« vetĂ«m tĂ« shĂ«rbimeve nĂ« re, mundĂ«sitĂ« pĂ«r monitorimin e sigurisĂ«, tĂ« cilat u pĂ«rmendĂ«n mĂ« lart, aplikimi i Cisco Stealthwatch Cloud Ă«shtĂ« njĂ« opsion i shkĂ«lqyer pĂ«r tĂ« marrĂ« njĂ« set tĂ« unifikuar tĂ« mundĂ«sive pĂ«r monitorimin e lojtarĂ«ve kryesorĂ« tĂ« cloud-it â Amazon, Microsoft dhe Google. E veçanta Ă«shtĂ« se nĂ«se krahasoni çmimet e Stealthwatch Cloud me licencat e avancuara pĂ«r monitorimin e sigurisĂ« nĂ« AWS, Azure ose GCP, mund tĂ« rezultojĂ« se zgjidhja e Cisco mund tĂ« jetĂ« madje mĂ« e lirĂ« se mundĂ«sitĂ« e ndĂ«rtuara nĂ« zgjidhjet e Amazon, Microsoft dhe Google. E çuditshme, por kĂ«shtu Ă«shtĂ«. Dhe sa mĂ« shumĂ« re dhe mundĂ«si tĂ« saj pĂ«rdorni, aq mĂ« e dukshme do tĂ« jetĂ« pĂ«rparĂ«sia e njĂ« zgjidhjeje tĂ« konsoliduar.
Për më tepër, Stealthwatch Cloud mund të monitorojë edhe re private që janë vendosur në organizatën tuaj, për shembull, duke u bazuar në kontejnerët Kubernetes ose duke monitoruar rrjedhat Netflow ose trafikun rrjetor që merret përmes pasqyrimit në pajisjet rrjetësore (edhe ato prodhim vendas), të dhënat AD ose serverët DNS etj. Të gjitha këto të dhëna do të pasurohen me informacionin Threat Intelligence, i mbledhur nga departamenti Cisco Talos, që është grupi më i madh në botë i kërkuesve të kërcënimeve të sigurisë.
Kjo ju lejon të realizoni një sistem të vetëm monitorimi për re publike dhe hibride që mund të përdorë kompania juaj. Informacioni i mbledhur mund të analizohet më pas duke përdorur mundësitë e integruara të Stealthwatch Cloud ose të dërgohet në SIEM-in tuaj (në mënyrë të paracaktuar mbështeten Splunk, ELK, SumoLogic dhe disa të tjera).
Me do këtë, ne do ta përfundojmë pjesën e parë të artikullit, ku shqyrtova mjetet e brendshme dhe të jashtme për monitorimin e sigurisë në platforma IaaS/PaaS, që na lejojnë të zbulojmë dhe reagojmë shpejt ndaj incidenteve që ndodhin në mjediset cloud që ka zgjedhur organizata jonë. Në pjesën e dytë do të vazhdojmë temën dhe do të shqyrtojmë mundësitë e monitorimit të platformave SaaS duke marrë si shembuj Salesforce dhe Dropbox, si dhe do të përpiqemi të përmbledhim dhe të mbledhim gjithçka së bashku duke krijuar një sistem të njëjtë monitorimi të sigurisë për ofrues të ndryshëm cloud.
Burimi: habr.com
