ProHoster > Blogs > Administrācija > Mākoņu droŔības uzraudzÄ«ba

Mākoņu droŔības uzraudzÄ«ba

Datu un lietojumprogrammu pārvietoÅ”ana uz mākoņiem rada jaunas problēmas korporatÄ«vajiem SOC, kuri ne vienmēr ir gatavi uzraudzÄ«t citu infrastruktÅ«ru. Saskaņā ar Netoskope datiem vidējais uzņēmums (domājams, ASV) izmanto 1246 dažādus mākoņu pakalpojumus, kas ir par 22% vairāk nekā pērn. 1246 mākoņu pakalpojumi!!! no kuriem 175 attiecas uz HR pakalpojumiem, 170 ir saistÄ«ti ar mārketingu, 110 ā€” komunikācijām un 76 finansēm un CRM. Cisco izmanto "tikai" 700 ārējo mākoņu pakalpojumus. Tāpēc mani nedaudz mulsina Å”ie skaitļi. Bet jebkurā gadÄ«jumā problēma nav tajos, bet gan tajā, ka mākoņi aktÄ«vi tiek izmantoti arvien lielākā skaitā uzņēmumu, kuri vēlētos iegÅ«t tādas paÅ”as uzraudzÄ«bas iespējas mākoņu infrastruktÅ«rā kā savā tÄ«klā. Un Ŕī tendence pieaug ā€” saskaņā ar Amerikas Kontroles palātas datiem 2023. gadā ASV plānots slēgt 1200 Datu centrus (6250 jau ir slēgti). Bet pāreja uz mākoņu risinājumiem nav vienkārÅ”i "aiziet, pārvietosim mÅ«su serverus pie ārējā pakalpojumu sniedzēja". Jaunā IT arhitektÅ«ra, jauns programmatÅ«ras komplekts, jauni procesi, jauni ierobežojumiā€¦ Viss tas ievieÅ” bÅ«tiskas izmaiņas ne tikai IT, bet arÄ« informācijas droŔībā. Un, ja pakalpojumu sniedzēji ir iemācÄ«juÅ”ies risināt paÅ”as mākoņa droŔības nodroÅ”ināŔanas jautājumus (paldies, ka ir daudz ieteikumu), tad ar mākoņa droŔības uzraudzÄ«bu, Ä«paÅ”i SaaS platformās, ir bÅ«tiskas grÅ«tÄ«bas, par kurām arÄ« runāsim.

Mākoņu droŔības uzraudzÄ«ba

Pieņemsim, ka jÅ«su uzņēmums ir pārvietojis daļu no savas infrastruktÅ«ras mākonÄ«... Apstājieties. Ne tā. Ja infrastruktÅ«ra ir pārvietota, bet jÅ«s tikai tagad domājat, kā to uzraudzÄ«t, tad jÅ«s jau esat zaudējuÅ”i. Ja tas nav Amazon, Google vai Microsoft (un pat tur ir dažas atrunas), tad, visticamāk, jums nebÅ«s daudz iespēju uzraudzÄ«t savus datus un lietojumprogrammas. Labi, ja jums ļaus strādāt ar žurnāliem. Dažreiz droŔības notikumu dati bÅ«s pieejami, bet piekļuves tiem nebÅ«s. Piemēram, Office 365. Ja jums ir lētākā E1 licence, tad droŔības notikumi jums vispār nav pieejami. Ar E3 licenci jÅ«su dati tiek glabāti tikai 90 dienas, un tikai ar E5 licenci žurnālu ilgums ir pieejams gada laikā (tomēr arÄ« Å”eit ir savas nianses, kas saistÄ«tas ar nepiecieÅ”amÄ«bu atseviŔķi pieprasÄ«t dažas funkcijas, kas saistÄ«tas ar žurnāliem no Microsoft atbalsta). Starp citu, E3 licence ir daudz vājāka uzraudzÄ«bas funkciju ziņā nekā korporatÄ«vais Exchange. Lai sasniegtu to paÅ”u lÄ«meni, jums ir nepiecieÅ”ama E5 licence vai papildu licencija Advanced Compliance, kas var prasÄ«t papildu naudu, kas nav iekļauta jÅ«su finanÅ”u modelÄ« pārejai uz mākonÄ« bāzētu infrastruktÅ«ru. Un tas ir tikai viens piemērs nepietiekamai ievērÅ”anai jautājumiem, kas saistÄ«ti ar mākonÄ« IB uzraudzÄ«bu. Å ajā rakstā, nesniedzot pilnÄ«gu izklāstu, es vēlos pievērst uzmanÄ«bu dažām niansēm, kuras ir vērts ņemt vērā, izvēloties mākonu pakalpojumu sniedzēju droŔības aspektu ietvaros. Raksta beigās tiks sniegts pārbaudes saraksts, kuru ir vērts veikt pirms uzskata, ka mākonÄ« IB uzraudzÄ«bas jautājums ir atrisināts.

Var izcelt vairākas tipiskas problēmas, kas noved pie incidentiem mākonī, uz kurām IB dienesti nespēj ātri reaģēt vai vispār tās neredz:

  • DroŔības žurnāli neeksistē. Tā ir diezgan izplatÄ«ta situācija, Ä«paÅ”i jaunajiem spēlētājiem mākonÄ« risinājumu tirgÅ«. Bet nevajag uzreiz atteikties no viņiem. Mazāki spēlētāji, Ä«paÅ”i vietējie, ir jÅ«tÄ«gāki pret klientu prasÄ«bām un var ātri Ä«stenot dažas pieprasÄ«tās funkcijas, mainot apstiprināto plānu saviem produktiem. Jā, tas nebÅ«s Amazon GuardDuty vai Bitrix ā€œProaktÄ«vās aizsardzÄ«basā€ modulis, bet vismaz kaut kas.
  • IB nezina, kur tiek glabāti žurnāli vai piekļuve tiem nav iespējama. Å ajā gadÄ«jumā nepiecieÅ”ams uzsākt sarunas ar mākoņu pakalpojumu sniedzēju ā€” iespējams, viņŔ sniegs Ŕādu informāciju, ja uzskatÄ«s klientu par nozÄ«mÄ«gu. Bet kopumā tas nav labi, ja piekļuve žurnāliem tiek sniegta "pēc Ä«paÅ”a lēmuma".
  • Ir gadÄ«jumi, kad žurnāli mākoņu pakalpojumu sniedzējam ir, taču tie nodroÅ”ina ierobežotu uzraudzÄ«bu un notikumu reÄ£istrÄ“Å”anu, kas nav pietiekami visiem incidentiem. Piemēram, jums var atdot tikai žurnālus par izmaiņām vietnē vai lietotāju autentifikācijas mēģinājumiem, bet citi notikumi, piemēram, par tÄ«kla trafiku, netiek nodoti, kas slēpj no jums ievērojamu notikumu daļu, kas raksturo uzbrukuma mēģinājumus jÅ«su mākoņu infrastruktÅ«rā.
  • Žurnāli ir, bet piekļuve tiem ir grÅ«ti automatizējama, kas liek tos uzraudzÄ«t nevis nepārtraukti, bet pēc grafika. Un, ja žurnālus pat nevar automātiski eksportēt, tad žurnālu izvadÄ«Å”ana, piemēram, Excel formātā (kā to dara daži vietējie mākoņu risinājumu piegādātāji), var pavest vēlmi no korporatÄ«vās IB dienesta puses nenodarboties ar tiem.
  • Nav žurnālu uzraudzÄ«bas. Tas, iespējams, ir visneskaidrs mākoņu vides IB incidentu raÅ”anās iemesls. Vai žurnāli ir, un piekļuve tiem ir automatizējama, bet neviens to nedara. Kāpēc?

Kopējās droŔības koncepcija mākoņos

Pāreja uz mākoņiem vienmēr ir lÄ«dzsvara meklējumi starp vēlmi saglabāt kontroli pār infrastruktÅ«ru un tās nodoÅ”anu profesionālāku mākoņu pakalpojumu sniedzēju rokās, kas specializējas tās uzturÄ“Å”anā. ArÄ« mākoņu vidi droŔības jomā Å”o lÄ«dzsvaru ir nepiecieÅ”ams meklēt. Turklāt, atkarÄ«bā no izmantotā mākoņu pakalpojumu sniegÅ”anas modeļa (IaaS, PaaS, SaaS), Å”is lÄ«dzsvars nepārtraukti mainÄ«sies. Jebkurā gadÄ«jumā jāatceras, ka visi mākoņu pakalpojumu sniedzēji Å”odien seko tā sauktajai kopÄ«gās atbildÄ«bas un kopÄ«gās kiberdroŔības modelim. Par kaut ko atbild mākoņi, par kaut ko atbild klients, kurÅ” ir novietojis savus datus, lietotnes, virtuālās maŔīnas un citus resursus mākoņos. NeapdomÄ«gi bÅ«tu cerēt, ka pārejot uz mākoņu, mēs visu atbildÄ«bu nokļūsim uz pakalpojumu sniedzēja pleciem. Taču tāpat nav prātÄ«gi pilnÄ«bā veidot visu droŔību patstāvÄ«gi pārejot uz mākoņu. NepiecieÅ”ams lÄ«dzsvars, kas bÅ«s atkarÄ«gs no daudziem faktoriem: ā€” riska pārvaldÄ«bas stratēģijas, apdraudējumu modeļiem, mākoņu pakalpojumu sniedzēja aizsardzÄ«bas mehānismiem, likumdoÅ”anas un citiem.

