Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?

Yhä useammat käyttäjät tuovat koko IT-infrastruktuurinsa julkiseen pilveen. Mikäli virustentorjunta on kuitenkin riittämätön asiakkaan infrastruktuurissa, syntyy vakavia kyberriskejä. Käytäntö osoittaa, että jopa 80 % olemassa olevista viruksista elää täydellisesti virtuaaliympäristössä. Tässä postauksessa puhumme siitä, kuinka IT-resursseja voidaan suojata julkisessa pilvessä ja miksi perinteiset virustorjuntaohjelmat eivät ole täysin sopivia näihin tarkoituksiin.

Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?

Aluksi kerromme, kuinka päädyimme siihen ajatukseen, että tavalliset virustorjuntatyökalut eivät sovellu julkiseen pilveen ja että resurssien suojaamiseen tarvitaan muita tapoja.

Ensinnäkin palveluntarjoajat tarjoavat yleensä tarvittavat toimenpiteet varmistaakseen, että heidän pilvialustojaan suojataan korkealla tasolla. Esimerkiksi #CloudMTS:ssä analysoimme kaiken verkkoliikenteen, seuraamme pilviturvajärjestelmien lokeja ja suoritamme säännöllisesti pentestejä. Yksittäisille asiakkaille allokoidut pilvisegmentit on myös suojattava turvallisesti.

Toiseksi klassinen vaihtoehto kyberriskien torjumiseksi sisältää virustentorjunta- ja virustentorjuntatyökalujen asentamisen jokaiseen virtuaalikoneeseen. Suurella määrällä virtuaalikoneita tämä käytäntö voi kuitenkin olla tehoton ja vaatia huomattavia määriä laskentaresursseja, mikä kuormittaa entisestään asiakkaan infrastruktuuria ja heikentää pilven yleistä suorituskykyä. Tästä on tullut keskeinen edellytys uusien lähestymistapojen etsimiselle tehokkaan virussuojauksen rakentamiseksi asiakkaiden virtuaalikoneen.

Lisäksi useimpia markkinoilla olevia virustorjuntaratkaisuja ei ole mukautettu ratkaisemaan IT-resurssien suojaamiseen liittyviä ongelmia julkisessa pilviympäristössä. Pääsääntöisesti kyseessä ovat raskaat EPP-ratkaisut (Endpoint Protection Platforms), jotka eivät myöskään tarjoa tarvittavaa räätälöintiä pilvipalvelun tarjoajan asiakaspuolella.

On selvää, että perinteiset virustentorjuntaratkaisut eivät sovellu pilvityöskentelyyn, koska ne kuormittavat vakavasti virtuaalista infrastruktuuria päivitysten ja tarkistusten aikana, eikä niissä ole myöskään tarvittavaa roolipohjaista hallintaa ja asetuksia. Seuraavaksi analysoimme yksityiskohtaisesti, miksi pilvi tarvitsee uusia lähestymistapoja virustentorjuntaan.

Mitä julkisessa pilvessä olevan virustorjunnan pitäisi pystyä

Kiinnitetään siis huomiota virtuaaliympäristössä työskentelyn erityispiirteisiin:

Päivitysten ja ajoitettujen massaskannausten tehokkuus. Jos huomattava määrä perinteistä virustorjuntaa käyttäviä virtuaalikoneita käynnistää päivityksen samanaikaisesti, pilvessä tapahtuu niin sanottu päivitysmyrsky. Useita virtuaalikoneita isännöivän ESXi-isännän teho ei välttämättä riitä käsittelemään oletusarvoisesti käynnissä olevien vastaavien tehtävien tulva. Pilvipalveluntarjoajan näkökulmasta tällainen ongelma voi johtaa useiden ESXi-isäntien lisäkuormitukseen, mikä lopulta johtaa pilvivirtuaaliinfrastruktuurin suorituskyvyn laskuun. Tämä voi muun muassa vaikuttaa muiden pilviasiakkaiden virtuaalikoneiden suorituskykyyn. Samanlainen tilanne voi syntyä massaskannausta käynnistettäessä: useiden eri käyttäjien samankaltaisten pyyntöjen samanaikainen käsittely levyjärjestelmässä vaikuttaa negatiivisesti koko pilven suorituskykyyn. Suurella todennäköisyydellä tallennusjärjestelmän suorituskyvyn heikkeneminen vaikuttaa kaikkiin asiakkaisiin. Tällaiset äkilliset kuormitukset eivät miellytä palveluntarjoajaa tai hänen asiakkaitaan, koska ne vaikuttavat pilven "naapureihin". Tästä näkökulmasta perinteinen virustorjunta voi aiheuttaa suuren ongelman.

