Palo Alto PA-3200 Series пилоты: қауіпсіз мониторинг

Пилоттың мақсаты: трафикті көру және желіге әсер етпеу

Қауіпсіз пилот — бұл нақты трафик пен болашақ ережелердің адал әсерін көру, бірақ жаңа ақау нүктелерін жасамау. NGFW бақылайды, есептейді және тіркейді, ал қызметтерге қолжетімдікті шешетін шешімдерді қабылдамайды. Palo Alto PA-3200 Series пилотында бизнес тоқтауына немесе деректерге зиян келтіруіне әкелетін жағдайлар қабылданбайды.

Жиі қабылданбайтын жағдайлар:

• критикалық жүйелердің тоқтауы (почта, ERP, телефония, VDI, мемлекеттік қызметтер)
• жасырын деградация (кідірулердің өсуі, сессиялардың үзілуі, MTU проблемалары)
• шикі ережелер не қате қосымшалардың анықталуы салдарынан кездейсоқ блоктаулар
• көрінудің жоғалуы (трафиктің бір бөлігі мониторингке түспеуінен қате қорытындылар)
• тез кері қайтаруға қиын өзгерістер

Бастапқыда бақылау неге маңызды: алғашқы аптада көбінесе күтпеген тәуелділіктер шығады. Мысалы, бухгалтерия таныс қосымша арқылы жұмыс істейді, бірақ ішінде лицензия серверіне стандарттан тыс порт арқылы сұраныс жібереді, немесе жаңартулар бұлттан келеді. Егер бірден тыйым салынса, бұл туралы сізге қолдау қызметіне қоңырау арқылы білесіз, ал жан-жақты есеп емес.

Пилот келесі негізгі сұрақтарға жауап беруі тиіс: қандай қосымшалар шынымен қолданылады, оларды кім іске қосады, қандай сегменттер арасында ағындар бар, қай сервистер критикалық және жұмыс уақытындағы терезелер қандай. Сондай-ақ «шу» — сканерлеулер, қате DNS-сұраныстар, ескірген протоколдар, әкімшілік трафикті де көру маңызды.

Пилоттың нәтижесі — «темір қойдық» емес, ал артефакттар пакеті: трафик көрінісі бойынша есеп, саясаттың жобасы (негіздемесі бар рұқсаттар мен тыйымдар), критикалық сервистерге арналған ерекшеліктер тізімі және анық, кері қайтару мүмкіндігі көрсетілген cutover жоспары мен жауапты тұлғалар.

Қосуға дейінгі дайындық: схема, рөлдер, базалық сызық

Пилот басталар алдында келісімдер конфигурация жайлы емес, бастапқы деректер жайлы болуы керек. Қай жерде және қандай трафикті жинауға болатынын білмесеңіз, әдемі журналдар аласыз, бірақ олар бизнес пен ИБ сұрақтарына жауап бермейді.

Практикалық түрде желі схемасы жасаңыз: ядро қайда, периметр қайда, DMZ бар ма, филиалдар қалай қосылған, интернет арналары мен резерві қалай жүзеге асырылған. Қай жерде TAP немесе SPAN қоюға болатынын белгілеңіз және шектеулерді тексеріңіз: порт жылдамдығы, SPAN-да жоғалту ықтималдығы, қажетті VLAN қолдауы, екі жақты айна мүмкіндігі.

Содан кейін пилот уақытында рөлдер мен байланыс тұлғыларын тағайындаңыз. Бір доменге бір жауапты және инциденттер үшін анық байланыс арналары жақсы:

• желі: SPAN/TAP, VLAN, маршрутизация, коммутаторлардағы өзгерістер
• ИБ: қосымшаларды бақылау, қатерлер, логталуға қойылатын талаптар
• сервис иелері: критикалық қосымшалар, жұмыс уақытындағы терезелер, рұқсат етілген тәуекелдер
• NOC/дежурная смена: мониторинг, бастапқы реакция, эскалация

