RBI браузерін оқшаулау: қашан фишингті төмендетеді және UX-ке қалай әсер етеді

Неліктен оқыту фишингке үлгере алмайды

Фишинг тек «назарыңды» сынамайды. Ол күнделікті жұмыс әдеттеріне сүйенеді: хатты ашу, сілтемеге өту, таныс сервиске кіру, шотты немесе құжатты жүктеу. Көбінесе шабуыл «вирус» тәрізді көрінбейді — бұл логин мен пароль сұрайтын байқалды веб-бет.

Оқытудағы мәселе — одан әр уақытта мінсіз мінез-құлық күтеді. Шындықта адамдар асығыс жұмыс істейді, тапсырмалар арасында ауысады және хабарламаларға жауап жазады. Тіпті жақсы дайындалған қызметкер те қате жіберуі мүмкін, егер хат сәйкес көрінсе («пароль жаңарту», «құжатқа қол қою», «өтінішті тексеру»), ал сайт визуалды түрде таныс порталды еске түсірсе.

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

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

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

RBI дегенді қарапайым тілмен түсіндіру

RBI (Remote Browser Isolation) — сайт пайдаланушының компьютері емес, бөлек оқшауланған ортада (көбінесе бұлтта немесе ұйымның қорғалған контурында) ашылатын тәсіл. Құрылғыға тек қауіпсіз көрініс жеткізіліп, потенциалды қауіпті веб-код өзі қолданушы жүйесіне жетпейді.

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

Оқшаулаудың мәні — интернеттегі ең қауіпті код (JavaScript, плагиндер, белсенді контент) ОС-қа, шолғышқа және корпоративтік желіге тікелей қол жеткізе алмайды. Егер сайтта эксплойт болса да, ол оқшауланған ортадағы контейнерге «тиіліп» қалады, ал қызметкердің жұмыс станциясына ене алмайды.

RBI ең жақсы қорғайтындар: drive-by downloads және жасырын жүктеулер, браузер мен оның компоненттеріндегі осалдықтарды пайдалану, зиянды скриптер мен жарнама желілерінен енгізілген код, компрометацияланған сайттарға өту — яғни код дереу іске қосылатын жағдайлар.

Шекараны түсіну маңызды. RBI жұқтыру және зиянды ПО-ның бекіну тәуекелін азайтады, бірақ адами факторды жоя алмайды. Қызметкер жалған бетке логин мен пароль енгізсе — бұл деректер деңгейіндегі фишинг. Сондықтан RBI әдетте MFA, сілтемелерді тексеру және түсінікті қолжетімділік саясаты сияқты шаралармен бірге қолданылады.

RBI типтік схемалары және айырмашылықтары

Пайдаланушы үшін RBI әдетте бірдей көрінеді: сайт әдеттегідей ашылады, бірақ белсенді веб-код жұмыс ПК-де емес, оқшауланған ортада орындалады. Шешімдер арасындағы айырмашылықтар көбінесе осы ортаның қай жерде орналасқаны және оқшаулау қашан іске қосылатындығында болады.

Оқшаулау қай жерде жұмыс істейді: бұлт немесе сіздің контур

Бірінші таңдау — қашықтан шолғышты провайдердің бұлтында іске қосу немесе ұйым инфрақұрылымында орналастыру.

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

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

Оқшаулау қашан қосылады: әрқашан немесе шартты түрде

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

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

Қалай қосады: шлюз, кеңейтім немесе портал

Практикада үш тәсіл жиі кездеседі:

• Веб-шлюз немесе прокси арқылы — орталықтандырылған, бақылау және есеп беру үшін ыңғайлы.
• Браузер кеңейтімі арқылы — тез бастау, бірақ орнату мен нұсқаларды басқаруды талап етеді.
• Қорғалған портал арқылы — кейбір сценарийлерді шектеу оңай, бірақ күнделікті жұмыс үрдісіне нашар үйлеседі.

Кепілдіктер көбінесе жылдамдық пен үйлесімділік туралы: енгізу кідірісі, ауыр веб-қосымшалар, файл жүктеу, бірнеше вкладкалармен жұмыс, басып шығару және USB-токендер. Сондықтан схема таңдағанға дейін 5-10 ең маңызды сайтты және бірнеше типтік тапсырманы (кіру, табу, жүктеу, жүктеу серверіне жіберу, басып шығару) нақты жұмыс орындарында тексеру пайдалы.

Қашан RBI фишингті тез азайтады

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