Turvallinen karanteeni. Jos järjestelmässä havaitaan tiedosto tai asiakirja, joka on mahdollisesti viruksen saastuttama, se lähetetään karanteeniin. Saastuneen tiedoston voi tietysti poistaa välittömästi, mutta tämä ei useinkaan ole hyväksyttävää useimmille yrityksille. Yritysten virustorjuntaohjelmilla, joita ei ole mukautettu toimimaan palveluntarjoajan pilvessä, on yleensä yhteinen karanteenialue - kaikki tartunnan saaneet objektit putoavat siihen. Esimerkiksi ne, jotka löytyvät yritysten käyttäjien tietokoneilta. Pilvipalveluntarjoajan asiakkaat "elävät" omissa segmenteissään (tai vuokralaisissa). Nämä segmentit ovat läpinäkymättömiä ja eristettyjä: asiakkaat eivät tiedä toisistaan ​​eivätkä tietenkään näe, mitä muut isännöivät pilvessä. Ilmeisesti yleinen karanteeni, johon kaikki pilven virustentorjunnan käyttäjät pääsevät, saattaa sisältää asiakirjan, joka sisältää luottamuksellisia tietoja tai liikesalaisuuden. Tätä ei voida hyväksyä palveluntarjoajan ja sen asiakkaiden kannalta. Siksi ratkaisuja voi olla vain yksi - henkilökohtainen karanteeni jokaiselle segmenttiin kuuluvalle asiakkaalle, johon palveluntarjoajalla tai muilla asiakkailla ei ole pääsyä.

Yksittäiset turvallisuuskäytännöt. Jokainen pilven asiakas on erillinen yritys, jonka IT-osasto määrittää omat tietoturvapolitiikkansa. Esimerkiksi järjestelmänvalvojat määrittävät tarkistussäännöt ja ajoittavat virustarkistukset. Vastaavasti jokaisella organisaatiolla on oltava oma ohjauskeskus virustentorjuntakäytäntöjen määrittämistä varten. Samanaikaisesti määritetyt asetukset eivät saisi vaikuttaa muihin pilviasiakkaisiin, ja palveluntarjoajan tulee pystyä varmistamaan, että esimerkiksi virustorjuntapäivitykset suoritetaan normaalisti kaikille asiakasvirtuaalikoneille.

Laskutuksen ja lisensoinnin järjestäminen. Pilvimallille on ominaista joustavuus ja siinä maksetaan vain siitä IT-resurssien määrästä, jota asiakas käytti. Jos tarvetta on esimerkiksi kausiluonteisuuden vuoksi, niin resurssien määrää voidaan nopeasti lisätä tai vähentää – kaikki tämän hetken laskentatehotarpeiden perusteella. Perinteinen virustorjunta ei ole niin joustava - pääsääntöisesti asiakas ostaa lisenssin vuodeksi ennalta määrätylle määrälle palvelimia tai työasemia. Pilvikäyttäjät katkaisevat ja yhdistävät säännöllisesti uusia virtuaalikoneita nykyisten tarpeidensa mukaan - vastaavasti virustorjuntalisenssien on tuettava samaa mallia.

Toinen kysymys on, mitä lisenssi tarkalleen ottaen kattaa. Perinteinen virustorjunta on lisensoitu palvelimien tai työasemien lukumäärän mukaan. Suojattujen virtuaalikoneiden määrään perustuvat lisenssit eivät ole täysin sopivia pilvimalliin. Asiakas voi luoda käytettävissä olevista resursseista minkä tahansa hänelle sopivan määrän virtuaalikoneita, esimerkiksi viisi tai kymmenen konetta. Tämä luku ei ole vakio useimmille asiakkaille, emmekä palveluntarjoajana pysty seuraamaan sen muutoksia. Ei ole teknistä mahdollisuutta lisensoida prosessorilla: asiakkaat saavat virtuaalisia prosessoreita (vCPU:ita), joita tulee käyttää lisensointiin. Uuteen virustorjuntamalliin tulee siis sisällyttää asiakkaan mahdollisuus määrittää tarvittava määrä vCPU:ita, joille hän saa virustorjuntalisenssit.

