🥇Ufuatiliaji wa usalama wa wingu

Kuhamisha data na programu kwenye wingu kunatoa changamoto mpya kwa SOC za mashirika, ambazo haziko tayari kufuatilia miundombinu ya watu wengine kila wakati. Kulingana na Netoskope, biashara ya wastani (inavyoonekana nchini Marekani) inatumia huduma tofauti za wingu 1246, ambayo ni 22% zaidi ya mwaka mmoja uliopita. 1246 huduma za wingu !!! 175 kati ya hizo zinahusiana na huduma za HR, 170 zinahusiana na uuzaji, 110 ziko katika uwanja wa mawasiliano na 76 ni za kifedha na CRM. Cisco hutumia huduma za "tu" 700 za nje za wingu. Kwa hivyo ninachanganyikiwa kidogo na nambari hizi. Lakini kwa hali yoyote, shida haiko nao, lakini kwa ukweli kwamba wingu linaanza kutumika kikamilifu na idadi inayoongezeka ya kampuni ambazo zingependa kuwa na uwezo sawa wa kuangalia miundombinu ya wingu kama kwenye mtandao wao wenyewe. Na hali hii inakua - kulingana na kulingana na Chemba ya Hesabu ya Marekani Kufikia 2023, vituo 1200 vya data vitafungwa nchini Merika (6250 tayari vimefungwa). Lakini mpito kwa wingu sio tu "wacha tuhamishe seva zetu kwa mtoaji wa nje." Usanifu mpya wa IT, programu mpya, taratibu mpya, vikwazo vipya ... Yote hii huleta mabadiliko makubwa kwa kazi ya sio tu ya IT, lakini pia usalama wa habari. Na ikiwa watoa huduma wamejifunza kwa namna fulani kukabiliana na kuhakikisha usalama wa wingu yenyewe (kwa bahati nzuri kuna mapendekezo mengi), basi kwa ufuatiliaji wa usalama wa habari wa wingu, hasa kwenye majukwaa ya SaaS, kuna matatizo makubwa, ambayo tutazungumzia.

Hebu tuseme kampuni yako imehamisha sehemu ya miundombinu yake kwenye wingu... Acha. Si kwa njia hii. Ikiwa miundombinu imehamishwa, na sasa unafikiri tu jinsi utakavyoifuatilia, basi tayari umepoteza. Isipokuwa ni Amazon, Google, au Microsoft (na kisha kwa kuweka nafasi), labda hutakuwa na uwezo mkubwa wa kufuatilia data na programu zako. Ni vizuri ikiwa unapewa fursa ya kufanya kazi na magogo. Wakati mwingine data ya tukio la usalama itapatikana, lakini hutaweza kuifikia. Kwa mfano, Ofisi ya 365. Ikiwa una leseni ya bei nafuu ya E1, basi matukio ya usalama hayapatikani kwako kabisa. Ikiwa una leseni ya E3, data yako imehifadhiwa kwa siku 90 tu, na tu ikiwa una leseni ya E5, muda wa magogo unapatikana kwa mwaka (hata hivyo, hii pia ina nuances yake mwenyewe kuhusiana na haja ya tofauti. omba idadi ya vitendaji vya kufanya kazi na kumbukumbu kutoka kwa usaidizi wa Microsoft). Kwa njia, leseni ya E3 ni dhaifu sana katika suala la kazi za ufuatiliaji kuliko Exchange ya ushirika. Ili kufikia kiwango sawa, unahitaji leseni ya E5 au leseni ya ziada ya Uzingatiaji wa Hali ya Juu, ambayo inaweza kuhitaji pesa za ziada ambazo hazikuwekwa katika muundo wako wa kifedha ili kuhamia miundombinu ya wingu. Na huu ni mfano mmoja tu wa kudharau masuala yanayohusiana na ufuatiliaji wa usalama wa taarifa za wingu. Katika makala hii, bila kujifanya kuwa kamili, nataka kuzingatia baadhi ya nuances ambayo inapaswa kuzingatiwa wakati wa kuchagua mtoaji wa wingu kutoka kwa mtazamo wa usalama. Na mwisho wa kifungu, orodha ya ukaguzi itatolewa ambayo inafaa kukamilishwa kabla ya kuzingatia kuwa suala la ufuatiliaji wa usalama wa habari wa wingu limetatuliwa.

Kuna shida kadhaa za kawaida ambazo husababisha matukio katika mazingira ya wingu, ambayo huduma za usalama wa habari hazina wakati wa kujibu au hazioni kabisa:

Kumbukumbu za usalama hazipo. Hii ni hali ya kawaida, haswa kati ya wachezaji wa novice kwenye soko la suluhisho la wingu. Lakini hupaswi kuachana nao mara moja. Wachezaji wadogo, hasa wa ndani, ni nyeti zaidi kwa mahitaji ya wateja na wanaweza kutekeleza kwa haraka baadhi ya vipengele vinavyohitajika kwa kubadilisha ramani ya barabara iliyoidhinishwa ya bidhaa zao. Ndiyo, hii haitakuwa analog ya GuardDuty kutoka Amazon au moduli ya "Proactive Protection" kutoka Bitrix, lakini angalau kitu.
Usalama wa habari haujui wapi kumbukumbu zimehifadhiwa au hakuna ufikiaji wao. Hapa inahitajika kuingia katika mazungumzo na mtoa huduma wa wingu - labda atatoa habari kama hiyo ikiwa atamwona mteja kuwa muhimu kwake. Lakini kwa ujumla, sio nzuri sana wakati ufikiaji wa magogo hutolewa "kwa uamuzi maalum."
Pia hutokea kwamba mtoa huduma wa wingu ana kumbukumbu, lakini hutoa ufuatiliaji mdogo na kurekodi matukio, ambayo haitoshi kuchunguza matukio yote. Kwa mfano, unaweza tu kupokea kumbukumbu za mabadiliko kwenye tovuti au kumbukumbu za majaribio ya uthibitishaji wa mtumiaji, lakini si matukio mengine, kama vile trafiki ya mtandao, ambayo yataficha kutoka kwako safu nzima ya matukio ambayo ni sifa ya majaribio ya kuingilia miundombinu yako ya wingu.
Kuna magogo, lakini upatikanaji wao ni vigumu automatiska, ambayo inawalazimisha kufuatiliwa si mara kwa mara, lakini kwa ratiba. Na ikiwa huwezi kupakua kumbukumbu kiotomatiki, kisha kupakua kumbukumbu, kwa mfano, katika muundo wa Excel (kama ilivyo kwa watoa huduma kadhaa wa ndani wa utatuzi wa wingu), kunaweza kusababisha kusita kwa huduma ya usalama wa habari ya shirika kutafakari nao.
Hakuna ufuatiliaji wa kumbukumbu. Labda hii ndiyo sababu isiyoeleweka zaidi ya kutokea kwa matukio ya usalama wa habari katika mazingira ya wingu. Inaonekana kwamba kuna magogo, na inawezekana kugeuza upatikanaji wao, lakini hakuna mtu anayefanya hivi. Kwa nini?

Dhana ya usalama wa wingu iliyoshirikiwa

Mpito kwa wingu daima ni utafutaji wa usawa kati ya hamu ya kudumisha udhibiti wa miundombinu na kuihamisha kwa mikono ya kitaalamu zaidi ya mtoa huduma wa wingu ambaye ni mtaalamu wa kuitunza. Na katika uwanja wa usalama wa wingu, usawa huu lazima pia utafutwa. Zaidi ya hayo, kulingana na mtindo wa utoaji wa huduma za wingu unaotumiwa (IaaS, PaaS, SaaS), salio hili litakuwa tofauti kila wakati. Kwa hali yoyote, lazima tukumbuke kwamba watoa huduma wote wa wingu leo wanafuata kinachojulikana kama jukumu la pamoja na mfano wa usalama wa habari ulioshirikiwa. Wingu linawajibika kwa baadhi ya mambo, na kwa wengine mteja anajibika, akiweka data yake, maombi yake, mashine zake za kawaida na rasilimali nyingine katika wingu. Itakuwa kutojali kutarajia kwamba kwa kwenda kwenye wingu, tutahamisha jukumu lote kwa mtoaji. Lakini pia sio busara kujenga usalama wote mwenyewe wakati wa kuhamia wingu. Usawa unahitajika, ambao utategemea mambo mengi: - mkakati wa usimamizi wa hatari, mfano wa tishio, taratibu za usalama zinazopatikana kwa mtoa huduma wa wingu, sheria, nk.

