Flere og flere brugere bringer hele deres it-infrastruktur til den offentlige sky. Men hvis antiviruskontrol er utilstrækkelig i kundens infrastruktur, opstår der alvorlige cyberrisici. Praksis viser, at op til 80 % af eksisterende vira lever perfekt i et virtuelt miljø. I dette indlæg vil vi tale om, hvordan man beskytter it-ressourcer i den offentlige sky, og hvorfor traditionelle antivirus ikke er helt egnede til disse formål.
Til at begynde med vil vi fortælle dig, hvordan vi kom til ideen om, at de sædvanlige antivirus-beskyttelsesværktøjer ikke er egnede til den offentlige sky, og at andre tilgange til beskyttelse af ressourcer er påkrævet.
For det første sørger udbydere generelt for de nødvendige foranstaltninger for at sikre, at deres cloud-platforme er beskyttet på et højt niveau. For eksempel analyserer vi på #CloudMTS al netværkstrafik, overvåger logfiler for vores clouds sikkerhedssystemer og udfører regelmæssigt pentests. Cloud-segmenter, der er allokeret til individuelle klienter, skal også være sikkert beskyttet.
For det andet involverer den klassiske mulighed for bekæmpelse af cyberrisici at installere et antivirus- og antivirusstyringsværktøj på hver virtuel maskine. Men med et stort antal virtuelle maskiner kan denne praksis være ineffektiv og kræve betydelige mængder computerressourcer, hvorved kundens infrastruktur belastes yderligere og skyens overordnede ydeevne reduceres. Dette er blevet en vigtig forudsætning for at søge efter nye tilgange til opbygning af effektiv antivirusbeskyttelse til kunders virtuelle maskiner.
Derudover er de fleste antivirusløsninger på markedet ikke tilpasset til at løse problemerne med at beskytte it-ressourcer i et offentligt cloudmiljø. Som udgangspunkt er der tale om tunge EPP-løsninger (Endpoint Protection Platforms), som i øvrigt ikke giver den nødvendige tilpasning på klientsiden hos cloud-udbyderen.
Det bliver tydeligt, at traditionelle antivirusløsninger ikke er egnede til at arbejde i skyen, da de for alvor belaster den virtuelle infrastruktur under opdateringer og scanninger, og heller ikke har de nødvendige niveauer af rollebaseret styring og indstillinger. Dernæst vil vi analysere i detaljer, hvorfor skyen har brug for nye tilgange til antivirusbeskyttelse.
Hvad et antivirus i en offentlig sky burde kunne
Så lad os være opmærksomme på detaljerne ved at arbejde i et virtuelt miljø:
Effektivitet af opdateringer og planlagte massescanninger. Hvis et betydeligt antal virtuelle maskiner, der anvender et traditionelt antivirus, starter en opdatering på samme tid, vil der opstå en såkaldt "storm" af opdateringer i skyen. Kraften i en ESXi-vært, der er vært for flere virtuelle maskiner, er muligvis ikke nok til at håndtere mængden af lignende opgaver, der kører som standard. Fra skyudbyderens synspunkt kan et sådant problem føre til yderligere belastninger på en række ESXi-værter, hvilket i sidste ende vil føre til et fald i ydeevnen af den virtuelle cloud-infrastruktur. Dette kan blandt andet påvirke ydeevnen af virtuelle maskiner fra andre cloud-klienter. En lignende situation kan opstå, når du starter en massescanning: samtidig behandling af disksystemet af mange lignende anmodninger fra forskellige brugere vil påvirke ydeevnen af hele skyen negativt. Med en høj grad af sandsynlighed vil et fald i lagersystemets ydeevne påvirke alle klienter. Sådanne pludselige belastninger behager hverken udbyderen eller hans kunder, da de påvirker "naboerne" i skyen. Fra dette synspunkt kan traditionel antivirus udgøre et stort problem.
Sikker karantæne. Hvis en fil eller et dokument, der potentielt er inficeret med en virus, opdages på systemet, sendes det i karantæne. Selvfølgelig kan en inficeret fil slettes med det samme, men det er ofte ikke acceptabelt for de fleste virksomheder. Virksomhedsantivirus, der ikke er tilpasset til at arbejde i udbyderens sky, har som regel en fælles karantænezone - alle inficerede objekter falder ind i den. For eksempel dem, der findes på virksomhedens brugeres computere. Kunder hos cloud-udbyderen "bor" i deres egne segmenter (eller lejere). Disse segmenter er uigennemsigtige og isolerede: klienter kender ikke hinanden og kan selvfølgelig ikke se, hvad andre hoster i skyen. Det er klart, at den generelle karantæne, som vil blive tilgået af alle antivirusbrugere i skyen, potentielt kan omfatte et dokument, der indeholder fortrolige oplysninger eller en forretningshemmelighed. Dette er uacceptabelt for udbyderen og dennes kunder. Derfor kan der kun være én løsning – personlig karantæne for hver kunde i sit segment, hvor hverken udbyderen eller andre kunder har adgang.
Individuelle sikkerhedspolitikker. Hver klient i skyen er en separat virksomhed, hvis it-afdeling fastsætter sine egne sikkerhedspolitikker. For eksempel definerer administratorer scanningsregler og planlægger antivirusscanninger. Derfor skal hver organisation have sit eget kontrolcenter til at konfigurere antiviruspolitikker. Samtidig skal de angivne indstillinger ikke påvirke andre cloud-klienter, og udbyderen skal kunne verificere, at eksempelvis antivirus-opdateringer udføres som normalt for alle klient-virtuelle maskiner.
Organisering af fakturering og licensering. Cloud-modellen er kendetegnet ved fleksibilitet og involverer kun betaling for den mængde it-ressourcer, som blev brugt af kunden. Hvis der er behov, for eksempel på grund af sæsonudsving, så kan mængden af ressourcer hurtigt øges eller reduceres – alt sammen ud fra det aktuelle behov for computerkraft. Traditionel antivirus er ikke så fleksibel - som regel køber klienten en licens for et år til et forudbestemt antal servere eller arbejdsstationer. Cloud-brugere afbryder og forbinder regelmæssigt yderligere virtuelle maskiner afhængigt af deres aktuelle behov - derfor skal antiviruslicenser understøtte den samme model.
Det andet spørgsmål er, hvad licensen præcist vil dække. Traditionel antivirus er licenseret af antallet af servere eller arbejdsstationer. Licenser baseret på antallet af beskyttede virtuelle maskiner er ikke helt egnede i skymodellen. Klienten kan oprette et hvilket som helst antal virtuelle maskiner, der er praktiske for ham, fra de tilgængelige ressourcer, for eksempel fem eller ti maskiner. Dette tal er ikke konstant for de fleste kunder; det er ikke muligt for os som udbyder at spore ændringerne. Der er ingen teknisk mulighed for at licensere med CPU: klienter modtager virtuelle processorer (vCPU'er), som skal bruges til licensering. Den nye antivirus-beskyttelsesmodel bør således omfatte muligheden for, at kunden kan bestemme det nødvendige antal vCPU'er, som han vil modtage antiviruslicenser for.
Overholdelse af lovgivning. En vigtig pointe, da de anvendte løsninger skal sikre overholdelse af regulatorens krav. For eksempel arbejder cloud-"beboere" ofte med personlige data. I dette tilfælde skal udbyderen have et separat certificeret cloudsegment, der fuldt ud overholder kravene i persondataloven. Så behøver virksomhederne ikke selvstændigt at "bygge" hele systemet til at arbejde med persondata: købe certificeret udstyr, tilslutte og konfigurere det og gennemgå certificering. For cyberbeskyttelse af sådanne klienters ISPD skal antivirussen også overholde kravene i russisk lovgivning og have et FSTEC-certifikat.
Vi har set på de obligatoriske kriterier, som antivirusbeskyttelse i den offentlige sky skal opfylde. Dernæst vil vi dele vores egen erfaring med at tilpasse en antivirusløsning til at fungere i udbyderens sky.
Hvordan kan du få venner mellem antivirus og cloud?
Som vores erfaring har vist, er valg af løsning baseret på beskrivelse og dokumentation én ting, men at implementere det i praksis i et allerede fungerende cloudmiljø er en helt anden opgave i forhold til kompleksitet. Vi fortæller dig, hvad vi gjorde i praksis, og hvordan vi tilpassede antivirusprogrammet til at fungere i udbyderens offentlige sky. Sælgeren af antivirusløsningen var Kaspersky, hvis portefølje omfatter antivirusbeskyttelsesløsninger til cloudmiljøer. Vi slog os fast på "Kaspersky Security for Virtualization" (Light Agent).
Det inkluderer en enkelt Kaspersky Security Center-konsol. Light agent og virtuelle sikkerhedsmaskiner (SVM, Security Virtual Machine) og KSC integrationsserver.
Efter at vi havde studeret arkitekturen af Kaspersky-løsningen og gennemført de første tests sammen med leverandørens ingeniører, opstod spørgsmålet om at integrere tjenesten i skyen. Den første implementering blev udført i fællesskab på Moskva-skystedet. Og det indså vi.
For at minimere netværkstrafikken blev det besluttet at placere en SVM på hver ESXi-vært og "binde" SVM'en til ESXi-værterne. I dette tilfælde får lette agenter fra beskyttede virtuelle maskiner adgang til SVM for den nøjagtige ESXi-vært, som de kører på. En separat administrativ lejer blev valgt til hoved-KSC. Som følge heraf er underordnede KSC'er placeret i lejerne af hver enkelt klient og adresserer den overordnede KSC placeret i ledelsessegmentet. Denne ordning giver dig mulighed for hurtigt at løse problemer, der opstår hos klientlejere.
Ud over problemer med at hæve komponenterne i selve antivirusløsningen, stod vi over for opgaven med at organisere netværksinteraktion gennem oprettelse af yderligere VxLAN'er. Og selvom løsningen oprindeligt var beregnet til virksomhedskunder med private skyer, var vi ved hjælp af den tekniske ekspertise og teknologiske fleksibilitet i NSX Edge i stand til at løse alle problemerne forbundet med adskillelse af lejere og licensering.
Vi arbejdede tæt sammen med Kasperskys ingeniører. I processen med at analysere løsningsarkitekturen mht. netværksinteraktion mellem systemkomponenter fandt man således ud af, at der udover adgang fra lysagenter til SVM også er behov for feedback - fra SVM til lysagenter. Denne netværksforbindelse er ikke mulig i et multitenant-miljø på grund af muligheden for identiske netværksindstillinger for virtuelle maskiner i forskellige cloud-lejere. Derfor omarbejdede kolleger fra leverandøren på vores anmodning mekanismen for netværksinteraktion mellem lysagenten og SVM med hensyn til at eliminere behovet for netværksforbindelse fra SVM til lysagenter.
Efter at løsningen var blevet implementeret og testet på Moskvas cloud-websted, replikerede vi den til andre websteder, inklusive det certificerede cloud-segment. Tjenesten er nu tilgængelig i alle regioner i landet.
Arkitektur af en informationssikkerhedsløsning inden for rammerne af en ny tilgang
Det generelle skema for drift af en antivirusløsning i et offentligt cloudmiljø er som følger:
Driftsskema for en antivirusløsning i et offentligt cloudmiljø #CloudMTS
Lad os beskrive funktionerne i driften af individuelle elementer af løsningen i skyen:
• En enkelt konsol, der giver klienter mulighed for centralt at administrere beskyttelsessystemet: køre scanninger, kontrollere opdateringer og overvåge karantænezoner. Det er muligt at konfigurere individuelle sikkerhedspolitikker inden for dit segment.
Det skal bemærkes, at selvom vi er en tjenesteudbyder, forstyrrer vi ikke de indstillinger, som klienterne har angivet. Det eneste, vi kan gøre, er at nulstille sikkerhedspolitikkerne til standardpolitikkerne, hvis omkonfiguration er nødvendig. Det kan for eksempel være nødvendigt, hvis klienten ved et uheld strammede dem eller svækkede dem væsentligt. En virksomhed kan altid modtage et kontrolcenter med standardpolitikker, som den derefter kan konfigurere selvstændigt. Ulempen ved Kaspersky Security Center er, at platformen i øjeblikket kun er tilgængelig for Microsoft-operativsystemet. Selvom lette agenter kan arbejde med både Windows- og Linux-maskiner. Kaspersky Lab lover dog, at KSC i den nærmeste fremtid vil arbejde under Linux OS. En af KSCs vigtige funktioner er evnen til at styre karantæne. Hver kundevirksomhed i vores sky har en personlig. Denne tilgang eliminerer situationer, hvor et dokument, der er inficeret med en virus, ved et uheld bliver offentligt synligt, hvilket kunne ske i tilfælde af et klassisk firma-antivirus med generel karantæne.
• Lysmidler. Som en del af den nye model er en let Kaspersky Security-agent installeret på hver virtuel maskine. Dette eliminerer behovet for at gemme antivirusdatabasen på hver VM, hvilket reducerer mængden af krævet diskplads. Tjenesten er integreret med cloud-infrastrukturen og fungerer gennem SVM, som øger tætheden af virtuelle maskiner på ESXi-værten og ydeevnen af hele cloud-systemet. Light-agenten opbygger en kø af opgaver for hver virtuel maskine: tjek filsystemet, hukommelsen osv. Men SVM er ansvarlig for at udføre disse operationer, som vi vil tale om senere. Agenten fungerer også som en firewall, kontrollerer sikkerhedspolitikker, sender inficerede filer i karantæne og overvåger den overordnede "sundhed" af det operativsystem, som den er installeret på. Alt dette kan styres ved hjælp af den allerede nævnte enkeltkonsol.
• Sikkerhed virtuel maskine. Alle ressourcekrævende opgaver (antivirusdatabaseopdateringer, planlagte scanninger) håndteres af en separat Security Virtual Machine (SVM). Hun er ansvarlig for driften af en fuldgyldig antivirusmotor og databaser til den. En virksomheds it-infrastruktur kan omfatte flere SVM'er. Denne tilgang øger systemets pålidelighed - hvis en maskine fejler og ikke reagerer i tredive sekunder, begynder agenter automatisk at lede efter en anden.
• KSC integrationsserver. En af komponenterne i hoved-KSC, som tildeler sine SVM'er til lysagenter i overensstemmelse med den algoritme, der er angivet i dens indstillinger, og kontrollerer også tilgængeligheden af SVM'er. Dette softwaremodul giver således belastningsbalancering på tværs af alle SVM'er i cloud-infrastrukturen.
Algoritme til at arbejde i skyen: reduktion af belastningen på infrastrukturen
Generelt kan antivirusalgoritmen repræsenteres som følger. Agenten får adgang til filen på den virtuelle maskine og kontrollerer den. Resultatet af verifikationen gemmes i en fælles centraliseret SVM-domsdatabase (kaldet Shared Cache), hvor hver post identificerer en unik filprøve. Denne tilgang giver dig mulighed for at sikre, at den samme fil ikke scannes flere gange i træk (for eksempel hvis den blev åbnet på forskellige virtuelle maskiner). Filen genscannes kun, hvis der er foretaget ændringer i den, eller scanningen er startet manuelt.
Implementering af en antivirusløsning i udbyderens sky
Billedet viser et generelt diagram over løsningens implementering i skyen. Det vigtigste Kaspersky Security Center er installeret i skyens kontrolzone, og en individuel SVM installeres på hver ESXi-vært ved hjælp af KSC-integrationsserveren (hver ESXi-vært har sin egen SVM tilknyttet med specielle indstillinger på VMware vCenter Server). Klienter arbejder i deres egne cloud-segmenter, hvor virtuelle maskiner med agenter er placeret. De styres gennem individuelle KSC-servere underordnet hoved-KSC. Hvis det er nødvendigt at beskytte et lille antal virtuelle maskiner (op til 5), kan klienten få adgang til den virtuelle konsol på en speciel dedikeret KSC-server. Netværksinteraktion mellem klient-KSC'er og hoved-KSC'er, såvel som lysagenter og SVM'er, udføres ved hjælp af NAT gennem EdgeGW-klient virtuelle routere.
Ifølge vores estimater og resultaterne af test af kolleger hos leverandøren, reducerer Light Agent belastningen på kundernes virtuelle infrastruktur med cirka 25 % (sammenlignet med et system, der bruger traditionel antivirussoftware). Især den standard Kaspersky Endpoint Security (KES) antivirus til fysiske miljøer bruger næsten dobbelt så meget server-CPU-tid (2,95 %) som en let agentbaseret virtualiseringsløsning (1,67 %).
Sammenligningsdiagram for CPU-belastning
En lignende situation observeres med hyppigheden af diskskriveadgange: for et klassisk antivirus er det 1011 IOPS, for et cloud-antivirus er det 671 IOPS.
Sammenligningsgraf for diskadgangshastighed
Ydeevnefordelen giver dig mulighed for at bevare infrastrukturens stabilitet og bruge computerkraft mere effektivt. Ved at tilpasse sig til at arbejde i et offentligt cloudmiljø reducerer løsningen ikke skyydelsen: den tjekker filer centralt og downloader opdateringer og fordeler belastningen. Det betyder på den ene side, at trusler, der er relevante for cloud-infrastrukturen, ikke kommer til at gå glip af, på den anden side reduceres ressourcekravene til virtuelle maskiner med i gennemsnit 25 % sammenlignet med et traditionelt antivirus.
Med hensyn til funktionalitet minder begge løsninger meget om hinanden: nedenfor er en sammenligningstabel. Men i skyen er det, som testresultaterne ovenfor viser, stadig optimalt at bruge en løsning til virtuelle miljøer.
Om takster inden for rammerne af den nye tilgang. Vi besluttede at bruge en model, der giver os mulighed for at opnå licenser baseret på antallet af vCPU'er. Det betyder, at antallet af licenser vil være lig med antallet af vCPU'er. Du kan teste dit antivirus ved at efterlade en anmodning .
I den næste artikel om cloud-emner vil vi tale om udviklingen af cloud WAF'er og hvad der er bedre at vælge: hardware, software eller cloud.
Teksten er udarbejdet af medarbejdere hos cloud-udbyderen #CloudMTS: Denis Myagkov, førende arkitekt og Alexey Afanasyev, produktudviklingschef for informationssikkerhed.
Kilde: www.habr.com