🥇Vöktun skýjaöryggis

Að flytja gögn og forrit yfir í skýið býður upp á nýja áskorun fyrir SOC fyrirtækja, sem eru ekki alltaf tilbúin til að fylgjast með innviðum annarra. Samkvæmt Netoskope notar meðalfyrirtæki (að því er virðist í Bandaríkjunum) 1246 mismunandi skýjaþjónustur, sem er 22% meira en fyrir ári síðan. 1246 skýjaþjónusta!!! 175 þeirra tengjast starfsmannaþjónustu, 170 tengjast markaðssetningu, 110 eru á sviði samskipta og 76 eru í fjármálum og CRM. Cisco notar „aðeins“ 700 ytri skýjaþjónustur. Svo ég er svolítið ruglaður með þessar tölur. En hvað sem því líður þá er vandamálið ekki hjá þeim heldur því að skýið er farið að vera nokkuð virkt í notkun hjá sífellt fleiri fyrirtækjum sem vilja hafa sömu getu til að fylgjast með skýjainnviðum og í eigin neti. Og þessi þróun fer vaxandi - skv samkvæmt American Chamber of Accounts Árið 2023 verður 1200 gagnaverum lokað í Bandaríkjunum (6250 hafa þegar lokað). En umskiptin yfir í skýið eru ekki bara „við skulum færa netþjóna okkar til utanaðkomandi þjónustuaðila. Nýr upplýsingatækniarkitektúr, nýr hugbúnaður, nýir ferlar, nýjar takmarkanir... Allt þetta hefur í för með sér verulegar breytingar á starfi ekki aðeins upplýsingatækni heldur einnig upplýsingaöryggi. Og ef veitendur hafa lært að takast á einhvern hátt við að tryggja öryggi skýsins sjálfs (sem betur fer eru fullt af ráðleggingum), þá eru verulegir erfiðleikar með skýupplýsingaöryggiseftirlit, sérstaklega á SaaS kerfum, sem við munum tala um.

Segjum að fyrirtækið þitt hafi flutt hluta af innviðum sínum yfir í skýið... Hættu. Ekki svona. Ef innviðirnir hafa verið fluttir, og þú ert fyrst núna að hugsa um hvernig þú munt fylgjast með því, þá hefur þú þegar tapað. Nema það sé Amazon, Google eða Microsoft (og þá með fyrirvara), muntu líklega ekki hafa mikla getu til að fylgjast með gögnum þínum og forritum. Það er gott ef þú færð tækifæri til að vinna með logs. Stundum verða gögn um öryggisatburði tiltæk, en þú munt ekki hafa aðgang að þeim. Til dæmis Office 365. Ef þú ert með ódýrasta E1 leyfið, þá eru öryggisviðburðir alls ekki í boði fyrir þig. Ef þú ert með E3 leyfi eru gögnin þín geymd í aðeins 90 daga og aðeins ef þú ert með E5 leyfi er lengd skráninganna tiltæk í eitt ár (þetta hefur hins vegar sín eigin blæbrigði sem tengjast þörfinni á aðskilin biðja um fjölda aðgerða til að vinna með annálum frá stuðningi Microsoft). Við the vegur, E3 leyfið er mun veikara hvað varðar eftirlitsaðgerðir en fyrirtækjaskipti. Til að ná sama stigi þarftu E5 leyfi eða viðbótar Advanced Compliance leyfi, sem gæti þurft viðbótarfé sem ekki var tekið með í fjárhagslíkanið þitt til að flytja yfir í skýjainnviði. Og þetta er aðeins eitt dæmi um vanmat á málum sem tengjast skýjaupplýsingaöryggiseftirliti. Í þessari grein, án þess að þykjast vera tæmandi, vil ég vekja athygli á nokkrum blæbrigðum sem ætti að hafa í huga þegar þú velur skýjaþjónustu frá öryggissjónarmiði. Og í lok greinarinnar verður gefinn gátlisti sem vert er að fylla út áður en talið er að búið sé að leysa vandamálið um eftirlit með skýupplýsingaöryggi.

Það eru nokkur dæmigerð vandamál sem leiða til atvika í skýjaumhverfi, sem upplýsingaöryggisþjónusta hefur ekki tíma til að bregðast við eða sjá þau alls ekki:

Öryggisskrár eru ekki til. Þetta er nokkuð algengt ástand, sérstaklega meðal nýliða á skýjalausnamarkaði. En þú ættir ekki að gefast upp á þeim strax. Litlir leikmenn, sérstaklega innlendir, eru næmari fyrir kröfum viðskiptavina og geta fljótt innleitt nokkrar nauðsynlegar aðgerðir með því að breyta samþykktum vegvísi fyrir vörur sínar. Já, þetta verður ekki hliðstæða GuardDuty frá Amazon eða „Proactive Protection“ einingunni frá Bitrix, heldur að minnsta kosti eitthvað.
Upplýsingaöryggi veit ekki hvar annálarnir eru geymdir eða það er enginn aðgangur að þeim. Hér þarf að fara í samningaviðræður við skýjaþjónustuveituna - kannski veitir hann slíkar upplýsingar ef hann telur viðskiptavininn mikilvægan fyrir sig. En almennt séð er það ekki mjög gott þegar aðgangur að annálum er veittur „með sérstakri ákvörðun“.
Það kemur líka fyrir að skýjaveitan er með logs, en þeir veita takmarkaða vöktun og atburðaskráningu sem dugar ekki til að greina öll atvik. Til dæmis gætirðu aðeins fengið skrár yfir breytingar á vefsíðu eða skrár yfir auðkenningartilraunir notenda, en ekki aðra atburði, eins og netumferð, sem mun fela fyrir þér heilt lag af atburðum sem einkenna tilraunir til að hakka innviði skýsins þíns.
Það eru logs, en aðgangur að þeim er erfitt að gera sjálfvirkan, sem neyðir þá til að fylgjast með þeim ekki stöðugt, heldur á áætlun. Og ef þú getur ekki hlaðið niður annálum sjálfkrafa, þá getur niðurhal á annálum, til dæmis á Excel sniði (eins og hjá fjölda innlendra skýlausnaveitenda), jafnvel leitt til tregðu hjá upplýsingaöryggisþjónustu fyrirtækja til að fikta við þá.
Ekkert log eftirlit. Þetta er ef til vill óljósasta ástæðan fyrir því að upplýsingaöryggisatvik eiga sér stað í skýjaumhverfi. Það virðist vera til logs og það er hægt að gera sjálfvirkan aðgang að þeim, en enginn gerir þetta. Hvers vegna?

Sameiginlegt skýjaöryggishugtak

Umskiptin í skýið eru alltaf leit að jafnvægi milli löngunar til að halda stjórn á innviðum og færa það yfir á fagmannlegri hendur skýjaveitu sem sérhæfir sig í að viðhalda því. Og á sviði skýjaöryggis þarf líka að leita eftir þessu jafnvægi. Þar að auki, allt eftir því hvaða skýjaþjónustuafhendingarlíkan er notað (IaaS, PaaS, SaaS), mun þetta jafnvægi vera mismunandi allan tímann. Í öllu falli verðum við að muna að allar skýjaveitur í dag fylgja svokölluðu sameiginlegri ábyrgð og sameiginlegu upplýsingaöryggislíkani. Skýið ber ábyrgð á sumum hlutum og fyrir öðrum er viðskiptavinurinn ábyrgur, setur gögnin sín, forritin sín, sýndarvélarnar og aðrar auðlindir í skýið. Það væri kæruleysi að búast við því að með því að fara í skýið munum við færa alla ábyrgð yfir á þjónustuveituna. En það er líka óskynsamlegt að byggja upp allt öryggi sjálfur þegar þú ferð yfir í skýið. Jafnvægis er krafist, sem mun ráðast af mörgum þáttum: - áhættustýringarstefnu, ógnarlíkani, öryggisaðferðum sem skýjaveitan stendur til boða, löggjöf o.s.frv.

