Шлюзтегі TLS-инспекциясы: жылдамдыққа және аудитке әсері

Неліктен TLS-инспекция жасайды және ол нені өзгертеді

Шлюзтегі TLS-инспекция — HTTPS арқылы шифрланған трафиктің ішіне «қарау» тәсілі: шлюз уақытша қосылымды дешифрлап, қауіпсіздік ережелерін (антивирус, DLP, сайт категориялары, IPS) қолданады, кейін трафикті қайта шифрлап жібереді.

Көбінесе TLS-инспекция корпоративтік интернет шығысы түйісетін жерде қосылады: шлюзте, прокси-серверде немесе NGFW-да. Желі ішінде бұл браузер мен қосымшаларға арналған жеке прокси болуы мүмкін, ал периметрде — барлық пайдаланушылар мен филиалдар үшін бірыңғай бақылау нүктесі.

Қосқаннан кейін әдетте келесі өзгерістер байқалады:

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

TLS-инспекция домен бойынша қарапайыланған сүзгіден өзгеше. Домендік сүзгі көбінесе "қайда" баратынын (SNI/домен, IP, категория, DNS) көреді және адрес деңгейінде блоктайды, бірақ ішіндегі дәл қандай деректер өтіп жатқанын анық көрмейді. Егер зиянды файл рұқсат етілген доменнен жүктеліп жатса немесе трафик бір ортақ бұлтты хостинг арқылы өтсе, домен сүзгісі жеткіліксіз болады.

Алайда TLS-инспекция жаңа тәуекелдер қосады. Біріншіден, кешігулер: әр қосылым қосымша операцияларды талап етеді, және ауыр каналдарда бұл байқалады. Екіншіден, сайттар мен қосымшалардың бұзылуы: кейбір сервистер certificate pinning немесе ерекше протоколдар қолданады және жұмысын тоқтatuы мүмкін. Үшіншіден, сенім мен құпиялылық мәселесі: ұйым трафик мазмұнына қол жеткізеді, сондықтан сезімтал ресурстарға исключениялар, түсінікті ережелер және ашық аудит қажет.

Қандай көрсеткіштер өнімділікке шынымен әсер етеді

TLS-инспекция әдетте жүктеме мен кешігу қосады. Оның айтарлықтай әсері метррикаларға және қай трафик басым екеніне байланысты.

Алғашқы өзгеріс — кешігу (latency). Ол екі себеппен өседі: шлюз клиентпен және сыртқы сайтпен жеке TLS-сессия орнатады, сосын ағынды өңдейді. Пайдаланушы үшін бұл беттің ашылуының баяулауы, қосымшалардың бастапқы жауапының кешігуі немесе кейде авторизацияның баяулауы ретінде көрінеді.

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

Тез анықтау үшін әдетте мыналар қаралады:

• Шлюзтегі CPU (жалпы жүктеме мен шыңдар) және криптооперацияларға кететін үлес.
• Жады (буферлер, кэштер, сигнатурлы анализ қосулы болса ерекше назар).
• Активті TLS-сессиялар және жаңа қосылымдардың жиілігі (connections per second).
• Инспекция қателері: таймауттар, reset, рукопожатие сәтсіздіктері.

Ресурстарды тек дешифрлау ғана «жеп» қоймайды. Дешифрлаудан кейінгі процестер — антивирустық тексеру, DLP ережелері, URL категориялау, файлдар үшін песочница — үлкен үлес қосады. Олар кейбір сұрауларда кешігуді айтарлықтай өсіріп, CPU мен диск қолдануды ұлғайтуы мүмкін. Кейде дәл песочница әсерінен "бәрі жұмыс істейтін еді, бірақ жүктеу күтетін болды" деген жағдай болады.

Трафиктің түрі шешуші. Видео және видеоконференциялар кешігу мен пакет жоғалтуларға сезімтал: аз ғана қосымша кешігу сапаны нашарлатады. ОС жаңартулары мен үлкен дистрибутивтер өткізу қабілетін ауыртатыны үшін инспекцияланатын лимитті «жеп қоюы» мүмкін, нәтижесінде басқа пайдаланушылар зардап шегеді. VDI және қашықтағы жұмыс үстелдері тұрақты кешігулер мен джиттерге тәуелді. Мессенджерлер мен бизнес-қосымшалар рукопожатие ақаулары мен сертификат ауысымына сезімтал болуы мүмкін.

