Контейнерлер мен образдардың қауіпсіздігі: релиздерді тоқтатпайтын тексерулер

Неліктен қажет және неге релиздер тұра қалады

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

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

Тексеру кенеттен қосылса және ережелер анық болмаса, релиздер жиі бұрылып қалады. CI/CD-де бір сәтте оншақты критикалық табу шығады, билдингтер сәтсіз болады, командалар не блокер екенін талқылайды және ерекшеліктерді кім бекітетіні, қаншаға дейін болатыны белгісіз қалады. Нәтижесінде қауіпсіздік «тоқтату рычагына» айналады, қауіп-қатерді басқаруға емес.

Көбінесе бұл үш себеппен болады:

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

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

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

Негізгі ұғымдар: не нәрселерді тексереміз

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

Образ (image) — бұл қолданба шаблоны: файлдық жүйе, тәуелділіктер, іске қосу конфигурациясы. Контейнер — образдан іске қосылған экземпляр, ол код орындайды және желі мен жүйеде нақты әрекеттер жасайды. Реестр (registry) — образдар сақталатын және CI/CD мен кластердің тартып алатын жері.

Әдетте үш түрлі зат тексеріледі, және әрқайсысының өз сәті бар:

• Образды скандеу: ішінде қандай пакеттер мен кітапханалар бар, олардың CVE-лары, зиянды компоненттер бар ма.
• Конфигурацияны тексеру: образ қалай жиналған және қалай іске қосылады (Dockerfile, Kubernetes манифесттері, құқықтар, желі, секреттер).
• Runtime-оқиғалар: контейнер іске қосылғаннан кейін не істейді (күтпеген процестер, құқықтарды көтеруге әрекет, таңғалған желі байланыстары).

Тізбек көбіне ұсақ нәрселерде бұзылады. Ескі base image пайдаланады, онда критикалық уязвимділер жиналған. Dockerfile арқылы секретті образға енгізеді да ол ұзақ уақыт реестрде қалады. Қосымшаны «тез іске қосу үшін» root-пен және қосымша capabilities-пен іске қосады.

Саясаттар жұмыс істес үшін тек сканер деректері емес, контекст те қажет. Міндетті минимум:

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

Осылайша порогтар мен ерекшеліктер кездейсоқ тыйым емес, келіскен ережелер болады.

Aqua, Prisma Cloud және Sysdig: таңдауға қалай қарау керек

Aqua, Prisma Cloud және Sysdig-те ортақ негізгі міндеттер бар: образдардағы уязвимдіктер мен қауіпті конфигурацияларды табу, түсінікті саясаттарды қолдану (не шығаруға болады, не болмаса болмайды) және контейнерлерді жұмыс кезінде қорғау. Егер осы үштік (образдар, саясаттар, runtime) есте болса, салыстыру жеңілірек.

Айырмашылық жиі басымдықтарда және құралдың қай ортада «туғанына» байланысты. Бір шешім жеткізу тізбегін бақылауда (образдарды скандеу, қол қою, базалық образдар мен реестрлерді бақылау) күшті болуы мүмкін. Басқалары бұлттық қауіпсіздік пен комплаенске кеңірек қарайды, контейнерлерді бұлттық баптаулар мен IAM-пен байланыстырады. Үшіншілері runtime-қорғанысқа және Kubernetes-та не болып жатқанын көрнекі етуде мықты: кім қайда желі бойымен барып жатыр, қандай процестер іске қосылып жатыр, қандай әрекеттер күдікті.

Сіздің контекстке қалай таңдау жасау керек

Алдымен қарапайым сұрақ қойыңыз: өндіріс қайда орналасқан және нақты шектеулер қандай — on-prem, бұлт немесе гибрид. Мемлекеттік сектор мен ірі ұйымдарда көбіне өз деректер орталығында развертывание, контурларды оқшаулау және аудитке есеп беру маңызды. Мұндай жағдайда құрал сіздің ережелеріңізді қолдауы керек, бөтен модельді ілгерілетпеуі керек.

