Коммерциялық WAF-ты Nginx + ModSecurity-ке ауыстыру: шабуылдар, FP, релиздер

WAF-ты ауыстыру қайдан басталады және мақсатын қалай қою керек

Коммерциялық WAF-тан Nginx + ModSecurity жиынтығына көшу әдетте ережелерден емес, себептерден басталады. Көбінесе бұл лицензия шығындары, вендорға тәуелділік, баптаулар мен журналдарға толық бақылау қажеттігі, жергілікті қолдау және жабдықтау тізбесінің ашықтығы сияқты факторлар. Егер осы себептерді алдын ала бекітпесеңіз, жоба «бұрынғыдай ету» баптауларына айналып, нақты нәтиже түсініксіз болып қалады.

Күтулерді басынан-ақ нақтылаған жөн. WAF тәуекелді азайтады және кейшама шабуылдарды тосады, бірақ ол кодтағы осалдықтарды жоймайды және қауіпсіз дамытуды алмастырмайды. Қолданбада SQL-инъекция немесе аутентификация логикасында қате болса, фильтр белгілерді уақытша жауып қалуы мүмкін, бірақ мәселе қала береді.

Келесі қадам — сервис осыға сәйкес келетінін тексеру. Ең қолайлы жағдай — URL-дері мен формалары болжанатын, параметрлері түсінікті, клиенттер тұрақты және логтары жақсы веб-қосымша. Күрделі жағдайларда — көп өзгеше API, жиі релиздер, әртүрлі командалар және кез келген қосымша срабатывание табыске соққы береді — managed WAF периметрде қалдырылып, ModSecurity қосымша қабат ретінде немесе тек жеке домендерге қосылуы ақылға сыятын болады.

Бастамас бұрын апталар үнемдейтін нәрселерді келісіп алыңыз: сервис иесі мен ережелер иесі ("блоктау" туралы шешімді кім қабылдайды), инциденттер мен жалған блоктаулар бойынша SLA, өзгеріс терезесі және откат әдісі, табыс критерийлері (мысалы, жабылған шабуылдар үлесі және рұқсат етілген жалған срабатываний пайызы), сондай-ақ бастапқы режим — тек Detection па немесе бірден Blocking пе.

Мақсаттар мен шекаралар анықталған кезде WAF-ты ауыстыру «қауіпсіздік сиқырынан» басқарылатын инженерлік өзгеріске айналады.

Nginx пен ModSecurity нақты практикада не береді

Бұл модельде Nginx көбінесе қосымша алдында reverse proxy ретінде жұмыс істейді. Ол HTTP(S) трафигін қабылдап, TLS-ді аяқтап, сұрауларды нормализациялап, содан кейін upstream-қа жібереді. Фильтрация Nginx деңгейінде (http/server/location контекстінде) ModSecurity модулін қосу арқылы іске қосылады, сондықтан бақылау нүктесі қосымша алдында болады, яғни коммерциялық WAF тұрған жермен сәйкес.

ModSecurity — ережелер қозғалтқышы. Ең маңыздысы — оның екі негізгі режимі бар:

• Detection (жазып, логтау)
• Blocking (блоктау)

Шынайы енгізулерде әдетте Detection-нан бастайды, қандай нәрселер бұзылатынын көру үшін, және тек содан кейін блоктауды біртіндеп қосады.

Бастапқы пакет ретінде OWASP CRS пайдаланылады — "қораптан шыққан" типтік ережелер жинағы, ол веб-деңгейдегі көпшілік шабуылдарды жабады (инъекциялар, күмәнді заголовктар, кодировкаларды айналып өту, ерекше параметрлер). CRS қызметті «өтпес» етпейді, бірақ өмір сүруге болатын бастапқы деңгей береді, оны біртіндеп жақсартуға болады.

Коммерциялық платформалардан айырмашылық жиі мынада көрінеді: мұнда әдепкі бойынша жоқ — мінез-құлықты талдау және автотүйіндеу (auto-learning) сіздің трафикке бейімдеу, боттарға қарсы прогрессивті қорғаныс (браузерлік тесттер, отпечатоктар, репутация), L7 DDoS-тан қорғаудың managed-сервис деңгейіндегі механизмдері (челленджтер, ғаламдық желілер, дайын профильдер). Nginx + ModSecurity ережелердің ашық, бақыланатын қабаты ретінде жақсы жұмыс жасайды, бірақ коммерциялық WAF-тардың "автоматикасын" бөлек шешімдермен толықтыру немесе оны саналы тәуекел ретінде қабылдау қажет.

