Оқшауланған контурлар үшін антивирусты лицензиялау: неге назар аудару керек

Неліктен оқшауланған контурда антивируспен проблемалар туындайды

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

Проблемалар көбінесе АҚ (ақпараттық қауіпсіздік) және ИТ арасындағы күтілімдердің айырмашылығынан басталады. АҚ — актуальды базалар, түсінікті есептер және барлық уздер қорғалғаны туралы растау күтеді. ИТ — лицензия белсенді болса, «сатып алдық, демек жұмыс істейді» логикасы бойынша қарайды. Нәтижесінде лицензия бар, бірақ жаңартулар келмейді, басқару консолі кейбір машиналарды көрмейді, және аудит кезінде ешкім дәлелдемелер жинамағаны анықталады.

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

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

• жаңартуларды қалай алатыныңыз, тексеретініңіз және әкелетініңіз (кім, қайдан, қаншалықты жиі, қандай валидациямен);
• офлайн-репозитарий қай жерде сақталатыны және оның тұтастығы үшін кім жауапты;
• лицензия қалай есептеледі: құрылғылар бойынша, серверлер бойынша, виртуалдық машиналар немесе ядролар бойынша;
• АҚ-қа қандай есептер қажет (қамту, актуалдық, инциденттер, исключения) және қандай форматта;
• бұзушылық не есептелетіні: «7 күн жаңартулар жоқ», «консольмен байланыс 24 сағат жоғалған» және т.б.

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

Лицензия моделдері: интернетсіз не шын мәнінде жұмыс істейді

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

Құрылғылар бойынша, серверлер бойынша немесе пайдаланушылар бойынша: офлайнда не оңай

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

Практикалық тәсіл — объектінің лицензияланатын нысаны ретінде ережелерді алдын ала бекіту (физикалық ПК, ВМ, терминалдық сервер, жаңартуларға бөлінген сервер) және біртұтас активтер тізімін жүргізу.

Сатып алудан бұрын вендордан есептеу детальдарын сұраңыз:

• физикалық ПК мен виртуалды машина бөлек есептеледі ме;
• басқару сервері мен офлайн-репозитарий бөлек лицензияны талап етеді ме немесе пакетке кіреді ме;
• терминалдық серверлер «сервер бойынша» есептеледі ме немесе сессиялар/пайдаланушылар бойынша ма;
• жабдық алмастырғанда лицензия тасымалдауға рұқсат етіле ме және бұл қалай расталады.

Жазылым (подписка) және мәңгілік лицензия: қайда қауіп бар

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

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

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

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

Интернетсіз жаңартулар: процесті және жиілікті қалай жоспарлау керек

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

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

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

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

Егер жаңартулар тек «санитарлы шлюз» арқылы рұқсат етілсе, процесті тексерулер тізбегі ретінде жоспарлаңыз:

1. сыртқы аймақта жаңартулар пакеттерін шығарып алу;
2. шлюзте антивирустық тексеріс және тұтастық бақылауы;
3. тасымалдаушы арқылы немесе бөлек арна арқылы буферлік аймаққа көшіру;
4. эталондық топта тестілеу (бірнеше ПК және бір сервер);
5. контурге тарату және ИБ үшін жаңарту фактісін тіркеу.

Офлайн-репозитарий: архитектура нұсқалары

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

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

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

Жүктеу зонасы (staging)

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

Сақтау және оралу

Егер импорттан кейін жалған срабатывания немесе өнімділіктің төмендеуі байқалса, жылдам оралу үшін бірнеше нұсқасын сақтаңыз. Қалыпты жағдайда 2–4 «срез» жеткілікті: соңғы жұмыс істеген, бір алдыңғы және тағы 1–2 сақтық көшірме.

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

Басқару инфрақұрылымы және журнал жүргізу жабық желіде

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

Басқару консоли: қайда және қалай орналастыру

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

Логтар мен оқиғаларды орталықтан сақтау жақсы: әйтпесе түйінді қайта орнатқанда немесе локал дискі толғанда тарих жоғалады. Практикалық нұсқа — оқиғалар мен журналдарды контурдегі бөлек серверге сақтау, сақтау мерзімі (мысалы, 90–180 күн) және резервтік көшірумен. Егер контур кішкентай болса, консоль серверінде сақтау қабылданады, бірақ диск орнын бақылау және тұрақты бэкаптар міндетті болуы тиіс.

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

Рөлдер және қолжетiмдер: хаос басталатын минимум

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

• антивирус әкімшілігі (саясаттар, орнату, жаңартулар);
• АҚ маманы (инциденттерді бақылау, есептер, исключенияларды мақұлдау);
• аудитор (тек оқу және есептерді шығару);
• резервті жауапты (демалыс немесе инцидент кезінде).

Осылайша жауапкершілік, консольдегі әрекеттердің журналдалуы және тексерулерге дайын болу мәселелері алдын ала жабылады.

Активтерді есепке алу және лицензия санын есептеу

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

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

Есепке әдетте жұмыс ПК мен моноблоктар (дежурные және резервті қоса), физикалық серверлер мен критикалық рөлдер (AD, файл, пошта), виртуалды машиналар (егер лицензия VM бойынша есептелсе), VDI және терминалдық фермалар (жиі бір уақытта қосылған пайдаланушылар немесе хосттар бойынша есептеледі), тест стендтері мен песочниктер кіреді, егер онда білікті деректер немесе контурге қатынасы бар болса.

