Cloud Security Monitoring

Datan ja sovellusten siirtäminen pilveen on uusi haaste yritysten SOC:ille, jotka eivät aina ole valmiita seuraamaan muiden ihmisten infrastruktuuria. Netoskopen mukaan keskivertoyritys (ilmeisesti Yhdysvalloissa) käyttää 1246 22 erilaista pilvipalvelua, mikä on 1246 % enemmän kuin vuosi sitten. 175 pilvipalvelua!!! Niistä 170 liittyy HR-palveluihin, 110 liittyy markkinointiin, 76 viestintäalaan ja 700 talous- ja asiakkuudenhallintaan. Cisco käyttää "vain" XNUMX ulkoista pilvipalvelua. Joten olen hieman hämmentynyt näistä numeroista. Mutta joka tapauksessa ongelma ei ole heissä, vaan siinä, että pilvi alkaa olla melko aktiivisesti käytössä yhä useammassa yrityksessä, joka haluaisi pilviinfrastruktuurin valvontaan samat valmiudet kuin omassa verkossaan. Ja tämä trendi on kasvava - mukaan American Chamber of Accountin mukaan Vuoteen 2023 mennessä Yhdysvalloissa suljetaan 1200 6250 datakeskusta (XNUMX XNUMX on jo suljettu). Mutta siirtyminen pilveen ei ole vain "siirretään palvelimemme ulkoiselle palveluntarjoajalle". Uusi IT-arkkitehtuuri, uudet ohjelmistot, uudet prosessit, uudet rajoitukset... Kaikki tämä tuo merkittäviä muutoksia paitsi IT:n, myös tietoturvan työhön. Ja jos palveluntarjoajat ovat oppineet jotenkin selviytymään itse pilven turvallisuuden varmistamisesta (onneksi suosituksia on paljon), niin pilvitietoturvavalvonnassa, erityisesti SaaS-alustoilla, on merkittäviä vaikeuksia, joista puhumme.

Oletetaan, että yrityksesi on siirtänyt osan infrastruktuuristaan ​​pilveen... Lopeta. Ei tällä tavalla. Jos infrastruktuuri on siirretty ja mietit vasta nyt, kuinka valvot sitä, olet jo hävinnyt. Ellei se ole Amazon, Google tai Microsoft (ja sitten varauksin), sinulla ei todennäköisesti ole paljon mahdollisuuksia seurata tietojasi ja sovelluksiasi. On hyvä, jos sinulle annetaan mahdollisuus työskennellä hirsien parissa. Joskus tietoturvatapahtumatiedot ovat saatavilla, mutta sinulla ei ole pääsyä niihin. Esimerkiksi Office 365. Jos sinulla on halvin E1-lisenssi, tietoturvatapahtumat eivät ole käytettävissäsi ollenkaan. Jos sinulla on E3-lisenssi, tietosi säilyvät vain 90 päivää, ja vain jos sinulla on E5-lisenssi, lokien kesto on saatavilla vuoden (tässä on kuitenkin myös omat vivahteensa, jotka liittyvät tarpeeseen erikseen pyytää Microsoftin tuelta useita toimintoja lokien käsittelyä varten). Muuten, E3-lisenssi on valvontatoimintojen suhteen paljon heikompi kuin yritysvaihto. Saman tason saavuttamiseksi tarvitset E5-lisenssin tai ylimääräisen Advanced Compliance -lisenssin, mikä saattaa vaatia lisärahoitusta, jota ei ole otettu huomioon rahoitusmallissasi siirtyessäsi pilviinfrastruktuuriin. Ja tämä on vain yksi esimerkki pilvitietoturvavalvontaan liittyvien ongelmien aliarvioinnista. Tässä artikkelissa, teeskentelemättä täydellisyyttä, haluan kiinnittää huomiota joihinkin vivahteisiin, jotka tulisi ottaa huomioon valittaessa pilvipalveluntarjoajaa tietoturvan näkökulmasta. Ja artikkelin lopussa annetaan tarkistuslista, joka kannattaa täyttää ennen kuin ajatellaan, että pilvitietoturvan valvontakysymys on ratkaistu.

Pilviympäristöissä on useita tyypillisiä ongelmia, jotka johtavat tapauksiin, joihin tietoturvapalvelut eivät ehdi reagoida tai eivät näe niitä ollenkaan:

• Suojauslokeja ei ole olemassa. Tämä on melko yleinen tilanne, etenkin pilviratkaisumarkkinoiden aloittelevien toimijoiden keskuudessa. Mutta sinun ei pidä luopua niistä heti. Pienet toimijat, erityisesti kotimaiset, ovat herkempiä asiakkaiden vaatimuksille ja voivat nopeasti toteuttaa joitain vaadittuja toimintoja muuttamalla tuotteilleen hyväksyttyä tiekarttaa. Kyllä, tämä ei ole analoginen Amazonin GuardDutylle tai Bitrixin "Proactive Protection" -moduulille, mutta ainakin jotain.
• Tietoturva ei tiedä missä lokit on tallennettu tai niihin ei ole pääsyä. Tässä on tarpeen ryhtyä neuvotteluihin pilvipalvelun tarjoajan kanssa - ehkä hän antaa tällaiset tiedot, jos hän pitää asiakasta itselleen tärkeänä. Mutta yleensä ei ole kovin hyvä, kun pääsy lokeihin tarjotaan "erityispäätöksellä".
• On myös mahdollista, että pilvipalveluntarjoajalla on lokeja, mutta ne tarjoavat rajoitettua seurantaa ja tapahtumatallennusta, jotka eivät riitä kaikkien tapahtumien havaitsemiseen. Saatat esimerkiksi saada vain lokeja sivuston muutoksista tai lokeja käyttäjien todennusyrityksistä, mutta et muita tapahtumia, esimerkiksi verkkoliikenteestä, mikä piilottaa sinulta kokonaisen kerroksen tapahtumia, jotka kuvaavat yrityksiä murtaa pilviinfrastruktuurisi. .
• Lokeja on, mutta niihin pääsy on vaikeasti automatisoitavissa, mikä pakottaa niitä seuraamaan ei jatkuvasti, vaan aikataulussa. Ja jos lokien lataaminen ei onnistu automaattisesti, niin lokien lataaminen esimerkiksi Excel-muodossa (kuten useiden kotimaisten pilviratkaisujen toimittajilla) voi jopa johtaa yritysten tietoturvapalvelun haluttomuuteen puuhata niitä.
• Ei lokin seurantaa. Tämä on ehkä epäselvin syy tietoturvahäiriöiden esiintymiseen pilviympäristöissä. Näyttää siltä, ​​​​että lokit ovat olemassa, ja niihin pääsy on mahdollista automatisoida, mutta kukaan ei tee tätä. Miksi?

Jaettu pilvitietoturvakonsepti

Pilveen siirtyminen on aina tasapainon etsintää halun hallita infrastruktuuria ja sen siirtämistä sen ylläpitoon erikoistuneen pilvipalvelun ammattimaisempiin käsiin. Ja pilviturvallisuuden alalla tätä tasapainoa on myös etsittävä. Lisäksi riippuen käytetystä pilvipalvelun toimitusmallista (IaaS, PaaS, SaaS), tämä saldo on erilainen koko ajan. Joka tapauksessa on muistettava, että kaikki pilvipalveluntarjoajat noudattavat nykyään niin sanottua yhteistä vastuuta ja yhteistä tietoturvamallia. Pilvi on vastuussa joistakin asioista ja toisista asiakas on vastuussa sijoittaen tietonsa, sovelluksensa, virtuaalikoneensa ja muut resurssinsa pilveen. Olisi holtitonta odottaa, että pilveen siirtymällä siirrämme kaiken vastuun palveluntarjoajalle. Mutta ei myöskään ole viisasta rakentaa kaikkea turvallisuutta itse, kun siirryt pilveen. Tarvitaan tasapaino, joka riippuu monista tekijöistä: - riskienhallintastrategia, uhkamalli, pilvipalveluntarjoajan käytettävissä olevat suojausmekanismit, lainsäädäntö jne.