Til dæmis er flokkun gagna hýst í skýinu alltaf á ábyrgð viðskiptavinarins. Skýjaveita eða utanaðkomandi þjónustuaðili getur aðeins aðstoðað hann með verkfærum sem hjálpa til við að merkja gögn í skýinu, bera kennsl á brot, eyða gögnum sem brjóta í bága við lög eða fela þau með einni eða annarri aðferð. Á hinn bóginn er líkamlegt öryggi alltaf á ábyrgð skýjaveitunnar, sem það getur ekki deilt með viðskiptavinum. En allt sem er á milli gagna og efnislegra innviða er einmitt umfjöllunarefnið í þessari grein. Til dæmis er framboð á skýinu á ábyrgð þjónustuveitunnar og uppsetning eldveggsreglur eða virkja dulkóðun er á ábyrgð viðskiptavinarins. Í þessari grein munum við reyna að skoða hvaða vöktunarkerfi upplýsingaöryggis eru veitt í dag af ýmsum vinsælum skýjaveitum í Rússlandi, hverjir eru eiginleikar notkunar þeirra og hvenær er þess virði að leita að ytri yfirborðslausnum (til dæmis Cisco E- póstöryggi) sem auka getu skýsins þíns hvað varðar netöryggi. Í sumum tilfellum, sérstaklega ef þú fylgir fjölskýjastefnu, muntu ekki hafa annan valkost en að nota ytri eftirlitslausnir upplýsingaöryggis í nokkrum skýjaumhverfi í einu (til dæmis Cisco CloudLock eða Cisco Stealthwatch Cloud). Jæja, í sumum tilfellum muntu gera þér grein fyrir því að skýjaveitan sem þú hefur valið (eða þröngvað á þig) býður alls ekki upp á neina upplýsingaöryggiseftirlitsgetu. Þetta er óþægilegt, en heldur ekki lítið, þar sem það gerir þér kleift að meta á fullnægjandi hátt áhættustigið sem fylgir því að vinna með þetta ský.

Lífsferill skýjaöryggiseftirlits

Til að fylgjast með öryggi skýjanna sem þú notar hefurðu aðeins þrjá valkosti:

treysta á verkfærin frá skýjaveitunni þinni,
nota lausnir frá þriðja aðila sem munu fylgjast með IaaS, PaaS eða SaaS kerfum sem þú notar,
byggja upp þitt eigið skýjaeftirlitskerfi (aðeins fyrir IaaS/PaaS vettvang).

Við skulum sjá hvaða eiginleika hver af þessum valkostum hefur. En fyrst þurfum við að skilja almenna rammann sem verður notaður við eftirlit með skýjapöllum. Ég myndi draga fram 6 meginþætti upplýsingaöryggiseftirlitsferlisins í skýinu:

Undirbúningur innviða. Að ákvarða nauðsynleg forrit og innviði til að safna atburðum sem eru mikilvægir fyrir upplýsingaöryggi í geymslu.
Safn. Á þessu stigi er öryggisatburðum safnað saman frá ýmsum aðilum til síðari flutnings til vinnslu, geymslu og greiningar.
Meðferð. Á þessu stigi er gögnunum umbreytt og auðgað til að auðvelda síðari greiningu.
Geymsla. Þessi hluti er ábyrgur fyrir skammtíma- og langtímageymslu á söfnuðum unnum og hráum gögnum.
Greining. Á þessu stigi hefur þú möguleika á að greina atvik og bregðast við þeim sjálfkrafa eða handvirkt.
Skýrslugerð. Þetta stig hjálpar til við að móta lykilvísa fyrir hagsmunaaðila (stjórnendur, endurskoðendur, skýjaveitu, viðskiptavini o.s.frv.) sem hjálpa okkur að taka ákveðnar ákvarðanir, til dæmis að skipta um þjónustuaðila eða efla upplýsingaöryggi.

Skilningur á þessum hlutum gerir þér kleift að ákveða fljótt í framtíðinni hvað þú getur tekið frá þjónustuveitunni þinni og hvað þú verður að gera sjálfur eða með aðkomu utanaðkomandi ráðgjafa.

Innbyggð skýjaþjónusta

Ég skrifaði þegar hér að ofan að margar skýjaþjónustur í dag bjóða ekki upp á neina upplýsingaöryggiseftirlitsgetu. Almennt séð taka þeir ekki mikla athygli á efni upplýsingaöryggis. Til dæmis, ein af vinsælustu rússnesku þjónustunum til að senda skýrslur til ríkisstofnana í gegnum internetið (ég mun ekki nefna nafn þess sérstaklega). Allur hlutinn um öryggi þessarar þjónustu snýst um notkun vottaðs CIPF. Upplýsingaöryggishluti annarrar innlendrar skýjaþjónustu fyrir rafræna skjalastjórnun er ekkert öðruvísi. Þar er talað um opinber lykilskírteini, vottaða dulritun, útrýmingu vefveikleika, vernd gegn DDoS árásum, notkun eldveggi, afrit og jafnvel reglulegar úttektir á upplýsingaöryggi. En ekki orð um vöktun, né um möguleikann á að fá aðgang að upplýsingaöryggisatburðum sem gætu verið áhugaverðir fyrir viðskiptavini þessa þjónustuveitanda.

Almennt séð, með því hvernig skýjaveitan lýsir upplýsingaöryggismálum á vefsíðu sinni og í skjölum sínum, geturðu skilið hversu alvarlega hún tekur þetta mál. Til dæmis, ef þú lest handbækurnar fyrir „My Office“ vörurnar, er alls ekki orð um öryggi, heldur í skjölunum fyrir sérstaka vöruna „My Office. KS3“, hannað til að vernda gegn óviðkomandi aðgangi, er venjulega listi yfir punkta af 17. röð FSTEC, sem „My Office.KS3“ útfærir, en ekki er lýst hvernig það útfærir það og, síðast en ekki síst, hvernig á að útfæra það. samþætta þessar aðferðir við upplýsingaöryggi fyrirtækja. Kannski eru slík skjöl til, en ég fann þau ekki á almenningi, á vefsíðunni „My Office“. Þó ég hafi kannski bara ekki aðgang að þessum leynilegum upplýsingum? ..

Fyrir Bitrix er staðan miklu betri. Skjölin lýsir sniði atburðaskránna og, athyglisvert, afskiptaskránni, sem inniheldur atburði sem tengjast hugsanlegum ógnum við skýjapallinn. Þaðan geturðu dregið út IP, notanda- eða gestanafn, viðburðaruppsprettu, tíma, notandaumboðsmann, tegund viðburðar osfrv. Að vísu geturðu unnið með þessa atburði annað hvort frá stjórnborði skýsins sjálfs eða hlaðið upp gögnum á MS Excel sniði. Það er nú erfitt að gera sjálfvirkan vinnu með Bitrix logs og þú verður að gera hluta af vinnunni handvirkt (hlaða upp skýrslunni og hlaða henni inn í SIEM þinn). En ef við minnumst þess að þar til tiltölulega nýlega var slíkt tækifæri ekki til staðar, þá eru þetta miklar framfarir. Á sama tíma vil ég taka fram að margar erlendar skýjaveitur bjóða upp á svipaða virkni „fyrir byrjendur“ - annaðhvort skoðaðu annálana með augunum í gegnum stjórnborðið eða hlaðið gögnunum upp á sjálfan þig (þó flest hlaða upp gögnum í . csv sniði, ekki Excel).