Lainsäädännön noudattaminen. Tärkeä seikka, koska käytettävien ratkaisujen on varmistettava viranomaisen vaatimusten noudattaminen. Esimerkiksi pilven ”asukkaat” työskentelevät usein henkilötietojen kanssa. Tässä tapauksessa palveluntarjoajalla on oltava erillinen sertifioitu pilvisegmentti, joka täyttää täysin henkilötietolain vaatimukset. Silloin yritysten ei tarvitse itsenäisesti "rakentaa" koko järjestelmää henkilötietojen kanssa työskentelyä varten: ostaa sertifioituja laitteita, yhdistää ja konfiguroida se ja suorittaa sertifiointi. Tällaisten asiakkaiden ISPD:n kybersuojausta varten virustorjunnan tulee täyttää myös Venäjän lainsäädännön vaatimukset ja sillä on oltava FSTEC-sertifikaatti.

Tarkastelimme pakollisia kriteerejä, jotka julkisen pilven virussuojauksen on täytettävä. Seuraavaksi jaamme omia kokemuksiamme virustorjuntaratkaisun mukauttamisesta toimimaan palveluntarjoajan pilvessä.

Kuinka voit saada ystäviä virustorjunnan ja pilven välillä?

Kuten kokemuksemme on osoittanut, ratkaisun valitseminen kuvauksen ja dokumentaation perusteella on yksi asia, mutta sen toteuttaminen käytännössä jo toimivassa pilviympäristössä on monimutkaisuudeltaan aivan eri tehtävä. Kerromme, mitä teimme käytännössä ja kuinka sovitimme virustorjunnan toimimaan palveluntarjoajan julkisessa pilvessä. Viruksentorjuntaratkaisun toimittaja oli Kaspersky, jonka portfolio sisältää virustentorjuntaratkaisuja pilviympäristöihin. Päädyimme "Kaspersky Security for Virtualization" -ratkaisuun (Light Agent).

Se sisältää yhden Kaspersky Security Center -konsolin. Kevyt agentti- ja turvallisuusvirtuaalikoneet (SVM, Security Virtual Machine) ja KSC-integraatiopalvelin.

Tutkittuamme Kaspersky-ratkaisun arkkitehtuuria ja suoritettuamme ensimmäiset testit yhdessä toimittajan insinöörien kanssa, heräsi kysymys palvelun integroimisesta pilveen. Ensimmäinen toteutus toteutettiin yhdessä Moskovan pilvisivustolla. Ja sen me ymmärsimme.

Verkkoliikenteen minimoimiseksi päätettiin sijoittaa SVM jokaiseen ESXi-isäntään ja "sidota" SVM ESXi-isäntään. Tässä tapauksessa suojattujen virtuaalikoneiden kevyet agentit käyttävät tarkalleen sen ESXi-isännän SVM:ää, jossa ne toimivat. Pää-KSC:lle valittiin erillinen hallintovuokralainen. Tämän seurauksena alaisuudessa olevat KSC:t sijaitsevat kunkin yksittäisen asiakkaan vuokralaisissa ja osoittavat johtamissegmentissä sijaitsevan ylimmän KSC:n. Tämän järjestelmän avulla voit nopeasti ratkaista asiakkaiden vuokralaisissa ilmenevät ongelmat.

Itse virustorjuntaratkaisun komponenttien nostamiseen liittyvien ongelmien lisäksi edessämme oli verkkovuorovaikutuksen järjestäminen luomalla lisää VxLAN-verkkoja. Ja vaikka ratkaisu oli alun perin tarkoitettu yritysasiakkaille, joilla on yksityiset pilvet, NSX Edgen insinööritaidon ja teknologisen joustavuuden avulla pystyimme ratkaisemaan kaikki vuokralaisten erottamiseen ja lisensointiin liittyvät ongelmat.

Työskentelimme tiiviisti Kasperskyn insinöörien kanssa. Siten analysoitaessa ratkaisuarkkitehtuuria järjestelmäkomponenttien välisen verkkovuorovaikutuksen kannalta, havaittiin, että kevytagenteista SVM:ään pääsyn lisäksi tarvitaan myös palautetta - SVM:stä kevytagenteille. Tämä verkkoyhteys ei ole mahdollista monivuokraajaympäristössä, koska virtuaalikoneiden verkkoasetukset voivat olla identtisiä eri pilvivuokralaisissa. Siksi toimittajan kollegat muokkasivat pyynnöstämme kevytagentin ja SVM:n välisen verkkovuorovaikutuksen mekanismia eliminoidakseen verkkoyhteyden tarpeen SVM:stä kevyisiin agentteihin.

Kun ratkaisu otettiin käyttöön ja testattiin Moskovan pilvisivustolla, kopioimme sen muille sivustoille, mukaan lukien sertifioitu pilvisegmentti. Palvelu on nyt saatavilla kaikilla maan alueilla.

Tietoturvaratkaisun arkkitehtuuri uuden lähestymistavan puitteissa