Ұйымның мөлшері мен пиковые сағаттар маңызды, өйткені жүктеме сызықты емес өседі. Таңертең жұмыс күнінің басында жаңа қосылымдар ең көп болады (эл. пошта, мессенджерлер, ашылған қойындылар, жаңартулар). Осы уаһыттағы шыңдарда проблемалар жиі көрінеді: CPU шыңға шығады, TLS орнату уақыты өседі, таймауттар пайда болады. Сондықтан «күн бойындағы орташа» өлшемдер жеткіліксіз — пик пен ең жаман сценарий бойынша өлшеу керек.

Әсерді қалай бағалау: қадамдық өлшеу жоспары

TLS-инспекцияның әсерін бағалау баптаудан гөрі өлшеулерден басталуы тиіс. Әйтпесе қай нәрсе нашарлағанын: арна, шлюз, DNS, сертификаттар немесе нақты сайттар екенін анықтау қиын болады. Негізгі базаны алыңыз, кейін пилот жасаңыз және одан кейін ғана масштабтаңыз.

1) Қосу алдында базалық линияне алыңыз

3–5 жұмыс күні ішінде әдеттегі режимдегі цифрларды жинап, пайдаланушылардың типтік шағымдарын белгілеңіз (беттің баяулауы, кіруге болмайды, қоңырау үзілуде). Мәліметтерді бірдей сағаттарда (мысалы, 10:00–12:00 және 15:00–17:00 пиковые сағаттар) тіркеңіз, әйтпесе салыстыру әділ болмайды.

Әдетте тіркеледі:

• танымал ресурстарға кешігулер (орташа және 95-перцентиль);
• HTTPS бойынша қателер үлесі (таймауттар, рукопожатие сәтсіздіктері);
• шлюзтегі жүктеме (CPU, RAM, сессиялар);
• типтік беттер мен файлдарды жүктеу жылдамдығы;
• видео байланыс сапасы (потеря пакетов, рывки, үзілістер).

2) Тестілеу тобына пилот жасаңыз

Шлюзтегі TLS-инспекция үшін кішкентай және анық бір бөлімді таңдаңыз: бір филиал, бір бөлім немесе 5–10% пайдаланушылар. Осылайша өнімділік шекарасын тезірек түсініп, бүкіл компанияны тоқтатпайсыз.

Тест сценарийлері нақты жұмыс жағдайын қайталауы тиіс: офис сайттары мен бұлт қызметтері, банктер, мемлекеттік ресурстар, почта, видеочаттар. Алдын ала кім не тексеретінін сипаттау пайдалы. Мысалы: бухгалтерия төлемдер жасайды, заңгерлер мемлекеттік порталдарға кіреді, қолдау видеосессиялар өткізеді, қалғандары типтік веб-сервистермен жұмыс істейді.

Қосу кейін сол өлшеулерді дәл сол сағаттарда қайта жасаңыз және «алдындағы/кейінгі» салыстырыңыз. Мән-жайды бөлек белгілеңіз: қандай проблемалар әрқашан пайда болады, қайсысы тек пиковые уақытта көрінеді.

3) Қабылдау критерийлерін алдын ала анықтаңыз

Критерийлерсіз пилот «баяулай бастады» деген дау-дамайға айналады. Бастапқыда қандай кешігулер мен қателерге рұқсат етілетінін келісіңіз.

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

Қай исключениялар әдетте міндетті және неге

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

Жиі исключенияларға банктер мен төлем сервисі домендері, мемлекеттік ресурстар, ЭЦП мен криптопровайдерлер қолданылатын сервисдер, сондай-ақ кейбір комплаенс талаптары бойынша расшифровкаға тыйым салатын жүйелер кіреді. Тағы бір категория — жаңартулар мен маңызды бағдарламалық репозиторийлер, егер олардың инспекцияда тексерілуі қызметті бұзса немесе қабылданбайтын кешігулерге әкелсе.

Техникалық белгілер де бар: ресурс инспекцияны «ұнатпайды». Ең жиі кездесетін себептер — certificate pinning (қосымша нақты сертификатты күту), клиенттік сертификаттар (mTLS) және аппараттық токендер арқылы ЭЦП. Бұл жағдайларда шлюз сенімділік тізбегін өзгертеді, қосымша «дұрыс емес» сертификат көріп немесе өзара аутентификациядан өте алмайды.