Án þess að taka tillit til valmöguleikans án skráningar bjóða skýjaveitendur þér venjulega þrjá valkosti til að fylgjast með öryggisatburðum - mælaborð, gagnaupphleðslu og API aðgang. Fyrsta virðist leysa mörg vandamál fyrir þig, en þetta er ekki alveg satt - ef þú átt nokkur tímarit þarftu að skipta á milli skjáanna sem sýna þau og missa heildarmyndina. Að auki er ólíklegt að skýjaveitan veiti þér möguleika á að tengja öryggisatburði og almennt greina þá frá öryggissjónarmiði (venjulega ertu að fást við hrá gögn, sem þú þarft að skilja sjálfur). Það eru undantekningar og við munum ræða þær frekar. Að lokum er þess virði að spyrja hvaða atburði eru skráðir af skýjaveitunni þinni, á hvaða sniði og hvernig samsvara þeir eftirlitsferli upplýsingaöryggis þíns? Til dæmis auðkenning og auðkenning notenda og gesta. Sama Bitrix gerir þér kleift, byggt á þessum atburðum, að skrá dagsetningu og tíma viðburðarins, nafn notanda eða gesta (ef þú ert með „vefgreiningar“ eininguna), hlutinn sem aðgangur er að og aðra þætti sem eru dæmigerðir fyrir vefsíðu. . En upplýsingaöryggisþjónusta fyrirtækja gæti þurft upplýsingar um hvort notandinn hafi fengið aðgang að skýinu frá traustu tæki (td í fyrirtækjaneti er þetta verkefni útfært af Cisco ISE). Hvað með svo einfalt verkefni eins og geo-IP aðgerðina, sem mun hjálpa til við að ákvarða hvort notendareikningi skýjaþjónustu hafi verið stolið? Og jafnvel þótt skýjafyrirtækið útvegi þér það, þá er þetta ekki nóg. Sami Cisco CloudLock greinir ekki bara landfræðilega staðsetningu heldur notar vélanám til þess og greinir söguleg gögn fyrir hvern notanda og fylgist með ýmsum frávikum í auðkenningar- og auðkenningartilraunum. Aðeins MS Azure hefur svipaða virkni (ef þú ert með viðeigandi áskrift).

Það er annar vandi - þar sem fyrir marga skýjaveitur er upplýsingaöryggiseftirlit nýtt efni sem þeir eru rétt að byrja að takast á við, þeir eru stöðugt að breyta einhverju í lausnum sínum. Í dag eru þeir með eina útgáfu af API, á morgun aðra, á morgun þá þriðju. Þú þarft líka að vera tilbúinn fyrir þetta. Það sama á við um virkni sem getur breyst sem þarf að taka tillit til í eftirlitskerfi upplýsingaöryggis þíns. Til dæmis hafði Amazon upphaflega sérstaka skýjaatburðaeftirlitsþjónustu - AWS CloudTrail og AWS CloudWatch. Þá birtist sérstök þjónusta til að fylgjast með upplýsingaöryggisatburðum - AWS GuardDuty. Eftir nokkurn tíma setti Amazon á markað nýtt stjórnunarkerfi, Amazon Security Hub, sem inniheldur greiningu á gögnum sem berast frá GuardDuty, Amazon Inspector, Amazon Macie og nokkrum öðrum. Annað dæmi er Azure log samþættingartólið með SIEM - AzLog. Það var virkt notað af mörgum SIEM söluaðilum, þar til árið 2018 tilkynnti Microsoft að þróun og stuðningur væri hætt, sem stóð frammi fyrir mörgum viðskiptavinum sem notuðu þetta tól með vandamál (við munum tala um hvernig það var leyst síðar).

Fylgstu því vandlega með öllum vöktunareiginleikum sem skýjaveitan þín býður þér. Eða treystu á utanaðkomandi lausnaveitendur sem munu starfa sem milliliðir milli SOC þíns og skýsins sem þú vilt fylgjast með. Já, það verður dýrara (þó ekki alltaf), en þú munt færa alla ábyrgð á herðar einhvers annars. Eða ekki allt? .. Við skulum muna hugtakið sameiginlegt öryggi og skilja að við getum ekki breytt neinu - við verðum að skilja sjálfstætt hvernig mismunandi skýjaveitur veita eftirlit með upplýsingaöryggi gagna þinna, forrita, sýndarvéla og annarra auðlinda hýst í skýinu. Og við byrjum á því sem Amazon býður upp á í þessum hluta.

Dæmi: Vöktun upplýsingaöryggis í IaaS byggt á AWS

Já, já, mér skilst að Amazon sé ekki besta dæmið vegna þess að þetta er amerísk þjónusta og hægt er að loka á hana sem hluti af baráttunni gegn öfgahyggju og miðlun upplýsinga sem er bönnuð í Rússlandi. En í þessu riti langar mig aðeins að sýna hvernig mismunandi skýjapallar eru mismunandi hvað varðar eftirlitsgetu upplýsingaöryggis og hvað þú ættir að borga eftirtekt til þegar þú flytur lykilferla þína yfir í skýin frá öryggissjónarmiði. Jæja, ef sumir af rússnesku verktaki skýjalausna læra eitthvað gagnlegt fyrir sig, þá verður það frábært.

Það fyrsta sem þarf að segja er að Amazon er ekki órjúfanlegt vígi. Ýmis atvik gerast reglulega hjá skjólstæðingum hans. Til dæmis var nöfnum, heimilisföngum, fæðingardögum og símanúmerum 198 milljóna kjósenda stolið úr Deep Root Analytics. Ísraelska fyrirtækið Nice Systems stal 14 milljón skrám yfir áskrifendur Verizon. Hins vegar gerir innbyggður möguleiki AWS þér kleift að greina margs konar atvik. Til dæmis:

áhrif á innviði (DDoS)
hnút málamiðlun (skipunarinnspýting)
málamiðlun reiknings og óviðkomandi aðgangs
rangar stillingar og veikleikar
óörugg viðmót og API.

Þetta misræmi stafar af því að, eins og við komumst að hér að ofan, er viðskiptavinurinn sjálfur ábyrgur fyrir öryggi gagna viðskiptavina. Og ef hann nennti ekki að kveikja á hlífðarbúnaði og kveikti ekki á eftirlitstækjum, þá mun hann aðeins læra um atvikið frá fjölmiðlum eða frá viðskiptavinum sínum.

Til að bera kennsl á atvik geturðu notað fjölbreytt úrval af mismunandi vöktunarþjónustu sem Amazon hefur þróað (þó að þetta sé oft bætt við utanaðkomandi verkfæri eins og osquery). Þannig að í AWS er fylgst með öllum aðgerðum notenda, óháð því hvernig þær eru framkvæmdar - í gegnum stjórnborðið, skipanalínuna, SDK eða aðra AWS þjónustu. Allar skrár yfir virkni hvers AWS reiknings (þar á meðal notendanafn, aðgerð, þjónusta, virknibreytur og niðurstöður) og API notkun eru fáanlegar í gegnum AWS CloudTrail. Þú getur skoðað þessa atburði (eins og AWS IAM innskráningu á vélinni) frá CloudTrail vélinni, greint þá með Amazon Athena, eða „útvistað“ þeim í utanaðkomandi lausnir eins og Splunk, AlienVault o.s.frv. AWS CloudTrail annálarnir sjálfir eru settir í AWS S3 fötuna þína.

