🥇Monitorimi i sigurisë në renë kompjuterike

Zhvendosja e të dhënave dhe aplikacioneve në cloud 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 njerëzve të tjerë. Sipas Netoskope, sipërmarrja mesatare (me sa duket në SHBA) përdor 1246 shërbime të ndryshme cloud, që është 22% më shumë se një vit më parë. 1246 shërbime cloud!!! 175 prej tyre kanë të bëjnë me shërbimet e burimeve njerëzore, 170 janë të lidhura me marketingun, 110 janë në fushën e komunikimit dhe 76 janë në financa dhe CRM. Cisco përdor "vetëm" 700 shërbime të jashtme cloud. Kështu që unë jam pak i hutuar nga këto shifra. Por në çdo rast, problemi nuk është tek ata, por tek fakti që cloud-i ka filluar të përdoret mjaft aktivisht nga një numër në rritje i kompanive që do të dëshironin të kishin të njëjtat aftësi për monitorimin e infrastrukturës cloud si në rrjetin e tyre. Dhe ky trend po rritet - sipas sipas Dhomës Amerikane të Llogarive Deri në vitin 2023, 1200 qendra të të dhënave do të mbyllen në Shtetet e Bashkuara (6250 tashmë janë mbyllur). Por kalimi në cloud nuk është vetëm "le t'i zhvendosim serverët tanë te një ofrues i jashtëm". Arkitekturë e re IT, softuer të ri, procese të reja, kufizime të reja... E gjithë kjo sjell ndryshime të rëndësishme në punën jo vetëm të IT-së, por edhe në sigurinë e informacionit. Dhe nëse ofruesit kanë mësuar të përballen disi me sigurimin e vetë cloud (për fat të mirë ka shumë rekomandime), atëherë me monitorimin e sigurisë së informacionit në cloud, veçanërisht në platformat SaaS, ka vështirësi të konsiderueshme, për të cilat do të flasim.

Le të themi se kompania juaj ka zhvendosur një pjesë të infrastrukturës së saj në renë kompjuterike... Ndalo. Jo në këtë mënyrë. Nëse infrastruktura është transferuar, dhe vetëm tani po mendoni se si do ta monitoroni, atëherë tashmë keni humbur. Nëse nuk është Amazon, Google ose Microsoft (dhe më pas me rezervime), ndoshta nuk do të keni shumë aftësi për të monitoruar të dhënat dhe aplikacionet tuaja. Është mirë nëse ju jepet mundësia të punoni me shkrime. Ndonjëherë të dhënat e ngjarjeve të sigurisë do të jenë të disponueshme, por ju nuk do të keni qasje në to. Për shembull, Office 365. Nëse keni licencën më të lirë E1, atëherë ngjarjet e sigurisë nuk janë fare të disponueshme për ju. Nëse keni një licencë E3, të dhënat tuaja ruhen vetëm për 90 ditë, dhe vetëm nëse keni një licencë E5, kohëzgjatja e regjistrave është e disponueshme për një vit (megjithatë, kjo gjithashtu ka nuancat e veta që lidhen me nevojën për të ndarë kërkoni një numër funksionesh për të punuar me regjistrat nga mbështetja e Microsoft). Nga rruga, licenca E3 është shumë më e dobët për sa i përket funksioneve të monitorimit sesa Exchange e korporatave. Për të arritur të njëjtin nivel, ju nevojitet një licencë E5 ose një licencë shtesë e Përputhshmërisë së Avancuar, e cila mund të kërkojë para shtesë që nuk janë përfshirë në modelin tuaj financiar për të kaluar në infrastrukturën cloud. Dhe ky është vetëm një shembull i nënvlerësimit të çështjeve që lidhen me monitorimin e sigurisë së informacionit në cloud. Në këtë artikull, pa pretenduar se jam i plotë, dua të tërheq vëmendjen për disa nuanca që duhet të merren parasysh kur zgjidhni një ofrues cloud nga pikëpamja e sigurisë. Dhe në fund të artikullit do të jepet një listë kontrolli që ia vlen të plotësohet përpara se të merret parasysh se çështja e monitorimit të sigurisë së informacionit në cloud është zgjidhur.

Ka disa probleme tipike që çojnë në incidente në mjediset cloud, të cilave shërbimet e sigurisë së informacionit nuk kanë kohë për t'u përgjigjur ose nuk i shohin fare:

Regjistrat e sigurisë nuk ekzistojnë. Kjo është një situatë mjaft e zakonshme, veçanërisht midis lojtarëve fillestarë në tregun e zgjidhjeve cloud. Por ju nuk duhet të hiqni dorë prej tyre menjëherë. Lojtarët e vegjël, veçanërisht ata vendas, janë më të ndjeshëm ndaj kërkesave të klientëve dhe mund të zbatojnë shpejt disa funksione të kërkuara duke ndryshuar udhërrëfyesin e miratuar për produktet e tyre. Po, ky nuk do të jetë një analog i GuardDuty nga Amazon ose moduli "Proactive Protection" nga Bitrix, por të paktën diçka.
Siguria e informacionit nuk e di se ku ruhen regjistrat ose nuk ka qasje në to. Këtu është e nevojshme të hyni në negociata me ofruesin e shërbimit cloud - mbase ai do të japë një informacion të tillë nëse e konsideron klientin të rëndësishëm për të. Por në përgjithësi, nuk është shumë mirë kur qasja në regjistra sigurohet "me vendim të veçantë".
Ndodh gjithashtu që ofruesi i cloud të ketë regjistra, por ato ofrojnë monitorim dhe regjistrim të kufizuar të ngjarjeve, të cilat nuk janë të mjaftueshme për të zbuluar të gjitha incidentet. Për shembull, ju mund të merrni vetëm regjistrat e ndryshimeve në një faqe interneti ose regjistrat e përpjekjeve për vërtetimin e përdoruesve, por jo ngjarje të tjera, si trafiku i rrjetit, i cili do të fshehë nga ju një shtresë të tërë ngjarjesh që karakterizojnë përpjekjet për të hakuar infrastrukturën tuaj cloud.
Ka regjistra, por aksesi në to është i vështirë për t'u automatizuar, gjë që i detyron ata të monitorohen jo vazhdimisht, por në një orar. Dhe nëse nuk mund t'i shkarkoni automatikisht regjistrat, atëherë shkarkimi i regjistrave, për shembull, në formatin Excel (si me një numër ofruesish vendas të zgjidhjeve cloud), madje mund të çojë në një hezitim nga ana e shërbimit të sigurisë së informacionit të korporatës për t'i ndërhyrë me to.
Asnjë monitorim i regjistrave. Kjo është ndoshta arsyeja më e paqartë për shfaqjen e incidenteve të sigurisë së informacionit në mjediset cloud. Duket se ka regjistra dhe është e mundur të automatizosh qasjen në to, por askush nuk e bën këtë. Pse?

Koncepti i përbashkët i sigurisë së resë kompjuterike

Kalimi në cloud është gjithmonë një kërkim për një ekuilibër midis dëshirës për të mbajtur kontrollin mbi infrastrukturën dhe transferimit të tij në duart më profesionale të një ofruesi të reve kompjuterike i cili është i specializuar në mirëmbajtjen e tij. Dhe në fushën e sigurisë së cloud, ky balancë duhet kërkuar gjithashtu. Për më tepër, në varësi të modelit të ofrimit të shërbimit cloud të përdorur (IaaS, PaaS, SaaS), ky bilanc do të jetë i ndryshëm gjatë gjithë kohës. Në çdo rast, duhet të kujtojmë se të gjithë ofruesit e cloud sot ndjekin të ashtuquajturin modelin e përgjegjësisë së përbashkët dhe të sigurisë së informacionit të përbashkët. cloud është përgjegjës për disa gjëra, dhe për të tjera klienti është përgjegjës, duke vendosur të dhënat e tij, aplikacionet e tij, makinat e tij virtuale dhe burime të tjera në cloud. Do të ishte e pamatur të presim që duke shkuar në renë kompjuterike, ne do t'ia kalojmë të gjithë përgjegjësinë ofruesit. Por nuk është gjithashtu e mençur të ndërtoni të gjithë sigurinë vetë kur lëvizni në re. Kërkohet një bilanc, i cili do të varet nga shumë faktorë: - strategjia e menaxhimit të rrezikut, modeli i kërcënimit, mekanizmat e sigurisë në dispozicion të ofruesit të cloud, legjislacioni, etj.