Енгізуді жиі бұзатын төрт нәрсені алдын ала тексеріңіз:

• образ реестрімен интеграция және сіздің форматтар, тегтеу және өмірлік циклды қолдау;
• CI/CD-ге қосылу — үнемі құлауға әкелмейтін (жұмсақ порогтар, есептер, MR-ге комментарийлер);
• Kubernetes-пен интеграция (admission-қадағалау, namespace бойынша саясаттар, ерекшеліктер);
• оқиғаларды SIEM-ге шығару және SOC үшін түсінікті алерттер.

Жақсы тест — бір сервис үшін пилот: скандеуді қосыңыз, 2–3 саясат және мерзімі бар бір ерекшелік жасаңыз, содан кейін runtime қанша шу шығаратынын көріңіз. Егер on-prem немесе гибрид пилоты қажет болса, бұлты интеграторлар әдетте мұндай тапсырмаларды орындайды — мысалы, GSE.kz деңгейіндегі жобаға ұқсас.

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

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

Практикалық түрде мақсаттарды үш деңгейге бөлуге болады:

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

Кім неге жауапты

Ролдерді алдын ала тағайындау жақсы, әйтпесе бәрі "командалар арасында" болады. Әдетте мына схема жұмыс істейді:

• Dev — тәуелділіктер, базалық образ және кодтағы уязвимдіктерді түзету үшін жауапты.
• DevOps — пайплайн, реестр, CI/CD саясаты және іске қосу параметрлері үшін жауапты.
• Sec — әдістемені, талаптарды анықтайды, ерекшеліктерді мақұлдайды және тәуекелдерді бақылайды.
• Қызмет иесі — қақтығыста: релиз мерзімі ме әлде тәуекелді азайту ма деген шешімді қабылдайды.
• Операциялар — өндірісте не болып жатқанын бақылайды: алерттер, runtime-қорғаныс, инциденттер.

Релизді тежемейтін порогтар мен мерзімдер

Порог түсінікті және өлшенімді болуы керек. Мысалы: «Критикалық уязвимдіктер — 7 күнде түзетілуі тиіс, жоғары — 30 күнде, орташа — жоспар бойынша». Және релизге бөлек ереже: «Егер өзгерісте жаңа критикалық пайда болса және келісілген ерекшелік болмаса, релизге тыйым салынады».

Таластарға кетпеу үшін ережелерді бір жерде ұстап, қарапайым тілде жазыңыз:

• не тексереміз;
• қай жерде тексереміз (build, merge, deploy);
• бұзушылық болғанда не болады;
• кім ерекшелікті бере алады және қаншаға дейін.

Осы кезде Aqua, Prisma Cloud және Sysdig құралдары орындау құралына айналады, дауыс тудыратын себепке емес.

Қадамдық схема: CI/CD-де стоп-крансыз тексерулер

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

Төрт қақпа схемасы

Өндірісіне жақындаған сайын ережелер қатаң және нәтиже сенімді болады:

• Құрастыру: build-тен кейін образы сканерлеңіз — контекст жаңа, түзету арзанырақ.
• Реестрге жариялау: push алдында қайта тексеру, реестрге тек тексерілген нұсқалар түссін.
• CI-саясаттары: секреттерге, Dockerfile-дегі қауіпті нұсқауларға және критикалық CVE-ларға тез тексерулер (барлығын бірден қамырлайтынға талпынбаңыз).
• Кластерге деплой алдында: admission-тексеру саясаттары арқылы Kubernetes-ке ережелерге сай емес образдар түспесін.

"Табылды" және "тыйым салынды" дегенді бөліп көрсету маңызды. Мысалы, High CVE — ескерту болуы мүмкін, ал белгілі эксплойты бар Critical — блоктауы тиіс.

Релизді тоқтатпау үшін