Исключение домен бойынша немесе қолданба бойынша болуы мүмкін. Домен бойынша исключение оңай әрі тез, бірақ кең: сол доменге (және көбіне поддомендерге) баратын барлық трафик үшін тексеруді өшіреді. Қолданба бойынша исключение дәлірек, бірақ ұстау қиын: қай трафик осы клиентке, портқа немесе пайдаланушылар тобына жататынын анықтау қажет.

Исключенияларды хаосқа айналғанша болдырмау үшін әрқайсысының «паспорты» болуы тиіс. Міндетті түрде тіркеу керек:

• не исключается (домен, поддомен, қолданба, пайдаланушылар тобы);
• неге (pinning, mTLS, ЭЦП, регулятор талабы, қосқанда болған инцидент);
• кім келісім берген (ИБ, сервистің иесі, қажет болса заң бөлімі);
• тәуекел және өтемдер (мысалы, күшейтілген DNS/URL бақылауы, жұмыс орындарында EDR);
• қайта қарау мерзімі (уақыт көрсеткіші).

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

Банктер мен мемлекеттік ресурстар: критикалық сервистерді бұзбау

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

Банктер: интернет-банкинг, төлемдер, 3-D Secure

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

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

Мемлекеттік ресурс және ЭЦП: қызметтер, кабинеттер, салық қызметтері

Мемлекеттік порталдар мен жеке кабинеттер ЭЦП, криптопровайдер мен локальды сертификат қоймамен тығыз байланысты. Дешифрлау криптопровайдердің іске қосылуын, құжатқа қол қоюды, сертификат тізбегін тексеруді бұзуы немесе авторизация процесін тоқтатуы мүмкін.

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

Қызметтердің бұзылмауын тез тексеру үшін қысқа тест тізімін қолданыңыз және оны өзгеріс алдында және кейін іске қосыңыз:

• 1–2 негізгі банкке кіру, есепшотты қарау, төлем жасау және оны растау;
• төлем беті немесе 3-D Secure растамасын тексеру (қолданылса);
• негізгі мемлекеттік порталға кіру, жеке кабинетті ашу;
• ЭЦП әрекеті: тесттық құжатқа қол қою немесе форманы жіберу;
• тесттерді әртүрлі ортада қайталау: браузер, жұқа клиент, ВКС/VDI (бар болса).

Аудит талаптарын орындау қажет болса, исключенияларды адрес бойынша жасаңыз: домендер/категориялар және пайдаланушылар топтары — және бұл саясатты және өзгерістер журналына тіркеңіз. Осылай аудиторға неге кей трафик дешифрланбайтынын түсіндіру оңай болады әрі төлемдер мен ЭЦП жұмысын сақтайсыз.

TLS-инспекция саясатты қалай баптау: тосынсыйларсыз

TLS-инспекция қосқанда көп "тосынсый" техникалық емес, саясаттан шығады. Егер саясат түсініксіз исключениялар, түпкі сертификат иесі және откат жоспарысыз құрылған болса, бизнес-сервистер бірінші зардап шегеді: банктер, мемлекеттік порталдар, ЭДО, клиент-банктер және ПО жаңартулары.

1) Сенімді сертификат: кім және қалай басқарады

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

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

2) Пайдаланушылар мен сценарийлерге бөлу

Барлығына бірдей саясат көбіне проблемалар әкеледі. Ең болмағанда үш топқа бөлуге кеңес беріледі: офис ПК-лары, қашықтағы пайдаланушылар (VPN/VDI), әкімшілер мен сервис есептері. Әкімшілерде басқару панелдеріне, репозиторияларға және бұлтқа қолжетімділік көп, сондықтан олардың ортақ инспекциясы SSO немесе MFA-ны бұзуы мүмкін. Қашықтағы пайдаланушыларға пилот кезеңінде жұмсақырақ режим керек болады.

Әрі қарай категориялар бойынша айқын саясат қойыңыз: қандай трафик инспекцияланады, қандайсы (банктер, мемлекеттік ресурстар, төлем шлюздері, mTLS) дешифрланбайды, қандай блокталады, қайсысы бақылауда (расшифровкасыз логтау) болады.

3) Қателер және қолдау: пайдаланушы не көреді

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

4) Нағыз жұмыс істейтін откат жоспары

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

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

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

Аудит және бақылау: журналдандыруды және тексеруді қалай ұйымдастыру

Шлюзтегі TLS-инспекция кезінде маңыздысы — жұмысы "бар/жоқ" емес, neге осындай шешім қабылданғанын көрсету. Жеткілікті логтарсыз саясатты ұстанғаныңызды дәлелдеу және шағымның себепін тез табу қиын.