Esimerkiksi pilvessä isännöidyn datan luokittelu on aina asiakkaan vastuulla. Pilvipalveluntarjoaja tai ulkoinen palveluntarjoaja voi auttaa häntä vain työkaluilla, jotka auttavat merkitsemään tietoja pilvessä, tunnistamaan rikkomuksia, poistamaan lakia rikkovat tiedot tai peittämään sen tavalla tai toisella. Toisaalta fyysinen turvallisuus on aina pilvipalveluntarjoajan vastuulla, jota se ei voi jakaa asiakkaiden kanssa. Mutta kaikki, mikä on datan ja fyysisen infrastruktuurin välillä, on juuri tämän artikkelin keskustelunaihe. Esimerkiksi pilven saatavuus on palveluntarjoajan vastuulla ja palomuurisääntöjen asettaminen tai salauksen käyttöönotto on asiakkaan vastuulla. Tässä artikkelissa yritämme tarkastella, mitä tietoturvan valvontamekanismeja useat suositut pilvipalveluntarjoajat tarjoavat nykyään Venäjällä, mitkä ovat niiden käytön ominaisuudet ja milloin kannattaa suunnata ulkoisiin peittoratkaisuihin (esim. Cisco E- mail Security), jotka laajentavat pilvesi kyberturvallisuuden ominaisuuksia. Joissakin tapauksissa, varsinkin jos noudatat monipilvistrategiaa, sinulla ei ole muuta vaihtoehtoa kuin käyttää ulkoisia tietoturvan valvontaratkaisuja useissa pilviympäristöissä samanaikaisesti (esimerkiksi Cisco CloudLock tai Cisco Stealthwatch Cloud). No, joissain tapauksissa huomaat, että valitsemasi (tai sinulle määräämäsi) pilvipalveluntarjoaja ei tarjoa lainkaan tietoturvan valvontaominaisuuksia. Tämä on epämiellyttävää, mutta ei vähän, koska sen avulla voit arvioida riittävästi tämän pilven kanssa työskentelemiseen liittyvän riskin tasoa.

Pilvitietoturvavalvonnan elinkaari

Voit valvoa käyttämiesi pilvien turvallisuutta vain kolmella tavalla:

• luottaa pilvipalveluntarjoajasi tarjoamiin työkaluihin,
• käyttää kolmansien osapuolien ratkaisuja, jotka valvovat käyttämiäsi IaaS-, PaaS- tai SaaS-alustoja,
• rakentaa oma pilvivalvontainfrastruktuuri (vain IaaS/PaaS-alustoille).

Katsotaanpa, mitä ominaisuuksia kullakin näistä vaihtoehdoista on. Mutta ensin meidän on ymmärrettävä yleinen kehys, jota käytetään pilvialustojen seurannassa. Haluaisin nostaa esiin kuusi pääkomponenttia tietoturvan seurantaprosessista pilvessä:

• Infrastruktuurin valmistelu. Tarvittavien sovellusten ja infrastruktuurin määrittäminen tietoturvallisuuden kannalta tärkeiden tapahtumien keräämiseksi varastoon.
• Kokoelma. Tässä vaiheessa tietoturvatapahtumat kootaan yhteen eri lähteistä myöhempää lähetystä varten käsittelyä, tallennusta ja analysointia varten.
• Hoito. Tässä vaiheessa tiedot muunnetaan ja rikastetaan myöhemmän analyysin helpottamiseksi.
• Varastointi. Tämä komponentti vastaa kerättyjen käsiteltyjen ja raakatietojen lyhyt- ja pitkäaikaisesta tallentamisesta.
• Analyysi. Tässä vaiheessa sinulla on mahdollisuus havaita tapahtumat ja vastata niihin automaattisesti tai manuaalisesti.
• Raportointi. Tämä vaihe auttaa muotoilemaan sidosryhmille (johto, tilintarkastajat, pilvipalveluntarjoaja, asiakkaat jne.) avainindikaattoreita, jotka auttavat meitä tekemään tiettyjä päätöksiä, esimerkiksi toimittajan vaihtamista tai tietoturvan vahvistamista.

Näiden komponenttien ymmärtäminen antaa sinun päättää tulevaisuudessa nopeasti, mitä voit ottaa palveluntarjoajaltasi ja mitä sinun on tehtävä itse tai ulkopuolisten konsulttien avulla.

Sisäänrakennetut pilvipalvelut

Kirjoitin jo ylempänä, että monet pilvipalvelut eivät nykyään tarjoa mitään tietoturvan seurantaominaisuuksia. Yleensä he eivät kiinnitä paljon huomiota tietoturva-aiheeseen. Esimerkiksi yksi suosituista venäläisistä palveluista raporttien lähettämiseen valtion virastoille Internetin kautta (en mainitse nimenomaisesti sen nimeä). Koko tämän palvelun turvallisuutta käsittelevä osio käsittelee sertifioidun CIPF:n käyttöä. Toisen kotimaisen pilvipalvelun tietoturvaosio sähköiseen dokumenttien hallintaan ei eroa toisistaan. Se kertoo julkisen avaimen varmenteista, sertifioidusta kryptografiasta, verkkohaavoittuvuuksien poistamisesta, suojauksesta DDoS-hyökkäyksiltä, ​​palomuurien käytöstä, varmuuskopioista ja jopa säännöllisistä tietoturvatarkastuksista. Mutta valvonnasta ei puhuta sanaakaan eikä mahdollisuudesta päästä käsiksi tietoturvatapahtumiin, jotka voivat kiinnostaa tämän palveluntarjoajan asiakkaita.

Yleisesti ottaen siitä, miten pilvipalveluntarjoaja kuvailee tietoturvakysymyksiä verkkosivuillaan ja dokumentaatiossaan, voit ymmärtää, kuinka vakavasti se suhtautuu asiaan. Jos esimerkiksi luet "My Office" -tuotteiden käsikirjat, turvallisuudesta ei puhuta sanaakaan, vaan erillisen tuotteen "My Office" dokumentaatiossa. KS3", joka on suunniteltu suojaamaan luvattomalta käytöltä, on tavallinen luettelo FSTEC:n 17. luokan kohdista, jotka "My Office.KS3" toteuttaa, mutta siinä ei ole kuvattu, kuinka se toteuttaa sen ja mikä tärkeintä, miten se toteutetaan. integroida nämä mekanismit yrityksen tietoturvaan. Ehkä tällainen dokumentaatio on olemassa, mutta en löytänyt sitä julkisesti "Oma toimisto" -verkkosivustolta. Vaikka ehkä minulla ei vain ole pääsyä näihin salaisiin tietoihin?

Bitrixin osalta tilanne on paljon parempi. Dokumentaatiossa kuvataan tapahtumalokien muodot ja mielenkiintoisella tavalla tunkeutumisloki, joka sisältää tapahtumia, jotka liittyvät mahdollisiin pilvialustaan ​​kohdistuviin uhkiin. Sieltä voit vetää esiin IP-osoitteen, käyttäjän tai vieraan nimen, tapahtuman lähteen, ajan, käyttäjäagentin, tapahtumatyypin jne. Totta, voit käsitellä näitä tapahtumia joko itse pilven ohjauspaneelista tai ladata tietoja MS Excel -muodossa. Bitrix-lokien kanssa työskentely on nyt vaikeaa automatisoida ja joudut tekemään osan työstä manuaalisesti (raportin lataaminen ja lataaminen SIEM-järjestelmääsi). Mutta jos muistamme, että tällaista mahdollisuutta ei ollut vielä suhteellisen äskettäin, niin tämä on suuri edistys. Samalla haluan huomauttaa, että monet ulkomaiset pilvipalveluntarjoajat tarjoavat samanlaisia ​​​​toimintoja "aloittelijoille" - joko katso lokeja silmilläsi ohjauspaneelin kautta tai lataa tiedot itsellesi (useimmat lataavat tiedot kuitenkin . csv-muodossa, ei Excelissä).