Mākoņu droŔības uzraudzÄ«ba

Piemēram, datu klasifikācija, kas tiek izvietota mākonÄ«, vienmēr ir pasÅ«tÄ«tāja atbildÄ«ba. Mākonis pakalpojumu sniedzējs vai ārējs pakalpojumu sniedzējs var tikai palÄ«dzēt ar rÄ«kiem, kas palÄ«dzēs marķēt datus mākonÄ«, identificēt pārkāpumus, dzēst likumiem neatbilstoÅ”us datus vai maskēt tos ar kādu no metodēm. Savukārt fiziskā droŔība vienmēr ir mākonÄ« pakalpojumu sniedzēja atbildÄ«ba, kuru viņŔ nevar dalÄ«t ar klientiem. Bet viss, kas ir starp datiem un fizisko infrastruktÅ«ru, ir Ŕīs raksta apsprieÅ”anas objekts. Piemēram, mākoņa pieejamÄ«ba ir pakalpojumu sniedzēja atbildÄ«ba, bet noteikumu konfigurācija vai Å”ifrÄ“Å”anas ieslēgÅ”ana jau ir klienta atbildÄ«ba. Å ajā rakstā mēs mēģināsim noskaidrot, kādas informācijas droŔības monitorÄ“Å”anas mehānismus Å”odien piedāvā dažādi populāri mākonÄ« pakalpojumu sniedzēji Krievijā, kādas ir to pielietoÅ”anas Ä«patnÄ«bas un kad vajadzētu paskatÄ«ties uz ārējiem risinājumiem (piemēram, Cisco E-mail Security), kas paplaÅ”ina jÅ«su mākoņa iespējas kiberdroŔībā. Dažos gadÄ«jumos, Ä«paÅ”i, sekvojot multilokalizācijas stratēģijai, jums nebÅ«s citas izvēles kā izmantot ārējos informācijas droŔības monitorÄ“Å”anas risinājumus vairākās mākoņa vidēs (piemēram, Cisco CloudLock vai Cisco Stealthwatch Cloud). Nu, dažos gadÄ«jumos jÅ«s sapratÄ«siet, ka izvēlētais (vai uzspiestais) mākoņu pakalpojumu sniedzējs vispār nepiedāvā nekādas iespējas informācijas droŔības monitorÄ“Å”anai. Tas ir nepatÄ«kami, bet tomēr bÅ«tiski, jo tas ļauj adekvāti novērtēt riskus, saistÄ«tos ar darbu ar Å”o mākoņu.

Mākoņa droŔības monitorÄ“Å”anas mūža cikls

Lai uzraudzÄ«tu jums izmantoto mākoņu droŔību, jums ir tikai trÄ«s iespējas:

  • paļauties uz rÄ«ku komplektu, ko sniedz jÅ«su mākoņa pakalpojumu sniedzējs,
  • izmantot treÅ”o puÅ”u risinājumus, kas uzraudzÄ«s jÅ«su izmantotās IaaS, PaaS vai SaaS platformas,
  • uzbÅ«vēt savu paÅ”u mākonÄ« videi monitorÄ“Å”anas infrastruktÅ«ru (tikai IaaS/PaaS platformām).

ApskatÄ«sim, kādas Ä«patnÄ«bas ir katram no Å”iem variantiem. Taču vispirms mums nepiecieÅ”ams saprast kopējo shēmu, kas tiks izmantota mākoņu platformu uzraudzÄ«bā. Es izceltu 6 galvenos komponentus IT droŔības uzraudzÄ«bas procesa mākoņos:

  • InfrastruktÅ«ras sagatavoÅ”ana. NepiecieÅ”amo lietojumprogrammu un infrastruktÅ«ras noteikÅ”ana notikumu vākÅ”anai, kas ir svarÄ«gi IT droŔībai, glabāŔanā.
  • VākÅ”ana. Å ajā posmā droŔības notikumi tiek apkopoti no dažādiem avotiem to tālākai nodoÅ”anai apstrādei, glabāŔanai un analÄ«zei.
  • Apstrāde. Å ajā posmā dati tiek pārveidoti un papildināti, lai atvieglotu to turpmāku analÄ«zi.
  • GlabāŔana. Å is komponents atbild par Ä«stermiņa un ilgtermiņa apstrādāto un ā€œneapstrādātoā€ datu glabāŔanu.
  • AnalÄ«ze. Å ajā posmā jums ir iespēja noteikt incidentus un reaģēt uz tiem automātiskā vai manuālā režīmā.
  • Pārskati. Å is posms palÄ«dz veidot nopietnus rādÄ«tājus ieinteresētajām pusēm (vadÄ«bai, auditoriem, mākoņu pakalpojumu sniedzējiem, klientiem utt.), kas palÄ«dz pieņemt kādu vai citu lēmumu, piemēram, pakalpojumu sniedzēja maiņu vai IT droŔības pastiprināŔanu.

Izpratne par Å”iem komponentiem ļaus jums vēlāk ātri izprast, ko jÅ«s varat saņemt no sava pakalpojumu sniedzēja, un ko jums nāksies darÄ«t paÅ”iem vai piesaistot ārējos konsultantus.

Iebūvētās mākoņu pakalpojumu iespējas

IepriekÅ” es jau minēju, ka ļoti daudz mākoņu pakalpojumu Å”odien nesniedz nekādas iespējas informācijas droŔības uzraudzÄ«bai. VispārÄ«gi, Å”ai tēmai netiek pievērsta liela uzmanÄ«ba. Piemēram, viens no populārākajiem Krievijas pakalpojumiem, kas nodroÅ”ina ziņojumu nosÅ«tÄ«Å”anu valsts iestādēm tieÅ”saistē (speciāli nenorādÄ«Å”u tā nosaukumu). Visa Ŕī pakalpojuma droŔības sadaļa ir saistÄ«ta ar sertificētu kriptogrāfisko aizsardzÄ«bu. Savukārt cita mājējo mākoņu pakalpojuma elektronisko dokumentu apmaiņas droŔības sadaļa ir ievērojami plaŔāka. Tajā ir runa par atslēgu sertifikātiem, sertificētu kriptogrāfiju, web ievainojamÄ«bu novērÅ”anu, aizsardzÄ«bu pret DDoS uzbrukumiem, MSE pielietojumu, datu dublÄ“Å”anu un pat regulāru informācijas droŔības auditu. Bet par uzraudzÄ«bu nav ne vārda, kā arÄ« par piekļuves iespējām informācijas droŔības notikumiem, kas varētu interesēt Ŕī pakalpojuma klientus.

VispārÄ«gi, pēc tā, kā mākoņu pakalpojumu sniedzējs savā vietnē un dokumentācijā apraksta informācijas droŔības jautājumus, var saprast, cik nopietni viņŔ attiecas pret Å”o jautājumu. Piemēram, ja palasām rokasgrāmatas produktiem "Mans kanceles", tur vispār nav ne vārda par droŔību, bet dokumentācijā par atseviŔķo produktu "Mans kanceles. KS3", kas paredzēts aizsardzÄ«bai pret neatļautu piekļuvi, ir parasts punktu uzskaitÄ«jums 17. FSTEK rÄ«kojumā, kuru izpilda "Mans kanceles. KS3", bet netiek aprakstÄ«ts, kā to izpilda un, kas ir vissvarÄ«gākais, kā integrēt Å”os mehānismus ar korporatÄ«vo informācijas droŔību. Iespējams, Ŕāda dokumentācija arÄ« ir, bet publiskajā pieejā, mājaslapā "Mans kanceles" es to neatradu. Lai gan varbÅ«t man vienkārÅ”i nav piekļuves Å”ai slepenajai informācijai?

Mākoņu droŔības uzraudzÄ«ba

Situācija ar Bitrix ir ievērojami labāka. Dokumentācijā ir aprakstÄ«ti notikumu žurnālu formāti un, kas interesanti, iebrukumu žurnāls, kas satur notikumus, kas saistÄ«ti ar potenciālajiem draudiem mākoņu platformai. No turienes jÅ«s varat iegÅ«t IP, lietotāja vai viesu vārdu, notikuma avotu, laiku, lietotāja aÄ£entu, notikuma veidu utt. PatiesÄ«bā darbu ar Å”iem notikumiem varat veikt vai nu no mākoņa vadÄ«bas paneļa, vai arÄ« eksportējot datus MS Excel formātā. Automātizēt darbu ar Bitrix žurnāliem Å”obrÄ«d ir grÅ«ti, un jums bÅ«s jāveic daļa darba manuāli (eksportējot ziņojumu un augÅ”upielādējot to savā SIEM). Bet, ja atceramies, ka vēl nesen Ŕāda iespēja nebija, tas ir liels progress. JāatzÄ«mē, ka arÄ« daudzi ārzemju mākoņu pakalpojumu sniedzēji piedāvā lÄ«dzÄ«gas funkcijas "sākumā" ā€” vai nu aplÅ«kojiet žurnālus ar acÄ«m caur vadÄ«bas paneli, vai eksportējiet datus pie sevis (patiesÄ«bā, lielākā daļa eksportē datus .csv formātā, nevis Excel).

Mākoņu droŔības uzraudzÄ«ba