Қосуға дейін ағымдағы инфрақұрылымға базалық сызықты нақтылаңыз: типтік кідірулер мен жоғалтулар (жұмыс уақытында және түнде), арналар жүктемесі, бір уақытта ашылған сессия саны және шыңдар. 3–5 критикалық тексеруді таңдаңыз (мысалы, ERP-ге кіру, поштаға қолжетімділік, пайдаланушылар VPN, байланыс орталығы қоңыраулары) және күтілетін жауап уақытын жазыңыз.

Тікелей бақылау режимі үшін де кері қайтару жоспарын дайындаңыз: кім және қалай айнауды өшіретінін, бұл қанша уақытты алады, қандай терезе қабылданатындығын және пилотты тоқтатуға себеп болатын белгілерді. Мысалы: SPAN қосылғаннан кейін ядро порттарында қателер немесе пакет жоғалтулар байқалса, пилот тоқтатылып, алу нүктесі өзгертіледі.

Мониторинг режиміне қосу сценариі (TAP немесе SPAN)

Пилот үшін нақты трафик көрінісін алу маңызды, бірақ жүйенің бірден ақауына айналмауы керек. Сондықтан пассивті қосылудан бастаңыз: NGFW пакеттерді көріп, лог жазады, бірақ пакеттер өтпесіне қатыспайды.

TAP пен SPAN бір міндетті шешеді, бірақ деректер сапасы әр түрлі. TAP көбіне ыңғайлы: физикалық деңгейде трафикті көшіреді және коммутатор баптауларына аз тәуелді. SPAN қосу оңай, бірақ ол жүктеме кезінде пакеттерді тастап жіберуі мүмкін және VLAN‑тегтер мен сәтсіздіктерді толық жеткізбеуі ықтимал.

Қосылу нүктесін мақсатқа қарай таңдаңыз:

• периметр үшін интернет шлюзіне жақын айна тиімді
• «восток‑запад» үшін — агрегацияда немесе ядро/таралу шатысында
• маршрутизатор мен коммутатор арасындағы стык L3 ағымдарын көруге пайдалы, бірақ онда жиі асимметрия кездеседі

PA-3200 үшін практикалық мониторинг сценариі:

• көшірме қабылдау үшін NGFW-да бөлек интерфейстер бөліп қойыңыз (L3 мекенжайларсыз және маршрутизацияға қатыстырмай)
• TAP немесе SPAN баптаңыз, көшірме тек осы порттарға келетіндей етіңіз
• tap/monitor сияқты бөлек зона жасаңыз және трафикті солай бағыттаңыз
• құрылғы пакеттерді желіге қайта жібермейтініне көз жеткізіңіз (физикалық «петлялар» жоқ және L2 bridge жоқ)
• зеркалирование көлемін фильтрмен шектеңіз (VLAN, подсеть, қажетті uplink), сонда SPAN толып кетпейді

Логтарды жинауды бастамас бұрын төрт нәрсені тексеріңіз.

Біріншіден, симметрия: NGFW бір сессияның екі бағытында да көре ме. Әйтпесе кейбір қосымшалар дұрыс анықталмауы мүмкін.

Екіншіден, толық емес ағымдар: SPAN‑да пропусктар болуы ықтимал, бұл қорытындыларға ескертілуі тиіс.

Үшіншіден, SPAN-порттың жүктелуі: коммутатордағы drop және трафик шыңдарын қадағалаңыз.

Төртіншіден, VLAN‑тегтер: егер олар сақталмаса, сегменттер «араласып», есептер қате болады.

Бұл режим пакет ағымына әсер етпей бақылау береді және кейінгі инлайн‑ауыстыруға ережелер дайындауға көмектеседі.

PA-3200 базалық баптаулары лог жинаудан бұрын

Лог жинаудан бұрын PA-3200‑ды қауіпсіз басқаруға және дұрыс көрініс беруге баптаңыз. Пилотта маңыздысы — пакеттің өзінен бөлек, құрылғыға қосымша тәуекел туғызбау.