Ottamatta huomioon no-logs-vaihtoehtoa, pilvipalveluntarjoajat tarjoavat yleensä kolme vaihtoehtoa tietoturvatapahtumien seurantaan - kojelaudat, tietojen lataus ja API-käyttö. Ensimmäinen näyttää ratkaisevan monia ongelmia puolestasi, mutta tämä ei ole täysin totta - jos sinulla on useita lehtiä, sinun on vaihdettava niitä näyttävien näyttöjen välillä, jolloin kokonaiskuva menettää. Lisäksi pilvipalveluntarjoaja ei todennäköisesti tarjoa sinulle mahdollisuutta korreloida tietoturvatapahtumia ja analysoida niitä yleisesti tietoturvan näkökulmasta (yleensä kyseessä on raakadata, joka sinun on ymmärrettävä itse). Poikkeuksiakin on ja niistä keskustellaan lisää. Lopuksi kannattaa kysyä, mitä tapahtumia pilvipalveluntarjoajasi tallentaa, missä muodossa ja miten ne vastaavat tietoturvan seurantaprosessiasi? Esimerkiksi käyttäjien ja vieraiden tunnistaminen ja todennus. Saman Bitrixin avulla voit tallentaa näiden tapahtumien perusteella tapahtuman päivämäärän ja kellonajan, käyttäjän tai vieraan nimen (jos sinulla on "Web Analytics" -moduuli), käytetyn objektin ja muut verkkosivustolle tyypilliset elementit. . Yritysten tietoturvapalvelut saattavat kuitenkin tarvita tietoa siitä, onko käyttäjä päässyt pilveen luotetusta laitteesta (esimerkiksi yritysverkossa tämän tehtävän toteuttaa Cisco ISE). Entä niin yksinkertainen tehtävä kuin geo-IP-toiminto, joka auttaa määrittämään, onko pilvipalvelun käyttäjätili varastettu? Ja vaikka pilvipalvelu tarjoaisi sen sinulle, tämä ei riitä. Sama Cisco CloudLock ei vain analysoi maantieteellistä sijaintia, vaan käyttää tähän koneoppimista ja analysoi jokaisen käyttäjän historiallisia tietoja ja tarkkailee erilaisia ​​tunnistus- ja todennusyritysten poikkeamia. Vain MS Azurella on samanlaiset toiminnot (jos sinulla on asianmukainen tilaus).

Toinen vaikeus on - koska monille pilvipalveluntarjoajille tietoturvan seuranta on uusi aihe, jonka kanssa he vasta alkavat käsitellä, he muuttavat jatkuvasti jotain ratkaisuissaan. Tänään heillä on yksi API-versio, huomenna toinen, ylihuomenna kolmas. Sinun on myös varauduttava tähän. Sama koskee toiminnallisuutta, joka voi muuttua, mikä on otettava huomioon tietoturvan valvontajärjestelmässäsi. Esimerkiksi Amazonilla oli alun perin erilliset pilvitapahtumien seurantapalvelut – AWS CloudTrail ja AWS CloudWatch. Sitten ilmestyi erillinen palvelu tietoturvatapahtumien seurantaan - AWS GuardDuty. Jonkin ajan kuluttua Amazon lanseerasi uuden hallintajärjestelmän, Amazon Security Hubin, joka sisältää GuardDutylta, Amazon Inspectorilta, Amazon Macieltä ja useilta muilta saatujen tietojen analysoinnin. Toinen esimerkki on Azure-lokin integrointityökalu SIEM:n kanssa – AzLog. Monet SIEM-toimittajat käyttivät sitä aktiivisesti, kunnes vuonna 2018 Microsoft ilmoitti lopettavansa kehittämisen ja tuen, mikä kohtasi monet tätä työkalua käyttäneet asiakkaat ongelman kanssa (puhumme siitä, kuinka se ratkaistiin myöhemmin).

Siksi tarkkaile huolellisesti kaikkia pilvipalveluntarjoajasi tarjoamia valvontaominaisuuksia. Tai luota ulkoisiin ratkaisuntarjoajiin, jotka toimivat välittäjinä SOC:si ja valvottavan pilven välillä. Kyllä, se tulee kalliimmaksi (tosin ei aina), mutta siirrät kaiken vastuun jonkun muun harteille. Vai eikö kaikkea isännöi pilvessä. Ja aloitamme siitä, mitä Amazon tarjoaa tässä osassa.

Esimerkki: Tietoturvan valvonta IaaS:ssä AWS:n perusteella

Kyllä, kyllä, ymmärrän, että Amazon ei ole paras esimerkki, koska tämä on amerikkalainen palvelu ja se voidaan estää osana taistelua ääriliikkeitä vastaan ​​ja Venäjällä kiellettyä tiedon levittämistä. Mutta tässä julkaisussa haluan vain näyttää, miten eri pilvialustojen tietoturvavalvontaominaisuudet eroavat toisistaan ​​ja mihin sinun tulee kiinnittää huomiota siirtäessäsi keskeisiä prosessejasi pilviin tietoturvan näkökulmasta. No, jos jotkut venäläisistä pilviratkaisujen kehittäjistä oppivat jotain hyödyllistä itselleen, se on hienoa.

Ensimmäinen asia on sanoa, että Amazon ei ole läpäisemätön linnoitus. Hänen asiakkailleen sattuu säännöllisesti erilaisia ​​tapauksia. Esimerkiksi 198 miljoonan äänestäjän nimet, osoitteet, syntymäajat ja puhelinnumerot varastettiin Deep Root Analyticsista. Israelilainen Nice Systems varasti 14 miljoonaa tietuetta Verizon-tilaajista. AWS:n sisäänrakennetut ominaisuudet mahdollistavat kuitenkin monenlaisten tapahtumien havaitsemisen. Esimerkiksi:

• vaikutus infrastruktuuriin (DDoS)
• solmun kompromissi (komentoinjektio)
• tilin vaarantuminen ja luvaton käyttö
• virheelliset asetukset ja haavoittuvuudet
• turvattomat käyttöliittymät ja API:t.

Tämä ristiriita johtuu siitä, että kuten edellä totesimme, asiakas on itse vastuussa asiakastietojen turvallisuudesta. Ja jos hän ei vaivautunut kytkemään suojamekanismeja päälle eikä käynnistänyt valvontatyökaluja, hän oppii tapahtumasta vain tiedotusvälineistä tai asiakkaistaan.

Tapahtumien tunnistamiseen voit käyttää laajaa valikoimaa erilaisia ​​Amazonin kehittämiä valvontapalveluita (tosin niitä usein täydennetään ulkoisilla työkaluilla, kuten osquery). Joten AWS:ssä kaikkia käyttäjän toimia valvotaan riippumatta siitä, miten ne suoritetaan - hallintakonsolin, komentorivin, SDK:n tai muiden AWS-palvelujen kautta. Kaikki tietueet kunkin AWS-tilin toiminnasta (mukaan lukien käyttäjänimi, toiminto, palvelu, toimintoparametrit ja tulos) ja API-käyttö ovat saatavilla AWS CloudTrailin kautta. Voit tarkastella näitä tapahtumia (kuten AWS IAM -konsolin kirjautumisia) CloudTrail-konsolista, analysoida niitä Amazon Athenalla tai "ulkoistaa" ne ulkoisille ratkaisuille, kuten Splunk, AlienVault jne. Itse AWS CloudTrail -lokit sijoitetaan AWS S3 -ämpäriisi.

Kaksi muuta AWS-palvelua tarjoavat useita muita tärkeitä valvontaominaisuuksia. Ensinnäkin Amazon CloudWatch on AWS-resurssien ja -sovellusten valvontapalvelu, jonka avulla voit muun muassa tunnistaa erilaisia ​​poikkeamia pilvessäsi. Kaikki sisäänrakennetut AWS-palvelut, kuten Amazon Elastic Compute Cloud (palvelimet), Amazon Relational Database Service (tietokannat), Amazon Elastic MapReduce (tietoanalyysi) ja 30 muuta Amazon-palvelua, käyttävät Amazon CloudWatchia lokien tallentamiseen. Kehittäjät voivat käyttää Amazon CloudWatchin avointa sovellusliittymää lisätäkseen lokinseurantatoimintoja mukautettuihin sovelluksiin ja palveluihin, jolloin he voivat laajentaa tapahtuma-analyysin laajuutta tietoturvaympäristössä.