Ja neņemot vērā variantu bez žurnāliem, mākoņu pakalpojumu sniedzēji parasti piedāvā trÄ«s iespējas droŔības notikumu uzraudzÄ«bai ā€” paneļi, datu eksportÄ“Å”ana un piekļuve caur API. Pirmais Ŕķiet risina daudzas problēmas jÅ«su vietā, taču tas tā nav ā€” ja ir vairāki žurnāli, nākas pārslēgties starp to attēloÅ”anas ekrāniem, zaudējot kopainu. Turklāt mākoņu pakalpojumu sniedzējs, visticamāk, neizsniegs jums iespēju veikt droŔības notikumu analÄ«zi un to korelāciju (parasti jÅ«s saskaraties ar neapstrādātiem datiem, kuros jums paÅ”iem jāorientējas). Ir izņēmumi, un par tiem mēs runāsim tālāk. Visbeidzot, ir vērts interesēties, kādus notikumus fiksē jÅ«su mākoņu pakalpojumu sniedzējs, kādā formātā, un cik tie atbilst jÅ«su informācijas droŔības uzraudzÄ«bas procesam? Piemēram, lietotāju un viesu identifikācija un autentifikācija. Tas pats Bitrix ļauj jums fiksēt notikuma datumu un laiku, lietotāja vai viesu vārdu (ja ir ā€œWeb-analÄ«tikaā€ modulis), objektu, kuram tika veikta piekļuve, un citus tipiskus tÄ«mekļa vietnes elementus. Bet korporatÄ«vajām informācijas droŔības dienestiem var bÅ«t nepiecieÅ”ama informācija par to, vai lietotājs mākoņos piekļuva no uzticama ierÄ«ces (piemēram, korporatÄ«vajā tÄ«klā Å”o uzdevumu veic Cisco ISE). Un tik vienkārÅ”s uzdevums kā geo-IP funkcija, kas palÄ«dzēs noteikt, vai mākoņu pakalpojuma lietotāja konts nav zagts? Pat ja mākoņu pakalpojumu sniedzējs jums to piedāvās, tā bÅ«s nepietiekama. Tas pats Cisco CloudLock ne tikai analizē Ä£eolokāciju, bet arÄ« izmanto maŔīnmācÄ«Å”anos un analizē katra lietotāja vēsturiskos datus, kā arÄ« uzrauga dažādas anomālijas identifikācijas un autentifikācijas mēģinājumos. LÄ«dzÄ«gs funkcionalitāte ir tikai MS Azure (attiecÄ«gās abonentmaksas gadÄ«jumā).

Mākoņu droŔības uzraudzÄ«ba

Ir vēl viena grÅ«tÄ«ba ā€” tā kā daudziem mākoņu pakalpojumu sniedzējiem IT droŔības uzraudzÄ«ba ir jauna tēma, kurā viņi tikai sāk strādāt, viņi pastāvÄ«gi kaut ko maina savos risinājumos. Å odien viņiem ir viena API versija, rÄ«t otra, pārdien treŔā. ArÄ« tam jābÅ«t gataviem. Tas pats attiecas uz funkcionalitāti, kas var mainÄ«ties, un to jāpatur prātā savā IT droŔības uzraudzÄ«bas sistēmā. Piemēram, Amazon sākumā bija atseviŔķi mākoņu notikumu uzraudzÄ«bas pakalpojumi ā€” AWS CloudTrail un AWS CloudWatch. Pēc tam parādÄ«jās atseviŔķs IT droŔības notikumu uzraudzÄ«bas pakalpojums ā€” AWS GuardDuty. Pēc kāda laika Amazon palaida jaunu pārvaldÄ«bas sistēmu Amazon Security Hub, kas ietver datu analÄ«zi, ko iegÅ«st no GuardDuty, Amazon Inspector, Amazon Macie un citiem. Vēl viens piemērs ā€” Azure žurnālu integrācijas rÄ«ks ar SIEM ā€” AzLog. To aktÄ«vi izmantoja daudzi SIEM piegādātāji, kamēr 2018. gadā Microsoft paziņoja par tā attÄ«stÄ«bas un atbalsta pārtraukÅ”anu, kas radÄ«ja problēmas daudziem klientiem, kas izmantoja Å”o rÄ«ku (kā tas tika atrisināts, mēs runāsim tālāk).

Tāpēc uzmanÄ«gi sekojiet visām uzraudzÄ«bas funkcijām, ko piedāvā jÅ«su mākoņu pakalpojumu sniedzējs. Vai uzticieties ārējiem risinājumu piegādātājiem, kas darbosies kā starpnieki starp jÅ«su SOC un mākoņu, ko vēlaties uzraudzÄ«t. Jā, tas izmaksās dārgāk (lai gan ne vienmēr), bet tādējādi jÅ«s pārlaidÄ«sit visu atbildÄ«bu uz citu pleciem. Vai ne visu? Atcerēsimies par koplēto droŔību un sapratÄ«sim, ka neko nevaram pilnÄ«bā pārsvÄ«trojiet ā€” nāksies patstāvÄ«gi izprast, kā dažādi mākoņu pakalpojumu sniedzēji nodroÅ”ina IT droŔības uzraudzÄ«bu jÅ«su datiem, lietojumprogrammām, virtuālām maŔīnām un citiem resursiem, kas izvietoti mākoņos. Un sāksim ar to, ko piedāvā Amazon Å”ajā jomā.

Piemērs: IT droŔības uzraudzÄ«ba IaaS, pamatojoties uz AWS

Jā, es saprotu, ka Amazon nav vislabākais piemērs, ņemot vērā, ka tas ir amerikāņu serviss, un to var bloķēt cīņas pret ekstremismu un aizliegta satura izplatÄ«Å”anu Krievijā ietvaros. Tomēr Å”ajā publikācijā es gribu parādÄ«t, cik dažādās mākonÄ« balstÄ«tās platformās atŔķiras iespējas droŔības monitorÄ“Å”anai un uz ko jāpievērÅ” uzmanÄ«ba, pārsniedzot savus galvenos procesus mākonÄ« no droŔības viedokļa. Un, ja kādi Krievijas mākoņu risinājumu izstrādātāji gÅ«s kādu noderÄ«gu informāciju, tas bÅ«s lieliski.

Mākoņu droŔības uzraudzÄ«ba

Vispirms jāteic, ka Amazon nav neiespējama cietokÅ”na. Tās klientiem regulāri notiek dažādi incidenti. Piemēram, Deep Root Analytics zaga 198 miljonu vēlētāju vārdus, adreses, dzimÅ”anas datumus un telefona numurus. Izraēlas uzņēmumam Nice Systems zagti 14 miljoni Verizon abonentu ierakstu. Tomēr iebÅ«vētās AWS iespējas ļauj jums atklāt plaÅ”u incidentu klāstu. Piemēram:

  • uzbrukums infrastruktÅ«rai (DDoS)
  • mezgla kompromitācija (komandu injekcija)
  • kontu kompromitācija un neautorizēta piekļuve
  • nepareiza konfigurācija un neaizsargātÄ«bas
  • neaizsargāti interfeisi un API.

Å Ä« neatbilstÄ«ba saistÄ«ta ar to, ka par klienta datu droŔību, kā mēs iepriekÅ” noskaidrojām, atbild pats pasÅ«tÄ«tājs. Un, ja viņŔ nav parÅ«pējies par aizsardzÄ«bas mehānismu ieslēgÅ”anu un neiekļāvis monitorÄ“Å”anas rÄ«kus, tad par incidentu viņŔ uzzinās tikai no masu medijiem vai no saviem klientiem.

Incidenta noteikÅ”anai var izmantot plaÅ”u dažādu uzraudzÄ«bas pakalpojumu klāstu, ko izstrādājusi Amazon (lai gan tie bieži tiek papildināti ar ārējiem rÄ«kiem, piemēram, osquery). AWS tiek izsekti visi lietotāju darbÄ«bas, neatkarÄ«gi no tā, kā tās tiek veiktas ā€” caur vadÄ«bas konsoli, komandrindu, SDK vai citiem AWS pakalpojumiem. Visi ieraksti par katras AWS konta darbÄ«bām (ieskaitot lietotājvārdus, darbÄ«bas, pakalpojumus, aktivitātes parametrus un rezultātus) un API izmantoÅ”ana ir pieejama caur AWS CloudTrail pakalpojumu. JÅ«s varat apskatÄ«t Å”os notikumus (piemēram, ieeju AWS IAM konsolē) no CloudTrail konsoles, analizēt tos, izmantojot Amazon Athena, vai

Mākoņu droŔības uzraudzÄ«ba

Divi citi AWS pakalpojumi nodroÅ”ina vēl virkni svarÄ«gu uzraudzÄ«bas iespēju. Pirmkārt, Amazon CloudWatch - tas ir resursu un lietojumprogrammu uzraudzÄ«bas pakalpojums AWS, kas ļauj, starp citu, noteikt dažādas anomālijas jÅ«su mākoņa vidē. Visi iebÅ«vētie AWS pakalpojumi, piemēram, Amazon Elastic Compute Cloud (serveri), Amazon Relational Database Service (datu bāzes), Amazon Elastic MapReduce (datu analÄ«ze) un vēl 30 citi Amazon pakalpojumi, izmanto Amazon CloudWatch savu žurnālu glabāŔanai. Izstrādātāji var izmantot Amazon CloudWatch atvērtā API, lai pievienotu žurnālu uzraudzÄ«bas funkcionalitāti pielāgotām lietojumprogrammām un pakalpojumiem, ļaujot paplaÅ”ināt analizējamo notikumu loku informācijas droŔības kontekstā.

