Flere og flere brugere flytter deres hele IT-infrastruktur til offentlige skyer. Men hvis antiviruskontrollen i kundeinfrastrukturen er utilstrækkelig, opstår der alvorlige cyberrisici. Praksis viser, at op til 80 % af eksisterende vira trives fint i virtuelle miljøer. I dette indlæg vil vi forklare, hvordan man beskytter IT-ressourcer i den offentlige sky, og hvorfor traditionelle antivirusløsninger ikke helt opfylder disse behov.
For det første vil vi forklare, hvordan vi kom frem til ideen om, at almindelige antivirusbeskyttelsesværktøjer ikke er passende for offentlige skyer og at der kræves andre tilgange til beskyttelse af ressourcer.
For det første sikrer udbydere normalt de nødvendige foranstaltninger for at garantere beskyttelse af deres skyplatforme på et højt niveau. For eksempel analyserer vi i #CloudMTS al netværkstrafik, overvåger sikkerhedssystemlogs i vores sky og udfører regelmæssigt penetrations-tests. De segmenter af skyen, der er givet til enkelte kunder, skal også være sikkert beskyttede.
For det andet indebærer den klassiske tilgang til bekæmpelse af cyberrisici installation af antivirusprogrammer og administration af dem på hver virtuel maskine. Men ved et stort antal virtuelle maskiner kan denne praksis vise sig at være ineffektiv og kræve betydelige mængder af computerressourcer, hvilket yderligere belaster kundeinfrastrukturen og reducerer den samlede ydeevne i skyen. Dette blev en central grund til at søge efter nye tilgange til at opbygge effektiv antivirusbeskyttelse for kundernes virtuelle maskiner.
Desuden er de fleste eksisterende antivirusløsninger på markedet ikke tilpasset til at løse opgaverne med at beskytte IT-ressourcer i offentlige sky miljøer. De er typisk tunge EPP-løsninger (Endpoint Protection Platforms), som desuden ikke giver mulighed for den nødvendige tilpasning fra cloududbyderens side.
Det bliver åbenlyst, at traditionelle antivirusløsninger ikke er velegnede til brug i skyen, da de alvorligt belaster den virtuelle infrastruktur under opdateringer og scanninger, og desuden mangler de nødvendige niveauer af rollebaseret styring og indstillinger. Vi vil nu nærmere undersøge, hvorfor skyen har brug for nye tilgange til antivirusbeskyttelse.
Hvad en antivirus skal kunne i et offentligt cloudmiljø
Lad os se på de specifikke forhold ved arbejde i virtuelle miljøer:
Effektiviteten af opdateringer og massecheck på planlagt tid. Hvis et stort antal virtuelle maskiner, der bruger traditionel antivirus, samtidig initierer en opdatering, vil der opstå det, man kalder en "opdateringsstorm" i cloudmiljøet. Kapaciteten på den ESXi-vært, der huser flere virtuelle maskiner, kan være utilstrækkelig til at håndtere bølgen af ensartede opgaver, der kører som standard. Fra cloududbyderens synspunkt kan et sådant problem føre til øget belastning på en række ESXi-værter, hvilket i sidste ende vil resultere i nedsat ydeevne af den virtuelle cloudinfrastruktur. Dette kan også påvirke ydeevnen af de virtuelle maskiner fra andre cloudkunder. En lignende situation kan opstå, når der køres massescanning: den samtidige behandling af mange ensartede anmodninger fra forskellige brugere af diskstyringssystemet vil negativt påvirke ydeevnen i hele cloudmiljøet. Sandsynligheden for, at nedsat ydeevne fra det lagerområde vil påvirke alle kunder, er høj. Sådanne pludselige belastninger er ikke ønskværdige for hverken udbyderen eller dens kunder, da de påvirker "naboerne" i cloudmiljøet. Set fra den vinkel kan traditionel antivirus være et stort problem.
Sikker karantæne. Hvis systemet opdager en fil eller dokument, der potentielt er inficeret med en virus, sendes det til karantæne. Selvfølgelig kan den inficerede fil straks slettes, men dette er ofte ikke acceptabelt for de fleste virksomheder. Corporate enterprise-antivirusprogrammer, der ikke er tilpasset til at arbejde i cloud-udbyderens miljø, har som regel et fælles karantæneområde — alle inficerede objekter havner her. For eksempel dem, der er fundet på virksomhedens brugeres computere. Klienterne hos cloud-udbyderen
Individuelle sikkerhedspolitikker. Hver klient i cloud'en er en separat virksomhed, hvis IT-afdeling fastsætter sine egne sikkerhedspolitikker. For eksempel bestemmer administratorerne scanningregler og tidsplaner for antiviruschecks. Derfor skal hver organisation have sit eget kontrolcenter til at konfigurere antiviruspolitikkerne. De angivne indstillinger må ikke påvirke andre klienter i cloud'en, og udbyderen skal have mulighed for at sikre, at for eksempel antivirusopdateringer udføres som planlagt for alle klientens virtuelle maskiner.
Organisering af fakturering og licensiering. Cloud-modellen kendetegnes ved fleksibilitet og indebærer betaling kun for den mængde IT-ressourcer, som kunden har brugt. Hvis der er behov, for eksempel på grund af sæsonfaktorer, kan mængden af ressourcer hurtigt øges eller reduceres — alt efter de aktuelle behov for beregningskraft. Traditionel antivirus er ikke så fleksibel — som regel køber kunden en licens for et år på et forhåndsbestemt antal. servere eller arbejdsstationer. Brugere af clouden tilslutter og frakobler regelmæssigt ekstra virtuelle maskiner afhængigt af deres aktuelle behov — derfor skal antiviruslicenserne understøtte den samme model.
Det andet spørgsmål omhandler, hvad licensen præcist vil dække. Traditionel antiviruslicens gives pr. antal servere eller arbejdsstationer. Licenser baseret på antallet af beskyttede virtuelle maskiner er ikke helt passende i en cloud-model. Kunden kan skabe et valgfrit antal virtuelle maskiner ud fra de eksisterende ressourcer, for eksempel fem eller ti maskiner. Dette antal er ikke konstant for de fleste kunder, og det er ikke muligt for os som udbyder at holde styr på ændringerne. Der er ingen teknisk mulighed for licensering pr. CPU: kunderne får virtuelle processorer (vCPU), som licenseringen skal baseres på. Derfor skal den nye model for antivirusbeskyttelse give mulighed for, at kunden selv kan bestemme, hvor mange vCPU'er de ønsker at modtage antiviruslicenser for.
Overholdelse af lovgivningen. Et vigtigt punkt, da de anvendte løsninger skal sikre opfyldelsen af regulatorens krav. For eksempel arbejder "beboere" i skyen ofte med personoplysninger. I så fald skal udbyderen have et separat certificeret segment af skyen, der fuldt ud overholder kravene i loven om "personoplysninger". Så behøver virksomhederne ikke selv at "opbygge" hele systemet til behandling af personoplysninger: de skal købe certificeret udstyr, tilslutte og konfigurere det samt gennemføre certificering. For at sikre cybersikkerheden for sådanne kunders personoplysninger skal antiviruset også overholde kravene i den russiske lovgivning og have FSTEC-certifikat.
Vi har gennemgået de nødvendige kriterier, som antivirusbeskyttelse i en offentlig sky skal opfylde. Dernæst vil vi dele vores egne erfaringer med tilpasningen af antivirusløsninger til drift i en udbyders sky.
Hvordan kan man forene antivirus og sky?
Som vores erfaring viser, er det en ting at vælge en løsning baseret på beskrivelse og dokumentation, men at implementere den i praksis i et allerede fungerende cloud-miljø er en helt anden kompleksitet. Vi vil fortælle, hvad vi gjorde i praksis, og hvordan vi tilpassede antivirusløsningen til at arbejde i en offentlig cloud udbyder. Antivirusløsningen blev leveret af Kaspersky, som har løsninger til antivirusbeskyttelse for cloud-miljøer i sit portefølje. Vi valgte "Kaspersky Security for Virtual Environments" (Light Agent).
Det inkluderer et samlet kontrolpanel Kaspersky Security Center. Light Agent og sikkerheds virtuelle maskiner (SVM, Security Virtual Machine) samt KSC integrationsserver.
Efter vi havde studeret arkitekturen af Kasperskys løsning og udført de første tests sammen med leverandørens ingeniører, opstod spørgsmålet om integration af tjenesten i cloud. Den første implementering blev gennemført i fællesskab på det moskveske cloudsite. Og her er, hvad vi fandt ud af.
For at minimere netværkstrafikken blev der truffet beslutning om at placere SVM på hver ESXi-host og "binde" SVM til ESXi-værterne. På den måde henvender de lette agenter for de beskyttede virtuelle maskiner sig til SVM'en på den ESXi-host, hvor de kører. For den primære KSC blev der valgt en separat administrativ tenant. Som resultat er de underordnede KSC'er placeret i tenanterne af hver enkelt kunde og henvender sig til den overordnede KSC, placeret i administrationssegmentet. Denne opbygning muliggør hurtig håndtering af problemer, der opstår i kundernes tenanter.
Udover at rejse spørgsmål om opsætningen af selve antivirusløsningens komponenter stod vi over for opgaven med at organisere netværksinteraktion ved at skabe yderligere VxLAN. Og selvom løsningen oprindeligt var designet til enterprise-kunder med private clouds, lykkedes det med ingeniørens opfindsomhed og teknologisk fleksibilitet fra NSX Edge at løse alle opgaver relateret til tenant-opdeling og licensadministration.
Vi har arbejdet tæt sammen med ingeniørerne fra Kaspersky. Under analysen af arkitekturen af løsningen, især hvad angår netværksinteraktionen mellem systemkomponenterne, blev det konstateret, at der, udover adgangen fra lette agenter til SVM, også er behov for feedback – fra SVM til de lette agenter. Denne netværksforbindelse er umulig i et multitenant-miljø på grund af muligheden for identiske netværksindstillinger i virtuelle maskiner på tværs af forskellige tenant-miljøer i skyen. Derfor blev mekanismen for netværksinteraktion mellem den lette agent og SVM omarbejdet på vores anmodning af kollegerne fra leverandøren for at udelukke behovet for netværksforbindelse fra SVM til de lette agenter.
Efter at løsningen blev implementeret og testet på den moskvaske cloud-site, har vi distribueret den til de øvrige sites, inklusive det certificerede cloud-segment. Nu er servicen tilgængelig i alle regioner i landet.
Arkitekturen af IT-sikkerhedsløsningen i den nye tilgang
Den overordnede skitse af antivirusløsningen i det offentlige cloud-miljø ser ud som følger:
Skitse af antivirusløsningen i det offentlige cloud-miljø #CloudMTS
Lad os beskrive funktionerne i de enkelte elementer af løsningen i skyen:
• En enkelt konsol, der giver klienterne mulighed for centralt at styre beskyttelsessystemet: udføre scanninger, overvåge opdateringer og følge med i karantæneområderne. Der er mulighed for at konfigurere individuelle sikkerhedspolitikker inden for sit eget segment.
Det skal bemærkes, at selvom vi er serviceudbyder, blander vi os ikke i de indstillinger, som kunderne foretager. Det eneste, vi kan gøre, er at nulstille sikkerhedspolitikkerne til standardindstillingerne, hvis der er behov for en omkonfiguration. For eksempel kan det være nødvendigt, hvis kunden ved et uheld har strammet dem eller markant svækket dem. Virksomheden kan altid få adgang til administrationcentret med standardpolitikker, som de derefter kan tilpasse selv. En ulempe ved Kaspersky Security Center er, at platformen i øjeblikket kun er tilgængelig for Microsofts operativsystem. Selvom lette agenter kan fungere både med Windows og Linux-maskiner. Men hos Kaspersky Lab lover de, at KSC snart også vil fungere under Linux OS. En af de vigtigste funktioner i KSC er muligheden for at administrere karantænen. Hver kunder virksomhed i vores cloud har en personlig karantæne. Denne tilgang eliminerer situationer, hvor et virusinficeret dokument ved en fejltagelse bliver offentlig tilgængeligt, som kunne ske med et klassisk virksomhedsanivirus med fælles karantæne.
• Lettere agenter. I den nye model installeres en let Kaspersky Security-agent på hver virtuelt maskine. Dette gør det unødvendigt at opbevare antivirusdatabasen på hver VM, hvilket reducerer pladskravene. Servicen er integreret med cloud-infrastrukturen og fungerer gennem SVM, hvilket øger tæthed af virtuelle maskiner på ESXi-værten og hele cloud-systemets ydeevne. Den lette agent opretter en opgavekø for hver virtuel maskine: at kontrollere filsystemet, hukommelsen osv. Men det er SVM, som er ansvarlig for udførelsen af disse operationer, som vi taler om senere. Desuden udfører agenten funktioner som firewalls, kontrollerer sikkerhedspolitikkerne, sender inficerede filer til karantæne og overvåger den generelle 'sundhed' af operativsystemet, hvorpå den er installeret. Alt dette kan styres ved hjælp af det allerede nævnte enhedskonsol.
• Security Virtual Machine. Alle ressourcekrævende opgaver (opdateringer af antivirusdatabaser, planlagte scanninger) håndteres af en separat Security Virtual Machine (SVM). Den er ansvarlig for driften af en fuldgyldig antivirusmotor og dens databaser. Virksomhedens IT-infrastruktur kan inkludere flere SVM. Denne tilgang øger systemets pålidelighed — hvis en maskine fejler og ikke reagerer i tredive sekunder, begynder agenter automatisk at søge efter en anden.
• KSC integrationsserver. En af de komponenter i hoved-KSC, der tildeler sine SVM til lette agenter i henhold til den algoritme, der er indstillet i dens indstillinger, samt kontrollerer tilgængeligheden af SVM. Denne softwaremodul sikrer derved belastningsbalance på alle SVM i den cloud-baserede infrastruktur.
Algoritme til drift i skyen: reduktion af belastning på infrastrukturen
Generelt kan algoritmen for antivirusets drift præsenteres således. Agenten anmoder om en fil på den virtuelle maskine og scanner den. Resultatet af scanningen gemmes i den fælles centraliserede database af SVM's domme (den kaldes Shared Cache), hvor hver post identificerer et unikt filmønster. Denne tilgang sikrer, at den samme fil ikke scannes flere gange i træk (for eksempel hvis den er blevet åbnet på forskellige virtuelle maskiner). Filen scannes kun igen, hvis der er foretaget ændringer, eller hvis scanningen blev startet manuelt.
Implementering af antivirusløsningen i udbyderens cloud
Billedet viser den overordnede plan for implementeringen af løsningen i skyen. I administrationszonen for skyen er hoved Kaspersky Security Center blevet implementeret, og på hver ESXi-vært er en individuel SVM blevet implementeret ved hjælp af KSC integrationsserveren (hver ESXi-vært er knyttet til sin egen SVM med specifikke indstillinger i VMware vCenter Server). Kunderne arbejder i deres egne segmenter af skyen, hvor virtuelle maskiner med agenter er placeret. De administreres gennem individuelle KSC-servere, der er underlagt hoved KSC. Hvis der er behov for at beskytte et lille antal virtuelle maskiner (op til 5), kan kunden få adgang til den virtuelle konsol på en specialdedikeret KSC-server. Netværksinteraktionen mellem kundens KSC og hoved KSC, såvel som de lette agenter og SVM, sker ved hjælp af NAT gennem kundens virtuelle EdgeGW-routere.
Ifølge vores vurderinger og resultaterne fra tests af kolleger hos leverandøren, reducerer den lette agent belastningen på kundernes virtuelle infrastruktur med cirka 25% (sammenlignet med et system, der bruger traditionel antivirussoftware). Specifikt bruger standard Kaspersky Endpoint Security (KES) til fysiske miljøer næsten dobbelt så meget serverens procesortid (2,95%) sammenlignet med løsningen til virtualisering baseret på lette agenter (1,67%).
Graf over sammenligning af processorpåvirkning
En lignende situation ses med diskadgangsfrekvensen for skrivning: for klassisk antivirus er den 1011 IOPS, mens den for cloud antivirus er 671 IOPS.
Graf over sammenligning af diskadgangsfrekvens
Gevinsten i ydeevne gør det muligt at opretholde stabiliteten i infrastrukturen og udnytte de regnekraft bedre. Takket være tilpasningen til arbejde i et offentligt sky miljø sænker løsningen ikke skyens ydeevne: den udfører centralt filkontrol og opdateringsindlæsning, hvilket fordeler belastningen. Det betyder, at aktuelle trusler mod skyinfrastrukturen ikke vil blive overset, og samtidig vil ressourcernes krav til de virtuelle maskiner i gennemsnit blive reduceret med 25% sammenlignet med traditionelt antivirus.
Begge løsninger minder meget om hinanden med hensyn til funktionalitet: Nedenfor er en sammenligningstabel. Men som testresultaterne ovenfor viser, er det alligevel mest optimalt at bruge løsningen til virtuelle miljøer i skyen.
Om takseringen inden for den nye tilgang. Vi har valgt at anvende en model, der muliggør licensindhentning baseret på antallet af vCPU. Det betyder, at antallet af licenser svarer til antallet af vCPU. Antivirus kan testes ved at indsende en anmodning. .
I det følgende materiale om cloud-emner vil vi fortælle om udviklingen af cloud WAF og hvad der er bedst at vælge: hardware, software eller cloud.
Teksten er udarbejdet af medarbejdere hos cloud-udbyderen #CloudMTS: Denis Myagkov, førende arkitekt, og Alexey Afanasev, produktudviklingschef inden for informationssikkerhed.
Kilde: habr.com