Kwa mfano, uainishaji wa data iliyopangishwa katika wingu daima ni wajibu wa mteja. Mtoa huduma wa wingu au mtoa huduma wa nje anaweza tu kumsaidia kwa zana ambazo zitasaidia kuashiria data katika wingu, kutambua ukiukaji, kufuta data inayokiuka sheria, au kuifunika kwa njia moja au nyingine. Kwa upande mwingine, usalama wa kimwili daima ni wajibu wa mtoa huduma wa wingu, ambayo hawezi kushiriki na wateja. Lakini kila kitu kilicho kati ya data na miundombinu ya kimwili ni mada ya majadiliano katika makala hii. Kwa mfano, upatikanaji wa wingu ni jukumu la mtoa huduma, na kuweka sheria za ngome au kuwezesha usimbaji fiche ni jukumu la mteja. Katika nakala hii tutajaribu kuangalia ni njia gani za ufuatiliaji wa usalama wa habari zinazotolewa leo na watoa huduma mbali mbali wa wingu nchini Urusi, ni sifa gani za utumiaji wao, na ni wakati gani inafaa kutazama suluhisho za nje (kwa mfano, Cisco E- mail Security) inayopanua uwezo wa wingu lako katika masuala ya usalama wa mtandao. Katika baadhi ya matukio, hasa ikiwa unafuata mkakati wa mawingu mengi, hutakuwa na chaguo ila kutumia ufumbuzi wa ufuatiliaji wa usalama wa taarifa za nje katika mazingira kadhaa ya wingu mara moja (kwa mfano, Cisco CloudLock au Cisco Stealthwatch Cloud). Kweli, katika hali zingine utagundua kuwa mtoaji wa wingu uliyemchagua (au uliyoweka kwako) haitoi uwezo wowote wa ufuatiliaji wa usalama wa habari hata kidogo. Hii haifurahishi, lakini pia sio kidogo, kwani hukuruhusu kutathmini kwa kutosha kiwango cha hatari inayohusiana na kufanya kazi na wingu hili.

Mzunguko wa Maisha wa Ufuatiliaji wa Usalama wa Wingu

Ili kufuatilia usalama wa mawingu unayotumia, una chaguo tatu pekee:

tegemea zana zinazotolewa na mtoaji wako wa wingu,
tumia suluhu kutoka kwa wahusika wengine ambao watafuatilia majukwaa ya IaaS, PaaS au SaaS unayotumia,
jenga miundombinu yako ya ufuatiliaji wa wingu (kwa majukwaa ya IaaS/PaaS pekee).

Wacha tuone ni sifa gani kila moja ya chaguzi hizi inazo. Lakini kwanza, tunahitaji kuelewa mfumo wa jumla ambao utatumika wakati wa kufuatilia majukwaa ya wingu. Ningeangazia sehemu kuu 6 za mchakato wa ufuatiliaji wa usalama wa habari kwenye wingu:

Maandalizi ya miundombinu. Kuamua maombi muhimu na miundombinu ya kukusanya matukio muhimu kwa usalama wa habari kwenye hifadhi.
Mkusanyiko. Katika hatua hii, matukio ya usalama yanajumlishwa kutoka kwa vyanzo mbalimbali kwa ajili ya uwasilishaji unaofuata kwa usindikaji, uhifadhi na uchambuzi.
Matibabu. Katika hatua hii, data hubadilishwa na kuimarishwa ili kuwezesha uchanganuzi unaofuata.
Hifadhi. Kipengele hiki kinawajibika kwa uhifadhi wa muda mfupi na mrefu wa data iliyochakatwa na mbichi iliyokusanywa.
Uchambuzi. Katika hatua hii, una uwezo wa kugundua matukio na kuyajibu kiotomatiki au kwa mikono.
Kuripoti. Hatua hii husaidia kuunda viashirio muhimu kwa washikadau (usimamizi, wakaguzi, watoa huduma za wingu, wateja, n.k.) ambavyo hutusaidia kufanya maamuzi fulani, kwa mfano, kubadilisha mtoa huduma au kuimarisha usalama wa taarifa.

Kuelewa vipengele hivi itawawezesha kuamua haraka katika siku zijazo nini unaweza kuchukua kutoka kwa mtoa huduma wako na nini utalazimika kufanya mwenyewe au kwa ushiriki wa washauri wa nje.

Huduma za wingu zilizojengwa

Tayari niliandika hapo juu kwamba huduma nyingi za wingu leo hazitoi uwezo wowote wa ufuatiliaji wa usalama wa habari. Kwa ujumla, hawazingatii sana mada ya usalama wa habari. Kwa mfano, moja ya huduma maarufu za Kirusi kwa kutuma ripoti kwa mashirika ya serikali kupitia mtandao (sitataja jina lake hasa). Sehemu nzima kuhusu usalama wa huduma hii inahusu matumizi ya CIPF iliyoidhinishwa. Sehemu ya usalama wa habari ya huduma nyingine ya wingu ya ndani kwa usimamizi wa hati za elektroniki sio tofauti. Inazungumza kuhusu vyeti muhimu vya umma, mfumo wa siri ulioidhinishwa, kuondoa athari za wavuti, ulinzi dhidi ya mashambulizi ya DDoS, kutumia ngome, chelezo, na hata ukaguzi wa mara kwa mara wa usalama wa taarifa. Lakini hakuna neno kuhusu ufuatiliaji, wala kuhusu uwezekano wa kupata upatikanaji wa matukio ya usalama wa habari ambayo inaweza kuwa ya manufaa kwa wateja wa mtoa huduma huyu.

Kwa ujumla, kwa jinsi mtoa huduma wa wingu anaelezea masuala ya usalama wa habari kwenye tovuti yake na katika nyaraka zake, unaweza kuelewa jinsi inavyochukua suala hili kwa uzito. Kwa mfano, ukisoma miongozo ya bidhaa za "Ofisi Yangu", hakuna neno juu ya usalama hata kidogo, lakini katika nyaraka za bidhaa tofauti "Ofisi Yangu. KS3”, iliyoundwa kulinda dhidi ya ufikiaji usioidhinishwa, kuna orodha ya kawaida ya pointi za amri ya 17 ya FSTEC, ambayo "Ofisi Yangu.KS3" inatekeleza, lakini haijaelezewa jinsi inavyotekeleza na, muhimu zaidi, jinsi ya kufanya hivyo. kuunganisha mifumo hii na usalama wa habari wa shirika. Labda nyaraka kama hizo zipo, lakini sikuzipata kwenye kikoa cha umma, kwenye wavuti ya "Ofisi Yangu". Ingawa labda sina ufikiaji wa habari hii ya siri? ..

Kwa Bitrix, hali ni bora zaidi. Nyaraka hufafanua miundo ya kumbukumbu za matukio na, cha kufurahisha, logi ya uvamizi, ambayo ina matukio yanayohusiana na vitisho vinavyoweza kutokea kwa jukwaa la wingu. Kutoka hapo unaweza kuvuta IP, jina la mtumiaji au mgeni, chanzo cha tukio, wakati, Wakala wa Mtumiaji, aina ya tukio, n.k. Kweli, unaweza kufanya kazi na matukio haya kutoka kwa paneli dhibiti ya wingu yenyewe, au upakie data katika umbizo la MS Excel. Sasa ni vigumu kufanyia kazi kiotomatiki na kumbukumbu za Bitrix na itabidi ufanye baadhi ya kazi wewe mwenyewe (kupakia ripoti na kuipakia kwenye SIEM yako). Lakini ikiwa tunakumbuka kuwa hadi hivi karibuni fursa kama hiyo haikuwepo, basi hii ni maendeleo makubwa. Wakati huo huo, ningependa kutambua kwamba watoa huduma wengi wa wingu wa kigeni hutoa utendakazi sawa "kwa wanaoanza" - ama angalia kumbukumbu kwa macho yako kupitia paneli dhibiti, au pakia data kwako (hata hivyo, data nyingi za upakiaji katika . csv umbizo, sio Excel).