Mākoņu droŔības uzraudzÄ«ba

Otrkārt, VPC Flow Logs pakalpojums ļauj analizēt tÄ«kla trafiku, ko sÅ«ta vai saņem jÅ«su AWS serveri (gan no ārpuses, gan iekÅ”pusē), kā arÄ« starp mikropakalpojumiem. Kad kāds no jÅ«su AWS VPC resursiem mijiedarbojas ar tÄ«klu, VPC Flow Logs pakalpojums reÄ£istrē informāciju par tÄ«kla trafiku, tostarp avota un galamērÄ·a tÄ«kla saskarnes, IP adreses, portus, protokolu, nosÅ«tÄ«to Š±Š°Š¹tu un pakeÅ”u skaitu, ko esat redzējis. Tie, kuriem ir pieredze lokālajā tÄ«kla droŔībā, atzÄ«s to par analogu plÅ«smām. NetFlow, kurus var izveidot uzņēmumu lÄ«meņa slēdži, marÅ”rutētāji un ugunsmÅ«ri. Å ie žurnāli ir svarÄ«gi kiberdroŔības uzraudzÄ«bas mērÄ·iem, jo tie, atŔķirÄ«bā no notikumiem par lietotāju un lietojumprogrammu darbÄ«bām, ļauj nepalaist garām arÄ« tÄ«kla mijiedarbÄ«bu virtuālajā privātajā mākoņa vidē AWS.

Mākoņu droŔības uzraudzÄ«ba

Tādējādi Å”ie trÄ«s AWS pakalpojumi ā€” AWS CloudTrail, Amazon CloudWatch un VPC Flow Logs ā€” kopā nodroÅ”ina pietiekami efektÄ«vu jÅ«su konta izmantoÅ”anas, lietotāju uzvedÄ«bas, infrastruktÅ«ras pārvaldÄ«bas, lietojumprogrammu un pakalpojumu aktivitātes, kā arÄ« tÄ«kla aktivitātes pārskatu. Piemēram, ar to palÄ«dzÄ«bu var atklāt Ŕādas anomālijas:

  • Mēģinājumi skenēt tÄ«mekļa vietni, meklējot aizmugures piekļuves, meklējot neaizsargātÄ«bas caur ā€œ404 kļūdasā€ pieaugumiem.
  • IeguldÄ«Å”anas uzbrukumi (piemēram, SQL injection) caur ā€œ500 kļūdasā€ pieaugumiem.
  • PazÄ«stami rÄ«ki SQL uzbrukumiem kā sqlmap, nikto, w3af, nmap u.c. caur lietotāja aÄ£enta lauka analÄ«zi.

Amazon Web Services ir izstrādājusi citus pakalpojumus kiberu droŔības mērÄ·iem, kas ļauj risināt daudzas citas problēmas. Piemēram, AWS ir iebÅ«vēts pakalpojums politiku un konfigurāciju auditÄ“Å”anai ā€” AWS Config. Å is pakalpojums nodroÅ”ina nepārtrauktu jÅ«su AWS resursu un to konfigurāciju auditu. ApskatÄ«sim vienkārÅ”u piemēru: pieņemsim, ka vēlaties pārliecināties, ka lietotāju paroles ir atslēgtas visos jÅ«su serveros un piekļuve ir iespējama tikai ar sertifikātiem. AWS Config ļauj viegli pārbaudÄ«t to visos jÅ«su serveros. Ir arÄ« citas politikas, kuras var tikt piemērotas jÅ«su mākoņa serveriem: "Nevienam serverim nav atļauts izmantot portu 22", "Tikai administrators var mainÄ«t ugunsmÅ«ra noteikumus" vai "Tikai lietotājs IvaÅ”ko var izveidot jaunas lietotāja kontus, un viņŔ to var darÄ«t tikai otrdienās". 2016. gada vasarā pakalpojums AWS Config tika paplaÅ”ināts, lai automatizētu pārkāpumu atklāŔanu izstrādātajās politikās. AWS Config Rules ir, bÅ«tÄ«bā, nepārtraukti konfigurācijas vaicājumi pakalpojumiem, ko izmantojat Amazon, kas Ä£enerē notikumus, gadÄ«jumā ja tiek pārkāptas attiecÄ«gās politikas. Piemēram, tā vietā, lai periodiski veiktu AWS Config vaicājumus, lai pārbaudÄ«tu, vai visi virtuālā servera diski ir Å”ifrēti, AWS Config Rules var izmantot, lai nepārtraukti pārbaudÄ«tu servera diskus, vai tie atbilst Å”im nosacÄ«jumam. Un, kas ir pats svarÄ«gākais, Ŕī publikācijas kontekstā, jebkuri pārkāpumi Ä£enerē notikumus, ko var analizēt jÅ«su kiberdroŔības dienests.

Mākoņu droŔības uzraudzÄ«ba

AWS ir arÄ« savi ekvivalenti tradicionālajiem uzņēmumu risinājumiem kiberu droŔībā, kas arÄ« Ä£enerē droŔības notikumus, kurus jÅ«s varat un jums vajadzētu analizēt:

  • iebrukuma atklāŔana ā€” AWS GuardDuty
  • informācijas noplÅ«des kontrole ā€” AWS Macie
  • EDR (kaut arÄ« runāt par gala ierÄ«cēm mākoņos izklausās nedaudz dÄ«vaini) ā€” AWS Cloudwatch + atvērtā pirmkoda risinājumi osquery vai GRR
  • Netflow analÄ«ze ā€” AWS Cloudwatch + AWS VPC Flow
  • DNS analÄ«ze ā€” AWS Cloudwatch + AWS Route53
  • AD ā€” AWS Directory Service
  • lietotāja kontu pārvaldÄ«ba ā€” AWS IAM
  • SSO ā€” AWS SSO
  • droŔības analÄ«ze ā€” AWS Inspector
  • konfigurāciju pārvaldÄ«ba ā€” AWS Config
  • WAF ā€” AWS WAF.

Es nevaru detalizēti izklāstÄ«t visus Amazon pakalpojumus, kas var bÅ«t noderÄ«gi informācijas droŔības kontekstā. Galvenais, ko jums jāizprot, ir tas, ka visi tie var Ä£enerēt notikumus, kurus mēs varam un vajadzētu analizēt informācijas droŔības ietvaros, piesaistot tam gan Amazon iebÅ«vētās iespējas, gan ārējās risinājumus, piemēram, SIEM, kas var iegÅ«t droŔības notikumus jÅ«su uzraudzÄ«bas centrā un analizēt tos kopā ar notikumiem no citiem mākoņu pakalpojumiem vai no iekŔējās infrastruktÅ«ras, perimetra vai mobilajām ierÄ«cēm.

Mākoņu droŔības uzraudzÄ«ba

Jebkurā gadījumā viss sākas ar datu avotiem, kas sniedz jums informācijas droŔības notikumus. Šādiem avotiem var starp citu pieskaitīt:

  • CloudTrail ā€” API izmantoÅ”ana un lietotāju darbÄ«bas
  • Trusted Advisor ā€” droŔības pārbaude atbilstÄ«bai labākajām praksēm
  • Config ā€” kontu un pakalpojumu iestatÄ«jumu inventarizācija un konfigurācija
  • VPC Flow Logs ā€” savienojumi ar virtuālajiem savienojumiem
  • IAM ā€” identifikācijas un autentifikācijas pakalpojums
  • ELB Access Logs ā€” slodzes lÄ«dzsvarotāja žurnāli
  • Inspector ā€” ievainojamÄ«bas lietojumprogrammās
  • S3 ā€” failu krātuve
  • CloudWatch ā€” lietojumprogrammu aktivitāte
  • SNS ā€” paziņojumu pakalpojums.

Amazon, piedāvājot tik plaÅ”u notikumu avotu un rÄ«ku klāstu to Ä£enerÄ“Å”anai, ir ļoti ierobežots datu analÄ«zes iespējās informācijas droŔības kontekstā. Jums bÅ«s jāiegÅ«st un jāpēta esoÅ”ie žurnāli, meklējot attiecÄ«gos kompromisa indikatorus. AWS Security Hub, kuru Amazon nesen ieviesa, ir paredzēts, lai risinātu Å”o problēmu, kļūstot par tādu kā mākoņu SIEM AWS. Tomēr tas joprojām ir tikai sākumposmā un ir ierobežots gan ar avots, ar kuriem tas strādā, gan ar citiem ierobežojumiem, ko nosaka Amazon arhitektÅ«ra un abonementi.

Piemērs: Informācijas droŔības uzraudzÄ«ba IaaS, pamatojoties uz Azure

Negribu iesaistÄ«ties ilgā diskusijā par to, kurÅ” no trim mākoņu pakalpojumu sniedzējiem (Amazon, Microsoft vai Google) ir labākais (jo katram no tiem ir sava specifika un tie ir piemēroti dažādu uzdevumu risināŔanai); koncentrēsimies uz droŔības uzraudzÄ«bas iespējām, kuras piedāvā Å”ie spēlētāji. JāatzÄ«st, ka Amazon AWS bija viens no pirmajiem Å”ajā segmentā, un tāpēc tas ir attÄ«stÄ«jies visvairāk droŔības funkciju ziņā (lai gan daudzi atzÄ«st, ka to lietot ir sarežģīti). Bet tas nenozÄ«mē, ka ignorēsim iespējas, kuras mums sniedz Microsoft ar Google.