Интерфейстерді мағыналық түрде бөліңіз: басқару үшін бөлек порт және мониторинг үшін бөлек порттар (TAP/SPAN). Басқару интерфейсіне әкімшілік подсеткада немесе бөлек VLAN‑да адрес қойып, пайдаланушы сегменттеріне маршрутизация жасамаңыз. Басқаруға рұқсатты нақты әкімшілердің IP‑дарына шектеңіз, «бүкіл желіден» емес.

Уақыт пен синхрондауды тексеріңіз. Инцидент талдауы мен ережелер жобалау үшін NGFW, коммутаторлар және сервер логтарының уақыт белгілері сәйкес болуы маңызды. NTP қосып, бірдей timezone қойыңыз және Traffic пен Threat жазбаларының меткалары SIEM немесе домен контроллерлері журналдарымен сәйкес екенін тексеріңіз.

Бастапқы минимум:

• Management IP, шлюз және DNS баптау; басқаруға қолжетімділікті IP және протоколдар бойынша шектеу (HTTPS, SSH)
• NTP қосу және timezone орнату; синхрондауын тексеру
• бөлек есептік жазбалар жасау: админ, логтарды қараушы оператор, аудит (тек оқу)
• әкімшілер әрекеттерінің журналын қосу және логтарды локалда сақтау (пилот уақытына)
• интерфейстер мен зоналарды атау схемасын ойластыру (мысалы, Z-Users, Z-Servers, Z-DC, Z-Guest)

Зоналар мен атауларды алдын ала қою жақсы, тіпті құрылғы әлі инлайнда болмаса да. Егер SPAN агрегациядан келіп, зонаны жай «SPAN1» деп атаған болсаңыз, инлайнға өткенде ережелер мен есептерді өзгертуге тура келеді. Ал мониторинг интерфейсін болашақ зонаға (мысалы, "Z-Users") байласақ, логтар арқылы саясат жобалау оңайырақ болады.

Пилот үшін логтар жинағы: не қосу және не қарау

Пилоттың мақсаты қарапайым: қандай ережелер қажет екенін дәлелдеу және тәуекелді түсіну, трафикті өзгертпей. Алдын ала қандай логтар міндетті екенін, қайда сақталатынын және күнделікті кім қарайтынын келісіп алыңыз.

Traffic: болашақ ережелер негізі

Traffic журналдарында іс саны маңызды емес, дұрыс өрістер маңызды. Олар желідегі нақты өмірді және алғашқы тыйым кезінде не сынатындығын көрсетеді. Есеп үшін әдетте жеткілікті тұрақты түрде шығарып, қаралатын өрістер:

• app және app-category: қосымшалар қалай анықталуда, не unknown немесе incomplete күйінде қалуда
• src/dst, zone және interface: ағындар қайдан/қайда, ережелер шекарасын қайда қою ыңғайлы
• user (интеграция болса): кім қандай қауіпті трафик жасайды
• bytes және session duration: «ауыр» ағындар, олар үшін ерекшелік қажет болуы мүмкін
• session end reason: жолдардағы проблемалар, таймауттар және асимметрия маркері

Мысалы: бухгалтерия (user/group) жиі бұлттық CRM‑мен жұмыс істейді, бірақ қосымша тұрақсыз анықталады және кей сессиялар таймаутпен аяқталады. Бұл ережелерді, DNS пен болашақ дешифрлауды алдын ала ойлауға сигнал.

Threat, URL және DNS: шуды нақты қатерден ажырату

Threat журналдарында пилотта маңыздысы — бір реттік жарқыл емес, қайталанушылық және нақты хосттарға байланым. Блоктаудан бұрын реакция талап ететін нәрселерді белгілеп алыңыз: high/critical severity, бір көзден қайталанатын эксплуатациялар, командалық каналдар және айқын malware срабатываниялары.

Шуды көбіне сканерлеулер, жарнамалық домендер, қате IoT‑құрылғылар және ескірген агенттер береді. Практикалық тәсіл: алдымен трафиктің қайталанатынын және сіздің активтерге тиесілі екенін растап, содан кейін ғана блоктауды жоспарлау.

URL көрінісі үшін жұмыс уақытында шынайы қолданылатын категорияларға назар аударыңыз және ішкі желіден күтпеген категорияларды байқаңыз. DNS бойынша жиі сұраныстарды, NXDOMAIN пен қысқа тарихы бар жаңа домендерді бақылаңыз.

