Лицензиялық келісімдердегі телеметрия: енгізбестен бұрын нені тексеру керек

Мәселе неде: лицензия деректер жинауды қамтуы мүмкін

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

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

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

Көп жағдайда мәселе жауапкершілік шекарасында туындайды. IT өнімді орнатып, баптайды (көп жағдайда әдепкі бойынша), ақпараттық қауіпсіздік деректерді беру заңдылығын және каналдарды бақылауды қарайды, юристтер лицензияларды, DPA‑ны және деректерді өңдеу туралы формулировкаларды тексереді, сатып алу шарттар мен қосымшаларда талаптарды бекітеді.

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

Қысқа және түсінікті анықтамалар

Телеметрия туралы шарттарды оқығанда, алдымен терминдерді салыстырып алған жөн. Әртүрлі вендорларда бір зат әртүрлі аталады, ал маңызды бөлшектер сноскаларда жасырылған болуы мүмкін.

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

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

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

Жеке деректер (ПДн) — адамды тікелей немесе жанама түрде анықтауға мүмкіндік беретін ақпарат. "Техникалық деректер" мен ПДн арасындағы шекара ұшқыш: IP‑адрес, құрылғы идентификаторы, есептік жазба аты, геолокация және журналдардың мазмұны телеметрияны жеке деп есептеуге жеткізуі мүмкін. Тіпті вендор «ПДн жинамаймыз» десе де, тұрақты идентификаторлар жиналмай ма және олар пайдаланушыға байланбай ма — соны тексеру керек.

Оператор және өңдеуші — деректермен жұмыс істеудің заңдылығы мен қауіпсіздігі үшін жауапты рөлдер. Оператор өңдеудің мақсаттары мен деректер құрамын анықтайды (әдетте ПО‑ны енгізетін ұйым). Өңдеуші оператордың тапсырмасы бойынша әрекет етеді (көбінесе ПО немесе бұлттық қызмет жеткізушісі). Лицензияда кім қандай рөлде екені және вендордың деректерді "өз мақсаттары үшін" пайдалану құқығы бар‑e (жоқ па) маңызды.

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

Қай құжаттарды сұрап, салыстыру керек

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

Ең алдымен EULA‑ны (лицензиялық келісім) оқыңыз. Сол жерде әдетте маңызды нәрселер жасырылған: өнім қандай деректер жинай алады, оны өшіруге бола ма, лицензия бұзылуы нені білдіреді және жеткізуші қашықтан нені жасай алады (мысалы, лицензия сәйкестігін тексеру немесе функцияларды бұғаттау). Diagnostics, telemetry, improvement, compliance checks, remote access сияқты бөлімдерді іздеңіз.

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

Егер деректерде ПДн болуы мүмкін болса, DPA (деректерді өңдеу келісімі) сұраңыз. Онда тараптардың рөлдері, өңдеу мақсаттары, сақтау мерзімдері, қорғаныс шаралары, инцидент туралы хабарлау тәртібі және субөңдеушілер тізімі бекітіледі. DPA жоқ болса, бұл — маңызды ескерту: құқықтық тұрғыдан "деректерді қалай өңдейміз" анықталмаған болуы мүмкін.

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

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

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

Телеметрия туралы мәтінде нені іздеу керек

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

Алдымен "Diagnostics", "Usage data", "Improvement", "Support", "Security" сияқты бөлімдерді табыңыз. Сосын жиналатын деректер тізімі бар‑жоғын тексеріңіз. Жақсы мәтін категориялар мен өріс мысалдарын көрсетеді (ОС нұсқасы, құрылғы моделі, қателер, іске қосу уақыты, баптаулар, идентификаторлар). Нашар мәтін «қажетті кез келген деректер» немесе «пайдалану туралы ақпарат» сияқты жалпы сөздермен шектеледі.

Формулировкаларға неге қарау керек

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

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

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

"Анонимдеуге" қатысты ынтымақтастықты ерекше тексеріңіз. "Деректерді анонимдей аламыз" деген формулиров өздігінен көп нәрсе айтпайды. Қай идентификаторлар өшірілетіні, IP‑адрестің маскасы, агрегаттау бар‑жоғын және тұлға анықталуының қайта қалпына келтіріле алатынын нақты көріңіз.

