SIEM лицензияларының құнын есептеу: EPS, күндік GB және сақтау

Неліктен алдын ала EPS, күндік GB және сақтау көлемін есептеу керек

SIEM әдетте күткендегіден тез өседі. Бүгін бәрі жұмыс істейді, өйткені барлық көздер қосылмаған, барлық корреляция ережелері іске қосылмаған және кейбір журналдар әлі жіберілмеген. 3–6 айдан кейін жаңа жүйелер қосылады, аудит көбірек дерек сұрайды, ИБ командасы егжей-тегжейлі оқиғаларды қосады, және сіз кенеттен лимиттерге соғасыз.

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

Көбінесе кездесетін шектеулер:

• EPS (секундтағы оқиғалар), кейде орташа мен шыңдық бөлек есептеледі
• GB/суткі (қабылданатын немесе индексалатын логтардың көлемі)
• сақтау көлемі мен мерзімі (горячее және архив)
• көздердің саны (хосттар, агенттер, коннекторлар)
• қолжетімді функциялар (корреляция, UEBA, SOAR, ретеншн деңгейлері)

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

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

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

Қарапайым ереже: егер жаңа көздер қосу немесе аудитті кеңейту жоспары болса, EPS, күндік GB және сақтау мерзімдерін өсу есебімен қарастырыңыз, тек қазіргі жағдайға сүйенбеңіз.

Терминдер: EPS, күндік GB және сақтау деңгейлері қарапайым тілмен

Ұсыныстарды салыстыру және бірнеше айдан кейін шектеулерге соғылмау үшін алдымен терминдерде келісіңіз. Әр түрлі шешімдер бірдей нәрсені әрқалай есептеуі мүмкін.

EPS: бұл не және неге көрсеткіштер «салмақсыз» өзгеруі мүмкін

EPS (events per second) — SIEM қабылдап және өңдейтін секундына оқиғалар саны. Оқиға әрқашан «бір лог жолы» дегенді білдірмейді. Бір шешімде оқиға кез келген алынған жазба саналғанымен, басқаларында — парсингтен өткен жазба, ал басқа жүйелерде тек сүзгіден өтіп индекске түскендер есептеледі.

Ең соңғы EPS-ке мына жайттар қатты әсер етеді:

• не есептеледі: шикі лог па, нормализованған немесе «обогащенный» жазба ма
• дубльдер, қайта жіберулер және retry қалай есепке алынады
• агрегация бар ма (ұқсас бірнеше лог бір оқиғаға айналады)
• кіріс жағында терең нормализация және корреляция қосылған ба

GB/суткі: шикі деректер мен «дайын өнім»

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

Сақтау деңгейлері: горячее, теплое, архив

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

Мерзімдер реттеуші талаптар мен ішкі саясатпен анықталады (мысалы, 30 күн горячем және 1 жыл архивте).

Орташа және пиктер: қайсысын есепке алу керек

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

Есептеуге қажетті бастапқы деректер

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

1. Лог көздерінің толық тізімін және олардың рөлін жасаңыз. Кейде прокси, DNS, пошталық шлюздер, бұлттық журналдар, бизнес-қосымшалардың логтары сияқты «кішігірім» көздер ұмытылады және кейін лимитті жейді. Негізгі жиынтыққа AD/LDAP, VPN, EDR/антивирус, фаерволдар, Windows/Linux серверлері, желілік жабдық, дерекқорлар және маңызды қосымшалар кіреді.

2. Логтардың нақты көлемін өлшеуге сүйеніңіз, «жаңылыс» емес. Практикалық минимум — 7–14 күндік таңдау, будни мен демалысты бөлек қарау. Әр көз үшін орташа EPS және GB/суткі көрсеткіштерін алу пайдалы (дискідегі дерек немесе ағымдағы лог жүйесінен). Осылайша мысалы VPN түнде тыныш, ал EDR тұрақты ағым береді дегені көрінеді.

3. Маусымдылық пен пиктерді бөлек белгілеңіз. Олар көбіне шабуылдармен емес, күнделікті өмірмен байланысты: патч-терезелер, жоспарлы аудит, айдың жабылуы, миграциялар, оқыту. Пик күндерді бөлек сақтап, оларды орташаға «араластырудан» сақтаныңыз.

4. 6–12 айға жоспарларды тіркеңіз: жаңа филиалдар, қосымша жүйелерді қосу, бұлтқа көшу, EDR енгізу, периметрді кеңейту. Бұл жүктемені күтіп тұрғаннан қатты өзгертеді. Мысалы, 500 жұмыс орнын қосу AD пен EDR оқиғаларын айтарлықтай көбейтуі мүмкін.

EPS-ті бағалау: негізгі есеп және пиктерді ескеру

