Гибрид ұйымға арналған SSO: Okta, Entra және Ping қалай таңдау керек

Гибрид ұйымдағы SSO міндеттері қарапайым тілмен

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

SSO жоқ кезде әдетте проблема технологияда емес, тәртіпте болады. Қызметкерде бірнеше парольдер, есептік жазбалар дубликациясы және «нақты қажет болмағандықтан» сақталған артық құқықтар пайда болады. Нәтижесінде қолдау қызметіне өтініштер көбейеді, инциденттерді тексеру қиынға соғады, және былтырғы атқарушы әлі де бір сервиске кіріп кетуі мүмкін деген тәуекел өседі.

SSO әдетте бірнеше мақсатты шешеді:

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

Гибрид ортада көбіне бір «негіз» болады: локальды каталог (көп жағдайда Active Directory), бұлттық сервистер жиынтығы (poчта, командалық жұмыс, HR) және 1–2 маңызды локальды қосымша, олар ескі және заманауи кіру әдістерін толық қолдамайды.

Сондықтан шешімдерді жиі шатастырады. Okta, Microsoft Entra ID және Ping Identity жиі «бірдей SSO» ретінде аталады, бірақ олар әртүрлі платформалар және әрқайсысының күшті жақтары бар. Бастапқыда брендтер туралы емес, қандай қосымшаларды қосатыныңызды, пайдаланушылардың түрлерін (қызметкерлер, филиалдар, мердігерлер) және бұзуға болмайтын қолжетімділік ережелерін айқындау маңызды.

Протоколдар: SAML, OIDC және неге тексеру керек

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

SAML көбіне классикалық корпоративті жүйелер үшін қолайлы: ескі веб-порталдар, HR және бухгалтерия, көптеген on-prem қосымшалар және API-лар дәуіріне дейін пайда болған SaaS. Ол браузердегі бірыңғай кіруді жақсы шешеді, бірақ мобильді сценарийлер мен токендерді дәл баптауда қолайсыз болуы мүмкін. Типтік мәселелер: жөндеу қиындау, уақытпен байланысты нюанстар (таймзоналар, сессия өміршеңдігі), және кейбір интеграциялар нақты атрибуттарды күткенде «жұмсақ емес» болуы мүмкін.

OIDC заманауи веб-қосымшаларға, мобильді клиенттерге және API арқылы жұмыс істейтін сервистерге ыңғайлырақ. Мұнда маңыздысы — «OIDC бар ма» ғана емес, оны қалай жүзеге асырғаны: токендер өміршеңдігі, refresh token-пен жұмыс, қолтаңба мен аудитория тексерістері. Егер сізде микросервистер көп немесе бірнеше фронтенд болса, OIDC әдетте икемділік береді.

OAuth 2.0-ды SSO-мен жиі шатастырады. OAuth — ресурстарға қолжетімдікті делегирлеу туралы, ал SSO көбіне OIDC (аутентификация қабатын қосады) немесе SAML арқылы құрылады.

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

• Қосымша қандай протоколдарды қолдайды: SAML 2.0, OIDC, тек OAuth 2.0 ма?
• Бұл браузерлік кіру ме, мобильді қосымша ма немесе API арқылы ма?
• Қандай атрибуттар немесе claims керек (email, табельный номер, рөлдер) және қандай форматта?
• Токен ішінде топтар/рөлдер қажет пе және өлшем шектеулері бар ма?
• Сессия және шыгу қалай ұйымдастырылған (таймауттар, мәжбүрлі қайта кіру)?

Қарапайым мысал: егер сізде ескі ішкі портал SAML-пен және жаңа мобильді кабинет OIDC-пен болса, бір IdP екі протоколды да қызмет ететіндей етіп жоспарлау ыңғайлы, бірақ қауіпсіздік ережелері мен токен мерзімдерін оларға бөлек қою керек.

Гибридтің типтік архитектурасы: AD, бұлт және бір IdP