Қандай шабуылдар әдетте ережелермен жабылады

OWASP CRS қосылған кезде алғашқы жеңістер көбіне типтік веб-шабуылдарда көрінеді. Бұл "өздігінен ақылды қорғаныс" емес, URL, заголовктар, параметрлер, JSON немесе form-телдегі мазмұнға сигнатуралар мен тексерістер.

Ең жиі кездесетін категория — инъекциялар. Ережелер SQLi, XSS және командалық инъекцияларға тән фрагменттерді ұстайды: күтпеген тырнақшалар мен операторлар, күдікті функциялар, контекстті жабып, өз кодыңды қосуға әрекет. Мысалы, іздеу сұрағында q=' OR 1=1 -- сияқты параметр көбіне ескерту тудырады, тіпті қосымша өздігінен қорғанса да.

Екінші үлкен топ — файл жолдарын оқу немесе айналып өту әрекеттері. Path traversal әдетте ../ (әртүрлі кодировкаларда) түрінде көрінеді немесе жүйелік файлдарды ашуға әрекет. CRS осындай сұраулар мен типтік файлдар мен каталогтарға сканерлеу әрекеттерін жақсы ұстайды.

Бөлек пласт — протокол бұзушылықтары және "қалыптан тыс" сұраулар: дұрыс емес әдістер, күтпеген үлкен денелер, қайшылықты заголовктар, күдікті Content-Type мәндері, сондай-ақ боттар мен сканерлер жиі пайдаланатын "бұзылған" сұраулар.

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

Админ-панельдерді қорғауды тек CRS-ке сеніп қалмай, қосымша Nginx бақылаулары мен нақты шектеулермен (тек қажетті әдістерді рұқсат ету, IP бойынша қолжетімділікті шектеу, гео-шектеулерді ақылмен қосу) үйлестіру тиімді.

Ережелер "кеңірек" болған сайын, заңды сұрауларда жалған срабатывания қаупі артады. Сондықтан бақылау режимінен бастаған дұрыс және ең сенімді категориялардан бастап блоктауды қосу қажет.

Қорғаныс шекаралары: WAF не шеше алмайды

Nginx + ModSecurity-қа миграция жасағанда шекараларды алдын ала келісіп алу маңызды. WAF ережелер бойынша типтік веб-шабуылдарды ұстайды, бірақ ол қосымшаны өзі қауіпсіз етпейді. Күтулер артық болса, сіз "тесіктер" немесе шексіз жалған блоктаулар аласыз.

Қай жерлерде сигнатуралар сәтсіздікке ұшырайды

OWASP CRS деңгейіндегі ережелер көп жағдайда шаблондарға сүйенеді. Оларды пайдалы жүктемені әртүрлі етіп өзгерту, кодировкалар, параметрлерді бөлу, сирек кездесетін заголовктар және өрістердің стандартты емес тәртібі арқылы айналып өтуге болады. Кейде шабуыл кәдімгі бизнес-сұрау сияқты көрінеді және WAF оны қосымша контекстсіз ажырата алмайды.

Тағы бір қапшық — WAF-қа жиі тән деп есептелетін, бірақ іс жүзінде басқа қорғаныс түрлері атқаратын функцияларға үміт арту: антибот және мінез-құлықтық қорғаныс (скрейпинг, накрутка, брутфорс), құрылғы отпечатоктары мен сессиялық риск-скоринг, репутацияға негізделген есептік жазбаларды қорғау (credential stuffing), API-ларды схема мен контракт бойынша қорғау және "инциденттерді қызмет ретінде" (аналитика мен әрекет) басқару.

Протоколдар және өнімділік

Трафикті тексеру сіз қалай прокси жасайтыныңызға байланысты. TLS-де сіз шифрлауды проксида аяқтайсыз немесе мазмұнды көрмейсіз. HTTP/2, WebSocket және әсіресе gRPC-де ұзақ өмір сүретін қосылымдар, бинарлы денелер, арнайы заголовктар кездеседі. Формалды түрде бұл жұмыс істеуі мүмкін, бірақ мазмұнды талдау мен ережелер қиын болады немесе кейде онша пайдалы болмайды.