Virustentorjuntaratkaisun yleinen toimintakaavio julkisessa pilviympäristössä on seuraava:

Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?
Virustorjuntaratkaisun toimintakaavio julkisessa pilviympäristössä #CloudMTS

Kuvataan ratkaisun yksittäisten elementtien toiminnan ominaisuuksia pilvessä:

• Yksi konsoli, jonka avulla asiakkaat voivat hallita suojausjärjestelmää keskitetysti: suorittaa tarkistuksia, hallita päivityksiä ja valvoa karanteenialueita. Segmentissäsi on mahdollista määrittää yksittäisiä suojauskäytäntöjä.

On huomattava, että vaikka olemme palveluntarjoaja, emme puutu asiakkaiden asettamiin asetuksiin. Ainoa asia, jonka voimme tehdä, on nollata suojauskäytännöt vakiomuotoisiksi, jos uudelleenmääritys on tarpeen. Tämä voi olla tarpeen esimerkiksi, jos asiakas kiristi niitä vahingossa tai heikensi niitä merkittävästi. Yritys voi aina vastaanottaa ohjauskeskuksen oletuskäytännöillä, jotka se voi sitten määrittää itsenäisesti. Kaspersky Security Centerin haittana on, että alusta on tällä hetkellä saatavilla vain Microsoft-käyttöjärjestelmälle. Vaikka kevyet agentit voivat työskennellä sekä Windows- että Linux-koneiden kanssa. Kaspersky Lab lupaa kuitenkin, että lähitulevaisuudessa KSC toimii Linux-käyttöjärjestelmän alla. Yksi KSC:n tärkeistä tehtävistä on kyky hallita karanteenia. Jokaisella pilvessämme olevalla asiakasyrityksellä on henkilökohtainen yritys. Tämä lähestymistapa eliminoi tilanteet, joissa viruksen saastuttama asiakirja tulee vahingossa julkisesti näkyväksi, kuten voisi tapahtua perinteisen yritysviruksentorjuntaohjelman tapauksessa, jossa on yleinen karanteeni.

• Miedot aineet. Osana uutta mallia jokaiseen virtuaalikoneeseen asennetaan kevyt Kaspersky Security -agentti. Tämä eliminoi tarpeen tallentaa virustentorjuntatietokantaa jokaiselle VM:lle, mikä vähentää vaaditun levytilan määrää. Palvelu on integroitu pilviinfrastruktuuriin ja toimii SVM:n kautta, mikä lisää virtuaalikoneiden tiheyttä ESXi-isännällä ja koko pilvijärjestelmän suorituskykyä. Kevyt agentti rakentaa jokaiselle virtuaalikoneelle tehtäväjonon: tarkista tiedostojärjestelmä, muisti jne. Mutta SVM on vastuussa näiden toimintojen suorittamisesta, joista puhumme myöhemmin. Agentti toimii myös palomuurina, valvoo suojauskäytäntöjä, lähettää tartunnan saaneet tiedostot karanteeniin ja valvoo sen käyttöjärjestelmän yleistä "terveyttä", johon se on asennettu. Kaikkea tätä voidaan hallita jo mainitulla yksittäisellä konsolilla.

• Turvallisuus Virtual Machine. Kaikki resurssiintensiiviset tehtävät (virustorjuntatietokannan päivitykset, ajoitetut tarkistukset) hoidetaan erillisellä Security Virtual Machinella (SVM). Hän vastaa täysimittaisen virustorjuntamoottorin ja sitä koskevien tietokantojen toiminnasta. Yrityksen IT-infrastruktuuri voi sisältää useita SVM:itä. Tämä lähestymistapa lisää järjestelmän luotettavuutta - jos yksi kone epäonnistuu eikä vastaa XNUMX sekuntiin, agentit alkavat automaattisesti etsiä toista.

• KSC-integraatiopalvelin. Yksi pää-KSC:n komponenteista, joka määrittää SVM:nsä kevytagenteille asetuksissa määritellyn algoritmin mukaisesti ja ohjaa myös SVM:ien saatavuutta. Näin ollen tämä ohjelmistomoduuli tarjoaa kuormituksen tasapainotuksen kaikissa pilviinfrastruktuurin SVM:issä.

Algoritmi pilvessä työskentelemiseen: infrastruktuurin kuormituksen vähentäminen

