DMARC мемлекеттік домендер үшін: SPF, DKIM және есептерді кезең-кезеңімен қосу

Мақсат анық және қарапайым: мемлекеттік доменді жалғандаудан қалай қорғау керек

«Біздің аттан келген хаттар» — бұл тек сіздің пошта жүйеңіз жіберген хабарламалар ғана емес. Бұл From өрісінде сіздің доменіңіз (мысалы, @gov.kz) көрсетілген кез келген хаттар, тіпті оларды алаяқтар өз серверлерінен жіберсе де. Қабылдаушыға бұл сенімді көрінеді: таныс домен, «ресми» стиль, кейде басшының қолтаңбасы.

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

Қорғаныс үш механизмге негізделеді:

• SPF — қай серверлер домен атынан хат жібере алатынын көрсетеді.
• DKIM — хатқа криптографиялық қолтаңба қосып, оны жолда өзгерту мүмкін емес етеді.
• DMARC — тексерістерді байланыстырып, қабылдаушыларға «күмәнді» хаттармен не істеу керектігін анықтайды.

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

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

Қысқаша: SPF, DKIM және DMARC туралы көп теориясыз

Жеңіл түсіну үшін: SPF қай серверлерден жіберуге болатынын айтады, DKIM хаттың өзгермегенін дәлелдейді, ал DMARC тексерістер бойынша саясат қояды.

SPF жіберушінің серверінің IP-ін тексереді және сіз DNS-те жариялаған тізіммен салыстырады. Бірақ SPF пайдаланушыға көрінетін From өрісін қорғамайды және қайта жіберулерде немесе кейбір тарату сервисінде бұзылуы мүмкін.

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

DMARC SPF пен DKIM-ті бір ережеге байланыстырып, alignment (сәйкестік) ұғымын енгізеді. Тексеру SPF/DKIM-нің өту фактісімен шектелмей, тексерілген доменнің From-тағы доменге сәйкес келуін тексереді. Бұл жіберушіні жалғандауды азайтады.

DMARC-тың үш режимі бар: none (тек бақылау), quarantine (күмәнділерді спамға) және reject (қатаң блоктау). Әдетте none-нан бастайды, сол арқылы жағдайды қарап, заңды жіберулерді бұзбайды.

DNS-де әдетте керекті жазбалар:

• SPF: доменнің түбірінде (немесе жіберетін поддоменде) TXT жазба.
• DKIM: selector._domainkey түріндегі TXT жазбалар.
• DMARC: саясат пен есептер мекенжайларын көрсететін _dmarc TXT жазба.

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

Дайындық: «кім шын мәнінде жібереді» деген инвентаризация

SPF, DKIM және DMARC-ты қоспас бұрын маңызды сұрақ: доменнің атынан қанша түрлі жүйе хат жібереді және кім жауапты? Бұл анық болмаса, «хаттар кетпей қалды» деген шағымдардан кейін соғұрлым слепой түзетулер жасайсыз.

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

Көбінесе тізімге корпоративті пошта мен шлюзтер, тарату және хабарландыру сервистері (сайттар, порталдар, колл-орталық, СЭД), МФУ/сканерлер, сыртқы мердігерлер, тест орта және басқа да жүйелер кіреді.

Әр көзге «паспорт» дайындаңыз: иесі (бөлімше), техникалық контакт, кім баптауларды өзгерте алады және қалай жылдам жауап береді. DMARC қатайған кезде сіз почта әкімшілерімен ғана емес, бизнес-жүйе иелерімен де жұмыс істейтін боласыз.

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

DMARC агрегатталған есептері (RUA) үшін бөлек пошта жәшігін ашыңыз. Ол жеке адамның атымен емес, иесі анық басқаратын қорап болуы керек: есептер тұрақты келеді және оларды талдау қажет.

1-қадам: SPF-ті сақтықпен және күтпеген жағдайларсыз баптау

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

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

Кейін барлық рұқсат етілген көздердің толық тізімін жинаңыз: пошта серверлері, шлюзтер, бұлтты пошта, сондай-ақ сіздің атыңыздан жіберетін мердігерлер. Көбіне бұл IP-адрестер (ip4/ip6) және сервис-include комбинациясы.