Өнімділік көбіне сұрау денелерінің көлемі мен ережелердің күрделілігіне байланысты мәселелерге ұшырайды. Үлкен JSON, файл жүктеулері, параллель сұраулар және ауыр регулярлы өрнектер CPU-ны тез жұмсайды. Егер everywhere (әр жерде) терең тексеру қоссаңыз, кешігулер мен таймауттар пайда болып, олар қосымшаның істен шығуы сияқты көрінуі мүмкін.

Қашан комбинирлеу керек

WAF ең үлкен әсерді басқа шаралармен бірге бергенде көрсетеді: логикалық осалдықтар мен авторизация қателерін түзету, rate limiting және дене өлшемдері шектеулері, критикалық эндпоинттер үшін қатты allowlist/схемалар, антибот-шешімдерді нақты бизнес қажеттілігі бар жерлерге қою. Осы шекараларды ескерсек, ModSecurity болжамды бақылау қабатына айналады, бірден барлық қорғаныс орнына емес.

Архитектура таңдау және трафиктегі орны

Бірінші шешім — WAF қай жерде тұрады. Ең қарапайым вариант — периметрде, балансировщик алдында немесе одан кейін, жалпы кіріс трафигін жабу үшін. Бұл көптеген сервистер болғанда және біртұтас бақылау керек болғанда ыңғайлы. Егер сервистер өте әртүрлі болса (мысалы, жария сайт пен ішкі API), WAF-ты нақты сервиске жақын қою жеңілірек: ережелерді баптау оңай, заңды сұрауларды бұзудың қаупі төмен.

Кейде WAF бөлек зонада (DMZ) тәуелсіз прокси қабаты ретінде орналастырылады. Бұл қатты желілік шекаралар маңызды болғанда пайдалы, бірақ қосымша хоп қосып, отладканы күрделендіреді.

Төмен сатып алымдылық үшін WAF кіріс нүктесі сияқты сенімді болуы тиіс. Көбінесе балансировщик артында актив-актив (бірдей конфигурациялы бірнеше нода), актив-пассив (резервтік нода және тез ауысу) немесе жүктеме бойынша горизонтальды масштабтау таңдалады.

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

Конфигурацияларды код ретінде сақтаңыз: бір репозиторий, версионирлеу, ревью және түсінікті өзгерістер. Сонда исключение неліктен қосылған және кім қосқанын көруге болады.

Откат жоспары жылдам болуы керек: Detection/Off ауыстыратын переключатель сервис немесе location деңгейінде болсын. Егер релизтен кейін API-да блоктаулар көбейсе, проблемалық ережені тез Detection-ға ауыстырып, жалған срабатыванияларды түзеп, блоктауды қайта қосуға болады, трафик тоқтамай.

Қызметке кідіріссіз кезең-кезеңімен миграция

WAF миграциясының қауіпті тұсы — блоктауға кесіп ауыстыру емес, бұл өзгертуді асыра қолдану. Оны тоқтатпай өту үшін байқаудан бастаңыз.

Бірінші қадам — ModSecurity-ті Detection режимінде қосып, нақты трафикте жұмыс істетіңіз. 3–7 күннің ішінде негізгі картинаны көруге болады: қай ережелер жиі срабатывает, қандай әдістер мен URI тексеріледі, қай жерде күтпеген пиктер бар.

Содан кейін OWASP CRS қосып, блоктауға асықпаңыз. Бұл кезеңде қосымшаның типтік мінезін бақылап шығу маңызды: формалар, авторизация, іздеу, файл жүктеулері, API.

Параллельді түрде техникалық баптауларды реттеңіз: әйтпесе кей сұраулар дұрыс талданбайды. Көбіне қаралатындар — сұрау денесінің және жеке параметрлердің шектеулері, файл жүктеулердің (multipart) дұрыс өңделуі, JSON талдауы (content-type, кодировка), логтардың бірыңғай форматы және request id арқылы корреляция.

