Secure Web Gateway‑қа техникалық тапсырма (ТЗ): SSL inspection, санаттар және AD

Secure Web Gateway неғұрлым түсінікті тілде

Secure Web Gateway (SWG) — қызметкерлердің веб‑трафигі үшін бақылау нүктесі. Ол пайдаланушының интернетте қайда баратынын, не жүктеп жатқанын және қандай деректерді сыртқа жіберуге тырысатынын тексереді және компания ережелерін бұзатын әрекеттерді бұғаттайды. ТЗ‑де бренд емес, міндеттерді, тәуекелдерді және күтілетін нәтижені анық жазған жөн.

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

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

SWG‑дегі сүзгілеу әдетте бірнеше қабаттан тұрады: URL және домендер бойынша блоктау, санаттар бойынша (әлеуметтік желілер, құмар ойындар, ересек мазмұн, анонимайзерлер және т.б.) және веб‑қосымшаларды бақылау. Мысалы, Teams‑ке рұқсат беруге болады, бірақ жеке бұлттарға файл жүктеуге тыйым салуға болады.

SWG орналастыруы әртүрлі болуы мүмкін: бас офисте (прокси/шлюз), филиалдарда (жергілікті түйін немесе орталыққа туннель), қашықтан жұмыс істейтін қызметкерлер үшін (агент немесе міндетті прокси). ТЗ‑де алғашында қай жерде шешім орналасатынын және нені қорғайтынын анықтап алу керек, сосын ғана SSL inspection және саясаттар туралы егжей‑тегжейге көшу қажет.

FortiProxy, Blue Coat және on‑prem баламалар: қалай салыстыру керек

FortiProxy, Blue Coat пен басқа нұсқаларды салыстырмас бұрын форматты анықтаңыз: on‑prem, бұлттық сервис немесе гибрид.

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

Шешімдерді салыстырғанда нақты сценарийлерді (офис, филиалдар, удаленка, қонақ Wi‑Fi, сервер сегменттері) және 1–2 жылдағы өсу жоспарын ескеріңіз.

Практикалық критерийлер, барлық нұсқаларда тексеруге тұрарлық:

• Өнімділік: SSL inspection қосылғанда өткізгіштік, қағаздағы көрсеткішпен шектелмей.\n- Масштабтау: кластер, жоғары қолжетімділік, сайттар бойынша тарату.\n- Саясаттар: санаттар, исключения, кестелер, топтар үшін әртүрлі ережелер.\n- Интеграциялар: AD/LDAP, прокси‑аутентификация, SIEM, DLP (қажет болса).\n- Эксплуатация: есептер, база жаңартулары, қолдау және жауап уақыты.

Лицензиялау бөлек қарастырылсын. Біреулерде шектеу пайдаланушылар бойынша, басқаларында — өткізу қабілеті бойынша, тағы біреулерінде — модульдер бойынша (фильтрация, SSL inspection, sandbox). ТЗ‑де жеткізілімге не кіретінін және қандай шектеулер қабылданбайтынын нақты жазыңыз (мысалы, "SSL inspection тек N Мбит/с дейін" немесе "санаттар тек қымбат пакетте қолжетімді").

ИБ және ішкі реттеушілер талаптарын алдын ала ескеріңіз: логтар қайда сақталады, кімге расшифрланған трафикке қолжетімділік беріледі, исключения қалай рәсімделеді, журналдардың тұтастығы қалай расталады. Егер on‑prem жоспарласаңыз, орын мен жабдық талаптарын дереу енгізген жөн. Бұл бөлікті әдетте жүйелік интеграторлар жабады — серверлерді таңдау мен қосу сұлбасынан бастап эксплуатацияға дейін.

ТЗ жазарда жинау керек бастапқы мәліметтер

Жақсы ТЗ Secure Web Gateway‑ды FortiProxy немесе Blue Coat‑тан бастамайды, ол бастапқы енгізулерден басталады. Солсыз SSL inspection, санаттар және логтар бойынша талаптар тым жалпылама немесе орындалмауы мүмкін болады.

