Monitro Diogelwch Cwmwl

Mae symud data a chymwysiadau i'r cwmwl yn cyflwyno her newydd i SOCs corfforaethol, nad ydynt bob amser yn barod i fonitro seilwaith pobl eraill. Yn ôl Netoskope, mae'r fenter gyfartalog (yn ôl pob tebyg yn yr Unol Daleithiau) yn defnyddio 1246 o wahanol wasanaethau cwmwl, sef 22% yn fwy na blwyddyn yn ôl. 1246 gwasanaeth cwmwl!!! Mae 175 ohonynt yn ymwneud â gwasanaethau AD, 170 yn ymwneud â marchnata, 110 yn y maes cyfathrebu a 76 ym maes cyllid a CRM. Mae Cisco yn defnyddio 700 o wasanaethau cwmwl allanol “yn unig”. Felly dwi wedi fy nrysu braidd gan y niferoedd hyn. Ond mewn unrhyw achos, nid yw'r broblem gyda nhw, ond gyda'r ffaith bod y cwmwl yn dechrau cael ei ddefnyddio'n eithaf gweithredol gan nifer cynyddol o gwmnïau a hoffai gael yr un galluoedd ar gyfer monitro seilwaith cwmwl ag yn eu rhwydwaith eu hunain. Ac mae'r duedd hon yn tyfu - yn ôl yn ôl Siambr Gyfrifon America Erbyn 2023, bydd 1200 o ganolfannau data ar gau yn yr Unol Daleithiau (mae 6250 eisoes wedi cau). Ond nid dim ond “gadewch i ni symud ein gweinyddwyr i ddarparwr allanol” yw'r newid i'r cwmwl. Pensaernïaeth TG newydd, meddalwedd newydd, prosesau newydd, cyfyngiadau newydd... Daw hyn i gyd â newidiadau sylweddol i waith nid yn unig TG, ond hefyd diogelwch gwybodaeth. Ac os yw darparwyr wedi dysgu ymdopi rywsut â sicrhau diogelwch y cwmwl ei hun (yn ffodus mae yna lawer o argymhellion), yna gyda monitro diogelwch gwybodaeth cwmwl, yn enwedig ar lwyfannau SaaS, mae anawsterau sylweddol, y byddwn yn siarad amdanynt.

Dywedwch fod eich cwmni wedi symud rhan o'i seilwaith i'r cwmwl... Stopiwch. Nid fel hyn. Os yw'r seilwaith wedi'i drosglwyddo, a dim ond nawr rydych chi'n meddwl sut y byddwch chi'n ei fonitro, yna rydych chi eisoes wedi colli. Oni bai ei fod yn Amazon, Google, neu Microsoft (ac yna gydag amheuon), mae'n debyg na fydd gennych lawer o allu i fonitro'ch data a'ch cymwysiadau. Mae'n dda os ydych yn cael y cyfle i weithio gyda logiau. Weithiau bydd data digwyddiadau diogelwch ar gael, ond ni fydd gennych fynediad iddo. Er enghraifft, Office 365. Os oes gennych y drwydded E1 rataf, yna nid yw digwyddiadau diogelwch ar gael i chi o gwbl. Os oes gennych drwydded E3, dim ond am 90 diwrnod y caiff eich data ei storio, a dim ond os oes gennych drwydded E5, mae hyd y logiau ar gael am flwyddyn (fodd bynnag, mae gan hyn hefyd ei naws ei hun sy'n gysylltiedig â'r angen i wneud hynny ar wahân. gofyn am nifer o swyddogaethau ar gyfer gweithio gyda logiau o gefnogaeth Microsoft). Gyda llaw, mae'r drwydded E3 yn llawer gwannach o ran swyddogaethau monitro na Chyfnewid corfforaethol. I gyrraedd yr un lefel, mae angen trwydded E5 neu drwydded Cydymffurfiaeth Uwch ychwanegol arnoch, a all fod angen arian ychwanegol na chafodd ei gynnwys yn eich model ariannol ar gyfer symud i seilwaith cwmwl. A dim ond un enghraifft yw hon o danamcangyfrif materion yn ymwneud â monitro diogelwch gwybodaeth cwmwl. Yn yr erthygl hon, heb esgus bod yn gyflawn, rwyf am dynnu sylw at rai arlliwiau y dylid eu hystyried wrth ddewis darparwr cwmwl o safbwynt diogelwch. Ac ar ddiwedd yr erthygl, rhoddir rhestr wirio sy'n werth ei chwblhau cyn ystyried bod y mater o fonitro diogelwch gwybodaeth cwmwl wedi'i ddatrys.

Mae yna nifer o broblemau nodweddiadol sy'n arwain at ddigwyddiadau mewn amgylcheddau cwmwl, nad oes gan wasanaethau diogelwch gwybodaeth amser i ymateb iddynt neu nad ydynt yn eu gweld o gwbl:

• Nid yw logiau diogelwch yn bodoli. Mae hon yn sefyllfa eithaf cyffredin, yn enwedig ymhlith chwaraewyr newydd yn y farchnad datrysiadau cwmwl. Ond ni ddylech roi'r gorau iddyn nhw ar unwaith. Mae chwaraewyr bach, yn enwedig rhai domestig, yn fwy sensitif i ofynion cwsmeriaid a gallant weithredu rhai swyddogaethau gofynnol yn gyflym trwy newid y map ffordd cymeradwy ar gyfer eu cynhyrchion. Ydy, nid analog o GuardDuty o Amazon na'r modiwl “Proactive Protection” o Bitrix fydd hwn, ond o leiaf rhywbeth.
• Nid yw diogelwch gwybodaeth yn gwybod ble mae'r logiau'n cael eu storio neu nid oes mynediad iddynt. Yma mae angen cychwyn trafodaethau gyda'r darparwr gwasanaeth cwmwl - efallai y bydd yn darparu gwybodaeth o'r fath os yw'n ystyried bod y cleient yn arwyddocaol iddo. Ond yn gyffredinol, nid yw'n dda iawn pan ddarperir mynediad at logiau “trwy benderfyniad arbennig.”
• Mae hefyd yn digwydd bod gan y darparwr cwmwl logiau, ond maent yn darparu monitro cyfyngedig a chofnodi digwyddiadau, nad ydynt yn ddigonol i ganfod pob digwyddiad. Er enghraifft, efallai mai dim ond logiau o newidiadau y byddwch yn eu derbyn ar wefan neu logiau o ymdrechion dilysu defnyddwyr, ond nid digwyddiadau eraill, megis traffig rhwydwaith, a fydd yn cuddio oddi wrthych haen gyfan o ddigwyddiadau sy'n nodweddu ymdrechion i hacio eich seilwaith cwmwl.
• Mae yna logiau, ond mae'n anodd awtomeiddio mynediad atynt, sy'n eu gorfodi i gael eu monitro nid yn barhaus, ond ar amserlen. Ac os na allwch lawrlwytho logiau yn awtomatig, yna gall lawrlwytho logiau, er enghraifft, ar ffurf Excel (fel gyda nifer o ddarparwyr datrysiadau cwmwl domestig), hyd yn oed arwain at amharodrwydd ar ran y gwasanaeth diogelwch gwybodaeth corfforaethol i tinceru gyda nhw.
• Dim monitro log. Efallai mai dyma'r rheswm mwyaf aneglur dros ddigwyddiadau diogelwch gwybodaeth mewn amgylcheddau cwmwl. Mae'n ymddangos bod yna logiau, ac mae'n bosibl awtomeiddio mynediad iddynt, ond nid oes neb yn gwneud hyn. Pam?

Cysyniad diogelwch cwmwl a rennir

Mae'r newid i'r cwmwl bob amser yn chwilio am gydbwysedd rhwng yr awydd i gadw rheolaeth dros y seilwaith a'i drosglwyddo i ddwylo mwy proffesiynol darparwr cwmwl sy'n arbenigo mewn cynnal a chadw. Ac ym maes diogelwch cwmwl, rhaid ceisio'r cydbwysedd hwn hefyd. Ar ben hynny, yn dibynnu ar y model darparu gwasanaeth cwmwl a ddefnyddir (IaaS, PaaS, SaaS), bydd y cydbwysedd hwn yn wahanol drwy'r amser. Mewn unrhyw achos, rhaid inni gofio bod pob darparwr cwmwl heddiw yn dilyn y model rhannu cyfrifoldeb a diogelwch gwybodaeth a rennir fel y'i gelwir. Mae'r cwmwl yn gyfrifol am rai pethau, ac i eraill y cleient sy'n gyfrifol, gan osod ei ddata, ei gymwysiadau, ei beiriannau rhithwir ac adnoddau eraill yn y cwmwl. Byddai'n ddi-hid disgwyl, trwy fynd i'r cwmwl, y byddwn yn symud yr holl gyfrifoldeb i'r darparwr. Ond mae hefyd yn annoeth adeiladu'r holl ddiogelwch eich hun wrth symud i'r cwmwl. Mae angen cydbwysedd, a fydd yn dibynnu ar lawer o ffactorau: - strategaeth rheoli risg, model bygythiad, mecanweithiau diogelwch sydd ar gael i ddarparwr y cwmwl, deddfwriaeth, ac ati.