Bila kuzingatia chaguo la hakuna kumbukumbu, watoa huduma za wingu kwa kawaida hukupa chaguo tatu za kufuatilia matukio ya usalama - dashibodi, upakiaji wa data na ufikiaji wa API. Ya kwanza inaonekana kutatua matatizo mengi kwako, lakini hii si kweli kabisa - ikiwa una magazeti kadhaa, unapaswa kubadili kati ya skrini zinazowaonyesha, kupoteza picha ya jumla. Kwa kuongeza, mtoa huduma wa wingu hawezi kukupa uwezo wa kuunganisha matukio ya usalama na kwa ujumla kuyachanganua kutoka kwa mtazamo wa usalama (kawaida unashughulika na data ghafi, ambayo unahitaji kuelewa mwenyewe). Kuna tofauti na tutazungumza juu yao zaidi. Hatimaye, inafaa kuuliza ni matukio gani yanayorekodiwa na mtoa huduma wako wa mtandaoni, katika muundo gani, na yanalinganaje na mchakato wako wa ufuatiliaji wa usalama wa taarifa? Kwa mfano, kitambulisho na uthibitishaji wa watumiaji na wageni. Bitrix sawa hukuruhusu, kulingana na matukio haya, kurekodi tarehe na saa ya tukio, jina la mtumiaji au mgeni (ikiwa una moduli ya "Web Analytics"), kitu kilichofikiwa na vipengele vingine vya kawaida kwa tovuti. . Lakini huduma za usalama wa taarifa za shirika zinaweza kuhitaji taarifa kuhusu iwapo mtumiaji alifikia wingu kutoka kwa kifaa kinachoaminika (kwa mfano, katika mtandao wa shirika kazi hii inatekelezwa na Cisco ISE). Vipi kuhusu kazi rahisi kama kazi ya geo-IP, ambayo itasaidia kubainisha ikiwa akaunti ya mtumiaji wa huduma ya wingu imeibiwa? Na hata kama mtoaji wa wingu atakupa, hii haitoshi. Cisco CloudLock sawa haichambui tu eneo la kijiografia, lakini hutumia kujifunza kwa mashine kwa hili na kuchanganua data ya kihistoria kwa kila mtumiaji na kufuatilia hitilafu mbalimbali katika majaribio ya utambuzi na uthibitishaji. MS Azure pekee ndiyo iliyo na utendakazi sawa (ikiwa una usajili unaofaa).

Kuna ugumu mwingine - kwa kuwa kwa watoa huduma wengi wa wingu ufuatiliaji wa usalama wa habari ni mada mpya ambayo wanaanza kushughulikia, wanabadilisha kitu kila wakati katika suluhisho zao. Leo wana toleo moja la API, kesho lingine, kesho kutwa la tatu. Pia unahitaji kuwa tayari kwa hili. Ndivyo ilivyo na utendakazi, ambao unaweza kubadilika, ambao lazima uzingatiwe katika mfumo wako wa ufuatiliaji wa usalama wa habari. Kwa mfano, Amazon awali ilikuwa na huduma tofauti za ufuatiliaji wa matukio ya wingu-AWS CloudTrail na AWS CloudWatch. Kisha huduma tofauti ya ufuatiliaji wa matukio ya usalama wa habari ilionekana - AWS GuardDuty. Baada ya muda, Amazon ilizindua mfumo mpya wa usimamizi, Amazon Security Hub, ambayo inajumuisha uchambuzi wa data iliyopokelewa kutoka kwa GuardDuty, Amazon Inspector, Amazon Macie na wengine kadhaa. Mfano mwingine ni zana ya ujumuishaji wa logi ya Azure na SIEM - AzLog. Ilitumiwa kikamilifu na wachuuzi wengi wa SIEM, hadi mwaka wa 2018 Microsoft ilitangaza kukomesha maendeleo na usaidizi wake, ambayo ilikabiliana na wateja wengi ambao walitumia chombo hiki na tatizo (tutazungumzia jinsi ilivyotatuliwa baadaye).

Kwa hiyo, fuatilia kwa uangalifu vipengele vyote vya ufuatiliaji ambavyo mtoaji wako wa wingu anakupa. Au tegemea watoa huduma za utatuzi wa nje ambao watafanya kama wapatanishi kati ya SOC yako na wingu unaotaka kufuatilia. Ndiyo, itakuwa ghali zaidi (ingawa si mara zote), lakini utahamisha wajibu wote kwenye mabega ya mtu mwingine. Au sio yote? .. Wacha tukumbuke dhana ya usalama wa pamoja na tuelewe kwamba hatuwezi kuhamisha chochote - tutalazimika kuelewa kwa uhuru jinsi watoa huduma tofauti wa wingu wanatoa ufuatiliaji wa usalama wa habari wa data yako, programu, mashine pepe na rasilimali zingine. mwenyeji katika wingu. Na tutaanza na kile Amazon inatoa katika sehemu hii.

Mfano: Ufuatiliaji wa usalama wa habari katika IaaS kulingana na AWS

Ndio, ndio, ninaelewa kuwa Amazon sio mfano bora kwa sababu hii ni huduma ya Amerika na inaweza kuzuiwa kama sehemu ya mapambano dhidi ya itikadi kali na usambazaji wa habari zilizopigwa marufuku nchini Urusi. Lakini katika chapisho hili ningependa tu kuonyesha jinsi majukwaa tofauti ya wingu yanavyotofautiana katika uwezo wao wa ufuatiliaji wa usalama wa taarifa na unachopaswa kuzingatia unapohamisha michakato yako muhimu hadi kwenye wingu kutoka kwa mtazamo wa usalama. Naam, ikiwa baadhi ya watengenezaji wa Kirusi wa ufumbuzi wa wingu hujifunza kitu muhimu kwao wenyewe, basi hiyo itakuwa nzuri.

Jambo la kwanza kusema ni kwamba Amazon sio ngome isiyoweza kupenya. Matukio mbalimbali hutokea mara kwa mara kwa wateja wake. Kwa mfano, majina, anwani, tarehe za kuzaliwa, na nambari za simu za wapiga kura milioni 198 ziliibwa kutoka kwa Deep Root Analytics. Kampuni ya Israeli ya Nice Systems iliiba rekodi milioni 14 za watumiaji wa Verizon. Walakini, uwezo wa ndani wa AWS hukuruhusu kugundua anuwai ya matukio. Kwa mfano:

athari kwa miundombinu (DDoS)
maelewano ya nodi (sindano ya amri)
maelewano ya akaunti na ufikiaji usioidhinishwa
usanidi usio sahihi na udhaifu
miingiliano isiyo salama na API.

Tofauti hii ni kwa sababu ya ukweli kwamba, kama tulivyogundua hapo juu, mteja mwenyewe anawajibika kwa usalama wa data ya mteja. Na ikiwa hakuwa na wasiwasi kuwasha taratibu za ulinzi na hakuwasha zana za ufuatiliaji, basi atajifunza tu kuhusu tukio hilo kutoka kwa vyombo vya habari au kutoka kwa wateja wake.

Ili kubaini matukio, unaweza kutumia anuwai ya huduma tofauti za ufuatiliaji zilizotengenezwa na Amazon (ingawa hizi mara nyingi hukamilishwa na zana za nje kama vile osquery). Kwa hiyo, katika AWS, vitendo vyote vya mtumiaji vinafuatiliwa, bila kujali jinsi vinafanywa - kupitia console ya usimamizi, mstari wa amri, SDK au huduma nyingine za AWS. Rekodi zote za shughuli za kila akaunti ya AWS (ikiwa ni pamoja na jina la mtumiaji, kitendo, huduma, vigezo vya shughuli na matokeo) na matumizi ya API zinapatikana kupitia AWS CloudTrail. Unaweza kutazama matukio haya (kama vile kuingia kwa dashibodi ya AWS IAM) kutoka kwa dashibodi ya CloudTrail, kuyachanganua kwa kutumia Amazon Athena, au "kutoa" kwa suluhu za nje kama vile Splunk, AlienVault, n.k. Kumbukumbu za AWS CloudTrail zenyewe zimewekwa kwenye ndoo yako ya AWS S3.

Huduma nyingine mbili za AWS hutoa idadi ya uwezo mwingine muhimu wa ufuatiliaji. Kwanza, Amazon CloudWatch ni huduma ya ufuatiliaji wa rasilimali na programu za AWS ambazo, miongoni mwa mambo mengine, hukuruhusu kutambua hitilafu mbalimbali katika wingu lako. Huduma zote za AWS zilizojengewa ndani, kama vile Amazon Elastic Compute Cloud (seva), Huduma ya Hifadhidata ya Uhusiano ya Amazon (hifadhidata), Amazon Elastic MapReduce (uchambuzi wa data), na huduma zingine 30 za Amazon, hutumia Amazon CloudWatch kuhifadhi kumbukumbu zao. Wasanidi programu wanaweza kutumia API iliyo wazi kutoka Amazon CloudWatch ili kuongeza utendaji wa ufuatiliaji wa kumbukumbu kwenye programu na huduma maalum, hivyo kuwaruhusu kupanua wigo wa uchanganuzi wa matukio ndani ya muktadha wa usalama.