Алдымен қанша пайдаланушыңыз бар және олар қайда жұмыс істейтінін анықтаңыз: бас офис, филиалдар, удаленка, мердігерлер. "400 адам" ғана емес, әркімнің қолжетімділік үлгісін сипаттау маңызды: кімде тұрақты VPN бар, кімнің тікелей интернетке шығуы бар, қонақ және Wi‑Fi үшін бөлек желілер бар ма.

Одан кейін жүктеме бойынша сандар керек. Желі командасынан минимум пиковый трафик пен HTTPS үлесі жөнінде бағалау сұраңыз. "Ауыр" сценарийлерді бөлек атап өтіңіз: видеоконференциялар, видео оқыту, үлкен жүктеулер, ПО жаңартулары. Бұл расшифровка өнімділігіне және шлюз орналасуына тікелей әсер етеді.

Критикалық бизнес‑қызметтер блок ретінде сипатталсын: мемлекеттік порталдар, интернет‑банкинг, бұлттар, CRM, пошта, бухгалтерия. ТЗ‑де мұндай қызметтер үшін не маңызды екенін көрсеткен дұрыс: қолжетімділік, минималды кешігу немесе толық логирование.

Ақырында — инфрақұрылымда не бар және ол қалай бірге жұмыс істеуі керек. Әдетте Active Directory (OU/топтар құрылымы), SIEM (қандай оқиғалар қажет және қанша жылдамдықпен), DLP/EDR (пайдаланушыға байланысты корреляция қажет пе), DNS‑фильтрация немесе бар прокси бар. Қысқаша мысал: егер филиалдар әртүрлі арналар арқылы интернетке шықса, ал AD бірегей болса, бұл пайдаланушыларды идентификациялау және логтарды орталықтан жинау талаптарын қояды.

SSL inspection: талаптарда міндетті түрде не жазу керек

SSL inspection әдетте ең даулы тармақ болады. Онсыз сүзу көп жағдайда соқыр, ал онды қосқанда приваттық, үйлесімділік және жүктеме мәселелері туындайды. Талаптарда алдын ала қандай бақылау қажет екенін және қай жерде исключения жасалатынын белгілеңіз.

Алдымен расшифровка режимдерін сипаттаңыз. Әдетте таңдау немесе үйлесімділік болады:

• барлық HTTPS‑ты толық расшифровка;\n- пайдаланушылар топтары бойынша таңдамалы расшифровка;\n- тек тәуекел санаттарына арналған расшифровка (зиянды сайттар, анонимайзерлер, фишинг, соңғы уақытта тіркелген домендер).

Әр бөлімшенің әртүрлі режимі болуы керек пе — соны көрсетіңіз.

Сертификаттарды сипаттау маңызды. Корпоративтік root сертификатты кім шығаратынын, оны Windows, macOS, мобильді және жеңіл клиенттерге қалай тарату керектігін, ротация жиілігін және табыстың өлшемін (мысалы, дұрыс сенім көрсеткен құрылғылар үлесі) көрсетіңіз. Қазіргі TLS нұсқаларын қолдау және қателерді өңдеу талаптарын бөлек атап өтіңіз.

Исключениялар «сұрау бойынша» емес, ережелер бойынша көрсетілсін. Мысалы, интернет‑банкинг, медициналық порталдар және жеке кабинеттер bypass‑қа жіберілуі мүмкін, бірақ қолжетуді және негізгі метадеректерді тіркеу сақталуы керек. Сондай‑ақ қандай санаттарды белгісіз себебпен исключать етуге болмайтынын көрсетіңіз.

Іске қосқаннан кейін даулар болмас үшін өлшенетін талаптар қосыңыз:

• сұрауға рұқсат беретін қосымша кешігулер және бетті жүктеу уақытының өсуі;\n- максималды жүктеме — бір уақытта сессиялар мен трафик;\n- пилотте қалай өлшенеді (тексеріс алдында және кейін SSL расшифровка қосқанда).