Er enghraifft, cyfrifoldeb y cwsmer bob amser yw dosbarthu data a gedwir yn y cwmwl. Dim ond gydag offer a fydd yn helpu i farcio data yn y cwmwl, nodi troseddau, dileu data sy'n torri'r gyfraith, neu ei guddio gan ddefnyddio un dull neu'r llall y gall darparwr cwmwl neu ddarparwr gwasanaeth allanol ei helpu. Ar y llaw arall, mae diogelwch corfforol bob amser yn gyfrifoldeb y darparwr cwmwl, na all ei rannu â chleientiaid. Ond mae popeth sydd rhwng data a seilwaith ffisegol yn union destun trafodaeth yn yr erthygl hon. Er enghraifft, cyfrifoldeb y darparwr yw argaeledd y cwmwl, a chyfrifoldeb y cleient yw sefydlu rheolau wal dân neu alluogi amgryptio. Yn yr erthygl hon byddwn yn ceisio edrych ar ba fecanweithiau monitro diogelwch gwybodaeth a ddarperir heddiw gan wahanol ddarparwyr cwmwl poblogaidd yn Rwsia, beth yw nodweddion eu defnydd, a phryd mae'n werth edrych tuag at atebion troshaen allanol (er enghraifft, Cisco E- post Security) sy'n ehangu galluoedd eich cwmwl o ran seiberddiogelwch. Mewn rhai achosion, yn enwedig os ydych chi'n dilyn strategaeth aml-gwmwl, ni fydd gennych unrhyw ddewis ond defnyddio datrysiadau monitro diogelwch gwybodaeth allanol mewn sawl amgylchedd cwmwl ar unwaith (er enghraifft, Cisco CloudLock neu Cisco Stealthwatch Cloud). Wel, mewn rhai achosion byddwch chi'n sylweddoli nad yw'r darparwr cwmwl rydych chi wedi'i ddewis (neu wedi'i orfodi arnoch chi) yn cynnig unrhyw alluoedd monitro diogelwch gwybodaeth o gwbl. Mae hyn yn annymunol, ond hefyd nid ychydig, gan ei fod yn caniatáu ichi asesu'n ddigonol lefel y risg sy'n gysylltiedig â gweithio gyda'r cwmwl hwn.

Cylch Bywyd Monitro Diogelwch Cwmwl

I fonitro diogelwch y cymylau a ddefnyddiwch, dim ond tri opsiwn sydd gennych:

• dibynnu ar yr offer a ddarperir gan eich darparwr cwmwl,
• defnyddio datrysiadau gan drydydd partïon a fydd yn monitro'r llwyfannau IaaS, PaaS neu SaaS a ddefnyddiwch,
• adeiladu eich seilwaith monitro cwmwl eich hun (ar gyfer llwyfannau IaaS/PaaS yn unig).

Gadewch i ni weld pa nodweddion sydd gan bob un o'r opsiynau hyn. Ond yn gyntaf, mae angen inni ddeall y fframwaith cyffredinol a ddefnyddir wrth fonitro llwyfannau cwmwl. Hoffwn dynnu sylw at 6 phrif elfen o’r broses monitro diogelwch gwybodaeth yn y cwmwl:

• Paratoi seilwaith. Pennu'r cymwysiadau a'r seilwaith angenrheidiol ar gyfer casglu digwyddiadau sy'n bwysig i ddiogelu gwybodaeth yn y storfa.
• Casgliad. Ar yr adeg hon, mae digwyddiadau diogelwch yn cael eu hagregu o wahanol ffynonellau i'w trosglwyddo wedyn ar gyfer prosesu, storio a dadansoddi.
• Triniaeth. Ar yr adeg hon, caiff y data ei drawsnewid a'i gyfoethogi i hwyluso dadansoddiad dilynol.
• Storio. Mae'r gydran hon yn gyfrifol am storio data prosesu a data crai a gasglwyd yn y tymor byr a'r tymor hir.
• Dadansoddi. Ar y cam hwn, mae gennych y gallu i ganfod digwyddiadau ac ymateb iddynt yn awtomatig neu â llaw.
• Adrodd. Mae'r cam hwn yn helpu i lunio dangosyddion allweddol ar gyfer rhanddeiliaid (rheolwyr, archwilwyr, darparwr cwmwl, cleientiaid, ac ati) sy'n ein helpu i wneud penderfyniadau penodol, er enghraifft, newid darparwr neu gryfhau diogelwch gwybodaeth.

Bydd deall y cydrannau hyn yn eich galluogi i benderfynu'n gyflym yn y dyfodol beth allwch chi ei gymryd gan eich darparwr, a beth fydd yn rhaid i chi ei wneud eich hun neu gyda chymorth ymgynghorwyr allanol.

Gwasanaethau cwmwl adeiledig

Ysgrifennais eisoes uchod nad yw llawer o wasanaethau cwmwl heddiw yn darparu unrhyw alluoedd monitro diogelwch gwybodaeth. Yn gyffredinol, nid ydynt yn talu llawer o sylw i bwnc diogelwch gwybodaeth. Er enghraifft, un o'r gwasanaethau Rwsia poblogaidd ar gyfer anfon adroddiadau at asiantaethau'r llywodraeth dros y Rhyngrwyd (ni fyddaf yn sôn yn benodol am ei enw). Mae'r adran gyfan ar ddiogelwch y gwasanaeth hwn yn ymwneud â defnyddio CIPF ardystiedig. Nid yw adran diogelwch gwybodaeth gwasanaeth cwmwl domestig arall ar gyfer rheoli dogfennau electronig yn wahanol. Mae'n sôn am dystysgrifau allweddol cyhoeddus, cryptograffeg ardystiedig, dileu gwendidau gwe, amddiffyniad rhag ymosodiadau DDoS, defnyddio waliau tân, copïau wrth gefn, a hyd yn oed archwiliadau diogelwch gwybodaeth rheolaidd. Ond nid oes gair am fonitro, nac am y posibilrwydd o gael mynediad i ddigwyddiadau diogelwch gwybodaeth a allai fod o ddiddordeb i gleientiaid y darparwr gwasanaeth hwn.

Yn gyffredinol, gyda llaw mae darparwr y cwmwl yn disgrifio materion diogelwch gwybodaeth ar ei wefan ac yn ei ddogfennaeth, gallwch ddeall pa mor ddifrifol y mae'n cymryd y mater hwn. Er enghraifft, os ydych chi'n darllen y llawlyfrau ar gyfer cynhyrchion “Fy Swyddfa”, nid oes gair am ddiogelwch o gwbl, ond yn y ddogfennaeth ar gyfer y cynnyrch ar wahân “My Office. KS3”, a gynlluniwyd i amddiffyn rhag mynediad anawdurdodedig, mae rhestr arferol o bwyntiau o 17eg gorchymyn y FSTEC, y mae “Fy Swyddfa.KS3” yn ei weithredu, ond ni chaiff ei ddisgrifio sut mae'n ei weithredu ac, yn bwysicaf oll, sut i integreiddio'r mecanweithiau hyn gyda diogelwch gwybodaeth corfforaethol. Efallai bod dogfennaeth o’r fath yn bodoli, ond ni ddois o hyd iddo yn y parth cyhoeddus, ar wefan “Fy Swyddfa”. Er efallai nad oes gen i fynediad at y wybodaeth gyfrinachol hon?..

