Terraform пен Pulumi: қауіпсіздік пен орталарды бөлу үшін IaC таңдау

Неліктен IaC таңдау ИБ мен өзгерістерді басқаруға келеді

Infrastructure as Code әдетте «әдемі код үшін» емес, уақыт өте инфрақұрылым өзгерістері хаосқа айналғандықтан енгізіледі. Біреу сервердегі параметрді қолмен өзгертеді, біреу желідегі ережені құжаттамайды — жүйе «қалайы» істейді де, алғашқы ақау немесе тексеріс жеткенше тыныш тұрады.

Сол сәтте түсінікті болады: мәселе синтаксисте емес, басқаруда. Өзгерістерді қалай қауіпсіз енгізуге және бәрі ережеге сай жасалғанын қалай дәлелдеуге болады. Сондықтан Terraform vs Pulumi салыстыруы көбіне ИБ талаптары, аудит пен келісімдер ағымына келіп тіреледі, қай тіл немесе формат ыңғайлырақ екенінен гөрі.

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

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

Көп жағдайда таңдау Terraform (немесе оның форкі OpenTofu) пен Pulumi арасында болады. Әрі қарай маңыздысы — «бұл сіздің контурларға, рөлдерге, ревьюге, state сақтауға және есеп беру талаптарына қалай сай келеді».

Таңдау алдында бекітуге тұратын ИБ талаптары

"Terraform vs Pulumi" дауы көбіне тым ерте басталады. Алдымен өзгерістер процесіне қатысты ИБ талаптарын келісу пайдалы. Сонда құралды таңдау техникалық мәселе сияқты шешіледі, саяси күрес емес.

Минималды жиын әдетте мыналарды қамтиды:

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

Егер бұл талаптар алдын ала бекітілмесе, IaC тез арада скрипттер жиынына айналып, бақылаудағы процесс болмай қалады.

Қай жерде бақылау нүктелері керек

Алдын ала анықтаңыз, өзгеріс қай жерде "тоқтап" ревью күтеді. Практикалық базалық контур келесідей:

• Plan: қолданар алдында не өзгеретіні түсінікті тізім бар ма;
• Ревью: жоба кімге тексерілуі керек және қандай критерийлер бойынша;
• Применение: apply-ды кім қай ортада іске қосуға құқылы;
• Откат: откат есептелінеді және оны кім іске қосады.

Бұл контур бұлтта да, on-prem инфрақұрылымда да маңызды (мысалы, дата-орталықтағы серверлер мен жұмыс станциялары), себебі тәуекел бірдей: бақылаусыз өзгерістер.

"Администратор атынан" жасалған өзгерістер неге қауіпті

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

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

Terraform және OpenTofu — қарапайым тілмен: не береді

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

Қарапайым процесс екі қадам айналасында тұр. Алдымен plan жасайсыз: құрал не өзгеретінін, не құрылатынын және не жойылатынын көрсетеді. Сосын apply: өзгерістер қолданылады. ИБ үшін plan-ды міндетті ревью кезеңі ету және apply тек контролденген орыннан (мысалы, CI/CD-тен) орындау ыңғайлы.

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

Terraform/OpenTofu-ның қосымша мәні — модульдер мен реестрлер. Модуль — қайта пайдаланылатын шаблон (мысалы, "типтік сервер", "VPC/желісі", "IAM ролдерінің жиынтығы"). Команда модульдерді стандарттағанда, қол еңбегі азаяды, ал қателіктер саны да кемиді: жүздеген жолды әр жолы жазудың орнына тексерілген жинақты қолданасыз.

Қатерлер көбіне құралдың өзінде емес, оның айналасында болады. Негізгі мәселелер — провайдерлер (олар нақты өзгерістерді орындайды), "жылжымалы" нұсқалар (құралдар, провайдерлер, модульдер) және командалық әдеттер (plan-ды айналып өту, ревью болмауы, apply-қа кең құқықтар).

Сондықтан "Terraform vs Pulumi" дауы көбіне: нұсқаларға, модульдерге және plan/review/apply процесіне тәртіп орнатуға дайынсыз ба деген сұраққа келіп тіреледі. Егер дайын болсаңыз, Terraform/OpenTofu ИБ талаптары мен аудитқа оңай байланатын түсінікті негіз береді.

Pulumi қарапайым тілмен: тәсілі неде өзгеше

