EDR/XDR лицензиялау: per endpoint пе, per server ме және серверлерді қалай есептеу керек

Лицензиялау моделін таңдаудағы проблема

Айырмашылықтар қарапайым жерден басталады: әр вендор EDR/XDR өнімдерін әрқалай есептейді, ал модельдердің атаулары ұқсас естілсе де мәні әртүрлі болуы мүмкін. Бір жерде лицензия пайдаланушы құрылғысына (ноутбук, ПК) байланған, басқа жерде сервер ретінде бөлек саналады, ал тағы бір жерде рөлге немесе функцияға (мысалы, пошта, файлдар, резервтік көшірме) байланыстырылады. Нәтижесінде «бірлік» бағасы бірдей екі ұсыныс жалпы сомамен мүлде әртүрлі болуы мүмкін.

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

Әдетте IT және сатып алу кезеңінде бірнеше негізгі сұраққа тоқталады: бірлік деген не — құрылғы, ОС, виртуалдық машина немесе физикалық хост па? Жұмыс станциялары мен серверлерге баға мен функционал бірдей ме? Терминалдық серверлер мен VDI қалай есептеледі? Пошталық пен файлдық серверлер жалпы лицензияға кіреді ме немесе бөлек модуль керек пе? Уақытша машиналар, тест қорлары және мезгілдік жүктемелер қалай есептеледі?

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

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

Қарапайым мысал: ұйымда 200 ПК және 8 сервер бар делік. Егер per endpoint таңдап, сервер рөлдерін нақтыламасаңыз, бір сәтте пошта серверіне бөлек лицензия қажет екені анықталуы мүмкін. Ал per server модельді таңдасаңыз, бірақ кейбір қызметтер ондаған виртуалдық машиналарда жұмыс істесе, есеп бірнеше есе өседі. Сондықтан бірінші кезекте есептеу ережелерін анықтап, кейін бағаны салыстыру ұсынылады.

Негізгі терминдер: endpoint, server және «бірлік» не

EDR/XDR жүйелерінде жиі баға емес, не есептелетіні туралы дау болады. Біреулер құрылғыларды, басқалары агент орнатылған орынды, үшіншілер рөлдерді «бірлік» деп есептейді.

Endpoint әдетте пайдаланушының жұмыс құрылғысын білдіреді: ПК мен ноутбуктер, сирек жағдайда тонкие клиенттер. Кейде мобильді құрылғылар да қосылады (егер шешімде iOS/Android модулі болса), бірақ бұл жалпы ереже емес. Endpoint-тың негізгі сипаты: құрылғыда адам жұмыс істейді және типтік тәуекелдер пошта, браузер мен құжаттардан туындайды.

Сервер — басқаға қызмет көрсететін жүйе: файл ресурстары, пошта, дерекқорлар, қосымшалар, домен, виртуализация. Лицензиялау тұрғысынан сервер әр вендорда әртүрлі болуы мүмкін: физикалық сервер, виртуалдық машина (VM), виртуализация хосты (Hyper-V/VMware және т.б.) немесе тіпті нақты серверлік рөл, егер баға осылай құрылса.

Бір хостты әртүрлі вендорлар неге әрқалай санайды? Себебі «бірлік» өнімнің техникалық деңгейде қалай орналастырылатынына және қорғанысты қалай өлшейтініне байланысты. Егер агент әр OS-қа орнатылса, ОС (endpoint/VM) бойынша есептеу логикалық. Егер қорғаныс түйін деңгейінде жұмыс істесе, хост бойынша есептеуі мүмкін. Кейде серверлік лицензия қымбаттау болады — себебі серверде жүктеме жоғары әрі қателіктің салдары қымбатырақ.

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

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

Per endpoint пен per server модельдері нені өзгертеді

Лицензиялау моделі тек бағаға ғана әсер етпейді, ол қамтуды есептеу, тәуекелдерді басқару және аудиттен өту тәсілдеріне де әсер етеді.

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

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

Модель таңдарда былайша сұраңыз:

• қашан және қандай әрекеттер қолжетімді (оқшаулау, процесті аяқтау, карантин, rollback);
• телеметрия қалай және қанша уақыт сақталады;
• критикалық серверлер үшін «үнсіз» мониторинг қолдай ма;
• автоматты ережелер мен жауап сценарийлері бар ма;
• терминалдық ортада және жалпы серверлерде «бірлік» қалай есептеледі.