Microsoft produkti vienmēr ir bijuÅ”i pazÄ«stami ar savu 'atvērtÄ«bu', un Azure situācija ir lÄ«dzÄ«ga. Piemēram, ja AWS un GCP vienmēr balstās uz konceptu 'viss, kas nav atļauts, ir aizliegts', tad Azure pieeja ir tieÅ”i pretēja. Piemēram, izveidojot virtuālo tÄ«klu mākoņos un virtuālo maŔīnu tajā, visi porti un protokoli pēc noklusējuma ir atvērti un atļauti. Tāpēc jums bÅ«s jāiegulda nedaudz vairāk pūļu, lai sākotnēji konfigurētu piekļuves kontroles sistēmu Microsoft mākoņos. Un tas uzliek jums stingrākas prasÄ«bas attiecÄ«bā uz darbÄ«bu uzraudzÄ«bu Azure mākoņos.

Mākoņu droŔības uzraudzÄ«ba

AWS ir Ä«paÅ”a iezÄ«me, kas saistÄ«ta ar to, ka, kamēr jÅ«s uzraugāt savus virtuālos resursus, ja tie atrodas dažādos reÄ£ionos, jums rodas grÅ«tÄ«bas apvienot visus notikumus un veikt to vienotu analÄ«zi, kuru novērÅ”anai jums jādodas uz dažādām viltÄ«bām, piemēram, izveidojot savu kodu AWS Lambda, kas pārsÅ«tÄ«s notikumus starp reÄ£ioniem. Azure Ŕādas problēmas nav ā€” tās mehānisms Activity Log seko lÄ«dzi visai aktivitātei visā organizācijā bez ierobežojumiem. Tas pats attiecas uz AWS Security Hub, kas nesen tika izstrādāts Amazon, lai konsolidētu daudzus droŔības funkcijas vienā droŔības centrā, bet tikai sava reÄ£iona ietvaros, kas, protams, Krievijai nav aktuāli. Azure ir sava Security Center, kas nav saistÄ«ta ar reÄ£ionālajiem ierobežojumiem un sniedz piekļuvi visām droŔības funkcijām mākoņa platformā. Turklāt dažādām vietējām komandām tas var nodroÅ”ināt savu komplektu aizsardzÄ«bas iespēju un, tostarp, pārvaldÄ«tus droŔības notikumus. AWS Security Hub vēl tikai cenÅ”as kļūt lÄ«dzÄ«gs Azure Security Center. Tomēr jāpiemin arÄ« ā€ždegtā€ ā€” jÅ«s varat izspiest no Azure ļoti daudz no iepriekÅ” aprakstÄ«tā AWS, bet visērtāk tas tiek izdarÄ«ts tikai Azure AD, Azure Monitor un Azure Security Center. Visi pārējie Azure aizsardzÄ«bas mehānismi, tostarp arÄ« droŔības notikumu analÄ«ze, pagaidām tiek pārvaldÄ«ti ne tik ērtā veidā. Daļēji problēmu risina API, kas caurvij visus Microsoft Azure pakalpojumus, bet tas prasÄ«s no jums papildu pÅ«les, integrējot savu mākoņu ar savu SOC un kvalificētu speciālistu klātbÅ«tni (pats attiecÄ«gi kā ar jebkuru citu SIEM, kas strādā ar mākoņu API). Daži SIEM, par kuriem tiks runāts tālāk, jau atbalsta Azure un var automatizēt tā uzraudzÄ«bas uzdevumu, bet arÄ« ar to ir savas grÅ«tÄ«bas ā€” ne visi tie var paņemt visus žurnālus, kas ir pieejami Azure.

Mākoņu droŔības uzraudzÄ«ba

Notikumu vākÅ”ana un uzraudzÄ«ba Azure tiek nodroÅ”ināta, izmantojot Azure Monitor pakalpojumu, kas ir galvenais rÄ«ks datu vākÅ”anai, glabāŔanai un analÄ«zei Microsoft mākonÄ« un tā resursos ā€” Git repozitorijās, konteineros, virtuālajās maŔīnās, lietojumprogrammās utt. Visi dati, ko vāc Azure Monitor, ir iedalÄ«ti divās kategorijās ā€” metrikās, kas tiek vāktas reālajā laikā un apraksta galvenos darbÄ«bas rādÄ«tājus Azure mākonÄ«, un žurnālos, kuros ir dati, organizēti ierakstos, kas raksturo konkrētus resursu un pakalpojumu aspektus.Azure. Turklāt, izmantojot Data Collector API, Azure Monitor pakalpojums var vāk datu no jebkura REST avota, lai izveidotu savus uzraudzÄ«bas scenārijus.

Mākoņu droŔības uzraudzÄ«ba

Šeit ir daži droŔības notikumu avoti, ko piedāvā Azure un kuriem varat piekļūt, izmantojot Azure Portal, CLI, PowerShell vai REST API (daži tikai caur Azure Monitor / Insight API):

  • DarbÄ«bu žurnāli ā€” Å”is žurnāls atbild uz klasiskajiem jautājumiem ā€œkurÅ”ā€, ā€œkoā€ un ā€œkadā€ attiecÄ«bā uz jebkuru ierakstÄ«Å”anas darbÄ«bu (PUT, POST, DELETE) mākonÄ« pieejamiem resursiem. Notikumi, kas saistÄ«ti ar piekļuvi (GET), Å”ajā žurnālā netiek iekļauti, kā arÄ« vairāki citi.
  • Diagnostikas žurnāli ā€” satur datus par darbÄ«bām ar konkrētu resursu, kas ietilpst jÅ«su abonementā.
  • Azure AD pārskati ā€” satur gan lietotāju aktivitāti, gan sistēmas aktivitāti, kas saistÄ«ta ar grupu un lietotāju pārvaldÄ«bu.
  • Windows notikumu žurnāls un Linux Syslog ā€” satur notikumus no virtuālajām maŔīnām, kas izvietotas mākonÄ«.
  • Metrikas ā€” satur telemtriju par snieguma un ā€œveselÄ«basā€ stāvokli jÅ«su mākoņa pakalpojumiem un resursiem. Tās tiek mērÄ«tas katru minÅ«ti un tiek glabātas 30 dienas.
  • TÄ«kla droŔības grupas plÅ«smu žurnāli ā€” satur datus par droŔības notikumiem tÄ«klā, kas tiek vākti, izmantojot Network Watcher pakalpojumu un resursu uzraudzÄ«bu tÄ«kla lÄ«menÄ«.
  • GlabāŔanas žurnāli ā€” satur notikumus, kas saistÄ«ti ar piekļuvi glabātuvēm.

Mākoņu droŔības uzraudzÄ«ba

Lai uzraudzÄ«tu, varat izmantot ārējās SIEM vai iebÅ«vēto Azure Monitor un tā paplaÅ”inājumus. Par informācijas droŔības notikumu vadÄ«bas sistēmām mēs vēl runāsim, bet pagaidām aplÅ«kosim, ko pats Azure piedāvā datu analÄ«zei droŔības kontekstā. Galvenā saskarne, kas saistÄ«ta ar droŔību Azure Monitor, ir Log Analytics Security and Audit Dashboard (bezmaksas versija atbalsta ierobežotu notikumu glabāŔanu tikai vienu nedēļu). Å Ä« paneļa ir sadalÄ«ta piecos galvenajos laukos, kas vizualizē kopsavilkuma statistiku par to, kas notiek jÅ«su izmantotajā mākoņa vidē:

  • DroŔības jomas ā€” galvenie kvantitatÄ«vie rādÄ«tāji, kas saistÄ«ti ar informācijas droŔību ā€” incidentu skaits, kompromitēto mezglu skaits, nepārbaudÄ«tie mezgli, tÄ«kla droŔības notikumi utt.
  • NozÄ«mÄ«gas problēmas ā€” parāda aktÄ«vo informācijas droŔības problēmu skaitu un to nopietnÄ«bu
  • Aptauju atklājumi ā€” parāda uzbrukumu shēmas, kas izmantotas pret jums
  • Draudu informācija ā€” parāda Ä£eogrāfisko informāciju par ārējiem mezgliem, kas uzbrÅ«k jums
  • Parastas droŔības vaicājumi ā€” tipiski vaicājumi, kas palÄ«dzēs jums labāk uzraudzÄ«t jÅ«su informācijas droŔību.

Mākoņu droŔības uzraudzÄ«ba

Kā Azure Monitor paplaÅ”inājumus var minēt Azure Key Vault (kriptogrāfisko atslēgu aizsardzÄ«ba mākoņos), Malware Assessment (kaitÄ«gā koda aizsardzÄ«bas analÄ«ze virtuālajās maŔīnās), Azure Application Gateway Analytics (analÄ«ze, tostarp mākoņu ugunsmÅ«ra žurnālu analÄ«ze) utt. Å ie rÄ«ki, kas bagātināti ar noteiktiem notikumu apstrādes noteikumiem, ļauj vizualizēt dažādus mākoņu pakalpojumu darbÄ«bas aspektus, tostarp droŔību, un identificēt dažādus novirzes no darbÄ«bas. Bet, kā tas bieži notiek, jebkuram papildu funkcionalitātei ir nepiecieÅ”ama attiecÄ«ga maksas abonÄ“Å”ana, kas prasÄ«s no jums attiecÄ«gus finanÅ”u ieguldÄ«jumus, kurus jums jāplāno iepriekÅ”.