Ar gyfer Bitrix, mae'r sefyllfa'n llawer gwell. Mae'r ddogfennaeth yn disgrifio fformatau'r logiau digwyddiadau ac, yn ddiddorol, y log ymwthiad, sy'n cynnwys digwyddiadau sy'n gysylltiedig â bygythiadau posibl i'r platfform cwmwl. Oddi yno gallwch dynnu'r IP, enw defnyddiwr neu westai, ffynhonnell digwyddiad, amser, Asiant Defnyddiwr, math o ddigwyddiad, ac ati. Yn wir, gallwch chi weithio gyda'r digwyddiadau hyn naill ai o banel rheoli'r cwmwl ei hun, neu uwchlwytho data mewn fformat MS Excel. Mae bellach yn anodd awtomeiddio gwaith gyda logiau Bitrix a bydd yn rhaid i chi wneud rhywfaint o'r gwaith â llaw (llwytho'r adroddiad a'i lwytho i mewn i'ch SIEM). Ond os cofiwn nad oedd cyfle o'r fath yn bodoli tan yn gymharol ddiweddar, yna mae hwn yn gynnydd mawr. Ar yr un pryd, hoffwn nodi bod llawer o ddarparwyr cwmwl tramor yn cynnig ymarferoldeb tebyg “ar gyfer dechreuwyr” - naill ai edrychwch ar y logiau gyda'ch llygaid trwy'r panel rheoli, neu uwchlwythwch y data i chi'ch hun (fodd bynnag, mae'r rhan fwyaf yn llwytho data i mewn . fformat csv, nid Excel).

Heb ystyried yr opsiwn dim logiau, mae darparwyr cwmwl fel arfer yn cynnig tri opsiwn i chi ar gyfer monitro digwyddiadau diogelwch - dangosfyrddau, lanlwytho data a mynediad API. Mae'n ymddangos bod y cyntaf yn datrys llawer o broblemau i chi, ond nid yw hyn yn gwbl wir - os oes gennych chi sawl cylchgrawn, mae'n rhaid i chi newid rhwng y sgriniau sy'n eu harddangos, gan golli'r darlun cyffredinol. Yn ogystal, mae'r darparwr cwmwl yn annhebygol o roi'r gallu i chi gydberthyn digwyddiadau diogelwch a'u dadansoddi'n gyffredinol o safbwynt diogelwch (fel arfer rydych chi'n delio â data crai, y mae angen i chi ei ddeall eich hun). Mae yna eithriadau a byddwn yn siarad amdanynt ymhellach. Yn olaf, mae'n werth gofyn pa ddigwyddiadau sy'n cael eu cofnodi gan eich darparwr cwmwl, ym mha fformat, a sut maen nhw'n cyfateb i'ch proses monitro diogelwch gwybodaeth? Er enghraifft, adnabod a dilysu defnyddwyr a gwesteion. Mae'r un Bitrix yn caniatáu ichi, yn seiliedig ar y digwyddiadau hyn, gofnodi dyddiad ac amser y digwyddiad, enw'r defnyddiwr neu'r gwestai (os oes gennych y modiwl “Web Analytics”), y gwrthrych a gyrchir ac elfennau eraill sy'n nodweddiadol ar gyfer gwefan . Ond efallai y bydd angen gwybodaeth ar wasanaethau diogelwch gwybodaeth corfforaethol ynghylch a yw'r defnyddiwr wedi cyrchu'r cwmwl o ddyfais y gellir ymddiried ynddi (er enghraifft, mewn rhwydwaith corfforaethol mae'r dasg hon yn cael ei gweithredu gan Cisco ISE). Beth am dasg mor syml â'r swyddogaeth geo-IP, a fydd yn helpu i benderfynu a yw cyfrif defnyddiwr gwasanaeth cwmwl wedi'i ddwyn? A hyd yn oed os yw darparwr y cwmwl yn ei ddarparu i chi, nid yw hyn yn ddigon. Nid yw'r un Cisco CloudLock yn dadansoddi geolocation yn unig, ond mae'n defnyddio dysgu peiriant ar gyfer hyn ac yn dadansoddi data hanesyddol ar gyfer pob defnyddiwr ac yn monitro anghysondebau amrywiol mewn ymdrechion adnabod a dilysu. Dim ond MS Azure sydd â swyddogaeth debyg (os oes gennych y tanysgrifiad priodol).

Mae anhawster arall - oherwydd i lawer o ddarparwyr cwmwl mae monitro diogelwch gwybodaeth yn bwnc newydd y maent newydd ddechrau delio ag ef, maent yn newid rhywbeth yn eu datrysiadau yn gyson. Heddiw mae ganddyn nhw un fersiwn o'r API, yfory un arall, y diwrnod ar ôl yfory traean. Mae angen i chi fod yn barod ar gyfer hyn hefyd. Mae'r un peth yn wir gydag ymarferoldeb, a all newid, y mae'n rhaid ei gymryd i ystyriaeth yn eich system monitro diogelwch gwybodaeth. Er enghraifft, i ddechrau roedd gan Amazon wasanaethau monitro digwyddiadau cwmwl ar wahân - AWS CloudTrail ac AWS CloudWatch. Yna ymddangosodd gwasanaeth ar wahân ar gyfer monitro digwyddiadau diogelwch gwybodaeth - AWS GuardDuty. Ar ôl peth amser, lansiodd Amazon system reoli newydd, Amazon Security Hub, sy'n cynnwys dadansoddiad o ddata a dderbyniwyd gan GuardDuty, Amazon Inspector, Amazon Macie a sawl un arall. Enghraifft arall yw offeryn integreiddio log Azure gyda SIEM - AzLog. Fe'i defnyddiwyd yn weithredol gan lawer o werthwyr SIEM, nes yn 2018 cyhoeddodd Microsoft y byddai ei ddatblygiad a'i gefnogaeth yn dod i ben, a wynebodd lawer o gleientiaid a ddefnyddiodd yr offeryn hwn â phroblem (byddwn yn siarad am sut y cafodd ei ddatrys yn nes ymlaen).

Felly, monitro'n ofalus yr holl nodweddion monitro y mae eich darparwr cwmwl yn eu cynnig i chi. Neu dibynnu ar ddarparwyr datrysiadau allanol a fydd yn gweithredu fel cyfryngwyr rhwng eich SOC a'r cwmwl rydych chi am ei fonitro. Bydd, bydd yn ddrytach (er nid bob amser), ond byddwch yn symud yr holl gyfrifoldeb i ysgwyddau rhywun arall. Neu ddim y cyfan?.. Gadewch i ni gofio'r cysyniad o ddiogelwch a rennir a deall na allwn symud unrhyw beth - bydd yn rhaid i ni ddeall yn annibynnol sut mae gwahanol ddarparwyr cwmwl yn darparu monitro diogelwch gwybodaeth eich data, cymwysiadau, peiriannau rhithwir ac adnoddau eraill cynnal yn y cwmwl. A byddwn yn dechrau gyda'r hyn y mae Amazon yn ei gynnig yn y rhan hon.

Enghraifft: Monitro diogelwch gwybodaeth yn IaaS yn seiliedig ar AWS

Ydw, ydw, rwy'n deall nad Amazon yw'r enghraifft orau oherwydd y ffaith mai gwasanaeth Americanaidd yw hwn a gellir ei rwystro fel rhan o'r frwydr yn erbyn eithafiaeth a lledaenu gwybodaeth a waherddir yn Rwsia. Ond yn y cyhoeddiad hwn hoffwn ddangos sut mae gwahanol lwyfannau cwmwl yn wahanol yn eu galluoedd monitro diogelwch gwybodaeth a'r hyn y dylech roi sylw iddo wrth drosglwyddo'ch prosesau allweddol i'r cymylau o safbwynt diogelwch. Wel, os yw rhai o ddatblygwyr datrysiadau cwmwl Rwsia yn dysgu rhywbeth defnyddiol drostynt eu hunain, yna bydd hynny'n wych.

Y peth cyntaf i'w ddweud yw nad yw Amazon yn gaer anhreiddiadwy. Mae digwyddiadau amrywiol yn digwydd yn rheolaidd i'w gleientiaid. Er enghraifft, cafodd enwau, cyfeiriadau, dyddiadau geni, a rhifau ffôn 198 miliwn o bleidleiswyr eu dwyn o Deep Root Analytics. Fe wnaeth cwmni Israel Nice Systems ddwyn 14 miliwn o gofnodion o danysgrifwyr Verizon. Fodd bynnag, mae galluoedd adeiledig AWS yn eich galluogi i ganfod ystod eang o ddigwyddiadau. Er enghraifft:

• effaith ar seilwaith (DDoS)
• cyfaddawd nod (chwistrelliad gorchymyn)
• peryglu cyfrif a mynediad heb awdurdod
• cyfluniad anghywir a gwendidau
• rhyngwynebau ac APIs anniogel.

Mae'r anghysondeb hwn i'w briodoli i'r ffaith mai'r cwsmer ei hun, fel y canfuwyd uchod, sy'n gyfrifol am ddiogelwch data cwsmeriaid. Ac os na fydd yn trafferthu i droi ar fecanweithiau amddiffynnol ac nad oedd yn troi ar offer monitro, yna bydd yn dysgu am y digwyddiad yn unig gan y cyfryngau neu gan ei gleientiaid.

I nodi digwyddiadau, gallwch ddefnyddio ystod eang o wahanol wasanaethau monitro a ddatblygwyd gan Amazon (er bod y rhain yn aml yn cael eu hategu gan offer allanol fel osquery). Felly, yn AWS, mae holl gamau gweithredu defnyddwyr yn cael eu monitro, waeth sut y cânt eu cyflawni - trwy'r consol rheoli, llinell orchymyn, SDK neu wasanaethau AWS eraill. Mae pob cofnod o weithgaredd pob cyfrif AWS (gan gynnwys enw defnyddiwr, gweithred, gwasanaeth, paramedrau gweithgaredd, a chanlyniad) a defnydd API ar gael trwy AWS CloudTrail. Gallwch weld y digwyddiadau hyn (fel mewngofnodi consol AWS IAM) o'r consol CloudTrail, eu dadansoddi gan ddefnyddio Amazon Athena, neu eu “rhoi ar gontract” i atebion allanol fel Splunk, AlienVault, ac ati. Mae logiau AWS CloudTrail eu hunain yn cael eu gosod yn eich bwced AWS S3.

Mae dau wasanaeth AWS arall yn darparu nifer o alluoedd monitro pwysig eraill. Yn gyntaf, mae Amazon CloudWatch yn wasanaeth monitro ar gyfer adnoddau a chymwysiadau AWS sydd, ymhlith pethau eraill, yn caniatáu ichi nodi anghysondebau amrywiol yn eich cwmwl. Mae'r holl wasanaethau AWS adeiledig, megis Amazon Elastic Compute Cloud (gweinyddwyr), Gwasanaeth Cronfa Ddata Perthynol Amazon (cronfeydd data), Amazon Elastic MapReduce (dadansoddiad data), a 30 o wasanaethau Amazon eraill, yn defnyddio Amazon CloudWatch i storio eu logiau. Gall datblygwyr ddefnyddio'r API agored o Amazon CloudWatch i ychwanegu ymarferoldeb monitro logiau at gymwysiadau a gwasanaethau arferol, gan ganiatáu iddynt ehangu cwmpas dadansoddi digwyddiadau o fewn cyd-destun diogelwch.

Yn ail, mae gwasanaeth Logiau Llif VPC yn caniatáu ichi ddadansoddi'r traffig rhwydwaith a anfonwyd neu a dderbynnir gan eich gweinyddwyr AWS (yn allanol neu'n fewnol), yn ogystal â rhwng microwasanaethau. Pan fydd unrhyw un o'ch adnoddau AWS VPC yn rhyngweithio â'r rhwydwaith, mae Logiau Llif VPC yn cofnodi manylion am draffig y rhwydwaith, gan gynnwys y rhyngwyneb rhwydwaith ffynhonnell a chyrchfan, yn ogystal â'r cyfeiriadau IP, porthladdoedd, protocol, nifer y beit, a nifer y pecynnau rydych chi gwelodd. Bydd y rhai sydd â phrofiad o ddiogelwch rhwydwaith lleol yn cydnabod hyn fel rhywbeth tebyg i edafedd NetFlow, y gellir eu creu gan switshis, llwybryddion a waliau tân gradd menter. Mae'r logiau hyn yn bwysig at ddibenion monitro diogelwch gwybodaeth oherwydd, yn wahanol i ddigwyddiadau am weithredoedd defnyddwyr a chymwysiadau, maent hefyd yn caniatáu ichi beidio â cholli rhyngweithiadau rhwydwaith yn amgylchedd cwmwl preifat rhithwir AWS.