Për shembull, klasifikimi i të dhënave të pritura në cloud është gjithmonë përgjegjësi e klientit. Një ofrues i resë kompjuterike ose një ofrues i jashtëm shërbimi mund ta ndihmojë atë vetëm me mjete që do të ndihmojnë në shënimin e të dhënave në re, identifikimin e shkeljeve, fshirjen e të dhënave që shkelin ligjin ose maskimin e tyre duke përdorur një metodë ose një tjetër. Nga ana tjetër, siguria fizike është gjithmonë përgjegjësi e ofruesit të cloud, të cilin ai nuk mund ta ndajë me klientët. Por gjithçka që është midis të dhënave dhe infrastrukturës fizike është pikërisht objekt diskutimi në këtë artikull. Për shembull, disponueshmëria e resë kompjuterike është përgjegjësi e ofruesit, dhe vendosja e rregullave të murit të zjarrit ose aktivizimi i enkriptimit është përgjegjësi e klientit. Në këtë artikull do të përpiqemi të shikojmë se cilat mekanizma të monitorimit të sigurisë së informacionit ofrohen sot nga ofrues të ndryshëm të njohur të cloud në Rusi, cilat janë tiparet e përdorimit të tyre dhe kur ia vlen të shikojmë drejt zgjidhjeve të mbivendosjes së jashtme (për shembull, Cisco E- mail Security) që zgjerojnë aftësitë e resë suaj në drejtim të sigurisë kibernetike. Në disa raste, veçanërisht nëse jeni duke ndjekur një strategji me shumë re, nuk do të keni zgjidhje tjetër veçse të përdorni zgjidhje të jashtme të monitorimit të sigurisë së informacionit në disa mjedise cloud menjëherë (për shembull, Cisco CloudLock ose Cisco Stealthwatch Cloud). Epo, në disa raste do të kuptoni se ofruesi i resë kompjuterike që keni zgjedhur (ose ju imponuar) nuk ofron fare aftësi monitorimi të sigurisë së informacionit. Kjo është e pakëndshme, por edhe jo pak, pasi ju lejon të vlerësoni në mënyrë adekuate nivelin e rrezikut që lidhet me punën me këtë re.

Cikli i jetës së monitorimit të sigurisë në renë kompjuterike

Për të monitoruar sigurinë e reve që përdorni, keni vetëm tre opsione:

mbështetuni në mjetet e ofruara nga ofruesi juaj i cloud,
përdorni zgjidhje nga palë të treta që do të monitorojnë platformat IaaS, PaaS ose SaaS që përdorni,
ndërtoni infrastrukturën tuaj të monitorimit të cloud (vetëm për platformat IaaS/PaaS).

Le të shohim se cilat veçori ka secila prej këtyre opsioneve. Por së pari, ne duhet të kuptojmë kornizën e përgjithshme që do të përdoret gjatë monitorimit të platformave cloud. Do të theksoja 6 komponentë kryesorë të procesit të monitorimit të sigurisë së informacionit në cloud:

Përgatitja e infrastrukturës. Përcaktimi i aplikacioneve dhe infrastrukturës së nevojshme për mbledhjen e ngjarjeve të rëndësishme për sigurinë e informacionit në ruajtje.
Mbledhja. Në këtë fazë, ngjarjet e sigurisë grumbullohen nga burime të ndryshme për transmetim të mëvonshëm për përpunim, ruajtje dhe analizë.
Mjekimi. Në këtë fazë, të dhënat transformohen dhe pasurohen për të lehtësuar analizën e mëvonshme.
Magazinimi. 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ë, ju keni mundësinë të zbuloni incidente dhe t'u përgjigjeni atyre automatikisht ose manualisht.
Raportimi. Kjo fazë ndihmon në formulimin e treguesve kryesorë për palët e interesuara (menaxhimi, auditorët, ofruesi i cloud, klientët, etj.) që na ndihmojnë të marrim vendime të caktuara, për shembull, ndryshimi i një ofruesi ose forcimi i sigurisë së informacionit.

Kuptimi i këtyre komponentëve do t'ju lejojë të vendosni shpejt në të ardhmen se çfarë mund të merrni nga ofruesi juaj dhe çfarë do të duhet të bëni vetë ose me përfshirjen e konsulentëve të jashtëm.

Shërbimet e integruara në renë kompjuterike

Tashmë kam shkruar më lart se shumë shërbime cloud sot nuk ofrojnë asnjë aftësi monitorimi të sigurisë së informacionit. Në përgjithësi, ata nuk i kushtojnë shumë vëmendje temës së sigurisë së informacionit. Për shembull, një nga shërbimet e njohura ruse për dërgimin e raporteve tek agjencitë qeveritare përmes Internetit (nuk do ta përmend në mënyrë specifike emrin e tij). I gjithë seksioni për sigurinë e këtij shërbimi sillet rreth përdorimit të CIPF të certifikuar. Seksioni i sigurisë së informacionit i një shërbimi tjetër të brendshëm cloud për menaxhimin e dokumenteve elektronike nuk është i ndryshëm. Ai flet për certifikatat e çelësit publik, kriptografinë e certifikuar, eliminimin e dobësive të uebit, mbrojtjen kundër sulmeve DDoS, përdorimin e mureve të zjarrit, kopjet rezervë dhe madje edhe auditimet e rregullta të sigurisë së informacionit. Por nuk flitet asnjë fjalë për monitorimin dhe as për mundësinë e aksesit në ngjarjet e sigurisë së informacionit që mund të jenë me interes për klientët e këtij ofruesi të shërbimit.

Në përgjithësi, nga mënyra se si ofruesi i cloud përshkruan çështjet e sigurisë së informacionit në faqen e tij të internetit dhe në dokumentacionin e tij, mund të kuptoni se sa seriozisht e merr këtë çështje. Për shembull, nëse lexoni manualet për produktet "My Office", nuk ka asnjë fjalë për sigurinë, por në dokumentacionin për produktin e veçantë "My Office". KS3”, i krijuar për të mbrojtur nga aksesi i paautorizuar, ekziston një listë e zakonshme e pikave të rendit të 17-të të FSTEC, të cilat i zbaton "My Office.KS3", por nuk përshkruhet se si e zbaton atë dhe, më e rëndësishmja, si integrimin e këtyre mekanizmave me sigurinë e informacionit të korporatës. Ndoshta një dokumentacion i tillë ekziston, por nuk e gjeta në domenin publik, në faqen e internetit “Zyra ime”. Edhe pse ndoshta thjesht nuk kam akses në këtë informacion sekret?..

Për Bitrix, situata është shumë më e mirë. Dokumentacioni përshkruan formatet e regjistrave të ngjarjeve dhe, interesant, regjistrin e ndërhyrjeve, i cili përmban ngjarje që lidhen me kërcënimet e mundshme për platformën cloud. Nga atje mund të nxirrni IP-në, emrin e përdoruesit ose të ftuarit, burimin e ngjarjes, kohën, agjentin e përdoruesit, llojin e ngjarjes, etj. Vërtetë, ju mund të punoni me këto ngjarje ose nga paneli i kontrollit të vetë cloud, ose të ngarkoni të dhëna në formatin MS Excel. Tani është e vështirë të automatizosh punën me regjistrat e Bitrix dhe do t'ju duhet të bëni një pjesë të punës me dorë (duke ngarkuar raportin dhe ngarkuar atë në SIEM tuaj). Por nëse kujtojmë se deri relativisht vonë një mundësi e tillë nuk ekzistonte, atëherë ky është përparim i madh. Në të njëjtën kohë, dëshiroj të vërej se shumë ofrues të huaj të cloud ofrojnë funksione të ngjashme "për fillestarët" - ose shikoni regjistrat me sytë tuaj përmes panelit të kontrollit, ose ngarkoni të dhënat tek vetja (megjithatë, shumica e të dhënave ngarkojnë në . format csv, jo Excel).