Mākoņu droŔības uzraudzÄ«ba

Azure piedāvā virkni iebÅ«vētu iespēju draudu uzraudzÄ«bai, kas ir integrētas Azure AD, Azure Monitor un Azure Security Center. Starp tiem ir, piemēram, virtuālo maŔīnu mijiedarbÄ«bas atklāŔana ar zināmiem ļaunprogrammatÅ«ras IP (sakarā ar integrāciju ar Microsoft Threat Intelligence pakalpojumiem), ļaunprogrammatÅ«ras atklāŔana mākoņu infrastruktÅ«rā, pamatojoties uz trauksmes signāliem no mākoņī izvietotām virtuālajām maŔīnām, uzbrukumi ar

Mākoņu droŔības uzraudzÄ«ba

Kā jau minēts iepriekÅ”, aizsardzÄ«bas funkcionalitāte un, kā rezultātā, Ä£enerētie droŔības notikumi, nav pieejami visiem lietotājiem vienādi un prasa noteiktas abonÄ“Å”anas, kas iekļauj jums nepiecieÅ”amo funkcionalitāti, kas Ä£enerē attiecÄ«gos notikumus droŔības uzraudzÄ«bai. Piemēram, daļa iepriekÅ” minētajos aprakstos minēto anomaliju uzraudzÄ«bas funkciju ir pieejama tikai Premium P2 licencē Azure AD pakalpojumam. Bez tās, tāpat kā AWS gadÄ«jumā, jums bÅ«s jāanalizē savāktie droŔības notikumi "rokas" veidā. Un, atkarÄ«bā no Azure AD licences veida, jums bÅ«s pieejami ne visi analÄ«zei nepiecieÅ”amie notikumi.

Azure portālā jÅ«s varat pārvaldÄ«t gan meklÄ“Å”anas pieprasÄ«jumus attiecÄ«bā uz jums interesējoÅ”ajiem reÄ£istru žurnāliem, gan pielāgot dējos svarÄ«gu droŔības rādÄ«tāju vizuālai attēloÅ”anai. Turklāt jÅ«s varat izvēlēties Azure Monitor paplaÅ”inājumus, kas ļauj paplaÅ”ināt Azure Monitor žurnālu funkcionalitāti un iegÅ«t padziļinātu notikumu analÄ«zi droŔības aspektā.

Mākoņu droŔības uzraudzÄ«ba

Ja jums ir nepiecieÅ”ama ne tikai iespēja strādāt ar žurnāliem, bet arÄ« visaptveroÅ”a droŔības centra izveide jÅ«su Azure mākoņa platformai, tostarp kiberdroŔības pārvaldÄ«bas politikas, tad var runāt par nepiecieÅ”amÄ«bu izmantot Azure Security Center, kura lielākā daļa noderÄ«go funkciju ir pieejama par papildus samaksu, piemēram, draudu atklāŔana, uzraudzÄ«ba ārpus Azure, atbilstÄ«bas novērtÄ“Å”ana utt. (bezmaksas versijā pieejama tikai droŔības novērtÄ“Å”ana un ieteikumi konstatēto problēmu novērÅ”anai). Tas konsolidē visus droŔības jautājumus vienuviet. PatiesÄ«bā var runāt par augstāku kiberdroŔības lÄ«meni, nekā to nodroÅ”ina Azure Monitor, jo Å”ajā gadÄ«jumā jÅ«su savāktie dati tiek papildināti ar daudziem avotiem, piemēram, Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) un Microsoft Security Response Center (MSRC), uz kuriem attiecas dažādi sarežģīti maŔīnmācÄ«Å”anās algoritmi un uzvedÄ«bas analÄ«ze, kas gala rezultātā paaugstina draudu atklāŔanas un reaģēŔanas efektivitāti.

Azure ir arÄ« savs SIEM ā€” tas parādÄ«jās 2019. gada sākumā. Tas ir Azure Sentinel, kas balstās uz datiem no Azure Monitor un var integrēties ar ārējām droŔības risinājumiem (piemēram, NGFW vai WAF), kuru saraksts pastāvÄ«gi tiek papildināts. Turklāt, pateicoties Microsoft Graph Security API integrācijai, jums ir iespēja pievienot Sentinel savus Threat Intelligence plÅ«smus, kas bagātina incidentu analÄ«zes iespējas jÅ«su Azure mākoņā. Var apgalvot, ka Azure Sentinel ir pirmais ā€œautentiskaisā€ SIEM, kas parādÄ«jās mākoņu pakalpojumu sniedzējos (tādi kā Splunk vai ELK, kurus var izvietot mākoņos, piemēram, AWS, tomēr ir izstrādāti ne tradicionālo mākoņa pakalpojumu sniedzēju). Azure Sentinel un Security Center varētu nosaukt par SOC mākoņiem Azure, un tie varētu tikt uzskatÄ«ti par pietiekamiem (ar dažiem atrunājumiem), ja jums vairs nebÅ«tu nekādas infrastruktÅ«ras, un jÅ«s visu savu skaitļoÅ”anas jaudu pārvietotu mākonÄ«, un tas bÅ«tu Microsoft Azure mākonis.

Mākoņu droŔības uzraudzÄ«ba

Tomēr, ņemot vērā, ka Azure iebÅ«vētās iespējas (pat ja ir Sentinel abonements) bieži nepietiek monitoringa informācijas droŔības vajadzÄ«bām un Å”o procesu integrācijai ar citiem droŔības notikumu avotiem (gan mākoņiem, gan iekŔējiem), rodas nepiecieÅ”amÄ«ba eksportēt savāktos datus ārējās sistēmās, kuru vidÅ« var bÅ«t arÄ« SIEM. Tas tiek darÄ«ts gan, izmantojot API, gan ar Ä«paÅ”iem paplaÅ”inājumiem, kas Å”obrÄ«d oficiāli ir pieejami tikai Ŕādiem SIEM ā€” Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight un ELK. Vēl nesen, Ŕādu SIEM bija vairāk, taču kopÅ” 2019. gada 1. jÅ«nija Microsoft pārtrauca Azure Log Integration Tool (AzLog) atbalstu, kas Azure pastāvÄ“Å”anas sākumā un normālu žurnālu standardizācijas trÅ«kuma apstākļos (Azure Monitor vēl nebija) ļāva viegli integrēt ārējos SIEM ar Microsoft mākoņu. Tagad situācija ir mainÄ«jusies, un Microsoft iesaka platformu Azure Event Hub kā galveno integrācijas lÄ«dzekli pārējiem SIEM. Daudzi jau ir veikuÅ”i Ŕādu integrāciju, taču esiet uzmanÄ«gi ā€” tie var neaptvert visus Azure žurnālus, bet tikai dažus (skatiet jÅ«su SIEM dokumentācijā).

Noslēdzot Ä«su ieskatu Azure, vēlos sniegt vispārÄ«gu ieteikumu par Å”o mākoņservisu: pirms apgalvot jebko par Azure droŔības monitoringa funkcijām, tās ir ļoti rÅ«pÄ«gi jākonfigurē un jāpārbauda, vai tās darbojas tā, kā rakstÄ«ts dokumentācijā un kā jums stāstÄ«ja Microsoft konsultanti (kuriem var bÅ«t atŔķirÄ«gi uzskati par Azure funkciju efektivitāti). Ja finanses to atļauj, no Azure var iegÅ«t daudz noderÄ«gas informācijas attiecÄ«bā uz droŔības uzraudzÄ«bu. Ja jÅ«su resursi ir ierobežoti, tad, kā gadÄ«jumā ar AWS, jums bÅ«s jāpaļaujas tikai uz saviem spēkiem un neapstrādātiem datiem, ko nodroÅ”ina Azure Monitor. Un atcerieties, ka daudzas monitoringa funkcijas maksā, tāpēc ar cenu politiku labāk iepazÄ«ties iepriekÅ”. Piemēram, bez maksas jÅ«s varat uzglabāt datus 31 dienu apjomā lÄ«dz 5 GB uz klientu; pārsniedzot Å”os ierobežojumus, jums bÅ«s jāmaksā papildu maksa (aptuveni 2+ dolāri par katru papildu GB un 0,1 dolārs par katru papildu GB katru mēnesi). Darbs ar lietojumprogrammu telemetriju un metrikām arÄ« var prasÄ«t papildu finanÅ”u lÄ«dzekļus, lÄ«dzÄ«gi kā alerÅ”u un paziņojumu veidoÅ”ana (bezmaksas pieejams noteikts limits, kura var arÄ« nepietikt jÅ«su vajadzÄ«bām).

Piemērs: DroŔības uzraudzÄ«ba IaaS Google Cloud Platform

Google Cloud Platform pretstatā AWS un Azure izskatās kā jaunpienācējs, taču tas daļēji ir labi. AtŔķirÄ«bā no AWS, kas pakāpeniski paplaÅ”ināja savas iespējas, tostarp droŔības jomā, un saskārās ar centralizācijas problēmām; GCP, tāpat kā Azure, ir daudz labāk centralizēti pārvaldāms, kas samazina kļūdu skaitu un ievieÅ”anas laiku uzņēmumā. DroŔības aspektā GCP ir, dÄ«vainā kārtā, starp AWS un Azure. Tam ir arÄ« vienota notikumu reÄ£istrācija visai organizācijai, taču tā nav pilnÄ«ga. Dažas funkcijas joprojām ir beta versijā, taču pakāpeniski Å”is trÅ«kums tiks novērsts, un GCP kļūs par nobrieduŔāku platformu droŔības uzraudzÄ«bas jomā.