DNS-сұраулар лимитін тексеріңіз. Бұл жиі кездесетін себептердің бірі: қабылдаушы тексеріс жүргізіп, 10 сұрау лимитіне тіреліп, SPF жарамсыз деп есептейді. Егер көп include болса, тізбектерді қысқартыңыз немесе жіберуді поддомендерге бөліңіз.

Жазбаны кезең-кезеңімен енгізіңіз: алдымен ~all (жұмсақ режим) қойып, тізімге түспеген көздерді анықтаңыз. Осы түзетулерден кейін -all (қатаң режим) қойыңыз.

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

2-қадам: DKIM-ді қосып, кілттерді басқаруды ұйымдастыру

DKIM хатқа криптографиялық қолтаңба қосады. Қабылдаушы оны DNS-тегі ашық кілтпен тексеріп, хаттің соңынан өзгермегеніне көз жеткізіп, қатты саясатқа көшу жеңілдейді.

Қай жерде қолтаңбаны қою керек

Хат сыртқа шығатын соңғы жерлерде қолтаңба қою керек және ол жерде баптауларға жақсы бақылау қажет. Негізгі ағымдардың барлығы қолтаңбалануы тиіс.

Қолтаңба әдетте пошта серверінде, интернетке шығатын соңғы шлюзте, бұлтты пошта провайдерінде, тарату сервисінде немесе тікелей хат жіберетін қолданбалы жүйеде (басқа жолы болмаса) қойылады.

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

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

Қайта айналдыру және бақылау

Ротация апатты жағдайда емес, жоспарлы болуы керек. Практикалық минимум:

• кілт иесін және резервті орындаушыны анықтау;
• кілттерді жоспар бойынша ауыстыру (мысалы, 6–12 айда);
• алдымен DNS-те жаңа ашық кілт жариялап, содан кейін қолтаңба селекторын ауыстыру;
• бұрынғы кілтті біраз уақытқа сақтау, ал хаттар қабылдаушыларға «жетуі» үшін уақыт беру.

Пішімдеу кезінде қолтаңбаға араласатын аралық өңдеулерді тексеріңіз: дисклеймер қосу, антивирус шлюздері, құжат айналымы жүйелері арқылы қайта жіберу. Әдетте қолтаңбаны соңғы интернет түйініне жақын қою және каноникализацияны relaxed/relaxed қию көмектеседі. Қосу соңында әр жүйеден тест хаттар жіберіп, қабылдаушыларда DKIM = pass болуын тексеріңіз.

3-қадам: DMARC-ты бақылау режимінде іске қосып, деректер жинау

SPF пен DKIM негізгі жіберушілерге орнатылғаннан кейін DMARC-ты осылайша қосуға болады, ештеңені бұзбай. Мақсат — домен атынан кім, қайдан хат жіберіп жатқанын және қай ағымдар тексерістен өтпейтінін көру.

Бастапқыда p=none саясатын қосыңыз. Бұл хаттарды блоктамайды, бірақ есептер келеді.

DMARC-тың негізгі жазбасына мысал (доменіңізге және есепке алу жәшігіне бейімдеңіз):

_dmarc.example.gov.kz TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100"

Бұл жазбада практикалық мәні бар бөліктер:

• rua: агрегатталған DMARC есептері (RUA), баста үшін жеткілікті;
• ruf: форензик есептер, егер ұйым саясаты мұндай деректерді алуға мүмкіндік берсе;
• adkim және aspf: сәйкестік режимі (alignment). Мемлекеттік домен үшін жиі қатаң режимнен бастау ақылға қонымды, бұл «жат» ағымдарды тез анықтауға көмектеседі.

Агрегатталған есептер (RUA) әдетте күнделікті архив түрінде келіп отырады. Бұл есептерді қайда сақтайтыныңызды және кімнің қолы барын алдын ала шешіңіз. Практикалық нұсқа: есептерге арналған бөлек пошта жәшігі, автоматты түрде қорғалған сақтау жүйесіне шығару және көз бойынша (IP/провайдер), сервис және SPF/DKIM нәтижелері бойынша сүзгілеу қабілеті бар қарапайым талдау құралын орнату.

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