Жекелей құпиялық тармағын бекітіңіз: SSL inspection кезінде логқа қандай өрістер түседі, кімге расшифрланған деректерге қолжетімділік беріледі, журналдарды қанша уақыт сақтау керек және қолжетімділік қалай рәсімделеді. Мысал: "контентті сақтамау, тек метадеректер мен санатты сақтау; логтарға қолжетімділік — ИБ‑ға сұрау бойынша, тіркеумен".

Санаттар, саясаттар және қолжетімділік ережелері

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

Міндетті санаттар жиынтығы және шешім логикасы

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

«Белгісіз санат» пен классификация қатесі жағдайында мінез‑құлықты міндетті түрде жазыңыз: SWG сайтты анықтай алмаса немесе қате санатқа жатқызса не істеу керек.

Одан кейін топтар бойынша саясаттарды сипаттаңыз. Мысалдар:

• бухгалтерия — банктер мен мемлекеттік ресурстарға қолжетімділік, бірақ файлобменді қатты шектеу;\n- ИТ — документация мен репозиторийлерге қолжетімділік, бірақ жүктеулер бақылауда;\n- қонақтар — қарапайым ережелер жиынтығымен шектеулі қолжетімділік;\n- оқу топтары — әлеуметтік желілерге тыйым, бірақ оқу платформаларына рұқсат.

Жеке санаттар мен тізімдер бөлек көрсетілсін: ұйымның домендері, серіктестері, критикалық SaaS‑қызметтер. Кім жазымдарды қоса алатынын және өзгерістер қашан күшіне енетінін анықтаңыз.

Кестелер туралы ұмытпаңыз. ТЗ‑де әртүрлі режимдер (жұмыс уақыты, емтихандар, ауысымдық кесте) және өзгеретін параметрлер: санаттар, шектеулер немесе тізімдер көрсетілгені жөн.

Исключения: қауіпсіздікті хаосқа айналдырмау

Исключения міндетті түрде болады: кей сайттар тексеруден өту кезінде бұзылады, кейбірі бизнес үшін қажет. Мәселе — исключения ауызша пайда болып, жылдар бойы сақталған кезде болады. ТЗ‑де техникалық флагтерден бөлек, оларды басқару ережесін жазған дұрыс.

Ақ тізім: кім және қанша уақытқа

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

Тексеруге болатын етіп, исключение өтінішіне кемінде мына ақпаратты қажетті етіңіз: не исключается (домен/URL/санат/қосымша), себеп және ықтимал тәуекел, мерзім және исключation иесі, кім және қашан келіскен, исключение әлі де қажет екенін қалай тексеру.

SSL inspection: «бұзылатын» сервистерге исключения

Кейбір критикалық сервистер расшифровкаға төзімсіз (certificate pinning немесе арнайы клиенттер себебінен). Мұндай исключения нүктелі болуы тиіс: нақты домендер мен пайдаланушы топтары үшін, «барлығына SSL inspection өшіру» дегенге жол берілмесін.

Түнде немесе филиалда уақытша айналып өту (break‑glass) режимі кімде болатынын, максимум мерзімін (мысалы, 1–4 сағат) және бұл әрекеттер журналда міндетті түрде жазылатынын көрсетіңіз.

«Көлеңкелі исключенияларға» тыйым салыңыз: жергілікті деңгейде қолмен өзгерістер, браузердегі жеке ережелер немесе филиалдардағы жеке проксидер болмауы тиіс. Барлық өзгерістер — тек орталық басқару арқылы, логтармен және есеппен.

Логирование, есептер және зерттеу

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

Әр оқиға үшін (рұқсат, блок, ескерту) қажет минималды өрістер:

• пайдаланушы (немесе техникалық идентификатор, егер пайдаланушы анықталмаса),\n- топ (AD‑тан немесе локальды рөл),\n- URL және домен (және тағайындалған IP),\n- санат және срабатывание себебі (санат/репутация/ережелер),\n- әрекет (allow/block/monitor),\n- уақыт,\n- қайдан (IP, филиал/площадка).

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

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