Pili, huduma ya VPC Flow Logs hukuruhusu kuchanganua trafiki ya mtandao iliyotumwa au kupokewa na seva zako za AWS (nje au ndani), na pia kati ya huduma ndogo. Rasilimali zako zozote za AWS VPC zinapoingiliana na mtandao, Kumbukumbu za Mtiririko wa VPC hurekodi maelezo kuhusu trafiki ya mtandao, ikijumuisha kiolesura cha chanzo na lengwa la mtandao, pamoja na anwani za IP, bandari, itifaki, idadi ya baiti na idadi ya pakiti unazotumia. saw. Wale wenye uzoefu na usalama wa mtandao wa ndani watatambua hili kama sawa na nyuzi NetFlow, ambayo inaweza kuundwa na swichi, routers na firewalls za daraja la biashara. Kumbukumbu hizi ni muhimu kwa madhumuni ya ufuatiliaji wa usalama wa taarifa kwa sababu, tofauti na matukio kuhusu vitendo vya watumiaji na programu, pia hukuruhusu usikose mwingiliano wa mtandao katika mazingira ya wingu ya faragha ya AWS.

Kwa muhtasari, huduma hizi tatu za AWS—AWS CloudTrail, Amazon CloudWatch, na Kumbukumbu za Mtiririko wa VPC—pamoja hutoa maarifa yenye nguvu kuhusu matumizi ya akaunti yako, tabia ya mtumiaji, usimamizi wa miundombinu, shughuli za programu na huduma na shughuli za mtandao. Kwa mfano, zinaweza kutumika kugundua hitilafu zifuatazo:

Majaribio ya kuchanganua tovuti, kutafuta milango ya nyuma, kutafuta udhaifu kupitia mlipuko wa "makosa 404".
Mashambulizi ya sindano (kwa mfano, sindano ya SQL) kupitia milipuko ya "makosa 500".
Zana za kushambulia zinazojulikana ni sqlmap, nikto, w3af, nmap, nk. kupitia uchanganuzi wa uwanja wa Wakala wa Mtumiaji.

Huduma za Wavuti za Amazon pia zimetengeneza huduma zingine kwa madhumuni ya usalama wa mtandao ambayo hukuruhusu kutatua shida zingine nyingi. Kwa mfano, AWS ina huduma iliyojengewa ndani ya sera za ukaguzi na usanidi - AWS Config. Huduma hii hutoa ukaguzi endelevu wa rasilimali zako za AWS na usanidi wake. Hebu tuchukue mfano rahisi: Hebu tuseme unataka kuhakikisha kuwa manenosiri ya mtumiaji yamezimwa kwenye seva zako zote na ufikiaji huo unawezekana tu kulingana na vyeti. AWS Config hurahisisha kuangalia hii kwa seva zako zote. Kuna sera zingine zinazoweza kutumika kwa seva zako za wingu: "Hakuna seva inayoweza kutumia mlango wa 22", "Wasimamizi pekee ndio wanaoweza kubadilisha sheria za ngome" au "Mtumiaji Ivashko pekee ndiye anayeweza kuunda akaunti mpya za watumiaji, na anaweza kufanya Ni Jumanne tu. " Katika majira ya kiangazi ya 2016, huduma ya AWS Config ilipanuliwa ili kuboresha ugunduzi wa ukiukaji wa sera zilizotengenezwa kiotomatiki. Kanuni za Usanidi wa AWS kimsingi ni maombi endelevu ya usanidi wa huduma za Amazon unazotumia, ambazo huzalisha matukio ikiwa sera zinazolingana zimekiukwa. Kwa mfano, badala ya kuendesha maswali ya AWS Config mara kwa mara ili kuthibitisha kwamba diski zote kwenye seva pepe zimesimbwa kwa njia fiche, Kanuni za Usanidi wa AWS zinaweza kutumika kuendelea kuangalia diski za seva ili kuhakikisha kuwa hali hii inatimizwa. Na, muhimu zaidi, katika muktadha wa chapisho hili, ukiukaji wowote hutoa matukio ambayo yanaweza kuchanganuliwa na huduma yako ya usalama wa habari.

AWS pia ina sawa na suluhu za usalama wa habari za jadi za shirika, ambazo pia hutoa matukio ya usalama ambayo unaweza na unapaswa kuchanganua:

Utambuzi wa Kuingilia - AWS GuardDuty
Udhibiti wa Uvujaji wa Taarifa - AWS Macie
EDR (ingawa inazungumza juu ya miisho kwenye wingu kwa kushangaza kidogo) - AWS Cloudwatch + osquery ya chanzo wazi au suluhisho za GRR
Uchambuzi wa Netflow - AWS Cloudwatch + AWS VPC Flow
Uchambuzi wa DNS - AWS Cloudwatch + AWS Route53
AD - Huduma ya Saraka ya AWS
Usimamizi wa Akaunti - AWS IAM
SSO - AWS SSO
uchambuzi wa usalama - Mkaguzi wa AWS
usimamizi wa usanidi - AWS Config
WAF - AWS WAF.

Sitaelezea kwa undani huduma zote za Amazon ambazo zinaweza kuwa muhimu katika muktadha wa usalama wa habari. Jambo kuu ni kuelewa kwamba wote wanaweza kuzalisha matukio ambayo tunaweza na tunapaswa kuchambua katika mazingira ya usalama wa habari, kwa kutumia kwa kusudi hili uwezo wa kujengwa wa Amazon yenyewe na ufumbuzi wa nje, kwa mfano, SIEM, ambayo inaweza. peleka matukio ya usalama kwenye kituo chako cha ufuatiliaji na uyachanganue hapo pamoja na matukio kutoka kwa huduma zingine za wingu au kutoka kwa miundombinu ya ndani, eneo au vifaa vya rununu.

Kwa hali yoyote, yote huanza na vyanzo vya data vinavyokupa matukio ya usalama wa habari. Vyanzo hivi ni pamoja na, lakini sio mdogo kwa:

CloudTrail - Matumizi ya API na Vitendo vya Mtumiaji
Mshauri Anayeaminika - ukaguzi wa usalama dhidi ya mbinu bora
Config - hesabu na usanidi wa akaunti na mipangilio ya huduma
Kumbukumbu za Mtiririko wa VPC - miunganisho kwa miingiliano ya kawaida
IAM - kitambulisho na huduma ya uthibitishaji
Kumbukumbu za Ufikiaji wa ELB - Kisawazisha cha Pakia
Mkaguzi - udhaifu wa programu
S3 - uhifadhi wa faili
CloudWatch - Shughuli ya Maombi
SNS ni huduma ya arifa.

Amazon, huku ikitoa aina mbalimbali za vyanzo na zana za matukio kwa ajili ya kizazi chao, ina uwezo mdogo sana wa kuchanganua data iliyokusanywa katika muktadha wa usalama wa taarifa. Utalazimika kusoma kwa uhuru magogo yanayopatikana, ukitafuta viashiria muhimu vya maelewano ndani yao. AWS Security Hub, ambayo Amazon ilizindua hivi karibuni, inalenga kutatua tatizo hili kwa kuwa SIEM ya wingu kwa AWS. Lakini hadi sasa ni mwanzoni mwa safari yake na ni mdogo kwa idadi ya vyanzo ambayo inafanya kazi na kwa vikwazo vingine vilivyoanzishwa na usanifu na usajili wa Amazon yenyewe.

Mfano: Ufuatiliaji wa usalama wa habari katika IaaS kulingana na Azure

Sitaki kuingia katika mjadala mrefu kuhusu ni nani kati ya watoa huduma wa wingu watatu (Amazon, Microsoft au Google) ni bora (hasa tangu kila mmoja wao bado ana maalum yake maalum na yanafaa kwa kutatua matatizo yake mwenyewe); Hebu tuzingatie uwezo wa ufuatiliaji wa usalama wa habari ambao wachezaji hawa hutoa. Ni lazima ikubalike kwamba Amazon AWS ilikuwa mojawapo ya ya kwanza katika sehemu hii na kwa hivyo imeendelea zaidi katika masuala ya kazi zake za usalama wa habari (ingawa wengi wanakubali kuwa ni vigumu kuzitumia). Lakini hii haimaanishi kwamba tutapuuza fursa ambazo Microsoft na Google hutupa.

Bidhaa za Microsoft zimekuwa zikitofautishwa na "uwazi" wao na katika Azure hali ni sawa. Kwa mfano, ikiwa AWS na GCP daima huendelea kutoka kwa dhana ya "kisichoruhusiwa ni marufuku," basi Azure ina mbinu kinyume kabisa. Kwa mfano, wakati wa kuunda mtandao wa kawaida katika wingu na mashine ya kawaida ndani yake, bandari zote na itifaki zimefunguliwa na kuruhusiwa kwa default. Kwa hivyo, italazimika kutumia juhudi kidogo zaidi kwenye usanidi wa awali wa mfumo wa udhibiti wa ufikiaji kwenye wingu kutoka kwa Microsoft. Na hii pia inaweka mahitaji magumu zaidi kwako katika suala la shughuli za ufuatiliaji katika wingu la Azure.