Pa marrë parasysh opsionin pa regjistrime, ofruesit e cloud zakonisht ju ofrojnë tre opsione për monitorimin e ngjarjeve të sigurisë - panelet e kontrollit, ngarkimin e të dhënave dhe aksesin në API. E para duket se ju zgjidh shumë probleme, por kjo nuk është plotësisht e vërtetë - nëse keni disa revista, duhet të kaloni midis ekraneve që i shfaqin ato, duke humbur pamjen e përgjithshme. Përveç kësaj, ofruesi i resë kompjuterike nuk ka gjasa t'ju ofrojë aftësinë për të lidhur ngjarjet e sigurisë dhe në përgjithësi t'i analizoni ato nga pikëpamja e sigurisë (zakonisht keni të bëni me të dhëna të papërpunuara, të cilat duhet t'i kuptoni vetë). Ka përjashtime dhe ne do të flasim për to më tej. Së fundi, ia vlen të pyesni se cilat ngjarje regjistrohen nga ofruesi juaj i resë kompjuterike, në çfarë formati dhe si korrespondojnë ato me procesin tuaj të monitorimit të sigurisë së informacionit? Për shembull, identifikimi dhe vërtetimi i përdoruesve dhe të ftuarve. I njëjti Bitrix ju lejon, bazuar në këto ngjarje, të regjistroni datën dhe orën e ngjarjes, emrin e përdoruesit ose të ftuarit (nëse keni modulin "Web Analytics"), objektin e aksesuar dhe elementë të tjerë tipikë për një faqe interneti. . Por shërbimet e sigurisë së informacionit të korporatës mund të kenë nevojë për informacion nëse përdoruesi ka akses në renë kompjuterike nga një pajisje e besuar (për shembull, në një rrjet të korporatës kjo detyrë zbatohet nga Cisco ISE). Po në lidhje me një detyrë kaq të thjeshtë si funksioni gjeo-IP, i cili do të ndihmojë në përcaktimin nëse një llogari e përdoruesit të shërbimit cloud është vjedhur? Dhe edhe nëse ofruesi i reve kompjuterike jua ofron, kjo nuk mjafton. I njëjti Cisco CloudLock nuk analizon vetëm vendndodhjen gjeografike, por përdor mësimin e makinerive për këtë dhe analizon të dhënat historike për secilin përdorues dhe monitoron anomali të ndryshme në përpjekjet për identifikimin dhe vërtetimin. Vetëm MS Azure ka funksionalitet të ngjashëm (nëse keni pajtimin e duhur).

Ekziston një vështirësi tjetër - pasi për shumë ofrues të cloud, monitorimi i sigurisë së informacionit është një temë e re me të cilën ata sapo kanë filluar të merren, ata vazhdimisht po ndryshojnë diçka në zgjidhjet e tyre. Sot ata kanë një version të API-së, nesër një tjetër, pasnesër një të tretën. Ju gjithashtu duhet të jeni të përgatitur për këtë. E njëjta gjë është e vërtetë me funksionalitetin, i cili mund të ndryshojë, gjë që duhet të merret parasysh në sistemin tuaj të monitorimit të sigurisë së informacionit. Për shembull, Amazon fillimisht kishte shërbime të veçanta të monitorimit të ngjarjeve në cloud - AWS CloudTrail dhe AWS CloudWatch. Pastaj u shfaq një shërbim i veçantë për monitorimin e ngjarjeve të sigurisë së informacionit - AWS GuardDuty. Pas ca kohësh, Amazon lançoi një sistem të ri menaxhimi, 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ë regjistrave Azure me SIEM - AzLog. Ai u përdor në mënyrë aktive nga shumë shitës SIEM, derisa në vitin 2018 Microsoft njoftoi ndërprerjen e zhvillimit dhe mbështetjes së tij, gjë që përballoi me një problem shumë klientë që përdornin këtë mjet (ne do të flasim për mënyrën se si u zgjidh më vonë).

Prandaj, monitoroni me kujdes të gjitha veçoritë e monitorimit që ju ofron ofruesi juaj i cloud. Ose mbështetuni te ofruesit e jashtëm të zgjidhjeve që do të veprojnë si ndërmjetës midis SOC tuaj dhe cloud që dëshironi të monitoroni. Po, do të jetë më e shtrenjtë (edhe pse jo gjithmonë), por ju do ta zhvendosni të gjithë përgjegjësinë mbi supet e dikujt tjetër. Apo jo të gjitha?.. Le të kujtojmë konceptin e sigurisë së përbashkët dhe të kuptojmë se nuk mund të zhvendosim asgjë - do të duhet të kuptojmë në mënyrë të pavarur se si ofruesit e ndryshëm të cloud ofrojnë monitorim të sigurisë së informacionit të të dhënave tuaja, aplikacioneve, makinave virtuale dhe burimeve të tjera të pritur në re. Dhe ne do të fillojmë me atë që Amazon ofron në këtë pjesë.

Shembull: Monitorimi i sigurisë së informacionit në IaaS bazuar në AWS

Po, po, e kuptoj që Amazon nuk është shembulli më i mirë për faktin se ky është një shërbim amerikan dhe mund të bllokohet si pjesë e luftës kundër ekstremizmit dhe shpërndarjes së informacionit të ndaluar në Rusi. Por në këtë botim do të doja vetëm të tregoja se si ndryshojnë platformat e ndryshme cloud në aftësitë e tyre të monitorimit të sigurisë së informacionit dhe çfarë duhet t'i kushtoni vëmendje kur transferoni proceset tuaja kryesore në retë nga pikëpamja e sigurisë. Epo, nëse disa nga zhvilluesit rusë të zgjidhjeve cloud mësojnë diçka të dobishme për veten e tyre, atëherë kjo do të jetë e mrekullueshme.

Gjëja e parë që duhet thënë është se Amazona nuk është një kështjellë e padepërtueshme. Klientëve të tij ndodhin rregullisht incidente të ndryshme. Për shembull, emrat, adresat, datat e lindjes dhe numrat e telefonit të 198 milionë votuesve u vodhën nga Deep Root Analytics. Kompania izraelite Nice Systems vodhi 14 milionë regjistrime të abonentëve të Verizon. Sidoqoftë, aftësitë e integruara të AWS ju lejojnë të zbuloni një gamë të gjerë incidentesh. Për shembull:

ndikimi në infrastrukturë (DDoS)
kompromisi i nyjeve (injeksion i komandës)
komprometimi i llogarisë dhe aksesi i paautorizuar
konfigurim të pasaktë dhe dobësi
ndërfaqe të pasigurta dhe API.

Kjo mospërputhje është për faktin se, siç kemi kuptuar më lart, vetë klienti është përgjegjës për sigurinë e të dhënave të klientit. Dhe nëse nuk ka marrë mundimin për të ndezur mekanizmat mbrojtës dhe nuk ka ndezur mjetet e monitorimit, atëherë incidentin do ta mësojë vetëm nga mediat ose nga klientët e tij.

Për të identifikuar incidentet, mund të përdorni një gamë të gjerë shërbimesh të ndryshme monitorimi të zhvilluara nga Amazon (edhe pse këto shpesh plotësohen nga mjete të jashtme si osquery). Pra, në AWS, të gjitha veprimet e përdoruesit monitorohen, pavarësisht se si kryhen - përmes tastierës së menaxhimit, linjës së komandës, SDK ose shërbimeve të tjera AWS. Të gjitha të dhënat e aktivitetit të çdo llogarie AWS (përfshirë emrin e përdoruesit, veprimin, shërbimin, parametrat e aktivitetit dhe rezultatin) dhe përdorimin e API-së janë të disponueshme përmes AWS CloudTrail. Ju mund t'i shikoni këto ngjarje (të tilla si hyrjet e konsolës AWS IAM) nga tastiera CloudTrail, t'i analizoni ato duke përdorur Amazon Athena ose t'i "kontraktoni" ato në zgjidhje të jashtme si Splunk, AlienVault, etj. Vetë regjistrat e AWS CloudTrail vendosen në kovën tuaj AWS S3.

Dy shërbime të tjera AWS ofrojnë një sërë aftësish të tjera të rëndësishme monitorimi. Së pari, Amazon CloudWatch është një shërbim monitorimi për burimet dhe aplikacionet AWS që, ndër të tjera, ju lejon të identifikoni anomali të ndryshme në cloud tuaj. Të gjitha shërbimet e integruara AWS, të tilla si Amazon Elastic Compute Cloud (serverët), Shërbimi i bazës së të dhënave Relacionale të Amazon (bazat e të dhënave), Amazon Elastic MapReduce (analiza e të dhënave) dhe 30 shërbime të tjera të Amazon, përdorin Amazon CloudWatch për të ruajtur regjistrat e tyre. Zhvilluesit mund të përdorin API-në e hapur nga Amazon CloudWatch për të shtuar funksionalitetin e monitorimit të regjistrave në aplikacionet dhe shërbimet e personalizuara, duke i lejuar ata të zgjerojnë fushën e analizës së ngjarjeve brenda një konteksti sigurie.

Së dyti, shërbimi VPC Flow Logs ju lejon të analizoni trafikun e rrjetit të dërguar ose të marrë nga serverët tuaj AWS (jashtë ose brenda), si dhe midis mikroshërbimeve. Kur ndonjë nga burimet tuaja AWS VPC ndërvepron me rrjetin, regjistrat e rrjedhës së VPC regjistrojnë detaje rreth trafikut të rrjetit, duke përfshirë ndërfaqen e rrjetit të burimit dhe destinacionit, si dhe adresat IP, portet, protokollin, numrin e bajteve dhe numrin e paketave që ju pa. Ata që kanë përvojë me sigurinë e rrjetit lokal do ta njohin këtë si të ngjashme me temat NetFlow, të cilat mund të krijohen nga çelsat, ruterat dhe muret e zjarrit të shkallës së ndërmarrjes. Këto regjistra janë të rëndësishëm për qëllime të monitorimit të sigurisë së informacionit, sepse, ndryshe nga ngjarjet në lidhje me veprimet e përdoruesve dhe aplikacioneve, ato gjithashtu ju lejojnë të mos humbisni ndërveprimet e rrjetit në mjedisin virtual privat të cloud AWS.

Si përmbledhje, këto tre shërbime AWS - AWS CloudTrail, Amazon CloudWatch dhe VPC Flow Logs - së bashku ofrojnë një pasqyrë mjaft të fuqishme në përdorimin e llogarisë suaj, sjelljen e përdoruesit, menaxhimin e infrastrukturës, aktivitetin e aplikacioneve dhe shërbimeve dhe aktivitetin e rrjetit. Për shembull, ato mund të përdoren për të zbuluar anomalitë e mëposhtme:

Përpjekjet për të skanuar sitin, për të kërkuar për dyer të pasme, për të kërkuar për dobësi përmes shpërthimeve të "gabimeve 404".
Sulmet e injektimit (për shembull, injeksioni SQL) përmes shpërthimeve të "500 gabimeve".
Mjetet e njohura të sulmit janë sqlmap, nikto, w3af, nmap, etj. përmes analizës së fushës Agjenti i përdoruesit.

Amazon Web Services ka zhvilluar gjithashtu shërbime të tjera për qëllime të sigurisë kibernetike që ju lejojnë të zgjidhni shumë probleme të tjera. Për shembull, AWS ka një shërbim të integruar për auditimin e politikave dhe konfigurimeve - AWS Config. Ky shërbim ofron auditim të vazhdueshëm të burimeve tuaja AWS dhe konfigurimeve të tyre. Le të marrim një shembull të thjeshtë: Le të themi se dëshironi të siguroheni që fjalëkalimet e përdoruesve janë të çaktivizuar në të gjithë serverët tuaj dhe se aksesi është i mundur vetëm në bazë të certifikatave. AWS Config e bën të lehtë kontrollimin e kësaj për të gjithë serverët tuaj. Ka politika të tjera që mund të zbatohen në serverët tuaj cloud: "Asnjë server nuk mund të përdorë portin 22", "Vetëm administratorët mund të ndryshojnë rregullat e murit të zjarrit" 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 zbulimin e shkeljeve të politikave të zhvilluara. Rregullat e konfigurimit AWS janë në thelb kërkesa të vazhdueshme konfigurimi për shërbimet e Amazon që përdorni, të cilat gjenerojnë ngjarje nëse shkelen politikat përkatëse. Për shembull, në vend që të ekzekutohen periodikisht pyetjet e AWS Config për të verifikuar që të gjithë disqet në një server virtual janë të koduar, Rregullat e konfigurimit AWS mund të përdoren për të kontrolluar vazhdimisht disqet e serverit për të siguruar që ky kusht plotësohet. Dhe, më e rëndësishmja, në kontekstin e këtij publikimi, çdo shkelje gjeneron ngjarje që mund të analizohen nga shërbimi juaj i sigurisë së informacionit.

AWS gjithashtu ka ekuivalentin e tij me zgjidhjet tradicionale të sigurisë së informacionit të korporatës, të cilat gjenerojnë gjithashtu ngjarje sigurie që mund dhe duhet t'i analizoni:

Zbulimi i ndërhyrjeve - AWS GuardDuty
Kontrolli i rrjedhjes së informacionit - AWS Macie
EDR (megjithëse flet për pikat fundore në re paksa çuditërisht) - AWS Cloudwatch + osquery me burim të hapur ose zgjidhje GRR
Analiza Netflow - AWS Cloudwatch + AWS VPC Flow
Analiza DNS - AWS Cloudwatch + AWS Route53
AD - Shërbimi i Drejtorisë AWS
Menaxhimi i Llogarisë - AWS IAM
SSO - AWS SSO
analiza e sigurisë - Inspektori AWS
menaxhimi i konfigurimit - AWS Config
WAF - AWS WAF.

Unë nuk do të përshkruaj në detaje të gjitha shërbimet e Amazon që mund të jenë të dobishme në kontekstin e sigurisë së informacionit. Gjëja kryesore është të kuptojmë se të gjitha ato mund të gjenerojnë ngjarje që ne mund dhe duhet t'i analizojmë në kontekstin e sigurisë së informacionit, duke përdorur për këtë qëllim si aftësitë e integruara të vetë Amazon ashtu edhe zgjidhjet e jashtme, për shembull, SIEM, të cilat mund të çojini ngjarjet e sigurisë në qendrën tuaj të monitorimit dhe analizojini atje së bashku me ngjarjet nga shërbimet e tjera cloud ose nga infrastruktura e brendshme, perimetri ose pajisjet celulare.

Në çdo rast, gjithçka fillon me burimet e të dhënave që ju ofrojnë ngjarje të sigurisë së informacionit. Këto burime përfshijnë, por nuk kufizohen vetëm në:

CloudTrail - Përdorimi i API dhe Veprimet e Përdoruesit
Këshilltar i besuar - kontrolli i sigurisë ndaj praktikave më të mira
Konfigurimi - inventari dhe konfigurimi i llogarive dhe cilësimet e shërbimit
Regjistrat e rrjedhës së VPC - lidhjet me ndërfaqet virtuale
IAM - shërbim identifikimi dhe vërtetimi
Regjistrat e aksesit ELB - Balancuesi i ngarkesës
Inspektori - dobësitë e aplikacionit
S3 - ruajtja e skedarëve
CloudWatch - Aktiviteti i aplikacionit
SNS është një shërbim njoftimi.

Amazon, ndërkohë që ofron një gamë të tillë burimesh dhe mjetesh ngjarjesh për gjenerimin e tyre, është shumë e kufizuar në aftësinë e saj për të analizuar të dhënat e mbledhura në kontekstin e sigurisë së informacionit. Ju do të duhet të studioni në mënyrë të pavarur regjistrat e disponueshëm, duke kërkuar tregues përkatës të kompromisit në to. AWS Security Hub, të cilin Amazon e lançoi së fundmi, synon të zgjidhë këtë problem duke u bërë një SIEM cloud për AWS. Por deri më tani ai është vetëm në fillim të rrugëtimit të tij dhe është i kufizuar si nga numri i burimeve me të cilat punon ashtu edhe nga kufizimet e tjera të vendosura nga arkitektura dhe abonimet e vetë Amazon.

Shembull: Monitorimi i sigurisë së informacionit në IaaS bazuar në Azure

Nuk dua të futem në një debat të gjatë se cili nga tre ofruesit e cloud (Amazon, Microsoft ose Google) është më i mirë (veçanërisht pasi secili prej tyre ka ende specifikat e veta specifike dhe është i përshtatshëm për zgjidhjen e problemeve të veta); Le të përqendrohemi në aftësitë e monitorimit të sigurisë së informacionit që ofrojnë këta lojtarë. Duhet pranuar se Amazon AWS ishte një nga të parët në këtë segment dhe për këtë arsye ka avancuar më së shumti për sa i përket funksioneve të sigurisë së informacionit (edhe pse shumë e pranojnë se ato janë të vështira për t'u përdorur). Por kjo nuk do të thotë se ne do të shpërfillim mundësitë që na ofrojnë Microsoft dhe Google.

Produktet e Microsoft janë dalluar gjithmonë për "hapjen" e tyre dhe në Azure situata është e ngjashme. Për shembull, nëse AWS dhe GCP gjithmonë rrjedhin nga koncepti "ajo që nuk lejohet është e ndaluar", atëherë Azure ka qasjen e saktë të kundërt. Për shembull, kur krijoni një rrjet virtual në cloud dhe një makinë virtuale në të, të gjitha portet 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ë hyrjes në cloud nga Microsoft. Dhe kjo gjithashtu imponon kërkesa më të rrepta për ju për sa i përket monitorimit të aktivitetit në renë Azure.

AWS ka një veçori që lidhet me faktin se kur monitoroni burimet tuaja virtuale, nëse ato ndodhen në rajone të ndryshme, atëherë keni vështirësi në ndërthurjen e të gjitha ngjarjeve dhe analizën e tyre të unifikuar, për të eliminuar të cilat duhet t'i drejtoheni trukeve të ndryshme, si p.sh. Krijoni kodin tuaj për AWS Lambda që do të transportojë ngjarje midis rajoneve. Azure nuk e ka këtë problem - mekanizmi i tij i Regjistrimit të Aktivitetit gjurmon të gjithë aktivitetin në të gjithë organizatën pa kufizime. E njëjta gjë vlen edhe për AWS Security Hub, i cili u zhvillua së fundmi nga Amazon për të konsoliduar shumë funksione sigurie brenda një qendre të vetme sigurie, por vetëm brenda rajonit të tij, i cili, megjithatë, nuk është i rëndësishëm për Rusinë. Azure ka Qendrën e vet të Sigurisë, e cila nuk është e kufizuar nga kufizimet rajonale, duke siguruar qasje në të gjitha veçoritë e sigurisë të platformës cloud. Për më tepër, për ekipe të ndryshme lokale ajo mund të sigurojë grupin e vet të aftësive mbrojtëse, duke përfshirë ngjarjet e sigurisë të menaxhuara prej tyre. AWS Security Hub është ende në rrugën e tij për t'u bërë i ngjashëm me Azure Security Center. Por ia vlen të shtoni një mizë në vaj - ju mund të shtrydhni nga Azure shumë nga ato që u përshkruan më parë në AWS, por kjo bëhet më e përshtatshme vetëm për Azure AD, Azure Monitor dhe Azure Security Center. Të gjithë mekanizmat e tjerë të sigurisë Azure, përfshirë analizën e ngjarjeve të sigurisë, nuk menaxhohen ende në mënyrën më të përshtatshme. Problemi zgjidhet pjesërisht nga API, i cili përshkon të gjitha shërbimet e Microsoft Azure, por kjo do të kërkojë përpjekje shtesë nga ju për të integruar renë tuaj me SOC tuaj dhe praninë e specialistëve të kualifikuar (në fakt, si me çdo SIEM tjetër që punon me cloud API). Disa SIEM, të cilat do të diskutohen më vonë, tashmë mbështesin Azure dhe mund të automatizojnë detyrën e monitorimit të tij, por gjithashtu ka vështirësitë e veta - jo të gjithë mund të mbledhin të gjitha regjistrat që ka Azure.

Mbledhja dhe monitorimi i ngjarjeve në Azure sigurohet duke përdorur shërbimin Azure Monitor, i cili është mjeti kryesor për mbledhjen, ruajtjen dhe analizimin e të dhënave në cloud të Microsoft dhe burimet e tij - depot Git, kontejnerët, makinat virtuale, aplikacionet, etj. Të gjitha të dhënat e mbledhura nga Azure Monitor ndahen në dy kategori - metrikë, të mbledhura në kohë reale dhe që përshkruajnë treguesit kryesorë të performancës së resë Azure, dhe regjistrat, që përmbajnë të dhëna të organizuara në regjistrime që karakterizojnë aspekte të caktuara të aktivitetit të burimeve dhe shërbimeve Azure. Përveç kësaj, duke përdorur API-në e mbledhjes së 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 tij të monitorimit.

Këtu janë disa burime të ngjarjeve të sigurisë që Azure ju ofron dhe që mund t'i përdorni përmes Portalit Azure, CLI, PowerShell ose REST API (dhe disa vetëm përmes API-së Azure Monitor/Insight):

Regjistrat e aktiviteteve - ky regjistër u përgjigjet pyetjeve klasike "kush", "çfarë" dhe "kur" në lidhje me çdo operacion shkrimi (PUT, POST, DELETE) në burimet e resë kompjuterike. Ngjarjet që lidhen me aksesin për lexim (GET) nuk përfshihen në këtë regjistër, si një numër të tjerash.
Regjistrat diagnostikues - përmban të dhëna për operacionet me një burim të veçantë të përfshirë në pajtimin tuaj.
Raportimi Azure AD - përmban aktivitetin e përdoruesit dhe aktivitetin e sistemit në lidhje me menaxhimin e grupit dhe përdoruesit.
Windows Event Log dhe Linux Syslog - përmban ngjarje nga makinat virtuale të pritura në re.
Metrics - përmban telemetri në lidhje me performancën dhe gjendjen shëndetësore të shërbimeve dhe burimeve tuaja cloud. Matur çdo minutë dhe ruhet. brenda 30 ditëve.
Regjistrat e rrjedhës së grupit të sigurisë së rrjetit - përmban të dhëna për ngjarjet e sigurisë së rrjetit të mbledhura duke përdorur shërbimin e vëzhguesit të rrjetit dhe monitorimin e burimeve në nivel rrjeti.
Regjistrat e ruajtjes - përmban ngjarje që lidhen me aksesin në objektet e ruajtjes.

Për monitorim, mund të përdorni SIEM të jashtëm ose Monitorin e integruar Azure dhe shtesat e tij. Ne do të flasim për sistemet e menaxhimit të ngjarjeve të sigurisë së informacionit më vonë, por tani për tani le të shohim se çfarë na ofron vetë Azure për analizën e të dhënave në kontekstin e sigurisë. Ekrani kryesor për gjithçka që lidhet me sigurinë në Azure Monitor është Paneli i Sigurisë dhe Auditimit të Log Analytics (versioni falas mbështet një sasi të kufizuar të ruajtjes së ngjarjeve për vetëm një javë). Ky panel kontrolli është i ndarë në 5 fusha kryesore që vizualizojnë statistikat përmbledhëse të asaj që po ndodh në mjedisin cloud që po përdorni:

Domenet e sigurisë - treguesit sasiorë kryesorë që lidhen me sigurinë e informacionit - numri i incidenteve, numri i nyjeve të komprometuara, nyjet e papatchuara, ngjarjet e sigurisë së rrjetit, etj.
Çështje të dukshme - tregon numrin dhe rëndësinë e çështjeve aktive të sigurisë së informacionit
Zbulimet - shfaq modelet e sulmeve të përdorura kundër jush
Inteligjenca e kërcënimit - shfaq informacionin gjeografik në nyjet e jashtme që po ju sulmojnë
Pyetjet e zakonshme të sigurisë - pyetje tipike që do t'ju ndihmojnë të monitoroni më mirë sigurinë tuaj të informacionit.

Zgjerimet e Azure Monitor përfshijnë Azure Key Vault (mbrojtja e çelësave kriptografikë në re), Vlerësimi i Malware (analiza e mbrojtjes kundër kodit me qëllim të keq në makinat virtuale), Azure Application Gateway Analytics (analiza e, ndër të tjera, regjistrat e murit të zjarrit të cloud), etj. . Këto mjete, të pasuruara me rregulla të caktuara për përpunimin e ngjarjeve, ju lejojnë të vizualizoni aspekte të ndryshme të aktivitetit të shërbimeve cloud, përfshirë sigurinë, dhe të identifikoni devijime të caktuara nga funksionimi. Por, siç ndodh shpesh, çdo funksionalitet shtesë kërkon një abonim përkatës me pagesë, i cili do të kërkojë investime financiare përkatëse nga ju, të cilat duhet t'i planifikoni paraprakisht.

Azure ka një numër aftësish të integruara të monitorimit të kërcënimeve që janë të integruara në Azure AD, Azure Monitor dhe Azure Security Center. Midis tyre, për shembull, zbulimi i ndërveprimit të makinave virtuale me IP-të e njohura me qëllim të keq (për shkak të pranisë së integrimit me shërbimet Threat Intelligence nga Microsoft), zbulimi i malware në infrastrukturën cloud duke marrë alarme nga makinat virtuale të pritura në cloud, fjalëkalimi sulme me hamendje” në makinat virtuale, dobësi në konfigurimin e sistemit të identifikimit të përdoruesit, hyrje në sistem nga anonimizuesit ose nyjet e infektuara, rrjedhje llogarie, hyrje në sistem nga vende të pazakonta, etj. Azure sot është një nga ofruesit e paktë të reve kompjuterike që ju ofron aftësi të integruara të inteligjencës së kërcënimit për të pasuruar ngjarjet e grumbulluara të sigurisë së informacionit.

Siç u përmend më lart, funksionaliteti i sigurisë dhe, si rezultat, ngjarjet e sigurisë të krijuara prej tij nuk janë të disponueshme për të gjithë përdoruesit në mënyrë të barabartë, por kërkojnë një abonim të caktuar që përfshin funksionalitetin që ju nevojitet, i cili gjeneron ngjarjet e duhura për monitorimin e sigurisë së informacionit. Për shembull, disa nga funksionet e përshkruara në paragrafin e mëparshëm për monitorimin e anomalive në llogari janë të disponueshme vetëm në licencën premium P2 për shërbimin Azure AD. Pa të, ju, si në rastin e AWS, do të duhet të analizoni "manualisht" ngjarjet e mbledhura të sigurisë. Dhe, gjithashtu, në varësi të llojit të licencës Azure AD, jo të gjitha ngjarjet do të jenë të disponueshme për analizë.

Në portalin Azure, ju mund të menaxhoni të dy pyetjet e kërkimit për regjistrat me interes për ju dhe të konfiguroni panele për të vizualizuar treguesit kryesorë të sigurisë së informacionit. Për më tepër, atje mund të zgjidhni shtesat e Azure Monitor, të cilat ju lejojnë të zgjeroni funksionalitetin e regjistrave të Azure Monitor dhe të merrni një analizë më të thellë të ngjarjeve nga pikëpamja e sigurisë.

Nëse ju nevojitet jo vetëm aftësia për të punuar me regjistrat, por një qendër gjithëpërfshirëse sigurie për platformën tuaj cloud Azure, duke përfshirë menaxhimin e politikave të sigurisë së informacionit, atëherë mund të flisni për nevojën për të punuar me Azure Security Center, shumica e funksioneve të dobishme të së cilës janë të disponueshme për disa para, për shembull, zbulimi i kërcënimit, monitorimi jashtë Azure, vlerësimi i pajtueshmërisë, etj. (në versionin falas, ju keni akses vetëm në një vlerësim sigurie dhe rekomandime për eliminimin e problemeve të identifikuara). Ai konsolidon të gjitha çështjet e sigurisë në një vend. Në fakt, mund të flasim për një nivel më të lartë sigurie informacioni sesa ju ofron Azure Monitor, pasi në këtë rast të dhënat e mbledhura në të gjithë fabrikën tuaj cloud pasurohen duke përdorur shumë burime, 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 janë mbivendosur algoritme të ndryshme të sofistikuara të mësimit të makinerive dhe analitikës së sjelljes, të cilat përfundimisht duhet të përmirësojnë efikasitetin e zbulimit dhe reagimit ndaj kërcënimeve .

Azure gjithashtu ka SIEM-in e vet - u shfaq në fillim të 2019. Ky është Azure Sentinel, i cili mbështetet në të dhënat nga Azure Monitor dhe gjithashtu mund të integrohet me të. zgjidhje të jashtme të sigurisë (për shembull, NGFW ose WAF), lista e të cilave po rritet vazhdimisht. Përveç kësaj, përmes integrimit të API-së së sigurisë së Microsoft Graph, ju keni mundësinë të lidhni burimet tuaja të Inteligjencës së Kërcënimit me Sentinel, gjë që pasuron aftësitë për analizimin e incidenteve në renë tuaj Azure. Mund të argumentohet se Azure Sentinel është SIEM i parë "vendas" që u shfaq nga ofruesit e cloud (i njëjti Splunk ose ELK, i cili mund të strehohet në cloud, për shembull, AWS, ende nuk janë zhvilluar nga ofruesit tradicionalë të shërbimeve cloud). Azure Sentinel dhe Qendra e Sigurisë mund të quhet SOC për cloud Azure dhe mund të kufizohet në to (me disa rezerva) nëse nuk do të kishit më asnjë infrastrukturë dhe do t'i transferonit të gjitha burimet tuaja kompjuterike në cloud dhe do të ishte Microsoft cloud Azure.

Por meqenëse aftësitë e integruara të Azure (edhe nëse keni një abonim në 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 të brendshëm), ekziston një duhet të eksportojë të dhënat e mbledhura në sisteme të jashtme, në të cilat mund të përfshijë SIEM. Kjo bëhet si duke përdorur API-në ashtu edhe duke përdorur shtesa speciale, të cilat aktualisht janë zyrtarisht të disponueshme vetëm për SIEM-ët e mëposhtëm - Splunk (Azure Monitor Add-On për Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight dhe ELK. Deri kohët e fundit, kishte më shumë SIEM të tillë, por që nga 1 qershori 2019, Microsoft ndaloi mbështetjen e Azure Log Integration Tool (AzLog), i cili në agimin e ekzistencës së Azure dhe në mungesë të standardizimit normal të punës me regjistrat (Azure Monitori as që ekzistonte ende) e bëri të lehtë integrimin e SIEM-it të jashtëm me renë kompjuterike të Microsoft. Tani situata ka ndryshuar dhe Microsoft rekomandon platformën Azure Event Hub si mjetin kryesor të integrimit për SIEM të tjera. Shumë prej tyre kanë zbatuar tashmë një integrim të tillë, por kini kujdes - ata mund të mos kapin të gjitha regjistrat Azure, por vetëm disa (shikoni në dokumentacionin për SIEM-in tuaj).

Duke përfunduar një ekskursion të shkurtër në Azure, do të doja të jap një rekomandim të përgjithshëm në lidhje me këtë shërbim cloud - përpara se të thoni ndonjë gjë në lidhje me funksionet e monitorimit të sigurisë së informacionit në Azure, duhet t'i konfiguroni ato me shumë kujdes dhe të provoni që ato funksionojnë siç shkruhet në dokumentacion dhe siç ju thanë konsulentët Microsoft (dhe ata mund të kenë pikëpamje të ndryshme mbi funksionalitetin e funksioneve Azure). Nëse keni burime financiare, mund të shtrydhni shumë informacione të dobishme nga Azure për sa i përket monitorimit të sigurisë së informacionit. Nëse burimet tuaja janë të kufizuara, atëherë, si në rastin e AWS, do të duhet të mbështeteni vetëm në forcat tuaja dhe të dhënat e papërpunuara që ju ofron Azure Monitor. Dhe mbani mend se shumë funksione monitorimi kushtojnë para dhe është më mirë të njiheni paraprakisht me politikën e çmimeve. Për shembull, mund të ruani falas 31 ditë të dhëna deri në një maksimum prej 5 GB për klient - tejkalimi i këtyre vlerave do t'ju kërkojë të shpenzoni para shtesë (afërsisht 2+ dollarë për ruajtjen e çdo GB shtesë nga klienti dhe 0,1 dollarë për duke ruajtur 1 GB çdo muaj shtesë). Puna me telemetrinë dhe metrikën e aplikacionit mund të kërkojë gjithashtu fonde shtesë, si dhe të punoni me sinjalizime dhe njoftime (një kufi i caktuar ofrohet falas, i cili mund të mos jetë i mjaftueshëm për nevojat tuaja).

Shembull: Monitorimi i sigurisë së informacionit në IaaS bazuar në Google Cloud Platform

Google Cloud Platform duket si një i ri në krahasim me AWS dhe Azure, por kjo është pjesërisht e mirë. Ndryshe nga AWS, i cili rriti gradualisht aftësitë e tij, përfshirë ato të sigurisë, duke pasur probleme me centralizimin; GCP, si Azure, menaxhohet shumë më mirë nga qendra, gjë që redukton gabimet dhe kohën e zbatimit në të gjithë ndërmarrjen. Nga pikëpamja e sigurisë, GCP është, çuditërisht, midis AWS dhe Azure. Ai gjithashtu ka një regjistrim të vetëm të ngjarjeve për të gjithë organizatën, por ai është i paplotë. Disa funksione janë ende në modalitetin beta, por gradualisht kjo mangësi duhet të eliminohet dhe GCP do të bëhet një platformë më e pjekur për sa i përket monitorimit të sigurisë së informacionit.

Mjeti kryesor për regjistrimin e ngjarjeve në GCP është Stackdriver Logging (i ngjashëm me Azure Monitor), i cili ju lejon të grumbulloni ngjarje në të gjithë infrastrukturën tuaj cloud (si dhe nga AWS). Nga pikëpamja e sigurisë në GCP, çdo organizatë, projekt ose dosje ka katër regjistra:

Aktiviteti i administratorit - përmban të gjitha ngjarjet që lidhen me aksesin administrativ, për shembull, krijimin e një makine virtuale, ndryshimin e të drejtave të aksesit, etj. Ky regjistër shkruhet gjithmonë, pavarësisht nga dëshira juaj, dhe ruan të dhënat e tij për 400 ditë.
Qasja në të dhëna - përmban të gjitha ngjarjet që lidhen me punën me të dhënat nga përdoruesit e cloud (krijimi, modifikimi, leximi, etj.). Si parazgjedhje, ky regjistër nuk është i shkruar, pasi vëllimi i tij fryhet shumë shpejt. Për këtë arsye, afati i ruajtjes së tij është vetëm 30 ditë. Përveç kësaj, jo gjithçka është shkruar në këtë revistë. Për shembull, ngjarjet që lidhen me burimet që janë publikisht të aksesueshme për të gjithë përdoruesit ose që janë të aksesueshme pa u identifikuar në GCP nuk janë të shkruara në të.
Ngjarja e sistemit - përmban ngjarje të sistemit që nuk lidhen me përdoruesit, ose veprime të një administratori që ndryshon konfigurimin e burimeve të resë kompjuterike. Shkruhet gjithmonë dhe ruhet për 400 ditë.
Access Transparency është një shembull unik i një regjistri që regjistron të gjitha veprimet e punonjësve të Google (por jo ende për të gjitha shërbimet GCP) të cilët aksesojnë infrastrukturën tuaj si pjesë e detyrave të tyre të punës. Ky regjistër ruhet për 400 ditë dhe nuk është i disponueshëm për çdo klient GCP, por vetëm nëse plotësohen një sërë kushtesh (mbështetje në nivel Gold ose Platinum, ose prania e 4 roleve të një lloji të caktuar si pjesë e mbështetjes së korporatës). Një funksion i ngjashëm është gjithashtu i disponueshëm, për shembull, në Office 365 - Lockbox.

Shembull i regjistrit: Qasja në Transparencë

{
 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"
}

Qasja në këto regjistra është e mundur në disa mënyra (në të njëjtën mënyrë si Azure dhe AWS të diskutuara më parë) - përmes ndërfaqes Log Viewer, përmes API-së, përmes Google Cloud SDK ose përmes faqes së Aktivitetit të projektit tuaj për të cilin ju janë të interesuar për ngjarjet. Në të njëjtën mënyrë, ato mund të eksportohen në zgjidhje të jashtme për analiza shtesë. Kjo e fundit bëhet duke eksportuar regjistrat në hapësirën ruajtëse BigQuery ose Cloud Pub/Sub.

Përveç Stackdriver Logging, platforma GCP ofron gjithashtu funksionalitetin e Monitorimit të Stackdriver, i cili ju lejon të monitoroni metrikat kryesore (performanca, MTBF, shëndeti i përgjithshëm, etj.) të shërbimeve dhe aplikacioneve cloud. Të dhënat e përpunuara dhe të vizualizuara mund ta bëjnë më të lehtë gjetjen e problemeve në infrastrukturën tuaj të resë kompjuterike, duke përfshirë edhe kontekstin e sigurisë. Por duhet të theksohet se ky funksionalitet nuk do të jetë shumë i pasur në kontekstin e sigurisë së informacionit, pasi sot GCP nuk ka një analog të të njëjtit AWS GuardDuty dhe nuk mund të identifikojë të këqijat midis të gjitha ngjarjeve të regjistruara (Google ka zhvilluar Zbulimin e Kërcënimeve të Ngjarjeve, por është ende në zhvillim në beta dhe është shumë herët për të folur për dobinë e tij). Stackdriver Monitoring mund të përdoret si një sistem për zbulimin e anomalive, të cilat më pas do të hetohen për të gjetur shkaqet e shfaqjes së tyre. Por duke pasur parasysh mungesën e personelit të kualifikuar në fushën e sigurisë së informacionit GCP në treg, kjo detyrë aktualisht duket e vështirë.

Vlen gjithashtu të jepni një listë të disa moduleve të sigurisë së informacionit që mund të përdoren në renë tuaj GCP dhe të cilat janë të ngjashme me atë që ofron AWS:

Cloud Security Command Center është një analog i Qendrës së Sigurisë AWS dhe Qendrës së Sigurisë Azure.
Cloud DLP - Zbulimi dhe redaktimi automatik (p.sh. maskimi) i të dhënave të pritura në renë kompjuterike duke përdorur më shumë se 90 politika të paracaktuara klasifikimi.
Cloud Scanner është një skaner për dobësitë e njohura (XSS, Flash Injection, biblioteka të papatchuara, etj.) në App Engine, Compute Engine dhe Google Kubernetes.
Cloud IAM - Kontrollo qasjen në të gjitha burimet GCP.
Cloud Identity - Menaxho llogaritë e përdoruesve, pajisjes dhe aplikacioneve GCP nga një tastierë e vetme.
Cloud HSM - mbrojtja e çelësave kriptografikë.
Shërbimi i menaxhimit të çelësave në renë kompjuterike - menaxhimi i çelësave kriptografikë në GCP.
Kontrolli i Shërbimit VPC - Krijoni një perimetër të sigurt rreth burimeve tuaja GCP për t'i mbrojtur ato nga rrjedhjet.
Çelësi i sigurisë Titan - mbrojtje kundër phishing.

Shumë prej këtyre moduleve gjenerojnë ngjarje sigurie që mund të dërgohen në ruajtjen e BigQuery për analizë ose eksportim në sisteme të tjera, duke përfshirë SIEM. Siç u përmend më lart, GCP është një platformë në zhvillim aktiv dhe Google tani po zhvillon një numër modulesh të reja të sigurisë së informacionit për platformën e saj. Midis tyre janë Zbulimi i Kërcënimeve të Ngjarjeve (tani i disponueshëm në beta), i cili skanon regjistrat e Stackdriver në kërkim të gjurmëve të aktivitetit të paautorizuar (analog me GuardDuty në AWS), ose Inteligjenca Politike (e disponueshme në alfa), e cila do t'ju lejojë të zhvilloni politika inteligjente për akses në burimet GCP.

Bëra një përmbledhje të shkurtër të aftësive të integruara të monitorimit në platformat e njohura të cloud. Por a keni specialistë që janë në gjendje të punojnë me regjistrat "të papërpunuar" të ofruesve të IaaS (jo të gjithë janë gati të blejnë aftësitë e avancuara të AWS ose Azure ose Google)? Përveç kësaj, shumë janë të njohur me fjalën e urtë "beso, por verifiko", e cila është më e vërtetë se kurrë në fushën e sigurisë. Sa i besoni aftësive të integruara të ofruesit të cloud që ju dërgojnë ngjarje të sigurisë së informacionit? Sa përqendrohen fare në sigurinë e informacionit?

Ndonjëherë ia vlen të shikoni zgjidhjet e mbivendosura të monitorimit të infrastrukturës së resë kompjuterike që mund të plotësojnë sigurinë e integruar të resë kompjuterike, dhe ndonjëherë zgjidhje të tilla janë opsioni i vetëm për të fituar njohuri mbi sigurinë e të dhënave dhe aplikacioneve tuaja të pritura në renë kompjuterike. Për më tepër, ato janë thjesht më të përshtatshme, pasi marrin përsipër të gjitha detyrat e analizimit të regjistrave të nevojshëm të krijuar nga shërbime të ndryshme cloud nga ofrues të ndryshëm cloud. Një shembull i një zgjidhjeje të tillë mbivendosjeje është Cisco Stealthwatch Cloud, i cili fokusohet në një detyrë të vetme - monitorimin e anomalive të sigurisë së informacionit në mjediset cloud, duke përfshirë jo vetëm Amazon AWS, Microsoft Azure dhe Google Cloud Platform, por edhe retë private.

Shembull: Monitorimi i sigurisë së informacionit duke përdorur Stealthwatch Cloud

AWS ofron një platformë kompjuterike fleksibël, por ky fleksibilitet e bën më të lehtë për kompanitë të bëjnë gabime që çojnë në çështje sigurie. Dhe modeli i përbashkët i sigurisë së informacionit kontribuon vetëm në këtë. Ekzekutimi i softuerit në cloud me dobësi të panjohura (ato të njohura mund të luftohen, për shembull, nga AWS Inspector ose GCP Cloud Scanner), fjalëkalime të dobëta, konfigurime të pasakta, insajderë, etj. Dhe e gjithë kjo reflektohet në sjelljen e burimeve cloud, të cilat mund të monitorohen nga Cisco Stealthwatch Cloud, i cili është një sistem monitorimi i sigurisë së informacionit dhe zbulimi i sulmeve. retë publike dhe private.

Një nga veçoritë kryesore të Cisco Stealthwatch Cloud është aftësia për të modeluar entitete. Me të, ju mund të krijoni një model softuerësh (d.m.th., një simulim pothuajse në kohë reale) të secilit prej burimeve tuaja cloud (nuk ka rëndësi nëse është AWS, Azure, GCP ose diçka tjetër). Këto mund të përfshijnë serverë dhe përdorues, si dhe lloje burimesh specifike për mjedisin tuaj cloud, si grupet e sigurisë dhe grupet e shkallës automatike. Këto modele përdorin rrjedha të strukturuara të të dhënave të ofruara nga shërbimet cloud si hyrje. Për shembull, për AWS këto do të ishin regjistrat e rrjedhës VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda dhe AWS IAM. Modelimi i entitetit zbulon automatikisht rolin dhe sjelljen e cilitdo prej burimeve tuaja (mund të flisni për profilizimin e të gjithë aktivitetit të resë kompjuterike). Këto role përfshijnë pajisjen celulare Android ose Apple, serverin Citrix PVS, serverin RDP, portën e postës, klientin VoIP, serverin e terminalit, kontrolluesin e domenit, etj. Më pas 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 hamendjen e fjalëkalimit, sulmet DDoS, rrjedhjet e të dhënave, aksesin e paligjshëm në distancë, aktivitetin e kodeve me qëllim të keq, skanimin e cenueshmërisë dhe kërcënime të tjera. Për shembull, kjo është se si duket zbulimi i një përpjekjeje për qasje në distancë nga një vend atipik për organizatën tuaj (Koreja e Jugut) në një grup Kubernetes nëpërmjet SSH:

Dhe kjo është se si duket rrjedhja e supozuar e informacionit nga baza e të dhënave Postgress në një vend me të cilin nuk kemi hasur më parë ndërveprim:

Më në fund, kështu duken shumë përpjekje të dështuara SSH nga Kina dhe Indonezia nga një pajisje e jashtme në distancë:

Ose, supozoni se shembulli i serverit në VPC, sipas politikës, nuk do të jetë kurrë një destinacion i largët i hyrjes. Le të supozojmë më tej se ky kompjuter përjetoi një hyrje në distancë për shkak të një ndryshimi të gabuar në politikën e rregullave të murit të zjarrit. Funksioni "Entity Modeling" do të zbulojë dhe raportojë këtë aktivitet ("Qasje e pazakontë në distancë") pothuajse në kohë reale dhe do t'i drejtojë thirrjes specifike AWS CloudTrail, Azure Monitor ose GCP Stackdriver Logging API (duke përfshirë emrin e përdoruesit, datën dhe kohën, midis detajeve të tjera i cili nxiti ndryshimin e rregullit të ITU. Dhe më pas ky informacion mund të dërgohet në SIEM për analizë.

Aftësi të ngjashme zbatohen për çdo mjedis cloud të mbështetur nga Cisco Stealthwatch Cloud:

Modelimi i entitetit është një formë unike e automatizimit të sigurisë që mund të zbulojë një problem të panjohur më parë me njerëzit, proceset ose teknologjinë tuaj. Për shembull, ju lejon të zbuloni, ndër të tjera, probleme sigurie si:

A ka zbuluar dikush një backdoor në softuerin që përdorim?
A ka ndonjë softuer ose pajisje të palës së tretë në renë tonë kompjuterike?
A abuzon përdoruesi i autorizuar me privilegjet?
A kishte ndonjë gabim konfigurimi që lejonte akses në distancë ose përdorim tjetër të paqëllimshëm të burimeve?
A ka rrjedhje të dhënash nga serverët tanë?
A po përpiqej dikush të lidhej me ne nga një vendndodhje gjeografike atipike?
A është reja jonë e infektuar me kod me qëllim të keq?

Një ngjarje e zbuluar e sigurisë së informacionit mund të dërgohet në formën e një bilete përkatëse te Slack, Cisco Spark, sistemi i menaxhimit të incidenteve PagerDuty dhe gjithashtu të dërgohet në SIEM të ndryshëm, duke përfshirë Splunk ose ELK. Për ta përmbledhur, mund të themi se nëse kompania juaj përdor një strategji me shumë re dhe nuk kufizohet në asnjë ofrues të reve kompjuterike, aftësitë e monitorimit të sigurisë së informacionit të përshkruara më sipër, atëherë përdorimi i Cisco Stealthwatch Cloud është një opsion i mirë për të marrë një grup të unifikuar monitorimi. aftësi për lojtarët kryesorë të cloud - Amazon , Microsoft dhe Google. Gjëja më interesante është se nëse krahasoni çmimet për Stealthwatch Cloud me licencat e avancuara për monitorimin e sigurisë së informacionit në AWS, Azure ose GCP, mund të rezultojë se zgjidhja Cisco do të jetë edhe më e lirë se aftësitë e integruara të Amazon, Microsoft. dhe zgjidhjet e Google. Është paradoksale, por është e vërtetë. Dhe sa më shumë retë dhe aftësitë e tyre të përdorni, aq më i dukshëm do të jetë avantazhi i një zgjidhjeje të konsoliduar.

Përveç kësaj, Stealthwatch Cloud mund të monitorojë retë private të vendosura në organizatën tuaj, për shembull, bazuar në kontejnerët Kubernetes ose duke monitoruar flukset Netflow ose trafikun e rrjetit të marrë përmes pasqyrimit në pajisjet e rrjetit (madje edhe të prodhuara në vend), të dhënat AD ose serverët DNS etj. Të gjitha këto të dhëna do të pasurohen me informacionin e Inteligjencës së Kërcënimeve të mbledhura nga Cisco Talos, grupi më i madh joqeveritar në botë i studiuesve të kërcënimeve të sigurisë kibernetike.

Kjo ju lejon të zbatoni një sistem të unifikuar monitorimi për retë publike dhe hibride që kompania juaj mund të përdorë. Informacioni i mbledhur më pas mund të analizohet duke përdorur aftësitë e integruara të Stealthwatch Cloud ose të dërgohet në SIEM-in tuaj (Splunk, ELK, SumoLogic dhe disa të tjerë mbështeten si parazgjedhje).

Me këtë, ne do të plotësojmë pjesën e parë të artikullit, në të cilin kam shqyrtuar mjetet e integruara dhe të jashtme për monitorimin e sigurisë së informacionit të platformave IaaS/PaaS, të cilat na lejojnë të zbulojmë dhe reagojmë shpejt ndaj incidenteve që ndodhin në mjediset cloud që ka zgjedhur ndërmarrja jonë. Në pjesën e dytë, ne do të vazhdojmë temën dhe do të shikojmë opsionet për monitorimin e platformave SaaS duke përdorur shembullin e Salesforce dhe Dropbox, dhe gjithashtu do të përpiqemi të përmbledhim dhe bashkojmë gjithçka duke krijuar një sistem të unifikuar monitorimi të sigurisë së informacionit për ofrues të ndryshëm cloud.

Burimi: www.habr.com

Monitorimi i sigurisë në renë kompjuterike