Зерттеулер үшін SIEM‑ге интеграция пайдалы: қандай оқиғалар жіберіледі, қандай форматта (мысалы, syslog CEF/LEEF немесе JSON), жиілігі және уақыт синхронизациясы. Мысал: егер бухгалтерия кенеттен жаңа тіркелген домендерге ондаған сұрау жасаса, логтардан пайдаланушы, топ, санат, ереже және дәл уақыт көрінуі тиіс, сол арқылы оқиға тізбегін жылдам көтеруге болады.

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

AD‑пен интеграция: пайдаланушылар, топтар және SSO

Егер қалай SWG пайдаланушыны танитынын жазбасаңыз, есептер IP‑адрестер бойынша шығады да, «кім бұл еді» деген даулар басталады. Бастапқыда идентификация моделін анықтап, филиалдар, NAT және удаленка үшін жарайтынын тексеріңіз.

Көбіне бір вариант немесе комбинация қолданылады: Kerberos/NTLM арқылы SSO (доменде мөлдір авторизация), ПК‑ға агент орнату пайдаланушы мен топты беру үшін, прокси‑аутентификация (explicit proxy) домендік учеткамен, сирек жағдайларда captive portal және қонақ құрылғылар үшін қарапайым сценарий.

Содан кейін саясаттарды AD құрылымына байланыстыру маңызды. Қай топтар немесе OU құқық көздері болып есептелетінін және қайшылық кезінде не болатынын көрсетіңіз (мысалы, пайдаланушы екі топта болса). Принципті бастапқыда бекітіңіз: рұқсат топқа сәйкес анықталады, пайдаланушы атауындағы лауазым бойынша емес.

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

Қонақтар мен мердігерлер үшін бөлек контур жасаңыз: бөлек есептік жазбалар, қысқа мерзімді саясат және өшіру процедурасы.

Журналда жазылуы тиіс: пайдаланушы, топ, құрылғы, NAT‑қа дейін және кейінгі IP, филиал немесе площадка. Мысал: филиалда 200 адам бір ақ IP арқылы интернетке шықса, "пайдаланушы + жұмыс станциясы + көз" байланысы жоқ болса, зерттеу табусыз болады.

Қадам бойынша: ТЗ‑ны қалай жазу керек, теріс түсінбеушіліктер болмас үшін

Бастапқыда бір беттік "жоба шекарасы": сіздің жағдайда Secure Web Gateway не деп есептеледі (қызметкерлердің веб‑қол жеткізуі, серверлердің интернетке шығуы, қонақ желі) және не кірмейді (мысалы, пошта немесе бөлек DLP жүйесі). Бұл артық күтулерді шегеріп тастайды.

Содан кейін талаптарды бірдей форматта бекітіңіз: "сценарий → ереже → күтілетін нәтиже → қалай тексереміз". Қабылдағанда тексеру критерийі болса, түсініксіздіктер азаяды.

1) ТЗ құрылымын қысқа және нақты көрсетіңіз

Құжатты бес блокта ұстаған ыңғайлы:

• Рөлдер мен құқықтар: кім админ, кім тек есептерді қарайды, кім исключенияны бекітеді және қандай мерзімде.\n- Желілік сценарийлер: явный прокси, мөлдір режим, PAC арқылы жұмыс, VPN арқылы және офистен тыс жұмыс.\n- Қолжетімділік: кластер/резерв, конфигурациялар қайда сақталады, узел құлдыраса не болады, жаңартулар тоқтатпай жүргізіле ме.\n- Қабылдау: тесттер тізімі және қабылдау есебі форматы.\n- Құжаттама және оқыту: қандай нұсқаулықтар керек және кімді оқыту қажет.

2) Қабылдау тексерістерін дереу көрсетіңіз

"Тұрақты жұмыс істеу керек" деген жалпылама фраза көмектеспейді. Төмендегі тесттерді міндетті түрде қосыңыз және не «өтілді» екенін анықтаңыз:

• Санаттар бойынша қолжетімділік: 5–10 тест сайттар рұқсат және тыйым санаттарынан.\n- SSL inspection: таңдалған топтар үшін және исключенияны тексеру (мысалы, банктер/мемресурстар).\n- Пайдаланушы идентификациясы: пайдаланушы/топ (AD) дұрыс анықталып, саясат қолданылғанын тексеру.\n- Логтар мен есептер: пайдаланушы, сайт, санат, әрекет, блоктау себебі көрінуі; мерзім бойынша экспорт.\n- Узел тоқтауы: бір құрылғының құлауында трафик алдын ала келісілген сценарий бойынша жалғаса беруі.

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

ТЗ‑да жиі жасалатын қателер және салдары

Ең қымбат қате — TЗ‑ды жалпы тілде жазу. "Қауіпті сайттарды сүзу" немесе "лог жүргізу" сияқты жалпы формулировкалар қабылдауда дау тудырады: қандай сайт "қауіпті", қандай логтар қажет, қанша мерзімге және қандай детальдармен, кімде қолжетімділік болу керек.

Көбіне SSL inspection қосылғанда проблемалар басталады. Егер талаптарда HTTPS үлесі, өнімділік талаптары және қабылданатын кешігулер көрсетілмесе, іске қосқаннан кейін "интернет баяу" және корпоративтік сервистердің істемеуі сияқты шағымдар келеді.

Эксплуатацияда хаосқа әкелетін жиі қателер:

• Қабылдау өлшемдері көрсетілмеген (жылдамдық, санаттар жабылуы, логтардың толықтығы) — жеткізуші тапсырманы «орындап береді», бірақ пайдалану ыңғайсыз болады.\n- SSL inspection ешқандай шартсыз қосылған — банктер, медицина сервисі және ПО жаңартулары бұзылады.\n- Исключения процесі жазылмаған — "ашуландырыңыз" деген өтініштер чаттарда шешіледі, жазбасыз.\n- Филиалдар, NAT және прокси тізбектері ескерілмеген — логтарда тек сыртқы IP көрінеді, зерттеу «кім болды» сұрағына айналады.\n- Рөлдер мен құқықтар араласпауы керек — админдар келісімсіз саясаттарды өзгертеді, әрі «бүгін жұмыс істеді, кеше істемеді» деген сұрақтар туындайды.

Жақсы ТЗ алдын ала: кім исключенияны бекітеді, қалай олар құжатталады, қандай өзгерістер келісуді талап етеді және саясаттардың пайдаланушыға емес, "анықталмаған IP"‑ға емес екендігін қалай тексеру керек дегендерді бекітеді.

Қысқа чек‑лист: ТЗ‑да бәрі бар ма

Талаптарды келісімге жіберіп немесе сатып алуға шығар алдында қысқа тізім арқылы тексеріңіз. Бұл құжаттың ИБ мен ИТ үшін бірдей оқылатындығын қамтамасыз етеді.

• Контекст пен масштабы: қанша пайдаланушы, қандай құрылғылар, қай жерде филиалдар мен байланыс арналар, қай қызметтер критикалық (банк‑клиент, ЭДО, мемлекеттік порталы, бұлттар).\n- Қолжетімділік саясаттары: қай санаттар рұқсат етіледі және тыйым салынады, AD топтары бойынша қандай ережелер, кестелер керек пе, қонақтар мен BYOD қалай өңделеді.\n- SSL inspection: режим қандай (толық, таңдамалы, тек тәуекел санаттары), міндетті исключения (медицина, банктер, жеке кабинеттер), сертификатты кім шығарады және орнатады, қандай рұқсат етілген кешігулер мен қателер бар (мысалы, видеоқоңыраулар бұзылмауы тиіс).\n- Логирование және есептер: қандай өрістер жазылады (пайдаланушы, топ, URL, санат, әрекет, блоктау себебі), сақтау мерзімі, қолжетімділік және SIEM интеграциясы қажет пе.\n- Қабылдау: тест‑план және «дайын» критерийлері (санаттар тексерісі, AD‑тан пайдаланушыны анықтау, исключения жұмысы, есептер сапасы, жүктеме астындағы тұрақтылық).

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