SOC немесе 24/7 мониторингтің болуы да приоритеттерді өзгертеді. Егер оқиғалар шын мәнінде тәулік бойы қаралса, серверлік телеметрияның молдығы маңыздырақ. Мониторинг болмаса, endpoint-тар үшін түсінікті есептер мен сақтық автоматтары маңыздырақ.

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

Мысал: 300 жұмыс орны және 20 сервер болғанда per endpoint кең қамтуды арзанырақ қамтамасыз етуі мүмкін, бірақ егер серверлерге кеңейтілген көрініс пен қатаң есеп талап етілсе, per server тиімдірек болуы ықтимал.

Почта және файл серверлеріне бөлек лицензия қажет пе

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

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

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

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

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

Ерекше жағдайлар: рөлдер, виртуализация, терминалдық орта

Шынайы желіде «бір сервер — бір тапсырма» сирек кездеседі. Рөлдер, виртуализация және терминалдық орта есептеуде қателікке әкелуі мүмкін.

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

Терминалдық серверлер мен VDI-де қателік «пайдаланушылар тығыздығы» себебінен туындайды. Бір RDS-серверде ондаған немесе жүздеген қызметкерлер жұмыс істей алады, және бір зиянды белсенділік тез үлкен инцидентке айналуы мүмкін. Лицензиялау сервер ретінде, әр VDI-VM/образ бойынша немесе пайдаланушылар/сессиялар саны бойынша болуы мүмкін — өндірушінің ережесіне байланысты.

Non-persistent VDI жағдайында ротация есептеуін алдын ала нақтылаңыз: бір мезетте белсенді VM-дер бойынша ма, пул бойынша ма, әлде белгілі бір кезеңдегі жасалған VM саны бойынша ма. Бұл маңызды, әйтпесе ай ішінде күтпеген лицензиялық шығындар пайда болуы ықтимал.

Виртуализация мен бұлтта негізгі сұрақ — VM-ге бе әлде физикалық хостқа бе байлау. Классикалық модельде әр VM есептеледі, өйткені агент қонақ ОС ішіне орнатылады. Бірақ дата-центрлер үшін кейде хост бойынша (сокет/ядро бойынша) есептеу немесе бір хосттағы барлық VM-дарды қамту құқығы ұсынылады. Егер VM-дерді жиі көшіру болса, хосттар арасында көшу кезінде құқықтар қалай сақталатынын нақтылаңыз.

Кластерлер мен шыдамдылық (HA) да тосынсыну әкелуі мүмкін. «Салқын» standby, яғни шынымен өшірулі тұрған және тек апат кезінде қосылатын түйін, кейде бөлек лицензия талап етпейді, бірақ бұл әмбебап ереже емес. Егер түйін белсенді, балансқа қатысса немесе репликаны ұстаса — оны әдеттегі сервер ретінде лицензиялау керек. «Салқын» түйінге техникалық қолдау және жаңартулар тұрғысынан қалай қаралатынын да нақтылаңыз.

Сатып алудан бұрын мына сұрақтарды жазбаша растаңыз:

• бірлік ОС (физикалық/виртуалдық) бойынша есептеледі ме әлде виртуализация хосты бойынша ма;
• VM-ді хосттар арасында көшіру кезінде лицензия не болады;
• VDI мен терминалдық орталар қалай есептеледі;
• пассивті кластер түйіндері мен standby-серверлерге лицензия қажет пе;
• бір агент болған жағдайда белгілі рөлдер үшін бөлек ақылы модульдер бар ма.

Лицензиялау моделін қалай таңдау: қадамдық тәсіл

Per endpoint пен per server арасындағы таңдау көбінесе «қағаздағы» арзандықта емес, жұмыс орындары, сервер рөлдері және реагирование қалай ұйымдастырылғанында шешіледі.

Практикалық жұмыс тәртібі келесідей.

Біріншіден, инвентаризация жасаңыз: пайдаланушы ПК мен ноутбуктар, жеке серверлер, виртуалдық машиналар, терминалдық хосттар. Тек санын емес, ОС түрі мен критикалық деңгейін де жазып алыңыз.

Содан кейін серверлерді тағайындауы бойынша бөліңіз: инфраструктуралық (AD, DNS, DHCP), пошта, файлдар, дерекқорлар, қосымшалар, VDI/RDS. Әр роль үшін есептеу ережелері әртүрлі болуы мүмкін.

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

Одан кейін тергеу талаптарын салыстырыңыз: кім инциденттерге жауап береді, журналдар мен сақтау мерзімдері қандай, қандай интеграциялар міндетті (SIEM, тикет жүйесі, SOC). Осыдан базалық EDR жеткілікті ме әлде корреляциялы XDR қажет пе анықталады.