Лицензия және инфрақұрылым үшін әдетте екі көрсеткіш маңызды: орташа EPS (жүйенің күнделікті өмірі) және шыңдық EPS (піктік жүктемелердегі мінез-құлқы).

Көздер бойынша базалық есептен бастаңыз. Егер көз EPS бермесе, кезеңдегі оқиғалар санын секундарға бөліп алыңыз. Мысалы, күніне 8 640 000 оқиға = 8 640 000 / 86 400 = 100 EPS.

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

Практикалық логика:

• көздердің кестесін жасаңыз: орташа және пиктік EPS
• орташа мәндерді қосып baseline алыңыз
• пиктерді қосып worst case алыңыз
• запас қосыңыз: +20–30% өсім үшін және пиктер үшін бөлек запас (көбіне baseline-тің 1,5–2x, немесе worst case негізінде)
• лицензия қалай есептелетінін нақтылаңыз: орташа бойынша ма, пик бойынша ма, сатылармен пе, әлде секундына қатты лимит бар ма

Қысқа мысал: орташа 60 EPS (AD, EDR, firewall, серверлер), бірақ күнде 10 минут бойы сканерлеуден 250 EPS келеді. Қабылдау сыйымдылығы 250 EPS пен өсім запасын көтере алуы керек, әйтпесе лицензиялық лимит немесе оқиға жоғалту мәселесі пайда болады.

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

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

GB/суткі-ні бағалау: не есептеу керек және қалай қателеспеу

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

Кем дегенде 7–14 күнге өлшемге сүйеніңіз. Егер SIEM әлі енгізілмеген болса, коллекторлардан, syslog серверлерінен, EDR консольдерінен, бұлттық журналдардан деректер алыңыз.

Әр негізгі көз үшін тіркеңіз:

• GB/суткі көлемі (шикі экспорт немесе ағымдағы шығару)
• оқиғалар саны және оқиғаның орташа өлшемі (мүмкін болса)
• «шулы» журналдардың үлесі (DNS, прокси, NetFlow, firewall allow)
• қосылған егжей-тегжей деңгейі (debug, audit, verbose)
• көлемнің кенет өсу кезеңдері (жаңартулар, сканерлер, есептер)

Кіріс пен SIEM ішіндегі көлем жиі өзгеше болады. Парсинг, нормализация және обогащение (өрістер, тегтер, гео, анықтамалар) оқиғаларды ауырлатуы мүмкін. Кейде керісінше — артықшалықтар тасталады. Сондықтан пилотта тексерілетін коэффициент қойып қойсаңыз жақсы: мысалы, белсенді обогащение жоспарласаңыз +20–50%.

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

Фильтрация мен агрегация мәнді жоғалтпай жүзеге асырылса тиімді:

• корреляцияларға қандай оқиғалар қатысады
• тергеуге не қажет (міндетті өрістер жиынтығы)
• қай логтар тек есептер үшін керек
• қай көздерді таңдаулы жазбаға немесе семплингке ауыстыруға болады

Осылай адал GB/суткі шығады, ал сатып алуда жақсы көрінген сан алты айдан кейін сынбайды.

Сақтауды жоспарлау: мерзімдер, деңгейлер және сыйымдылықтың қарапайым есебі

Сақтау — бюджет жиі шынымен сәйкес келмейтін орын. Мұнда қанша күн қандай жылдамдықта қолжетімді болуы керек және не артық сақтау екенін алу маңызды.

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

Содан кейін журналдарды деңгейлерге бөліңіз:

• горячее (hot): тез іздеу мен корреляциялар үшін, әдетте қысқа мерзім және қымбат
• теплое (warm): іздеу мүмкін, бірақ баяу; негізгі тарих осы жерде болуы мүмкін
• архив (cold): тек тексерулерге және сирек сұрауларға; қолжетімділік шектеулі немесе экспорт арқылы

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

Емкость = GB_сутки x Дни_хранения x Кзапаса

Кзапас өсім мен күтпеген көздер үшін бөлек қойылуы керек. Практикада 1.2–1.5 аралығында алады, егер нақты болжам болмаса.

Бірақ нақты диск қажеттілігі тек GB/суткі-ге тәуелді емес. Көбіне ұмытып кететін үш фактор бар:

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

Мысал: 120 GB/суткі. Талап: hot 14 күн, warm 90 күн, архив 365 күн. Қабаттар бойынша: 120 x 14 = 1680 GB (hot), 120 x 90 = 10800 GB (warm), 120 x 365 = 43800 GB (архив). Барлығы 56300 GB, сосын запас (мысалы 1.3) және индексация мен репликация әсерін қосасыз.

Қадамдық есептеу әдістемесі (вендорға байланбаған)