Статистика анықталған соң, бірнеше критикалық эндпоинтті таңдап, біртіндеп блоктауды қосыңыз. Әдетте админка, авторизация, төлем сұраулары және контакт формалары сияқты бизнес үшін ауыр нүктелерден бастайды. Қалғандары үшін Detection ұстап, исключения жинақтап отырады.

Алдын ала дежур және сервис иесіне қысқа runbook әзірлеңіз: шабуылды жалған срабатываниедан қалай ажырату, Nginx пен ModSecurity логтарында қайдан қарау, ережені уақытша қалай әлсірету (URI немесе параметр бойынша) және өзгерістерді бүкіл сервисті қайта іске қоспай қалай қайтару.

Жалған срабатыванияларды жинау және талдау

Жалған срабатывание (false positive) — WAF заңды қолданушы немесе сервис сұрауын блоктаған кезде болады. Кім шешім қабылдайтынын алдын ала келісу маңызды: қауіпсіздік тәуекел үшін жауап береді, ал қосымша иесі сұраудың шынымен заңды әрі бизнеске қажетті екенін растайды.

Detection режимінен бастап базалық статистиканы жинаңыз. "Тыныш кезең" болмаса, сіз инциденттерді сөндірумен өткізесіз, баптаумен емес.

Оқиғаларды тез талдау үшін логтардан шығатын пайдалы заттар: rule id, не сәйкес келгені (matched data), URL мен әдіс, параметрлер мен заголовктар, жауап статусы. Бір rule id бойынша жиі срабатывание SQLi, XSS немесе, мысалы, дене форматының күдікті болуы екені көрінеді.

FP-ті басу тәсілдері — қауіпсізірек нұсқадан қауіптірекіне дейін:

• нақты параметр бойынша қоспа жасау (тек comment өрісіне арнайы символдарға рұқсат беру)
• эндпоинт бойынша исключение (тек бір URL үшін ерекше форматқа рұқсат)
• rule id бойынша ережені өшіру (тек салмақты себеп болса және басқа шаралармен өтеме жасалса)

Исключения минималды және негізделген болуы тиіс. Комментарий, иесі және мерзімі (мысалы, 30 күн) қосыңыз, сонда исключение қайта қаралады. Егер тексеруді әлсірету керек болса, бірінші кезекте нақты өріс немесе формат үшін шектеу жасаңыз, сайттың бәрі үшін емес.

FP-пен жұмыс процесі әдетте мынадай: тикетке сұрау үлгісі мен уақыт қосылады, тестте қайта жасау және қосымша иесі арқылы растау, исключение бойынша шешім және қауіпсіздікпен келісу, ережені релизбен бірге енгізу және выкаттан кейін қысқа уақыт логтарды тексеру.

Ережелерді релиз процесіне енгізу

Ең маңыздысы — продта ережелерді қолмен түзетуді доғару. Ережелер кодпен бірге өмір сүруі және басқа өзгерістер сияқты сенімді түрде шығуы керек.

Ережелер — код ретінде

Жалпы ережелер, исключения және локальды доработкаларды бөлу ыңғайлы. Осылай өзгерістерді көру және откаттау оңайырақ:

• crs/ - өзгеріссіз OWASP CRS (бөлектеп PR арқылы жаңартылады)
• custom/ - нақты қосымшалар мен API үшін сіздің ережелер
• exclusions/ - исключения (URL, параметр, әдіс бойынша байланыстырылған)
• tests/ - тексеру сұраулары жиынтығы (заңды және шабуылдық)
• docs/ - келісімдер мен типтік шешімдердің қысқаша сипаттамасы

PR үшін қысқа шаблон пайдалы: не үшін өзгеріс, қандай тәуекел, қандай эндпоинттер зақымданады, қандай логтар мен оқиғалар күтіледі. Ревью міндетті: ереже оңайша жалған срабатываниеға емес, қауіпсіздіктің бұзылуына әкелуі мүмкін.

Өзгерістерді қалай шығаруға болады

Әртүрлі ортадағы қатаңдық — қалыпты тәжірибе. dev-та агрессивті ережелерді қосып, ерте проблемаларды ұстаңыз, ал prod-та минимум қажетті блоктауды ұстап тұруға ыңғайлы.