Көптеген гибрид ұйымдарда локальда Active Directory (AD) бар: онда қызметкерлердің есептік жазбалары, топтары, парольдері және таныс ережелер тұрады. Бір уақытта бұлттық сервистер пайда болады (по́чта, HR, CRM, SaaS), және кейде сыртқы пайдаланушылар: мердігерлер, серіктестер, уақытша персонал. SSO архитектурасының мақсаты — адам бір рет кіргенде қолжетімділік алдын ала болжамды және тексерілетін болсын.

Көбіне AD негізгі идентичностьті сақтайды (логин, атрибуттар, топқа мүшелік), ал бұлтқа қосымшаларға қажет нәрсе жіберіледі: атауы, email, бөлім, рөл, «қызметкер/мердігер» сияқты белгі. Алдын ала шешіңіз, қандай топтар құқықтың дереккөзі болып табылады (AD-топтары, бұлттық топтар, IdP ішіндегі топтар). Әйтпесе рөлдер жүйелер арасында таралып кетеді.

3 жұмыс істейтін нұсқа

Практикада схемалар бірнеше түсінікті түрге бөлінеді:

• Entra ID орталық ретінде: AD Entra-ға синхрондалады, Entra SaaS пен бір бөлікті ішкі қосымшаларға токен береді. Microsoft сервистері көп болса бұл ыңғайлы.
• Тәуелсіз IdP (Okta немесе Ping) орталық ретінде: AD есептік жазбаларын сақтай береді, IdP AD/каталогтан пайдаланушыларды алады және барлық қосымшаларға, соның ішінде Microsoft сервистеріне де токен береді.
• Аймақтар бойынша екі IdP: біреуі ішкі қосымшаларға, екіншісі бұлтқа, олардың арасында федерация. Бұл ретте әкімшілендіру мен реттегіш талаптар себепті қажет болуы мүмкін, бірақ қолдауды қиындатады.

Кілт сұрақ: есептік жазба қайда «тұрады» және токенді кім шығарады. Есептік жазба AD-де болуы мүмкін, бірақ SAML немесе OIDC токенін әдетте бір IdP шығарады. Содан кейін қосымшалар IdP-ге сенеді, пайдаланушы пароліне тікелей сенбейді.

MFA және шартты қолжетімділікті кіру орнында, яғни IdP-де ұстау оңай. Солайша біртұтас ережелер қою оңайырақ (мысалы, офистен тыс желі немесе жаңа құрылғыдан кіру — екінші фактор міндетті, ал артықшылықты рөлдер үшін — әрдайым). Қосымшалардың өзінде тек спецификалық тексерістер қалсын, мысалы маңызды операцияларды растау.

Күрделі рөлдер мен қолжетімділік саясаттары: талаптарды қалай сипаттау

Гибридте рөлдер тез күрделенеді. Бір қызметкерде лауазым, бөлім және екі жобаға қатысу болуы мүмкін, және әрбір қосымшаға қолжетім әртүрлі болады. SSO-ны көптеген қолмен жасалған ерекшеліктерге айналдырмау үшін «кімге не беру» емес, «қандай ережелер бойынша беріледі» дегеннен бастаңыз.

Түсінікті бастама — RBAC: рөлдер арқылы қолжетімділік (мысалы, "Бухгалтерия", "Ақпараттық қауіпсіздік қызметі", "Колл-орталығы операторы"). Жобалар, филиалдар, рұқсат деңгейлері және жұмыстың түрлері пайда болғанда ABAC (атрибуттар негізінде) қосқан ыңғайлы. Атрибуттар қарапайым болуы мүмкін: бөлім, қала, қызметкер түрі (штат/мердігер), келісім мерзімі, жоба, критикалдық деңгей.

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

Талаптарды жинауға көмектесетін матрица:

• Қай қосымшалар мен деректер критичты (ERP, пошта, қаржы, мемл. жүйелер).
• Лауазым бойынша және жобалар бойынша қандай рөлдер бар.
• Қай атрибуттар каталогтарда (AD/HR) шын мәнінде бар, ал қайсысы жоқ.
• Қандай тыйымдар міндетті (мысалы, "қаржы" мен "сатып алу" үйлеспейді).
• Қандай оқиғалар қолжетімділікті автоматты түрде кері қайтарып тастайды (жұмыстан шығару, ауыстыру, келісімнің аяқталуы).

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