Және тек содан кейін жеткізушіден сіздің схеманы ескере отырып нақты есептеме сұраңыз: не endpoint, не server саналады, VM, кластерлер, резервтік түйіндер және тест орта қалай есептеледі.

Егер сіз интегратор арқылы сатып алатын болсаңыз, екі нұсқада есептеме сұраңыз (per endpoint және per server) — осылай сіз қайсысы «арзан» екенін, бірақ қажетті функциялар кірмегенін бірден көре аласыз.

EDR/XDR лицензиялау кезінде жиі кездесетін қателер

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

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

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

Тағы бір жиі сценарий: минималды редакция сатып аламыз, кейін қажет функционал тапшы болады — телеметрия жеткіліксіз, ретеншн жоқ, автоматика аз, SIEM/SOAR интеграциясы жоқ. Формальды түрде лицензия бар, бірақ тергеу мен реагирование тапсырмалары шешілмейді.

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

Тағы қысқа чек-лист сатып алудан бұрын

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

Жауаптарды жинап, бір файлға бекітіңіз (кесте жарайды). Бұл файлды сұранысқа қоссаңыз, сізге бірдей әдіспен және тосынсыйсыз есеп береді.

• Қазір қанша жұмыс құрылғысы мен сервер бар және алдағы 3–6 айда не қосылады.
• Қандай «ерекше» серверлер бар: пошта, файл, терминалдық, домен контроллері, қосымша серверлері.
• Қай жерде критикалық деректер орналасқан және шабуыл болған жағдайда қай түйіндер бірінші қорғалуы тиіс.
• Инциденттерге кім жауап береді: сіздің ИБ/IT командасы немесе 24/7 мониторинг керек пе.
• Есептеу ережелері жазбаша бекітілген бе: endpoint пен server анықтамалары, VM есептеу ережелері, аппарат ауыстырғанда лицензияны аудару, почта мен файлдарға бөлек лицензиялар/модульдер қажет пе.

Кішкене мысал: 120 жұмыс орны және 15 сервер, олардың ішінде 1 пошта, 2 файлдық, 2 терминалдық, қалғаны инфрақұрылым мен қосымшалар. Егер per endpoint алынса және терминалдық орта қалай есептелетінін нақтыламаса, лицензия жетіспеуі немесе артық төлеу болуы мүмкін. Сұраныс есептемесін сіздің түйіндер тізіміңізге байлансын деңіз.

Мысал сценарий: типтік ұйымға лицензия қалай есептеледі

Компанияда 250 қызметкер бар делік. Жұмыс орындары, бірнеше физикалық сервер мен виртуалды орта бар. Мақсат — тәуекелді жабатын әрі артық сатып алудан сақтайтын лицензия есептеу.

1-қадам. Не қорғау керек екенін анықтау

Алдымен нақты инвентарьды бекітіңіз:

• 230 қызметкер ПК/ноутбуктары;
• 8 физикалық сервер (гипервизорлар, файлдық, домен рөлдері, қосымшалар);
• 20 виртуалдық машина (оның ішінде пошта мен сервислер);
• пошта: on-prem сервер ме әлде бұлт қызметі ме;
• жалпы файл ресурстары (SMB-шары).

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

A-нұсқа. Per endpoint моделі

Агент орнатылған барлық соңғы нүктелерді санаймыз: 230 жұмыс құрылғысы + 8 физикалық сервер + 20 VM = 258 лицензия per endpoint. Әдетте 5–10% өсім үшін резерв қосады.

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

B-нұсқа. Per server моделі

Бұл жерде логика өзгеше: жұмыс ПК бөлек лицензияланады (немесе басқа пакетпен), ал сервер бөлігін «серверлер бойынша» есептеу болады. Мысалы, 8 физикалық сервер + 20 VM = 28 лицензия per server.

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

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

Внедрению дейінгі келесі қадамдар

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

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

Талаптарды қарапайым сөйлемдермен жазыңыз: «файл серверінде шифрлаушыны анықтау», «поштаның күдікті кірулерін көру», «карантин және хостты қашықтан оқшаулау қажет». Осылай EDR жеткілікті ме әлде кеңірек XDR керек пе анықтау жеңілдейді.

2–3 нұсқаны бірдей активтер жиынтығында салыстырыңыз: per endpoint, per server, аралас модель және өсімге резерв (5–10% жылдық). Сол уақытта орналастыру инфраструктурасын ойластырыңыз: басқару консоль қайда, логтарды сақтау талаптары, әкімшілерге қолжетімділік қалай ұйымдастырылады.

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