Логика қарапайым: алдымен нақты жүктемені (EPS және GB/суткі) есептейсіз, содан кейін запас қосасыз, және тек соған қарай нақты вендор моделіне аударасыз.

1. Лог көздерін және 3–6 айдағы өзгерістерді жинаңыз. Қандай филиалдар, сенсорлар, аудит қосылатынын белгілеңіз.

2. EPS пен GB/суткі-ні нақты деректер бойынша өлшеңіз. Егер SIEM жоқ болса, коллекторлардан немесе ағымдағы лог жүйесінен алыңыз. Пиктерді бөлек көрсетіңіз.

3. Запас коэффициенттерін қосыңыз. Типтік көрсеткіштер:

• көлем өсімі: +20–50% (жоба кеңейсе жоғарырақ)
• пиктер: кей көздер үшін 2–5x (VPN, прокси, EDR)
• өңдеу шығындары: парсинг, нормализация және жүйелік оқиғалар үшін +10–30%

4. Жүктемені лицензия шектеулеріне аударыңыз және лимиттерді тексеріңіз: EPS, күндік көлем, көздер саны, қолжетімді функциялар. Орташа және пиковый күндерді бөлек салыстырыңыз.

5. Қабылдау, іздеу және архивке арналған сақтау мен инфрақұрылымды есептеңіз. Сақтауды қабаттарға бөліп, жүйенің пиктерді және аналитиктердің сұрауларын бірге көтере алатынын тексеріңіз.

Қателеспеу үшін мини-мысал

Егер қазір 1200 EPS орташа, пиктерде 3000 EPS болса және сіз EDR мен желілік құрылғыларды қосуды жоспарласаңыз, тек орташа бойынша лицензия алу сізді тез шектеуге әкеп соғады. Қауіпсіздік үшін пик пен өсім запасын ескеріңіз, ал сақтау мерзімін «жұмыс үшін» және «талаптар үшін» бөлу тиімді.

Лимиттердің кенеттен таусылуына әкелетін типтік қателіктер

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

Екінші қате — кіріс көлемін сақтау көлемімен шатастыру. GB/суткі — бұл келген көлем, ал сақтау парсинг, обогащение, индексация, сығымдау және қызметтік өрістер әсерінен өзгеруі мүмкін. Коэффициенттерсіз 1,5–3 есеге қате кету оңай.

Тағы бір сценарий: жобаның уақыт өте көздері көбейеді, бірақ есепті қайта қарамайды. Бүгін тек домен мен желі болса, ертең EDR 500 жұмыс орнында, бұлт журналдары, WAF және жаңа бизнес-қызмет қосылады. Бұл қағаздағы «іріктеулерге» қарағанда EPS пен көлем бойынша үлкен өзгерістер әкелуі мүмкін.

Шуды тоқтатпау да жиі проблема: барлық debug-логтар, рұқсат етілген allow оқиғалары және көп сөзді прокси журналдары көлемді тез өсіреді. Сәйкестілік: не шFiltering on intake, what to aggregate, what not to store — policies are needed.

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

Өзіңізді тексеру үшін:

• пиктер ескерілген бе (мысалы 95-процентиль немесе орташаға x2) және «жауын-тұзды» сынақтар бар ма
• кіріс көлемі vs нақты сақтау коэффициенттері (индексация мен жүйелік деректерді ескеріп)
• «+6 ай» көздер тізімі мен өсім бағалауы дайын ба
• лог гигиенасы мен фильтрлер анықталды, ретеншн деректердің құндылығына байланыстырылған
• горячее және архив айырмасы бар ма, жылдамдық үшін төлеуге қажет емес жерде ақша жұмсамау үшін

Практикалық мысал: EDR қосып, домен контроллерлерінде егжей-тегжейлі аудитты пилот үшін қосқан соң, пилот аяқталып параметрлер қалса, EPS пен күндік көлем өседі — SIEM «жаман» болғандықтан емес, кім болса да қандай логтарды сақтау және қалай қайта қарау керектігін бекітпегендіктен шектеуге соғады.

Сценарий мысалы: 6 айға есептеу өсімді ескере отырып

Мысалға, 800–1500 пайдаланушысы бар компания, бірнеше филиалмен. Алты ай ішінде штат пен жүктеме 20% өседі. Сонымен қатар жаңа көздер қосылады: жұмыс станцияларына EDR, прокси, пошталық шлюз және VPN.

Бастапқыда AD, Windows сервер оқиғалары, желілік құрылғылар және бірнеше бизнес-қосымша қосулы. 7–14 күндік өлшем бойынша орташа 900 EPS және 25 GB/суткі шығады. Жұмыс уақытындағы пиктер 2500 EPS-ке дейін жетеді (мысалы таңертеңгі логиндер мен жаңартулар кезінде).