Yleensä virustorjuntaalgoritmi voidaan esittää seuraavasti. Agentti käyttää virtuaalikoneen tiedostoa ja tarkistaa sen. Tarkistuksen tulos tallennetaan yhteiseen keskitettyyn SVM-päätöstietokantaan (nimeltään Shared Cache), jonka jokainen merkintä tunnistaa yksilöllisen tiedostonäytteen. Tämän lähestymistavan avulla voit varmistaa, että samaa tiedostoa ei tarkisteta useita kertoja peräkkäin (esimerkiksi jos se on avattu eri virtuaalikoneissa). Tiedosto tarkistetaan uudelleen vain, jos siihen on tehty muutoksia tai tarkistus on aloitettu manuaalisesti.

Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?
Virustorjuntaratkaisun käyttöönotto palveluntarjoajan pilvessä

Kuvassa on yleinen kaavio ratkaisun toteutuksesta pilvessä. Pääasiallinen Kaspersky Security Center otetaan käyttöön pilven ohjausvyöhykkeellä, ja jokaiselle ESXi-isännälle otetaan käyttöön yksittäinen SVM KSC-integraatiopalvelimen avulla (jokaisella ESXi-isännällä on oma SVM liitettynä erityisillä asetuksilla VMware vCenter Serveriin). Asiakkaat työskentelevät omissa pilvisegmenteissään, joissa virtuaalikoneet ja agentit sijaitsevat. Niitä hallitaan yksittäisten KSC-palvelimien kautta, jotka ovat pää-KSC:n alaisia. Jos on tarpeen suojata pieni määrä virtuaalikoneita (enintään 5), asiakkaalle voidaan tarjota pääsy erityisen dedikoidun KSC-palvelimen virtuaalikonsoliin. Verkkovuorovaikutus asiakas-KSC:iden ja pää-KSC:n sekä kevytagenttien ja SVM:iden välillä tapahtuu NAT:n avulla EdgeGW-asiakasvirtuaalireitittimien kautta.

Arviomme ja toimittajan kollegoiden testien tulosten mukaan Light Agent vähentää asiakkaiden virtuaalisen infrastruktuurin kuormitusta noin 25 % (verrattuna perinteistä virustorjuntaohjelmistoa käyttävään järjestelmään). Erityisesti fyysisiin ympäristöihin tarkoitettu tavallinen Kaspersky Endpoint Security (KES) -virustorjunta kuluttaa lähes kaksi kertaa enemmän palvelimen suoritinaikaa (2,95 %) kuin kevyt agenttipohjainen virtualisointiratkaisu (1,67 %).

Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?
Prosessorin kuormituksen vertailutaulukko

Samanlainen tilanne havaitaan levyn kirjoituskäyttöjen taajuudella: klassiselle viruksentorjuntaohjelmalle se on 1011 IOPS, pilviviruksentorjuntaohjelmalle se on 671 IOPS.

Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?
Levyn käyttöasteen vertailukaavio

Suorituskykyedun avulla voit ylläpitää infrastruktuurin vakautta ja käyttää laskentatehoa tehokkaammin. Sopeutumalla toimimaan julkisessa pilviympäristössä, ratkaisu ei heikennä pilven suorituskykyä: se tarkastaa keskitetysti tiedostot ja lataa päivitykset jakaen kuorman. Tämä tarkoittaa, että toisaalta pilviinfrastruktuurin kannalta oleelliset uhat eivät jää huomaamatta, toisaalta virtuaalikoneiden resurssitarve pienenee keskimäärin 25 % perinteiseen virustorjuntaan verrattuna.

Toiminnallisesti molemmat ratkaisut ovat hyvin samankaltaisia: alla on vertailutaulukko. Kuitenkin pilvessä, kuten yllä olevat testitulokset osoittavat, on silti optimaalista käyttää ratkaisua virtuaaliympäristöihin.

Miksi perinteiset virustentorjuntaohjelmat eivät sovellu julkisiin pilviin? Eli mitä minun pitäisi tehdä?

Tietoja tariffeista uuden lähestymistavan puitteissa. Päätimme käyttää mallia, jonka avulla voimme hankkia lisenssejä vCPU:iden lukumäärän perusteella. Tämä tarkoittaa, että lisenssien määrä on yhtä suuri kuin vCPU:iden lukumäärä. Voit testata virustorjuntasi jättämällä pyynnön verkossa.

Seuraavassa pilviaiheita käsittelevässä artikkelissa puhumme pilvi WAF:ien kehityksestä ja siitä, mikä on parempi valita: laitteisto, ohjelmisto vai pilvi.

Tekstin ovat laatineet pilvipalveluntarjoajan #CloudMTS työntekijät: johtava arkkitehti Denis Myagkov ja tietoturvan tuotekehityspäällikkö Aleksei Afanasjev.

Lähde: will.com

Lisää kommentti