CI/CD-ді стоп-кранға айналдырмас үшін бақылаудан бастаңыз және қатаңдықты жоспар бойынша арттырыңыз:

• Ескерту режимі: алғашқы 1–2 апта блоктамай, статистика жинаңыз.
• Grace period: түзетуге уақыт беріңіз (мысалы, 14 күн) және қай күні ереже блоктайтынын көрсетіңіз.
• Фича-флагтар: жаңа ережелерді бір реткі қосқыш ретінде енгізіп, жалған срабатыванияда тез өшіруге мүмкіндік беріңіз.
• Қадамды блоктаулар: ең критикалық ережелерден бастап және тек жаңа релиздерге қолданыңыз, кейін бүкіл паркті қамту.
• Тәуекел бойынша бөліну: сыртқа ашық қызметтер мен төлем контурын ертерек қатайтыңыз, ішкі сервистерді кейінге қалдырыңыз.

Осы тәсіл Aqua, Prisma Cloud немесе Sysdig-те бірдей жүзеге асады: алдымен көрініс пен ақиқат порогтары, кейін ақыры блоктау. Мысалы, GSE S200 Series серверлері бар кластерде admission тексеруді тек интернет-фронтқа қосып, команданың ережелерге үйренуін күтсе болады.

Саясаттарды қалай жазу керек, олар орындалатын болсын

Саясат — "барлығын тыйым салу" емес, командаға нақты түсінік беруі керек:

• қазір не түзету керек;
• қандай тәуекелдерді қабылдауға болады;
• бұл шешімді кім мақұлдайды.

Жақсы тест: әзірлеуші 2 минут ішінде Dockerfile немесе манифестте не өзгерту керектігін түсінуі тиіс.

Түсінікті ереже құрылымы

Әр ережеде міндетті тіркелер:

• мақсат: не қорғалады;
• ауқым: қай жерде қолданылады (бөтақ, орта, namespace, сервис түрі);
• шарт: "егер X болса, онда Y" (нақты өрістер, тегтер, баптаулар);
• порог: не блоктайды, не тек ескертеді;
• әрекет: кім және қалай түзетеді, ерекшелік қайдан сұралады.

Практика: өмір сүретін саясаттар

Образдар үшін релизді сирек бұзатын тексерулерден бастаңыз: рұқсат етілген базалық образдар тізімі, latest-ты тыйу, immutable тегтер немесе digest талап ету, образдарға қол қою. SBOM-ды алдымен маңызды сервистерге енгізген жөн.

CVE-ларды түзетуге бөлгенде оларды екіге бөліңіз: түзетілетін және түзетілуі мүмкін емес.

Түзетілетін (патч бар) — порогпен блоктауға болады, мысалы өндірісте Critical және High. Патч жоқ уязвимостьтер — «ерекшелікпен рұқсат ету» деп аударып, нақты себеп пен қайта қарау мерзімі көрсетілуі тиіс.

Kubernetes-та бастапқыдан қарапайым тәуекелдерді бастаған жөн: privileged-ті тыйу, hostPath-ты нақты тізімсіз тыйу, capabilities шектеу, root-пен іске қосуды негізсіз тыйу.

Желілік саясаттар әдетте namespace ішінде «әдепкі тыйу» және нақты allow-мен басталады: кім дерекқорға жаза алады, кім интернетке шыға алады, қандай порттар рұқсат етілген.

Минималды бастапқы жиын, әдетте әсер береді және қатты қиындық туғызбайды:

• базалық образ тек рұқсат тізімінен және latest жоқ;
• продқа образға қол қою міндетті;
• CVE бойынша блок: патч бар Critical;
• кластерде: әдепкі бойынша privileged және runAsRoot тыйылған;
• NetworkPolicy: нақты allow жоқ болса кіріс трафик тыйылады.

Ерекшеліктер ережелері: ашық және мерзімі болуы тиіс

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

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