Pulumi-ды жиі "инфрақұрылымды кәдімгі код ретінде" сипаттайды. Яғни бұлтты, желілерді, кластерлер мен рұқсаттарды бөлек DSL емес, таныс программалау тілінде (мысалы, TypeScript, Python, Go, C#) сипаттайсыз. Команда үшін бұл тек синтаксисті өзгертпей, привычкаларды да өзгертеді: IaC қосымшалармен қатар, сол репозиторийлерде және сол практикалармен өмір сүреді.

Pulumi-дың негізгі ерекшелігі — ол дамудың әдістеріне көбірек сүйенеді. Бұл инженерлік мәдениет дамыған жерде икемділікті береді.

"Кәдімгі код" командаға не береді

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

ИБ және өзгерістерді басқарудағы тәуекелдер

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

Сондықтан ИБ үшін маңыздысы құрал емес, оның айналасындағы ережелер: міндетті ревью, ноутбуктерден тікелей қолдануға тыйым салу, CI/CD-де саясаттарды тексеру, тәуелділіктердің бекітілген нұсқаларын қолдану.

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

dev, test, prod орталарын бөлу: практикалық нұсқалар

Dev, test және prod-ты бөлу тәртіп үшін емес, тәуекелдерді басқару үшін қажет. Dev-те өзгерістер жиі және кейде қатты болады. Prod-та қателік қымбатқа түседі: сервистің істен шығуы, мәліметтердің ағуы, ИБ регламенттерінің бұзылуы. Сондықтан орталардың құқықтары, өзгерістер қарқыны және бақылау деңгейі әр түрлі болуы керек.

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

Terraform/OpenTofu және Pulumi үшін бірдей қолданылатын практикалық схемалар:

• dev, test, prod үшін бөлек аккаунттар/жазылымдар және әр орта үшін жеке CI-пайплайндар;
• бір аккаунт ішінде бөлек жобалар немесе ресурс топтары, бірақ қатал саясаттар және «өз аймағынан тыс» ресурс жасауға тыйым салынуы;
• әр ортаға (және әр ірі компонентке) бөлек state, сонда dev орта жалпы state арқылы prod-ты зақымдай алмайды.

Dev пен prod араласпасын қамтамасыз етуге қарапайым гигиена ережелері көмектеседі: бірдей каталог құрылымы, атауларға префикстер (мысалы, prd-, tst-), орта мен иесіне арналған тегтер, және prod-қа қолмен өзгертулерге тыйым салу. Егер ұйым аудиттен өтсе (мысалы, мемлекеттік сектор немесе қаржы), бұл ережелерді стандартқа енгізіп, автоматты түрде тексерген дұрыс.

Қолжетімділікті "prod-та аз құқық" принципі бойынша ұйымдастыру ыңғайлы: әзірлеушілер dev-те өзгерістер енгізе алады, test-те — сұрау бойынша, ал prod-та — тек ревьюден кейін және жеке роль арқылы. Минималды рөлдер: dev-те apply рұқсаты бар, prod-қа қатысы жоқ; test үшін оператор — келісім бойынша қолданады; prod-операторы — тек CI арқылы және мақұлдаудан кейін қолданады; және ИБ, аудит пен жүйе иелері үшін тек оқу құқықтары.

Осылайша dev/test/prod бөлінісі жауапкершілік шекаралары, сөз жүзіндегі келісім емес, анық ережелер болады.

Өзгерістерге құқықтарды бақылау: рөлдер, ревью және саясаттар

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

Көп жағдайда төрт роль жеткілікті: автор (код пен негіздемені дайындайды), ревьюер (қауіпсіздік пен стандарттарға сай екенін тексереді), оператор (керекті контурда plan және apply орындайды) және аудитор (кім не істегенін және не үшін істегенін журнал арқылы қарайды).

Негізгі қағида: apply құқықтары әзірлеу құқықтарынан бөлек болуы керек. Автор тармақтар мен pull request жасай алады, бірақ test және әсіресе prod-та қолдануға арналған кілттер/токендерге қолжеткізуі болмауы тиіс. Бұл тәуекелді азайтады және тергеуді жеңілдетеді.

Pull request арқылы процесс

Жақсы базалық схема pull request және міндетті тексерулер төңірегінде құрылады. Тексеру қағаз жүзінде емес, техникалық тұрғыдан міндетті болуы керек:

• міндетті ревью ( кемінде 1-2 адам) және негізгі бұтаққа тікелей пушқа тыйым;
• CI-де автоматты plan/preview және оның нәтижесін артефакт ретінде сақтау;
• prod үшін бөлек қолмен растау қадамы;
• журналдар: кім мақұлдаған, кім қолданған және қандай plan қолданылғаны.

Саясаттар мен шектеулер

Саясаттар қауіпті конфигурацияларды қолданар алдында блоктауға көмектеседі. Типтік ережелер: әдепкі бойынша публичті IP-лерге тыйым, әкімшілік порттар үшін ашық security group-тарға тыйым (0.0.0.0/0), аймақтар мен ресурс типтерін шектеу, диск шифрлауды талап ету және есепке алу үшін міндетті тегтер.

Рұқсат талаптары қатаң ұйымдарда саясаттарды код ретінде бекіту ыңғайлы. Сол кезде Terraform/OpenTofu немесе Pulumi қолданылса да — ережелер бірдей жұмыс істеп, әр PR-да автоматты түрде тексеріледі.

State пен құпиялар: тәуекелдер қайда жиі жасырынады

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

State сақтау орны және негізгі талаптар

Басты ереже: state қашықтағы, қолжетімділікті бақылаумен және журналданумен сақталуы керек. Дамуыштың ноутбугіндегі локальды файл — жиі ақпарат ағуы мен бақылаудың жоғалуына себепші.

Негізгі сұрақтарды тексеріңіз: state-ті кім оқи алады және кім өзгерте алады; шифрлау қосылған ба; apply кезінде бір уақытта екі адам өзгерістер жасамауы үшін құлыптау бар ма; резервтік көшірмелер қалай жасалады және қалпына келтіру қаншалықты тез орындалады.

Мысалы: команда dev/test/prod контурын серверлердегі кластер үшін орнатады. Егер prod state dev-тің жанында және сол адамдарға ашық болса, бір құқық қатесі prod-тағы өзгерістерге жол ашады.

Құпиялар: кодта емес және мүмкіндігінше state-те де емес

Құпияларды (құпия сөздер, токендер, кілттер) репозиторийде сақтауға болмайды. Бірақ маңыздысы — құпиялар көбіне ресурстар параметрі арқылы state-ке "кездейсоқ" түседі. Terraform/OpenTofu мен Pulumi-де де бұл ықтимал.

Реалды тәуекелді азайтатын шаралар:

• dev/test/prod үшін бөлек есептік жазбалар мен кілттер;
• IaC үшін минималды құқықтар (тек қажетті әрекеттер);
• state-ті сақтау кезінде және тасымалдауда шифрлау және оқуды шектеу;
• әсіресе prod-та кілттер мен токендерді үнемі айналдыру (rotation);
• CI-де құпиялардың конфигурация файлдарына немесе айнымалыларға түсуін тексеруді ұйымдастыру.

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

Қадам-қадам: құралды қалай таңдап, процесс бұзылмауын қамтамасыз ету

Көбіне IaC таңдау Terraform vs Pulumi-дан емес, өзгерістер процесі сипатталмағандықтан құрылады. Алдымен ережелерді келісіп алыңыз, содан кейін құралдарды ыңғайлылығы бойынша салыстырыңыз.

Бастапқыда 1-2 беттен тұратын қысқа құжат жасаңыз. ИБ және эксплуатация талаптарын бекітіңіз: қай жерде apply жасауға болады, қандай журналдар мен артефактілер сақталуы тиіс және қанша уақытқа, кім өзгерістерді мақұлдайды, қандай тыйымдар бар (мысалы, публичті IP немесе ашық порттар болмауы).

Содан кейін орталар мен ресурстардың иелігін анықтаңыз. Қате жиі dev/test/prod "как получится" күйінде болғанда пайда болады және кейін кім не үшін желіні немесе қолжетімділік саясаттарын өзгертті деп дәлелдеу мүмкін болмай қалады. Алдын ала шешіңіз: бөлек аккаунттар немесе жобалар, бөлек state, бөлек кілттер және әр қабаттың (желi, есептеу, дерекқор, мониторинг) иесі кім.

Практикалық іс-қимыл тәртібі:

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

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

Финалдық тексеріс: командаға жаңа адам келгенде құрылымды түсініп, қауіпсіз түрде ревью арқылы өзгеріс енгізіп, prod-ты кездейсоқ зақымдамауы тиіс.

Мысал сценариі: үш контурлы ұйым және міндетті аудит

Елестетіңіз: ұйымда dev, test және prod бар. Ішкі ережелер өзгерістерге жергілікті бақылау талап етеді, ал аудит көрсетулері тиіс: кім бастады, кім мақұлдады, нақты не өзгерген және қашан production-ға түскен. Қосымша талап — бұлт немесе виртуализацияға тікелей әзірлеушілерге қолжеткізу таратылмауы керек.

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

Өзгерістер ағыны қалай көрінеді

Көбінесе келесі схема жұмыс істейді:

• өзгеріс туралы сұрау: мақсаты, тәуекелі және откат жоспары сипатталған;
• IaC репозиторийге PR және эксплуатация мен ИБ-тан ревью аламыз;
• CI-де автотексерулер: формат, линтер, plan/preview және сақталған есеп;
• apply тек CI-ден қолмен растау арқылы және тек тиісті контурға жүзеге асады;
• қолдану есебі сақталып, сұрауға байланыстырылады — аудит үшін толық тізбек қалады.

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

IaC енгізуде типтік қателіктер

Ең жиі қате — Terraform немесе Pulumi кодын жазуды бастау, бірақ ережелерді келісуді кейінге қалдыру: кім инфрақұрылымды өзгерте алады, ревью қалай өтеді, "қолдану" деп не есептеледі, state қайда сақталады және оны кім көреді — бұлар анықталмаған. Одан кейін осы талаптарды енгізу қиынға түсіп, команда шаршайды.

Екінші мәселе — орталардың араластыруы. Dev, test және prod бір state немесе бір есептік деректер жиынтығында болғанда кез келген қателік инцидентке айналады. Бұл аудит талаптары бар жерде өте қауіпті: продтағы өзгерістер бақылаулы түрде жасалғанын дәлелдеу қиын.

Құпиялармен байланысты қателіктер жиі кездеседі: парольдар, токендер, кілттер репозиторийде, CI айнымалыларында немесе tfvars файлдарында қалады. Тіпті жеке репозиторий болса да, бұл тәуекел — құпиялар көшіріледі, журналдар мен тарихта қалады.

Тағы бір сынып қатенің себебі — "жылжымалы" нұсқалар. Провайдерлер, модульдер мен тәуелділіктердің нұсқаларын бекітпесеңіз, бір және сол код әр түрлі машиналарда немесе әр уақытта әр түрлі plan береді. "Terraform vs Pulumi" дауысында бұл жиі ұмытылатын жайт: мәселе құралда емес, нұсқаларды басқаруда.

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

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

Жұмысты бастамас бұрын чек-лист пен келесі қадамдар

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

Бастау алдындағы дайындық чек-листі:

• dev, test, prod оқшауланған (аккаунттар, жазылымдар, жобалар немесе ең болмағанда бөлек state және желілер);
• prod-қа тікелей apply шектелген: тек CI/CD арқылы, ролдер бойынша және міндетті ревью;
• аудит қосылған: әрекеттер журналдары, plan мен apply тарихы, "кім және не үшін өзгертті" деген анық із;
• құпиялар қорғалған: репозиторийде пароль жоқ, ротация және қолжетімділікті бақылау бар;
• откат жоспары бар: бұрынғы конфигурацияны қалай тез қайтарып алуға болады және оны кім жасайды.

Одан кейін эксплуатацияның дайын екеніне көз жеткізіңіз. Кім дежурейді, егер 02:00-де релизтен кейін сервис құлап қалса? Runbook қайда, диагностика мен қалпына келтірудің қарапайым қадамдары жазылған ба? IaC өзгерісі себепті екенін қалай анықтайсыз? Мұндай жауаптар іске қосар алдында бекітілуі тиіс.

1–2 айдан кейін табыс көбіне мына белгілер бойынша көрінеді: консольде қолмен түзетулер азайды және өзгерістер код арқылы өтеді; инфрақұрылым релиздері уақыт пен нәтиже жағынан болжамды болды; кез келген өзгеріс тарих арқылы түсіндірілетін және қайта жасалатын болды; конфигурациядан шыққан ақаулар саны азайды.

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

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