Жұмыс кезеңін тексеріңіз: кім қолжетімдікті бастайды (басшы, HR, жүйе иесі), кім бекітіледі, кім бақылайды және қаншалықты жылдам қолжетімділік қайтарылады. Егер бұл алдын ала жазылмаса, кез келген платформа (Okta, Entra ID немесе Ping) «болғанша» конфигурацияланады.

Интеграциялар және есептік жазбалар өмірлік циклі (SCIM, каталогтар)

Интеграциялар табыстың жартысын шешеді, бірақ «нақты интеграцияны» қағаздағы шаблоннан ажырату маңызды. Қосымша тек SAML немесе OIDC арқылы кіруді қабылдап қоймай, қажетті атрибуттар мен топтарды қолдап, MFA мен шартты ережелерге сай болуы және диагностика мен қалпына келтіру сценарийлері болуы керек.

Microsoft 365, VPN, VDI, корпоративті порталдар, сондай-ақ HR және ITSM интеграцияларын тексеріңіз — осында көп жағдайда домендер, бірнеше каталогтар, қонақ есептік жазбалар және филиал саясаттарымен нюанстар шығады.

«Өмірде қалай жұмыс істейтінін» түсіну үшін вендорға немесе интеграторға нақты сұрақтар қойыңыз:

• Қандай атрибуттар мен топтар қосымшаларға беріледі және олар қалай мэптеледі?
• Осы қосымша үшін MFA және шартты ережелердің нақты қолдауы бар ма?
• Бөлім, лауазым немесе басшы өзгерсе не болады?
• Жұмыстан босату күні қолжетімділікті өшіру қалай көрінеді және қанша уақыт алады?
• Ерекшеліктер қалай өңделеді: сервис шоттары, уақытша мердігерлер, ортақ жұмыс орындары?

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

Ескі, SSO-ны қолдамайтын қосымшалар үшін әдетте үш жол бар: прокси/шлюз қою, агент қолдану немесе миграция жоспарын тану. Мысалы, ескі портал уақытша шлюз арқылы қаралуы мүмкін, сол уақытта ерекшеліктер тізімін қысқартып, бірнеше жыл бойы әртүрлі кіру түрлерін қолдамау керек деген шешімге келесіз.

Журналдау және аудит: SSO-платформадан не талап ету керек

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

Қай оқиғалар логта болуы тиіс

Көпшілігі үшін кем дегенде:

• кіру әрекеттері (сәтті және сәтсіз) — пайдаланушы, қосымша, IP, құрылғы және география бойынша;
• MFA оқиғалары: сұрау, әдіс, сәтті/сәтсіз, ерекшеліктер бойынша айналып өту;
• токендер немесе мәлімдемелердің берілуі мен жаңартылуы (OIDC/SAML): кімге, қай қосымшаға, қандай мерзімге;
• саясаттар өзгерістері: шартты қолжетімділік, MFA талаптары, ерекшеліктер, сенімді желілер;
• әкімші әрекеттері: интеграция қосу, атрибуттар өзгерту, әкімші рөлдерін беру.

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

Аудит пен SIEM үшін не маңызды

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

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

Аудиторлар жиі келесі сұрақтарды қояды:

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

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

Эксплуатация және тәуекелдер: әкімшілік, сенімділік, шығын

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

Әкімшілік: адамдар, рөлдер, өзгерістер

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

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

Сенімділік және орналастыру моделі

Сенімділік — презентациядағы SLA ғана емес. Интернет, DNS, MFA провайдері немесе локальды AD коннекторі істен шыққанда не болатынын нақтылаңыз. Гибридті схемаларда IdP уақытша қолжетімсіз болғанда негізгі жүйелерге қалай кіруге болатынын жоспарлау маңызды.

Практикалық сұрақтар:

• кіруге қатысты резервтеу аймақтары және RTO/RPO бар ма?
• техникалық қызмет көрсету терезелері қалай өтеді және оларды сіздің графикіңізге сай келтіруге бола ма?
• локальды агент немесе каталог қолжетімсіз болғанда не болады?
• тез қауіпті ережені қалай өшіруге болады, толық конфигурацияны қайтармай?
• төтенше әкімшілер үшін break-glass (авариялық кіру) қалай ұйымдастырылған?

Локальды орналастыруды қарастырсаңыз, қосымша тәуекелдер: жаңартулар, «темір», жоғары қолжетімділік пен 24/7 қолдау қажеттілігі шығады. Бұлттық модель кейбір қамшыларды жояды, бірақ провайдер мен байланыс желілеріне тәуелділікті күшейтеді.

Иеленудің құны: тек лицензия емес

TCO лицензиядан ғана тұрмайды. Кірістіру, қосымшаларды миграциялау, қолдау мен эксплуатация, админдер мен бірінші деңгей қолдауды оқыту, аудит және журналдауға интеграция шығындары болады.

Филиалдар мен мердігерлер бар ұйымдарда қолдау құны рөлдер жиі өзгеретіндіктен тез өседі. Сондықтан алдын ала регламент пен инциденттерге реакция келісіңіз. Сыртқы команда шақыратын болсаңыз, олардың 24/7 қолдауы және елдік сервис желісі бар-жоғын тексеріңіз. Мысалы, GSE.kz құрамында 24/7 техникалық қолдау және ұлттық сервис желісі бар, бұл критикалы контурлар үшін маңызды болуы мүмкін.

Қалай таңдау жасауға: 2–4 апталық қадамдар жоспары

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

Практикалық маршрут 2–4 аптада:

• Апта 1: қосымшаларды инвентаризациялау. Әрқайсысы SAML, OIDC, екі протоколды ма немесе SSO-сыз ба — белгілеңіз. Арнайы критикалық жүйелерді (қаржы, HR, пошта, сервис-деск) және мердігер қосымшаларын бөлек жазыңыз.
• Апта 1–2: рөлдер мен топ картасы. Атрибуттарды қайдан алатыныңызды (HR, AD, бұлт каталогтары), деректер иесін және өзгеру жиілігін анықтаңыз.
• Апта 2: MFA және шартты қолжетімділік талаптарын қарапайым ережелермен анықтаңыз: кім, қайдан және қандай құрылғылардан кіре алады.
• Апта 2–3: журнал талаптары: қандай оқиғалар керек, қанша уақыт ішінде SIEM-ге жетуі тиіс және қалай сақтау керек.
• Апта 3–4: 3–5 қосымшаға пилот өткізіңіз, онда SAML, OIDC бар және кемінде бір проблемалы қосымша болсын. Сәттілік критерийлерін алдын ала қойыңыз: қосылу уақыты, журналдардың түсініктілігі, әкімшілеудің ыңғайлығы, топтарды миграциялау сапасы.

Мысал: ұйымның кеңсесі мен филиалдары бар, бір бөлігі AD-де, бір бөлігі бұлтта, плюс мердігерлер. Пилотқа почта, өтініш порталы, бір ішкі веб-жүйе және бір мердігер қосымшасы қосылады. Нәтижесінде қай жерде рөлдерді сипаттаудың ыңғайлы екенін, шартты қолжетімділік қалай жұмыс жасайтынын және аудит журналдарының жеткіліктілігін көресіз.

Мысал сценарий: филиалдары мен мердігерлері бар орташа ұйым

Компанияда 800–1200 қызметкер: бас офис, 6–8 филиал, кейбірі қашықтан жұмыс істейді. Active Directory, Microsoft 365 және бірнеше локальды жүйе бар: өтініш есебі, кадр жүйесі және ішкі портал. Кейбір ресурсқа VPN немесе VDI арқылы қол жеткізу қажет.

Рөлдер күрделілігі көп: филиалдарда әртүрлі қосымша жиынтығы және бір қосымшада әр филиалда әртүрлі құқықтар бар. Мердігерлер 2–3 айға келіп, тек бір сервис көре алуы керек, пошта мен ішкі папкаларға қолжетім болмауы тиіс. Қосымша талаптар: мердігерлерге қолжетімділік тек жұмыс күндері 09:00–19:00 аралығында беріледі, ал әкімшілердің критикалық жүйелерге кіруі күшті аутентификацияны талап етеді.

Пилотты шағын бірақ сипаттамалық етіп жасаңыз. Әдетте үш қосымша жеткілікті:

• бір SAML-қосымша (көбінесе ескі корпоративті портал немесе кадр жүйесі);
• бір OIDC-қосымша (заманауи веб-сервис немесе ішкі кабинет);
• бір қашықтан контур: VPN немесе VDI, сырттан кіру мен MFA жұмысын тексеру үшін.

Пилот ішінде дереу рөл моделін қойыңыз ("Филиал А — Бухгалтерия", "Филиал Б — Сату", "Мердігер — Жоба X") және платформа ережелерін қалай қолданатынын тексеріңіз: топ бойынша, құрылғы бойынша, желі бойынша, уақыт бойынша, және жұмыстан шығарылғанда немесе келісім аяқталғанда не болатынын бақылаңыз.

Шешімді фактілерге негіздеу үшін өлшеңіз:

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

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

SSO енгізуде жиі жіберілетін қателіктер

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

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

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

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

Ары қарайғы хаостан сақтанудың бірнеше ережесі жеткілікті:

• қосымшаларды инвентаризациядан бастап, пилотқа 5–10 бірінші қосымшаны таңдаңыз;
• талаптарды бөлек жасаңыз: кіру (SSO, MFA, протоколдар) бөлек, құқықтар (рөлдер, топтар) бөлек;
• есептік жазбалардың өмірлік циклін сипаттаңыз: жасау, өзгерту, блоктау, жою, қонақ қолжетімділік;
• алдын ала журналдағы қандай оқиғалар жазылатынын және қанша сақталатынын тексеріңіз;
• кілт пайдаланушыларға арналған ерекшеліктерді шектеулі және уақытша етіп жасаңыз, бекіту тәртібін енгізіңіз.

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

Okta, Entra ID және Ping Identity-ны салыстырғанда қысқа чеклист қолыңызда болсын. Гибридте, AD және on-prem бір бөлігі, бұлттағы бөлігі бар кезде бұл тізім тез әлсіз тұстарды көрсетеді.

Пилот пен демоға дейін тексеріңіз:

• қосымшаларыңыздың протоколдары: SAML, OIDC, сондай-ақ LDAP/RADIUS және ескі формаларды қажет ететін жүйелер;
• топтар мен атрибуттардың көзі: AD, бұлттық каталогтар, HR жүйесі және қайсысы қай жағдайда басым болатыны;
• есептік жазбалардың өмірлік циклі: SCIM, өшіру/жою, бөлімдер арасында тасымалдау, қонақтар мен мердігерлер;
• MFA және шартты қолжетімділік: офис желісі, VPN, BYOD, артықшылықты әкімшілер сценарийлері;
• журналдар мен SIEM-ге интеграция: кіру, саясат өзгерістері, токендер, қателер, экспорт және сақтау мерзімі.

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

Ескі протоколдары бар қосымшаларды миграциялау жоспарын жазып қойыңыз. Үш жол бар: прокси/шлюз, қосымшаны ауыстыру немесе өтпелі кезеңде бөлек кіруді қалдыру, бірақ оны күшейтілген MFA және мониторингпен қамтамасыз ету.

2–4 апталық келесі қадамдар:

• пилот үшін 5–8 қосымшаны таңдаңыз (бұлттық, on-prem, критикалық, проблемалы);
• сәттілік критерийлерін келісіңіз: кіру уақыты, инциденттер саны, журналдардың толықтығы, пайдаланушылар үшін ыңғайлылық;
• тәуекелдерді бағалаңыз (IdP үзілістері, әкімші қолжетімдігі, резервтік схемалар) және откат жоспарын дайындаңыз;
• енгізу және оқыту жоспарын жасаңыз: кімге не өзгереді және қайда жүгіну керек.

Егер көмек керек болса, систем интегратор жобалаудан бастап пилотқа, интеграцияға және қолдауға дейін көмектесе алады. Гибрид жобаларда бұл әсіресе пайдалы, өйткені параллельде инфрақұрылым, мониторинг және эксплуатацияны ойластыру қажет.