Релиз алдында автотесттерді іске қосыңыз: "жақсы" сұраулар блокталмауы тиіс, ал "жаман" сұраулар сенімді ұсталуы керек. Жұмыс тәртібі әдетте келесідей: алдымен stage-та Detection-only, содан кейін prod-та кішкене бөлікте, кейін ең сенімді ережелер бойынша нүктелік блоктау, әсерді өлшеу (блоктар үлесі, FP саны, жүктеме, қолданушылардан келетін шағымдар), тез откат (флаг/окружение айнымасы немесе ережелердің алдыңғы тегіне оралу).

Осылайша ережелерді шағын порциямен шығарасыз, әсерді бірден көресіз және WAF-ты релизтерге кедергі келтіретін "қара қора" еткеннен сақтайсыз.

Бақылау: логтар, метрикалар және алертер

Nginx + ModSecurity-ға өткенде дайын дашбордтардың бір бөлігі жоғалуы мүмкін, сондықтан бақылауды саналы түрде жинау керек. Әйтпесе шабуылды байқамай қаласыз немесе жалған срабатываниялардан ережелерді әдейі өшіруге кірісесіз.

Тұрақты түрде қарауға тұрарлық минимум: уақыт бойынша блоктау үлесі (blocked vs allowed), ең көп срабатываған ережелер (rule id) және олардың динамикасы, срабатывания жиі болатын эндпоинттер, Nginx деңгейіндегі кешігу және WAF әсері (егер бөлек өлшесеңіз), статус-кодтар таралымы (200/3xx/4xx/5xx) WAF оқиғаларымен қатар.

WAF-ты қосымшадан бөлек қарамау маңызды. Егер ережелерді өзгерткеннен кейін 403 көбейсе, қай сұраулар блокталғанын және қосымшадағы қателер өсімімен сәйкес келетінін тексеріңіз. 5xx өссе, бұл шабуыл емес, ереженің ауыр сұрауды өткізіп жіберіп, қосымша шыдамағаны немесе ретрайлер мен таймауттардың арқасында жүктеменің өскені болуы мүмкін.

Алерттарды қарапайым ету керек: орташаға қарағанда блоктау шұғыл секірісі (мысалы, 3–5 есе), бір эндпоинтте немесе бір клиент/підсеткада 403-тің өсуі, ережелерді өзгерткеннен немесе OWASP CRS жаңартылғаннан кейін 5xx өсімі, топқа жаңа ереженің кіруі, блоктауды қосқаннан кейін кірістегі latency-тің тұрақты өсуі.

Логтарды инциденттер мен FP-ті талдауға жарайтындай етіп сақтаңыз: сұрау, ереже, себеп, endpoint, корреляция идентификаторы (request id), қайдан келгені. 2–4 аптада бір рет исключенияларды қайта қарап отырыңыз: ескі жолдар жоғалып, жаңалары пайда болады, уақытша айналып өту тұрақты түрде қалса, ол тесіктерге айналуы мүмкін.

Коммерциялық WAF-ты ауыстыруда жиі кездесетін қателіктер

Миграцияның сәтсіздігі көбінесе ModSecurity мен Nginx-те емес, тәсілде болады. Көп күтеді, ережелер бірден бәрін блоктайды және бизнеске кедергі болмайды. Іс жүзінде алғашқы апталар бақылауға, баптауға және тәртіпке кетеді.

Қолжетімділікке қатты соққы беретін қателіктер

Көбіне былай болады: бірден блоктауды қосады да заңды сұрауларда күтпеген 403-тер пайда болады; исключенияларды тым кең қылып қояды (мысалы, "/api"-ның бәрін тексермеу), нақты трафик форматын (JSON, multipart, үлкен файлдар, ұзын заголовктар, ерекше кодировкалар) тексермейді; откат жоспары мен жауапты адам болмайды; WAF-ты spike қорғауымен шатастырады (WAF сұраулар деңгейіндегі шабуылдарды ұстайды, бірақ rate limiting және базалық қорғанысты алмастырмайды).

Алдын ала қарапайым ереже белгілеу пайдалы: ережелер сапасы сенімді болмағанша Detection режимінде жұмыс істейміз, сұрау мысалдарын жинаймыз және әр срабатывание бойынша шешім қабылдаймыз.

Практикалық қысқа мысал