Toiseksi VPC Flow Logs -palvelun avulla voit analysoida AWS-palvelimiesi (ulkoisesti tai sisäisesti) lähettämää tai vastaanottamaa verkkoliikennettä sekä mikropalvelujen välillä. Kun jokin AWS VPC -resursseistasi on vuorovaikutuksessa verkon kanssa, VPC Flow Logs tallentaa tietoja verkkoliikenteestä, mukaan lukien lähde- ja kohdeverkkorajapinta sekä IP-osoitteet, portit, protokolla, tavujen määrä ja pakettien määrä. näin. Paikallisen verkon turvallisuudesta kokeneet tunnistavat tämän analogiseksi säikeiden kanssa Nettovirta, jotka voidaan luoda kytkimillä, reitittimillä ja yritystason palomuureilla. Nämä lokit ovat tärkeitä tietoturvan seurantaan, koska toisin kuin käyttäjien ja sovellusten toimintaa koskevista tapahtumista, niiden avulla voit myös välttää verkkovuorovaikutuksia AWS:n virtuaalisessa yksityisessä pilviympäristössä.

Yhteenvetona voidaan todeta, että nämä kolme AWS-palvelua – AWS CloudTrail, Amazon CloudWatch ja VPC Flow Logs – tarjoavat yhdessä melko tehokkaan käsityksen tilisi käytöstä, käyttäjien käyttäytymisestä, infrastruktuurin hallinnasta, sovellus- ja palvelutoiminnasta sekä verkkotoiminnasta. Niitä voidaan käyttää esimerkiksi seuraavien poikkeamien havaitsemiseen:

• Yritykset skannata sivusto, etsiä takaovia, etsiä haavoittuvuuksia "404-virheiden" purskeilla.
• Injektiohyökkäykset (esimerkiksi SQL-injektio) "500 virheen" purskeilla.
• Tunnettuja hyökkäystyökaluja ovat sqlmap, nikto, w3af, nmap jne. User Agent -kentän analysoinnin kautta.

Amazon Web Services on myös kehittänyt muita kyberturvallisuuspalveluita, joiden avulla voit ratkaista monia muita ongelmia. Esimerkiksi AWS:ssä on sisäänrakennettu palvelu käytäntöjen ja kokoonpanojen tarkastamiseen - AWS Config. Tämä palvelu tarjoaa jatkuvan AWS-resurssien ja niiden kokoonpanojen tarkastuksen. Otetaan yksinkertainen esimerkki: Oletetaan, että haluat varmistaa, että käyttäjien salasanat on poistettu käytöstä kaikilla palvelimillasi ja että pääsy on mahdollista vain varmenteiden perusteella. AWS Config tekee tämän tarkistamisen helpoksi kaikille palvelimillesi. Pilvipalvelimillesi voidaan soveltaa muitakin käytäntöjä: "Mikään palvelin ei voi käyttää porttia 22", "Vain järjestelmänvalvojat voivat muuttaa palomuurin sääntöjä" tai "Vain käyttäjä Ivashko voi luoda uusia käyttäjätilejä, ja hän voi tehdä Se on vain tiistaisin. " Kesällä 2016 AWS Config -palvelua laajennettiin automatisoimaan kehitettyjen käytäntöjen rikkomusten havaitseminen. AWS Config Rules ovat pohjimmiltaan jatkuvia määrityspyyntöjä käyttämillesi Amazon-palveluille, jotka luovat tapahtumia, jos vastaavia käytäntöjä rikotaan. Esimerkiksi sen sijaan, että suoritettaisiin säännöllisin väliajoin AWS Config -kyselyitä varmistaakseen, että kaikki virtuaalipalvelimen levyt ovat salattuja, AWS Config Rules -sääntöjä voidaan käyttää palvelimen levyjen jatkuvaan tarkistamiseen sen varmistamiseksi, että tämä ehto täyttyy. Ja mikä tärkeintä, tämän julkaisun yhteydessä kaikki rikkomukset synnyttävät tapahtumia, jotka tietoturvapalvelusi voi analysoida.

AWS:llä on myös vastineensa perinteisille yritysten tietoturvaratkaisuille, jotka myös luovat tietoturvatapahtumia, joita voit ja kannattaa analysoida:

• Tunkeutumisen tunnistus - AWS GuardDuty
• Tietovuotojen valvonta - AWS Macie
• EDR (vaikka se puhuu pilven päätepisteistä hieman oudosti) - AWS Cloudwatch + avoimen lähdekoodin osquery tai GRR-ratkaisut
• Netflow-analyysi - AWS Cloudwatch + AWS VPC Flow
• DNS-analyysi - AWS Cloudwatch + AWS Route53
• AD - AWS-hakemistopalvelu
• Tilinhallinta - AWS IAM
• SSO - AWS SSO
• turvallisuusanalyysi - AWS Inspector
• kokoonpanon hallinta - AWS Config
• WAF - AWS WAF.

En kuvaile yksityiskohtaisesti kaikkia Amazon-palveluita, jotka voivat olla hyödyllisiä tietoturvan kannalta. Tärkeintä on ymmärtää, että ne kaikki voivat generoida tapahtumia, joita voimme ja meidän tulee analysoida tietoturvan kontekstissa käyttämällä tähän tarkoitukseen sekä Amazonin itsensä sisäänrakennettuja ominaisuuksia että ulkoisia ratkaisuja, esimerkiksi SIEM:ää, joka voi vie tietoturvatapahtumat valvontakeskukseesi ja analysoi ne siellä yhdessä muiden pilvipalveluiden tai sisäisen infrastruktuurin, kehä- tai mobiililaitteiden tapahtumien kanssa.

Joka tapauksessa kaikki alkaa tietolähteistä, jotka tarjoavat sinulle tietoturvatapahtumia. Näitä lähteitä ovat muun muassa:

• CloudTrail – API-käyttö ja käyttäjän toimet
• Trusted Advisor – turvatarkastus parhaiden käytäntöjen mukaan
• Config - tilien ja palveluasetusten inventointi ja konfigurointi
• VPC Flow Logs - yhteydet virtuaalisiin rajapintoihin
• IAM - tunnistus- ja todennuspalvelu
• ELB Access Logs - Kuormituksen tasauslaite
• Inspector - sovelluksen haavoittuvuudet
• S3 - tiedostojen tallennus
• CloudWatch – Sovellustoiminta
• SNS on ilmoituspalvelu.

Vaikka Amazon tarjoaakin tällaisen valikoiman tapahtumalähteitä ja työkaluja niiden luomiseen, sen kyky analysoida kerättyä dataa tietoturvan yhteydessä on hyvin rajallinen. Sinun on tutkittava itsenäisesti saatavilla olevat lokit ja etsittävä niistä asiaankuuluvia kompromissin osoittimia. Amazonin äskettäin lanseeraama AWS Security Hub pyrkii ratkaisemaan tämän ongelman muuttumalla pilvi-SIEMiksi AWS:lle. Mutta toistaiseksi se on vasta matkansa alussa, ja sitä rajoittavat sekä lähteiden lukumäärä, joiden kanssa se toimii, että muut Amazonin itsensä arkkitehtuurin ja tilausten asettamat rajoitukset.

Esimerkki: Tietoturvan valvonta IaaS:ssä Azureen perustuvassa

En halua käydä pitkää keskustelua siitä, kumpi kolmesta pilvipalveluntarjoajasta (Amazon, Microsoft vai Google) on parempi (varsinkin kun jokaisella niistä on edelleen omat erityispiirteensä ja ne sopivat omien ongelmiensa ratkaisemiseen); Keskitytään näiden pelaajien tarjoamiin tietoturvavalvontaominaisuuksiin. On myönnettävä, että Amazon AWS oli yksi ensimmäisistä tässä segmentissä ja on siksi edistynyt pisimmälle tietoturvatoimintojensa suhteen (vaikka monet myöntävät, että niitä on vaikea käyttää). Tämä ei kuitenkaan tarkoita, että jättäisimme huomiotta Microsoftin ja Googlen meille tarjoamat mahdollisuudet.