6 айдан кейін жаңа көздер қосылады. EDR әдетте EPS пен көлемді едәуір өсіреді. Прокси көп «сөйлейді», VPN инциденттерде және жаппай қосылымдарда пиктер береді. Алдыңғы сүзгісіз және баптаусыз бұл 1600 EPS және 50 GB/суткі орташаға айналуы мүмкін.

Нормализация мен гигиена енгізілгеннен кейін: ашық шуды алып тастау, артық егжей-тегжейлерді шектеу, дедупликация. Егер лицензия шикі кіріс бойынша есептелсе, бұл төлемді әрдайым азайтпайды, бірақ сақтау мен іздеулерге әсерін төмендетеді. Мысалға, горючем үшін сақтауға арналған пайдалы ағым 20% қысқарды: 40 GB/суткі, бірақ лицензиялық шектеуді шикі 50 GB/суткі ретінде жоспарлаңыз.

Өсімді 20% ескеріп соңғы жоспар: шамамен 60 GB/суткі және 1900 EPS (піктерімен бірге).

Сақтауға келсек: горячее 30 күн және архив 180–365 күн. 60 GB/суткі бойынша горячее: 60 x 30 = 1800 GB (1.8 TB) плюс индекстер мен метадеректер үшін 30–50% (шамамен 2.4–2.7 TB). 365 күн архив: 60 x 365 = 21.9 TB. Архив 2 есеге сығылса ~11 TB, бірақ сақ болу үшін үлкенірек есептеген дұрыс.

Лицензияларды төте сатып алмау үшін әдетте келесі запас қойылады:

• EPS үшін пиктерге запас: орташаға 2–3x минимум
• GB/суткі-ге запас: жаңа көздер мен бастамадағы шуды ескеріп +25–40%
• инциденттерге жеке буфер (DDoS, EDR-тің жаппай срабатываниялары)
• сақтау бойынша запас: есептелген сыйымдылыққа +30% (индекстер, ретеншн, өсім)
• кеңею жоспары кварталға арналған, тіпті егер сатып алу жылына бір рет болса да

Қысқа чек-лист сатып алу мен іске қоспас бұрын

Лицензиялар мен лог жинауды қоспас бұрын негізгі сандар мен келісімдер бекітілсін.

• лог көздерінің толық тізімі бар (AD, VPN, EDR, фаерволдар, серверлер, бизнес-жүйелер) және әрқайсысының иесі анықталған
• негізгі көздер бойынша орташа және пиктік EPS өлшемдері тіркеліп, өлшем кезеңі (қалыпты күн, патч-терезе, инцидент) көрсетілген
• GB/суткі есептелген: шикі ағым және өңделгенінен кейінгі көлем (егер SIEM шикі және өңделгенді екі көлем ретінде сақтаса — екі бөлек көрсетіңіз)

Сақтау шектеулеріне соғыспау үшін мерзімдер мен қабаттарды алдын ала келісіңіз. Әйтпесе бір департамент жыл бойы горячее іздеуді сұрайды, ал бюджет екі аптаға есептелген болып шығады.

• сақтау мерзімдері мен қабат бойынша бөлініс бекітілген (тергеулер үшін горячее, тексерулер үшін warm, комплаенс үшін архив)
• өсім мен жаңа көздерге запас қойылған және допущениялары түсінікті (мысалы, квартал сайын +20% оқиғалар және N жаңа жүйе қосу)

Соңында лицензия, сақтау және «темір» өзара сәйкес келетінін тексеріңіз:

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

Мини-сценарий: егер ертең бір ірі көз қосылса (мысалы EDR барлық жұмыс орындарына), сіз алдын ала EPS, GB/суткі және сақтау көлемін қандай шамаға өсетінін және қай лимит бірінші болып критик болатынын білесіз.

Келесі қадамдар: келісім, пилот және масштабтау жоспары

EPS, күндік GB және сақтау бойынша сандар бар болса, оларды сатып алу және ИТ талаптарына ауыстырыңыз. Қандай керек қазір және 6–12 айдан кейін қанша болатынын бекітіңіз.

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

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

Пилот көп көздер, шуды жоғары немесе пиктер белгісіз болған жағдайда пайдалы. Қарапайым схема: критик көздерді (AD, VPN, EDR, негізгі серверлер) 2–4 апта қосып, өлшемдерді қайталап алып, соңғы сатып алуды жаңартыңыз.

Егер көмек керек болса, GSE.kz есептеу, аудит, SIEM енгізу және сервер/сақтау таңдау бойынша қолдау көрсете алады. Жүктеме бойынша масштабтау үшін көбіне кеңейтілетін есептеу тораптары (мысалы S200 Series негізіндегі стоечные серверлер) және 24/7 қолдау қарастырылады, осылайша кеңейту тоқтаусыз өтеді.