Нақты трафикке арналған NGFW таңдау: өнімділікті бағалау
Нақты трафикке арналған NGFW таңдау: неге брошюрадағы көрсеткіштер IPS пен SSL тексерісі кезінде нақты жылдамдықпен сәйкес келмейді және пилотты қалай дұрыс өткізу керек.
Неліктен брошюрадағы «гигабиттер» жиі сіздің желіге сәйкес келмейді
NGFW (жаңа буын желілік экрандар) спецификациясында әдетте үш көрсеткіш болады: throughput (жылдамдық), бір уақытта ашылған сессиялардың саны және CPS (секундына жаңа қосылыстар). Мәселе — бұл мәндер көбінесе нақты желіден алыстағы шарттарда алынады: үлкен пакеттер, қарапайым ережелер, тек минималды тексерулер, шифрланбаған трафик және «ауыр» қауіпсіздік профильдері жоқ.
IPS, антивирустық сканер, қолданба бақылауы немесе SSL/TLS-инспекциясын қосқан сәттен бастап құрылғы жай ғана «жылдам маршрутизатор» болуды тоқтатады. Ол трафикті талдайды, ағындарды жинайды, сигнатуралармен салыстырады, саясаттарды қолданады, журнал жазады және кейде TLS-ді ашып, тексеріп, қайта шифрлайды. Практикада бұл брошюрадағы гигабиттер мүлде басқа сандарға айналуы мүмкін екенін білдіреді.
Өнімділік мәселелері сирек «бәрі құлады» секілді көрінеді. Көбінесе бұл белгілер жиынтығы: кешігу өседі, микропотерялар пайда болады, VoIP пен видео үзіліс жасайды, VPN тұрақсыз болады, пайдаланушылар «интернет баяу» деп шағымданады. Қауіптің белгісі — әкімші уақытша инспекцияны өшіріп немесе саясаттарды жеңілдетіп «жылдамдықты қайтаруға» мәжбүр болғанда.
Брошюрадағы гигабиттерге сеніп, кейін қымбат түзетулер жасауға әкелетін шешімдер қабылданады. Мысалы, өсуге резервсіз модель таңдап, SSL-инспекциясын «кейін қосамыз» деп жоспарлап, бірақ аппарат оны көтермейді; орташа канал жүктемесіне қарап шығып, шыңдарды және CPS есептемейді. Тағы бір типтік қателік — пилотта «жеңіл» трафикті тестілеу, ал өндірісте таңғалу.
Егер сізге нақты трафикке арналған NGFW таңдау маңызды болса, даташиттегі сандарды бастапқы нүкте ретінде қабылдаңыз, кепілдеме емес. Нақты бағалау сіздің жағдайларыңызды — өз қолданбаларыңызды, шыңдарыңызды, саясаттарыңызды және, әсіресе, TLS-трафиктің үлесін қайталау жерде басталады.
NGFW өнімділігін нақты не «жейді»
Паспорттық көрсеткіштер көбінесе IP және порттар бойынша «таза» фильтрация жылдамдығын көрсетеді. Бірақ нақты желіде NGFW әдетте бірнеше функциямен жұмыс істейді: қолданба бақылауы, IDS/IPS, антивирус, URL-фильтрация және кейде sandbox. Әр модуль есептеулер мен өңдеу кезекшелерін қосады, сондықтан «10 Гбит/с firewall throughput» толық функциялар жиынтығында оңай 1–3 Гбит/с-қа айналуы мүмкін. Сондықтан құрылғыны бір жол бойынша таңдау қауіпті.
CPU қайда кетеді және мәселе тек «сигнатураларда» ғана емес
Ең ауыр операциялар — құрылғының алдына не келгенін анықтау, жай ғана пакеттерді өткізіп жібермей тұру керек болғанда.
Әдетте ресурстар мынаға жұмсалады:
- сессияларды жинау және ағындарды қайта құрастыру (әсіресе қысқа қосылыстар көп болса);
- архивтер, Office/PDF, қоса келген файлдарды ашып талдау;
- IPS-пен тексерулер: сигнатурамен салыстыру және қосымша контекстік тексерістер;
- қолданбаларды және URL-дарды классификациялау, егер тақырыптардан тереңірек қарау керек болса.
Жүктеме тек «арнамен» ғана емес, трафиктің құрылымымен де өседі. Бірдей 500 Мбит/с үлкен жүктеулерден және 500 Мбит/с мыңдаған қысқа HTTPS-сессиялардан NGFW-ды әртүрлі түрде жүктейді.
Неліктен тек «жылдамдық» емес, кешігу мен потери маңызды
NGFW тестте қажетті мегабиттерді көрсете алса да, пайдаланушылар «құлыпталулар» деп шағымдануы мүмкін. Себебі жиі кешігу мен микропотерялардың өсуі: шыңдарда кезектер толып, орташа жүктеме қалыпты көрінсе де проблемалар туындайды.
Мысал: бір уақытта видеозвоноктар басталады, бұлтпен синхрондау және жаңартулар жүреді. Канал тек 60–70% жүктелгендей көрінуі мүмкін, бірақ NGFW сессиялар саны мен тексеру тереңдігіне ұшырайды. Нәтижесінде маңызды қолданбалар кешігуді бірінші сезеді.
Тағы бір қулық — ережелер мен объектілердің өсуі. Көп саясат, топтар, жеке қоспалар, қауіпсіздік профильдері және маршруттар болса, әр жаңа сессияға көбірек тексерулер жүреді. Сондықтан пилотта «бір әдемі саясатты» емес, болашақ өндірістік конфигурацияға жақын конфигурацияны тексеру маңызды.
SSL-инспекция: ең көп тосын сый әкелетін көзі
SSL/TLS-инспекция (әдетте «HTTPS ашу» деп айтылады) NGFW-ды тақырып бойынша сүзгіден терең тексеретін жүйеге айналдырады: ағынды ашып, оны ережелер арқылы (IPS, антивирус, URL-фильтр, DLP — не қосылғанына байланысты) өткізіп, қайта шифрлайды. Бұл қарапайым фильтрациядан ауыр: криптографиялық операциялар, сессияларды өңдеу және көптеген қосылуларға күй сақтау қосылады.
Екі режимді ажыратыңыз. Outbound-инспекция (пайдаланушылардан интернетке) әдетте ең ауыр жұмыс көлемін береді: сайттар көп, қысқа қосылыстар көп, үнемі жаңа TLS-сессиялар пайда болады. Inbound-инспекция (сервистеріңізге келетін трафик) әдетте профилі бойынша тұрақтырақ, бірақ кешігулер мен қолжетімділік талаптары жоғарырақ, ал баптау қатесі қолжетімділікке қатты әсер етуі мүмкін.
Өнімділікке әсер ететін бөлшектер, олар брошюрада көрсетілмейді:
- HTTPS-тің үлесі және секундына жаңа қосылыстар саны (CPS);
- TLS нұсқалары мен шифр жиынтықтары, сондай-ақ ерекшеліктер логикасы;
- сертификат тізбектерінің көлемі мен күрделілігі, кэштеу және тексеріс жиілігі;
- расшифровкадан кейін қосылатын тексерістер (IPS пен антивирус қарапайым қолданба бақылаудан ауыр).
Алғашқы проблемалар кезінде типтік сценарий — инспекцияны уақытша өшіру: сайт категориялары, жаңартулар, бұлт қызметтері, видеосервистер немесе бүтін подсекторлар үшін. Жылдамдық қайтады, бірақ көрінбейтін аймақ өседі: HTTPS арқылы келетін зиянды жүктеулер мен фишинг тексерусіз өтіп кетеді, инциденттер «түсініксіз» болады.
Пилот әділ болуы үшін алдын ала не расшифровкалайтыныңызды және неге қоспайтыныңызды шешіңіз. Мысалы, веб-шолу және жүктеулер үшін инспекцияны қосуға болады, ал банктік кабинеттер мен кейбір корпоративтік SaaS-ті комплаенс талаптары бойынша ерекшелеуге болады. Содан кейін тек Mbps ғана емес, кешігу, CPS, TLS-сессиялардың үзілуі және CPU жүктемесін шың уақыттарда өлшеңіз.
Қандай трафик параметрлері арнаның енінен маңыздырақ
«Бізде арна 1 Гбит/с» деген фраза түсінікті естіледі, бірақ NGFW үшін бұл көп нәрсе айтпайды. Желілік экран мегабиттерді ғана емес, бір уақытта қанша қосылыс бар екенін, олар қаншалықты жиі жасалатынын, ішінде қандай қолданбалар бар екенін және оларды терең тексеру қажет пе (IPS, антивирус, қолданба бақылау, SSL-инспекция) екенін есептейді.
Аралас трафик әрқашан «біркелкі» трафиктен ауыр. Бір кеңседе бір уақытта видеозвоноктар, бұлтқа кіру, филиалдарға VPN, веб-шолу, қашықтан қол жеткізу және файлдар синхрондануы жүреді. Мегабиттер бойынша бұл «бар-жоғы» 300–400 Мбит/с болуы мүмкін, ал NGFW үшін өңдеудің күрделілігі бойынша бұл толық гигабит және одан да көп сияқты әсер етуі мүмкін.
Қандай трафик NGFW-ды шын мәнінде жүктейді
Қысқа және жиі сессиялар әдетте өнімділік үшін ұзын бір ағыннан қауіптірек. Веб-беттер, мобильді қолданбалар және көптеген бұлттық сервистер көп кішкене сұраулар жібереді. Ал сақтық көшірлемелер мен жаңартулар көбіне ұзын ағындар береді, оларды «жетектеу» оңайырақ, тіпті канал бойынша ауыр болса да.
Жүктемені бағалауға көмектесетін метрикалар:
- CPS (connections per second) — секундына жаңа қосылыстар саны;
- concurrent sessions — бір уақытта «жұмыста» болған қосылыстар саны;
- орташа пакет өлшемі (кіші пакеттер шығындарды өсіреді);
- «ауыр» профилдерден өтетін трафиктің үлесі (IPS/SSL/антивирус);
- бағыттардың балансы: «солтүстік-оңтүстік» (интернет) және «шығыс-батыс» (сегменттер арасында, филиалдар, VPN).
Шыңдар орташа көрсеткіштен маңыздырақ
Күнделікті орташа жүктеме жиі сабақты елітті етіп, адастырады. NGFW шыңдарды көтеруге тиіс: таңертең (қызметкерлер кіруі, пошта, мессенджерлер), жұмыс аяқталу (анықтамалар, жүктеулер), жаппай хабарламалар, жоспарлы жаңартулар және кейде инциденттерден туындайтын өрлеулер.
Мысал: 9:30-да бір уақытта пошта мен CRM ашыла бастайды, VPN арқылы филиалдармен видео, артқы фонда жұмыс станциялары жаңартулары басталады. Арна көтерілмесе де CPS және бір уақытта қосылыс саны күрт өседі. Егер пилотта тек iperf-пен гигабитті тексерсеңіз, нақты проблемаларды тексермеген боласыз.
Пилотқа дайындық: жабдықты қоспас бұрын не жинау керек
Пилотты шағын жоба ретінде дайындау керек. Әйтпесе сіз әдемі сандар алуға боласыз және кейінгі енгізуде тосыншылар болады.
Алдымен желіде шынайы өмір сүретін сценарийлерді анықтаңыз. Қателік — тек интернет шығысын тексеріп, межсегменттік трафик, дата-центрге қатынау және VPN-ды ұмыту. Филиалдар, қашықтағы пайдаланушылар, бөлек аймақтар (офис, сервер бөлмесі, Wi‑Fi, қонақ желісі) болса, әр зона үшін кешігулер мен қолжетімділікке өз талаптары болуы керек.
Келесі қадам — өндірісте міндетті түрде қосылатын функциялар тізімін құру. Пилотта «таза firewall» тексеріп, кейін IPS пен SSL-инспекциясын қоссаңыз, пилот мағынасыз болады. Белгілі бір саясаттар жиынтығын таңдаңыз: қай веб-фильтр категориялары қосылады, қай IPS профильдері, қоса келген файлдарды тексеру болады ма, өндіруші sandbox ұсынса — ол қажет пе.
Құтқару критерийлерін алдын ала анықтаңыз. Олар өлшенетін болуы керек, «жұмыс баяуламауы» сияқты жалпылама емес: негізгі қолданбалар үшін рұқсат етілген қосымша кешігу, VPN үзілістерінің болмауы, кезектер мен қателердің өспеуі, шыңдықтағы рұқсат етілген потери пайызы.
Шын мәнінде бастапқы «до» көрсеткіштерін жинау пайдалы:
- NetFlow/sFlow типтік апта бойынша (шыңдар, орташа, топ қолданбалар және бағыттар);
- ағымдағы шлюз статистикасы (CPU/жады, сессиялар, CPS, интерфейстер бойынша көлемдер);
- инциденттер мен блоктаулар журналы (не ұсталады, қандай жалған сәйкестіктер белгілі);
- маршруттар мен аймақтардың картасы (NAT, межсегмент, критикалық сервистер);
- тексеру үшін «алтын тізім» (бизнес үшін ең маңызды 5–10 қолданба).
Пилот ережелерін алдын ала келісіңіз: ол нақты трафикте жүреді ме (немесе айнада, бірақ сол қауіпсіздік профильдерімен), өлшеулер бірдей уақыт интервалдарында жасалады, және кез келген «жеңілдетулер» (SSL өшіру, IPS жеңілдету) бөлек сценарий ретінде тіркеледі, финалдық нәтиже ретінде саналмайды.
Қадамдық: дұрыс пилотты қалай өткізуге болады
Пилоттың мақсаты — максималды сандарды көру емес, IPS пен SSL-инспекцияны қосқаннан кейін сіздің желіңізде не болатынын түсіну.
1) Пилотты өндірісте қалай қолданылатыны сияқты жинаңыз
Алдымен құрылғыны қалай қосатыныңызды шешіңіз. Айна (mirror) қауіпсіз және ыңғайлы, бірақ нақты кешігу мен ақау кезінде қалай әрекет ететінін көрсетпейді. Разрывқа қосу адал картинаны береді, ал параллельдік схема маршруттар мен саясаттарды салыстыруға көмектеседі.
Негізгі ережелер мен маршруттауды «косметикасыз» көшіріңіз. Қате — тест уақытында саясаттарды жеңілдетіп немесе бөліп кейбір подсетьтерді шығару. Нәтижесінде пилот тым жеңіл болып, адастырады.
2) Функцияларды кезең-кезеңімен қосып, өзгерістерді жазып отырыңыз
Практикалық тәртіп:
- базалық фильтрация және NAT (трафик жүруі үшін);
- қолданба бақылауы және негізгі пайдаланушы саясаттары;
- негізгі бағыттарда IPS;
- SSL-инспекция, алдымен нүктелі (1–2 топ), содан соң кеңейту;
- қосымша тексерістер (антивирус, sandbox, DNS-фильтр) — олар жоспарланса.
Әр кезең арасында бірдей бақылау терезесін ұстаңыз (мысалы, 1–2 жұмыс сағаты), салыстыру адал болу үшін. Қолданбалы жүктемелерді бір уақытта шығарыңыз: видеоконференциялар, CRM/ERP, файл алмасу, пошта, сақтық көшірмелер, жаппай ОС жаңартулары. Оларды әдеттегі уақыттарда жүргізген дұрыс (таңертең, түсте, жұмыс күні соңында), себебі трафиктің профилі өзгереді.
Нәтижелерді сандармен қорғау үшін алдын ала қай метрикаларды жинайтыныңызды келісіңіз және қай жерде. Әдетте кешігу мен потери, CPU және жад, белсенді сессиялар саны, CPS, VPN жылдамдығы және типтік сайттардың ашылу уақыты фиксирленеді.
Шығарда әр кезең бойынша «болды/болмады» кестесі және сайзинг бойынша қорытынды болуы керек: қай режим деградациясыз жұмыс істейді, қай жерде шыңдар пайда болады және өсуге қанша резерв қалды.
Бағалау кезінде типтік қателіктер мен тұзақтар
Пилоттың сәтсіздік себептерінің ең бастысы — өндірісте қандай жұмыс істейтініне сай емес нәрсені өлшеу. Нәтижесінде NGFW тестте «гигабиттерді ұстап» тұрады, ал IPS пен SSL-инспекция қосылғаннан кейін пакет жоғалтып, кешіктіреді.
Көбіне келесідей болады:
- тек «таза» throughput (мысалы, iperf) жүргізіп, нақты тексерулер мен логтауды елемеу;
- әдемі, жеңілдетілген саясаттарды жасау, кең рұқсаттар мен ерекшеліктермен;
- тыныш уақытта тестілеу және ауыр кезеңдерді ұстамау (жаңартулар, видеозвоноктар, сақтық көшірмелер);
- VPN және шифрлаудың/дешифровканың шығындарын ұмытпау;
- тек «жылдамдыққа» қарап, кешігу, потери және тұрақтылықты назарға алмау.
Жай тұзақ бар: «сайзинг впритык». Бүгін бәрі жұмыс істейді, ал алты айдан кейін жаңа сервистер қосылып, TLS үлесі өсіп, қосымша IPS ережелері пайда болғанда резерв жоқ болады.
Минималды бақылау жиынтығы әдетте мыналар: негізгі бағыттар бойынша орташа және 95-процентиль кешігу, drops/қателер пайызы және шамадан тыс жүктелгендігін көрсететін белгілер (кезектер, CPU өсуі, сессиялардың таусылуы), сессияларды орнату жылдамдығы және шыңды уақытта максимум бір уақытта ашық сессиялар.
Қысқа чек-лист: сізге жеткілікті қуат па
«Файлды максималды жылдамдықпен жүктеу» тесті шамалы ғана ақпарат береді IPS, SSL-инспекциясы және пайдаланушылардың нақты сессияларымен жұмыс туралы.
Егер келесі екі–үш тармақ бойынша нақты цифрлар болмаса, недосайзинг қаупі жоғары:
- concurrent sessions және CPS бойынша шыңдар тіркелген, тек орташа канал жүктемесін ғана емес;
- «ауыр» профильдер сол комбинацияда іске қосылған, қандай да бір жеңілдетулер жоқ;
- SSL-инспекция нақты сценарийлерде (браузинг, порталдар, жаңартулар, мессенджерлер, видеосервис) тексерілген, бір тест-сайтпен емес;
- саясаттарды қосқанға дейін және кейін кешігу мен потери өлшенген (latency, packet loss, jitter);
- CPU, жад және сессия кестелері бойынша 12–24 айға есептелген резерв түсінікті.
Арнайы тексеріңіз: интернет-банк, мемлекеттік ресурстар, медициналық жүйелер, EDI, клиенттік сертификаттары бар порталдар. Маңыздысы — тек «ашылады/ажыратылмайды» ғана емес, күні бойы қаншалықты тұрақты жұмыс істейтіндігі.
Қуат «жетеді» деп айтуға болады, егер шыңды кезеңдерде ресурс резерві сақталса, критикалық сервистер тосынсыйсыз жұмыс істесе және кешігу пайдаланушы тәжірибесін нашарлатпаса.
Қолданбадан мысал: филиалдары мен VPN бар кеңсеге пилот
400 қызметкері бар компания: бас кеңсе, 6 филиал, ортақ интернет-арна және тұрақты VPN-туннельдер. Жұмыс уақытында видеозвоноктар, бұлт сервистері, пошта, жаңартулар, бухгалтерия мен CRM жүреді. «Арна жеткілікті», бірақ қауіпсіздікті күшейту мақсатында everywhere IPS пен кейбір категориялар үшін SSL-инспекциясын қосу жоспарланған (мысалы, белгісіз сайттар мен файл алмасу, ал банктер мен мемлекеттік ресурстарды өзгешелендіру).
Пилот басында NGFW бас кеңседе разрывқа қойылып, филиалдардан трафик VPN арқылы айнаға таратылды, сонда тест шынайырақ болды. Алғашқы кезеңде тек базалық функциялар қосылып, «таза» есептік нүкте алынып, кейін жүктеме біртіндеп қосылды.
Бірнеше күн бойы ауыр тексерістерсіз трафик профилі өлшеніп, кейін негізгі IPS-ті қосып, содан кейін таңдалған категориялар бойынша SSL-инспекциясы қосылды. Өлшеулер шыңды сағаттарда (әдетте 10:30–12:00 және 15:00–17:00) жүргізілді, түнгі уақытта емес.
Команда мегабиттерден бөлек тармақтарды да жазды: вебтегі CPS және жаппай жаңартулардағы CPS, интерфейстегі кезектер мен drops, кешігу өсімі (видеосвязьте айқын), IPS пен SSL бойынша CPU жүктемесі, өрлеу кезіндегі мінез-құлық (throughput-тың құлауы және қалпына келу уақыты).
Бұл жағдайда «тосын» жалпы трафиктен емес, CPS өрлеуінен және SSL-ден келді: расшифровка қосылғанда кешігу ұлғайып, CPU шыңға жетті, ал орташа жүктеме әдетте қалыпты көрінді. Графиктерде бұл қысқа жылдамдықтың құлауы мен сұрауларға жауап уақытының өсуі ретінде көрінді, әсіресе жаппай қосымшалар пен жаңартулар басталғанда.
Нәтижесінде қуатқа резерв қосылды, ал функциялар «бәріне бірдей қосу» емес, саясаттар арқылы таралды: SSL-инспекция тиімді болатын жерлерде қалдырылды, IPS кіріс және межсегмент бағыттарында қаттырақ қолданылды, сенімді бағыттар үшін жұмсартыла отырып, филиалдарға бөлек ережелер мен лимиттер енгізілді, бір офис ресурстарды «жеп алмауы» үшін.
Егер пилот интегратормен бірге жүрсе, «қызыл аймақ» саналатын метрикаларды алдын ала келісу пайдалы — сонда шешім сандар негізінде қабылданады. Қазақстанда осындай тапсырмаларды GSE.kz жүйелік интегратор ретінде орындайды: пилот пен өлшеу әдістемесінен бастап енгізу және кейінгі қолдауға дейін.
FAQ
Какие цифры в даташите NGFW важнее «10 Гбит/с»?
Смотрите не на «firewall throughput», а на показатели *threat prevention* / *IPS throughput* и отдельно на производительность при SSL/TLS-инспекции. Минимум, что нужно запросить/проверить: - пропускная способность с теми профилями, которые вы реально включите (IPS, AV, App Control, URL); - CPS и максимум одновременных сессий; - задержка и потери под нагрузкой, а не только Мбит/с.
Почему «гигабиты в брошюре» не равны скорости в нашей сети?
Потому что «10 Гбит/с» часто измерены на простом трафике: крупные пакеты, минимум правил, без IPS/антивируса и без расшифровки TLS. Как только вы включаете глубокие проверки, NGFW начинает: - собирать и анализировать потоки; - сопоставлять содержимое с сигнатурами; - логировать и применять больше условий политики. Это упирается в CPU/память и очереди обработки, и скорость в реальной сети становится ниже.
Какие симптомы подскажут, что NGFW не справляется по производительности?
Чаще всего проблемы выглядят не как полный отказ, а как «плавающее качество»: - растет задержка и джиттер; - появляются микропотери и дропы в пике; - VoIP/видео начинает заикаться; - VPN-сессии рвутся или долго поднимаются; - сайты «думают», хотя средняя загрузка канала не выглядит высокой. Если ради «скорости» приходится временно отключать инспекцию или упрощать политики — это явный сигнал, что мощности/настройки не подходят.
Что важнее для NGFW: скорость канала или CPS?
CPS (новые соединения в секунду) важен, потому что много коротких HTTPS-сессий нагружают NGFW сильнее, чем один длинный поток на те же мегабиты. Практика такая: - «ровные» скачивания/бэкапы чаще упираются в полосу; - веб, мессенджеры, облака и мобильные приложения чаще упираются в CPS и обработку TLS. Поэтому для сайзинга нужно смотреть и Mbps, и CPS, и concurrent sessions.
Почему SSL/TLS-инспекция так сильно снижает производительность?
Почти всегда самый тяжелый режим — outbound (трафик пользователей в интернет): много сайтов, много коротких соединений, постоянно новые TLS-сессии. Inbound-инспекция (к вашим сервисам) бывает более предсказуемой по шаблону запросов, но там выше требования к доступности и ошибки настройки больнее. Оптимальный подход: сначала решить, *что именно* вы расшифровываете, и проверить это в пилоте на реальных приложениях.
Что обычно нельзя или нежелательно расшифровывать при SSL-инспекции?
Базовый набор исключений обычно делают для: - интернет-банков и платежных страниц; - госресурсов и систем с жесткими требованиями комплаенса; - сервисов с клиентскими сертификатами, где расшифровка часто ломает сценарий; - некоторых медицинских/EDI-систем, если так требуют регламенты. Дальше правило простое: все исключения должны быть осознанными и минимальными. Если исключениями «лечат производительность», вы получаете большие слепые зоны.
Какие данные нужно собрать перед пилотом NGFW?
Соберите «портрет нагрузки» до пилота, иначе сравнивать будет нечего: - пики по CPS и одновременным сессиям (за типичную неделю); - долю TLS-трафика и топ приложений; - направления трафика: интернет, межсегмент, VPN/филиалы; - текущие показатели задержки/потерь на ключевых сервисах. И заранее зафиксируйте, какие профили безопасности будут включены в бою (IPS, AV, URL, SSL-инспекция) — без этого пилот легко станет «слишком легким».
Как провести пилот так, чтобы он показал реальную картину?
Пилот должен повторять будущую эксплуатацию, иначе выводы будут ложными. Рабочий порядок: - включить базовую фильтрацию/NAT и снять «точку отсчета»; - добавить контроль приложений и пользовательские политики; - включить IPS на нужных направлениях; - запустить SSL-инспекцию сначала на небольшой группе, потом расширять; - при каждом шаге мерить одни и те же метрики в одинаковые временные окна. И обязательно тестировать в часы пик, а не в «тихое» время.
Какие метрики нужно мерить в пилоте, кроме Mbps?
Минимальный практичный набор: - задержка (средняя и 95-й процентиль) и джиттер для критичных приложений; - packet loss/drops и ошибки на интерфейсах; - CPU/память и заполнение таблиц сессий; - concurrent sessions и CPS; - стабильность VPN (время установления, разрывы). Через эти метрики видно, *где именно* узкое место: полоса, сессии, TLS, IPS или очереди.
Какой запас по мощности закладывать и как не ошибиться с сайзингом?
Частая ошибка — выбрать модель «впритык» по средним цифрам. Нормальная цель — иметь запас в пике и возможность включать нужные проверки без деградации. Практичный ориентир: - планируйте рост на 12–24 месяца (пользователи, сервисы, доля TLS, правила); - держите запас по CPU/сессиям в пиковые часы, а не только «в среднем»; - заранее решите стратегию масштабирования: HA-кластер, апгрейд модели, разделение ролей (например, отдельный упор на VPN или на SSL). Если нужна помощь с методикой пилота, замерами и внедрением в Казахстане, это делает GSE.kz как системный интегратор: от сайзинга до поддержки 24/7.