Microsoftin tuotteet ovat aina eronneet "avoimuudestaan" ja Azuressa tilanne on samanlainen. Jos esimerkiksi AWS ja GCP lähtevät aina käsitteestä "mikä ei ole sallittua, on kiellettyä", Azurella on täysin päinvastainen lähestymistapa. Esimerkiksi luotaessa virtuaaliverkkoa pilveen ja virtuaalikoneen siihen, kaikki portit ja protokollat ​​ovat avoinna ja oletuksena sallittuja. Siksi sinun on käytettävä hieman enemmän vaivaa Microsoftin pilvessä olevan kulunvalvontajärjestelmän alkuasennukseen. Tämä asettaa sinulle myös tiukempia vaatimuksia Azure-pilven toiminnan seurantaan.

AWS:llä on erityispiirre, joka liittyy siihen, että kun seuraat virtuaalisia resurssejasi, jos ne sijaitsevat eri alueilla, sinulla on vaikeuksia yhdistää kaikki tapahtumat ja niiden yhtenäinen analyysi, jonka poistamiseksi sinun on turvauduttava erilaisiin temppuihin, kuten esim. Luo oma koodi AWS Lambdalle, joka siirtää tapahtumia alueiden välillä. Azurella ei ole tätä ongelmaa – sen Activity Log -mekanismi seuraa kaikkea toimintaa koko organisaatiossa ilman rajoituksia. Sama pätee AWS Security Hubiin, jonka Amazon on äskettäin kehittänyt yhdistämään useita tietoturvatoimintoja yhteen tietoturvakeskukseen, mutta vain sen alueelle, mikä ei kuitenkaan ole Venäjän kannalta oleellista. Azurella on oma tietoturvakeskus, jota alueelliset rajoitukset eivät sido ja joka tarjoaa pääsyn kaikkiin pilvialustan suojausominaisuuksiin. Lisäksi se voi tarjota eri paikallisille tiimeille omia suojaominaisuuksia, mukaan lukien niiden hallinnoimat tietoturvatapahtumat. AWS Security Hub on edelleen tulossa samanlaiseksi kuin Azure Security Center. Mutta se kannattaa lisätä - voit puristaa Azuresta paljon sitä, mitä aiemmin on kuvattu AWS:ssä, mutta tämä on kätevintä tehdä vain Azure AD:lle, Azure Monitorille ja Azure Security Centerille. Kaikkia muita Azure-suojausmekanismeja, mukaan lukien tietoturvatapahtuma-analyysi, ei vielä hallita kätevimmällä tavalla. Ongelma on osittain ratkaistu API:lla, joka läpäisee kaikki Microsoft Azure -palvelut, mutta tämä vaatii sinulta lisäponnisteluja pilvesi integroimiseksi SOC:si kanssa ja pätevien asiantuntijoiden läsnäoloa (itse asiassa, kuten minkä tahansa muun pilven kanssa toimivan SIEM:n kanssa API:t). Jotkut SIEM:istä, joista keskustellaan myöhemmin, tukevat jo Azurea ja voivat automatisoida sen valvonnan, mutta sillä on myös omat vaikeutensa - kaikki eivät pysty keräämään kaikkia Azurella olevia lokeja.

Tapahtumien kerääminen ja seuranta Azuressa tarjotaan käyttämällä Azure Monitor -palvelua, joka on tärkein työkalu tietojen keräämiseen, tallentamiseen ja analysointiin Microsoft-pilvessä ja sen resursseissa - Git-arkistot, säilöt, virtuaalikoneet, sovellukset jne. Kaikki Azure Monitorin keräämät tiedot on jaettu kahteen luokkaan – reaaliajassa kerättyihin mittareihin, jotka kuvaavat Azure-pilven keskeisiä suorituskykyindikaattoreita, sekä lokeihin, jotka sisältävät tietueiksi järjestettyjä tietoja, jotka kuvaavat tiettyjä Azure-resurssien ja -palveluiden toimintaa. Lisäksi Data Collector API:n avulla Azure Monitor -palvelu voi kerätä tietoja mistä tahansa REST-lähteestä omien valvontaskenaarioidensa luomiseksi.

Tässä on muutamia tietoturvatapahtumalähteitä, joita Azure tarjoaa sinulle ja joita voit käyttää Azure Portalin, CLI:n, PowerShellin tai REST API:n kautta (ja joihinkin vain Azure Monitor/Insight API:n kautta):

• Toimintalokit – tämä loki vastaa klassisiin kysymyksiin "kuka", "mitä" ja "milloin" koskien mitä tahansa pilviresurssien kirjoitustoimintoa (PUT, POST, DELETE). Lukuoikeuksiin (GET) liittyvät tapahtumat eivät sisälly tähän lokiin, kuten monet muut.
• Diagnostiset lokit - sisältävät tietoja toiminnoista tietyn tilauksesi sisältämän resurssin kanssa.
• Azure AD -raportointi – sisältää sekä käyttäjien että ryhmien ja käyttäjien hallintaan liittyvän järjestelmätoiminnan.
• Windows Event Log ja Linux Syslog – sisältävät tapahtumia pilvessä isännöidyistä virtuaalikoneen.
• Mittarit – sisältää telemetriaa pilvipalveluidesi ja -resurssien suorituskyvystä ja terveydentilasta. Mitattu minuutin välein ja tallennettu. 30 päivän sisällä.
• Network Security Group Flow Logs - sisältää tietoja verkon tietoturvatapahtumista, jotka on kerätty käyttämällä Network Watcher -palvelua ja resurssien valvontaa verkkotasolla.
• Storage Logs - sisältää tapahtumia, jotka liittyvät varastotiloihin pääsyyn.

Valvontaan voit käyttää ulkoisia SIEMejä tai sisäänrakennettua Azure Monitoria ja sen laajennuksia. Puhumme tietoturvatapahtumien hallintajärjestelmistä myöhemmin, mutta katsotaan nyt, mitä Azure itse tarjoaa meille tietoturvan analysointiin. Kaiken tietoturvaan liittyvän päänäyttö Azure Monitorissa on Log Analyticsin suojauksen ja tarkastuksen hallintapaneeli (ilmainen versio tukee rajoitettua määrää tapahtumatallennustilaa vain yhden viikon ajan). Tämä hallintapaneeli on jaettu viiteen pääalueeseen, jotka visualisoivat yhteenvetotilastoja käyttämäsi pilviympäristön tapahtumista:

• Security Domains - keskeiset tietoturvaan liittyvät kvantitatiiviset indikaattorit - tapausten määrä, vaarantuneiden solmujen määrä, korjaamattomat solmut, verkon tietoturvatapahtumat jne.
• Huomattavat ongelmat - näyttää aktiivisten tietoturvaongelmien määrän ja tärkeyden
• Havainnot – näyttää sinua vastaan ​​käytettyjen hyökkäysten mallit
• Threat Intelligence - näyttää maantieteelliset tiedot ulkoisista solmuista, jotka hyökkäävät sinua vastaan
• Yleiset tietoturvakyselyt – tyypilliset kyselyt, joiden avulla voit valvoa paremmin tietoturvaasi.

Azure Monitor -laajennukset sisältävät Azure Key Vaultin (salausavaimien suojaaminen pilvessä), Malware Assessmentin (virtuaalikoneiden haitallisen koodin suojauksen analyysi), Azure Application Gateway Analyticsin (muun muassa pilvipalomuurin lokien analyysi) jne. . Nämä työkalut, jotka on rikastettu tietyillä tapahtumien käsittelysäännöillä, mahdollistavat pilvipalvelujen toiminnan eri näkökohtien visualisoinnin, mukaan lukien tietoturvan, sekä tiettyjen toiminnasta poikkeamien tunnistamisen. Mutta kuten usein tapahtuu, kaikki lisätoiminnot vaativat vastaavan maksullisen tilauksen, joka vaatii sinulta vastaavia taloudellisia investointeja, jotka sinun on suunniteltava etukäteen.