System және Config журналдарын да қосыңыз: олар жүктемелерді, процестерді қайта іске қосуды, саясат өзгерістерін және кім енгізгенін көрсетеді. Кейін SSL‑дешифрлауды жоспарласаңыз, алдын ала TLS‑трафик үлесін, танымал SNI/домендерді және дешифрлау кезінде жиі «шашылатын» қосымшаларды жинаңыз (банктер, медицина, жаңартулар).

Логтарға қарап ережелерді бағалау және жобалау

PA-3200 мониторингте жұмыс істегенде мақсат — ережелерді болжау емес, фактілер жинау. Аптадан 7–14 күндік тереземен қорытынды жасаңыз: күнделікті жұмыс, шыңдар, түнгі сақтық көшірмелер және сирек, бірақ маңызды ағындар көрінеді. Бір күн жиі адастырады.

Тізбекпен бастау: топ қосымшалар, бағыттардың (зоналар, подсетьтар, сервер сегменттері) тобы, пайдаланушылар немесе сервис есептік жазбаларының тобы және көлем бойынша топ сессиялар. Бұл — болашақ саясаттың қаңқасы.

Логтарды қалай ереже жобасына айналдыру

Ең қолайлы әдіс — кеңнен тарқа және әр болжамды жазу:

• критикалық маршруттар үшін бастапқы рұқсат ережелерін жинаңыз (мысалы, пайдаланушылар -> пошта, филиалдар -> ERP, қолданба серверлері -> DB), бәрін бірден «тартпай»\n- App-ID сенімді жерде оны қолдана отырып жатықтаңыз (конкретті қосымша орнына tcp/443), зоналар, мекенжайлар және пайдаланушылар бойынша шектеулер қосыңыз
• анық зиянды немесе Threat бойынша тәуекелді заттарға нүктелік тыйымдар енгізіңіз
• дау туғызатындар үшін уақытша ерекшеліктер енгізіңіз: себеп және мерзімі (мысалы, TEMP-14D + түсініктеме, сервис иесі)
• SaaS шектеулері, сыртқы интеграциялар, жаңартулар, EDI, телефония, видеоконференциялар сияқты бизнеспен келісуді қажет ететін ережелерді бөлек белгілеңіз

«Бейтаныс» қосымшалармен бөлек жұмыс істеу керек. Егер App-ID тым жалпылама (мысалы, ssl немесе web-browsing), осыны идентификациялауға жеткілікті ме, трафик маскеселеніп тұрған жоқ па (туннельдер, прокси) және дешифрлау қажет пе — тексеріңіз. Кейде идеалды App-ID болмайды (CDN, әмбебап клиенттер). Ондайда ережені мақсатқа қарай құрыңыз: сервер, домен, сегмент, пайдаланушы.

Мысал: түнгі уақытта бухгалтериядан бұлтқа tcp/443 бойынша тұрақты трафик бар. Журналдарда бұл «ssl», бірақ адресаттар мен кестеге қарай бұл ЭДО операторымен алмасу болуы мүмкін. Мұндай ережені сервис иесінен растама алғанша уақытша рұқсат ретінде қалдыру дұрыс.

Тұрақтылық бақылауы: метрикалар және құрылғының денсаулығы

Тіпті мониторингте пилот жүктеме, зеркалирование жоғалту немесе тым шуыл логтар себебінен «ағып» кетуі мүмкін. Мақсат — болашақ ережелердің дұрыстығын дәлелдеу ғана емес, құрылғының шынайы шыңдарда да трафикті сенімді көруін тексеру.

Өнімділік пен кестелердің өсуін қадағалаңыз. Жүктеме алдын ала болжанатын болуы керек: CPU‑да кенетті секірулер жоқ, сессиялардың тұрақты өсуі және dataplane лимитіне жетпеу.

Күн сайын (және шың сәттерде) тексерілетін метрикалар:

• management plane және dataplane CPU, dataplane‑тың жүктелу белгілері (кезектер, өңдеу кідірістері)
• белсенді сессиялар саны мен олардың пайда болу жылдамдығы
• интерфейстер бойынша PPS және throughput, кестелердің өсуі (ARP/route, session table), лог жазу жылдамдығы
• интерфейстердегі дроптар және дроп себептері (буфер толу, қателер, oversubscription)
• диск/лог сақтау толу және логтардың SIEM‑ге жеткізілуінің кешігуі (егер қолдансаңыз)

SPAN/TAP арқылы көрінудің жоғалмауын тексеріңіз. SPAN портты коммутатордағы жүктеме кезінде кесіп тастауы немесе бірнеше көзді бір тар портқа айнау кезінде дұрыс жұмыс істемеуі мүмкін. Өзіңіз қолданатын көздегі және айна портындағы қабылданған пакеттер есептерін салыстырып, шыңдарда қандай да бір трафик «жоғалып кетпейтінін» бақылаңыз.

Шыңдар мен сирек оқиғалар орташа күн бойынша көрінбеуі мүмкін. Бір циклді (түнгі бэкап, төлем терезелері, күннің жабылуы, жаппай есептер, OS жаңартулары) қаптау жетеді. Егер осы сәттерде PPS және сессиялар өсіп, дроптар жоқ және ресурстар көтерсе — бұл жақсы белгі.

Пилот уақытында қарапайым оповещениелерді орнатыңыз: CPU/сессиялардың шектен асуы, мониторинг интерфейсінде дроптардың пайда болуы, диск толуы, лог жазудың тоқтауы, басқарудың қолжетімсіздігі. Сол кезде деградация үнсіз қалмайды.

Мысал сценарий: филиалдары және критикалық сервистері бар желіде пилот

Ұйым: бас офис, 6 филиал, байланыс IPsec VPN арқылы, интернетке шығу периметр арқылы. Критикалық сервистер: корпоративті пошта, мемлекеттік жүйелерге қолжетімділік, бухгалтерия және банк‑клиент. Қателер жұмысын тоқтатуы оңай болғандықтан пилот трафикке әсер етпей жасалады.

Қосылу сценариі: периметрде шеткі маршрутизатордың сыртқы және ішкі интерфейстерінен SPAN/TAP баптаймыз, ал филиал трафигі үшін VPN туннельдері терминалданатын интерфейстен бөлек зеркалдеу жасаймыз. Солай интернет пен филиалдар арасындағы ағындарды көріп, ағымдағы маршруттарды бұзбаймыз.

3–5 жұмыс күнінде схемада жоқ нәрселер шығады: күтпеген қосымшалар, көлеңкелі бұлттар, ескірген протоколдар мен шифрлар, офис ішінен жаппай RDP/SSH, мемлекеттік жүйелерге стандартты емес түйіндерден сұраныстар.

Келесі қадам — бірден мінсіз саясат жазу емес, келісуге арналған қысқа пакет дайындау: бизнеске қажет ағындар, күдікті ағындар, қайсысы ерекшеліктерді талап етеді.

Практикалық нәтиже форматы:

• «рұқсат ету»: қосымша + көз/мақсат + пайдаланушы/топ (бар болса) — пошта, бухгалтерия, мемлекеттік жүйелер
• «рұқсат шарттарымен»: тек прокси арқылы, тек уақыт бойынша, тек терминал подсетінен
• «тыйым салу»: көлеңкелі бұлттар, рұқсат етілмеген қашықтан қатынау
• ерекшеліктер: ескірген протоколдар тек белгілі серверлер үшін және уақытша
• сервис иелеріне сұрақтар: бұл түйін не үшін, қандай порт, кім жауапты

Осылайша пилот инлайнға өтуге қандай нәрсені қосу, ал қайсысын кейінге қалдыру керектігін көрсететін басқарылатын жоспарға айналады.

Инлайнға ауысуға дайындық критерийлері

NGFW‑ты инлайнға ауыстыру — «түймені басып, қараймыз» емес. Шешім тыныш әрі тексерілетін болу үшін критерийлерді алдын ала бекітіңіз.