I grynhoi, mae'r tri gwasanaeth AWS hyn - AWS CloudTrail, Amazon CloudWatch, a VPC Flow Logs - gyda'i gilydd yn rhoi mewnwelediad eithaf pwerus i'ch defnydd cyfrif, ymddygiad defnyddwyr, rheoli seilwaith, gweithgaredd cymhwysiad a gwasanaeth, a gweithgaredd rhwydwaith. Er enghraifft, gellir eu defnyddio i ganfod yr anomaleddau canlynol:

• Ymdrechion i sganio'r wefan, chwilio am ddrysau cefn, chwilio am wendidau trwy byliau o “404 gwall”.
• Ymosodiadau chwistrellu (er enghraifft, chwistrelliad SQL) trwy byliau o “wallau 500”.
• Offer ymosod hysbys yw sqlmap, nikto, w3af, nmap, ac ati. trwy ddadansoddi'r maes Asiant Defnyddiwr.

Mae Amazon Web Services hefyd wedi datblygu gwasanaethau eraill at ddibenion seiberddiogelwch sy'n eich galluogi i ddatrys llawer o broblemau eraill. Er enghraifft, mae gan AWS wasanaeth adeiledig ar gyfer archwilio polisïau a chyfluniadau - AWS Config. Mae'r gwasanaeth hwn yn darparu archwiliad parhaus o'ch adnoddau AWS a'u ffurfweddiadau. Gadewch i ni gymryd enghraifft syml: Gadewch i ni ddweud eich bod am sicrhau bod cyfrineiriau defnyddwyr wedi'u hanalluogi ar eich holl weinyddion a bod mynediad yn bosibl ar sail tystysgrifau yn unig. Mae AWS Config yn ei gwneud hi'n hawdd gwirio hyn ar gyfer eich holl weinyddion. Mae yna bolisïau eraill y gellir eu cymhwyso i'ch gweinyddwyr cwmwl: “Ni all unrhyw weinydd ddefnyddio porthladd 22”, “Dim ond gweinyddwyr all newid rheolau wal dân” neu “Dim ond defnyddiwr Ivashko all greu cyfrifon defnyddwyr newydd, a gall wneud hynny ar ddydd Mawrth yn unig. " Yn ystod haf 2016, ehangwyd gwasanaeth Config AWS i awtomeiddio'r gwaith o ganfod troseddau polisïau datblygedig. Yn y bôn, mae Rheolau Ffurfwedd AWS yn geisiadau cyfluniad parhaus ar gyfer y gwasanaethau Amazon rydych chi'n eu defnyddio, sy'n cynhyrchu digwyddiadau os caiff y polisïau cyfatebol eu torri. Er enghraifft, yn lle rhedeg ymholiadau AWS Config o bryd i'w gilydd i wirio bod yr holl ddisgiau ar weinydd rhithwir wedi'u hamgryptio, gellir defnyddio Rheolau Ffurfweddu AWS i wirio disgiau gweinydd yn barhaus i sicrhau bod yr amod hwn yn cael ei fodloni. Ac, yn bwysicaf oll, yng nghyd-destun y cyhoeddiad hwn, mae unrhyw doriadau yn arwain at ddigwyddiadau y gellir eu dadansoddi gan eich gwasanaeth diogelwch gwybodaeth.

Mae gan AWS hefyd ei gyfwerth ag atebion diogelwch gwybodaeth corfforaethol traddodiadol, sydd hefyd yn cynhyrchu digwyddiadau diogelwch y gallwch ac y dylech eu dadansoddi:

• Canfod Ymyrraeth - AWS GuardDuty
• Rheoli Gollyngiadau Gwybodaeth - AWS Macie
• EDR (er ei fod yn siarad am bwyntiau terfyn yn y cwmwl ychydig yn rhyfedd) - AWS Cloudwatch + osquery ffynhonnell agored neu atebion GRR
• Dadansoddiad Netflow - AWS Cloudwatch + AWS VPC Llif
• Dadansoddiad DNS - AWS Cloudwatch + AWS Route53
• AD - Gwasanaeth Cyfeiriadur AWS
• Rheoli Cyfrifon - AWS IAM
• SSO - AWS SSO
• dadansoddiad diogelwch - Arolygydd AWS
• rheoli cyfluniad - AWS Config
• WAF - AWS WAF.

Ni fyddaf yn disgrifio'n fanwl holl wasanaethau Amazon a allai fod yn ddefnyddiol yng nghyd-destun diogelwch gwybodaeth. Y prif beth yw deall y gall pob un ohonynt gynhyrchu digwyddiadau y gallwn ac y dylem eu dadansoddi yng nghyd-destun diogelwch gwybodaeth, gan ddefnyddio at y diben hwn alluoedd adeiledig Amazon ei hun ac atebion allanol, er enghraifft, SIEM, a all ewch â digwyddiadau diogelwch i'ch canolfan fonitro a'u dadansoddi yno ynghyd â digwyddiadau o wasanaethau cwmwl eraill neu o seilwaith mewnol, perimedr neu ddyfeisiau symudol.

Beth bynnag, mae'r cyfan yn dechrau gyda'r ffynonellau data sy'n darparu digwyddiadau diogelwch gwybodaeth i chi. Mae’r ffynonellau hyn yn cynnwys, ond heb fod yn gyfyngedig i:

• CloudTrail - Defnydd API a Gweithrediadau Defnyddiwr
• Cynghorydd Dibynadwy - gwiriad diogelwch yn erbyn arferion gorau
• Config - rhestr eiddo a chyfluniad o gyfrifon a gosodiadau gwasanaeth
• Logiau Llif VPC - cysylltiadau â rhyngwynebau rhithwir
• IAM - gwasanaeth adnabod a dilysu
• Logiau Mynediad ELB - Cydbwysedd Llwyth
• Arolygydd - gwendidau ceisiadau
• S3 - storio ffeiliau
• CloudWatch - Gweithgaredd Cymhwysiad
• Gwasanaeth hysbysu yw SNS.

Mae Amazon, er ei fod yn cynnig ystod o ffynonellau ac offer digwyddiadau ar gyfer eu cenhedlaeth, yn gyfyngedig iawn yn ei allu i ddadansoddi'r data a gasglwyd yng nghyd-destun diogelwch gwybodaeth. Bydd yn rhaid i chi astudio'r logiau sydd ar gael yn annibynnol, gan chwilio am ddangosyddion cyfaddawd perthnasol ynddynt. Nod AWS Security Hub, a lansiwyd gan Amazon yn ddiweddar, yw datrys y broblem hon trwy ddod yn SIEM cwmwl ar gyfer AWS. Ond hyd yn hyn dim ond ar ddechrau ei daith ydyw ac mae wedi'i gyfyngu gan nifer y ffynonellau y mae'n gweithio â nhw a chan gyfyngiadau eraill a sefydlwyd gan bensaernïaeth a thanysgrifiadau Amazon ei hun.

Enghraifft: Monitro diogelwch gwybodaeth yn IaaS yn seiliedig ar Azure

Nid wyf am fynd i ddadl hir ynghylch pa un o'r tri darparwr cwmwl (Amazon, Microsoft neu Google) sy'n well (yn enwedig gan fod gan bob un ohonynt ei fanylion penodol ei hun o hyd ac yn addas ar gyfer datrys ei broblemau ei hun); Gadewch i ni ganolbwyntio ar y galluoedd monitro diogelwch gwybodaeth y mae'r chwaraewyr hyn yn eu darparu. Rhaid cyfaddef mai Amazon AWS oedd un o'r rhai cyntaf yn y gylchran hon ac felly mae wedi datblygu bellaf o ran ei swyddogaethau diogelwch gwybodaeth (er bod llawer yn cyfaddef eu bod yn anodd eu defnyddio). Ond nid yw hyn yn golygu y byddwn yn anwybyddu'r cyfleoedd y mae Microsoft a Google yn eu darparu i ni.