AWS ina upekee unaohusishwa na ukweli kwamba unapofuatilia rasilimali zako za kawaida, ikiwa ziko katika mikoa tofauti, basi unapata shida katika kuchanganya matukio yote na uchambuzi wao wa umoja, ili kuondoa ambayo unahitaji kuamua hila mbalimbali, kama vile. Unda msimbo wako mwenyewe wa AWS Lambda ambao utasafirisha matukio kati ya maeneo. Azure haina tatizo hili - utaratibu wake wa Kumbukumbu ya Shughuli hufuatilia shughuli zote katika shirika zima bila vikwazo. Vile vile hutumika kwa AWS Security Hub, ambayo hivi karibuni ilitengenezwa na Amazon ili kuunganisha kazi nyingi za usalama ndani ya kituo kimoja cha usalama, lakini tu ndani ya eneo lake, ambalo, hata hivyo, sio muhimu kwa Urusi. Azure ina Kituo chake cha Usalama, ambacho hakijafungwa na vikwazo vya kikanda, kutoa upatikanaji wa vipengele vyote vya usalama vya jukwaa la wingu. Zaidi ya hayo, kwa timu tofauti za ndani inaweza kutoa seti yake ya uwezo wa ulinzi, ikiwa ni pamoja na matukio ya usalama yanayosimamiwa nao. AWS Security Hub bado iko njiani kuwa sawa na Kituo cha Usalama cha Azure. Lakini inafaa kuongeza nzi kwenye marashi - unaweza kufinya kutoka kwa Azure mengi ya yale yaliyoelezewa hapo awali katika AWS, lakini hii inafanywa kwa urahisi tu kwa Azure AD, Azure Monitor na Kituo cha Usalama cha Azure. Njia zingine zote za usalama za Azure, pamoja na uchanganuzi wa tukio la usalama, bado hazijadhibitiwa kwa njia rahisi zaidi. Tatizo linatatuliwa kwa sehemu na API, ambayo huingia kwenye huduma zote za Microsoft Azure, lakini hii itahitaji jitihada za ziada kutoka kwako ili kuunganisha wingu lako na SOC yako na uwepo wa wataalamu waliohitimu (kwa kweli, kama ilivyo kwa SIEM nyingine yoyote inayofanya kazi na wingu. API). Baadhi ya SIEMs, ambazo zitajadiliwa baadaye, tayari zinaunga mkono Azure na zinaweza kuelekeza kazi ya kuifuatilia, lakini pia ina shida zake - sio zote zinaweza kukusanya kumbukumbu zote ambazo Azure ina.

Mkusanyiko na ufuatiliaji wa matukio katika Azure hutolewa kwa kutumia huduma ya Azure Monitor, ambayo ndiyo zana kuu ya kukusanya, kuhifadhi na kuchambua data katika wingu la Microsoft na rasilimali zake - hazina za Git, kontena, mashine pepe, programu, n.k. Data yote iliyokusanywa na Azure Monitor imegawanywa katika makundi mawili - metrics, iliyokusanywa kwa wakati halisi na kuelezea viashiria muhimu vya utendaji vya wingu la Azure, na kumbukumbu, zilizo na data iliyopangwa katika rekodi zinazoonyesha vipengele fulani vya shughuli za rasilimali na huduma za Azure. Kwa kuongezea, kwa kutumia API ya Ukusanyaji Data, huduma ya Azure Monitor inaweza kukusanya data kutoka kwa chanzo chochote cha REST ili kuunda hali zake za ufuatiliaji.

Hapa kuna vyanzo vichache vya matukio ya usalama ambavyo Azure inakupa na ambavyo unaweza kuvipata kupitia Azure Portal, CLI, PowerShell, au REST API (na vingine kupitia Azure Monitor/Insight API):

Kumbukumbu za Shughuli - kumbukumbu hii inajibu maswali ya kawaida ya "nani," "nini," na "wakati" kuhusu operesheni yoyote ya kuandika (PUT, POST, DELETE) kwenye rasilimali za wingu. Matukio yanayohusiana na ufikiaji wa kusoma (GET) hayajajumuishwa kwenye kumbukumbu hii, kama idadi ya mengine.
Kumbukumbu za Uchunguzi - ina data juu ya uendeshaji na rasilimali fulani iliyojumuishwa katika usajili wako.
Ripoti ya AD ya Azure - ina shughuli za mtumiaji na shughuli za mfumo zinazohusiana na usimamizi wa kikundi na mtumiaji.
Kumbukumbu ya Matukio ya Windows na Syslog ya Linux - ina matukio kutoka kwa mashine pepe zinazopangishwa katika wingu.
Metrics - ina telemetry kuhusu utendakazi na hali ya afya ya huduma na rasilimali zako za wingu. Inapimwa kila dakika na kuhifadhiwa. ndani ya siku 30.
Kumbukumbu za Mtiririko wa Kikundi cha Usalama cha Mtandao - kina data kwenye matukio ya usalama ya mtandao yaliyokusanywa kwa kutumia huduma ya Mtandao wa Kuangalia Mtandao na ufuatiliaji wa rasilimali katika kiwango cha mtandao.
Kumbukumbu za Uhifadhi - ina matukio yanayohusiana na upatikanaji wa vifaa vya kuhifadhi.

Kwa ufuatiliaji, unaweza kutumia SIEM za nje au Azure Monitor iliyojengwa ndani na viendelezi vyake. Tutazungumza kuhusu mifumo ya usimamizi wa matukio ya usalama wa habari baadaye, lakini kwa sasa hebu tuone kile Azure yenyewe inatupa kwa uchambuzi wa data katika muktadha wa usalama. Skrini kuu ya kila kitu kinachohusiana na usalama katika Azure Monitor ni Dashibodi ya Usalama ya Uchanganuzi wa Kumbukumbu na Ukaguzi (toleo la bila malipo linaweza kutumia kiasi kidogo cha hifadhi ya tukio kwa wiki moja pekee). Dashibodi hii imegawanywa katika maeneo makuu 5 ambayo yanaonyesha muhtasari wa takwimu za kile kinachotokea katika mazingira ya wingu unayotumia:

Vikoa vya Usalama - viashiria muhimu vya kiasi vinavyohusiana na usalama wa habari - idadi ya matukio, idadi ya nodi zilizoathiriwa, nodi ambazo hazijafungwa, matukio ya usalama wa mtandao, nk.
Masuala Mashuhuri - huonyesha nambari na umuhimu wa maswala amilifu ya usalama wa habari
Ugunduzi - huonyesha mifumo ya mashambulizi yanayotumiwa dhidi yako
Intelligence ya Tishio - huonyesha taarifa za kijiografia kwenye nodi za nje zinazokushambulia
Maswali ya kawaida ya usalama - maswali ya kawaida ambayo yatakusaidia kufuatilia usalama wa maelezo yako vizuri.

Viendelezi vya Azure Monitor ni pamoja na Azure Key Vault (ulinzi wa funguo za siri kwenye wingu), Tathmini ya Malware (uchambuzi wa ulinzi dhidi ya msimbo hasidi kwenye mashine pepe), Uchanganuzi wa Njia ya Utumiaji wa Azure (uchambuzi wa, miongoni mwa mambo mengine, kumbukumbu za ngome za wingu), n.k. . Zana hizi, zilizoboreshwa na sheria fulani za matukio ya usindikaji, hukuruhusu kuibua vipengele mbalimbali vya shughuli za huduma za wingu, ikiwa ni pamoja na usalama, na kutambua kupotoka fulani kutoka kwa uendeshaji. Lakini, kama inavyotokea mara nyingi, utendaji wowote wa ziada unahitaji usajili unaolipwa unaolingana, ambao utahitaji uwekezaji unaolingana wa kifedha kutoka kwako, ambao unahitaji kupanga mapema.

Azure ina idadi ya uwezo wa ufuatiliaji wa vitisho uliojengwa ndani ambao umeunganishwa katika Azure AD, Azure Monitor, na Kituo cha Usalama cha Azure. Miongoni mwao, kwa mfano, ugunduzi wa mwingiliano wa mashine za kawaida na IP zinazojulikana hasidi (kutokana na uwepo wa kuunganishwa na huduma za Ujasusi wa Tishio kutoka kwa Microsoft), kugundua programu hasidi katika miundombinu ya wingu kwa kupokea kengele kutoka kwa mashine za kawaida zilizowekwa kwenye wingu, nenosiri. mashambulizi ya kubahatisha ” kwenye mashine pepe, udhaifu katika usanidi wa mfumo wa kitambulisho cha mtumiaji, kuingia kwenye mfumo kutoka kwa watu wasiojulikana au nodi zilizoambukizwa, uvujaji wa akaunti, kuingia kwenye mfumo kutoka kwa maeneo yasiyo ya kawaida, nk. Azure leo ni mojawapo ya watoa huduma wachache wa wingu ambao hukupa uwezo wa Upelelezi wa Tishio uliojengewa ndani ili kuboresha matukio yaliyokusanywa ya usalama wa habari.