Осы кезеңде «сайтанынан өтпеген» хаттарға жаза қолдану қажет емес. Негізгісы — себептерді жіктеу: SPF бұзылған, DKIM жоқ, DKIM бар бірақ домен сәйкестемейді, немесе жіберуші мүлдем сіздің емес.

Поддомендер мәселесін бөлек қарастырыңыз. Егер service.department.gov.kz сияқты адресаттарыңыз болса, sp (поддомендерге саясат) орнатуды немесе оны p-пен бірдей қалдыруды шешіңіз, сонда кейін күтпеген блоктаулар болмайды. Үлкен ұйымдарда әдетте sp=none бастап, маңызды поддомендерге бөлек ережелер орнатады.

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

DMARC есептерін талдау: «кім біздің атынан жібереді» дегенді қалай түсіну

Агрегатталған DMARC есептері (RUA) сіздің доменіңізді From өрісінде көрсеткен хаттарды кім жібергенін, қай IP-лерден келгенін және SPF пен DKIM тексерістерінен өткен/өтпегенін көрсетеді, сонымен қатар alignment туралы мәлімет бар. Бұл ең сенімді дереккөз: ол нақты жұмысты көрсетеді, регламентте жазылған нәрсені емес.

Есептегі ең пайдалы өрістер

Есепте көптеген техникалық өрістер бар, бірақ жұмыс үшін әдетте мынасы жеткілікті:

• жіберу көзі: IP-адрес және кейде провайдердің атауы;
• көлем: осы көзден қанша хат келгені;
• нәтиже: SPF және DKIM бойынша pass/fail;
• alignment: DMARC политиканысын From домені бойынша өтуі;
• уақыт аралығы: қай күнге жинақталған статистика.

Бастау үшін көлемге назар аударыңыз: 1–2 көзі жалпы трафиктің 80% бере алады. Содан кейін бұзылу түрін қараңыз: тек SPF, тек DKIM немесе alignment-тің сәтсіздігі. Мысалы, кейбір заңды жүйеде қайта жіберу салдарынан SPF құлап қалуы мүмкін, ал DKIM кейде хаттың өзгеруінен бұзылады.

Шынайы тарату мен жалғандауды ажырату үшін мына белгілерді іздеңіз: кенеттен пайда болған жаңа IP-лер, күніне 1–5 хаттан тұратын «ұсақ құйрықтар», мердігерлеріңізге сәйкес келмейтін провайдерлер және From сіздің доменіңіз болса да, SPF де, DKIM де өтпейтін үйлесімдер.

Деректерді талдау барысында жіберушілер реестрін жүргізген дұрыс:

• көз (IP немесе сервис) және тағайындау (қандай хаттар жібереді);
• иесі: бөлімше немесе мердігер;
• статус: расталған, тексеріліп жатыр, тыйым салынған;
• не түзету керек: SPF-ке қосу, DKIM қосу, From дұрыстау;
• мерзім және жауапты адам.

Криминалистикалық RUF есептерін нақтылы және қысқа уақытқа қосыңыз: олар хат үзінділерін қамтуы мүмкін және қабылдаушы саясаттарына тәуелді. Күнделікті бақылау үшін көбіне RUA жеткілікті.

Мемлекеттік органға арналған мысал: хаостан бақылауға дейін

Мысал ретінде example.gov.kz доменін алайық. Домен атынан бірнеше заңды көз хат жібереді: корпоративті пошта, азаматтық өтініштер порталы, массовая тарату үшін мердігер, сондай-ақ бірнеше МФУ мен сканерлер.

DMARC-ты мониторинг режимінде қосқан алғашқы күндерде көбіне артықтар шығады: ескі сервис, бөлімшенің тест сервері, мердігердің теңшелмеген таратуы немесе SMTP арқылы авторизациясыз жіберетін құрылғы.

Бастапқы күндердегі есептер не көрсетеді

Есептер нақты кімнің қай IP-ден жібергенін, SPF пен DKIM-тің өтуін және alignment бар-жоғын көрсетеді.