Жылдам эффект көбінесе сыртқы сайттармен көп жұмыс істейтін ұйымдарда көрінеді: мемлекеттік қызметтер, тендер алаңдары, контрагенттер порталдары, мердігер кабинеттері, банктер, бұлттық сервистер. Мұндай ресурс көп болған сайын бір сілтеме немесе баннер қақпан болуы ықтималдығы жоғары.

RBI әсіресе құрылғылар паркін тез реттеуге мүмкіндік жоқ жерде пайдалы. Қызметкерлердің бір бөлігі ескі ПК-де, бір бөлігі жаңа, филиалдар бар, тонкие клиенттер, жеке ноутбуктер мен планшеттер — бәріне бірдей жаңартуларды, кеңейтімдерді, саясаттарды тез енгізу қиын. Ал тәуекел бүгін бар.

Көбінесе RBI-ді бірінші кезекте қарастыру керек болса, келесі белгілер сәйкес келеді:

• Жұмыс талаптары бойынша хаттар мен мессенджерлерден жиі сілтемелерге басу.
• Қызметкерлер сыртқы сайттарға жиі кіреді, оларды сіз бақыламайсыз.
• Браузерлерді жаңарту және баптау уақыт бойынша шашыраңқы немесе бәріне мүмкін емес.
• Ұзақ оқыту бағдарламасысыз жылдам нәтиже керек.

Мысалы, бухгалтер «мердігерден» келген хаттағы «актіні тексеріңіз» деген сілтемені басады. Сілтеме RBI арқылы ашылады — бет жүктеледі, бірақ ол қызметкердің ПК-інде емес, қашықтағы шолғышта орындалады. Тіпті егер бетте эксплойт немесе формаға ауыстыру болса, зиян оқшауланған сессияда қалады және жұмыс ПК-не енбейді.

RBI кімге әсіресе пайдалы: топтар мен сценарийлер

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

Жоғары тәуекелді пайдаланушылар

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

RBI сондай-ақ сыртқы хат алмасу және күтпеген сұраулар көп болатын бөлімдерге пайдалы: қаржы мен бухгалтерия, сатып алу, HR, заң бөлімі, сату және қолдау. Онда шоттар, контрагенттер кабинеттері, формалар, бұлттық құжаттар және жеткізу порталдары жиі ашылады. Тіпті сақ бола жұмысшы кейде "нақты сияқты" көрінген нәрсені ашады.

RBI ең көп пайда беретін сценарийлер

Жылдам әсер келесі типтік жағдайларда байқалады:

• BYOD және қашықтан жұмыс, құрылғылардың бір бөлігі толық бақылауда болмаған кезде.
• Ақша мен деректерге қолжетімді веб-кабинеттер (банк, төлем сервистері, CRM, кадрлар жүйелері).
• Әкімші панельдері мен консольдерге кіру, мұнда сессия ұрлау мен зиянды скриптерден қорғау маңызды.
• Сыртқы порталдармен жұмыс: мемлекеттік қызметтер, тендер алаңдары, жеткізушілер кабинеттдері.
• Пошта мен мессенджерден тез қарап шығу — бәрін жүктеп тексергіңіз келмейтін жағдайлар.

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

RBI басқа қауіпсіздік шараларын қалай толықтырады

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

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

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

DLP және жүктемелер бақылауымен RBI ережелерді қарапайым әрі орындалатын етеді. Вебке толық тыйым салудың орнына қарау рұқсат етіліп, бірақ оқшаулаудан не шығатыны қатаң басқарылуы мүмкін. Әдетте бұл бірнеше қарапайым ережеге келеді: тек сенімді типтегі файлдарды жүктеуге рұқсат беру, күдік тудырған файлдарды қосымша тексеруге жіберу, домендерді және жүктеу әрекеттерін журналға жазу, ал жоғары тәуекелді рөлдер үшін «тек оқу» режимін қосу.

Zero Trust архитектурасында RBI тағы бір тексеру деңгейі ретінде үйлеседі: вебке қолжетімділік контекстке тәуелді (кім, қайдан, қандай құрылғы, қандай тәуекел). Мысалы, бухгалтер SSO арқылы кіреді, және тәуекел жоғарылағанда сыртқы сайттар автоматты түрде оқшаулауда ашылады. Ұйымдар инфрақұрылыммен бірге қорғалған веб-қолжетуді құрып жатқанда (мысалы, интеграциялық жобалар аясында GSE.kz сияқты) RBI жиі жалпы саясаттың бөлігі болады, жеке шолғышқа қосымша емес.

RBI-ді ауыртпалықсыз енгізу қадамдары

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

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

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