Логта не жазу керек

Әр сессия бойынша былайша көрінуі керек: трафик расшифрланды ма, сол күйінде жіберілді ме немесе блокталды ма. Әдетте жеткілікті түрде:

• саясат шешімі (inspect, bypass, block) және қай ереже іске қосылғаны;
• категория немесе себеп (мысалы, «қаржы», «мемресурс», «сертификат сенімсіз»);
• TLS қателері (атау сәйкессіздігі, ескі нұсқалар, сертификат тізбегі мәселелері);
• исключениялардың іске қосылуы (қай исключение және қандай белгілер бойынша);
• тергеу үшін техникалық параметрлер: уақыт, көз, тағайындау, SNI немесе домен.

Дешифрланған мазмұнды "артықтап" логтау пайдалы емес — бұл қауіптер мен сақтау көлемін күрт арттырады. Көбінесе метадеректер мен саясат шешімі жеткілікті.

Сақтау, қолжетімділік және «кім жауапты»

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

Жақсы модель — оқу құқығы ИБ-да, шектеулі түрде желі командасынан, және лог шығару сұраныстары қауіпсіздік жауаптысының арқылы жүзеге асады. Егер тәулік бойы қолдау болса (интегратордан қоса), қай лог үзінділері берілетінін алдын ала келісіңіз, артық ақпарат ашпаңыз.

Тикеттер бойынша тексеру және исключенияларды қайта қарау

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

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

Басқарма үшін қысқа есеп пайдалы: инспекциядан өткен трафик пайызы, bypass пайызы, bypass себептері, TLS бойынша шағымдар саны және орташа шешу уақыты, осы кезеңде қосылған/алып тасталған исключениялар және 2–3 түйінді қорытынды.

TLS-инспекцияны енгізуде жиі кездесетін қателер

Көп мәселе технологиядан гөрі оны қалай енгізетіндіктен пайда болады. Шлюзтегі TLS-инспекция жылдамдық пен пайдаланушылар сеніміне әсер етеді, сондықтан қателер тез байқалады: төлемдердің бұзылуы, порталдардың істемеуі, баяу интернет туралы шағымдар.

Өндірісті жиі бұзатын қателер

1. Исключенияларды тым кең қояды. Егер bypass-қа бүкіл категория немесе домен маскасы түссе, инспекцияның мәні жоғалады. Жеке исключениялардан бастаңыз және оларды жүйелі түрде қайта қараңыз.

2. Барлығына бірден қосады, пилот пен базалық линиясынсыз. Қосу алдында кешігулерді, өткізу қабілетін және TLS қателер санын өлшемесеңіз кейінгі талдауды дәлелдеу қиын.

3. Сертификаттарды басқаруды дайын тұтпайды. Түпкі сертификат мерзімін, корневой сертификатты жұмыс станцияларға тарауды және техподдержка нұсқауларын ұмытады. Нәтижесінде браузердегі ескертулер мен шағымдар көбейеді.

4. Мобильді құрылғылар мен қашықтағы пайдаланушыларды елемейді. Телефондар мен планшеттерде сертификатты орнату күрделі болуы мүмкін. Қашықтағы жұмысшыларда VPN, split-tunnel және әртүрлі DNS себебінен ережелер офиске ұқсас жұмыс істемеуі мүмкін.

5. Критикалық бизнес-сервистерді алдын ала тексермейді. Ең жиі зақымданатындар — банктер, мемқызметтер, EDI, SSO, ішкі порталдар және certificate pinning қолданатын қосымшалар. Бірнеше жүйені өткізіп жіберу сатып алуларды немесе төлемдерді тоқтатуы мүмкін.

Практикалық мысал: Қазақстандағы бір ұйым бухгалтерияға инспекцияны бір күнде қосып жіберген. Бір сағаттың ішінде интернет-банктегі төлемдер өтпей қалды және мемлекеттік сатып алу порталына кіру қателері басталды. Себеп — қажетті домендер үшін исключения жасалмады, және банк қатаң certificate pinning қолданды.

Қалай сақтануға: қарапайым қадамдар

Қауіпті төмендететін қысқа іс-әрекет жоспары:

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

Осы элементтер жасалса, HTTPS-инспекция саясатын баптау әдетте тыныш өтеді: исключениялар басқарылатын болады, ал пайдаланушыларға әсері болжауға болатын болады.