Tvær aðrar AWS þjónustur bjóða upp á fjölda annarra mikilvægra eftirlitsgetu. Í fyrsta lagi er Amazon CloudWatch eftirlitsþjónusta fyrir AWS auðlindir og forrit sem meðal annars gerir þér kleift að bera kennsl á ýmis frávik í skýinu þínu. Öll innbyggð AWS þjónusta, eins og Amazon Elastic Compute Cloud (þjónar), Amazon Relational Database Service (gagnagrunnar), Amazon Elastic MapReduce (gagnagreining) og 30 aðrar Amazon þjónustur, nota Amazon CloudWatch til að geyma annála sína. Hönnuðir geta notað opna API frá Amazon CloudWatch til að bæta virkni skráningarvöktunar við sérsniðin forrit og þjónustu, sem gerir þeim kleift að auka umfang atburðagreiningar í öryggissamhengi.

Í öðru lagi gerir VPC Flow Logs þjónustan þér kleift að greina netumferð sem send er eða móttekin af AWS netþjónum þínum (ytri eða innri), sem og milli örþjónustu. Þegar eitthvað af AWS VPC auðlindum þínum hefur samskipti við netið, skráir VPC Flow Logs upplýsingar um netumferðina, þar á meðal uppruna- og áfanganetviðmótið, svo og IP tölur, gáttir, samskiptareglur, fjölda bæta og fjölda pakka sem þú sá. Þeir sem hafa reynslu af staðbundnu netöryggi munu kannast við að þetta sé hliðstætt þræði NetFlow, sem hægt er að búa til með rofum, beinum og eldveggjum í fyrirtækisgráðu. Þessar annálar eru mikilvægar fyrir upplýsingaöryggiseftirlit vegna þess að ólíkt atburðum um aðgerðir notenda og forrita leyfa þeir þér einnig að missa af netsamskiptum í AWS sýndar einkaskýjaumhverfinu.

Í stuttu máli, þessar þrjár AWS þjónusta — AWS CloudTrail, Amazon CloudWatch og VPC Flow Logs — veita saman nokkuð öfluga innsýn í reikningsnotkun þína, notendahegðun, innviðastjórnun, virkni forrita og þjónustu og netvirkni. Til dæmis er hægt að nota þau til að greina eftirfarandi frávik:

Tilraunir til að skanna síðuna, leita að bakdyrum, leita að veikleikum með „404 villum“.
Innspýtingarárásir (til dæmis SQL innspýting) með „500 villum“.
Þekkt árásartæki eru sqlmap, nikto, w3af, nmap o.s.frv. með greiningu á reitnum User Agent.

Amazon Web Services hefur einnig þróað aðra þjónustu í netöryggistilgangi sem gerir þér kleift að leysa mörg önnur vandamál. Til dæmis er AWS með innbyggða þjónustu fyrir endurskoðunarstefnur og stillingar - AWS Config. Þessi þjónusta veitir stöðuga endurskoðun á AWS auðlindum þínum og stillingum þeirra. Tökum einfalt dæmi: Segjum að þú viljir ganga úr skugga um að lykilorð notenda séu óvirk á öllum netþjónum þínum og að aðgangur sé aðeins mögulegur á grundvelli vottorða. AWS Config gerir það auðvelt að athuga þetta fyrir alla netþjóna þína. Það eru aðrar reglur sem hægt er að beita á skýjaþjónana þína: „Enginn þjónn getur notað port 22“, „Aðeins stjórnendur geta breytt eldveggsreglum“ eða „Aðeins notandinn Ivashko getur búið til nýja notendareikninga og hann getur gert það bara á þriðjudögum. " Sumarið 2016 var AWS Config þjónustan stækkuð til að gera sjálfvirka greiningu á brotum á þróuðum reglum. AWS Config Reglur eru í meginatriðum samfelldar stillingarbeiðnir fyrir Amazon þjónustuna sem þú notar, sem búa til atburði ef samsvarandi reglur eru brotnar. Til dæmis, í stað þess að keyra reglulega AWS Config fyrirspurnir til að sannreyna að allir diskar á sýndarþjóni séu dulkóðaðir, er hægt að nota AWS Config Reglur til að athuga stöðugt netþjónsdiska til að tryggja að þetta skilyrði sé uppfyllt. Og síðast en ekki síst, í tengslum við þessa útgáfu, mynda öll brot atburði sem hægt er að greina af upplýsingaöryggisþjónustunni þinni.

AWS hefur líka sitt jafngildi hefðbundinna upplýsingaöryggislausna fyrirtækja, sem einnig búa til öryggisatburði sem þú getur og ætti að greina:

Innbrotsgreining - AWS GuardDuty
Stjórnun upplýsingaleka - AWS Macie
EDR (þó það tali svolítið undarlega um endapunkta í skýinu) - AWS Cloudwatch + open source osquery eða GRR lausnir
Netflæðisgreining - AWS Cloudwatch + AWS VPC Flow
DNS greining - AWS Cloudwatch + AWS Route53
AD - AWS skráaþjónusta
Reikningsstjórnun - AWS IAM
SSO - AWS SSO
öryggisgreining - AWS Inspector
stillingarstjórnun - AWS Config
WAF - AWS WAF.

Ég mun ekki lýsa í smáatriðum allri þjónustu Amazon sem gæti verið gagnleg í tengslum við upplýsingaöryggi. Aðalatriðið er að skilja að allir geta framkallað atburði sem við getum og ættum að greina í samhengi við upplýsingaöryggi og nota í þessu skyni bæði innbyggða getu Amazon sjálfrar og utanaðkomandi lausnir, til dæmis SIEM, sem geta farðu með öryggisatburði í eftirlitsstöðina þína og greindu þá þar ásamt atburðum frá annarri skýjaþjónustu eða frá innri innviðum, jaðar- eða fartækjum.

Í öllum tilvikum byrjar þetta allt með gagnaheimildum sem veita þér upplýsingaöryggisatburði. Þessar heimildir innihalda, en takmarkast ekki við:

CloudTrail - API notkun og notendaaðgerðir
Traustur ráðgjafi - öryggisathugun gegn bestu starfsvenjum
Config - skrá og uppsetning reikninga og þjónustustillinga
VPC Flow Logs - tengingar við sýndarviðmót
IAM - auðkenningar- og auðkenningarþjónusta
ELB aðgangsskrár - álagsjafnari
Eftirlitsmaður - veikleikar í forritum
S3 - skráargeymsla
CloudWatch - Forritavirkni
SNS er tilkynningaþjónusta.

Amazon býður upp á slíkt úrval af viðburðaheimildum og verkfærum fyrir sína kynslóð, en er mjög takmörkuð í getu sinni til að greina söfnuð gögn í samhengi við upplýsingaöryggi. Þú verður að rannsaka sjálfstætt tiltæka annála og leita að viðeigandi vísbendingum um málamiðlun í þeim. AWS Security Hub, sem Amazon hóf nýlega, miðar að því að leysa þetta vandamál með því að verða skýja SIEM fyrir AWS. En enn sem komið er er það aðeins í upphafi ferða sinnar og takmarkast bæði af fjölda heimilda sem það vinnur með og af öðrum takmörkunum sem settar eru af arkitektúr og áskriftum Amazon sjálfs.

Dæmi: Vöktun upplýsingaöryggis í IaaS byggt á Azure

Ég vil ekki fara út í langa umræðu um hvor af þremur skýjaveitum (Amazon, Microsoft eða Google) er betri (sérstaklega þar sem hver þeirra hefur enn sína sérstöðu og hentar til að leysa eigin vandamál); Við skulum einbeita okkur að vöktunargetu upplýsingaöryggis sem þessir leikmenn bjóða upp á. Það verður að viðurkennast að Amazon AWS var einn af þeim fyrstu í þessum flokki og hefur því náð lengst í upplýsingaöryggisaðgerðum sínum (þótt margir viðurkenni að þeir séu erfiðir í notkun). En þetta þýðir ekki að við munum hunsa tækifærin sem Microsoft og Google veita okkur.

