Контейнерлерге Cosign арқылы қол қою: қабылдау саясаты және CI/CD

Неліктен контейнер образдарына қол қою керек

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

Уязвимділіктерді сканерлеу пайдалы, бірақ ол басқа сұраққа жауап береді: «компоненттерде белгілі осалдықтар бар ма?». Ол образдың шынымен сіздің командаңыз жинағаны мен жолда ауыстырылмағанын дәлелдемейді. Зиянды образ CVE-ге сәйкес «таза» болуы мүмкін, бірақ оны шабуылшы жинаған болар. Сондықтан образға қол қою (Cosign және ұқсас механизмдер) шығу тегін және тұтастықты тексеру ретінде қажет.

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

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

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

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

Қарапайым тілмен: қолтаңба, digest және аттестациялар

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

Негізгі терминдер артық теориясыз

• Образ (image): контейнерде іске қосылатын қосымша мен тәуелділіктері бар қабаттар жиынтығы.
• Манифест: образдың «мазмұнының тізімі» — қандай қабаттар кіретіні, қандай платформалар қолдау табатыны, метадеректер.
• Digest: манифест мазмұнының хэші (мысалы, sha256). Бір байт өзгерсе, digest өзгереді.
• Тег (tag): app:1.2 немесе app:latest сияқты ыңғайлы атау. Тег реестрде басқа образға қайта тағайындалуы мүмкін.

Түйінді ой: digest дерлік өзгермейтін, ал тег өзгермелі. Сондықтан қауіпсіздік саясаттары әдетте тегке емес, digest-ке сүйенеді.

Қолтаңба vs хэш: не нәрсені қорғайды

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

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

Аттестациялар: қолтаңбадан басқа не растала алады

«Образ қол қойылды» дегеннен басқа қосымша дәлелдерді (аттестацияларды) тексеруге болады. Мысалы:

• образ сіздің CI-де жинағанын, ноутбукта қолмен емес екенін;
• уязвимділіктер сканері қабылданған нәтиже бергенін;
• қолданылған базалық ОС немесе базалық образ нақты біреу болғанын;
• жинауда қажет параметрлер қолданылғанын (мысалы, privileged нұсқаулар тыйым салынған).

Қабылдау саясатына байланысты байланыс қарапайым: Kubernetes-те admission control «кіру күзетшісі» болады. Ол Pod іске қосуға рұқсат ету не жоқ па соны шешеді, қолтаңба мен аттестацияларды тексереді. Егер тексеріс өтпесе, образ іске қосылмайды.

Cosign және Notary v2: айырмашылығы және қайсысы қашан жарамды

Cosign пен Notary v2 контейнер образдарының ауысуын болдырмауға көмектеседі, бірақ әрқайсысы әртүрлі тәсілмен және әртүрлі фокуспен жұмыс істейді. Түсініксіз таңдауда екі түрлі сенім схемасы шығып, кейін оны ешкім түсінбей қалуы мүмкін.

Cosign практикалық идеядан пайда болды: нақты digest-ке қол қою және қолтаңбаны реестрдің қасында сақтау. Әдетте оған аттестациялар да қосылады (образ қалай жиналғаны, қандай тексерістерден өткендігі). Сондықтан Cosign көбіне CI/CD-ге оңай енеді: жинадыңыз, тексердіңіз, қол қойдыңыз, әрі қарай тек қойылған образ ғана деплойланады.

Notary v2 реестрлерге арналған сенім стандартын құру ретінде ойластырылған: артефактілерді (қолтаңбалар мен метадеректерді қоса) OCI форматында жариялау, сонда әртүрлі құралдар бірдей түсінеді. Практикада бұл көбіне реестр мен экожүйе жағында стандарттау мен қолдауға қатысты.

Таңдау бойынша бағдар:

• Жылдам жұмыс істейтін CI/CD қалқандарын орнатқымыз келсе және digest-ке байланысты қол қою керек болса — Cosign таңдаңыз.
• Егер стандарттау маңызды және реестр/платформа компоненттерінің қолдауы керек болса — Notary v2 қараңыз.
• Егер Kubernetes бар болса, Cosign-пен бастау оңайырақ: оны admission control және қабылдау ережелеріне байлау жиі жеңілірек.