Mae cynhyrchion Microsoft bob amser wedi cael eu gwahaniaethu gan eu “bod yn agored” ac yn Azure mae'r sefyllfa yn debyg. Er enghraifft, os yw AWS a GCP bob amser yn symud ymlaen o'r cysyniad “mae'r hyn na chaniateir yn cael ei wahardd,” yna mae gan Azure yr union ddull i'r gwrthwyneb. Er enghraifft, wrth greu rhwydwaith rhithwir yn y cwmwl a pheiriant rhithwir ynddo, mae'r holl borthladdoedd a phrotocolau yn agored ac yn cael eu caniatáu yn ddiofyn. Felly, bydd yn rhaid i chi dreulio ychydig mwy o ymdrech ar sefydlu cychwynnol y system rheoli mynediad yn y cwmwl gan Microsoft. Ac mae hyn hefyd yn gosod gofynion llymach arnoch chi o ran monitro gweithgaredd yn y cwmwl Azure.

Mae gan AWS hynodrwydd sy'n gysylltiedig â'r ffaith, pan fyddwch chi'n monitro'ch adnoddau rhithwir, os ydyn nhw wedi'u lleoli mewn gwahanol ranbarthau, yna rydych chi'n cael anawsterau wrth gyfuno'r holl ddigwyddiadau a'u dadansoddiad unedig, i ddileu pa rai sydd angen i chi droi at driciau amrywiol, megis Creu eich cod eich hun ar gyfer AWS Lambda a fydd yn cludo digwyddiadau rhwng rhanbarthau. Nid oes gan Azure y broblem hon - mae ei fecanwaith Log Gweithgaredd yn olrhain pob gweithgaredd ar draws y sefydliad cyfan heb gyfyngiadau. Mae'r un peth yn berthnasol i AWS Security Hub, a ddatblygwyd yn ddiweddar gan Amazon i gydgrynhoi llawer o swyddogaethau diogelwch o fewn un ganolfan ddiogelwch, ond dim ond o fewn ei ranbarth, nad yw, fodd bynnag, yn berthnasol i Rwsia. Mae gan Azure ei Ganolfan Ddiogelwch ei hun, nad yw wedi'i rhwymo gan gyfyngiadau rhanbarthol, gan ddarparu mynediad i holl nodweddion diogelwch y platfform cwmwl. Ar ben hynny, ar gyfer gwahanol dimau lleol gall ddarparu ei set ei hun o alluoedd amddiffynnol, gan gynnwys digwyddiadau diogelwch a reolir ganddynt. Mae AWS Security Hub yn dal i fod ar ei ffordd i ddod yn debyg i Ganolfan Ddiogelwch Azure. Ond mae'n werth ychwanegu pryfyn yn yr eli - gallwch chi wasgu allan o Azure lawer o'r hyn a ddisgrifiwyd yn flaenorol yn AWS, ond dim ond ar gyfer Azure AD, Azure Monitor a Chanolfan Ddiogelwch Azure y gwneir hyn yn fwyaf cyfleus. Nid yw holl fecanweithiau diogelwch Azure eraill, gan gynnwys dadansoddi digwyddiadau diogelwch, yn cael eu rheoli yn y ffordd fwyaf cyfleus eto. Mae'r broblem yn cael ei datrys yn rhannol gan yr API, sy'n treiddio trwy holl wasanaethau Microsoft Azure, ond bydd hyn yn gofyn am ymdrech ychwanegol gennych chi i integreiddio'ch cwmwl â'ch SOC a phresenoldeb arbenigwyr cymwys (mewn gwirionedd, yn union fel gydag unrhyw SIEM arall sy'n gweithio gyda APIs cwmwl). Mae rhai SIEMs, a fydd yn cael eu trafod yn ddiweddarach, eisoes yn cefnogi Azure a gallant awtomeiddio'r dasg o'i fonitro, ond mae ganddo hefyd ei anawsterau ei hun - ni all pob un ohonynt gasglu'r holl logiau sydd gan Azure.

Darperir casglu a monitro digwyddiadau yn Azure gan ddefnyddio gwasanaeth Azure Monitor, sef y prif offeryn ar gyfer casglu, storio a dadansoddi data yn y cwmwl Microsoft a'i adnoddau - storfeydd Git, cynwysyddion, peiriannau rhithwir, cymwysiadau, ac ati. Mae'r holl ddata a gesglir gan Azure Monitor wedi'i rannu'n ddau gategori - metrigau, wedi'u casglu mewn amser real ac yn disgrifio dangosyddion perfformiad allweddol cwmwl Azure, a logiau, sy'n cynnwys data wedi'u trefnu'n gofnodion sy'n nodweddu rhai agweddau ar weithgaredd adnoddau a gwasanaethau Azure. Yn ogystal, gan ddefnyddio'r API Casglwr Data, gall gwasanaeth Azure Monitor gasglu data o unrhyw ffynhonnell REST i adeiladu ei senarios monitro ei hun.

Dyma rai ffynonellau digwyddiadau diogelwch y mae Azure yn eu cynnig i chi ac y gallwch eu cyrchu trwy'r Azure Portal, CLI, PowerShell, neu REST API (a rhai yn unig trwy'r Azure Monitor / Insight API):

• Logiau Gweithgaredd - mae'r log hwn yn ateb y cwestiynau clasurol o “pwy,” “beth,” a “phryd” ynghylch unrhyw weithrediad ysgrifennu (PUT, POST, DELETE) ar adnoddau cwmwl. Nid yw digwyddiadau sy'n ymwneud â mynediad darllen (GET) wedi'u cynnwys yn y log hwn, fel nifer o rai eraill.
• Logiau Diagnostig - yn cynnwys data ar weithrediadau gydag adnodd penodol wedi'i gynnwys yn eich tanysgrifiad.
• Adroddiadau Azure AD - yn cynnwys gweithgaredd defnyddwyr a gweithgaredd system sy'n gysylltiedig â rheolaeth grŵp a defnyddwyr.
• Log Digwyddiad Windows a Linux Syslog - yn cynnwys digwyddiadau o beiriannau rhithwir a gynhelir yn y cwmwl.
• Metrigau - yn cynnwys telemetreg am berfformiad a statws iechyd eich gwasanaethau ac adnoddau cwmwl. Wedi'i fesur bob munud a'i storio. o fewn 30 diwrnod.
• Logiau Llif Grŵp Diogelwch Rhwydwaith - yn cynnwys data ar ddigwyddiadau diogelwch rhwydwaith a gasglwyd gan ddefnyddio gwasanaeth Network Watcher a monitro adnoddau ar lefel rhwydwaith.
• Logiau Storio - yn cynnwys digwyddiadau sy'n ymwneud â mynediad i gyfleusterau storio.