Microsoft vörur hafa alltaf verið aðgreindar með „opnun“ þeirra og í Azure er ástandið svipað. Til dæmis, ef AWS og GCP ganga alltaf út frá hugmyndinni um „það sem er ekki leyfilegt er bannað,“ þá hefur Azure nákvæmlega andstæða nálgun. Til dæmis, þegar búið er til sýndarnet í skýinu og sýndarvél í því, eru allar hafnir og samskiptareglur opnar og leyfðar sjálfgefið. Þess vegna verður þú að eyða aðeins meiri fyrirhöfn í fyrstu uppsetningu aðgangsstýringarkerfisins í skýinu frá Microsoft. Og þetta setur líka strangari kröfur á þig hvað varðar eftirlit með virkni í Azure skýinu.

AWS hefur sérkenni í tengslum við þá staðreynd að þegar þú fylgist með sýndarauðlindum þínum, ef þær eru staðsettar á mismunandi svæðum, þá átt þú í erfiðleikum með að sameina alla atburði og sameinaða greiningu þeirra, til að útrýma þeim sem þú þarft að grípa til ýmissa brellna, eins og Búðu til þinn eigin kóða fyrir AWS Lambda sem mun flytja viðburði á milli svæða. Azure á ekki við þetta vandamál að stríða - virkniskrárbúnaður þess rekur alla virkni í öllu skipulagi án takmarkana. Sama á við um AWS Security Hub, sem nýlega var þróað af Amazon til að sameina margar öryggisaðgerðir innan einnar öryggismiðstöðvar, en aðeins innan svæðis þess, sem þó á ekki við fyrir Rússland. Azure hefur sína eigin öryggismiðstöð, sem er ekki bundin af svæðisbundnum takmörkunum, sem veitir aðgang að öllum öryggiseiginleikum skýjapallsins. Þar að auki, fyrir mismunandi staðbundin teymi, getur það útvegað sitt eigið sett af verndarmöguleikum, þar á meðal öryggisatburði sem stjórnað er af þeim. AWS Security Hub er enn á leiðinni til að verða svipað og Azure Security Center. En það er þess virði að bæta við flugu í smyrslinu - þú getur kreist út úr Azure mikið af því sem áður var lýst í AWS, en þetta er þægilegast gert aðeins fyrir Azure AD, Azure Monitor og Azure Security Center. Öllum öðrum Azure öryggisaðferðum, þar með talið öryggisatburðagreiningu, er ekki enn stjórnað á sem þægilegastan hátt. Vandamálið er að hluta til leyst með API, sem gegnsýrir alla Microsoft Azure þjónustu, en þetta mun krefjast aukinnar áreynslu frá þér til að samþætta skýið þitt við SOC og nærveru hæfra sérfræðinga (reyndar eins og með öll önnur SIEM sem vinnur með skýinu API). Sumar SIEM, sem verða ræddar síðar, styðja nú þegar Azure og geta sjálfvirkt verkefnið að fylgjast með því, en það hefur líka sína erfiðleika - ekki allir geta safnað öllum annálum sem Azure hefur.

Atburðasöfnun og eftirlit í Azure er veitt með því að nota Azure Monitor þjónustuna, sem er aðal tólið til að safna, geyma og greina gögn í Microsoft skýinu og auðlindum þess - Git geymslum, gámum, sýndarvélum, forritum o.s.frv. Öllum gögnum sem safnað er af Azure Monitor er skipt í tvo flokka - mælikvarða, safnað í rauntíma og lýsa lykilframmistöðuvísum Azure skýsins, og logs, sem innihalda gögn skipulögð í skrár sem einkenna ákveðna þætti virkni Azure auðlinda og þjónustu. Að auki, með því að nota Data Collector API, getur Azure Monitor þjónustan safnað gögnum frá hvaða REST uppsprettu sem er til að búa til eigin vöktunarsviðsmyndir.

Hér eru nokkrar heimildir fyrir öryggisatburði sem Azure býður þér og þú getur fengið aðgang að í gegnum Azure Portal, CLI, PowerShell eða REST API (og sumar aðeins í gegnum Azure Monitor/Insight API):

Athafnaskrár - þessi skrá svarar klassískum spurningum um „hver,“ „hvað,“ og „hvenær“ varðandi hvaða skrifaðgerð sem er (PUT, POST, DELETE) á skýjaauðlindum. Atburðir sem tengjast lesaðgangi (GET) eru ekki með í þessari annál, eins og fjöldi annarra.
Greiningarskrár - inniheldur gögn um aðgerðir með tiltekinni auðlind sem er innifalin í áskriftinni þinni.
Azure AD skýrslur - inniheldur bæði notendavirkni og kerfisvirkni sem tengist hóp- og notendastjórnun.
Windows Atburðaskrá og Linux Syslog - inniheldur viðburði frá sýndarvélum sem hýstar eru í skýinu.
Mælingar - inniheldur fjarmælingar um frammistöðu og heilsufar skýjaþjónustu þinna og auðlinda. Mælt á hverri mínútu og geymt. innan 30 daga.
Netöryggishópflæðisskrár - inniheldur gögn um netöryggisatburði sem safnað er með Network Watcher þjónustunni og auðlindaeftirliti á netstigi.
Geymsluskrár - inniheldur atburði sem tengjast aðgangi að geymsluaðstöðu.

Fyrir eftirlit geturðu notað ytri SIEM eða innbyggða Azure Monitor og viðbætur þess. Við munum tala um viðburðastjórnunarkerfi upplýsingaöryggis síðar, en í bili skulum við sjá hvað Azure sjálft býður okkur fyrir gagnagreiningu í samhengi við öryggi. Aðalskjárinn fyrir allt öryggistengt í Azure Monitor er Log Analytics Security and Audit Dashboard (ókeypis útgáfan styður takmarkað magn af viðburðageymslu í aðeins eina viku). Þessu mælaborði er skipt í 5 meginsvið sem sýna yfirlitstölfræði yfir það sem er að gerast í skýjaumhverfinu sem þú notar:

Öryggislén - helstu magnvísar sem tengjast upplýsingaöryggi - fjöldi atvika, fjöldi hnúta sem eru í hættu, hnúta sem ekki hafa verið lagaðir, netöryggisatburðir o.s.frv.
Athyglisverð vandamál - sýnir fjölda og mikilvægi virkra upplýsingaöryggismála
Uppgötvun - sýnir mynstur árása sem notuð eru gegn þér
Threat Intelligence - sýnir landfræðilegar upplýsingar um ytri hnúta sem ráðast á þig
Algengar öryggisfyrirspurnir - dæmigerðar fyrirspurnir sem hjálpa þér að fylgjast betur með upplýsingaöryggi þínu.

Azure Monitor viðbætur innihalda Azure Key Vault (vernd dulmálslykla í skýinu), Malware Assessment (greining á vörnum gegn skaðlegum kóða á sýndarvélum), Azure Application Gateway Analytics (greining á m.a. skýjaeldveggsskrám) o.fl. . Þessi verkfæri, auðguð með ákveðnum reglum um vinnslu atburða, gera þér kleift að sjá fyrir þér ýmsa þætti í starfsemi skýjaþjónustu, þar á meðal öryggi, og bera kennsl á ákveðin frávik frá rekstri. En, eins og oft gerist, krefst öll viðbótarvirkni samsvarandi greiddra áskriftar, sem mun krefjast samsvarandi fjárhagslegra fjárfestinga frá þér, sem þú þarft að skipuleggja fyrirfram.