Жұмыс жоспары жиі мынадай болады:

• Әр түрлі тапсырмалары бар 2–3 пайдаланушы тобы анықтаңыз (мысалы, бухгалтерия, сатып алу, колл-орталық).
• Жүктеу мен көшіру саясатын орнатыңыз және кімнің ерекшелік бере алатындығын бекітіңіз.
• 2–4 апталық пилот өткізіңіз, тестіленген сайттардың орнына нақты тапсырмаларда тексеріңіз.
• Өндірістік іске қосу кезең-кезеңімен болсын: алдымен жоғары тәуекелді топтар, содан кейін басқалары.
• Қарапайым ерекшелік процесін енгізіңіз: өтініш, мерзім, жауапты адам, себеп.

Пилот типтік әрекеттерге негізделген болғаны дұрыс: поштадағы сілтемені ашу, веб-поштаны пайдалану, шотты жүктеп алу, файлды порталға жүктеу, құжатты басып шығару. Мысалы, мемлекеттік органда жұмыс орындарында (ПК және моноблоктар қоса) жеткізушілерден күн сайын хаттар келеді. Менло сияқты шешімдерді (Menlo Security) немесе ұқсас жүйелерді орнату арқылы сыртқы сілтемелер автоматты түрде оқшаулауға жіберіліп, ішкі порталдар әдеттегідей жұмыс істей алады.

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

UX-ке әсерін қалай тексеруге: метрикалар мен тесттер

RBI енгізгенде UX-ті қауіпсіздік сияқты қатаң тексеру керек. Әйтпесе сіз тек «бәрі баяулады» деген шағымдарды естисіз — сан мен себепсіз. Бастапқыда бір топта 2–4 апталық пилот өткізіп, кейін бақылау тобымен салыстырыңыз.

Пилотқа дейін және кезінде негізгі метрикаларды жинаңыз. RBI үшін ең маңыздысы — уақыт пен тұрақтылық.

Сенімді картинаны беретін метрикалар

Бірдей құрылғылар мен бірдей желіде өлшеңіз:

• Бетті ашу және интерактивтілік уақыты (секундтармен): «басыңыз — енгізіп/басуға болады».
• Сынақ сәтсіздіктерінің жиілігі: рендер қателері, жұмыс істемейтін формалар, файл жүктеу проблемалары.
• Типтік тапсырмалардың орындалу уақыты (минуттар): порталға кіру, өтініш толтыру, төлем, веб-поштада жұмыс.
• Веб-қолжетумен байланысты қолдау сұрауларының саны (күн/апта) және олардың қанша пайызы «өздігінен шешілді».
• Пилот соңындағы қанағаттану бағалауы: 2–3 сұрақ және «не кедергі болды» деген өріс.

Пилотта жүргізілетін тесттер

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

Порогтарды алдын ала белгілеңіз: мысалы, «бет 3 секундтан жоғары ашылмауы керек», «тапсырма бастапқы уақыттың 20%-нан артық ұзармауы тиіс». Егер шектер бұзылса, бұл RBI-дің «сәтсіздігі» емес — сенімді порталдарға ерекшелік қосу, шығу нүктелерін өзгерту немесе саясатты оңтайландыру қажет екендігінің сигналы.

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

RBI-ге шағымдардың негізгі себебі — қауіпсіздік өздігінен емес, әдеттегі әрекеттердің күтпеген түрде бұзылуы. Адамдар жаңа ережелерді қабылдайды, егер олар түсінікті және жұмысты орындай алатын болса.

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

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

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

Бизнеске арналған ерекшеліктер қажет болады: мемлекеттік порталдар, банк кабинеттері, ЭЦҚ/қол қою, басып шығару, видеобайланыс. Қарапайым өтініш формасы мен анық критерийлер арқылы ерекшелік сұрау жолын жасаңыз: бір форма, жауап мерзімі. Пилот тобында басып шығару, қол қою және типтік мемлекеттік сервистерді алдын ала тексеріңіз, әйтпесе алғашқы қолданушылар тек «сапаны тексерушілерге» айналады.

RBI таңдау және баптау кезінде жиі болатын қателіктер

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

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