Mākoņu droŔības uzraudzÄ«ba

Galvenais rÄ«ks notikumu reÄ£istrācijai GCP ir Stackdriver Logging (analogais Azure Monitor), kas ļauj jums apkopt notikumus visā jÅ«su mākoņa infrastruktÅ«rā (kā arÄ« no AWS). No droŔības viedokļa GCP katrai organizācijai, projektam vai mapēm ir četri reÄ£istrācijas žurnāli:

  • Admin Activity ā€” satur visus notikumus, kas saistÄ«ti ar administratÄ«vo piekļuvi, piemēram, virtuālās maŔīnas izveidoÅ”ana, piekļuves tiesÄ«bu maiņa utt. Å is žurnāls tiek rakstÄ«ts vienmēr, neatkarÄ«gi no jÅ«su vēlmēm, un saglabā savus datus 400 dienas.
  • Data Access ā€” satur visus notikumus, kas saistÄ«ti ar datu apstrādi mākoņa lietotājiem (izveidoÅ”ana, izmaiņas, lasÄ«Å”ana utt.). Noklusējuma iestatÄ«jumos Å”is žurnāls netiek rakstÄ«ts, jo tā apjoms ļoti ātri pieaug. Tāpēc tā uzglabāŔanas termiņŔ ir tikai 30 dienas. Turklāt Å”ajā žurnālā netiek ierakstÄ«ti visi notikumi. Piemēram, tajā netiek ierakstÄ«ti notikumi, kas saistÄ«ti ar publiski pieejamiem resursiem visiem lietotājiem vai kas pieejami bez pieteikÅ”anās GCP.
  • System Event ā€” satur sistēmiskos notikumus, kas nav saistÄ«ti ar lietotājiem, vai administratora rÄ«cÄ«bu, kas maina mākoņa resursu konfigurāciju. Tiek rakstÄ«ts vienmēr un saglabāts 400 dienas.
  • Access Transparency ā€” tas ir unikāls reÄ£istrācijas žurnāls, kas fiksē visas Google darbinieku darbÄ«bas (bet pagaidām ne visiem GCP pakalpojumiem), kuri piekļūst jÅ«su infrastruktÅ«rai darba pienākumu izpildes laikā. Å is žurnāls tiek glabāts 400 dienas un ir pieejams ne visiem GCP klientiem, bet tikai tad, ja tiek izpildÄ«ti noteikti nosacÄ«jumi (vai Gold vai Platinum lÄ«meņa atbalsts, vai 4 noteikta tipa lomu klātbÅ«tne korporatÄ«vajā atbalstā). LÄ«dzÄ«ga funkcionalitāte pastāv arÄ«, piemēram, Office 365 ā€” Lockbox.

Žurnāla piemērs: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "ASV"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "KAN"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Lieta numurs: bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Piekļuve norādÄ«tajiem žurnāliem ir iespējama dažādos veidos (lÄ«dzÄ«gi kā iepriekÅ” apspriestā Azure un AWS) ā€” caur Log Viewer saskarni, caur API, caur Google Cloud SDK vai caur jÅ«su projekta Activity lapu, kurā jÅ«s interesē notikumi. Tos var arÄ« eksportēt uz ārējām risinājumiem papildu analÄ«zei. Pēdējo var veikt, eksportējot žurnālus BigQuery vai Cloud Pub/Sub glabātavā.

Papildus Stackdriver Logging platforma GCP piedāvā arÄ« Stackdriver Monitoring funkcionalitāti, kas ļauj sekot lÄ«dzi galvenajām metrikām (veiktspējai, kļūmju normām, vispārējam stāvoklim utt.) mākoņu pakalpojumiem un lietojumprogrammām. Speciāli apstrādātie un vizualizētie dati var atvieglot problēmu meklÄ“Å”anu jÅ«su mākoņu infrastruktÅ«rā, tostarp droŔības kontekstā. Tomēr jāatzÄ«mē, ka Å”is funkcionalitāte nebÅ«s ļoti bagāta tieÅ”i droŔības kontekstā, jo Å”obrÄ«d GCP nav analoga AWS GuardDuty un nevar izcelt sliktus notikumus starp visiem reÄ£istrētajiem notikumiem (Google ir izstrādājis Event Threat Detection, bet Å”obrÄ«d tas ir beta versijā, un ir pāragri runāt par tā noderÄ«gumu). Stackdriver Monitoring var izmantot kā anomāliju atklāŔanas sistēmu, kuras pēc tam tiks izmeklētas, lai atrastu to raÅ”anās cēloņus. Bet ar kvalificētu droŔības ekspertu trÅ«kumu GCP tirgÅ«, Å”is uzdevums Å”obrÄ«d izskatās sarežģīts.

Mākoņu droŔības uzraudzÄ«ba

Vērts pieminēt dažus droŔības moduļus, kurus var izmantot jÅ«su GCP mākoņa ietvaros, un kuri ir lÄ«dzÄ«gi tam, ko piedāvā AWS:

  • Cloud Security Command Center ā€” tas ir analoga AWS Security Hub un Azure Security Center.
  • Cloud DLP ā€” automātiska datu identificÄ“Å”ana un rediģēŔana (piemēram, maskÄ“Å”ana), kas izvietota mākoņos, saskaņā ar vairāk nekā 90 iepriekÅ” noteiktām klasifikācijas politikām.
  • Cloud Scanner ā€” pazÄ«stamo ievainojamÄ«bu (XSS, Flash Injection, nepārsniegtas bibliotēkas utt.) skeneris App Engine, Compute Engine un Google Kubernetes.
  • Cloud IAM ā€” piekļuves pārvaldÄ«ba visiem GCP resursiem.
  • Cloud Identity ā€” GCP lietotāju, ierīču un lietojumprogrammu kontu pārvaldÄ«ba no vienas konsoles.
  • Cloud HSM ā€” kriptogrāfisko atslēgu aizsardzÄ«ba.
  • Cloud Key Management Service ā€” kriptogrāfisko atslēgu pārvaldÄ«ba GCP.
  • VPC Service Control ā€” droÅ”a perimetra izveide ap jÅ«su GCP resursiem, lai aizsargātu tos no noplÅ«dēm.
  • Titan Security Key ā€” aizsardzÄ«ba pret phishing uzbrukumiem.

Mākoņu droŔības uzraudzÄ«ba

Daudzi no Å”iem moduļiem Ä£enerē droŔības notikumus, kurus var nosÅ«tÄ«t uz BigQuery krātuvi analÄ«zei vai eksportÄ“Å”anai citām sistēmām, tostarp SIEM. Kā jau minēts iepriekÅ”, GCP ir aktÄ«vi attÄ«stÄ«ta platforma, un Å”obrÄ«d Google izstrādā jaunu moduļu virkni droŔības jomā savai platformai. Starp tiem ir Event Threat Detection (paÅ”laik pieejams beta testÄ“Å”anai), kas skenē Stackdriver žurnālus, meklējot nelikumÄ«gas aktivitātes pēdas (analogiski GuardDuty AWS), vai Policy Intelligence (pieejams alfa testÄ“Å”anai), kas ļaus izstrādāt inteliÄ£entas piekļuves politikās GCP resursiem.

Es veicu nelielu apskatu par iebÅ«vētajām uzraudzÄ«bas iespējām populārās mākoņu platformās. Bet vai jums ir speciālisti, kas spēj strādāt ar 'neapstrādātiem' IaaS pakalpojumu sniedzēja žurnāliem (ne visi ir gatavi iegādāties paplaÅ”inātas iespējas AWS, Azure vai Google)? Turklāt daudziem ir zināma paruna 'uzticēties, bet pārbaudÄ«t', kas droŔības jomā ir svarÄ«gāka nekā jebkad. Cik ļoti jÅ«s uzticaties mākoņu pakalpojumu sniedzēja iebÅ«vētajām iespējām, kas jums sniedz droŔības notikumus? Cik daudz tie vispār koncentrējas uz droŔību?

Dažreiz ir vērts apsvērt risinājumus, kas nodroÅ”ina uzraudzÄ«bu mākonÄ«, kas var papildināt mākonÄ« iebÅ«vēto droŔību, un dažreiz Ŕādi risinājumi ir vienÄ«gā iespēja saņemt datus par jÅ«su datu un lietojumprogrammu droŔību, kas izvietotas mākonÄ«. Turklāt tie ir vienkārŔāki, jo uzņemās visus uzdevumus, kas saistÄ«ti ar nepiecieÅ”amo žurnālu analÄ«zi, ko Ä£enerē dažādi mākonÄ« esoÅ”ie pakalpojumi no dažādiem mākonÄ« sniedzējiem. Par tādu risinājumu var minēt Cisco Stealthwatch Cloud, kas koncentrējas uz vienu uzdevumu ā€” uzraudzÄ«t anomālijas informācijas droŔībā mākonÄ«, tostarp ne tikai Amazon AWS, Microsoft Azure un Google Cloud Platform, bet arÄ« privātajos mākoņos.