Azure er með fjölda innbyggðra ógnarvöktunarmöguleika sem eru samþættir Azure AD, Azure Monitor og Azure Security Center. Meðal þeirra, til dæmis, uppgötvun á samskiptum sýndarvéla við þekktar skaðlegar IP-tölur (vegna tilvistar samþættingar við Threat Intelligence þjónustur frá Microsoft), uppgötvun spilliforrita í skýjainnviðum með því að fá viðvörun frá sýndarvélum sem hýstar eru í skýinu, lykilorð giska árásir ” á sýndarvélar, veikleika í uppsetningu notendaauðkenningarkerfisins, innskráning í kerfið frá nafnlausum eða sýktum hnútum, reikningsleki, innskráning í kerfið frá óvenjulegum stöðum o.s.frv. Azure í dag er einn af fáum skýjaveitum sem býður þér innbyggða Threat Intelligence getu til að auðga safnaða upplýsingaöryggisatburði.

Eins og fram kemur hér að ofan er öryggisvirknin og þar af leiðandi öryggisatburðir sem myndast af henni ekki jafnt aðgengilegir öllum notendum, heldur þarf tiltekna áskrift sem inniheldur þá virkni sem þú þarft, sem býr til viðeigandi atburði fyrir eftirlit með upplýsingaöryggi. Til dæmis eru sumar aðgerðir sem lýst er í fyrri málsgrein til að fylgjast með frávikum í reikningum aðeins fáanlegar í P2 aukagjaldaleyfinu fyrir Azure AD þjónustuna. Án þess verður þú, eins og í tilfelli AWS, að greina safnað öryggisatburði „handvirkt“. Og líka, allt eftir tegund Azure AD leyfis, verða ekki allir atburðir tiltækir til greiningar.

Á Azure-gáttinni geturðu stjórnað bæði leitarfyrirspurnum fyrir annála sem þú hefur áhuga á og sett upp mælaborð til að sjá lykilupplýsingaröryggisvísa. Þar að auki geturðu valið Azure Monitor viðbætur, sem gera þér kleift að auka virkni Azure Monitor logs og fá dýpri greiningu á atburðum frá öryggissjónarmiði.

Ef þú þarft ekki aðeins getu til að vinna með annálum, heldur alhliða öryggismiðstöð fyrir Azure skýjapallinn þinn, þar á meðal stjórnun upplýsingaöryggisstefnu, þá geturðu talað um nauðsyn þess að vinna með Azure Security Center, sem flestar gagnlegar aðgerðir sem eru fáanlegar fyrir einhvern pening, til dæmis, ógnunargreining, eftirlit utan Azure, samræmismat o.s.frv. (í ókeypis útgáfunni hefurðu aðeins aðgang að öryggismati og ráðleggingum til að útrýma auðkenndum vandamálum). Það sameinar öll öryggismál á einum stað. Reyndar getum við talað um hærra stigi upplýsingaöryggis en Azure Monitor veitir þér, þar sem í þessu tilfelli eru gögnin sem safnað er um skýjaverksmiðjuna þína auðgað með mörgum heimildum, svo sem Azure, Office 365, Microsoft CRM á netinu, Microsoft Dynamics AX , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) og Microsoft Security Response Center (MSRC), þar sem ýmsar háþróaðar vélanáms- og atferlisgreiningar reiknirit eru lögð ofan á, sem ætti að lokum að bæta skilvirkni við að greina og bregðast við ógnum .

Azure hefur líka sitt eigið SIEM - það birtist í byrjun árs 2019. Þetta er Azure Sentinel, sem byggir á gögnum frá Azure Monitor og getur einnig samþætt við. utanaðkomandi öryggislausnir (til dæmis NGFW eða WAF), listinn yfir þær stækkar stöðugt. Að auki, með samþættingu Microsoft Graph Security API, hefurðu möguleika á að tengja þína eigin Threat Intelligence strauma við Sentinel, sem auðgar getu til að greina atvik í Azure skýinu þínu. Það má færa rök fyrir því að Azure Sentinel sé fyrsti „innfæddi“ SIEM sem birtist frá skýjaveitum (sama Splunk eða ELK, sem hægt er að hýsa í skýinu, til dæmis, AWS, eru enn ekki þróaðar af hefðbundnum skýjaþjónustuaðilum). Azure Sentinel and Security Center gæti verið kallað SOC fyrir Azure skýið og gæti verið takmarkað við þau (með ákveðnum fyrirvörum) ef þú varst ekki lengur með neina innviði og þú færðir allar tölvuauðlindir þínar í skýið og það væri Microsoft skýið Azure.

En þar sem innbyggður möguleiki Azure (jafnvel þó þú sért með áskrift að Sentinel) dugar oft ekki til þess að fylgjast með upplýsingaöryggi og samþætta þetta ferli við aðrar uppsprettur öryggisatburða (bæði í skýi og innri), þá er þarf að flytja gögnin sem safnað er út í utanaðkomandi kerfi, sem gæti falið í sér SIEM. Þetta er gert bæði með því að nota API og með því að nota sérstakar viðbætur, sem nú eru opinberlega aðeins fáanlegar fyrir eftirfarandi SIEM - Splunk (Azure Monitor viðbót fyrir Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight og ELK. Þar til nýlega voru fleiri slíkar SIEM, en frá 1. júní 2019 hætti Microsoft að styðja Azure Log Integration Tool (AzLog), sem í upphafi tilvistar Azure og þar sem ekki var eðlileg stöðlun á vinnu með logs (Azure) Monitor var ekki einu sinni til ennþá) gerði það auðvelt að samþætta ytri SIEM við Microsoft skýið. Nú hefur ástandið breyst og Microsoft mælir með Azure Event Hub pallinum sem aðal samþættingartæki fyrir önnur SIEM. Margir hafa þegar innleitt slíka samþættingu, en farðu varlega - það er ekki víst að þeir fanga alla Azure logs, heldur aðeins suma (kíktu í skjölin fyrir SIEM þinn).

Í lok stuttrar skoðunarferðar um Azure langar mig að gefa almennar ráðleggingar um þessa skýjaþjónustu - áður en þú segir eitthvað um eftirlitsaðgerðir upplýsingaöryggis í Azure ættir þú að stilla þær mjög vandlega og prófa að þær virki eins og skrifað er í skjölunum og eins og ráðgjafarnir sögðu þér frá Microsoft (og þeir kunna að hafa mismunandi skoðanir á virkni Azure aðgerða). Ef þú hefur fjármagn geturðu kreist út fullt af gagnlegum upplýsingum frá Azure hvað varðar eftirlit með upplýsingaöryggi. Ef auðlindir þínar eru takmarkaðar, þá, eins og í tilfelli AWS, verður þú aðeins að treysta á þinn eigin styrk og hráu gögnin sem Azure Monitor veitir þér. Og mundu að margar eftirlitsaðgerðir kosta peninga og það er betra að kynna þér verðstefnuna fyrirfram. Til dæmis, ókeypis geturðu geymt 31 dag af gögnum að hámarki 5 GB á hvern viðskiptavin - ef farið er yfir þessi gildi mun þú þurfa að punga út aukapeningum (u.þ.b. $2+ fyrir að geyma hvert viðbótar GB frá viðskiptavininum og $0,1 fyrir geymir 1 GB í hverjum mánuði til viðbótar). Að vinna með fjarmælingu forrita og mæligildi gæti einnig krafist viðbótarfjármagns, auk þess að vinna með viðvaranir og tilkynningar (ákveðin hámark er ókeypis, sem gæti ekki verið nóg fyrir þínum þörfum).

Dæmi: Vöktun upplýsingaöryggis í IaaS byggt á Google Cloud Platform