Типтік көрініс: корпоративті пошта pass және alignment береді, өтініштер порталы SPF-ті өтіп тұр, бірақ DKIM қолданбайды; мердігер DKIM қояды, бірақ қолтаңба домені сәйкес емес, ал МФУ ештеңені өтпейді.

Жұмысын тоқтатпай шешім қабылдау

Әр «тартылымды» келесі қадамдармен ретке келтіреді:

• көздегі баптауды түзету: сервисі SPF-ке қосу, DKIM қосу, дұрыс қолтаңба доменін орнату;
• жіберуді поддоменге ауыстыру (мысалы, notice.example.gov.kz) және оның SPF, DKIM, DMARC-ын бөлек баптау;
• қажетсіз немесе басқарылмайтын көздерді тыйым салу (әсіресе құрылғылар мен «өз қолымен жазылған» жіберушілер);
• мердігерден бекітілген шлюз арқылы жіберуді сұрау немесе сіздің доменіңізбен қолтаңбалауды талап ету.

Келіссөз ұзап кетпес үшін жауаптыларды алдын ала бекітіңіз: IT — DNS пен поштаның иесі, профильдік бөлім — портал мен процестер, сатып алу немесе келісімшарт менеджері — мердігерлер. Өзгерістерді кезекпен енгізіп, әр қадамнан кейін 2–3 күн бақылау терезесін қалдырыңыз.

Прогресті есептерден өлшеңіз: SPF пен DKIM бойынша pass-тың үлесі өседі, alignment көрсеткіші жақсарады. Шуы жоғалғаннан кейін none-нан quarantine және одан reject-ке өтуге болады.

Қатаң саясатқа өту: quarantine және reject зиянсыз

DMARC-тың қатаң саясаты фишинг пен жіберушіні жалғандауды азайту үшін қажет, бірақ оны тек нақты қандай жүйелер заңды жіберулерді қамтамасыз ететінін біліп болғаннан кейін қатаң түрде енгізу керек. Мемлекеттік орган үшін азаматтарға немесе ортақ хат алмасуға хабарлама жіберудің тоқтауы аса қауіпті.

quarantine-ге қалай өту және pct таңдау

p=none кезеңінен кейін нақты жіберушілер тізіміне ие боласыз. Қауіпсіз өту үшін p=quarantine-ге пайыздық көрсеткішпен өту қолайлы.

Көбінде pct=10–25-ден бастап, апта сайын немесе екі аптасына көтеріп отырады, егер жағымсыз жағдайлар болмаса. Пайызды көбейткен сайын түзетулерді тексеріңіз: SPF-ке жетіспейтін сервисті қостыңыз ба, сервис DKIM-ді қосты ма, домен сәйкестігі түзетілді ме.

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

Қашан reject қосуға болады

p=reject-ке өту — «күмәнді зона» аз қалған кезде ақталады. Бақылау нүктелері қарапайым:

• есептерде 2–4 апта бойы жаңа белгісіз жіберушілер жоқ;
• барлық маңызды қызметтер DMARC-ты тұрақты түрде өтеді (SPF немесе DKIM-мен alignment);
• жаңа жіберушіні қосу және өзгерістерді енгізу процесі анықталған;
• поддомендер үшін бөлек ережілер орнатылған.

Ретрансляция мен тарату тізімдері SPF-тен жиі ұшырап қалатынын ескеріңіз; DKIM қайта қойылуы мүмкін. Жұмыс тәжірибесінде келесі тәсілдер көмектеседі: бастапқы жіберушінің DKIM-іне сену, шлюзтерде қолтаңбаларды бұзбау және таратулар үшін бөлек домен/поддомен пайдалану.

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

SPF, DKIM және DMARC енгізуде жиі кездесетін қателіктер

SPF, DKIM және DMARC қосылғанымен пошта әлі де спамға түсіп немесе блокталуы мүмкін. Бұл көбіне «жазба нашар» емес, жіберу ағымдарының, домендердің және хаттардың жолдағы өзгерістері арасындағы келіспеушіліктерден болады.

Типтік проблемалар:

• SPF өсіп, DNS-сұраулар лимитіне (10) тіреледі — сол себепті кейбір хаттар SPF permerror алып, DMARC те істен шығады. Шешім: include-дарды қысқарту, артық көздерден тазарту және жіберуді поддомендерге бөлу.
• DKIM барлық ағымдарды қолтамайды: негізгі пошта қолтаңбаланса, портал арқылы шыққан хабарлар қолтаңбасыз немесе басқа доменмен қолтаңбаланған болуы мүмкін.
• Хат жолда өзгеріске ұшырап, DKIM бұзылады: шлюз баннер қосады, жолдарды өзгертеді немесе MIME-ді қайта қаптайды. Өзгеріс орнын табып, қолтаңбаны интернетке шығатын соңғы түйінде қою керек.
• DMARC қосылған, бірақ alignment жоқ: From сіздің доменіңіз болса да Return-Path (MAIL FROM) басқа домен және SPF сәйкеспейді. Немесе DKIM d= поддоменге қойылған, ал сіз негізгі доменге сәйкестікті күтіп отырғансыз.
• Сыртқы қызметтердің ұмытылуы: билет жүйелері, мердігерлер, тарату, сканерлер, МФУ, веб-формалар — олар домен атынан жібереді, бірақ саясатқа дайын болмауы мүмкін.

Ең қауіпті қателік — reject-ті тым тез қосу. Бақылаусыз кезеңсіз оны қоссаңыз, маңызды хабарламалар тоқтап қалады және сіз бұл туралы бірнеше күннен кейін білесіз.

Іс жүзінде қарапайым әдіс: алдымен мониторингтен бастаңыз, деректер жинаңыз, жүйе иелерін тағайындаңыз және откат жоспарын сақтаңыз (мысалы, уақытша pct-ті төмендету немесе p=none-ге қайту). Егер пошталық ағымдарды басқарғысы келмейтін адам жоқ болса, интегратор көмегімен жіберушілер картасын жинап, баптауларды стандартқа келтіру пайдалы.

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

SPF, DKIM және DMARC пошталық қорғаныс «қиын тақырып» емес, егер оны басқарылатын процеске айналдырсаңыз.

Негізгі дайындықты тексеріңіз:

• Жіберуші көздері тізімі жасалған және расталған (пошта серверлері, сервис-деск, таратулар, кадр жүйелері, мердігерлер). Әр көзге жауапты тағайындалған.
• SPF абайлап орнатылған: артық жазбалар жоқ, қажетті сервистер қосылған, DNS-сұраулар лимиті аспаған және жаңа сервис пайда болғанда өзгеріс тәртібі анықталған.
• DKIM мүмкін жерлерде қосылған: қолтаңба тұрақты өтіп жатыр, кілттер бақылауда, ротация жоспары бар (мысалы, 6–12 айда) және компрометация жағдайындағы процедура бар.
• DMARC есептері жиналып, талданады: тұрақты шолу, жіберушілер реестрі және не түзетілгені, не әлі жұмыста екені жазылады.
• quarantine/reject-ке өту келісілген: дайындық критерийлері мен өзгеріс терезелері анықталған, сонда хабарламалар мен ішкі хат алмасу бұзылмайды.

Қатаңдатуға дайындықтың критерийлері де анық: есептерде заңды ағындардың көбісі SPF және/немесе DKIM арқылы домен сәйкестігімен өтеді, белгісіз көздер ажыратылған немесе дұрыс қолтаңбаланған. Әдетте өту схемасы: p=none -> p=quarantine (аз мөлшерде) -> pct-ті арттыру -> p=reject.

Одан әрі процестің иесін тағайындау (көбінесе пошта/Ақпараттық қауіпсіздік) және регламент бекіту маңызды: жаңа сервис қалай қосылады, есептер кім қарайды, тәуекел кім қабылдайды. Қол жеткізуге етек жетпесе, жүйелік интегратор шақыруға болады. Мысалы, GSE.kz (gse.kz) Қазақстанда интегратор ретінде пошта инфрақұрылымын, DMARC есептерін талдауды және қызмет көрсетуді қамтамасыз ете алады.