Azuressa on useita sisäänrakennettuja uhkien valvontaominaisuuksia, jotka on integroitu Azure AD:hen, Azure Monitoriin ja Azure Security Centeriin. Näitä ovat esimerkiksi virtuaalikoneiden vuorovaikutuksen havaitseminen tunnettujen haitallisten IP-osoitteiden kanssa (johtuen integraatiosta Microsoftin Threat Intelligence -palveluiden kanssa), haittaohjelmien havaitseminen pilviinfrastruktuurissa vastaanottamalla hälytyksiä pilvessä isännöidyiltä virtuaalikoneita, salasana arvaushyökkäykset ” virtuaalikoneita vastaan, haavoittuvuudet käyttäjien tunnistusjärjestelmän kokoonpanossa, kirjautuminen järjestelmään anonymisoijista tai tartunnan saaneista solmuista, tilivuodot, kirjautuminen järjestelmään epätavallisista paikoista jne. Azure on nykyään yksi harvoista pilvipalveluntarjoajista, joka tarjoaa sinulle sisäänrakennettuja Threat Intelligence -ominaisuuksia kerättyjen tietoturvatapahtumien rikastamiseksi.

Kuten edellä mainittiin, tietoturvatoiminnallisuus ja siitä johtuen sen generoimat tietoturvatapahtumat eivät ole tasapuolisesti kaikkien käyttäjien ulottuvilla, vaan vaativat tietyn liittymän, joka sisältää tarvitsemasi toiminnallisuuden, joka generoi tietoturvan valvontaan sopivat tapahtumat. Esimerkiksi jotkin edellisessä kappaleessa kuvatuista toiminnoista tilien poikkeavuuksien seurantaan ovat käytettävissä vain Azure AD -palvelun P2 premium -lisenssissä. Ilman sitä sinun, kuten AWS:n tapauksessa, on analysoitava kerätyt tietoturvatapahtumat "manuaalisesti". Ja myös Azure AD -lisenssin tyypistä riippuen kaikki tapahtumat eivät ole käytettävissä analysoitavaksi.

Azure-portaalissa voit hallita sekä sinua kiinnostavien lokien hakukyselyitä että määrittää koontinäyttöjä tärkeimpien tietoturva-indikaattoreiden visualisoimiseksi. Lisäksi sieltä voit valita Azure Monitor -laajennuksia, joiden avulla voit laajentaa Azure Monitor -lokien toimivuutta ja saada syvemmän analyysin tapahtumista tietoturvan näkökulmasta.

Jos tarvitset lokien työskentelyn lisäksi kattavan suojauskeskuksen Azure-pilvialustaan, mukaan lukien tietoturvakäytäntöjen hallinta, voit puhua tarpeesta työskennellä Azure Security Centerin kanssa, jonka useimmat hyödylliset toiminnot ovat saatavilla rahalla, esimerkiksi uhkien havaitsemiseen, Azuren ulkopuoliseen valvontaan, vaatimustenmukaisuuden arviointiin jne. (ilmaisessa versiossa sinulla on pääsy vain tietoturvaarvioon ja suosituksiin havaittujen ongelmien poistamiseksi). Se yhdistää kaikki tietoturvakysymykset yhteen paikkaan. Itse asiassa voimme puhua korkeammasta tietoturvasta kuin Azure Monitor tarjoaa sinulle, koska tässä tapauksessa pilvitehtaallasi kerättyä dataa täydennetään useilla lähteillä, kuten Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) ja Microsoft Security Response Center (MSRC), joiden päälle on sijoitettu erilaisia ​​kehittyneitä koneoppimis- ja käyttäytymisanalytiikkaalgoritmeja, joiden pitäisi viime kädessä parantaa uhkien havaitsemisen ja niihin reagoimisen tehokkuutta. .

Azurella on myös oma SIEM - se ilmestyi vuoden 2019 alussa. Tämä on Azure Sentinel, joka perustuu Azure Monitorin tietoihin ja joka voidaan myös integroida. ulkoisia turvaratkaisuja (esim. NGFW tai WAF), joiden luettelo kasvaa jatkuvasti. Lisäksi Microsoft Graph Security API:n integroinnin ansiosta sinulla on mahdollisuus yhdistää omat Threat Intelligence -syötteet Sentineliin, mikä rikastuttaa kykyjä analysoida Azure-pilvisi tapahtumia. Voidaan väittää, että Azure Sentinel on ensimmäinen "natiivi" SIEM, joka ilmestyi pilvipalveluntarjoajilta (sama Splunk tai ELK, jota voidaan isännöidä pilvessä, esimerkiksi AWS, eivät ole vieläkään perinteisen pilvipalveluntarjoajan kehittämiä). Azure Sentinel and Security Center voisi olla nimeltään SOC Azure-pilvelle ja se voidaan rajoittaa niihin (tietyillä varauksilla), jos sinulla ei enää olisi infrastruktuuria ja siirsit kaikki laskentaresurssit pilveen, jolloin se olisi Microsoftin Azure-pilvi.

Mutta koska Azuren sisäänrakennetut ominaisuudet (vaikka sinulla olisi Sentinel-tilaus) eivät useinkaan riitä tietoturvan valvontaan ja tämän prosessin integroimiseen muihin tietoturvatapahtumien lähteisiin (sekä pilveen että sisäisiin), on olemassa täytyy viedä kerätyt tiedot ulkoisiin järjestelmiin, joihin voi sisältyä SIEM. Tämä tehdään sekä API:lla että erikoislaajennuksilla, jotka ovat tällä hetkellä virallisesti saatavilla vain seuraaville SIEM:ille - Splunk (Azure Monitor -lisäosa Splunkille), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ja ELK. Viime aikoihin asti tällaisia ​​SIEM-malleja oli enemmän, mutta 1. kesäkuuta 2019 alkaen Microsoft lopetti Azure Log Integration Toolin (AzLog) tuen, joka Azuren olemassaolon kynnyksellä ja normaalin lokien kanssa työskentelyn standardoinnin puuttuessa (Azure) Monitoria ei edes ollut vielä olemassa) teki helpoksi integroida ulkoinen SIEM Microsoftin pilveen. Nyt tilanne on muuttunut ja Microsoft suosittelee Azure Event Hub -alustaa tärkeimmäksi integrointityökaluksi muille SIEM:eille. Monet ovat jo ottaneet käyttöön tällaisen integroinnin, mutta ole varovainen - ne eivät välttämättä tallenna kaikkia Azure-lokeja, vaan vain joitakin (katso SIEM-tietosi dokumentaatiosta).

Lyhyen Azure-retken päätteeksi haluaisin antaa yleisen suosituksen tästä pilvipalvelusta - ennen kuin sanot mitään Azuren tietoturvallisuuden valvontatoiminnoista, sinun on määritettävä ne erittäin huolellisesti ja testattava, että ne toimivat dokumentaatiossa kirjoitetulla tavalla ja kuten konsultit kertoivat Microsoftille (ja heillä voi olla erilaisia ​​näkemyksiä Azure-toimintojen toimivuudesta). Jos sinulla on taloudellisia resursseja, voit puristaa Azuresta paljon hyödyllistä tietoa tietoturvan valvonnan kannalta. Jos resurssit ovat rajalliset, sinun on, kuten AWS:n tapauksessa, luotettava vain omiin voimiisi ja Azure Monitorin tarjoamiin raakatietoihin. Ja muista, että monet valvontatoiminnot maksavat rahaa ja on parempi tutustua hinnoittelupolitiikkaan etukäteen. Voit esimerkiksi tallentaa ilmaiseksi 31 päivää dataa korkeintaan 5 Gt asiakasta kohti - näiden arvojen ylittäminen edellyttää lisärahoitusta (noin $ 2+ jokaisen lisäGB:n tallentamisesta asiakkaalta ja 0,1 $ tallentaa 1 Gt jokaista lisäkuukautta). Sovelluksen telemetrian ja mittareiden työskentely voi myös vaatia lisärahoitusta, samoin kuin hälytyksiä ja ilmoituksia käsitteleminen (tietty raja on saatavilla ilmaiseksi, mikä ei välttämättä riitä tarpeisiisi).

Esimerkki: Tietoturvan valvonta IaaS:ssä Google Cloud Platformin pohjalta