Kama ilivyoelezwa hapo juu, utendaji wa usalama na, kwa sababu hiyo, matukio ya usalama yanayotokana nayo hayapatikani kwa watumiaji wote kwa usawa, lakini yanahitaji usajili fulani unaojumuisha utendakazi unaohitaji, ambao huzalisha matukio yanayofaa kwa ufuatiliaji wa usalama wa habari. Kwa mfano, baadhi ya kazi zilizoelezwa katika aya iliyotangulia za ufuatiliaji wa hitilafu katika akaunti zinapatikana tu katika leseni ya malipo ya P2 ya huduma ya Azure AD. Bila hivyo, wewe, kama ilivyo kwa AWS, itabidi uchambue matukio ya usalama yaliyokusanywa "kwa mikono". Na, pia, kulingana na aina ya leseni ya Azure AD, sio matukio yote yatapatikana kwa uchambuzi.

Kwenye tovuti ya Azure, unaweza kudhibiti hoja zote mbili za utafutaji wa kumbukumbu zinazokuvutia na usanidi dashibodi ili kuibua viashirio muhimu vya usalama wa taarifa. Kwa kuongeza, huko unaweza kuchagua upanuzi wa Azure Monitor, ambayo inakuwezesha kupanua utendaji wa kumbukumbu za Azure Monitor na kupata uchambuzi wa kina wa matukio kutoka kwa mtazamo wa usalama.

Ikiwa hauhitaji tu uwezo wa kufanya kazi na magogo, lakini kituo cha usalama cha kina cha jukwaa lako la wingu la Azure, ikiwa ni pamoja na usimamizi wa sera ya usalama wa habari, basi unaweza kuzungumza juu ya hitaji la kufanya kazi na Kituo cha Usalama cha Azure, kazi nyingi muhimu ambazo zinapatikana kwa baadhi ya pesa, kwa mfano, kugundua vitisho, ufuatiliaji nje ya Azure, tathmini ya kufuata, n.k. (katika toleo lisilolipishwa, unaweza tu kufikia tathmini ya usalama na mapendekezo ya kuondoa matatizo yaliyotambuliwa). Inaunganisha masuala yote ya usalama katika sehemu moja. Kwa kweli, tunaweza kuzungumza juu ya kiwango cha juu cha usalama wa habari kuliko Azure Monitor inakupa, kwa kuwa katika kesi hii data iliyokusanywa katika kiwanda chako cha wingu inaboreshwa kwa kutumia vyanzo vingi, kama vile Azure, Office 365, Microsoft CRM mtandaoni, Microsoft Dynamics AX. , outlook .com, MSN.com, Kitengo cha Uhalifu wa Kidijitali cha Microsoft (DCU) na Kituo cha Majibu ya Usalama cha Microsoft (MSRC), ambapo algoriti mbalimbali za kisasa za ujifunzaji na uchanganuzi wa tabia zimewekwa juu, ambazo zinapaswa kuboresha ufanisi wa kugundua na kujibu vitisho. .

Azure pia ina SIEM yake mwenyewe - ilionekana mwanzoni mwa 2019. Hii ni Azure Sentinel, ambayo inategemea data kutoka kwa Azure Monitor na inaweza pia kuunganishwa nayo. ufumbuzi wa usalama wa nje (kwa mfano, NGFW au WAF), orodha ambayo inakua daima. Kwa kuongezea, kupitia ujumuishaji wa API ya Usalama wa Grafu ya Microsoft, una uwezo wa kuunganisha milisho yako ya Ujasusi wa Tishio kwa Sentinel, ambayo inaboresha uwezo wa kuchanganua matukio katika wingu lako la Azure. Inaweza kubishaniwa kuwa Azure Sentinel ndiye SIEM ya "asili" ya kwanza ambayo ilionekana kutoka kwa watoa huduma wa wingu (Splunk sawa au ELK, ambayo inaweza kupangishwa katika wingu, kwa mfano, AWS, bado haijatengenezwa na watoa huduma wa kawaida wa wingu). Azure Sentinel na Kituo cha Usalama kinaweza kuitwa SOC kwa wingu la Azure na inaweza kuwekewa mipaka kwao (pamoja na uhifadhi fulani) ikiwa huna tena miundombinu yoyote na ukahamisha rasilimali zako zote za kompyuta kwenye wingu na itakuwa Microsoft cloud Azure.

Lakini kwa kuwa uwezo uliojengewa ndani wa Azure (hata kama una usajili kwa Sentinel) mara nyingi hautoshi kwa madhumuni ya kufuatilia usalama wa habari na kuunganisha mchakato huu na vyanzo vingine vya matukio ya usalama (wingu na ya ndani), kuna haja ya kusafirisha data iliyokusanywa kwa mifumo ya nje, ambayo inaweza kujumuisha SIEM. Hii inafanywa wote kwa kutumia API na kutumia upanuzi maalum, ambayo kwa sasa inapatikana rasmi tu kwa SIEM zifuatazo - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight na ELK. Hadi hivi majuzi, kulikuwa na SIEMs zaidi kama hizo, lakini kutoka Juni 1, 2019, Microsoft iliacha kuunga mkono Chombo cha Ujumuishaji cha Azure Log (AzLog), ambayo mwanzoni mwa uwepo wa Azure na kwa kukosekana kwa viwango vya kawaida vya kufanya kazi na magogo (Azure). Monitor hata haikuwepo) ilifanya iwe rahisi kuunganisha SIEM ya nje na wingu la Microsoft. Sasa hali imebadilika na Microsoft inapendekeza jukwaa la Azure Event Hub kama zana kuu ya ujumuishaji kwa SIEM zingine. Wengi tayari wametekeleza ujumuishaji kama huo, lakini kuwa mwangalifu - hawawezi kukamata kumbukumbu zote za Azure, lakini zingine tu (angalia hati za SIEM yako).

Kuhitimisha safari fupi ya Azure, ningependa kutoa pendekezo la jumla kuhusu huduma hii ya wingu - kabla ya kusema chochote kuhusu kazi za ufuatiliaji wa usalama wa habari huko Azure, unapaswa kuzisanidi kwa uangalifu sana na ujaribu kuwa zinafanya kazi kama ilivyoandikwa kwenye hati na. kama washauri walikuambia Microsoft (na wanaweza kuwa na maoni tofauti juu ya utendakazi wa kazi za Azure). Ikiwa una rasilimali za kifedha, unaweza kubana taarifa nyingi muhimu kutoka kwa Azure kulingana na ufuatiliaji wa usalama wa habari. Ikiwa rasilimali zako ni chache, basi, kama ilivyo kwa AWS, itabidi utegemee nguvu zako mwenyewe na data mbichi ambayo Azure Monitor hukupa. Na kumbuka kuwa kazi nyingi za ufuatiliaji zinagharimu pesa na ni bora kujijulisha na sera ya bei mapema. Kwa mfano, bila malipo unaweza kuhifadhi siku 31 za data hadi kiwango cha juu cha GB 5 kwa kila mteja - kuzidi maadili haya itakuhitaji utoe pesa za ziada (takriban $2+ kwa kuhifadhi kila GB ya ziada kutoka kwa mteja na $0,1 kwa kuhifadhi GB 1 kila mwezi wa ziada). Kufanya kazi na telemetry ya maombi na vipimo pia kunaweza kuhitaji pesa za ziada, pamoja na kufanya kazi na arifa na arifa (kikomo fulani kinapatikana bila malipo, ambacho kinaweza kutosheleza mahitaji yako).

Mfano: Ufuatiliaji wa usalama wa habari katika IaaS kulingana na Google Cloud Platform

Google Cloud Platform inaonekana kama kijana ikilinganishwa na AWS na Azure, lakini hii ni nzuri kwa kiasi. Tofauti na AWS, ambayo iliongeza uwezo wake, ikiwa ni pamoja na wale wa usalama, hatua kwa hatua, kuwa na matatizo na centralization; GCP, kama Azure, inasimamiwa vyema zaidi serikali kuu, ambayo hupunguza makosa na muda wa utekelezaji katika biashara yote. Kwa mtazamo wa usalama, GCP iko, isiyo ya kawaida, kati ya AWS na Azure. Pia ana usajili wa tukio moja kwa shirika zima, lakini haujakamilika. Baadhi ya vipengele bado viko katika hali ya beta, lakini hatua kwa hatua upungufu huu unapaswa kuondolewa na GCP itakuwa jukwaa la watu wazima zaidi katika masuala ya ufuatiliaji wa usalama wa taarifa.