Бес сұрақ тез бағалауға көмектеседі:

• Қандай нақты өрістер жиналады, мысалдар бар ма?
• Қандай мақсаттар үшін деректер пайдаланылады, маркетинг немесе серіктестер бар ма?
• Кім келісім алуға міндетті, телеметриядан бас тартуға бола ма?
• Қанша уақыт сақталып, қалай жойылады, сақтық көшірмелер не болады?
• "Анонимдеу" нақты қалай жасалады және жеке тұлғаны қайта анықтауға мүмкіндік бар ма?

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

Бұлттық компоненттер: орналастыру және деректерді беру

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

Ең бірінші іздейтін нәрсе — өңдеу жері. Жақсы мәтін елдерді немесе аймақтарды (мысалы, ЕО, АҚШ, Қазақстан) нақты көрсетеді. "Біздің дата‑орталықтарымыз бар кез келген елде" деген тұжырым бақылаудың минималдығын қалдырады және трансшекаралық беруге әкелуі мүмкін.

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

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

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

Формулировкаларды не үшін тексеру керек

Бес сұрақ жиі белгісіздікті азайтады:

• Қай елдер немесе аймақтар көрсетілген, сақтық көшірмелерді қоса алғанда?
• Субөңдеушілер тізімі бар ма және өзгерістер туралы хабарлау тәртібі қалай?
• Трансшекаралық беру кезінде клиентке қандай міндеттер жүктеледі (келісімдер, хабарландырулар, құжаттар)?
• Келісім тоқтатылғанда деректер не болады: экспорт, жою және жоюды растау мерзімдері қандай?
• Жеткізуші бұлттық сервисті келісусіз өзгерте ала ма, қарсылық білдіру құқығы бар ма?

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

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

Қауіпсіздік және қолжетімділіктер: не жазылуы тиіс

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

Шифрлау және сақтау

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

"Қажет болса" немесе "мүмкін болса" сияқты тұжырымдарға сақ болыңыз — бұл әлсіз нүкте. Сондай‑ақ, кілттер қайда сақталатынын және диагностика үшін журналдар ашық күйде сақталмауы тиіс екендігін нақтылау тиімді.

Деректерге қолжетімділік және аудит

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

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

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

Осалдықтар, инциденттер және жаңартулар

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

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

Қадамдар бойынша: енгізер алдында қалай тексеру керек

Телеметрияны тексеру EULA‑дағы бір абзацқа келіп артық емес. Деректер жинау бөлек модульдер арқылы, бұлттық функциялармен, авто‑жаңартулар арқылы немесе қолдау арқылы іске қосылуы мүмкін, әрі талаптар әртүрлі құжаттарда шашыраған.

1. Инвентаризация компоненттері. Орнатылатын және қосылатын барлық элементтердің тізімін жасаңыз: клиент, сервер, агенттер, плагиндер, қолдау модулі, авто‑жаңартулар, аналитика, "ұсыныс" функциялары.

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

3. Құжаттарды техникалық шындықпен салыстыру. EULA, DPA (бар болса) және техникалық сипаттаманы салыстырыңыз: деректер қайда, кім және не үшін өңдейді. Айырмашылықтарды іздеңіз: техникалық сипатта "тек диагностика" деп тұрғанда, EULA «пайдалану аналитикасы» деп рұқсат беруі мүмкін.

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

5. Пилотқа дейін баптаулар және бақылау әдісі. Телеметрияны өшіруге бола ма, локальды режим бар ма, жаңартулар прокси арқылы өтеді ме — бұларды келісіңіз. Нәтижені қалай растау керегі: журналдар, конфигурация параметрлері немесе ИБ/комплаенс үшін есептер.

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

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

Лицензияларды келісуде жиі кездесетін қателіктер

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

Көбінесе кездесетін қателіктер:

• "Әдепкіде өшірулі" дегенге үміттену, нақты баптаулар тексерілмеген. Лицензияда телееметрия өшіруге болады деп жазылғанымен, өшіру түймелері клиентте, серверде, агентте және әкімші панелінде шашыраған болуы мүмкін.
• Диагностика мен маркетингті араластыру. "Диагностика" қатарында "қызметті жақсарту", "аналитика" немесе "ұсыныстар" деген мақсат табылуы мүмкін. Жұмыс пен қауіпсіздік үшін қажетті деректерді жарнама және профильдеу үшін пайдаланатыннан айыра білу керек.
• Субөңдеушілерді өткізіп жіберу және олардың тізімін келісусіз өзгерту құқығы. Бұл тәуекел: өңдеу жаңа провайдерге өтіп кетуі мүмкін, сіз кейін біліп қаласыз.
• Өнімді локальды деп сену, бірақ ішінде бұлт болуы. Сервер сізде тұрғанымен, лицензияда облақ арқылы лицензия тексеру, хабарламалар, антифрод немесе CDN арқылы жаңартулар қарастырылған болуы мүмкін.
• Пилот басталғасын DPA‑ны кейін жазу. Тестілеу лицензиясымен команда нақты есептермен өнімді іске қосады, ал кейін юридиялық шарттарды өзгерту керек болып шығады.

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

Қол қою мен іске қосу алдындағы жылдам чек‑тізім

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

• Жиналатын деректер мен мақсаттардың нақты тізімі бар ма (оқиғалар, журналдар, идентификаторлар, есептік жазба деректері, файл мазмұны — егер жиналса)? Мақсаттар нақты жазылуы тиіс.
• Телеметрия өшіріле ме: қай деңгейде (клиент, сервер, саясат) және не істен шығады? Автоматты түрде бұлтқа тіркелу міндетті ме?
• Деректер қайда сақталады: ел немесе аймақ көрсетілген бе, трансшекаралық беру бар ма, кім алушы (жеткізуші мен субөңдеушілер)?
• Кім журналдарға қол жеткізеді және қалай бақыланады: рөлдер, қолжетімділік журналдары, аутентификация талаптары, қол жеткізуді шектеу мүмкіндігі бар ма?
• Инциденттер туралы хабарлау мерзімдері: нақты сағаттар немесе күндер, байланыс арнасы және жауапты тұлғалар, сондай‑ақ қандай деректер зақымданғаны туралы міндетті хабарлау.
• Деректер қалай жойылады: мерзімдер, жою растамасының форматы және сақтық көшірмелерге қатысты ережелер.

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

Практикалық мысал: пилоттағы тәуекелдерді қалай бағалау

Орталық кеңсесі және 12 филиалы бар ұйым қызмет сұрауларын есептейтін ПО‑ны тестілеуге шешім қабылдады. Филиалдарда жалпы есептермен (мысалы, "operator1" бір бөлімше үшін) жұмыс істейді, ал кейбір компьютерлер мекенжай немесе кабинет атымен аталған. Жеткізуші «сапаны жақсарту үшін» ғана деректер жиналады деп сендірсе де, лицензиядан нақты не шығарып жатқаны және қайда сақталатыны анық емес болды.

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

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

Біріншіден, минимализация: кеңейтілген диагностика мен дамп жіберуді өшірді. Екіншіден, псеудонимдеу: тесттік компьютерлер мен есептік жазбаларды ФИО мен мекенжайларды қамтымайтындай етіп қайта атады (мысалы, "BR03‑WS07"). Үшіншіден, желілік бақылау: қосымшаның барлық шығыс трафигін прокси арқылы өткізіп, домендер мен сұраулар түрін бақылауға алды және қажет болса тез блоктауға мүмкіндік жасады.

Содан кейін шешімді пилот протоколымен бекітті: тексерулер, баптаулар және қабылданған тәуекелдер тізімделді. Қарапайым тәуекел матрицасы (ықтималдық/әсер) және өндірістік іске қосуға міндетті баптаулар тізімі юристтер мен ИБ‑ға нақты сценарийлер мен қорғаныс шараларын талқылауға көмектесті.

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

Келесі қадам — интеграторды тартып, талаптарды тіркеу: қандай деректер өңделеді, қай жерде сақтау керек, желі сегменттері, прокси, журналдар және қолжетімділік рөлдері. Егер инфраструктура жобаланса және филиалдар үшін жабдық алынатын болса, бұл талаптарды GSE.kz сияқты интегратормен бірге келісу ыңғайлы: ПО, желі, серверлер және қолдау талаптарын бір құжатта жинау оңайырақ болады.