Flere og flere brukere bringer hele IT-infrastrukturen sin til den offentlige skyen. Men hvis antiviruskontrollen ikke er tilstrekkelig i kundens infrastruktur, oppstår det alvorlige cyberrisikoer. Praksis viser at opptil 80 % av eksisterende virus lever perfekt i et virtuelt miljø. I dette innlegget skal vi snakke om hvordan man kan beskytte IT-ressurser i den offentlige skyen og hvorfor tradisjonelle antivirus ikke er helt egnet for disse formålene.
Til å begynne med vil vi fortelle deg hvordan vi kom til ideen om at de vanlige anti-virusbeskyttelsesverktøyene ikke er egnet for den offentlige skyen og at andre tilnærminger for å beskytte ressurser er nødvendige.
For det første gir tilbydere generelt de nødvendige tiltakene for å sikre at deres skyplattformer er beskyttet på et høyt nivå. For eksempel, på #CloudMTS analyserer vi all nettverkstrafikk, overvåker logger over skyens sikkerhetssystemer og utfører regelmessige tester. Skysegmenter som er allokert til individuelle klienter, må også være sikkert beskyttet.
For det andre innebærer det klassiske alternativet for å bekjempe cyberrisiko å installere et antivirus- og antivirusverktøy på hver virtuell maskin. Men med et stort antall virtuelle maskiner kan denne praksisen være ineffektiv og kreve betydelige mengder dataressurser, og dermed belaste kundens infrastruktur ytterligere og redusere den generelle ytelsen til skyen. Dette har blitt en nøkkelforutsetning for å søke etter nye tilnærminger for å bygge effektiv antivirusbeskyttelse for kundenes virtuelle maskiner.
I tillegg er de fleste antivirusløsninger på markedet ikke tilpasset for å løse problemene med å beskytte IT-ressurser i et offentlig skymiljø. Som regel er det tunge EPP-løsninger (Endpoint Protection Platforms), som dessuten ikke gir nødvendig tilpasning på klientsiden til skyleverandøren.
Det blir åpenbart at tradisjonelle antivirusløsninger er dårlig egnet for å jobbe i skyen, siden de seriøst belaster den virtuelle infrastrukturen under oppdateringer og skanninger, og heller ikke har de nødvendige nivåene av rollebasert administrasjon og innstillinger. Deretter vil vi analysere i detalj hvorfor skyen trenger nye tilnærminger til antivirusbeskyttelse.
Hva et antivirus i en offentlig sky bør kunne gjøre
Så la oss ta hensyn til detaljene ved å jobbe i et virtuelt miljø:
Effektivitet av oppdateringer og planlagte masseskanninger. Hvis et betydelig antall virtuelle maskiner som bruker et tradisjonelt antivirus starter en oppdatering samtidig, vil en såkalt "storm" av oppdateringer oppstå i skyen. Kraften til en ESXi-vert som er vert for flere virtuelle maskiner er kanskje ikke nok til å håndtere floken av lignende oppgaver som kjører som standard. Fra skyleverandørens synspunkt kan et slikt problem føre til ytterligere belastninger på en rekke ESXi-verter, noe som til slutt vil føre til et fall i ytelsen til den virtuelle skyinfrastrukturen. Dette kan blant annet påvirke ytelsen til virtuelle maskiner til andre skyklienter. En lignende situasjon kan oppstå når du starter en masseskanning: samtidig behandling av disksystemet av mange lignende forespørsler fra forskjellige brukere vil påvirke ytelsen til hele skyen negativt. Med en høy grad av sannsynlighet vil en reduksjon i lagringssystemytelsen påvirke alle klienter. Slike brå belastninger gleder verken leverandøren eller kundene hans, da de påvirker "naboene" i skyen. Fra dette synspunktet kan tradisjonell antivirus utgjøre et stort problem.
Trygg karantene. Hvis en fil eller et dokument som potensielt er infisert med et virus oppdages på systemet, sendes det i karantene. Selvfølgelig kan en infisert fil slettes umiddelbart, men dette er ofte ikke akseptabelt for de fleste selskaper. Bedriftsantivirus som ikke er tilpasset til å fungere i leverandørens sky, har som regel en felles karantenesone - alle infiserte objekter faller inn i den. For eksempel de som finnes på datamaskinene til bedriftsbrukere. Klienter til skyleverandøren «bor» i sine egne segmenter (eller leietakere). Disse segmentene er ugjennomsiktige og isolerte: klienter vet ikke om hverandre og ser selvfølgelig ikke hva andre hoster i skyen. Åpenbart kan den generelle karantenen, som vil være tilgjengelig for alle antivirusbrukere i skyen, potensielt inkludere et dokument som inneholder konfidensiell informasjon eller en forretningshemmelighet. Dette er uakseptabelt for leverandøren og dens kunder. Derfor kan det bare være én løsning – personlig karantene for hver klient i sitt segment, hvor verken leverandøren eller andre klienter har tilgang.
Individuelle sikkerhetspolicyer. Hver klient i skyen er et eget selskap, hvis IT-avdeling setter sine egne sikkerhetspolicyer. For eksempel definerer administratorer skanneregler og planlegger antivirusskanninger. Følgelig må hver organisasjon ha sitt eget kontrollsenter for å konfigurere antiviruspolicyer. Samtidig skal ikke de angitte innstillingene påvirke andre skyklienter, og leverandøren skal kunne verifisere at for eksempel antivirusoppdateringer utføres som normalt for alle virtuelle klientmaskiner.
Organisering av fakturering og lisensiering. Skymodellen er preget av fleksibilitet og innebærer kun å betale for mengden IT-ressurser som ble brukt av kunden. Hvis det er behov, for eksempel på grunn av sesongvariasjoner, kan ressursmengden raskt økes eller reduseres – alt basert på dagens behov for datakraft. Tradisjonelt antivirus er ikke så fleksibelt - som regel kjøper klienten en lisens for et år for et forhåndsbestemt antall servere eller arbeidsstasjoner. Skybrukere kobler regelmessig fra og kobler til flere virtuelle maskiner, avhengig av deres nåværende behov – derfor må antiviruslisenser støtte samme modell.
Det andre spørsmålet er hva lisensen skal dekke. Tradisjonelt antivirus er lisensiert av antall servere eller arbeidsstasjoner. Lisenser basert på antall beskyttede virtuelle maskiner er ikke helt egnet innenfor skymodellen. Klienten kan lage et hvilket som helst antall virtuelle maskiner som er praktiske for ham fra de tilgjengelige ressursene, for eksempel fem eller ti maskiner. Dette tallet er ikke konstant for de fleste kunder; det er ikke mulig for oss som leverandør å spore endringene. Det er ingen teknisk mulighet for å lisensiere med CPU: klienter mottar virtuelle prosessorer (vCPUer), som skal brukes til lisensiering. Dermed bør den nye antivirusbeskyttelsesmodellen inkludere muligheten for kunden til å bestemme det nødvendige antallet vCPUer som han vil motta antiviruslisenser for.
Overholdelse av lovverket. Et viktig poeng, siden løsningene som brukes skal sikre samsvar med regulatorens krav. For eksempel jobber "beboere" i nettskyen ofte med personlige data. I dette tilfellet må leverandøren ha et eget sertifisert skysegment som fullt ut oppfyller kravene i personopplysningsloven. Da trenger ikke bedrifter å "bygge" hele systemet for å jobbe med personopplysninger uavhengig: kjøpe sertifisert utstyr, koble til og konfigurere det, og gjennomgå sertifisering. For cyberbeskyttelse av ISPD-en til slike klienter, må antiviruset også overholde kravene i russisk lovgivning og ha et FSTEC-sertifikat.
Vi så på de obligatoriske kriteriene som antivirusbeskyttelse i den offentlige skyen må oppfylle. Deretter vil vi dele vår egen erfaring med å tilpasse en antivirusløsning til å fungere i leverandørens sky.
Hvordan kan du få venner mellom antivirus og sky?
Som vår erfaring har vist er det én ting å velge en løsning basert på beskrivelse og dokumentasjon, men å implementere den i praksis i et allerede fungerende skymiljø er en helt annen oppgave når det gjelder kompleksitet. Vi forteller deg hva vi gjorde i praksis og hvordan vi tilpasset antiviruset til å fungere i leverandørens offentlige sky. Leverandøren av antivirusløsningen var Kaspersky, hvis portefølje inkluderer antivirusløsninger for skymiljøer. Vi bestemte oss for "Kaspersky Security for Virtualization" (Light Agent).
Den inkluderer en enkelt Kaspersky Security Center-konsoll. Light agent og virtuelle sikkerhetsmaskiner (SVM, Security Virtual Machine) og KSC-integrasjonsserver.
Etter at vi studerte arkitekturen til Kaspersky-løsningen og gjennomførte de første testene sammen med leverandørens ingeniører, oppsto spørsmålet om integrering av tjenesten i skyen. Den første implementeringen ble utført i fellesskap på skyområdet i Moskva. Og det var det vi innså.
For å minimere nettverkstrafikken ble det besluttet å plassere en SVM på hver ESXi-vert og "knytte" SVM til ESXi-vertene. I dette tilfellet får lette agenter fra beskyttede virtuelle maskiner tilgang til SVM-en til den eksakte ESXi-verten de kjører på. En egen administrativ leietaker ble valgt for hoved-KSC. Som et resultat er underordnede KSC-er lokalisert i leietakerne til hver enkelt klient og adresserer den overordnede KSC-er i ledelsessegmentet. Denne ordningen lar deg raskt løse problemer som oppstår hos klientleietakere.
I tillegg til problemer med å heve komponentene i selve antivirusløsningen, ble vi møtt med oppgaven med å organisere nettverksinteraksjon gjennom opprettelsen av ytterligere VxLAN. Og selv om løsningen opprinnelig var ment for bedriftskunder med private skyer, kunne vi ved hjelp av ingeniørkunnskapen og den teknologiske fleksibiliteten til NSX Edge løse alle problemene knyttet til separasjon av leietakere og lisensiering.
Vi jobbet tett med Kaspersky-ingeniører. I prosessen med å analysere løsningsarkitekturen med tanke på nettverksinteraksjon mellom systemkomponenter, ble det således funnet at det i tillegg til tilgang fra lysagenter til SVM også er nødvendig med tilbakemelding - fra SVM til lysagenter. Denne nettverkstilkoblingen er ikke mulig i et multitenant-miljø på grunn av muligheten for identiske nettverksinnstillinger for virtuelle maskiner i forskjellige skyleietakere. Derfor, på vår forespørsel, omarbeidet kolleger fra leverandøren mekanismen for nettverksinteraksjon mellom lysagenten og SVM når det gjelder å eliminere behovet for nettverkstilkobling fra SVM til lysagenter.
Etter at løsningen ble distribuert og testet på nettskyen i Moskva, replikerte vi den til andre nettsteder, inkludert det sertifiserte skysegmentet. Tjenesten er nå tilgjengelig i alle regioner i landet.
Arkitektur av en informasjonssikkerhetsløsning innenfor rammen av en ny tilnærming
Det generelle opplegget for drift av en antivirusløsning i et offentlig skymiljø er som følger:
Driftsskjema for en antivirusløsning i et offentlig skymiljø #CloudMTS
La oss beskrive funksjonene til driften av individuelle elementer av løsningen i skyen:
• En enkelt konsoll som lar klienter administrere beskyttelsessystemet sentralt: kjøre skanninger, kontrollere oppdateringer og overvåke karantenesoner. Det er mulig å konfigurere individuelle sikkerhetspolicyer innenfor ditt segment.
Det skal bemerkes at selv om vi er en tjenesteleverandør, forstyrrer vi ikke innstillingene satt av klienter. Det eneste vi kan gjøre er å tilbakestille sikkerhetspolicyene til standard hvis rekonfigurering er nødvendig. Dette kan for eksempel være nødvendig hvis klienten ved et uhell strammet dem eller svekket dem betydelig. Et selskap kan alltid motta et kontrollsenter med standardpolicyer, som det deretter kan konfigurere uavhengig. Ulempen med Kaspersky Security Center er at plattformen foreløpig kun er tilgjengelig for Microsoft-operativsystemet. Selv om lette agenter kan fungere med både Windows- og Linux-maskiner. Kaspersky Lab lover imidlertid at KSC i nær fremtid vil fungere under Linux OS. En av de viktige funksjonene til KSC er evnen til å administrere karantene. Hvert kundeselskap i skyen vår har en personlig. Denne tilnærmingen eliminerer situasjoner der et dokument infisert med et virus ved et uhell blir offentlig synlig, noe som kan skje i tilfellet med et klassisk bedriftsantivirus med generell karantene.
• Lysmidler. Som en del av den nye modellen er en lett Kaspersky Security-agent installert på hver virtuell maskin. Dette eliminerer behovet for å lagre antivirusdatabasen på hver VM, noe som reduserer mengden diskplass som kreves. Tjenesten er integrert med skyinfrastrukturen og fungerer gjennom SVM, som øker tettheten av virtuelle maskiner på ESXi-verten og ytelsen til hele skysystemet. Light-agenten bygger en kø med oppgaver for hver virtuell maskin: sjekk filsystemet, minnet osv. Men SVM er ansvarlig for å utføre disse operasjonene, som vi skal snakke om senere. Agenten fungerer også som en brannmur, kontrollerer sikkerhetspolicyer, sender infiserte filer i karantene og overvåker den generelle "helsen" til operativsystemet den er installert på. Alt dette kan administreres ved hjelp av den allerede nevnte enkeltkonsollen.
• Sikkerhet virtuell maskin. Alle ressurskrevende oppgaver (antivirusdatabaseoppdateringer, planlagte skanninger) håndteres av en separat Security Virtual Machine (SVM). Hun er ansvarlig for driften av en fullverdig antivirusmotor og databaser for den. Et selskaps IT-infrastruktur kan omfatte flere SVM-er. Denne tilnærmingen øker påliteligheten til systemet - hvis en maskin svikter og ikke reagerer på tretti sekunder, begynner agenter automatisk å lete etter en annen.
• KSC integrasjonsserver. En av komponentene i hoved-KSC, som tildeler sine SVM-er til lysagenter i samsvar med algoritmen spesifisert i innstillingene, og kontrollerer også tilgjengeligheten til SVM-er. Dermed gir denne programvaremodulen lastbalansering på tvers av alle SVM-er i skyinfrastrukturen.
Algoritme for å jobbe i skyen: redusere belastningen på infrastrukturen
Generelt kan antivirusalgoritmen representeres som følger. Agenten får tilgang til filen på den virtuelle maskinen og sjekker den. Resultatet av verifiseringen lagres i en felles sentralisert SVM-domsdatabase (kalt Shared Cache), hvor hver oppføring identifiserer et unikt fileksempel. Denne tilnærmingen lar deg sikre at den samme filen ikke skannes flere ganger på rad (for eksempel hvis den ble åpnet på forskjellige virtuelle maskiner). Filen skannes bare på nytt hvis det er gjort endringer i den eller skanningen er startet manuelt.
Implementering av antivirusløsning i leverandørens sky
Bildet viser et generelt diagram over løsningsimplementeringen i skyen. Kasperskys hovedsikkerhetssenter er distribuert i kontrollsonen til skyen, og en individuell SVM distribueres på hver ESXi-vert ved å bruke KSC-integrasjonsserveren (hver ESXi-vert har sin egen SVM tilknyttet med spesielle innstillinger på VMware vCenter Server). Klienter jobber i sine egne skysegmenter, hvor virtuelle maskiner med agenter er plassert. De administreres gjennom individuelle KSC-servere underordnet hoved-KSC. Hvis det er nødvendig å beskytte et lite antall virtuelle maskiner (opptil 5), kan klienten gis tilgang til den virtuelle konsollen til en spesiell dedikert KSC-server. Nettverksinteraksjon mellom klient-KSC-er og hoved-KSC-er, så vel som lysagenter og SVM-er, utføres ved hjelp av NAT gjennom EdgeGW-klient virtuelle rutere.
I henhold til våre estimater og resultatene av tester av kolleger hos leverandøren, reduserer Light Agent belastningen på klienters virtuelle infrastruktur med omtrent 25 % (sammenlignet med et system som bruker tradisjonell antivirusprogramvare). Spesielt bruker standard Kaspersky Endpoint Security (KES) antivirus for fysiske miljøer nesten dobbelt så mye server CPU-tid (2,95 %) som en lett agentbasert virtualiseringsløsning (1,67 %).
Sammenligningsdiagram for CPU-belastning
En lignende situasjon observeres med frekvensen av diskskrivetilganger: for et klassisk antivirus er det 1011 IOPS, for et sky-antivirus er det 671 IOPS.
Sammenligningsgraf for disktilgangshastighet
Ytelsesfordelen lar deg opprettholde infrastrukturstabilitet og bruke datakraft mer effektivt. Ved å tilpasse seg arbeid i et offentlig skymiljø, reduserer ikke løsningen skyytelsen: den sjekker filer sentralt og laster ned oppdateringer, og fordeler belastningen. Dette betyr at på den ene siden ikke vil gå glipp av trusler som er relevante for skyinfrastrukturen, på den andre siden vil ressurskravene til virtuelle maskiner reduseres med gjennomsnittlig 25 % sammenlignet med et tradisjonelt antivirus.
Når det gjelder funksjonalitet, er begge løsningene veldig like hverandre: nedenfor er en sammenligningstabell. Men i skyen, som testresultatene ovenfor viser, er det fortsatt optimalt å bruke en løsning for virtuelle miljøer.
Om tariffer innenfor rammen av den nye tilnærmingen. Vi bestemte oss for å bruke en modell som lar oss få lisenser basert på antall vCPUer. Dette betyr at antall lisenser vil være lik antall vCPUer. Du kan teste antivirusprogrammet ditt ved å legge igjen en forespørsel .
I den neste artikkelen om skytemaer vil vi snakke om utviklingen av sky WAF-er og hva som er bedre å velge: maskinvare, programvare eller sky.
Teksten ble utarbeidet av ansatte i skyleverandøren #CloudMTS: Denis Myagkov, ledende arkitekt og Alexey Afanasyev, produktutviklingssjef for informasjonssikkerhet.
Kilde: www.habr.com