Топта құжат жүктеу формасы мен мобильді қолданбаға арналған жеке JSON API бар делік. Ережелер қосылғаннан кейін comment параметріне байланысты оқиғалар көбейеді, себебі қолданушылар \\u003c\\u003e символдарын немесе код үзінділерін қояды. Егер барлық POST сұраулары үшін тексеруді өшірсеңіз, қорғанысты қажет жерлерде жоғалтасыз.

Дұрысы — исключение тар ету: оны нақты параметр мен нақты эндпоинтке байлау, мерзім қойып, параллельде ең ауыр әдістерге rate limiting қосу.

Блоктауға ауысқанға дейін және одан кейін қысқа чеклист

Ең қауіпті сәт — Detection-нан Blocking-қа ауысу. Қолданбаны түсіріп алмай және инциденттерге батпай тұруға көмектесетін чеклист:

Алып қосар алдында:

• сервис пен критикалық эндпоинттер, иелері, өзгеріс терезелері бекітілген
• сұрау денесі өлшемі лимиттері, рұқсат етілген әдістер, кодировкалар, URL нормализациясы бапталған
• real IP қосылған (оқиғаларда нақты клиент болу үшін) және логтар бірыңғай форматта
• бастапқы кезең Detection-да және қосу кезеңдері жоспарланған: бір сервис немесе трафиктің аз бөлігі, кейін кеңейту
• жалған срабатыванияға арналған процесс бар: кім шешім қабылдайды, разборға SLA, шешім қайда сақталады, исключения атаулары мен қайта қарау мерзімі

Бірінші Blocking релизінен кейін бақылауды нығайтыңыз:

• метрикаларға қараңыз: блоктау үлесі, топ ережелер, топ URL, 4xx/5xx өсімі және негізгі бизнес оқиғаларға әсер
• эндпоинт, ереже және көз бойынша блоктау шоғырлануына алертер қойыңыз
• әр инцидент бойынша қысқа ретро жасаңыз: не блокталды, не себептен, қалай анықталды, ережелер мен тесттерде не жақсарту керек
• исключенияларды тұрақты тазалаңыз: уақытшаларды жою, дубликаттарды біріктіру, мерзім мен иені белгілеу
• ережелерді қосымшаның релиздерімен сәйкестендіріңіз: API жаңартылғанда немесе жаңа форма қосылғанда алдын ала түзетулер мен тест-кейстер дайындаңыз

Нақты енгізу мысалы: пилоттан тұрақты қорғанысқа дейін

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

Пилотты апта бойынша бөліп өткізу ыңғайлы:

• Апта 1: Detection режимі. OWASP CRS бойынша оқиғалар жиналады, ең көп срабатываған 10 ереже мен 20 URL анықталады, қай жерде шабуыл, қай жерде бизнес-логика екені белгіленеді.
• Апта 2: нүктелік исключения. Тек нақты параметрлер мен жолдарға тар exclusions жасалады, stage-та типтік сценарийлер (кіру, іздеу, форма жіберу) тексеріледі. Админка үшін SQLi, RCE сияқты анық категориялар бойынша ішінара Blocking қосылады.
• Апта 3: Blocking-ті кеңейту. Блоктауды сыртқы формаға біртіндеп енгізеді, бірақ алдымен сирек және анық зиянды сигнатуралар мен аномальды сұраулардан бастайды.

Өнімге зиян келтірмейтіндігіңізді білу үшін күнделікті мониторингке келіседі: сыртқы форма конверсиясы және 4xx/5xx қателердің үлесі, жауап уақыты және клиенттік ретрайлердің өсуі, кілтті URL-дар бойынша блокталған сұраулар үлесі, қолдау көрсетулердегі "жіберілмейді" немесе "кіргізбейді" сияқты шағымдар саны.

Кейін архитектуралық сұрақтар шығады: нақты IP қай жерде жоғалады, портал мен форма үшін саясатты қалай бөлу, ережелерді релиздермен бірге қалай версионировать. Қолдау жетпесе немесе 24/7 қажет болса, бұл кезеңде жиі интеграторға тапсырады. Мысалы, GSE.kz (gse.kz) сияқты жүйелік интегратор WAF айналасындағы инфрақұрылымды енгізуге және қолдауға көмектеседі.