Aqua, Prisma Cloud немесе Sysdig ішінде ерекшеліктерді бірдей іске қосу үшін қарапайым стандарт орнатыңыз. Ерекшелік карточкасында болуы тиіс:

• себеп пен негігін неге ерекшелендіріп отырғаны (CVE, пакет, образ, тег);
• иесі (нақты команда немесе адам);
• мерзім (аяқталу күні);
• өтемді шаралар (мысалы, сыртқа қолжетімділікті шектеу, құқықтарды азайту, қосылған runtime бақылау);
• жабу критерийі (ерекшелік қашан алынуы тиіс).

Мерзімі жоқ ерекшеліктерді, образ бойынша жаһандық whitelist-ті және компенсирлеусіз критикалық уязвимдіктерге берілген ерекше рұқсаттарды бірден тыйыңыз.

Ерекшеліктерді жүйелі тексеріп отырыңыз: аптасына қысқа шолу және аяқталуға 7–14 күн қалғанда автоматты еске салулар. Осылай командалар уақытында жаңартып немесе ұзартуға өтініш түсіреді.

Мысал: өндірістегі сервис нақты кітапхана бар образты қажет етеді, патч ай ішінде күтіледі. Команда бір CVE үшін тек бір репозиторий мен тегке арналған ерекшелік жасайды, аяқталу күнін қояды, шығыс трафикті шектейді және shell іске қосуды бақылайтын runtime ережесін қосады. Айдан кейін ерекшелікті жапса немесе жаңа негіздеме бере отырып ұзартады.

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

Runtime-қорғаныс: жалған срабатываниясыз қалай қосуды

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

Қауіпсіз бастау: алдымен бақылау

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

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

Әдетте қолдануға болатын минималды ережелер

Операциялық команда мен сервис иелеріне түсінікті қысқа жиыннан бастаңыз:

• prod-неймспейс үшін контейнер ішінде интерактивті шеллдерді (bash, sh) тыйу;
• қосымшаның қажеті болмаса күтпеген бинарьларды (мыс., curl, nc) іске қосуға детект қою;
• жүйелік жолдарға (мыс., /bin, /usr/bin, /etc) жазуды тыйу, тек нақты рұқсаттармен;
• сирек кездесетін сыртқа адреске немесе стандартты емес порттарға шыққан кездегі алерт;
• шетелдік директорялар монтталуын және привилегиялы режимдерді бақылау.

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

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

Енгізу барысында жиі жіберілетін қателіктер және оларды қалай болдырмау

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

Бес типтік қате:

• барлық репозиторийлер мен командалар үшін бәрін бірден блоктау. Жақсырақ — 1–2 сервиспен бастаңыз, статистика жинаңыз және кезең-кезеңімен блоктауларды енгізіңіз.
• dev, stage және prod саясаттарын араластыру. Продта қатаң талаптар мен қол қою қажет, dev-та жылдамдық пен кеңес беру маңызды.
• базалық образдарды елемеу. Нұсқаларды бекітіңіз, рұқсатты base images тізімін жүргізіңіз және оларды кестеге сай жаңартыңыз.
• сканер мәселені өз бетінше шешеді деп ойлау. Сканер тек тәуекелді көрсетеді, бірақ «кім түзетеді және қашан» деген сұраққа жауап бермейді.
• мерзімі жоқ және иесі жоқ ерекшеліктер жасау. Бұл тез тұрақты саңылауға айналады.

Не көмектеседі:

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

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

Өндірістік іске қосар алдында тез чек-лист

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

10 минутта өтуге болатын минималды сұрақтар:

• Порогтар мен мерзімдер: критикалықтік бойынша біртұтас ережелер бар ма және түзету мерзімдері белгіленген бе?
• Пайплайндағы бақылау нүктелері: образ build кезінде және деплой алдында қайта тексеріледі ме?
• Базалық образдар мен тегтер: рұқсат етілген base images бекітілген бе, latest сияқты қозғалмалы тегтер тыйылған ба, нұсқалау схемасы айқын ба?
• Ерекшеліктер: бір шаблон бар ма (себеп, иесі, сервис, тикет) және аяқталу күні міндетті ме?
• Runtime-наблюдение: кемінде бақылау режимі қосылған ба және алерттер қайға түсетіні анық па (канал, жауаптылар, жауап уақыты)?

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

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

Мысал сценарий: енгізіп, жеткізуді тоқтатпау

Команда банктік немесе мемлекеттік органға сервис жасауда. Релиздер аптасына бір рет шығады, ИБ талаптары қатаң: уязвимдіктер туралы есептер тез керек, бірақ әр CVE үшін релиз тоқтатылса болмайды.

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

Алғашқы 3–4 аптаға практикалық жоспар:

• 1-апта: CI/CD-дегі образ сканері ескерту режимінде. Есепті әзірлеушілер мен ИБ көреді, пайплайн түспейді.
• 2-апта: өндірісте патч бар Critical-ды ғана блоктау; High үшін әлі ескерту режимі.
• 3-апта: «алтын» base image келісіліп, жаңартулар кестесі жасалады, CVE жиналмау үшін.
• 4-апта: пилотта runtime-наблюдение detect-only режимінде: оқиғалар жинау және автоматты блоктаулар жоқ.

Егер базалық образтағы критикалық тез түзетілмесе, 30 күнге ерекшелік рәсімделеді: себеп, әсерленген образдар мен сервистер, өтемді шаралар (мысалы, шеллді тыйу, egress шектеу, root-пен іске қоспау), иесі және аяқталу күні.

Айдан кейін метрикаларды қарайды:

• пайплайнның орташа өту уақыты және қолмен келісімсіз релиздер үлесі;
• активті ерекшеліктер саны және мерзімі өткендері;
• қанша Critical base image жаңартуымен жабылды;
• runtime-оқиғалардың қаншасы нақты инцидент, қаншасы шу болғаны.

Көрсеткіштер жақсарса, қаттылықты арттырады: кейбір High-тарды блокқа енгізіп, runtime-ты бақылаудан нақты блоктауға ауыстырады.

Келесі қадамдар: 2–4 аптаға жоспар және кімге тапсыру

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

2–4 аптаға жоспар

Жылдам нәтиже беретін темп:

• 1-апта: реестрлерді, CI-жобаларды, кластерлерді және критикалық сервисдерді инвентаризациялау. Пилоттық сервис таңдау және иесін нақтылау.
• 2-апта: CI/CD-де есеп режимінде образ сканері. Орындалатын ережелер жиынтығы (root-пайдаланушыны тыйу, базалық меткалар, рұқсатталған base image).
• 3-апта: кей ережелерді "soft gate"-ке аудару (ескерту, бірақ блоктаусыз), мерзімі бар ерекшеліктер процесін іске қосу.
• 4-апта: пилотта минималды runtime-қорғаныс (бақылау немесе ең қауіпті әрекеттерге блоктау), 2–3 сервиске кеңейту.

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

Кімді жүктеу керек

Жауапкершілікті алдын ала бөліңіз:

• Платформа/DevOps: реестрлер, CI-агенттер, кластер саясаты.
• Қызмет командалары: Dockerfile және тәуелділіктер бойынша түзетулер, қайта құрастыру.
• ИБ: порогтар, ерекшеліктерді растау, мерзімдерді бақылау.
• Өнім иелері: не алдымен жөндеу керектігін приоритеттеу.

Егер Aqua, Prisma Cloud немесе Sysdig-ті сіздің контурға таңдап, on-prem немесе гибридта енгізу керек болса, жүйелік интегратормен жұмыс жақсы нәтиже береді. GSE.kz сияқты жобалар бұл процесті инфрақұрылым, жүйемен интеграция және 24/7 қолдаумен толықтырады.