Zana kuu ya matukio ya ukataji miti katika GCP ni Uwekaji kumbukumbu kwa Stackdriver (sawa na Azure Monitor), ambayo hukuruhusu kukusanya matukio kwenye miundombinu yako yote ya wingu (pamoja na kutoka kwa AWS). Kwa mtazamo wa usalama katika GCP, kila shirika, mradi au folda ina kumbukumbu nne:

Shughuli ya Msimamizi - ina matukio yote yanayohusiana na ufikiaji wa msimamizi, kwa mfano, kuunda mashine pepe, kubadilisha haki za ufikiaji, n.k. Logi hii imeandikwa kila wakati, bila kujali hamu yako, na huhifadhi data yake kwa siku 400.
Ufikiaji wa data - ina matukio yote yanayohusiana na kufanya kazi na data na watumiaji wa wingu (uundaji, marekebisho, kusoma, nk). Kwa chaguo-msingi, logi hii haijaandikwa, kwani kiasi chake kinaongezeka haraka sana. Kwa sababu hii, maisha yake ya rafu ni siku 30 tu. Kwa kuongeza, sio kila kitu kimeandikwa katika gazeti hili. Kwa mfano, matukio yanayohusiana na nyenzo zinazoweza kufikiwa na umma kwa watumiaji wote au zinazoweza kufikiwa bila kuingia kwenye GCP hazijaandikiwa.
Tukio la Mfumo - lina matukio ya mfumo ambayo hayahusiani na watumiaji, au vitendo vya msimamizi ambaye hubadilisha usanidi wa rasilimali za wingu. Daima huandikwa na kuhifadhiwa kwa siku 400.
Uwazi wa Ufikiaji ni mfano wa kipekee wa kumbukumbu inayonasa vitendo vyote vya wafanyakazi wa Google (lakini bado si kwa huduma zote za GCP) ambao wanafikia miundombinu yako kama sehemu ya majukumu yao ya kazi. Logi hii huhifadhiwa kwa siku 400 na haipatikani kwa kila mteja wa GCP, lakini ikiwa tu idadi ya masharti yametimizwa (msaada wa kiwango cha Dhahabu au Platinamu, au uwepo wa majukumu 4 ya aina fulani kama sehemu ya usaidizi wa shirika). Kazi sawa inapatikana pia, kwa mfano, katika Ofisi ya 365 - Lockbox.

Mfano wa kumbukumbu: Uwazi wa Ufikiaji

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

Ufikiaji wa kumbukumbu hizi unawezekana kwa njia kadhaa (kwa njia sawa na Azure na AWS iliyojadiliwa hapo awali) - kupitia kiolesura cha Log Viewer, kupitia API, kupitia Google Cloud SDK, au kupitia ukurasa wa Shughuli wa mradi wako ambao unautumia. wanavutiwa na matukio. Kwa njia hiyo hiyo, zinaweza kusafirishwa kwa suluhisho za nje kwa uchambuzi wa ziada. Mwisho unafanywa kwa kuhamisha kumbukumbu kwa BigQuery au hifadhi ya Cloud Pub/Sub.

Mbali na Kuweka Magogo kwa Stackdriver, jukwaa la GCP pia hutoa utendakazi wa Ufuatiliaji wa Stackdriver, ambao hukuruhusu kufuatilia vipimo muhimu (utendaji, MTBF, afya kwa ujumla, n.k.) za huduma na programu za wingu. Data iliyochakatwa na kuonyeshwa inaweza kurahisisha kupata matatizo katika miundombinu yako ya wingu, ikiwa ni pamoja na katika muktadha wa usalama. Lakini ikumbukwe kwamba utendaji huu hautakuwa tajiri sana katika muktadha wa usalama wa habari, kwani leo GCP haina analog ya AWS GuardDuty sawa na haiwezi kutambua mbaya kati ya matukio yote yaliyosajiliwa (Google imetengeneza Utambuzi wa Tishio la Tukio, lakini bado inaendelezwa katika beta na ni mapema mno kuzungumza kuhusu manufaa yake). Ufuatiliaji wa Stackdriver unaweza kutumika kama mfumo wa kugundua hitilafu, ambao ungechunguzwa ili kupata sababu za kutokea kwao. Lakini kwa kuzingatia ukosefu wa wafanyikazi waliohitimu katika uwanja wa usalama wa habari wa GCP kwenye soko, kazi hii kwa sasa inaonekana ngumu.

Inafaa pia kutoa orodha ya moduli za usalama wa habari ambazo zinaweza kutumika ndani ya wingu lako la GCP, na ambazo ni sawa na AWS inatoa:

Kituo cha Amri ya Usalama wa Wingu ni analog ya Kituo cha Usalama cha AWS na Kituo cha Usalama cha Azure.
Cloud DLP - Ugunduzi na uhariri wa kiotomatiki (k.m. kuficha) data iliyopangishwa katika wingu kwa kutumia zaidi ya sera 90 za uainishaji zilizobainishwa mapema.
Cloud Scanner ni kichanganuzi cha udhaifu unaojulikana (XSS, Flash Injection, maktaba ambazo hazijabandikwa, n.k.) katika Injini ya Programu, Injini ya Kuhesabu na Google Kubernetes.
Cloud IAM - Dhibiti ufikiaji wa rasilimali zote za GCP.
Utambulisho wa Wingu - Dhibiti akaunti za mtumiaji, kifaa na programu za GCP kutoka kwa kiweko kimoja.
Cloud HSM - ulinzi wa funguo za cryptographic.
Huduma ya Kudhibiti Ufunguo wa Wingu - usimamizi wa funguo za kriptografia katika GCP.
Udhibiti wa Huduma ya VPC - Unda eneo salama karibu na rasilimali zako za GCP ili kuzilinda dhidi ya uvujaji.
Ufunguo wa Usalama wa Titan - ulinzi dhidi ya hadaa.

Nyingi za sehemu hizi huzalisha matukio ya usalama yanayoweza kutumwa kwa hifadhi ya BigQuery kwa uchanganuzi au kuhamishwa kwa mifumo mingine, ikijumuisha SIEM. Kama ilivyoelezwa hapo juu, GCP ni jukwaa linaloendelea na Google sasa inatengeneza moduli mpya za usalama wa habari kwa ajili ya jukwaa lake. Miongoni mwayo ni Utambuzi wa Tishio la Tukio (sasa linapatikana katika beta), ambayo huchanganua kumbukumbu za Stackdriver ili kutafuta athari za shughuli ambazo hazijaidhinishwa (sawa na GuardDuty katika AWS), au Policy Intelligence (inapatikana katika alpha), ambayo itakuruhusu kuunda sera mahiri za ufikiaji wa rasilimali za GCP.

Nilifanya muhtasari mfupi wa uwezo wa ufuatiliaji uliojengwa katika majukwaa maarufu ya wingu. Lakini je, una wataalamu ambao wanaweza kufanya kazi na kumbukumbu za watoa huduma wa IaaS "mbichi" (sio kila mtu yuko tayari kununua uwezo wa juu wa AWS au Azure au Google)? Isitoshe, wengi wanafahamu usemi “tumaini, lakini thibitisha,” ambao ni wa kweli kuliko wakati mwingine wowote katika nyanja ya usalama. Je, unaamini kwa kiasi gani uwezo uliojengewa ndani wa mtoa huduma wa wingu ambao hukutumia matukio ya usalama wa maelezo? Je, wanazingatia usalama wa habari kwa kiasi gani hata kidogo?

Wakati mwingine inafaa kuangalia masuluhisho ya ufuatiliaji wa miundombinu ya wingu ambayo yanaweza kutimiza usalama wa wingu uliojengwa ndani, na wakati mwingine masuluhisho kama haya ndiyo chaguo pekee la kupata maarifa juu ya usalama wa data na programu zako zinazopangishwa katika wingu. Kwa kuongeza, wao ni rahisi zaidi, kwa vile wanachukua kazi zote za kuchambua magogo muhimu yanayotokana na huduma tofauti za wingu kutoka kwa watoa huduma tofauti wa wingu. Mfano wa suluhisho kama hilo la kufunika ni Cisco Stealthwatch Cloud, ambayo inazingatia kazi moja - ufuatiliaji wa hitilafu za usalama wa habari katika mazingira ya wingu, ikiwa ni pamoja na sio tu Amazon AWS, Microsoft Azure na Google Cloud Platform, lakini pia mawingu ya kibinafsi.