Google Cloud Platform lítur út eins og unglingur miðað við AWS og Azure, en þetta er að hluta til gott. Ólíkt AWS, sem jók getu sína, þar á meðal öryggisgetu, smám saman, í vandræðum með miðstýringu; GCP, eins og Azure, er miklu betur stjórnað miðlægt, sem dregur úr villum og innleiðingartíma í fyrirtækinu. Frá öryggissjónarmiði er GCP, einkennilega nóg, á milli AWS og Azure. Hann er líka með eina viðburðaskráningu fyrir allt skipulagið, en það er ófullnægjandi. Sumar aðgerðir eru enn í beta-ham, en smám saman ætti að útrýma þessum skort og GCP verður þroskaðri vettvangur hvað varðar eftirlit með upplýsingaöryggi.

Helsta tólið til að skrá atburði í GCP er Stackdriver Logging (svipað og Azure Monitor), sem gerir þér kleift að safna atburðum yfir allan skýjainnviðina (sem og frá AWS). Frá öryggissjónarmiði í GCP hefur hver stofnun, verkefni eða mappa fjórar annálar:

Admin Activity - inniheldur alla atburði sem tengjast stjórnunaraðgangi, til dæmis að búa til sýndarvél, breyta aðgangsréttindum o.s.frv. Þessi annál er alltaf skrifuð, óháð ósk þinni, og geymir gögnin í 400 daga.
Gagnaaðgangur - inniheldur alla atburði sem tengjast vinnu með gögn skýnotenda (gerð, breyting, lestur osfrv.). Sjálfgefið er að þessi annál er ekki skrifuð þar sem rúmmál hans stækkar mjög hratt. Af þessum sökum er geymsluþol þess aðeins 30 dagar. Auk þess er ekki allt skrifað í þetta blað. Til dæmis eru atburðir sem tengjast auðlindum sem eru aðgengilegir öllum notendum almenningi eða sem eru aðgengilegir án þess að skrá þig inn á GCP ekki skrifaðir á það.
Kerfisviðburður - inniheldur kerfisatburði sem ekki tengjast notendum, eða aðgerðir stjórnanda sem breytir uppsetningu skýjaauðlinda. Það er alltaf skrifað og geymt í 400 daga.
Access Transparency er einstakt dæmi um annál sem fangar allar aðgerðir starfsmanna Google (en ekki enn fyrir alla GCP þjónustu) sem fá aðgang að innviðum þínum sem hluta af starfsskyldum sínum. Þessi annál er geymd í 400 daga og er ekki í boði fyrir alla GCP-viðskiptavini, heldur aðeins ef nokkrum skilyrðum er fullnægt (annaðhvort stuðningur á gulli eða platínustigi, eða tilvist 4 hlutverka af ákveðinni gerð sem hluti af stuðningi fyrirtækja). Svipuð aðgerð er einnig fáanleg, til dæmis í Office 365 - Lockbox.

Dagskrárdæmi: Aðgangur gagnsæi

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

Aðgangur að þessum annálum er mögulegur á nokkra vegu (á nokkurn hátt á sama hátt og áður hefur verið fjallað um Azure og AWS) - í gegnum Log Viewer viðmótið, í gegnum API, í gegnum Google Cloud SDK, eða í gegnum virknisíðu verkefnisins sem þú ert fyrir. hafa áhuga á viðburðum. Á sama hátt er hægt að flytja þær út í ytri lausnir til viðbótargreiningar. Hið síðarnefnda er gert með því að flytja út annála til BigQuery eða Cloud Pub/Sub geymslu.

Auk Stackdriver Logging býður GCP vettvangurinn einnig Stackdriver Monitoring virkni, sem gerir þér kleift að fylgjast með lykilmælingum (frammistöðu, MTBF, heildarheilbrigði osfrv.) skýjaþjónustu og forrita. Unnin og sjónræn gögn geta gert það auðveldara að finna vandamál í skýjainnviðum þínum, þar á meðal í tengslum við öryggi. En það skal tekið fram að þessi virkni verður ekki mjög rík í tengslum við upplýsingaöryggi, þar sem í dag er GCP ekki með hliðstæðu við sama AWS GuardDuty og getur ekki greint slæma meðal allra skráðra atburða (Google hefur þróað Event Threat Detection, en það er enn í þróun í beta og það er of snemmt að tala um notagildi þess). Hægt væri að nota Stackdriver eftirlit sem kerfi til að greina frávik, sem síðan yrði rannsakað til að finna orsakir þess að þær komu upp. En í ljósi skorts á starfsfólki sem er hæft á sviði GCP upplýsingaöryggis á markaðnum lítur þetta verkefni erfitt út eins og er.

Það er líka þess virði að gefa upp lista yfir nokkrar upplýsingaöryggiseiningar sem hægt er að nota í GCP skýinu þínu, og sem eru svipaðar því sem AWS býður upp á:

Cloud Security Command Center er hliðstæða AWS Security Hub og Azure Security Center.
Cloud DLP - Sjálfvirk uppgötvun og breyting (t.d. gríma) gagna sem hýst eru í skýinu með því að nota meira en 90 fyrirfram skilgreindar flokkunarreglur.
Cloud Scanner er skanni fyrir þekkta veikleika (XSS, Flash Injection, ópatched bókasöfn o.s.frv.) í App Engine, Compute Engine og Google Kubernetes.
Cloud IAM - Stjórna aðgangi að öllum GCP auðlindum.
Cloud Identity - Stjórnaðu GCP notenda-, tækja- og forritareikningum frá einni stjórnborði.
Cloud HSM - vernd dulmálslykla.
Cloud Key Management Service - stjórnun dulmálslykla í GCP.
VPC þjónustustýring - Búðu til örugga jaðar í kringum GCP auðlindirnar þínar til að vernda þau gegn leka.
Titan öryggislykill - vörn gegn vefveiðum.

Margar þessara eininga búa til öryggisatburði sem hægt er að senda í BigQuery geymslu til greiningar eða útflutnings í önnur kerfi, þar á meðal SIEM. Eins og getið er hér að ofan er GCP vettvangur í virkri þróun og Google er nú að þróa fjölda nýrra upplýsingaöryggiseininga fyrir vettvang sinn. Meðal þeirra eru Event Threat Detection (nú fáanlegt í beta), sem skannar Stackdriver annála í leit að ummerkjum um óviðkomandi virkni (sambærilegt GuardDuty í AWS), eða Policy Intelligence (fáanlegt í alfa), sem gerir þér kleift að þróa greindar stefnur fyrir aðgang að GCP auðlindum.

Ég gerði stutt yfirlit yfir innbyggða eftirlitsgetu í vinsælum skýjapöllum. En ertu með sérfræðinga sem geta unnið með „hráa“ IaaS veitendaskrár (ekki allir tilbúnir til að kaupa háþróaða eiginleika AWS eða Azure eða Google)? Að auki kannast margir við orðtakið „treysta, en sannreyna,“ sem er sannara en nokkru sinni fyrr á sviði öryggis. Hversu mikið treystir þú innbyggðum getu skýjaveitunnar sem sendir þér upplýsingaöryggisatburði? Hversu mikið leggja þeir áherslu á upplýsingaöryggi yfirleitt?

Stundum er þess virði að skoða vöktunarlausnir á skýjagrunni sem geta bætt við innbyggt skýjaöryggi og stundum eru slíkar lausnir eini kosturinn til að fá innsýn í öryggi gagna og forrita sem hýst eru í skýinu. Að auki eru þeir einfaldlega þægilegri þar sem þeir taka að sér öll verkefnin við að greina nauðsynlega annála sem myndast af mismunandi skýjaþjónustu frá mismunandi skýjaveitum. Dæmi um slíka yfirlagslausn er Cisco Stealthwatch Cloud, sem einbeitir sér að einu verkefni - að fylgjast með upplýsingaöryggisfrávikum í skýjaumhverfi, þar á meðal ekki aðeins Amazon AWS, Microsoft Azure og Google Cloud Platform, heldur einnig einkaskýjum.

