Ինչու ավանդական հակավիրուսները հարմար չեն հանրային ամպերի համար: Այսպիսով, ինչ պետք է անեմ:

Ավելի ու ավելի շատ օգտվողներ իրենց ամբողջ ՏՏ ենթակառուցվածքը բերում են հանրային ամպի մեջ: Այնուամենայնիվ, եթե հաճախորդի ենթակառուցվածքում հակավիրուսային հսկողությունը անբավարար է, լուրջ կիբեր ռիսկեր են առաջանում: Պրակտիկան ցույց է տալիս, որ գոյություն ունեցող վիրուսների մինչև 80%-ը հիանալի ապրում է վիրտուալ միջավայրում: Այս գրառման մեջ մենք կխոսենք այն մասին, թե ինչպես պաշտպանել ՏՏ ռեսուրսները հանրային ամպում և ինչու ավանդական հակավիրուսները լիովին հարմար չեն այդ նպատակների համար:

Սկզբից մենք ձեզ կպատմենք, թե ինչպես եկանք այն մտքին, որ հակավիրուսային պաշտպանության սովորական գործիքները հարմար չեն հանրային ամպի համար, և որ պահանջվում են ռեսուրսների պաշտպանության այլ մոտեցումներ:

Նախ, պրովայդերները, ընդհանուր առմամբ, ապահովում են անհրաժեշտ միջոցները՝ ապահովելու, որ իրենց ամպային հարթակները պաշտպանված են բարձր մակարդակով: Օրինակ, #CloudMTS-ում մենք վերլուծում ենք ցանցի ողջ երթևեկությունը, վերահսկում ենք մեր ամպի անվտանգության համակարգերի տեղեկամատյանները և կանոնավոր կերպով կատարում Pentests: Անհատական ​​հաճախորդներին հատկացված ամպային հատվածները նույնպես պետք է ապահով պաշտպանված լինեն:

Երկրորդ, կիբեր ռիսկերի դեմ պայքարի դասական տարբերակը ներառում է հակավիրուսային և հակավիրուսային կառավարման գործիքների տեղադրում յուրաքանչյուր վիրտուալ մեքենայի վրա: Այնուամենայնիվ, մեծ թվով վիրտուալ մեքենաների դեպքում այս պրակտիկան կարող է անարդյունավետ լինել և պահանջել զգալի քանակությամբ հաշվողական ռեսուրսներ՝ դրանով իսկ ավելի բեռնելով հաճախորդի ենթակառուցվածքը և նվազեցնելով ամպի ընդհանուր կատարումը: Սա հիմնական նախապայման է դարձել հաճախորդների վիրտուալ մեքենաների համար արդյունավետ հակավիրուսային պաշտպանություն ստեղծելու նոր մոտեցումների որոնման համար:

Բացի այդ, շուկայում հակավիրուսային լուծումների մեծ մասը հարմարեցված չէ հանրային ամպային միջավայրում ՏՏ ռեսուրսների պաշտպանության խնդիրները լուծելու համար: Որպես կանոն, դրանք ծանր քաշային EPP լուծումներ են (Endpoint Protection Platforms), որոնք, ավելին, չեն ապահովում անհրաժեշտ հարմարեցում ամպային մատակարարի հաճախորդի կողմից։

Ակնհայտ է դառնում, որ ավանդական հակավիրուսային լուծումները հարմար չեն ամպում աշխատելու համար, քանի որ դրանք լրջորեն բեռնում են վիրտուալ ենթակառուցվածքը թարմացումների և սկանավորման ժամանակ, ինչպես նաև չունեն դերի վրա հիմնված կառավարման և կարգավորումների անհրաժեշտ մակարդակներ: Հաջորդիվ մենք մանրամասն կվերլուծենք, թե ինչու են ամպին անհրաժեշտ հակավիրուսային պաշտպանության նոր մոտեցումներ։

Ինչ պետք է կարողանա անել հանրային ամպի հակավիրուսը

Այսպիսով, եկեք ուշադրություն դարձնենք վիրտուալ միջավայրում աշխատելու առանձնահատկություններին.