Ең бастысы — әдістерді жоспарсыз араластырмау. Қате мысал: кейбір командалар Cosign арқылы қол қояды, басқалары Notary стилінде метадеректер жариялайды, ал кластер тек бір тәсілді тексеретіндей бапталған.

Алаңдамау үшін алдын ала анықтаңыз:

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

Сенім моделі: кім қол қояды және кім тексереді

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

Қол қойған сенімді тарап әдетте ноутбуктағы әзірлеуші емес. Ең сенімді нұсқа — CI, ол репозиторийден образ жинайды, тест пен скан жүргізеді де содан кейін артефактіні қол қояды. Осылайша біреу кездейсоқ немесе белгісіз орыннан алынған сборканы қол қойған тәуекел азаяды. Cosign енгізсеңіз, алдын ала «релиз иесі» кім болатынын шешіңіз: платформа командасы, релиз-инженер немесе CI қызметтік аккаунты.

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

Тексеретін тарап — минимум екі нүкте. Біріншісі — CI/CD: тест немесе стейджке орналастыру кезінде «шеткі» образды тежеген жөн. Екіншісі — кластер арқылы admission control: продқа ештеңе саясатқа сай өтпесе, ол жолдан бас тарта алады.

«Прод» неге тең екенін келісіңіз. Әдетте бұл нақты реестрлер мен репозиторийлер, registry ішіндегі бөлек жобалар және нақты қағида: продқа тек digest бойынша образдар ғана рұқсат етіледі, тег бойынша емес.

Қол қою орындалуы тиіс нәрсе — «Dockerfile папкасын» емес, нақты нәтиже:

• digest бойынша образ (нақты іске қосылатын нәрсе);
• жинау аттестациялары (кім және қалай жинағаны);
• SBOM немесе құрам туралы негізгі белгі (егер қолданатын болсаңыз);
• рұқсат етілген көз (қай registry және қай репозиторий).

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

Қадам-қадам: команданың ішінде қол қоюды енгізу

Бастапқыда қарапайым ереже енгізіңіз: қол қою қалыпты сборка бөлігі, ал тексеру қалыпты деплой бөлігі болсын. Осындайда бұл «қосымша қауіпсіздік» емес, сапа стандартына айналады.

Алдымен неге қол қойғыңыз келетінін және қолтаңба арқылы нені дәлелдегіңіз келетінін келісіп алыңыз. Көп командалар үшін Cosign GitHub Actions, GitLab CI және басқа пайплайндарға оңай кіреді. Notary v2 реестрге және әртүрлі артефактілер үшін біркелкі саясатқа ауыр басымдық бергенде таңдалуы мүмкін.

Жұмыс тәртібі, әдетте процесті бұзбайтын түрде:

• Форматты анықтаңыз: тек образға қол қою ма, әлде қол қою мен аттестациялар (мысалы, SBOM, кім жинаған, қандай тесттер өткені) бірге ме.
• Кілт модельін таңдаңыз: дәстүрлі кілттер (қайда сақталатыны) немесе OIDC арқылы keyless, ұзақ өмір сүретін құпиясыз.
• Ереже бекітіңіз: тек digest бойынша қол қоямыз, тег бойынша емес. Тег адамдарға ыңғайлы, бірақ digest нақты байт-байт сәйкестігін бекітеді.
• Аттестацияларды бөлек міндетті артефакт ретінде қосыңыз: «CI-де келесі коммиттен жинаған», «сканерлеуден өтті», «осы базалық образ қолданылды».
• Міндеттілік матрицасын жасаңыз: қай репозиторийлер мен ортада қол қою міндетті (prod), қай жерде ерекшеліктер мүмкін (dev), және оларды кім бекітеді.

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

Осы қадамда күрделендірмеңіз. Алдымен 1–2 критикалық сервиске қол қоюды міндеттеп, кілттерді сақтау мен digest бойынша релизді сынап көріңіз, содан кейін ғана ережені барлық образдарға кеңейтіңіз.

CI/CD-де тексеру: қақпаларды қайда қою және не логтау керек

Қолтаңба артефакт сенімге лайық болған кезде пайда болуы тиіс. Әдетте бұл жинау мен тесттен кейін, бірақ образ «шақпадан» әрі қарай бармас бұрын. Осылайша сіз идеяны емес, нақты нәтижені — бір digest, бір кіріс жиынтығы, бір нұсқаны қол қоясыз.

Ыңғайлы схема:

• Образ жинау және тесттерді іске қосу.
• Уязвимділіктерді сканерлеу және базалық тексерістер (мысалы, root тыйым, минималды базалық образдар).
• Аттестациялар құру (не тексерілгені және қалай тексерілгені).
• Образға қол қою және реестрге жариялау.
• Деплой алдында бөлек қадам: қолтаңба мен аттестацияларды міндетті «қақпа» ретінде тексеру.

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

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

Логтар мен артефакттар тек әсемдік үшін емес, талдаулар үшін қажет. Сақтаңыз:

• образ digest, тег және нақты жариялау уақыты;
• сборка идентификаторы (pipeline run), коммит және өзгертулер авторы;
• қолтаңба тексерісінің нәтижесі және тексерілген аттестациялар тізімі;
• кілттердің нұсқасы немесе сенімді қолтаңба иесінің идентификаторы;
• қабылданбаудың себебі қысқа әрі оқылатын мәтін түрінде.

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

Kubernetes-те қабылдау саясаты: қолтаңбасы жоқтарды блоктау

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

Прод үшін практикалық минимум: тек келесі шартқа сай образдарды іске қосуға рұқсат ету — (1) қол қойылған және (2) digest-пен бекітілген, тегпен емес. latest немесе release сияқты тегтер оңай қайта жазылуы мүмкін, ал digest әрқашан нақты деректер жиынтығын көрсетеді. Сондықтан саясат көбіне екі ережеге келеді: «тегтерге тыйым салынады» және «қолтаңба міндетті». Cosign қолдансаңыз, бұл әдетте публичді кілтпен немесе қолтаңба иесінің идентичностарына сәйкес қолтаңбаны тексеруге айналады.

Дамуды бұзбау үшін ережелерді ортаға бөліп қойыңыз:

• dev: аудит режимі (қолтаңба жоқтарды рұқсат етіледі, бірақ журналда жазылады);
• stage: тэгтерді тыйу, критикалық namespace-терде қолтаңбаны талап ету;
• prod: қолтаңбасы жоқтарды және digest-пен бекітілмегендерді толық блоктау.

Басқа мәселе — базалық образдар. Команда жиі оларды публичді реестрлерден тартады, онда қолтаңба әр түрлі немесе мүлде жоқ болуы мүмкін. Практикалық шешім: сенімді базалық образдар тізімін жасап, оларды ішкі реестрге зеркалдап қойыңыз; сол жерде digest-ті бақылап, сканерлеп, қажет болса «бекітілген» ретінде қол қойыңыз.

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

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

Осылайша admission «сақшыдан» аудитке айналады: тек блоктау фактісі ғана емес, себебі де көрсетіледі, әрі оны түзету оңайырақ болады.

Енгізуде жиі кездесетін қателіктер мен тұзақтар

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

Типтік айналу жолы — тег бойынша деплой. Тег қайта жазыла алады, сондықтан жаңа бинарь ескі атаумен жүре береді. Егер қабылдау саясаты digest талап етпесе, шабуылшы (немесе жай ғана абайсыз инженер) тегті ауыстырып қоя алады. Тексерістердің дұрыс бағыты — digest және сол digest-ке байланысқан қолтаңба.

Тағы бір тұзақ — қолмен жасалған деплойлар мен «уақытша» тексерулерді өшіру. Қауіп шұғыл болса, адамдар қысқа жолға түседі: ноутбуктан kubectl apply, жеке репозиторийден образ, ал кластер жағында тексеру тек CI-де қалады. Егер кластерде admission control болмаса, бұл қысқа жол тұрақты жолға айналады.

Әдетте жүйені бұзатын бірнеше қатенің үйлесімі:

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

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

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

Ерекшеліктерді қалай құжаттап, бақылауды жоғалтпау

Қатты саясат болса да ерекшеліктер қажет болады: инцидент кезінде тез қайтару, лездік емес л legacy сервис немесе вендордан келетін образтар. Мәселе ерекшелік әдетке айналғанда басталады.

Ерекше жағдайды Cosign немесе Notary v2-ге кедергі болмайтындай «кішкентай келісім» ретінде рәсімдеңіз. Жазбада не рұқсат етілгені және неге рұқсат етілгені айқын болуы тиіс.

Аудиттен өтуге жарайтын минималды шаблон:

• Себеп: не болды және неліктен ережемен тез түзетпейсіз.
• Иесі: ерекшелікті жабуға жауапты нақты адам немесе команда.
• Мерзімі: аяқталу күні және ұзарту шарттары.
• Қауіп бағасы: образ ауысса немесе осалдық пайда болса, не болуы мүмкін.
• Өтемді шаралар: қазір қол қою орнына не істеп жатырсыз.

Ерекшеліктің радиусын тар етіп шектеңіз. «Репозиторий үшін» деген жалпылама рұқсат бермеңіз: тек нақты digest-ке, бір namespace-ке, бір service account-қа ғана рұқсат беріңіз. Ондайда қатемен де зиян аз болады.

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

Жазбаларды тексеруге ыңғайлы жерде сақтаңыз: талқылауы бар тикет, қабылдау саясаты бар репозиторийдегі коммит, және admission controller логтары (кім, қашан және қай образ ерекше ретінде рұқсат еткенін көрсету). Мысалы: жұмада сыртқы мониторинг агентінің қолтаңбасы жоқ образын тек observability namespace-інде 7 күнге және тек нақты digest-ке рұқсат етіп қойдық, сканерлеуден өткізіп, құпияларға қолжетімділігін шектедік.

Қысқа өмірлік сценарий: образ ауыстыру қалай ұсталады

Команда payments:release тегімен жаңарту шығарады. Сол күні реестрдің образ базасы жаңартылады: біреу образды қайта жинап, тегті қайта жазып қояды «жылдам түзету үшін». Формалды бәрі қалыпты: тег сол, пайплайн жасыл, деплой өтті.

Кейін продта күтпеген қосымша желілік шақырулар мен қателер пайда болады. Талдау көрсетеді: payments:release тегінің digest-бі өзгерген, яғни басқа образ. Бұл жай процесс қатесі болуы да мүмкін, реестрге кіру кеңірек болғандықтан орын алған ауыстыру да болуы ықтимал.

Не дұрыс болмады: команда тегтерге сенді және қолтаңба тексермеді. Пайплайн образды жинап, пуш жасады, бірақ digest-ті «бірден шындық» ретінде тіркемеді. Kubernetes манифестте көрсетілгенді қабылдады.

Оны қалай тоқтатуға болады: CI жинау кезінде дәл сол digest-ке Cosign арқылы қол қоюы керек, одан кейін екі «қақпа». Біріншісі — CI: деплойға рұқсат тек қолтаңба табылған және валид болса ғана беріледі. Екіншісі — продта admission control: қол қойған сенімсіз идентичность немесе рұқсат етілмеген образ болса, іске қосуды блоктайды.

Егер шұғыл ерекшелік қажет болса, қауіпті кеңейтпей жасауға болады:

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

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

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

Бастау үшін шексіз талқылауларсыз жылдам қабылданатын минималды ережелерге келіңіз. Олар кез келген әзірлеушіге түсінікті және автоматты түрде тексерілетін болуы тиіс.

Бастапқы минималды ережелер

• Реестрге тек қол қойылған және бекітілген digest-і бар образдарды жариялау.
• Релиз алдында тексеру: сборка көзі (қай репозиторий және пайплайн), қолтаңба құқығы (кім қол қоя алады) және тегпен digest сәйкестігі.
• Кілттер мен құқықтарды кодтан бөлек сақтау: рөлдер бойынша қолжетімділік, қол қою құқығы бар адамдар саны аз, жоспарлы ротация.
• CI/CD-де «қақпалар»: қолтаңба немесе digest тексерісі өтпесе, релиз жалғаспайды; логтарда кім, не және қандай құралмен қол қойғаны сақталады.
• Kubernetes-та admission control қосып, қолтаңбасы жоқ образдарды блоктау (немесе кластерлерде алдымен audit режиміне қойып, кейін enforce-ке көшу).

Содан кейін ерекшеліктер мен «уақытша» айналып өтулерге бақылауды жоғалтпау маңызды.

Жиі бақылау (аптасына бір рет)

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

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

Егер практикалық көмек керек болса (қабылдау саясаты, CI/CD және Kubernetes тексерісін интеграциялау, реестрмен жұмыс және қолдау), бұл жұмысты GSE.kz (gse.kz) сияқты жүйелік интегратор арқылы бірге орындауға болады: осылай ережелер қағаздан жұмыс істейтін процестерге жылдамырақ айналады.