Dæmi: Vöktun upplýsingaöryggis með Stealthwatch Cloud

AWS býður upp á sveigjanlegan tölvuvettvang, en þessi sveigjanleiki auðveldar fyrirtækjum að gera mistök sem leiða til öryggisvandamála. Og sameiginlega upplýsingaöryggislíkanið stuðlar aðeins að þessu. Að keyra hugbúnað í skýinu með óþekktum veikleikum (þekkt er hægt að berjast gegn, til dæmis með AWS Inspector eða GCP Cloud Scanner), veik lykilorð, rangar stillingar, innherja o.s.frv. Og allt þetta endurspeglast í hegðun skýjaauðlinda, sem hægt er að fylgjast með með Cisco Stealthwatch Cloud, sem er upplýsingaöryggiseftirlits- og árásaskynjunarkerfi. opinber og einkaský.

Einn af lykileiginleikum Cisco Stealthwatch Cloud er hæfileikinn til að fyrirmynda einingar. Með því geturðu búið til hugbúnaðarlíkan (þ.e. næstum rauntíma uppgerð) af hverju skýjaauðlindinni þínu (það skiptir ekki máli hvort það er AWS, Azure, GCP eða eitthvað annað). Þetta geta falið í sér netþjóna og notendur, svo og auðlindategundir sem eru sértækar fyrir skýjaumhverfið þitt, svo sem öryggishópa og sjálfvirka kvarðahópa. Þessi líkön nota skipulagða gagnastrauma sem skýjaþjónustur veita sem inntak. Til dæmis, fyrir AWS væru þetta VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda og AWS IAM. Entity Modeling uppgötvar sjálfkrafa hlutverk og hegðun hvers kyns auðlinda þinna (þú getur talað um að sniðganga alla skýjavirkni). Þessi hlutverk fela í sér Android eða Apple farsíma, Citrix PVS netþjón, RDP netþjón, póstgátt, VoIP biðlara, útstöðvarþjón, lénsstýringu o.s.frv. Það fylgist síðan stöðugt með hegðun þeirra til að ákvarða hvenær áhættusöm eða öryggisógnandi hegðun á sér stað. Þú getur greint giska á lykilorð, DDoS árásir, gagnaleka, ólöglegan fjaraðgang, illgjarn kóðavirkni, varnarleysisskönnun og aðrar ógnir. Til dæmis lítur þetta út fyrir að greina tilraun til fjaraðgangs frá landi sem er óvenjulegt fyrir fyrirtæki þitt (Suður-Kórea) til Kubernetes-þyrpingar í gegnum SSH:

Og svona lítur meintur leki upplýsinga úr Postgress gagnagrunninum til lands sem við höfum ekki áður lent í samskiptum við:

Að lokum, þetta er hvernig of margar misheppnaðar SSH tilraunir frá Kína og Indónesíu frá ytra fjarlægu tæki líta út:

Eða gerðu ráð fyrir að netþjónstilvikið í VPC sé, samkvæmt stefnu, aldrei að vera ytri innskráningarstaður. Við skulum enn frekar gera ráð fyrir að þessi tölva hafi fundið fyrir ytri innskráningu vegna rangrar breytingar á reglum eldveggsins. Eiginleikinn Entity Modeling mun greina og tilkynna þessa virkni („óvenjulegur fjaraðgangur“) í næstum rauntíma og benda á tiltekið AWS CloudTrail, Azure Monitor eða GCP Stackdriver Logging API símtal (þar á meðal notendanafn, dagsetningu og tíma, meðal annarra upplýsinga ), sem olli breytingunni á ITU-reglunni. Og svo er hægt að senda þessar upplýsingar til SIEM til greiningar.

Svipuð möguleiki er útfærður fyrir hvaða skýjaumhverfi sem er stutt af Cisco Stealthwatch Cloud:

Entity Modeling er einstakt form öryggissjálfvirkni sem getur afhjúpað áður óþekkt vandamál með fólkið þitt, ferla eða tækni. Til dæmis gerir það þér kleift að greina meðal annars öryggisvandamál eins og:

Hefur einhver uppgötvað bakdyr í hugbúnaðinum sem við notum?
Er einhver hugbúnaður eða tæki frá þriðja aðila í skýinu okkar?
Misnotar viðurkenndur notandi réttindi?
Var uppsetningarvilla sem leyfði fjaraðgang eða aðra óviljandi notkun á tilföngum?
Er gagnaleki frá netþjónum okkar?
Var einhver að reyna að tengjast okkur frá óhefðbundnum landfræðilegum stað?
Er skýið okkar sýkt af skaðlegum kóða?

Uppgötvun upplýsingaöryggisatburðar er hægt að senda í formi samsvarandi miða til Slack, Cisco Spark, PagerDuty atvikastjórnunarkerfisins og einnig senda til ýmissa SIEM, þar á meðal Splunk eða ELK. Til að draga saman getum við sagt að ef fyrirtæki þitt notar fjölskýjastefnu og er ekki takmarkað við einn skýjaveitu, þá er upplýsingaöryggiseftirlitsmöguleikinn sem lýst er hér að ofan, þá er notkun Cisco Stealthwatch Cloud góður kostur til að fá sameinað eftirlitskerfi getu fyrir leiðandi skýjaspilara - Amazon, Microsoft og Google. Athyglisverðast er að ef borið er saman verð fyrir Stealthwatch Cloud við háþróuð leyfi fyrir upplýsingaöryggiseftirlit í AWS, Azure eða GCP, þá gæti komið í ljós að Cisco lausnin verði enn ódýrari en innbyggður möguleiki Amazon, Microsoft og Google lausnir. Það er þversagnakennt, en það er satt. Og því fleiri ský og getu þeirra sem þú notar, því augljósari verður kosturinn við samþætta lausn.

Að auki getur Stealthwatch Cloud fylgst með einkaskýjum sem eru notuð í fyrirtækinu þínu, til dæmis, byggð á Kubernetes gámum eða með því að fylgjast með Netflow flæði eða netumferð sem berast með speglun í netbúnaði (jafnvel innanlandsframleiddur), AD gögnum eða DNS netþjónum og svo framvegis. Öll þessi gögn verða auðguð með Threat Intelligence-upplýsingum sem safnað er af Cisco Talos, stærsta óopinbera hópi heims sem rannsakar netöryggisógnir.

Þetta gerir þér kleift að innleiða sameinað eftirlitskerfi fyrir bæði opinber og blendingsský sem fyrirtæki þitt gæti notað. Safnaðar upplýsingar er síðan hægt að greina með því að nota innbyggða möguleika Stealthwatch Cloud eða senda til SIEM þíns (Splunk, ELK, SumoLogic og nokkrir aðrir eru sjálfgefið studdir).

Með þessu munum við klára fyrsta hluta greinarinnar, þar sem ég fór yfir innbyggða og ytri verkfæri til að fylgjast með upplýsingaöryggi IaaS/PaaS kerfa, sem gera okkur kleift að greina fljótt og bregðast við atvikum sem eiga sér stað í skýjaumhverfinu sem fyrirtækið okkar hefur valið. Í seinni hlutanum munum við halda umræðuefninu áfram og skoða valkosti til að fylgjast með SaaS kerfum með því að nota dæmið Salesforce og Dropbox, og við munum einnig reyna að draga saman og setja allt saman með því að búa til sameinað upplýsingaöryggiseftirlitskerfi fyrir mismunandi skýjaveitur.

Heimild: www.habr.com

Skýjaöryggiseftirlit