Piemērs: Informācijas droŔības uzraudzÄ«ba ar Stealthwatch Cloud

AWS nodroÅ”ina elastÄ«gu skaitļoÅ”anas platformu, taču Ŕī elastÄ«ba noved pie tā, ka uzņēmumiem ir vieglāk pieļaut kļūdas, kas rada droŔības problēmas. Un koplietoÅ”anas informācijas droŔības modelis to tikai veicina. ProgrammatÅ«ras palaiÅ”ana mākonÄ« ar nezināmām ievainojamÄ«bām (ar zināmām, piemēram, var cÄ«nÄ«ties AWS Inspector vai GCP Cloud Scanner), vājas paroles, nepareizas konfigurācijas, iekŔējie riski utt. Un viss tas ietekmē mākoņa resursu uzvedÄ«bu, kuru var uzraudzÄ«t Cisco Stealthwatch Cloud, kas ir informācijas droŔības uzraudzÄ«bas un uzbrukumu atklāŔanas sistēma publiskajos un privātajos mākoņos.

Mākoņu droŔības uzraudzÄ«ba

Viens no galvenajiem Cisco Stealthwatch Cloud aspektiem ir iespēja modelēt entÄ«tijas. Ar tā palÄ«dzÄ«bu var izveidot programmatÅ«ras modeli (proti, praktiski reāliem apstākļiem atbilstoÅ”u simulāciju) katram no jÅ«su mākoņa resursiem (neatkarÄ«gi no tā, vai tas ir AWS, Azure, GCP vai kas cits). Tajos var ietilpt serveri un lietotāji, kā arÄ« resursi, kas specifiski jÅ«su mākoņa videi, piemēram, droŔības grupas un automātiskās mērogoÅ”anas grupas (auto-scale). Å ie modeļi izmanto strukturotus datu plÅ«smas datus, ko sniedz mākoņa pakalpojumi. Piemēram, AWS gadÄ«jumā tas bÅ«s VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda un AWS IAM. EntÄ«tiju modelÄ“Å”ana automātiski identificē jebkura no jÅ«su resursiem lomu un uzvedÄ«bu (var runāt par visu mākoņa aktivitātes profilÄ“Å”anu). Starp Ŕīm lomām ir Android vai Apple mobilā ierÄ«ce, Citrix PVS serveris, RDP serveris, e-pasta vārti, VoIP klients, terminālu serveris, domēna kontrolieris utt. Pēc tam tas nepārtraukti uzrauga to uzvedÄ«bu, lai noteiktu, kad notiek riskanta vai droŔībai bÄ«stama uzvedÄ«ba. JÅ«s varat identificēt paroles uzminÄ“Å”anu, DDoS uzbrukumus, datu noplÅ«des, nelikumÄ«gu attālinātu piekļuvi, ļaunprogrammatÅ«ras darbÄ«bu, ievainojamÄ«bu skenÄ“Å”anu un citas briesmas. Piemēram, tā izskatās mēģinājumu attālināti piekļūt no netipiskas jÅ«su organizācijai valsts (Dienvidkorejas) Kubernetes klasterim pa SSH atklāŔana:

Mākoņu droŔības uzraudzÄ«ba

Un Ŕādi izskatās aizdomīga informācijas noplūde no Postgress datu bāzes uz valsti, ar kuru iepriekŔ nav bijusi saskarsme:

Mākoņu droŔības uzraudzÄ«ba

Visbeidzot, tā izskatās pārāk liels neveiksmīgu piekļuves mēģinājumu skaits pa SSH no Ķīnas un Indonēzijas no ārējās attālinātās ierīces:

Mākoņu droŔības uzraudzÄ«ba

Vai, pieņemsim, ka servera instances VPC, saskaņā ar politiku, nekad nedrÄ«kst bÅ«t attālās pieslēgÅ”anās mērÄ·is. Pieņemiet tālāk, ka Å”ajā datorā ir notikusi attālā pieslēgÅ”anās kļūdas dēļ, kas radusies, mainot ugunsmÅ«ra noteikumus. EntitāŔu modelÄ“Å”anas funkcija atklās un ziņos par Å”o aktivitāti ("Neparasta attālā piekļuve") gandrÄ«z Ä«stajā laikā un norādÄ«s uz konkrētu AWS CloudTrail, Azure Monitor vai GCP Stackdriver Logging API pieprasÄ«jumu (ieskaitot lietotājvārdu, datumu un laiku, kā arÄ« citus datus), kas izsauca izmaiņas ugunsmÅ«ra noteikumā. Pēc tam Ŕī informācija var tikt nodota SIEM analÄ«zei.

Mākoņu droŔības uzraudzÄ«ba

Līdzīgas iespējas tiek īstenotas jebkurā mākoņu vidē, ko atbalsta Cisco Stealthwatch Cloud:

Mākoņu droŔības uzraudzÄ«ba

EntitāŔu modelÄ“Å”ana ir unikāla droŔības automatizācijas forma, kas var atklāt iepriekÅ” nezināmu problēmu ar jÅ«su cilvēkiem, procesiem vai tehnoloÄ£ijām. Piemēram, tā ļauj atklāt, starp citu, Ŕādas droŔības problēmas:

  • Vai kāds ir atradis aizmugures durvis programmatÅ«rā, ko mēs izmantojam?
  • Vai mÅ«su mākoņos ir kāda treŔā puse programmatÅ«ra vai ierÄ«ce?
  • Vai pilnvarota persona ļaunprātÄ«gi izmanto privilēģijas?
  • Vai ir pieļauta konfigurācijas kļūda, kas nodroÅ”ina attālo piekļuvi vai citu neparedzētu resursu izmantoÅ”anu?
  • Vai no mÅ«su serveriem nav datu noplÅ«des?
  • Vai kāds nav mēģinājis pieslēgties no netipiskas Ä£eogrāfiskas vietas?
  • Vai mÅ«su mākonis nav inficēts ar ļaunprātÄ«gu kodu?

Mākoņu droŔības uzraudzÄ«ba

Konstatētā kiberdroŔības notikums var tikt nodots kā attiecÄ«gs biļete Slack, Cisco Spark, incidentu pārvaldÄ«bas sistēmā PagerDuty, kā arÄ« tiek nodots dažādiem SIEM, tai skaitā Splunk vai ELK. Rezumējot, var teikt, ka, ja jÅ«su uzņēmums izmanto multiklāstu stratēģiju un nav ierobežots ar kādu vienu mākoņa pakalpojumu sniedzēju, kiberdroŔības uzraudzÄ«bas iespējas, kas aprakstÄ«tas iepriekÅ”, izmantojot Cisco Stealthwatch Cloud, ir labs veids, kā iegÅ«t vienotu uzraudzÄ«bas komplektu vadoÅ”ajiem mākoņu spēlētājiem ā€” Amazon, Microsoft un Google. Kas ir visinteresantākais, ja salÄ«dzināt Stealthwatch Cloud cenas ar uzlabotajām licencēm kiberdroŔības uzraudzÄ«bai AWS, Azure vai GCP, var izrādÄ«ties, ka Cisco risinājums ir pat lētāks par iebÅ«vētajām iespējām, ko piedāvā Amazon, Microsoft un Google. Paradoxāli, bet tā ir. Un jo vairāk mākoņu un to iespēju jÅ«s izmantojat, jo acÄ«mredzamāka bÅ«s konsolidētā risinājuma priekÅ”rocÄ«ba.

Mākoņu droŔības uzraudzÄ«ba

Turklāt Stealthwatch Cloud var uzraudzÄ«t arÄ« privātos mākoņus, kas izvietoti jÅ«su organizācijā, piemēram, balstoties uz Kubernetes konteineriem, vai uzraugot Netflow plÅ«smas vai tÄ«kla trafiku, kas iegÅ«ts caur tÄ«kla aprÄ«kojuma spoguļoÅ”anu (pat vietējā ražojuma), AD vai DNS serveru datus u.c. Visi Å”ie dati tiks bagātināti ar Threat Intelligence informāciju, kas tiek vāktas no Cisco Talos nodaļas, kas ir lielākā pasaulē nevalstiskā kiberdroŔības pētnieku grupa.

Mākoņu droŔības uzraudzÄ«ba

Tas ļauj jums izveidot vienotu uzraudzības sistēmu gan publiskajiem, gan hibrīdajiem mākoņiem, kuri var tikt izmantoti jūsu uzņēmumā. Savākta informācija pēc tam var tikt analizēta, izmantojot iebūvētās Stealthwatch Cloud iespējas vai nosūtīta uz jūsu SIEM (iekļauts Splunk, ELK, SumoLogic un vairāki citi).

Tādējādi mēs noslēdzam raksta pirmo daļu, kurā es apskatÄ«ju IaaS/PaaS platformu iebÅ«vētās un ārējās droŔības uzraudzÄ«bas rÄ«kus, kas ļauj mums ātri atklāt un reaģēt uz incidentiem, kas notiek mākoņvidēs, ko izvēlējusies mÅ«su uzņēmums. Otrajā daļā mēs turpināsim tēmu un apskatÄ«sim uzraudzÄ«bas iespējas SaaS platformām, izmantojot Salesforce un Dropbox piemērus, kā arÄ« mēģināsim apkopt un apvienot visu, izveidojot vienotu droŔības uzraudzÄ«bas sistēmu dažādu mākoņu pakalpojumu sniedzēju vidÅ«.

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster