Гибридтік инфрақұрылым: жергілікті сервистер мен бұлтты қалай байланыстыруға болады

Неліктен гибрид жиі «екі әлемге» айналып кетеді?

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

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

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

Гибрид инфрақұрылым «екі әлемге» бөлініп кетпеуі үшін мақсаттарды нақтылап алу технологияны таңдаудан бұрын пайдалы:

• бір кіру әдісі және біртұтас рөлдер моделі;
• алаңдар мен бұлт арасындағы болжамды байланыс;
• бэкап пен қалпына келтіру үшін бірдей RPO және RTO мақсаттары;
• біртұтас мониторинг және инциденттерге жауап беру ережелері.

Мақсаттар алдын ала анықталған кезде, архитектура жүйе ретінде құрылады, жеке қосулар жиынтығы емес.

Гибридтің тірек қағидалары: ең алдымен не ұқсастыру керек

Гибрид инфрақұрылым әдетте үш бөліктен тұрады: жергілікті сервистер (виртуализация, дерекқорлар, файл ресурстары, AD), бұлттық сервистер (IaaS, SaaS, басқарылатын базалар) және олардың арасындағы байланыс арналары (VPN, арнайы арналар, резервті маршруттар). Бастапқы қателік — осы бөліктерді бөлек әлем ретінде жобалап, "жапсыруды" кейінге қалдыру.

Екі деңгейді бөліп қараған жөн.

Контрольдік жазықтық (басқару) — есептік жазбалар, саясаттар, инвентарь, конфигурациялар, жаңартулар, мониторинг.

Деректер жазықтығы (трафик) — маршруттар, DNS, API-ларға қолжетімділік, репликация, бэкап.

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

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

Әдетте бірінші кезекте сәйкестендіру мен рөлдерді, атаулау мен DNS, желіні сегментациялау және қолжетімділікті, бэкапқа (RPO және RTO қоса) және біртұтас мониторинг пен журналдауды унификациялау керек.

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

Сәйкестендіру және қолжетімділік: біртұтас кіру және рөлдер

Гибрид инфрақұрылымда жиі бұзылатын нәрсе — желі емес, қолжетімділік. Адамдарда әртүрлі парольдер, әртүрлі топтар және жергілікті және бұлттық жүйелердегі әртүрлі ережелер пайда болады.

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

Біртұтас кіру (SSO) жергілікті қолданбалар мен бұлттық сервистер үшін бірдей жұмыс істеуі тиіс. Екінші міндетті қадам — MFA. Оны барлығына бірден енгізуден гөрі рөлдер мен тәуекел бойынша енгізу оңайырақ болады. Жақсы тексеру: қызметкер офис серверіндегі есеп жүйесіне де, корпоративті бұлт қосымшасына да бірдей ережелер бойынша кіруі тиіс.

Құқықтарды техникалық топтардан гөрі бизнес-рөлдер арқылы сипаттаған дұрыс. "Бухгалтерия", "Режистратура", "Жұмысқа Қызмет Көрсету Инженерлері" сияқты атаулар адамдарға түсінікті және келісімі жеңіл, APP_FIN_RW сияқты техникалық атаулардан гөрі. Техникалық топтарды ішкі қажеттіліктер үшін қалдыруға болады, бірақ келісім тілі адамға түсінікті болуы керек.

Қолжетімділіктің хаосқа айналмауы үшін есептік жазба өмірлік циклын бекітіңіз:

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

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

Желілік байланыс: өсуге шыдамды паттерндер

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

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

Масштабталатын топология

Практикада жиі үш схема жұмыс істейді:

• Hub-spoke: орталық түйін (ЦОД немесе бұлт) және филиал «спицалары». Басқару оңай, қолжетімділікті басқару айқын.
• Орталық шлюз: барлық кіріс және шығыс трафик бір саясат бойынша өтеді. Аудит пен сүзгілерге ыңғайлы.
• Mesh: әрқайсысы әрқайсысымен. Сайттар аз болғанда жарайды, кейін күрделенеді.

Егер бас кеңседе жергілікті сервер бар және филиалдар көп болса, hub-spoke өсу кезінде күтпеген жағдайларды аз береді.

Сегментация, DNS және адресация

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

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

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

Гибрид қауіпсіздігі: шектеулер, бақылау және аудит

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

Бастапқы принцип — ортааралық минималды қажетті қолжетімділік. Подсетьтерге "бәрін көруге" рұқсат бермеңіз. Рұқсаттарды әкімшілерге жеңіл болсын дегеннен гөрі қосымшалар мен олардың порттарына негіздеп жасаңыз. Егер сервиске тек дерекқор мен хабарлар кезегіне қолжетімділік керек болса, қалған бағыттар жабық болуы тиіс.

Бақылау нүктелері ережелер санына қарағанда маңыздырақ. Әдетте бірнеше «қақпа» жеткілікті:

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

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

Қолжетімділік журналдары «для галочки» үшін емес. Міндетті түрде тіркелсін: кім кірген, қайдан, қашан, қандай ресурсқа қолжеткізген, не өзгерткен және сессия қалай аяқталған. Инцидентті талдау сағаттармен емес, бірнеше сағат ішінде шешілуі тиіс.

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

Деректер мен интеграциялар: екі шындық шықпау үшін

Гибрид инфрақұрылымдағы басты тәуекел — бір көрсеткіш екі жерде сақталып, айырылып кетуі. Негізгі ереже: әр объект үшін (клиент, келісім, пациент, қойма, пайдаланушы) бір шынайы дереккөз және «алтын көшірме» орны болсын.

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

Алмасу әдісін міндет бойынша таңдаңыз. Репликация екі контурда деректерді ұқсас ұстауға жарайды. Пакеттік шығару есеп беру және сирек жаңартулар үшін ыңғайлы. Кезектер мен оқиғалар өзгерістерді жоғалтпауға және қысқа үзілістерді көтеруге көмектеседі. API-шлюз сұрау бойынша деректер қажет болғанда және біртұтас қолжетімділік ережелері мен лимиттер керек болғанда пайдалы.

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

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

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

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

Бэкап және апаттық қалпына келтіру

Гибридте бэкаптар көбіне технологиядан емес, жауапкершіліктің бөлінуінен бұзылады: жергілікті көшірмелер бір команда жасайды, бұлттық snapshot-тар — басқа команда, ал қалпына келтіру тексермесін ешкім өткізбейді. 3-2-1 ережесін бастаңыз, бірақ гибридке бейімдеңіз.

3-2-1 қарапайым нұсқасы: деректердің кемінде үш көшірмесі болсын, екі түрлі сақтау түрінде, және бір көшірме негізгі алаңнан тыс жерде болсын. Гибридте бұл әдетте былай көрінеді: күнделікті тез қалпына келтіру үшін жергілікті көшірмелер, алаң жоғалғанда бұлттағы көшірме және шифрлаушыға қарсы оқшауланған (immutable немесе ажыратылатын) көшірме.

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

• виртуалдық машиналар мен критикалық сервистер;
• дерекқорлар дұрыс режимде (журналдар, consistency);
• файл сақтау және жалпы папкалар;
• конфигурациялар: желі, фаервол, гипервизор, IaC-шаблондар;
• кілттер, сертификаттар және қосымша параметрлері.

RPO мен RTO-ны бизнес тілімен түсіндірген дұрыс. RPO — қанша деректер жоғалтуға болады (мысалы, 15 минутқа дейін). RTO — қызмет қанша уақытта қайта іске қосылуы тиіс (мысалы, 2 сағат). Егер бухгалтерия бір сағаттық тоқтаудың құны бұлттық сақтаудан қымбат екенін айтса, басымдық бірден өзгереді.

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

Біртұтас мониторинг: барлығын бір жерде көру

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

Көп командаларға базалық телеметрия жиынтығы кішкентай: маңыздысы — ол on-prem және cloud үшін бірдей жұмыс істеуі.

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

Келесі — оповещенилар ережелері. Шекті мәндер мен приоритеттер бірдей болуы тиіс: бұлттағы "P1" пен сервердегі "P1" бизнес үшін бірдей қауіп екенін білдіреді. Практикада симптом бойынша алертер орнатқан жөн (қателер өсімі, қолжетімділіктің төмендеуі), минуттық CPU секірісінен гөрі.

Дежурлар мен эскалацияларды алдын ала бекітіңіз: түнде кім жауапты, ҚС/ИБ қашан қосылады, шешім қайда жазылады (тикет, қысқа есеп, себебі және не өзгертілді).

Басқарушыға «метрикалар орманы» қажет емес. Бір экранда әдетте бес көрсеткіш жеткілікті:

• негізгі сервистердің қолжетімділігі;
• деңгейлер бойынша инциденттер саны (P1–P3);
• қалпына келтіру уақыты (MTTR);
• сәтті бэкаптардың үлесі;
• критикалық операциялар үшін кешігулер тренді.

Мысал сценарий: филиалдары бар ұйым және критикалық сервистер

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

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

Жұмыс жоспары әдетте былай көрінеді:

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

Алғашқы 2–4 апта ішінде пайдаланушылар басты өзгерісті байқайды: екі парольдің орнына бір кіру және "сізде қолжетімділік жоқ" жағдайлары азаяды. Әкімшілерге — болжамдылық келеді: құқықтар рөл арқылы беріледі, өзгерістер журналда көрініп, инфрақұрылымды қызмет көрсету біртұтас ережелер бойынша жүреді.

"Екі әлем" азайғанын көрсететін метрикалар: SSO арқылы кіретін қосымшалар үлесі, жергілікті есептік жазбалардың саны, қолжетімділік беру уақыты, инциденттің орташа қалпына келу уақыты (MTTR), мониторингтің ақауларды табу уақыты, тесттік қалпына келтірулердің сәттілігі (RTO мен RPO) критикалық жүйелер бойынша.

Тоқтап қалмастан енгізу үшін қадамдық жоспар

Инвентаризациядан бастаңыз, бірақ «солай болсын» үшін емес. Қандай сервистер критикалық, деректер қайда жатқанын, әр қолданба неге тәуелді екенін (AD, DNS, дерекқорлар, интеграциялар) және нақты қажет қолжетімділік пен қалпына келтіру уақытын анықтаңыз.

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

Темп үшін 1–2 қосымшадан пилот жасаңыз. Біріншіден бір критикалық, екіншіден маңызды емес (мысалы, бөлім үшін файл сервисі және ішкі портал). Пилотта атаулау стандарттарын, қолжетімділікті, логтауды, метрикаларды және бэкапты бекітіңіз, сонда әр көшіруде бәрін қайтадан ойлап табудың қажеті болмайды.

Одан кейін толқын бойынша жылжыңыз:

• әр толқын үшін тәуелділіктер мен табыс критерийлерін сипаттау (SLA, RTO/RPO, өзгеріс терезелері);
• пилотта «біртұтас» компоненттерді (SSO, желі, мониторинг, бэкап) шығарып, тексеру;
• үдерістерді орнату: қолжетімділік сұранысы, өзгеріс тәртібі, жауап беру және дежурство регламенттері;
• сервистерді партиямен көшіру және әр қадамнан кейін бақылау нүктелерін тексеру;
• алдын ала откат жоспарын дайындау: snapshot-тар, резервтік көшірмелер, DNS пен маршруттар қайтару жоспары және жауапты тұлғалар.

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

Гибрид архитектурадағы типтік қателіктер мен тұзақтар

Көбінесе гибрид «екі әлемге» бөлінуі бұлттың немесе темірдің кінәсі емес. Себеп — жедел шешімдер, олар кейін әдетке айналады.

Ең жиі кездесетін қателіктер, олар қолжетімділік пен қауіпсіздікке қатты соққы береді:

• Байланыс арнасын баптадың, бірақ DNS пен маршруттауды ойламадың. Нәтижесінде сервистер «пингтейді», бірақ атаулар бойынша табылмайды, таймауттар пайда болады, кейбір трафик бақылаудан айналып өтеді.
• Қолжетімділіктерді "сол күйінде" көшіріп, рөлдерді көбейткен. Адамда 3–4 есептік жазба болғанда аудит табу қиын, ал қызметкер жұмыстан шыққанда барлық орталарда қолжетімдікті жапқаныңызға кепілдік жоқ.
• Резервтік көшірмелерді сол тәуекел аймағында ұстайды. Егер бэкап сол ЦОД-та немесе сол желіде болса, өрт, шифрлаушы немесе әкімшінің қатесі өндірістік жүйемен бірге көшірмелерді жоя алады.
• Бұлт пен жергілікті бөлікті әртүрлі командалар әртүрлі ережелермен мониторингілейді. Инцидент «біздікі емес» деп басталады, бірақ негізі көбінесе стыкта: DNS, сертификаттар, маршруттар, лимиттер.
• Критикалық деректерді өте ерте көшіріп, қалпына келтіруді тексермеген. Миграцияны қайтарудың жоқтығын тексермей көшіру дайындықтың жалған сезімін береді.

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

Желілік және DNS атауларын, рөл модельдерін, бэкаптардың бөлек өңірде сақталуын және алертер стандартын критикалық жүйелерді көшіру алдында бекіту жақсы тәжірибе.

Қысқа чек-лист: іске қоспас бұрын не тексеру керек

Ингредиенттерге бір үзіліс жасап, негізгі нәрселерді тексеріңіз. Бұл бюрократия емес: көбіне түнгі инциденттер мен дауласқан қолжетімділіктердің себептері осында жасырылады.

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

Іске қоспас бұрын қысқаша тексерулер:

• бір каталог және түсінікті рөлдер: "пайдаланушы", "оператор", "әкімші" және бұл қайда бекітілген;
• әкімшілер мен барлық критикалық жүйелерге кем дегенде MFA қосылған (тек бұлтта емес, on-prem үшін де);
• адресация жоспары мен желі сегментациясы рәсімделген: подсетьтер, зоналар, маршруттар, сегменттер арасындағы рұқсаттар;
• біртұтас алертер мен журналдау: кіру оқиғалары, қолжетімділіктен бас тарту және құқық өзгерістері бір жерде жиналады және жауапты бар;
• бэкап пен қалпына келтіру: қалпына келтіру нақты тексерілген және нәтижелері мен қалпына келтіру уақыты бекітілген.

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

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