Ar gyfer monitro, gallwch ddefnyddio SIEMs allanol neu'r Azure Monitor adeiledig a'i estyniadau. Byddwn yn siarad am systemau rheoli digwyddiadau diogelwch gwybodaeth yn ddiweddarach, ond am y tro gadewch i ni weld beth mae Azure ei hun yn ei gynnig i ni ar gyfer dadansoddi data yng nghyd-destun diogelwch. Y brif sgrin ar gyfer popeth sy'n ymwneud â diogelwch yn Azure Monitor yw'r Dangosfwrdd Diogelwch ac Archwilio Log Analytics (mae'r fersiwn am ddim yn cefnogi swm cyfyngedig o storio digwyddiadau am wythnos yn unig). Mae'r dangosfwrdd hwn wedi'i rannu'n 5 prif faes sy'n delweddu ystadegau cryno o'r hyn sy'n digwydd yn yr amgylchedd cwmwl rydych chi'n ei ddefnyddio:

• Parthau Diogelwch - dangosyddion meintiol allweddol sy'n ymwneud â diogelwch gwybodaeth - nifer y digwyddiadau, nifer y nodau dan fygythiad, nodau heb eu cywiro, digwyddiadau diogelwch rhwydwaith, ac ati.
• Materion Nodedig - yn dangos nifer a phwysigrwydd materion diogelwch gwybodaeth gweithredol
• Canfyddiadau - yn arddangos patrymau o ymosodiadau a ddefnyddir yn eich erbyn
• Cudd-wybodaeth Bygythiad - yn arddangos gwybodaeth ddaearyddol am nodau allanol sy'n ymosod arnoch chi
• Ymholiadau diogelwch cyffredin - ymholiadau nodweddiadol a fydd yn eich helpu i fonitro eich diogelwch gwybodaeth yn well.

Mae estyniadau Azure Monitor yn cynnwys Azure Key Vault (amddiffyn allweddi cryptograffig yn y cwmwl), Asesiad Malware (dadansoddiad o amddiffyniad yn erbyn cod maleisus ar beiriannau rhithwir), Azure Application Gateway Analytics (dadansoddiad o, ymhlith pethau eraill, logiau wal dân cwmwl), ac ati. . Mae'r offer hyn, wedi'u cyfoethogi â rheolau penodol ar gyfer prosesu digwyddiadau, yn caniatáu ichi ddelweddu gwahanol agweddau ar weithgarwch gwasanaethau cwmwl, gan gynnwys diogelwch, a nodi rhai gwyriadau o'r gweithrediad. Ond, fel sy'n digwydd yn aml, mae unrhyw swyddogaeth ychwanegol yn gofyn am danysgrifiad taledig cyfatebol, a fydd yn gofyn am fuddsoddiadau ariannol cyfatebol gennych chi, y mae angen i chi eu cynllunio ymlaen llaw.

Mae gan Azure nifer o alluoedd monitro bygythiad adeiledig sydd wedi'u hintegreiddio i Azure AD, Azure Monitor, a Chanolfan Ddiogelwch Azure. Yn eu plith, er enghraifft, canfod rhyngweithio peiriannau rhithwir ag IPs maleisus hysbys (oherwydd presenoldeb integreiddio â gwasanaethau Threat Intelligence gan Microsoft), canfod malware yn seilwaith y cwmwl trwy dderbyn larymau o beiriannau rhithwir a gynhelir yn y cwmwl, cyfrinair dyfalu ymosodiadau ” ar beiriannau rhithwir, gwendidau yn ffurfweddiad y system adnabod defnyddwyr, mewngofnodi i'r system gan anhysbyswyr neu nodau heintiedig, gollyngiadau cyfrif, mewngofnodi i'r system o leoliadau anarferol, ac ati. Azure heddiw yw un o'r ychydig ddarparwyr cwmwl sy'n cynnig galluoedd Cudd-wybodaeth Bygythiad adeiledig i chi i gyfoethogi digwyddiadau diogelwch gwybodaeth a gasglwyd.

Fel y soniwyd uchod, nid yw'r swyddogaeth diogelwch ac, o ganlyniad, y digwyddiadau diogelwch a gynhyrchir ganddo ar gael yn gyfartal i bob defnyddiwr, ond mae angen tanysgrifiad penodol sy'n cynnwys y swyddogaeth sydd ei hangen arnoch, sy'n cynhyrchu'r digwyddiadau priodol ar gyfer monitro diogelwch gwybodaeth. Er enghraifft, dim ond yn y drwydded premiwm P2 ar gyfer gwasanaeth Azure AD y mae rhai o'r swyddogaethau a ddisgrifir yn y paragraff blaenorol ar gyfer monitro anghysondebau mewn cyfrifon ar gael. Hebddo, bydd yn rhaid i chi, fel yn achos AWS, ddadansoddi'r digwyddiadau diogelwch a gasglwyd “â llaw”. Ac, hefyd, yn dibynnu ar y math o drwydded Azure AD, ni fydd pob digwyddiad ar gael i'w ddadansoddi.

Ar borth Azure, gallwch reoli ymholiadau chwilio am logiau sydd o ddiddordeb i chi a sefydlu dangosfyrddau i ddelweddu dangosyddion diogelwch gwybodaeth allweddol. Yn ogystal, gallwch ddewis estyniadau Azure Monitor yno, sy'n eich galluogi i ehangu ymarferoldeb logiau Azure Monitor a chael dadansoddiad dyfnach o ddigwyddiadau o safbwynt diogelwch.

Os oes angen nid yn unig y gallu i weithio gyda logiau, ond canolfan ddiogelwch gynhwysfawr ar gyfer eich platfform cwmwl Azure, gan gynnwys rheoli polisi diogelwch gwybodaeth, yna gallwch chi siarad am yr angen i weithio gyda Chanolfan Ddiogelwch Azure, y mae'r rhan fwyaf o'i swyddogaethau defnyddiol ar gael am rywfaint o arian, er enghraifft, canfod bygythiadau, monitro y tu allan i Azure, asesu cydymffurfiaeth, ac ati. (yn y fersiwn am ddim, dim ond asesiad diogelwch ac argymhellion ar gyfer dileu problemau a nodwyd sydd gennych). Mae'n cydgrynhoi'r holl faterion diogelwch mewn un lle. Mewn gwirionedd, gallwn siarad am lefel uwch o ddiogelwch gwybodaeth nag y mae Azure Monitor yn ei ddarparu i chi, oherwydd yn yr achos hwn mae'r data a gesglir trwy gydol eich ffatri cwmwl yn cael ei gyfoethogi gan ddefnyddio llawer o ffynonellau, megis Azure, Office 365, Microsoft CRM ar-lein, Microsoft Dynamics AX , outlook .com, MSN.com, Uned Troseddau Digidol Microsoft (DCU) a Chanolfan Ymateb Diogelwch Microsoft (MSRC), y mae amryw o algorithmau dysgu peirianyddol a dadansoddi ymddygiadol wedi'u harosod arnynt, a ddylai yn y pen draw wella effeithlonrwydd canfod ac ymateb i fygythiadau .

Mae gan Azure ei SIEM ei hun hefyd - ymddangosodd ar ddechrau 2019. Dyma Azure Sentinel, sy'n dibynnu ar ddata o Azure Monitor a gall hefyd integreiddio â. atebion diogelwch allanol (er enghraifft, NGFW neu WAF), y mae'r rhestr ohonynt yn tyfu'n gyson. Yn ogystal, trwy integreiddio API Diogelwch Graff Microsoft, mae gennych y gallu i gysylltu eich porthiannau Bygythiad Cudd-wybodaeth eich hun â Sentinel, sy'n cyfoethogi'r galluoedd ar gyfer dadansoddi digwyddiadau yn eich cwmwl Azure. Gellir dadlau mai Azure Sentinel yw'r SIEM “brodorol” cyntaf a ymddangosodd gan ddarparwyr cwmwl (nid yw'r un Splunk neu ELK, y gellir ei gynnal yn y cwmwl, er enghraifft, AWS, yn cael eu datblygu o hyd gan ddarparwyr gwasanaeth cwmwl traddodiadol). Gellid galw Azure Sentinel a Security Center yn SOC ar gyfer cwmwl Azure a gellid ei gyfyngu iddynt (gyda rhai amheuon) os nad oedd gennych unrhyw seilwaith mwyach a'ch bod wedi trosglwyddo'ch holl adnoddau cyfrifiadurol i'r cwmwl a hwn fyddai cwmwl Microsoft Azure.

Ond gan nad yw galluoedd adeiledig Azure (hyd yn oed os oes gennych danysgrifiad i Sentinel) yn aml yn ddigon at ddibenion monitro diogelwch gwybodaeth ac integreiddio'r broses hon â ffynonellau digwyddiadau diogelwch eraill (cwmwl a mewnol), mae yna angen allforio'r data a gasglwyd i systemau allanol, a all gynnwys SIEM. Gwneir hyn gan ddefnyddio'r API a thrwy ddefnyddio estyniadau arbennig, sydd ar gael yn swyddogol ar hyn o bryd ar gyfer y SIEMs canlynol yn unig - Splunk (Ychwanegiad Azure Monitor ar gyfer Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ac ELK. Tan yn ddiweddar, roedd mwy o SIEMs o'r fath, ond o 1 Mehefin, 2019, rhoddodd Microsoft y gorau i gefnogi Offeryn Integreiddio Log Azure (AzLog), sydd ar wawr bodolaeth Azure ac yn absenoldeb safoni arferol o weithio gyda logiau (Azure Nid oedd Monitor hyd yn oed yn bodoli eto) ei gwneud hi'n hawdd integreiddio SIEM allanol gyda'r cwmwl Microsoft. Nawr mae'r sefyllfa wedi newid ac mae Microsoft yn argymell platfform Azure Event Hub fel y prif offeryn integreiddio ar gyfer SIEMs eraill. Mae llawer eisoes wedi gweithredu integreiddio o'r fath, ond byddwch yn ofalus - efallai na fyddant yn dal holl logiau Azure, ond dim ond rhai (edrychwch yn y dogfennau ar gyfer eich SIEM).

Wrth gloi taith fer i Azure, hoffwn roi argymhelliad cyffredinol am y gwasanaeth cwmwl hwn - cyn i chi ddweud unrhyw beth am y swyddogaethau monitro diogelwch gwybodaeth yn Azure, dylech eu ffurfweddu'n ofalus iawn a phrofi eu bod yn gweithio fel y'u hysgrifennwyd yn y ddogfennaeth a fel y dywedodd yr ymgynghorwyr wrthych Microsoft (ac efallai y bydd ganddynt farn wahanol ar ymarferoldeb swyddogaethau Azure). Os oes gennych chi'r adnoddau ariannol, gallwch chi wasgu llawer o wybodaeth ddefnyddiol allan o Azure o ran monitro diogelwch gwybodaeth. Os yw'ch adnoddau'n gyfyngedig, yna, fel yn achos AWS, bydd yn rhaid i chi ddibynnu ar eich cryfder eich hun a'r data crai y mae Azure Monitor yn ei ddarparu i chi yn unig. A chofiwch fod llawer o swyddogaethau monitro yn costio arian ac mae'n well ymgyfarwyddo â'r polisi prisio ymlaen llaw. Er enghraifft, am ddim gallwch storio 31 diwrnod o ddata hyd at uchafswm o 5 GB y cwsmer - bydd rhagori ar y gwerthoedd hyn yn gofyn ichi fforchio arian ychwanegol (tua $2+ ar gyfer storio pob GB ychwanegol gan y cwsmer a $0,1 ar gyfer storio 1 GB bob mis ychwanegol ). Efallai y bydd angen arian ychwanegol hefyd i weithio gyda thelemetreg cymwysiadau a metrigau, yn ogystal â gweithio gyda rhybuddion a hysbysiadau (mae cyfyngiad penodol ar gael am ddim, ac efallai na fydd yn ddigon ar gyfer eich anghenion).

Enghraifft: Monitro diogelwch gwybodaeth yn IaaS yn seiliedig ar Google Cloud Platform

Mae Google Cloud Platform yn edrych fel llanc o'i gymharu ag AWS ac Azure, ond mae hyn yn rhannol dda. Yn wahanol i AWS, a gynyddodd ei alluoedd, gan gynnwys rhai diogelwch, yn raddol, yn cael problemau gyda chanoli; Mae GCP, fel Azure, yn cael ei reoli'n llawer gwell yn ganolog, sy'n lleihau gwallau ac amser gweithredu ar draws y fenter. O safbwynt diogelwch, mae GCP, yn rhyfedd ddigon, rhwng AWS ac Azure. Mae ganddo hefyd gofrestriad digwyddiad unigol ar gyfer y sefydliad cyfan, ond mae'n anghyflawn. Mae rhai swyddogaethau yn dal i fod yn y modd beta, ond yn raddol dylid dileu'r diffyg hwn a bydd GCP yn dod yn llwyfan mwy aeddfed o ran monitro diogelwch gwybodaeth.

Y prif offeryn ar gyfer logio digwyddiadau yn GCP yw Stackdriver Logging (yn debyg i Azure Monitor), sy'n eich galluogi i gasglu digwyddiadau ar draws eich seilwaith cwmwl cyfan (yn ogystal ag o AWS). O safbwynt diogelwch yn GCP, mae gan bob sefydliad, prosiect neu ffolder bedwar cofnod:

• Gweithgaredd Gweinyddol - yn cynnwys yr holl ddigwyddiadau sy'n ymwneud â mynediad gweinyddol, er enghraifft, creu peiriant rhithwir, newid hawliau mynediad, ac ati. Mae'r log hwn bob amser yn cael ei ysgrifennu, waeth beth fo'ch dymuniad, ac mae'n storio ei ddata am 400 diwrnod.
• Mynediad Data - yn cynnwys yr holl ddigwyddiadau sy'n ymwneud â gweithio gyda data gan ddefnyddwyr cwmwl (creu, addasu, darllen, ac ati). Yn ddiofyn, nid yw'r log hwn wedi'i ysgrifennu, gan fod ei gyfaint yn chwyddo'n gyflym iawn. Am y rheswm hwn, dim ond 30 diwrnod yw ei oes silff. Yn ogystal, nid yw popeth wedi'i ysgrifennu yn y cylchgrawn hwn. Er enghraifft, nid yw digwyddiadau sy'n ymwneud ag adnoddau sydd ar gael i'r cyhoedd i bob defnyddiwr neu sy'n hygyrch heb fewngofnodi i GCP yn cael eu hysgrifennu ato.
• Digwyddiad System - yn cynnwys digwyddiadau system nad ydynt yn gysylltiedig â defnyddwyr, neu weithredoedd gweinyddwr sy'n newid cyfluniad adnoddau cwmwl. Mae bob amser yn cael ei ysgrifennu a'i storio am 400 diwrnod.
• Mae Access Transparency yn enghraifft unigryw o log sy'n dal holl weithredoedd gweithwyr Google (ond nid eto ar gyfer holl wasanaethau GCP) sy'n cyrchu'ch seilwaith fel rhan o'u dyletswyddau swydd. Mae'r log hwn yn cael ei storio am 400 diwrnod ac nid yw ar gael i bob cleient GCP, ond dim ond os bodlonir nifer o amodau (naill ai cefnogaeth lefel Aur neu Blatinwm, neu bresenoldeb 4 rôl o fath penodol fel rhan o gefnogaeth gorfforaethol). Mae swyddogaeth debyg hefyd ar gael, er enghraifft, yn Office 365 - Lockbox.

Enghraifft o log: Tryloywder Mynediad

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

Mae mynediad i'r logiau hyn yn bosibl mewn sawl ffordd (yn debyg iawn i'r hyn a drafodwyd yn flaenorol Azure ac AWS) - trwy'r rhyngwyneb Log Viewer, trwy'r API, trwy Google Cloud SDK, neu trwy dudalen Gweithgaredd eich prosiect yr ydych chi ar ei gyfer diddordeb mewn digwyddiadau. Yn yr un modd, gellir eu hallforio i atebion allanol ar gyfer dadansoddiad ychwanegol. Gwneir yr olaf trwy allforio logiau i BigQuery neu Cloud Pub/Is storfa.

Yn ogystal â Stackdriver Loggging, mae platfform GCP hefyd yn cynnig ymarferoldeb Monitro Stackdriver, sy'n eich galluogi i fonitro metrigau allweddol (perfformiad, MTBF, iechyd cyffredinol, ac ati) gwasanaethau a chymwysiadau cwmwl. Gall data wedi'i brosesu a'i ddelweddu ei gwneud hi'n haws dod o hyd i broblemau yn eich seilwaith cwmwl, gan gynnwys yng nghyd-destun diogelwch. Ond dylid nodi na fydd y swyddogaeth hon yn gyfoethog iawn yng nghyd-destun diogelwch gwybodaeth, oherwydd heddiw nid oes gan GCP analog o'r un AWS GuardDuty ac ni all adnabod rhai drwg ymhlith yr holl ddigwyddiadau cofrestredig (mae Google wedi datblygu Canfod Bygythiad Digwyddiad, ond mae'n dal i gael ei ddatblygu yn beta ac mae'n rhy gynnar i siarad am ei ddefnyddioldeb). Gellid defnyddio Monitro Stackdriver fel system ar gyfer canfod anomaleddau, a fyddai wedyn yn cael ei ymchwilio i ganfod achosion eu digwyddiad. Ond o ystyried y diffyg personél cymwys ym maes diogelwch gwybodaeth GCP yn y farchnad, mae'r dasg hon yn edrych yn anodd ar hyn o bryd.

Mae hefyd yn werth rhoi rhestr o rai modiwlau diogelwch gwybodaeth y gellir eu defnyddio yn eich cwmwl GCP, ac sy'n debyg i'r hyn y mae AWS yn ei gynnig:

• Mae Cloud Security Command Center yn analog o AWS Security Hub a Azure Security Centre.
• Cloud DLP - Darganfod a golygu awtomatig (e.e. masgio) data sy'n cael ei letya yn y cwmwl gan ddefnyddio mwy na 90 o bolisïau dosbarthu wedi'u diffinio ymlaen llaw.
• Mae Cloud Scanner yn sganiwr ar gyfer gwendidau hysbys (XSS, Chwistrelliad Flash, llyfrgelloedd heb eu clytio, ac ati) yn App Engine, Compute Engine a Google Kubernetes.
• Cloud IAM - Rheoli mynediad i holl adnoddau GCP.
• Hunaniaeth Cwmwl - Rheoli cyfrifon defnyddwyr, dyfeisiau a rhaglenni GCP o un consol.
• Cloud HSM - amddiffyn allweddi cryptograffig.
• Gwasanaeth Rheoli Allwedd Cwmwl - rheoli allweddi cryptograffig yn GCP.
• Rheoli Gwasanaeth VPC - Creu perimedr diogel o amgylch eich adnoddau GCP i'w hamddiffyn rhag gollyngiadau.
• Allwedd Ddiogelwch Titan - amddiffyniad rhag gwe-rwydo.

Mae llawer o'r modiwlau hyn yn cynhyrchu digwyddiadau diogelwch y gellir eu hanfon i storfa BigQuery i'w dadansoddi neu eu hallforio i systemau eraill, gan gynnwys SIEM. Fel y soniwyd uchod, mae GCP yn blatfform sy'n datblygu'n weithredol ac mae Google bellach yn datblygu nifer o fodiwlau diogelwch gwybodaeth newydd ar gyfer ei lwyfan. Yn eu plith mae Canfod Bygythiad Digwyddiad (sydd bellach ar gael mewn beta), sy'n sganio logiau Stackdriver i chwilio am olion gweithgaredd anawdurdodedig (yn debyg i GuardDuty yn AWS), neu Policy Intelligence (ar gael yn alpha), a fydd yn caniatáu ichi ddatblygu polisïau deallus ar gyfer mynediad at adnoddau GCP.

Gwneuthum drosolwg byr o'r galluoedd monitro adeiledig mewn llwyfannau cwmwl poblogaidd. Ond a oes gennych chi arbenigwyr sy'n gallu gweithio gyda logiau darparwr IaaS “amrwd” (nid yw pawb yn barod i brynu galluoedd uwch AWS neu Azure neu Google)? Yn ogystal, mae llawer yn gyfarwydd â'r dywediad “ymddiried, ond gwirio,” sy'n fwy gwir nag erioed ym maes diogelwch. Faint ydych chi'n ymddiried yng ngalluoedd adeiledig y darparwr cwmwl sy'n anfon digwyddiadau diogelwch gwybodaeth atoch? I ba raddau maen nhw'n canolbwyntio ar ddiogelwch gwybodaeth o gwbl?

Weithiau mae'n werth edrych ar atebion monitro seilwaith cwmwl troshaenu a all ategu diogelwch cwmwl adeiledig, ac weithiau atebion o'r fath yw'r unig opsiwn i gael mewnwelediad i ddiogelwch eich data a'ch cymwysiadau a gynhelir yn y cwmwl. Yn ogystal, maent yn symlach yn fwy cyfleus, gan eu bod yn ymgymryd â'r holl dasgau o ddadansoddi'r logiau angenrheidiol a gynhyrchir gan wahanol wasanaethau cwmwl gan wahanol ddarparwyr cwmwl. Enghraifft o ddatrysiad troshaen o'r fath yw Cisco Stealthwatch Cloud, sy'n canolbwyntio ar un dasg - monitro anghysondebau diogelwch gwybodaeth mewn amgylcheddau cwmwl, gan gynnwys nid yn unig Amazon AWS, Microsoft Azure a Google Cloud Platform, ond hefyd cymylau preifat.

Enghraifft: Monitro Diogelwch Gwybodaeth Gan Ddefnyddio Cwmwl Stealthwatch

Mae AWS yn darparu llwyfan cyfrifiadurol hyblyg, ond mae'r hyblygrwydd hwn yn ei gwneud hi'n haws i gwmnïau wneud camgymeriadau sy'n arwain at faterion diogelwch. Ac mae'r model diogelwch gwybodaeth a rennir yn cyfrannu at hyn yn unig. Rhedeg meddalwedd yn y cwmwl gyda gwendidau anhysbys (gellir brwydro yn erbyn rhai hysbys, er enghraifft, gan Arolygydd AWS neu Sganiwr Cwmwl GCP), cyfrineiriau gwan, cyfluniadau anghywir, mewnwyr, ac ati. Ac mae hyn i gyd yn cael ei adlewyrchu yn ymddygiad adnoddau cwmwl, y gellir ei fonitro gan Cisco Stealthwatch Cloud, sef system monitro diogelwch gwybodaeth a chanfod ymosodiadau. cymylau cyhoeddus a phreifat.

Un o nodweddion allweddol Cisco Stealthwatch Cloud yw'r gallu i fodelu endidau. Ag ef, gallwch greu model meddalwedd (hynny yw, efelychiad amser real bron) o bob un o'ch adnoddau cwmwl (does dim ots a yw'n AWS, Azure, GCP, neu rywbeth arall). Gall y rhain gynnwys gweinyddwyr a defnyddwyr, yn ogystal â mathau o adnoddau sy'n benodol i'ch amgylchedd cwmwl, megis grwpiau diogelwch a grwpiau ar raddfa auto. Mae'r modelau hyn yn defnyddio ffrydiau data strwythuredig a ddarperir gan wasanaethau cwmwl fel mewnbwn. Er enghraifft, ar gyfer AWS byddai'r rhain yn Logiau Llif VPC, AWS CloudTrail, AWS CloudWatch, AWS Config, Arolygydd AWS, AWS Lambda, ac AWS IAM. Mae modelu endid yn awtomatig yn darganfod rôl ac ymddygiad unrhyw un o'ch adnoddau (gallwch siarad am broffilio holl weithgaredd cwmwl). Mae'r rolau hyn yn cynnwys dyfais symudol Android neu Apple, gweinydd Citrix PVS, gweinydd RDP, porth post, cleient VoIP, gweinydd terfynell, rheolwr parth, ac ati. Yna mae'n monitro eu hymddygiad yn barhaus i benderfynu pryd mae ymddygiad peryglus neu sy'n bygwth diogelwch yn digwydd. Gallwch adnabod dyfalu cyfrinair, ymosodiadau DDoS, gollyngiadau data, mynediad anghyfreithlon o bell, gweithgaredd cod maleisus, sganio bregusrwydd a bygythiadau eraill. Er enghraifft, dyma sut olwg sydd ar ganfod ymgais mynediad o bell o wlad annodweddiadol ar gyfer eich sefydliad (De Korea) i glwstwr Kubernetes trwy SSH:

A dyma sut olwg sydd ar y gollyngiad gwybodaeth honedig o gronfa ddata Postgress i wlad nad ydym wedi dod ar draws rhyngweithio â hi o'r blaen:

Yn olaf, dyma sut olwg sydd ar ormod o ymdrechion SSH aflwyddiannus o Tsieina ac Indonesia o ddyfais anghysbell allanol:

Neu, tybiwch nad yw enghraifft y gweinydd yn y VPC, yn ôl polisi, byth yn gyrchfan mewngofnodi o bell. Gadewch i ni dybio ymhellach bod y cyfrifiadur hwn wedi profi mewngofnodi o bell oherwydd newid gwallus yn y polisi rheolau wal dân. Bydd y nodwedd Modelu Endid yn canfod ac yn adrodd ar y gweithgaredd hwn (“Mynediad Anghysbell Anarferol”) bron mewn amser real ac yn pwyntio at alwad benodol AWS CloudTrail, Azure Monitor, neu GCP Stackdriver Loggging API (gan gynnwys enw defnyddiwr, dyddiad ac amser, ymhlith manylion eraill ) a ysgogodd y newid i'r rheol ITU. Ac yna gellir anfon y wybodaeth hon i SIEM i'w dadansoddi.

Mae galluoedd tebyg yn cael eu gweithredu ar gyfer unrhyw amgylchedd cwmwl a gefnogir gan Cisco Stealthwatch Cloud:

Mae modelu endid yn fath unigryw o awtomeiddio diogelwch a all ddatgelu problem anhysbys o'r blaen gyda'ch pobl, prosesau neu dechnoleg. Er enghraifft, mae'n caniatáu ichi ganfod, ymhlith pethau eraill, problemau diogelwch fel:

• Oes rhywun wedi darganfod drws cefn yn y meddalwedd rydyn ni'n ei ddefnyddio?
• A oes unrhyw feddalwedd neu ddyfais trydydd parti yn ein cwmwl?
• A yw'r defnyddiwr awdurdodedig yn cam-drin breintiau?
• A oedd gwall ffurfweddu a oedd yn caniatáu mynediad o bell neu ddefnydd anfwriadol arall o adnoddau?
• A oes gollyngiad data o'n gweinyddion?
• A oedd rhywun yn ceisio cysylltu â ni o leoliad daearyddol annodweddiadol?
• A yw ein cwmwl wedi'i heintio â chod maleisus?

Gellir anfon digwyddiad diogelwch gwybodaeth a ganfuwyd ar ffurf tocyn cyfatebol i Slack, Cisco Spark, system rheoli digwyddiadau PagerDuty, a hefyd ei anfon at amrywiol SIEMs, gan gynnwys Splunk neu ELK. I grynhoi, gallwn ddweud, os yw'ch cwmni'n defnyddio strategaeth aml-gwmwl ac nad yw'n gyfyngedig i unrhyw un darparwr cwmwl, y galluoedd monitro diogelwch gwybodaeth a ddisgrifir uchod, yna mae defnyddio Cisco Stealthwatch Cloud yn opsiwn da i gael set unedig o fonitro galluoedd ar gyfer y chwaraewyr cwmwl blaenllaw - Amazon , Microsoft a Google . Y peth mwyaf diddorol yw, os cymharwch y prisiau ar gyfer Stealthwatch Cloud â thrwyddedau uwch ar gyfer monitro diogelwch gwybodaeth yn AWS, Azure neu GCP, efallai y bydd datrysiad Cisco hyd yn oed yn rhatach na galluoedd adeiledig Amazon, Microsoft ac atebion Google. Mae'n baradocsaidd, ond mae'n wir. A pho fwyaf o gymylau a'u galluoedd a ddefnyddiwch, y mwyaf amlwg fydd mantais datrysiad cyfunol.

Yn ogystal, gall Stealthwatch Cloud fonitro cymylau preifat a ddefnyddir yn eich sefydliad, er enghraifft, yn seiliedig ar gynwysyddion Kubernetes neu trwy fonitro llif Netflow neu draffig rhwydwaith a dderbynnir trwy adlewyrchu mewn offer rhwydwaith (hyd yn oed a gynhyrchir yn ddomestig), data AD neu weinyddion DNS ac ati. Bydd yr holl ddata hwn yn cael ei gyfoethogi â gwybodaeth Threat Intelligence a gesglir gan Cisco Talos, grŵp anllywodraethol mwyaf y byd o ymchwilwyr bygythiadau seiberddiogelwch.

Mae hyn yn caniatáu ichi weithredu system fonitro unedig ar gyfer cymylau cyhoeddus a hybrid y gall eich cwmni eu defnyddio. Yna gellir dadansoddi'r wybodaeth a gasglwyd gan ddefnyddio galluoedd adeiledig Stealthwatch Cloud neu ei hanfon at eich SIEM (mae Splunk, ELK, SumoLogic a sawl un arall yn cael eu cefnogi yn ddiofyn).

Gyda hyn, byddwn yn cwblhau rhan gyntaf yr erthygl, lle adolygais yr offer mewnol ac allanol ar gyfer monitro diogelwch gwybodaeth llwyfannau IaaS/PaaS, sy'n ein galluogi i ganfod ac ymateb yn gyflym i ddigwyddiadau sy'n digwydd yn yr amgylcheddau cwmwl sy'n mae ein menter wedi dewis. Yn yr ail ran, byddwn yn parhau â'r pwnc ac yn edrych ar opsiynau ar gyfer monitro llwyfannau SaaS gan ddefnyddio'r enghraifft o Salesforce a Dropbox, a byddwn hefyd yn ceisio crynhoi a rhoi popeth at ei gilydd trwy greu system monitro diogelwch gwybodaeth unedig ar gyfer gwahanol ddarparwyr cwmwl.

Ffynhonnell: hab.com