Өндірістен бұрынғы тез тексеру тізімі

Шлюзтегі TLS-инспекцияны жұмыс желісінде қоспас бұрын «қалыпты» не екенін келісіңіз. Базалық өлшеулер мен қабылдау критерийлері болмаған жағдайда көзқарастарға емес фактілерге таласу қауіпі бар.

Қосу алдында "до" өлшеулері мен "после" үшін қарапайым шекті көрсеткіштер болсын. Әдетте қаралады: HTTPS-сессияны орнату уақыты (рукопожатие), TLS қателер пайызы, шлюзтің CPU/жад жүктемесі және пиктегі өткізу қабілеті. Қабылдау критерийлері қарапайым болуы тиіс: мысалы, "пиктік уақытта кешігудің X%дан артуына рұқсат жоқ" және "10 000 сессияда TLS қателері Y-дан аспауы".

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

Өндірістен бұрын хабарламалар мен қолдау маршруты дайын болу керек. Пайдаланушылар сертификат қателерін немесе "сайт ашылмайды" көрген жағдайда бірінші сынып қолдауда не сұрау керектігі, нені тексеру, қайда эскалировать және қандай деректер жинау (уақыт, URL/домен, құрылғы түрі, желі, қате скрин) анық болу керек.

Логтар мен аудит қосылған және тексерілетін болуы тиіс. Журналдардан "не расшифрланды/блокталды", "қандай саясат іске қосылды", "TLS-сессиясының нәтижесі қандай" және "қандай исключения қолданылды" деген сұрақтарға жауап беруге жеткілікті болуын қамтамасыз етіңіз. Алғашқы апталарда журналдарды кестелі түрде қарап тұруды келісіңіз.

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

Қысқаша, өндіріске дейін бес нәрсені тексеріңіз:

• "до" өлшеулері және кешігулер, қателер және жүктеме бойынша қабылдау критерийлері бар.
• Исключениялар анықталған (банктер мен мемресурстарды қоса) және олардың иелері тағайындалған.
• Хабарландырулар мен қолдау және эскалация схемасы дайын.
• Логтар қосылған және журналдарды регуларлы тексеру қамтамасыз етілген.
• Откат жоспары, резервтік сценарий және өзгерістер терезесі келісілген.

Мысал: банктер мен мемресурстар бар ұйымдағы TLS-инспекция пилоты

Ұйым: бас кеңсе және 8 филиал, жалпы 1200 қызметкер. Күн сайын мемлекеттік қызметтер (сатып алулар, ЭЦП-порталдар, салық сервисі) пайдаланылады, жалақы жобасы мен төлемдер бір банк арқылы өтеді. Желідегі веб-фильтрация бар, бірақ HTTPS дешифрланбаса кейбір қауіптер мен қажетсіз категориялар көрінбейді.

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

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

Мәселелер тез пайда болды. Кей банктік беттерде кіру қателері және сессия үзілулері болды (certificate pinning пен қатал тексерістер салдарынан). Кей мемлекеттік ресурстарда ЭЦП арқылы авторизация өтпей қалды: браузер "сенімсіз сертификат" көрсетті немесе сервис тексерісте ілініп қалды.

Нәтижелер қысқа есепке енгізіліп, келесі түзетулер жасалды:

• Төлемдегі банктер мен төлем шлюздері үшін домендік исключениялар қосылды (pinning бұзатын ресурстар).
• Негізгі мемлекеттік домендер мен ЭЦП сервисін исключенияға шығарып, жұмыс станцияларында қажетті түпкі сертификаттарды жаңартты.
• Политиканы топтар бойынша бөлді: "офис пайдаланушылары" инспекциямен және "критикалық рөлдер" кей домендер үшін инспекциясыз.
• Ондай жерлерде расшифровка түрлерін шектеді, ауыр жаңартуларды тексермеу сияқты, жүктемені азайту үшін.

Келесі қадам — кем дегенде 70–80% қолданушыларды қамту жоспарында таңдалған жабдықтың шыдамына баға беру. Егер өлшеулер CPU/SSL операцияларына немесе жадқа қарай шоғырланса, интеграторға жүгініп, нақты өнімділікке сай инфрақұрылымды таңдау керек. Қазақстанда мұндай жобалар жиі GSE.kz (gse.kz) сияқты интеграторлармен бірге жүреді, егер саясаттан бөлек платформа таңдау және одан әрі қолдау керек болса.