Міндетті дайындық критерийлері

• Функционалдық: негізгі ағындар анық ережелермен қамтылған, ерекшеліктер рәсімделген және түсінікті, «көрінбейтін» аймақтар жоқ (түсініксіз көздер, сегменттер, қосымшалар).
• Тәуекел критерийлері: кері қайтару жоспары расталған (кім, не және қанша минут ішінде істейді), жұмыс терезесі үшін тест жоспары және келісілген жауаптылар бар.
• Операциялық: құрылғы мен арналар мониторингі бапталған, негізгі оқиғаларға хабарландырулар бар, жауап процедурасы анық (кім логтарды қарайды, кім ережелерді өзгертеді, кім кері қайтаруды бастайды), әкімшілер әрекеттері журналданады.
• Пайдаланушы критерийлері: тест нәтижелері бойынша критикалық сервистерге қолжетімділік пен жылдамдыққа әсер жоқ, пайдаланушылардан келетін шағымдар анық және түсінікті, «жұмыс істейді/жоқ» сияқты хаотикалық күй емес.
• Техникалық: инлайн схемасы (L2/L3, VR, ECMP және т.б.) таңдалып, тестіленген, қай жерде ақау нүктесі болатыны және оны қалай жою керектігі түсінікті (резервтеу, bypass, кластер), маршрутизация және желілік қорғаныспен үйлесімділігі расталған.

Критерийлер өлшенетін болу үшін алдыңғыдан шектерді келісіңіз: ережелерге түсетін трафик үлесі (allow any уақытша ережесіз), күн ішіндегі жаңа қосымшалар саны, рұқсат етілген сервистерге қатысты Threat срабатываний саны, бір инцидентті талдауға кеткен уақыт.

Инлайнға өту алдындағы гейт — бір жұмыс терезесіне арналған тексеру

1. тесттік терезеде бизнес сценарийлер тізімінен (5–10 нақты әрекет) өтіңіз

2. жұмыс кезінде консоль/басқаруға қолжетімділіктің бар екенін және дежурлықтармен байланыс арналарының анық екенін тексеріңіз

3. ережелердің қайталанатындығын растаңыз: сипаттамасы, иесі, қайта қарау мерзімі

4. кері қайтаруды стендте немесе аз критикалық сегментте репетициялаңыз

5. қосқаннан кейінгі алғашқы 15, 60 және 240 минут ішінде тексерілетін логтар мен метрикаларды бекітіңіз

Егер кем дегенде бір тармақ тұрғысынан күдік болса, инлайнды апталап кейінге қалдырыңыз — кейінгі шұғыл «уақытша рұқсаттар» мәңгі қалуы мүмкін.

Пилотта жиі жасалатын қателер және оларды қалай болдырмау

Пилот тыныш және қауіпсіз көрінуі мүмкін, бірақ шешімдер шын трафикті көрсетпейтін деректерге сүйеніп қабылдануы — жиі кездесетін проблема. Бұл, әсіресе, SPAN‑да пилот жасап, бірден логтар бойынша ережелер жазғанда байқалады.

Типтік оқиға: айна портында критикалық сервиге баратын кейбір сессиялар көрінбейді, сондықтан ереже қажетсіз көрінеді. Инлайнға ауысқанда үзілістер пайда болады, өйткені өндірістік трафик әрқашан көбірек және өзгеше.

Ең жиі кездесетін қателер:

• SPAN‑ға тым сену. Коммутатордың шыңдық жүктеме кезіндегі айнауды қалай ұстайтынын тексеріңіз. Көздегі және айнадағы трафик есептерін салыстырып, дроптарды бақылаңыз. Қиындыққа соғып жатса TAP қолдануға тырысыңыз.
• Блоктауды ерте енгізу. Бастапқыда саясаттарды рұқсаттау және логтау режимінде ұстаңыз, блоктауларды тек сервис иелерімен расталғаннан кейін ғана енгізіңіз. Қауіптілікті тез азайту керек болса, нақты зиянды ағындарға нүктелік тыйым қойыңыз.
• Асимметрия мен NAT‑ты елемеу. Мониторингте ағымдардың бір бөлігі ғана көрінуі мүмкін және мекенжайлар өзгертілген болуы ықтимал. Кейін ережелер сәйкес келмейді. Симметрияны және NAT қай жерде болатынын тексеріп, логтарды NGFW орналасатын нүктемен салыстырыңыз.
• Тесттік және өндірістік өзгерістерді араластыру. Әр өзгерісті тәртіппен тіркеңіз: бөлек терезелер, ережелерге түсініктеме, конфигурация журналдарын міндетті тексеру.
• Ерекшеліктерді тым жеңіл санау. Пилотта ерекшеліктер әдетте көп болады. Сервис иелерін тағайындап, жауап мерзімдерін және өтініш форматын келісіңіз, әйтпесе пилот дау‑даппен тоқтап қалуы мүмкін.

Егер айнауда жоғалту, асимметриядан туындаған даулы сессиялар немесе өзгерістердегі хаос байқасаңыз, тоқтатып, ретке келтірген дұрыс. Бұл инлайнға өткеннен кейінгі ақауларды түзетуден арзанырақ.

Қысқа чек‑лист және пилоттан кейінгі келесі қадамдар

Пилот нақты нәтиже беруі үшін қысқа чек‑лист сақтап, жұмыстар барысында оны жаңартыңыз:

• мониторинг нүктесі: қайда TAP/SPAN қосылған, қандай VLAN/сегменттер көрінеді, не айнауға түспейді
• базалық сызық: тәуліктің уақыты бойынша трафик көлемі, типтік қосымшалар, шыңдар, критикалық бағыттар
• логтар және сақтау: қандай логтар қосылған, сақтау мерзімі, кім қолжетімді, пилот оқиғалары қалай белгіленеді
• есеп беру: күнделікті сводка форматы және қорытынды есеп, дедлайндар, «пилот табысты/сәтсіз» критерийлері
• жауаптылар: сервис иесі, желі, ИБ, NGFW әкімшісі, дежурная смена және эскалация арналары

Содан кейін қорытынды пакетті жинаңыз, инлайнға ауысу шешімі ойдан шығармаға емес, деректерге негізделген болу үшін:

• «кім кіммен сөйлеседі»: бағыттар, порттар және көлемдер, қайсысы кешіктірме талап етеді
• App-ID бойынша топ қосымшалар: не шынымен жұмыс істейді, не маскелденеді, қай жерде белгісіз қосымшалар бар
• ережелер кандидаттары: нені нақты рұқсат етуге болады, қайсысына ерекшелік қажет
• тәуекелдер және ерекшеліктер: шифрланбаған сервистер, стандарттан тыс порттар, ескірген клиенттер, DNS/NTP тәуелділігі
• қосқаннан кейінгі логтау жоспары: не жинауды жалғастыру және алғашқы 72 сағатта кім қарайды

Жұмсақ қосылуды кезеңдер бойынша жоспарлаңыз: алдымен allow‑only режимі және логтау (блоктау жоқ), кейін нақты зиянды және тыйым салынатын заттарға нүктелік тыйымдар, сосын зоналар мен қосымшалар бойынша қатаңдату. Әр кезең үшін кері қайтару қалай жүзеге асырылатынын алдын ала келісіңіз: шешімді кім қабылдайды және қанша уақытты алады.

Интегратор қажет болғанда қосыңыз: инлайн‑схеманы жобалау (маршрутизация, L2/L3), отказоустойчивость (HA, тамақтандыру, арналар) және қызмет көрсету процестерін әзірлеу үшін. Егер пилот критикалық сервисі бар тірі желіде жүргізілсе, инцидент кезіндегі әрекеттерді алдын ала жаттықтыру өте маңызды.

Егер пилоттан инлайнға қауіпсіз өту жолын толық өткізу керек болса (қосу схемасы, HA және дежурная регламенты қоса), бұл жұмысты GSE.kz командасымен бірге орындау ыңғайлы: пилот артефактілері дереу жұмыс жоспарына көшіріліп, қолдауға дайын болады.