Թարմացումների և պլանավորված զանգվածային սկանավորումների արդյունավետությունը: Եթե ​​ավանդական հակավիրուսային օգտագործող վիրտուալ մեքենաների զգալի թվաքանակը միաժամանակ նախաձեռնում է թարմացում, ամպում կառաջանա թարմացումների այսպես կոչված «փոթորիկ»: ESXi հոսթի հզորությունը, որը հյուրընկալում է մի քանի վիրտուալ մեքենաներ, կարող է բավարար չլինել լռելյայնորեն կատարվող նմանատիպ առաջադրանքների տարափը լուծելու համար: Ամպային մատակարարի տեսանկյունից նման խնդիրը կարող է հանգեցնել լրացուցիչ բեռների մի շարք ESXi հոսթերների վրա, ինչը, ի վերջո, կհանգեցնի ամպային վիրտուալ ենթակառուցվածքի աշխատանքի անկմանը։ Սա, ի թիվս այլ բաների, կարող է ազդել այլ ամպային հաճախորդների վիրտուալ մեքենաների աշխատանքի վրա: Նմանատիպ իրավիճակ կարող է առաջանալ զանգվածային սկանավորման ժամանակ. տարբեր օգտվողների բազմաթիվ նմանատիպ հարցումների միաժամանակյա մշակումը սկավառակի համակարգի կողմից բացասաբար կանդրադառնա ամբողջ ամպի աշխատանքի վրա: Հավանականության բարձր աստիճանի դեպքում պահեստավորման համակարգի կատարողականի նվազումը կազդի բոլոր հաճախորդների վրա: Նման կտրուկ բեռները չեն գոհացնում ոչ մատակարարին, ոչ էլ նրա հաճախորդներին, քանի որ դրանք ազդում են ամպի «հարևանների» վրա: Այս տեսանկյունից ավանդական հակավիրուսը կարող է մեծ խնդիր առաջացնել։

Անվտանգ կարանտին. Եթե ​​համակարգում հայտնաբերվում է վիրուսով վարակված ֆայլ կամ փաստաթուղթ, այն ուղարկվում է կարանտին: Իհարկե, վարակված ֆայլը կարող է անմիջապես ջնջվել, բայց դա հաճախ անընդունելի է ընկերությունների մեծ մասի համար: Կորպորատիվ ձեռնարկությունների հակավիրուսները, որոնք հարմարեցված չեն մատակարարի ամպում աշխատելու համար, որպես կանոն, ունեն ընդհանուր կարանտինային գոտի. բոլոր վարակված օբյեկտները ընկնում են դրա մեջ: Օրինակ՝ ընկերության օգտատերերի համակարգիչներում հայտնաբերվածները։ Ամպային մատակարարի հաճախորդները «ապրում են» իրենց սեփական հատվածներում (կամ վարձակալներում): Այս հատվածները անթափանց և մեկուսացված են. հաճախորդները չգիտեն միմյանց մասին և, իհարկե, չեն տեսնում, թե ինչ են ուրիշները հոսթինգում ամպում: Ակնհայտ է, որ ընդհանուր կարանտինը, որին հասանելի կլինեն ամպի բոլոր հակավիրուսային օգտվողները, կարող է ներառել գաղտնի տեղեկատվություն կամ առևտրային գաղտնիք պարունակող փաստաթուղթ: Սա անընդունելի է մատակարարի և նրա հաճախորդների համար: Հետևաբար, լուծումը կարող է լինել միայն մեկ՝ անհատական ​​կարանտին իր սեգմենտի յուրաքանչյուր հաճախորդի համար, որտեղ մուտք չունեն ո՛չ մատակարարը, ո՛չ մյուս հաճախորդները։

