Սա վեցից չորրորդ մասն է այն մասին, թե ինչպես գնահատել ցանցային անվտանգության արտադրանքը։ Մաս 1՝ datasheet-ների կառուցվածքային տարբերությունը։ Մաս 2՝ NGFW-ի ծուղակները։ Մաս 3՝ WAF, IPS, DLP։
SASE-ն դնում է այլ դասի գնահատման խնդիր՝ տեղական սարքավորման համեմատ։ SASE ներդրման արտադրողականությունը արտադրանքի ֆիքսված հատկություն չէ։ Դա ճարտարապետության, աշխարհագրության, ընդհանուր ենթակառուցվածքի ծանրաբեռնվածության և ձեր օգտատերերի ու հավելվածների միջև կոնկրետ երթուղու ֆունկցիա է տվյալ պահին։ Դրա պատճառով վենդորի մարկետինգային նյութերի թվերը հատկապես վատ են կանխատեսում այն, ինչ կստանաք դուք։
Տեղական NGFW-ն ձեր դարակում առանձնացված սարքավորում է։ Նրա արտադրողականության միջակայքը դետերմինիստական է․ նույն տրաֆիկի պրոֆիլը կայունորեն տալիս է նույն throughput-ը և latency-ն, որովհետև ռեսուրսների համար ուրիշ ոչ ոք չի մրցում։
SASE-ի PoP-ը ընդհանուր ենթակառուցվածք է։ Մեկ PoP-ը միաժամանակ սպասարկում է տասնյակ կամ հարյուրավոր կորպորատիվ հաճախորդների։ Հզորությունը միավորված է pool-ի մեջ։ Ծանրաբեռնվածությունը փոխվում է ըստ օրվա ժամի, շաբաթվա օրվա և տարածաշրջանային տրաֆիկի փաթերների, որոնք ձեր ներդրմանն առնչություն չունեն։
Վենդորի demo-ն վերահսկվող կետից, ընտրված ժամային գոտու աշխատանքային ժամերին, վենդորի վերահսկվող endpoint-ին ցույց է տալիս, թե ինչ կարող է տալ պլատֆորմն իդեալական պայմաններում՝ առանձնացված ուշադրությամբ։ Այն չի ասում, թե ինչ կստանան ձեր հեռավոր օգտատերերը տարբեր գրասենյակներից երկուշաբթի առավոտյան պիկին, երբ տարածաշրջանային PoP-ը մի քանի արենդատորի միաժամանակյա ծանրաբեռնվածության տակ է։
Սա վարկած չէ։ Արտադրողականության ցրվածությունն ըստ ժամանակի և PoP-ի դիրքի ընդհանուր ամպային ենթակառուցվածքի կառուցվածքային հատկություն է։ SASE-ի գնահատումը պահանջում է չափել արտադրողականությունը ձեր օգտատերերի իրական կետերից, ձեր հավելվածների իրական endpoint-ներին, մի քանի ժամանակային պատուհանում՝ ներառյալ պիկայինները։
SASE-ի ճարտարապետությունը տրաֆիկի ուղում դնում է անվտանգության մի քանի ֆունկցիա։ Ամեն մեկն ավելացնում է latency։ Վենդորի սխեմայի վրա սրանք դիսկրետ գումարելիներ են։ Ինչպես է latency-ն գումարվում միաժամանակյա ծանրաբեռնվածության տակ, գործնականում ավելի բարդ է։
Ֆունկցիաները, որոնք սովորաբար կանգնած են SASE-ի inline ուղում՝ ZTNA բրոկեր, SWG, CASB, URL-ֆիլտրում, DLP inspection, բրաուզերի իզոլյացիա, SSL inspection։ Ամեն մեկը մշակում է տրաֆիկը մինչև փոխանցումը։ Ցածր ծանրաբեռնվածության դեպքում ամեն մեկի latency-ն փոքր է, գումարը կառավարելի է։ Բարձր կոնկուրենտության դեպքում՝ շատ օգտատերեր, շատ միաժամանակյա սեսիաներ, պիկային ժամանակահատվածներ՝ հերթերի էֆեկտները և բաղադրիչների փոխազդեցությունը տալիս են latency-ի ոչ գծային աճ։
Վենդորները սովորաբար բերում են ֆունկցիաների latency-ն՝ չափված առանձին։ End-to-end latency-ն բոլոր ֆունկցիաներով՝ իրատեսական միաժամանակյա ծանրաբեռնվածության տակ, հրապարակում են հազվադեպ։ Այս թվերի տարբերությունն այն է, ինչ կնկատեն ձեր օգտատերերը։
SASE-ի գնահատման ժամանակ պահանջեք end-to-end latency-ի չափումներ՝ օգտատիրոջ բնորոշ կետում գտնվող կլիենտ-ագենտից մինչև բնորոշ հավելված՝ միացված լրիվ նպատակային պաշտպանության ստեկով, ձեր միաժամանակյա սեսիաների պիկային քանակին համապատասխան ծանրաբեռնվածության տակ։
SASE պլատֆորմները, որոնք անում են SSL/TLS inspection, տերմինացնում և վերահաստատում են ամեն օգտատիրոջ ամեն TLS սեսիան PoP-ի մակարդակում։ Անվտանգության օգուտն իրական է․ առանց inspection-ի շիֆրված տրաֆիկն անցնում է պաշտպանության ստեկը՝ առանց բովանդակության վերլուծության։
Գործառնական և արտադրողականության հետևանքները հաճախ թերասում են։
Սերտիֆիկատների կառավարում։ TLS inspection-ը պահանջում է, որ PoP-ը ներկայացնի սերտիֆիկատ, որին վստահում են վերջնական սարքերը։ Սա բաշխված ընկերությունում կառավարելը՝ BYOD-ով, հյուր սարքերով և certificate pinning-ով հավելվածներով՝ գործառնական բարդություն է, և դա երևում է ներդրման ժամանակ, ոչ demo-ում։
Inspection-ի ճշգրտությունը բարձր էնտրոպիայով շիֆրված տրաֆիկի վրա։ Ժամանակակից TLS 1.3-ը շիֆրված SNI-ով և ESNI-ով սահմանափակում է մետատվյալները, որ հասանելի են մինչև վերծանումը։ Դասակարգման ճշգրտությունը և քաղաքականությունների ճշտությունն այս պայմաններում տարբեր վենդորների մոտ տարբեր է և գնահատումների ժամանակ հազվադեպ է ստուգվում իրատեսական ժամանակակից TLS-ի վրա։
Throughput-ը միաժամանակյա TLS սեսիաների դեպքում։ Վենդորի PoP-ը, որ TLS է տերմինացնում հազարավոր միաժամանակյա կորպորատիվ սեսիաների համար, անընդհատ անում է անհամաչափ կրիպտոգրաֆիա։ Մի քանի թեստային կլիենտի վրա չափված թվերը կորպորատիվ մասշտաբում պահվածքը չեն կանխատեսում։ Եթե ունեք տասնյակ հազարավոր հեռավոր օգտատերեր ընդհանուր PoP-ով, թեստավորեք պլատֆորմն այդ կոնկուրենտությանը մոտ ծանրաբեռնվածության վրա, ոչ թե ստերիլ լաբորատոր սցենարի վրա։
Ասեմ ուղիղ․ ոչ մի հրապարակված SASE բենչմարկ չեն չափել ձեր կոնկրետ ներդրման պայմաններում։
Հրապարակված բենչմարկներն անում են վենդորի ենթակառուցվածքի վրա, վենդորի ընտրած endpoint-ների միջև, վենդորի ընտրած ժամին։ Դրանք օպտիմիզացնում են լավագույն թվի տակ։ Ձեր ներդրման մեջ․
Latency-ն և throughput-ը, որ կստանաք դուք, որոշվում են այս իրական պայմաններով։ Դրանք կանխատեսելը հնարավոր է միայն չափմամբ՝ իրական ագենտներով օգտատերերի իրական կետերում, հավելվածների իրական endpoint-ներին, այն ժամանակային պատուհաններում, որոնք կարևոր են բիզնեսի աշխատանքի համար։
SASE-ի PoC-ը, որ գնում է մեկ թեստային կետից, վենդորի hosting-ի demo-հավելվածին, մի քանի ժամ նշանակված պատուհանում, օգտակար տվյալներ չի տալիս։ Այն տալիս է մարկետինգային որակի թվեր, որոնք լավ տեսք ունեն ընտրության հանձնաժողովի պրեզենտացիայում։
SASE-ի գնահատումը, որ տալիս է որոշման մակարդակի արդյունքներ, պահանջում է սարքավորման թեստավորումից այլ մոտեցում։
Տեղադրեք ագենտներ օգտատերերի բնորոշ կետերում։ Եթե ձեր օգտատերերն Երևանում, Լոնդոնում, Սինգապուրում և Սան Պաուլուում են՝ սրանք են չափման կետերը։ Տրաֆիկը պետք է գնա այս վայրերից SASE ստեկով դեպի ձեր իրական հավելվածները։
Չափեք հավելվածների իրական endpoint-ներով։ Ձեր բիզնեսի համար կրիտիկական հավելվածները՝ ERP, համագործակցության գործիքներ, ամպային պահեստ՝ ահա նպատակը։ Վենդորի hosting-ի demo-endpoint-ները չեն արտացոլում ձեր իրական հավելվածների երթուղիները, latency-ի բնութագրերը և TLS պրոֆիլները։
Թեստավորեք մի քանի ժամանակային պատուհանում։ Երկուշաբթի ժամը 9-ը, չորեքշաբթի ժամը 14-ը և ուրբաթ ժամը 17-ը՝ ընդհանուր PoP-երի վրա տարբեր ծանրաբեռնվածություն է։ Չափեք ողջ աշխատանքային միջակայքով։
Միացրեք պաշտպանության լրիվ նպատակային ստեկը։ ZTNA, CASB, SWG, DLP, URL-ֆիլտրում՝ այն համակցությունը, որ պատրաստվում եք շահագործել։ Ֆունկցիաների բենչմարկները չեն գումարվում և ստեկի լրիվ արտադրողականությունը չեն կանխատեսում։
Չափեք end-to-end latency, ոչ թե latency-ն մինչև հանգույցը։ Օգտատերը զգում է լրիվ round-trip ժամանակը իր սարքից մինչև հավելվածը։ Չափեք հենց դա, ոչ թե latency-ն մինչև PoP-ի եզրը։
Համեմատեք ձեր ընթացիկ բազայի հետ։ Հարցը ոչ թե այն է, արդյոք SASE-ն անցնում է բացարձակ շեմը, այլ այն, արդյոք այն ձեր այսօրվա ունեցածից վատ չէ նույն պայմաններում։ Չափեք ընթացիկ ճարտարապետությունը և SASE թեկնածուն նույն պայմաններում։
Հաջորդը շարքում՝ Գրառում 5՝ ինչպես կառուցել թեստ, որի արդյունքները կարելի է պաշտպանել՝ մեթոդիկա, գործիքներ և ինչու է անկախ գնահատումն ինքն իրեն արդարացնում։
TEST4NET LLC-ն ցանցերի և անվտանգության թեստավորման անկախ լաբորատորիա է։ Մենք նախագծում և անցկացնում ենք SASE-ի գնահատումներ՝ ագենտներով ձեր օգտատերերի իրական կետերում, ձեր հավելվածների իրական endpoint-ներին։ Գրեք մեզ։