Google Cloud Platform näyttää nuorelta AWS:ään ja Azureen verrattuna, mutta tämä on osittain hyvä. Toisin kuin AWS, joka lisäsi kykyjään, mukaan lukien tietoturvaominaisuudet, vähitellen, ja sillä oli keskittämisongelmia; GCP, kuten Azure, on paljon paremmin hallittavissa keskitetysti, mikä vähentää virheitä ja käyttöönottoaikaa koko yrityksessä. Turvallisuuden näkökulmasta GCP on kummallista kyllä ​​AWS:n ja Azuren välissä. Hänellä on myös yksi tapahtuma-ilmoittautuminen koko organisaatiolle, mutta se on puutteellinen. Jotkut toiminnot ovat vielä beta-tilassa, mutta asteittain tämä puute pitäisi poistaa ja GCP:stä tulee kypsempi alusta tietoturvavalvonnan kannalta.

Päätyökalu tapahtumien kirjaamiseen GCP:ssä on Stackdriver Logging (samanlainen kuin Azure Monitor), jonka avulla voit kerätä tapahtumia koko pilviinfrastruktuuristasi (sekä AWS:stä). GCP:n turvallisuusnäkökulmasta jokaisessa organisaatiossa, projektissa tai kansiossa on neljä lokia:

• Admin Activity - sisältää kaikki järjestelmänvalvojan käyttöoikeuksiin liittyvät tapahtumat, kuten virtuaalikoneen luominen, käyttöoikeuksien muuttaminen jne. Tämä loki kirjoitetaan aina halustasi riippumatta, ja sen tiedot säilytetään 400 päivän ajan.
• Data Access - sisältää kaikki tapahtumat, jotka liittyvät pilvikäyttäjien tietojen käsittelyyn (luominen, muokkaaminen, lukeminen jne.). Oletuksena tätä lokia ei kirjoiteta, koska sen määrä turpoaa hyvin nopeasti. Tästä syystä sen säilyvyys on vain 30 päivää. Lisäksi kaikkea ei ole kirjoitettu tässä lehdessä. Esimerkiksi tapahtumia, jotka liittyvät resursseihin, jotka ovat julkisesti kaikkien käyttäjien käytettävissä tai jotka ovat käytettävissä ilman kirjautumista GCP:hen, eivät kirjoita siihen.
• Järjestelmätapahtuma - sisältää järjestelmätapahtumia, jotka eivät liity käyttäjiin tai pilviresurssien määritystä muuttavan järjestelmänvalvojan toimiin. Se kirjoitetaan aina ja säilytetään 400 päivää.
• Access Transparency on ainutlaatuinen esimerkki lokista, joka tallentaa kaikki Googlen työntekijöiden toimet (mutta ei vielä kaikkien GCP-palvelujen osalta), jotka käyttävät infrastruktuuriasi osana työtehtäviään. Tämä loki säilytetään 400 päivää, eikä se ole kaikkien GCP-asiakkaiden käytettävissä, mutta vain, jos tietyt ehdot täyttyvät (joko kulta- tai platinatason tuki tai 4 tietyn tyyppistä roolia osana yritystukea). Vastaava toiminto on saatavilla myös esimerkiksi Office 365 - Lockboxissa.

Lokiesimerkki: Access Transparency

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

Pääsy näihin lokeihin on mahdollista useilla tavoilla (samalla tavalla kuin aiemmin käsitellyt Azure ja AWS) - Log Viewer -käyttöliittymän kautta, API:n kautta, Google Cloud SDK:n kautta tai projektisi Toiminta-sivun kautta. ovat kiinnostuneita tapahtumista. Samalla tavalla ne voidaan viedä ulkoisiin ratkaisuihin lisäanalyysiä varten. Jälkimmäinen tehdään viemällä lokit BigQuery- tai Cloud Pub/Sub -tallennustilaan.

Stackdriver Loggingin lisäksi GCP-alusta tarjoaa myös Stackdriver Monitoring -toiminnon, jonka avulla voit seurata pilvipalvelujen ja -sovellusten keskeisiä mittareita (suorituskyky, MTBF, yleinen kunto jne.). Käsitellyt ja visualisoidut tiedot voivat helpottaa pilviinfrastruktuurin ongelmien löytämistä, myös tietoturvan yhteydessä. Mutta on huomattava, että tämä toiminto ei ole kovin rikas tietoturvan kontekstissa, koska GCP:llä ei nykyään ole saman AWS GuardDutyn analogia eikä se pysty tunnistamaan huonoja kaikista rekisteröidyistä tapahtumista (Google on kehittänyt Event Threat Detection, mutta se on vielä kehitteillä beta-vaiheessa, ja on liian aikaista puhua sen hyödyllisyydestä). Stackdriver Monitoringia voitaisiin käyttää järjestelmänä poikkeamien havaitsemiseen, jota sitten tutkittaisiin niiden esiintymisen syiden selvittämiseksi. Mutta koska markkinoilla ei ole GCP-tietoturvan alalla pätevää henkilöstöä, tämä tehtävä näyttää tällä hetkellä vaikealta.

On myös syytä antaa luettelo tietoturvamoduuleista, joita voidaan käyttää GCP-pilvessäsi ja jotka ovat samanlaisia ​​kuin AWS:n tarjoamat:

• Cloud Security Command Center on analoginen AWS Security Hubille ja Azure Security Centerille.
• Pilvi-DLP – Pilvessä isännöidyn datan automaattinen etsintä ja muokkaaminen (esim. peittäminen) yli 90 ennalta määritetyn luokituskäytännön avulla.
• Cloud Scanner on tunnettujen haavoittuvuuksien (XSS, Flash Injection, korjaamattomat kirjastot jne.) etsijä App Enginessä, Compute Enginessä ja Google Kubernetesissa.
• Cloud IAM - Hallitse pääsyä kaikkiin GCP-resursseihin.
• Cloud Identity - Hallitse GCP-käyttäjien, laite- ja sovellustilejä yhdestä konsolista.
• Cloud HSM - salausavainten suojaus.
• Cloud Key Management Service - salausavainten hallinta GCP:ssä.
• VPC-palvelunhallinta – Luo suojattu kehys GCP-resurssien ympärille suojaamaan niitä vuodoilta.
• Titan Security Key - suojaus tietojenkalastelulta.

Monet näistä moduuleista luovat tietoturvatapahtumia, jotka voidaan lähettää BigQuery-tallennustilaan analysoitavaksi tai viedä muihin järjestelmiin, mukaan lukien SIEM. Kuten edellä mainittiin, GCP on aktiivisesti kehittyvä alusta, ja Google kehittää nyt useita uusia tietoturvamoduuleja alustaansa. Niitä ovat Event Threat Detection (saatavilla nyt betaversiossa), joka skannaa Stackdriver-lokeja ja etsii jälkiä luvattomasta toiminnasta (AWS:n GuardDutyn tapaan) tai Policy Intelligence (saatavilla alfaversiossa), jonka avulla voit kehittää älykkäitä käytäntöjä pääsy GCP-resursseihin.

Tein lyhyen yleiskatsauksen suosittujen pilvialustojen sisäänrakennetuista valvontamahdollisuuksista. Mutta onko sinulla asiantuntijoita, jotka pystyvät työskentelemään "raaka" IaaS-palveluntarjoajan lokien kanssa (kaikki eivät ole valmiita ostamaan AWS:n tai Azuren tai Googlen edistyneitä ominaisuuksia)? Lisäksi monet tuntevat sanonnan "luota, mutta varmista", joka on totta kuin koskaan turvallisuusalalla. Kuinka paljon luotat tietoturvatapahtumia lähettävän pilvipalvelun tarjoajan sisäänrakennettuun kykyyn? Kuinka paljon he ylipäätään keskittyvät tietoturvaan?

Joskus kannattaa tarkastella peittopilviinfrastruktuurin valvontaratkaisuja, jotka voivat täydentää sisäänrakennettua pilviturvallisuutta, ja joskus tällaiset ratkaisut ovat ainoa vaihtoehto saada käsitys pilvessä isännöityjen tietojesi ja sovellusten turvallisuudesta. Lisäksi ne ovat yksinkertaisesti kätevämpiä, koska ne ottavat kaikki tehtävät eri pilvipalvelujen tarjoajien eri pilvipalvelujen tuottamien tarvittavien lokien analysoinnissa. Esimerkki tällaisesta peittoratkaisusta on Cisco Stealthwatch Cloud, joka keskittyy yhteen tehtävään - pilviympäristöjen tietoturvapoikkeamien seurantaan, mukaan lukien Amazon AWS:n, Microsoft Azuren ja Google Cloud Platformin lisäksi myös yksityiset pilvet.