• Барлық файлдарды шектеп тастау, ерекше жағдайларсыз. Нәтижесінде құжаттар жеке пошта немесе мессенджерлер арқылы жіберіле бастайды — бұл бақылаудағы жүктеуден нашар.
• RBI-ді «бәріне және бәріне» қосу, бизнес-қосымшалардың иелерімен келісусіз. Сосын SSO, сатып алу порталдары, веб-банкинг, CRM, ішкі кадрлық жүйелер бұзылуы мүмкін.
• Филиалдар мен әлсіз арналарды ескермей қалу. Қашықтықтан рендерлеу арқылы кідіріс көп болса, пайдаланушылар «кері оралады» және ескі браузерлерді пайдалануы мүмкін.
• Журналдандыру мен инциденттерді талдау ережелерін орнатпау. Кейін «кім сілтемені ашты» немесе «не блокталды» сияқты қарапайым сұрақтарға жауап беру мүмкін болмай қалады.
• RBI-ді барлық қорғаныс шараларының орнына қою. RBI веб-қатерлерді жақсы кеседі, бірақ MFA, пошта сүзгілері, жаңартулар, EDR және айқын қолжетімділік ережелерін алып тастамайды.

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

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

Егер ИТ бөлімі ел бойынша әртүрлі нысандар үшін жауапты болса, жетістіктің метрикалары туралы келісу маңызды: қауіпті өту санының азаюы және бет ашу уақытының қабылданарлық шегі. Сонда RBI пайдаланушылармен жанжалдаспай тез нәтиже береді.

Қысқаша нақты сценарий: поштадағы фишинг сілтемесі

Бухгалтерге "жеткізушіден" деп келген хат: «Шот жаңартылды, жеке кабинетте тексеріңіз». Хаттағы батырма жалған порталына апарады. Көрінісі бойынша бәрі шынайы: логотип, таныс "Логин" және "Пароль" өрістері, тіпті адрес сенімді көрінеді.

Қызметкер сілтемені басады, ол RBI оқшаулау арқылы ашылады. Бет шынымен жүктеледі, бірақ жұмыс ПК-де емес, оқшауланған ортада орындалады. Егер бетте зиянды скриптер немесе жасырын жүктеулер болса да, олар оқшауланған ортада қалып, құрылғыға енбейді.

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

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

Жылдам чек-лист және келесі қадамдар

Егер фишингпен күресте тез нәтиже керек болса, RBI жиі оқытудан жылдам нәтиже береді. Төменде қайдан бастауға болатыны және UX пен қауіпсіздікті не ұмытпау керектігі көрсетілген.

Бастамас бұрын жылдам тексеру

• Қолдау көрсетілетін пайдаланушылар мен сайттар: сыртқы пошта мен веб-пошта, құжаттар порталдары, жаңа немесе аз танымал домендер, хаттар мен мессенджерлерден жиі келетін нәрселер.
• UX негіздері: бет ашу және кіру уақыты, негізгі веб-қосымшалармен үйлесімділік, басып шығару, жүктеулер, буфер алмасу, көпфакторлы аутентификацияның ыңғайлылығы.
• Практикадағы UX: қанша қосымша басу пайда болды, күнде қанша рет блоктау көрінеді, қанша өтініш қолдауға келді.
• Қауіпсіздік: қандай әрекеттер рұқсат етілген (жүктеу, файлдарды шығару, көшіру), журналдарда не жазылады, оқиғалар қалай сақталады және кім оларды талқылайды.
• Саясаттар мен ерекшеліктер: сенімді ішкі сайттар тізімі, мердігерлер мен қонақ құрылғылар үшін ережелер, SSO, прокси, DLP, EDR, пошта қорғанысымен интеграциялар.

Чек-листтен кейін қарапайым қағидаға келісіңіз: ерекше жағдайлар аз болсын, бірақ пайдаланушылар үшін түсінікті ережелер болсын. Ерекше жағдайлар күрделі болса, айналып өтулер де көбейеді.

Келесі қадамдар

• 2–4 апталық пилотты бір тәуекел тобына іске қосыңыз (қаржы, сатып алу, қызметкерлер хаттарын қабылдаушылар, қолдау).
• Алдын ала табыстың критерийлерін белгілеңіз: қауіпті өту санының азаюы, веб арқылы жұқтырудың төмендеуі, бет жүктеу уақытының қабылданарлық деңгейде болуы, өтініштер санының белгіленген өсуінен көп болмауы.
• Кері байланысты жинаңыз: қысқа сауалнама және RBI-нің көмегі немесе кедергі болған 10–20 нақты жағдайды талдау.
• Нәтижелер бойынша қамтуды рөлдер мен сайттар бойынша кезең-кезеңімен кеңейтіңіз.

Егер шешімді өз контурыңызда развертывать жоспарласаңыз, GSE.kz архитектура таңдауында, интеграцияда, 24/7 қолдау мен өнімділік талаптарына сай жұмыс станцияларымен көмектесе алады.