Мысал сценарий: 400 пайдаланушы және бірнеше филиал үшін SWG

Компанияда 400 қызметкер бар, бас офис пен 6 филиалда жұмыс істейді. Интернет бір арна арқылы ЦОД‑қа шығады, есептік жазбалар мен топтар бір Active Directory‑де. Мақсат — ТЗ‑де филиалдарда «жергілікті исключениялар» болмауы үшін түсінікті қолжетімділік ережелерін жазу және ИБ инциденттерді тез талдай алуы.

Саясаттарды қағаздағы бөлімдер бойынша емес, AD‑топтар арқылы беру ыңғайлы: офис пайдаланушылары (стандартты қолжетімділік және қатты шектеу тәуекел санаттарына), колл‑орталығы (тек CRM, пошта, білім базасы және рұқсат етілген сайттар), ИТ (кеңейтілген қолжетімділік + жүктеулер бақылауда), мердігерлер ("тек қажеті" және уақыт бойынша шектеу). Филиалдарға сол ережелер сақталып, есептер филиал бойынша арнайы көрініс береді.

Осындай сценарийде SSL inspection таңдамалы түрде жиі қолданылады. ТЗ‑де расшифровка тәуекел санаттарына (жаңа домендер, анонимайзерлер, файлобмендер, зиянды/фишинг ресурстары) қосылады, ал сезімтал сервис үшін исключения белгіленеді. Әдеттегідей интернет‑банкинг, мемлекеттік порталдар, медицина ресурстары pinning немесе басқа себептер бойынша расшифровкаға алынбайды. Исключения тізімін кім бекітетінін және қаншалықты жиі қайта қаралатынын көрсетіңіз.

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

Енгізбе алдында қабылдау тексерістерін өткізіп, жұмыс уақытына проблемалар түсірмеңіз:

• Офис пен филиалдардан негізгі бизнес‑сайттарға тест‑қолжетімділік;\n- SSO/аутентификация және AD‑тан топтардың дұрыс анықталуын тексеру;\n- SSL исключениялары қажет мөлшерден үлкен емес екеніне бақылау;\n- Логтарды салыстыру: пайдаланушы, топ, сайт, әрекет, блоктау себебі бар екені;\n- Пиковый уақыттағы жүктеме тесті және кері қайтару жоспары.

ТЗ кейінгі қадамдар: пилот, енгізу және қолдау

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

Пилотты бүкіл компанияға бірден қосу емес, шағын топпен бастау жақсы. Пилотта нақты исключениялар (банктер, мемлекеттік порталдар, ерекше SaaS), SSL нюанстары және есептер талаптары жылдам көрінеді.

Пилотты нәтижелі өткізу жолы

• Әртүрлі бөлімдерден 30–50 пайдаланушы және 1–2 типтік филиал таңдаңыз.\n- Негізгі санаттарды қосыңыз және AD‑топтар бойынша 1–2 саясат қойыңыз.\n- SSL inspection‑ті критикалық сервистер бойынша тексеріп, исключенияны жазбаша рәсімдеңіз.\n- Логтарды салыстырыңыз: пайдаланушы, топ, URL, санат, әрекет, блоктау себебі көрінсін.\n- Нәтижелер бойынша саясаттар мен есептер талаптарын түзетіңіз.

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

Содан кейін қолдау жоспары — категориялар мен сигнатураларды жаңарту жиілігі, инциденттерді қарау тәртібі, исключенияға өтініш беру регламенті, жауап беру уақыты және тұрақты есептер форматы.

Ресурстар немесе тәжірибе жетіспесе, кей жұмыстар жүйелік интеграторға тапсырылуы мүмкін: on‑prem SWG жобалау, серверлер мен қосу сұлбасын таңдау, Active Directory интеграциясы және логирование ұйымдастыру. Мысалы, GSE.kz (gse.kz) — Қазақстанда серверлер мен жүйелер өндіретін және жүйелік интеграция жасай алатын компания ретінде инфрақұрылымды жинап, іске қосқаннан кейін қолдау ұсына алады.