Esimerkki: Tietoturvan seuranta Stealthwatch Cloudin avulla

AWS tarjoaa joustavan laskenta-alustan, mutta tämä joustavuus helpottaa yritysten virheiden tekemistä, jotka johtavat tietoturvaongelmiin. Ja yhteinen tietoturvamalli vain edistää tätä. Pilvessä ajettavat ohjelmistot, joissa on tuntemattomia haavoittuvuuksia (tunnettuja voi torjua esim. AWS Inspectorilla tai GCP Cloud Scannerilla), heikkoja salasanoja, virheellisiä kokoonpanoja, sisäpiiriläisiä jne. Ja kaikki tämä heijastuu pilviresurssien käyttäytymiseen, jota voidaan valvoa Cisco Stealthwatch Cloudilla, joka on tietoturvan valvonta- ja hyökkäysten havaitsemisjärjestelmä. julkiset ja yksityiset pilvet.

Yksi Cisco Stealthwatch Cloudin tärkeimmistä ominaisuuksista on kyky mallintaa kokonaisuuksia. Sen avulla voit luoda ohjelmistomallin (eli lähes reaaliaikaisen simulaation) jokaisesta pilviresurssistasi (ei väliä onko kyseessä AWS, Azure, GCP vai jokin muu). Näitä voivat olla palvelimia ja käyttäjiä sekä pilviympäristöllesi ominaisia ​​resurssityyppejä, kuten suojausryhmiä ja automaattisen skaalauksen ryhmiä. Nämä mallit käyttävät syötteenä pilvipalvelujen tarjoamia strukturoituja tietovirtoja. Esimerkiksi AWS:lle nämä olisivat VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ja AWS IAM. Entiteettimallinnus löytää automaattisesti minkä tahansa resurssi roolin ja käyttäytymisen (voit puhua kaiken pilvitoiminnan profiloinnista). Näitä rooleja ovat Android- tai Apple-mobiililaite, Citrix PVS -palvelin, RDP-palvelin, sähköpostiyhdyskäytävä, VoIP-asiakas, päätepalvelin, verkkotunnuksen ohjain jne. Sen jälkeen se seuraa jatkuvasti heidän käyttäytymistään määrittääkseen, milloin riskialtista tai turvallisuutta uhkaavaa käyttäytymistä esiintyy. Voit tunnistaa salasanan arvailut, DDoS-hyökkäykset, tietovuodot, laittomat etäkäytöt, haittakooditoiminnan, haavoittuvuustarkistukset ja muut uhat. Esimerkiksi tältä näyttää etäkäyttöyrityksen havaitseminen organisaatiollesi epätyypillisestä maasta (Etelä-Korea) Kubernetes-klusteriin SSH:n kautta:

Ja tältä näyttää väitetty tiedon vuotaminen Postgress-tietokannasta maahan, jonka kanssa emme ole aiemmin kohdanneet vuorovaikutusta:

Lopuksi, tältä näyttää liian monet epäonnistuneet SSH-yritykset Kiinasta ja Indonesiasta ulkoisesta etälaitteesta:

Tai oletetaan, että VPC:n palvelinesiintymä ei ole käytännön mukaan koskaan etäkirjautumiskohde. Oletetaan edelleen, että tämä tietokone koki etäkirjautumisen palomuurin sääntöjen virheellisen muutoksen vuoksi. Entity Modeling -ominaisuus havaitsee ja raportoi tämän toiminnan ("Epätavallinen etäkäyttö") lähes reaaliajassa ja osoittaa tiettyyn AWS CloudTrail-, Azure Monitor- tai GCP Stackdriver Logging API -kutsuun (mukaan lukien käyttäjänimi, päivämäärä ja aika, muun muassa ). Ja sitten nämä tiedot voidaan lähettää SIEMille analysoitavaksi.

Samanlaisia ​​ominaisuuksia on toteutettu kaikissa Cisco Stealthwatch Cloudin tukemissa pilviympäristöissä:

Kokonaisuusmallinnus on ainutlaatuinen tietoturvaautomaation muoto, joka voi paljastaa aiemmin tuntemattoman ongelman henkilöissäsi, prosesseissasi tai teknologiassasi. Sen avulla voit esimerkiksi havaita muun muassa tietoturvaongelmia, kuten:

• Onko joku löytänyt käyttämämme ohjelmiston takaoven?
• Onko pilvessämme kolmannen osapuolen ohjelmistoja tai laitteita?
• Käyttääkö valtuutettu käyttäjä oikeuksia väärin?
• Oliko määritysvirhe, joka salli etäkäytön tai muun tahattoman resurssien käytön?
• Onko tietovuoto palvelimiltamme?
• Yrittikö joku ottaa meihin yhteyttä epätyypillisestä maantieteellisestä sijainnista?
• Onko pilvessämme haitallinen koodi?

Havaittu tietoturvatapahtuma voidaan lähettää vastaavan lipun muodossa Slackiin, Cisco Sparkiin, PagerDuty-tapahtumanhallintajärjestelmään sekä lähettää myös erilaisille SIEMeille, mukaan lukien Splunk tai ELK. Yhteenvetona voidaan todeta, että jos yrityksesi käyttää usean pilven strategiaa eikä rajoitu mihinkään yhteen pilvipalveluntarjoajaan, yllä kuvatut tietoturvan seurantaominaisuudet, Cisco Stealthwatch Cloudin käyttö on hyvä vaihtoehto saada yhtenäinen seurantasarja. ominaisuudet johtaville pilvipelaajille - Amazonille, Microsoftille ja Googlelle. Mielenkiintoisin asia on, että jos vertaa Stealthwatch Cloudin hintoja edistyneisiin AWS:n, Azuren tai GCP:n tietoturvavalvonnan lisensseihin, voi käydä ilmi, että Cisco-ratkaisu on jopa halvempi kuin Amazonin, Microsoftin sisäänrakennetut ominaisuudet. ja Googlen ratkaisut. Se on paradoksaalista, mutta se on totta. Ja mitä enemmän pilviä ja niiden ominaisuuksia käytät, sitä selvempi on konsolidoidun ratkaisun etu.

Lisäksi Stealthwatch Cloud voi valvoa organisaatiossasi käyttöön otettuja yksityisiä pilviä, esimerkiksi Kubernetes-säilöihin perustuen tai tarkkailemalla Netflow-virtoja tai verkkoliikennettä, joka on vastaanotettu peilauksen kautta verkkolaitteissa (jopa kotimaisesti tuotetuissa), AD-data- tai DNS-palvelimissa ja niin edelleen. Kaikki tämä tieto rikastetaan Threat Intelligence -tiedolla, jonka on kerännyt Cisco Talos, maailman suurin kansalaisjärjestö kyberturvallisuusuhkien tutkijaryhmä.

Näin voit toteuttaa yhtenäisen seurantajärjestelmän sekä julkisille että hybridipilville, joita yrityksesi saattaa käyttää. Kerätyt tiedot voidaan sitten analysoida Stealthwatch Cloudin sisäänrakennetuilla ominaisuuksilla tai lähettää SIEM-järjestelmääsi (Splunk, ELK, SumoLogic ja monet muut ovat oletuksena tuettuja).

Tällä täydennämme artikkelin ensimmäisen osan, jossa käyn läpi IaaS/PaaS-alustojen tietoturvan valvontaan tarkoitettuja sisäänrakennettuja ja ulkoisia työkaluja, joiden avulla voimme nopeasti havaita pilviympäristöissä tapahtuvat tapahtumat ja reagoida niihin. yrityksemme on valinnut. Toisessa osassa jatketaan aihetta ja tarkastellaan vaihtoehtoja SaaS-alustojen seurantaan Salesforcen ja Dropboxin esimerkin avulla sekä yritämme myös tiivistää ja koota kaiken luomalla yhtenäisen tietoturvan seurantajärjestelmän eri pilvipalveluntarjoajille.

Lähde: will.com