Անհատական ​​անվտանգության քաղաքականություն. Ամպում յուրաքանչյուր հաճախորդ առանձին ընկերություն է, որի ՏՏ բաժինը սահմանում է իր անվտանգության քաղաքականությունը: Օրինակ, ադմինիստրատորները սահմանում են սկանավորման կանոններ և պլանավորում հակավիրուսային սկանավորումներ: Համապատասխանաբար, յուրաքանչյուր կազմակերպություն պետք է ունենա իր կառավարման կենտրոնը հակավիրուսային քաղաքականությունը կարգավորելու համար: Միևնույն ժամանակ, նշված կարգավորումները չպետք է ազդեն այլ ամպային հաճախորդների վրա, և մատակարարը պետք է կարողանա ստուգել, ​​որ, օրինակ, հակավիրուսային թարմացումներն իրականացվում են ինչպես սովորական բոլոր հաճախորդի վիրտուալ մեքենաների համար:

Բիլինգի և լիցենզավորման կազմակերպում: Ամպային մոդելը բնութագրվում է ճկունությամբ և ներառում է վճարում միայն հաճախորդի կողմից օգտագործված ՏՏ ռեսուրսների համար: Եթե ​​կա անհրաժեշտություն, օրինակ, սեզոնայնության պատճառով, ապա ռեսուրսների քանակը կարող է արագ աճել կամ կրճատվել, բոլորը հիմնված են հաշվողական հզորության ընթացիկ կարիքների վրա: Ավանդական հակավիրուսն այնքան էլ ճկուն չէ. որպես կանոն, հաճախորդը լիցենզիա է գնում մեկ տարով կանխորոշված ​​քանակությամբ սերվերների կամ աշխատակայանների համար: Ամպային օգտատերերը պարբերաբար անջատում և միացնում են լրացուցիչ վիրտուալ մեքենաներ՝ կախված իրենց ընթացիկ կարիքներից. համապատասխանաբար, հակավիրուսային լիցենզիաները պետք է աջակցեն նույն մոդելին:

Երկրորդ հարցն այն է, թե կոնկրետ ինչ է ընդգրկելու լիցենզիան։ Ավանդական հակավիրուսը լիցենզավորված է սերվերների կամ աշխատանքային կայանների քանակով: Պաշտպանված վիրտուալ մեքենաների քանակի վրա հիմնված լիցենզիաները լիովին հարմար չեն ամպային մոդելում: Հաճախորդը հասանելի ռեսուրսներից կարող է ստեղծել իրեն հարմար ցանկացած թվով վիրտուալ մեքենաներ, օրինակ՝ հինգ կամ տասը մեքենա։ Այս թիվը հաստատուն չէ հաճախորդների մեծ մասի համար, մեզ՝ որպես մատակարարի, հնարավոր չէ հետևել դրա փոփոխություններին: Պրոցեսորի կողմից լիցենզավորման տեխնիկական հնարավորություն չկա. հաճախորդները ստանում են վիրտուալ պրոցեսորներ (vCPU), որոնք պետք է օգտագործվեն լիցենզավորման համար: Այսպիսով, հակավիրուսային պաշտպանության նոր մոդելը պետք է ներառի հաճախորդի համար vCPU-ների պահանջվող քանակությունը որոշելու հնարավորություն, որոնց համար նա կստանա հակավիրուսային արտոնագրեր:

Համապատասխանություն օրենսդրությանը: Կարևոր կետ, քանի որ օգտագործվող լուծումները պետք է ապահովեն համապատասխանությունը կարգավորողի պահանջներին: Օրինակ, ամպի «բնակիչները» հաճախ աշխատում են անձնական տվյալների հետ: Այս դեպքում մատակարարը պետք է ունենա առանձին հավաստագրված ամպային հատված, որը լիովին համապատասխանում է Անձնական տվյալների մասին օրենքի պահանջներին: Այնուհետև ընկերությունները կարիք չունեն ինքնուրույն «կառուցել» անձնական տվյալների հետ աշխատելու ամբողջ համակարգը. ձեռք բերել հավաստագրված սարքավորումներ, միացնել և կարգավորել այն և անցնել սերտիֆիկացում: Նման հաճախորդների ISPD-ի կիբեր պաշտպանության համար հակավիրուսը պետք է նաև համապատասխանի Ռուսաստանի օրենսդրության պահանջներին և ունենա FSTEC վկայական:

Մենք ուսումնասիրեցինք այն պարտադիր չափանիշները, որոնց պետք է համապատասխանի հակավիրուսային պաշտպանությունը հանրային ամպում: Հաջորդը, մենք կկիսվենք մեր սեփական փորձով հակավիրուսային լուծումը մատակարարի ամպում աշխատելու համար հարմարեցնելու հարցում:

Ինչպե՞ս կարող եք ընկերներ ձեռք բերել հակավիրուսային և ամպի միջև:

Ինչպես ցույց է տվել մեր փորձը, նկարագրության և փաստաթղթերի վրա հիմնված լուծում ընտրելը մի բան է, բայց այն գործնականում կիրառելը արդեն իսկ գործող ամպային միջավայրում բարդության առումով բոլորովին այլ խնդիր է: Մենք ձեզ կասենք, թե ինչ ենք արել գործնականում և ինչպես ենք հարմարեցրել հակավիրուսը մատակարարի հանրային ամպում աշխատելու համար: Հակավիրուսային լուծումների մատակարարը Kaspersky-ն էր, որի պորտֆելը ներառում է հակավիրուսային պաշտպանության լուծումներ ամպային միջավայրերի համար: Մենք որոշեցինք «Kaspersky Security for Virtualization» (Light Agent) հարցը:

Այն ներառում է մեկ Kaspersky Security Center վահանակ: Թեթև գործակալ և անվտանգության վիրտուալ մեքենաներ (SVM, Security Virtual Machine) և KSC ինտեգրացիոն սերվեր:

Այն բանից հետո, երբ մենք ուսումնասիրեցինք Kaspersky-ի լուծման ճարտարապետությունը և վաճառողի ինժեներների հետ միասին անցկացրինք առաջին թեստերը, հարց առաջացավ ծառայությունը ամպի մեջ ինտեգրելու մասին: Առաջին ներդրումն իրականացվել է համատեղ Մոսկվայի ամպային կայքում։ Եվ դա այն է, ինչ մենք հասկացանք.

Ցանցի տրաֆիկը նվազագույնի հասցնելու համար որոշվեց SVM տեղադրել յուրաքանչյուր ESXi հոսթի վրա և SVM-ը «կապել» ESXi հոսթներին: Այս դեպքում, պաշտպանված վիրտուալ մեքենաների լուսային գործակալները մուտք են գործում այն ​​ճշգրիտ ESXi հոսթի SVM-ին, որի վրա նրանք աշխատում են: Հիմնական ԿՍԿ-ի համար ընտրվել է առանձին վարչական վարձակալ: Արդյունքում, ենթակա KSC-ները տեղակայված են յուրաքանչյուր առանձին հաճախորդի վարձակալներում և հասցեագրվում են կառավարման սեգմենտում գտնվող վերադաս KSC-ին: Այս սխեման թույլ է տալիս արագ լուծել խնդիրները, որոնք առաջանում են հաճախորդի վարձակալների մոտ:

Ի լրումն բուն հակավիրուսային լուծման բաղադրիչների բարձրացման հետ կապված խնդիրներին, մենք խնդիր ունեինք կազմակերպել ցանցային փոխգործակցությունը լրացուցիչ VxLAN-ների ստեղծման միջոցով: Եվ չնայած լուծումն ի սկզբանե նախատեսված էր մասնավոր ամպեր ունեցող ձեռնարկությունների հաճախորդների համար, NSX Edge-ի ինժեներական խոհեմության և տեխնոլոգիական ճկունության օգնությամբ մենք կարողացանք լուծել վարձակալների բաժանման և լիցենզավորման հետ կապված բոլոր խնդիրները:

Մենք սերտորեն համագործակցել ենք Kaspersky-ի ինժեներների հետ: Այսպիսով, համակարգի բաղադրիչների միջև ցանցային փոխազդեցության տեսանկյունից լուծման ճարտարապետության վերլուծության գործընթացում պարզվել է, որ, բացի լույսի գործակալներից SVM մուտք գործելուց, անհրաժեշտ է նաև հետադարձ կապ՝ SVM-ից մինչև լուսային գործակալներ: Ցանցային այս միացումը հնարավոր չէ բազմավարձակալ միջավայրում՝ տարբեր ամպային վարձակալների մեջ վիրտուալ մեքենաների նույնական ցանցային կարգավորումների հնարավորության պատճառով: Հետևաբար, մեր խնդրանքով, վաճառողի գործընկերները վերամշակեցին լուսային գործակալի և SVM-ի միջև ցանցային փոխազդեցության մեխանիզմը՝ SVM-ից լուսային գործակալներին ցանցային միացման անհրաժեշտությունը վերացնելու տեսանկյունից:

Այն բանից հետո, երբ լուծումը տեղադրվեց և փորձարկվեց Մոսկվայի ամպային կայքում, մենք այն կրկնօրինակեցինք այլ կայքերում, ներառյալ հավաստագրված ամպային հատվածը: Ծառայությունն այժմ հասանելի է հանրապետության բոլոր մարզերում։

Տեղեկատվական անվտանգության լուծման ճարտարապետություն նոր մոտեցման շրջանակներում

Հանրային ամպային միջավայրում հակավիրուսային լուծման գործողության ընդհանուր սխեման հետևյալն է.

Հակավիրուսային լուծման գործարկման սխեման հանրային ամպային միջավայրում #CloudMTS

Եկեք նկարագրենք ամպի մեջ լուծման առանձին տարրերի շահագործման առանձնահատկությունները.

• Մեկ վահանակ, որը թույլ է տալիս հաճախորդներին կենտրոնացված կերպով կառավարել պաշտպանական համակարգը. սկանավորել, վերահսկել թարմացումները և վերահսկել կարանտինային գոտիները: Հնարավոր է կարգավորել անհատական ​​անվտանգության քաղաքականությունը ձեր հատվածում:

Հարկ է նշել, որ չնայած մենք ծառայություններ մատուցող ենք, մենք չենք խանգարում հաճախորդների կողմից սահմանված կարգավորումներին: Միակ բանը, որ մենք կարող ենք անել, անվտանգության կանոնների վերակայումն է ստանդարտների, եթե անհրաժեշտ է վերակազմավորում: Օրինակ, դա կարող է անհրաժեշտ լինել, եթե հաճախորդը պատահաբար սեղմել է դրանք կամ զգալիորեն թուլացրել է դրանք: Ընկերությունը միշտ կարող է ստանալ կառավարման կենտրոն լռելյայն քաղաքականություններով, որը կարող է այնուհետև ինքնուրույն կարգավորել: Kaspersky Security Center-ի թերությունն այն է, որ հարթակը ներկայումս հասանելի է միայն Microsoft օպերացիոն համակարգի համար: Թեև թեթև գործակալները կարող են աշխատել ինչպես Windows, այնպես էլ Linux մեքենաների հետ: Այնուամենայնիվ, Kaspersky Lab-ը խոստանում է, որ մոտ ապագայում KSC-ն կաշխատի Linux OS-ով։ KSC-ի կարևոր գործառույթներից է կարանտինը կառավարելու ունակությունը։ Մեր ամպի յուրաքանչյուր հաճախորդ ընկերություն ունի անձնական ընկերություն: Այս մոտեցումը վերացնում է այն իրավիճակները, երբ վիրուսով վարակված փաստաթուղթը պատահաբար տեսանելի է դառնում հանրությանը, ինչպես դա կարող է պատահել ընդհանուր կարանտինով դասական կորպորատիվ հակավիրուսի դեպքում:

• Մեղմ գործակալներ. Որպես նոր մոդելի մաս, յուրաքանչյուր վիրտուալ մեքենայի վրա տեղադրված է թեթև Kaspersky Security գործակալ: Սա վերացնում է հակավիրուսային տվյալների բազան յուրաքանչյուր VM-ում պահելու անհրաժեշտությունը, ինչը նվազեցնում է սկավառակի պահանջվող տարածքը: Ծառայությունը ինտեգրված է ամպային ենթակառուցվածքի հետ և աշխատում է SVM-ի միջոցով, ինչը մեծացնում է վիրտուալ մեքենաների խտությունը ESXi հոսթի վրա և ամբողջ ամպային համակարգի կատարումը։ Լույսի գործակալը յուրաքանչյուր վիրտուալ մեքենայի համար առաջադրանքների հերթ է ստեղծում՝ ստուգեք ֆայլային համակարգը, հիշողությունը և այլն: Բայց SVM-ն պատասխանատու է այս գործողությունների կատարման համար, որոնց մասին մենք կխոսենք ավելի ուշ: Գործակալը նաև գործում է որպես firewall, վերահսկում է անվտանգության քաղաքականությունը, վարակված ֆայլերը ուղարկում է կարանտին և վերահսկում է օպերացիոն համակարգի ընդհանուր «առողջությունը», որի վրա այն տեղադրված է: Այս ամենը կարելի է կառավարել արդեն նշված մեկ վահանակի միջոցով:

• Անվտանգության վիրտուալ մեքենա: Բոլոր ռեսուրսների ինտենսիվ առաջադրանքները (հակավիրուսային տվյալների բազայի թարմացումներ, պլանավորված սկանավորումներ) իրականացվում են անվտանգության առանձին վիրտուալ մեքենայի (SVM) կողմից: Նա պատասխանատու է լիարժեք հակավիրուսային շարժիչի և դրա համար տվյալների բազաների շահագործման համար: Ընկերության ՏՏ ենթակառուցվածքը կարող է ներառել մի քանի SVM: Այս մոտեցումը մեծացնում է համակարգի հուսալիությունը. եթե մի մեքենա ձախողվի և չպատասխանի երեսուն վայրկյան, գործակալները ավտոմատ կերպով սկսում են մյուսը փնտրել:

• KSC ինտեգրացիոն սերվեր: Հիմնական KSC-ի բաղադրիչներից մեկը, որն իր SVM-ները վերագրում է լուսային գործակալներին՝ իր կարգավորումներում նշված ալգորիթմի համաձայն, ինչպես նաև վերահսկում է SVM-ների առկայությունը: Այսպիսով, այս ծրագրային մոդուլը ապահովում է բեռի հավասարակշռում ամպային ենթակառուցվածքի բոլոր SVM-ներում:

Ամպում աշխատելու ալգորիթմ. ենթակառուցվածքի բեռի նվազեցում

Ընդհանուր առմամբ, հակավիրուսային ալգորիթմը կարող է ներկայացվել հետևյալ կերպ. Գործակալը մուտք է գործում ֆայլը վիրտուալ մեքենայի վրա և ստուգում այն: Ստուգման արդյունքը պահվում է ընդհանուր կենտրոնացված SVM դատավճիռների տվյալների բազայում (կոչվում է Համօգտագործվող քեշ), որտեղ յուրաքանչյուր գրառում նույնականացնում է ֆայլի եզակի նմուշ: Այս մոտեցումը թույլ է տալիս ապահովել, որ նույն ֆայլը մի քանի անգամ անընդմեջ սկանավորվի (օրինակ, եթե այն բացվել է տարբեր վիրտուալ մեքենաներում): Ֆայլը նորից սկանավորվում է միայն այն դեպքում, եթե դրանում փոփոխություններ են կատարվել կամ սկանավորումը սկսվել է ձեռքով:

Հակավիրուսային լուծման ներդրում պրովայդերի ամպում

Պատկերը ցույց է տալիս ամպում լուծման իրականացման ընդհանուր դիագրամը: Հիմնական Kaspersky Security Center-ը տեղակայված է ամպի կառավարման գոտում, և յուրաքանչյուր ESXi հոսթի վրա տեղադրվում է անհատական ​​SVM՝ օգտագործելով KSC ինտեգրման սերվերը (յուրաքանչյուր ESXi հոսթ ունի իր SVM-ն՝ հատուկ կարգավորումներով VMware vCenter Server-ի վրա): Հաճախորդներն աշխատում են իրենց ամպային հատվածներում, որտեղ տեղակայված են գործակալներով վիրտուալ մեքենաներ: Դրանք կառավարվում են հիմնական KSC-ին ենթակա անհատական ​​KSC սերվերների միջոցով: Եթե ​​անհրաժեշտ է պաշտպանել փոքր թվով վիրտուալ մեքենաներ (մինչև 5), հաճախորդը կարող է մուտք գործել հատուկ հատուկ KSC սերվերի վիրտուալ վահանակ: Ցանցային փոխազդեցությունը հաճախորդի KSC-ների և հիմնական KSC-ի, ինչպես նաև լուսային գործակալների և SVM-ների միջև իրականացվում է NAT-ի միջոցով EdgeGW հաճախորդի վիրտուալ երթուղիչների միջոցով:

Ըստ մեր գնահատականների և վաճառողի գործընկերների թեստերի արդյունքների՝ Light Agent-ը նվազեցնում է հաճախորդների վիրտուալ ենթակառուցվածքի բեռը մոտավորապես 25%-ով (երբ համեմատվում է ավանդական հակավիրուսային ծրագրակազմ օգտագործող համակարգի հետ): Մասնավորապես, ստանդարտ Kaspersky Endpoint Security (KES) հակավիրուսը ֆիզիկական միջավայրերի համար սպառում է գրեթե երկու անգամ ավելի շատ սերվերի պրոցեսորի ժամանակ (2,95%), քան գործակալների վրա հիմնված վիրտուալացման թեթև լուծումը (1,67%):

CPU-ի բեռնվածության համեմատական ​​աղյուսակը

Նմանատիպ իրավիճակ է նկատվում սկավառակի գրելու մուտքերի հաճախականության դեպքում՝ դասական հակավիրուսի համար այն 1011 IOPS է, ամպային հակավիրուսի համար՝ 671 IOPS։

Սկավառակի մուտքի արագության համեմատության գրաֆիկ

Կատարման առավելությունը թույլ է տալիս պահպանել ենթակառուցվածքի կայունությունը և ավելի արդյունավետ օգտագործել հաշվողական հզորությունը: Հարմարվելով հանրային ամպային միջավայրում աշխատելուն՝ լուծումը չի նվազեցնում ամպի արդյունավետությունը. այն կենտրոնացված կերպով ստուգում է ֆայլերը և ներբեռնում թարմացումները՝ բաշխելով բեռը: Սա նշանակում է, որ մի կողմից ամպային ենթակառուցվածքին առնչվող սպառնալիքները բաց չեն թողնի, մյուս կողմից՝ վիրտուալ մեքենաների համար ռեսուրսների պահանջները կնվազեն միջինը 25%-ով՝ համեմատած ավանդական հակավիրուսի։

Ֆունկցիոնալության առումով երկու լուծումներն էլ շատ նման են միմյանց. ստորև ներկայացված է համեմատական ​​աղյուսակ: Այնուամենայնիվ, ամպում, ինչպես ցույց են տալիս վերը նշված թեստի արդյունքները, դեռ օպտիմալ է լուծում օգտագործել վիրտուալ միջավայրերի համար:

Նոր մոտեցման շրջանակներում սակագների մասին. Մենք որոշեցինք օգտագործել մոդել, որը թույլ է տալիս մեզ լիցենզիաներ ստանալ՝ հիմնվելով vCPU-ների քանակի վրա: Սա նշանակում է, որ լիցենզիաների թիվը հավասար կլինի vCPU-ների թվին: Դուք կարող եք ստուգել ձեր հակավիրուսը՝ թողնելով հարցում առցանց.

Ամպային թեմաների վերաբերյալ հաջորդ հոդվածում մենք կխոսենք ամպային WAF-ների էվոլյուցիայի և այն մասին, թե որն է ավելի լավ ընտրել՝ սարքաշար, ծրագրաշար կամ ամպ:

Տեքստը պատրաստել են #CloudMTS ամպային մատակարարի աշխատակիցները՝ առաջատար ճարտարապետ Դենիս Մյագկովը և տեղեկատվական անվտանգության արտադրանքի մշակման մենեջեր Ալեքսեյ Աֆանասևը։

Source: www.habr.com