Өсу мен ауыстыру үшін резерв қалдырыңыз. Көбіне бұл ағымдағы санға 10–20% тең, бірақ жоспарға сүйенген дұрыс: жаңа жұмыс орындарын сатып алу, сервер жаңарту, жаңа сервис пилоты. Мысалы, егер контурда 50 жұмыс станциясы және 10 сервер болса, және кварталда 2–3 ПК жаңартатын болсаңыз, 8–12 лицензия резерві орынды көрінеді.

Уақытша түйіндер мен мердігерлерді бөлек қарастырыңыз. Жұмыс үшін ноутбуктарға уақытша пул ұстап, мерзімдерін тіркеу қауіпсіз. Әйтпесе ұқпай шектеуден шығып кету оңай.

Инвентаризация қарапайым, бірақ толық болуы керек. Міндетті өрістер: хост аты, рөлі (ПК, сервер, VDI, тест), орналасқан жері (площадка, стойка, кабинет), иесі (бөлімше, жауапты), статусы (қызметте, резерв, уақытша, списан).

АҚ және аудит үшін есептілік: алдын ала не жинау керек

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

АҚ әдетте төрт сұрақ қояды: қорғаныс бар ма, ол актуалды ма, инциденттер болды ма, қай жерлерде исключения бар. Осыған жауап ретінде регламент бойынша үнемі келесі есептер жасалуы керек:

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

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

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

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

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

Жұмыс реттілігі келесідей:

• контур шекарасын және шектеулерді бекітіңіз: сегменттер, түйіндер саны, критикалық серверлер, USB/носительдер ережесі, тасымалдау кестесі, журнал талаптары;
• лицензия моделін және есептеу метрикасын таңдаңыз: құрылғылар бойынша, пайдаланушылар бойынша, серверлер бойынша, виртуалдық машиналар мен тест стендтер бөлек есептелетінін анықтаңыз;
• басқару және жаңартуларды развернуть етіңіз: контурдегі басқару консольі, офлайн-репозитарий, пакеттерді тасымалдау маршруты (мысалы, тексеру үшін буферлік аймақтағы бөлек компьютер арқылы);
• саясаттарды орнатыңыз: қорғаныс деңгейлері, сканерлеу кестелері, локальдық репозитарийден жаңарту, исключениялар тек өтініш арқылы, әкімшілер мен операторлардың құқықтары;
• бақылауды қосыңыз: тұрақты есептер, мерзімі өткен базалар бойынша ескертпелер, өшірілген қорғанысқа бақылау, «факт vs есеп» регулярлы сәйкестендіру.

Пилотты шағын топта (мысалы, 20–30 жұмыс орны және 2–3 сервер) бастау пайдалы, содан кейін кеңейту қажет. Аурухана не өндіріс болса, сканерлеудің жұмыс уақытын бұзбауын қамтамасыз ету үшін бұл тәуекелді азайтады.

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

Сатып алу және эксплуатацияда жиі қателіктер

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

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

Тағы бір қате — носительдермен тасымалдауда: олар тексерілмейді, тасымалдау журналдалмайды, қайдан не келгені белгісіз. Нәтижесінде АҚ жаңартулар жеткізілу тізбегін дәлелдей алмайды және қай жерде қате болғанын тез анықтай алмайды.

Көп жағдайда «уақытша шара» тұрақтыға айналады: қосымшаларға немесе папкаларға арналған исключениялар орнатылады және кейін қайта қаралмайды. Бір жарым жылдан кейін исключениялар оншақты болады да қорғаныс деңгейі елеулі төмендейді.

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

Сатып алудан бұрын және алғашқы эксплуатация айларында қысқа тексеріс көмектеседі:

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

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

Сатып алу немесе продление алдында қысқа чек-лист

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

Бес нәрсені тексеріңіз:

• лицензия метрикасы және нысандар тізімі: жұмыс станциялары, серверлер, VDI, терминалдық серверлер, тест стендтері; өшірілген уздер мен виртуализация қалай есептелетінін;
• жаңартулар регламенты: база көзі, контурге әкелу жиілігі, кім жеткізеді (ИТ) және кім қадағалайды (АҚ), форс-мажор кезінде не істеу керек;
• офлайн-репозитарий схемасы және нұсқаларды сақтау: қанша ұрпақты ұстайсыз, эталондық көшірме қайда, тұтастық қалай тексеріледі;
• минималды есептер жинағы: қамту, базалар мен қозғалтқыштың актуалдығы, инциденттер, исключениялар (аудит көбіне исключенияларға мән береді);
• журнал талаптары: қандай оқиғалар жазылады (жаңартулар, детектілер, қорғаныстың өшірілуі, саясат өзгерістері), қайда сақталады және қанша уақыт, орын жеткілікті ме және кімде қолжетімділік бар.

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

Келесі қадамдар: талаптарды қалай рәсімдеп, енгізуді қалай ұйымдастыру керек

Алдымен контурді қысқа, бірақ дәл сипаттаудан бастаңыз. ТЗ-де қандай сегменттер оқшауланғандығы, деректер ішке қалай енгізілуі мүмкін (носительдер, шлюз, арнайы терезе), және әкімшілік программалық қамсыздандыруға қандай шектеулер бар екенін көрсетіңіз.

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

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

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

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