Mfano: Ufuatiliaji wa Usalama wa Taarifa Kwa Kutumia Wingu la Stealthwatch

AWS hutoa jukwaa la kompyuta linalonyumbulika, lakini kubadilika huku hurahisisha makampuni kufanya makosa ambayo husababisha masuala ya usalama. Na mfano wa usalama wa habari ulioshirikiwa huchangia tu kwa hili. Kuendesha programu katika wingu na udhaifu usiojulikana (unaojulikana unaweza kupigana, kwa mfano, na Mkaguzi wa AWS au GCP Cloud Scanner), nywila dhaifu, usanidi usio sahihi, wa ndani, nk. Na hii yote inaonekana katika tabia ya rasilimali za wingu, ambazo zinaweza kufuatiliwa na Cisco Stealthwatch Cloud, ambayo ni ufuatiliaji wa usalama wa habari na mfumo wa kutambua mashambulizi. mawingu ya umma na ya kibinafsi.

Moja ya vipengele muhimu vya Cisco Stealthwatch Cloud ni uwezo wa kuiga huluki. Kwa hiyo, unaweza kuunda muundo wa programu (yaani, uigaji wa wakati halisi) wa kila rasilimali yako ya wingu (haijalishi ikiwa ni AWS, Azure, GCP, au kitu kingine). Hizi zinaweza kujumuisha seva na watumiaji, pamoja na aina za rasilimali maalum kwa mazingira yako ya wingu, kama vile vikundi vya usalama na vikundi vya kupima kiotomatiki. Miundo hii hutumia mitiririko ya data iliyopangwa inayotolewa na huduma za wingu kama ingizo. Kwa mfano, kwa AWS hizi zitakuwa Kumbukumbu za Mtiririko wa VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda, na AWS IAM. Uundaji wa huluki hugundua kiotomati jukumu na tabia ya nyenzo zako zozote (unaweza kuzungumza kuhusu kuorodhesha shughuli zote za wingu). Majukumu haya ni pamoja na kifaa cha rununu cha Android au Apple, seva ya Citrix PVS, seva ya RDP, lango la barua, mteja wa VoIP, seva ya terminal, kidhibiti cha kikoa, n.k. Kisha hufuatilia tabia zao mara kwa mara ili kubaini wakati tabia hatari au ya kutishia usalama inapotokea. Unaweza kutambua kubahatisha nenosiri, mashambulizi ya DDoS, uvujaji wa data, ufikiaji usio halali wa mbali, shughuli za msimbo hasidi, uchanganuzi wa uwezekano na vitisho vingine. Kwa mfano, hivi ndivyo kugundua jaribio la ufikiaji wa mbali kutoka kwa nchi isiyo ya kawaida kwa shirika lako (Korea Kusini) hadi kundi la Kubernetes kupitia SSH inaonekana kama:

Na hivi ndivyo madai ya uvujaji wa taarifa kutoka kwa hifadhidata ya Postgress hadi nchi ambayo hatujapata mwingiliano nayo inaonekana kama:

Hatimaye, hivi ndivyo majaribio mengi ya SSH yaliyofeli kutoka Uchina na Indonesia kutoka kwa kifaa cha mbali cha nje yanaonekana kama:

Au, tuseme kwamba mfano wa seva katika VPC, kwa sera, kamwe usiwe mahali pa kuingia kwa mbali. Hebu tuchukulie zaidi kwamba kompyuta hii ilipata logon ya mbali kutokana na mabadiliko ya kimakosa katika sera ya sheria za ngome. Kipengele cha Muundo wa Huluki kitatambua na kuripoti shughuli hii (“Ufikiaji Usio wa Kawaida wa Mbali”) karibu na muda halisi na kuelekeza kwenye AWS CloudTrail, Azure Monitor, au GCP Stackdriver Logging API simu (ikiwa ni pamoja na jina la mtumiaji, tarehe na saa, miongoni mwa maelezo mengine. ) ambayo ilisababisha mabadiliko ya sheria ya ITU. Na kisha habari hii inaweza kutumwa kwa SIEM kwa uchambuzi.

Uwezo sawa unatekelezwa kwa mazingira yoyote ya wingu yanayoungwa mkono na Wingu la Cisco Stealthwatch:

Muundo wa huluki ni aina ya kipekee ya otomatiki ya usalama ambayo inaweza kugundua shida isiyojulikana hapo awali na watu wako, michakato au teknolojia. Kwa mfano, hukuruhusu kugundua, kati ya mambo mengine, shida za usalama kama vile:

Je, kuna mtu amegundua mlango wa nyuma katika programu tunayotumia?
Je, kuna programu au kifaa cha wahusika wengine kwenye wingu letu?
Je, mtumiaji aliyeidhinishwa anatumia vibaya haki?
Je, kulikuwa na hitilafu ya usanidi iliyoruhusu ufikiaji wa mbali au matumizi mengine yasiyotarajiwa ya rasilimali?
Je, kuna uvujaji wa data kutoka kwa seva zetu?
Je, kuna mtu anayejaribu kuungana nasi kutoka eneo lisilo la kawaida la kijiografia?
Je, wingu letu limeathiriwa na msimbo hasidi?

Tukio la usalama wa taarifa lililotambuliwa linaweza kutumwa kwa njia ya tikiti inayolingana kwa Slack, Cisco Spark, mfumo wa usimamizi wa matukio ya PagerDuty, na pia kutumwa kwa SIEM mbalimbali, ikiwa ni pamoja na Splunk au ELK. Kwa muhtasari, tunaweza kusema kwamba ikiwa kampuni yako inatumia mkakati wa wingu nyingi na haizuiliwi na mtoa huduma yeyote wa wingu, uwezo wa ufuatiliaji wa usalama wa habari uliofafanuliwa hapo juu, kisha kutumia Cisco Stealthwatch Cloud ni chaguo nzuri kupata seti moja ya ufuatiliaji. uwezo kwa wachezaji wanaoongoza wa wingu - Amazon , Microsoft na Google. Jambo la kufurahisha zaidi ni kwamba ukilinganisha bei za Stealthwatch Cloud na leseni za hali ya juu za ufuatiliaji wa usalama wa habari katika AWS, Azure au GCP, inaweza kuibuka kuwa suluhisho la Cisco litakuwa nafuu zaidi kuliko uwezo uliojengwa wa Amazon, Microsoft. na suluhu za Google. Ni paradoxical, lakini ni kweli. Na mawingu zaidi na uwezo wao unaotumia, faida ya suluhisho iliyoimarishwa itakuwa dhahiri zaidi.

Zaidi ya hayo, Stealthwatch Cloud inaweza kufuatilia mawingu ya faragha yaliyotumwa katika shirika lako, kwa mfano, kulingana na vyombo vya Kubernetes au kwa kufuatilia mtiririko wa Netflow au trafiki ya mtandao inayopokelewa kupitia uakisi katika vifaa vya mtandao (hata vinavyozalishwa nchini), data ya AD au seva za DNS na kadhalika. Data hii yote itaboreshwa na taarifa ya Ujasusi wa Tishio iliyokusanywa na Cisco Talos, kundi kubwa zaidi lisilo la kiserikali lisilo la kiserikali la watafiti wa vitisho vya usalama wa mtandao.

Hii hukuruhusu kutekeleza mfumo wa ufuatiliaji wa pamoja kwa mawingu ya umma na mseto ambayo kampuni yako inaweza kutumia. Taarifa iliyokusanywa inaweza kisha kuchanganuliwa kwa kutumia uwezo uliojengewa ndani wa Stealthwatch Cloud au kutumwa kwa SIEM yako (Splunk, ELK, SumoLogic na zingine kadhaa zinaauniwa kwa chaguomsingi).

Kwa hili, tutakamilisha sehemu ya kwanza ya makala, ambayo nilipitia zana zilizojengwa na za nje za ufuatiliaji wa usalama wa habari wa majukwaa ya IaaS/PaaS, ambayo hutuwezesha kutambua haraka na kujibu matukio yanayotokea katika mazingira ya wingu ambayo biashara yetu imechagua. Katika sehemu ya pili, tutaendelea na mada na kuangalia chaguzi za ufuatiliaji wa majukwaa ya SaaS kwa kutumia mfano wa Salesforce na Dropbox, na pia tutajaribu kufupisha na kuweka kila kitu pamoja kwa kuunda mfumo wa ufuatiliaji wa usalama wa habari kwa watoa huduma tofauti wa wingu.

Chanzo: mapenzi.com

Ufuatiliaji wa Usalama wa Wingu