Ішкі жүйелерге арналған Keycloak: OIDC және SAML арқылы лицензиясыз SSO

Ішкі жүйелерге кіруде жиі кездесетін қиындықтар

Қызметкерлерде оншақты ішкі сервис болса, логиндер мен парольдер тез арада хаосқа айналады. Парольдер қайталанады, ескерту жазбаларында сақталады, тест пен өндіріс аккаунттары араласады. Қолдау қызметі үнемі парольді қалпына келтіру сұрайды, ал жаңадан келгендер апта бойы почта мен чаттар арқылы рұқсат жинайды.

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

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

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

Қосылатын жүйелер әртүрлі: кадрлық сервистер, өтініштер мен құжат айналымы, CRM/ERP, ВКС пен почта, ішкі әкімшілік панельдер және кейде өзге жазылған қосымшалар. Жақсы SSO-схема қазіргі протоколдарды (OIDC) және ескі интеграцияларды (SAML) жабуы керек, бәрін бірден қайта жазбай.

Keycloak қай жерде тиімді

Keycloak ішкі жүйелердің негізгі проблемасын шешеді: оншақты пароль орнына бір рет кіру. Ол аутентификацияны реттейді, аккаунттарды сақтап, сыртқы каталогтарды (LDAP немесе Active Directory сияқты) қосады. Қосымшаларға ол кіруді растайтын токендер немесе мәлімдемелер жібереді. Осылайша сіз кіруді, құқықтарды және қауіпсіздік талаптарының бір бөлігін орталықтандырасыз, әр сервиске жеке баптауды шашпаңыз.

OIDC мен SAML айырмашылығы негізінен деректер алмасу форматында және типтік орталарында. OIDC қазіргі веб және мобильді қосымшалар үшін оңайырақ: ол токендер (JWT) арқылы жұмыс істейді және API-лерге ыңғайлы. SAML корпоративтік жүйелер мен ескі веб-қосымшаларда жиі кездеседі: ол қол қойылған XML-ұсыныстарды жібереді және SAML қабылданған стандарт болған жүйелерде ыңғайлы.

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

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

Бастамас бұрын жауапкершілікті айқындап алыңыз. Әйтпесе SSO «ешкімнің» критикалық сервисіне айналуы мүмкін. Практикада үш рөл керек болады: IAM иесі (қолданушылар мен құқықтардың өмірлік циклі), Keycloak әкімшісі (бағдарламалық баптау, интеграциялар, жаңарту) және Қауіпсіздік (MFA, парольдер, аудит пен тергеулер).

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

Дайындық: орта, домен, пайдаланушылар және негізгі гигиена

Қосымшаларды қоспас бұрын негізді ретке келтіріңіз. SSO әдетте OIDC немесе SAML-дан емес, домен, уақыт, сертификаттар және орта шатасуынан бұзылады. Бұл әсіресе Keycloak-ты бірнеше команда қатар қолдана бастағанда көрінеді.

Орталар: dev, test, prod

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

• dev: жедел эксперименттер, дерекқор мен realm-ді қалпына келтіруге болады
• test: өндірістікке барынша ұқсас, жаңартулар мен миграцияларды тексеру
• prod: өзгерістер рәсіммен, бэкап пен оралу жоспары бар жағдай

Келесі қадам — домен таңдау. SSO үшін Keycloak мекенжайы тұрақты болуы маңызды: пайдаланушылар оған үйренеді, ал қосымшалар redirect/callback адрестарына қатты байланады.

TLS-сертификат барлық жұмыс құрылғылары үшін сенімді болуы тиіс. Өз қолтаңбалы сертификаттар жиі күтпеген кіру қателері мен шолғыш ескертуін береді.

Уақыт синхрондауы (NTP) міндетті. Тіпті бірнеше минут айырмашылық токендер мен қолтаңбаларды бұзуы мүмкін және «кездейсоқ» кіру сәтсіздіктерін тудырады.

Пайдаланушыларды қайда ұстау

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

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

Әр қосымша үшін минимум деректер жинаңыз: базалық URL, дәл redirect/callback URI, қосымша әкімшісінің байланысы, рөлдер/топтар тізімі және сессия талаптары (таймауттар, шығу, "құрылғыны есте сақтау" сияқты MFA талаптары).

Қосымшаны OIDC арқылы қосу қалай

Егер қосымша веб-типті және OpenID Connect қолдаса, оны әдетте OIDC арқылы қосады (заманауи стектер мен көптеген корпоративтік порттар үшін).

Алдымен Keycloak-та негіз құрыңыз: ұйымға немесе ортаға бөлек realm жасаңыз (мысалы, "intranet-dev" және "intranet-prod"). Бастапқыда сессиялар мен токендердің жарамдылық мерзімі (access/refresh), пароль саясаты және қауіпсіздіктің базалық талаптарын тексеріңіз. Бұл баптаулар кейін қолданушыларға әсер етуі мүмкін болғандықтан, оларды кейін өзгерту қиын болуы мүмкін.

Әдеттегі қосылу қадамдары:

• OpenID Connect типіндегі Client жасаңыз және Client ID беріңіз (әдетте қосымша аты).
• Valid Redirect URIs, Web Origins және logout (post logout redirect) параметрлерін баптаңыз.
• Қол жетімділік түрін таңдаңыз: confidential (client secret бар) немесе public (секретсіз, SPA үшін), және Authorization Code Flow-ды қосыңыз.
• Қосымшаға қандай мәліметтер қажет екенін шешіңіз: минимум sub, жиі email, ал құқықтар үшін рөлдер немесе топтар.
• Кіруді тестілеп, қосымшаның керек claims-ті оқитынын тексеріңіз.

Мысалы: кадрлық портал толық аты-жөнді көрсету және рөл бойынша бөлімдерді ашу үшін email арқылы қолданушыны байланыстырады және ID token немесе UserInfo арқылы рөлдер (мысалы, "hr" немесе "manager") алады.

Егер логиннен кейін редирект қателері шықса, көбіне себептер: redirect URI символдық дәлдікпен сәйкес келмейді (артық слэш, басқа протокол), домен Web Origins-қа қосылмаған, confidential/public түрі қате, realm немесе Client ID дұрыс емес немесе қосымшаға қажет claim (email/groups) mappers арқылы қосылмаған.

Қосымшаны SAML арқылы қосу қалай

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

Баптау қадамдары

Бастапқыда минималды жұмыс істейтін кіруден бастаңыз, содан кейін қол қою, шифрлау және Single Logout қосыңыз.

1. Keycloak-та жаңа client жасап, протокол ретінде SAML таңдаңыз.

2. Клиентке арналған metadata-ны экспорттаңыз (қосымша иесіне қажет болады). Қосымша Service Provider ретінде қатысса, оның metadata-ын сұраңыз.

3. Негізгі өрістерді баптаңыз: ACS URL (кіруден кейін Keycloak қайсысына жауап жібереді) және Entity ID (қосымшаның бірегей идентификаторы). Бір символдағы қате интеграцияны бұзуы мүмкін.

4. Қосымша шығу керек болса, Single Logout тәсілі туралы алдын ала келісіңіз. Практикада SLO тұрақсыз жұмыс істеуі мүмкін, сол себепті кейде тек қосымшада шығу жасап, барлық SSO-сессияны шығару әрекетін жасамай қоюды таңдайды.

5. Серверлердегі уақыт пен уақыт белдеулерінің синхрондауын тексеріңіз. Уақыт айырмашылығы SAML-жауаптарды мерзімінен тыс деп есептеуі мүмкін.

Атрибуттарды сәйкестендіру

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

Содан кейін қол қою мен шифрлауды келісіңіз: response немесе assertion-ды неге қол қою қажет, бөлек сертификат керек пе, қай алгоритмдер жарайды, assertion-ды шифрлау керек пе — бұл барлығын жазбаша бекітіңіз, сонда сертификаттар немесе саясат ауысқанда түнгі инцидент болмайды.

Рөлдер, топтар және шатасусыз қол жеткізу моделін құру

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

• Realm — пайдаланушылар, кіру ережелері және қосымшалары бар бөлек басқару аумағы.
• Client — Keycloak-қа сенетін және SSO-ны қабылдайтын нақты қосымша.
• User — адам немесе сервиске тиесілі есеп жазбасы.
• Role — не істеуге рұқсат барын көрсететін құқық.
• Group — пайдаланушыларға құқықтарды топпен беру тәсілі.

Realm-roles және client-roles

Realm-role жалпы және әртүрлі қосымшалар үшін бірдей түсінік беретін құқықтар үшін ыңғайлы (мысалы, "employee" немесе "security-auditor"). Client-role нақты сервис үшін мағыналы құқықтарға сай келеді.

Қарапайым логика үшін негізгі ережелерді ұстаныңыз: жалпы статустар мен шектеулерді realm-roles-ке қойып, қосымшаға тән құқықтарды client-roles-қа бөліп, құқықтарды топтар арқылы жаппай беріңіз. Қосымша расында тексеретін рөлдер ғана болсын — «әрі қарай болуы мүмкін» үшін көп роль жасаудың қажеті жоқ.

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

Құқықтар қосымшаға қалай өтеді (OIDC және SAML)

OIDC-де рөлдер әдетте токенде claims ретінде жіберіледі (мысалы, roles немесе realm_access/client_access блоктары). SAML-де сол мәлімет attributes ретінде өтеді. Қосымша қандай өрісті оқитынын алдын ала шешіңіз, әйтпесе «роль бар, бірақ қолжетім жоқ» жағдай туындайды.

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

• portal-user — өз өтініштерін жасау және көру
• portal-operator — өтініштерді өңдеу
• admin-console — тіркеу кітаптарын және баптауларды басқару
• reports-read — есептерді оқу

Keycloak-та MFA: баптау, ерекшеліктер және қолжетімділікті қалпына келтіру

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

Қандай факторларды таңдау

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

MFA-ны қай жерде және қалай қосу

Keycloak-та MFA әдетте authentication flows арқылы орнатылады, «барлығына бір батырма» емес. Ыңғайлы тәсіл: барлығы үшін базалық кіру, ал екінші факторды топтар (мысалы, "Әкімшілер", "Қаржы") немесе нақты қосымша үшін міндеттеу.

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

Сервис тіркелгілері мен токен арқылы интеграциялар интерактивті MFA-ға тап болмауы тиіс.

Қолжетімділікті қалпына келтіру

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

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

ІБ үшін журналдар және аудит: не қосу керек

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

Әдетте аутентификация және қауіпсіздік оқиғаларын және әкімшілік оқиғаларды қосады. Қауіпсіздік командалары ең жиі мыналарды талап етеді:

• кірулер және кіру қателері (табысты/сәтсіз), логаут, токендер мен сессиялар мәселелері
• MFA оқиғалары (сұрау, табыс, сәтсіздік, блоктау, қалпына келтіру және қайта байлау)
• қолжетімдіктің өзгерістері (рөлдер тағайындау/алу, топ өзгерістері, рөл мэппингі)
• әкімшілік әрекеттер (пайдаланушылар жасау, пароль қалпына келтіру, есепті өшіру, realm пен клиент баптауларын өзгерту)

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

Тергеу үшін міндетті өрістер: пайдаланушы (username/userId), уақыт, нәтиже (табысты/сәтсіз), IP, client (қай қосымша), realm, оқиға түрі. Әкімшілік әрекеттер үшін actor (кім өзгертті) және target (кімге өзгертілді) қосыңыз. Егер прокси немесе балансировщик болса, оқиғаларда нақты IP сақталатынын тексеріңіз.

Сақтау мен қол жеткісуді бөлек ойлаңыз. Аудит әдетте қолданбалы журналдардан ұзағырақ сақталады: мысалы, 90–180 күн онлайнда және талапқа сай архив. Құжаттарды әкімшілер Keycloak баптауларын өзгерткенде оңай жоя алмауы үшін журналдарға қолжетуді шектеңіз.

Инцидентті сараптау қолмен іздеуге айналмасын десеңіз, оқиғаларды бір форматқа келтіріп, қосымша журналдармен байланыстырыңыз. "Сәтсіз кірулер -> табысты кіру -> токен беру -> API шақырулар" тізбегі парольді ұрлау, MFA айналып өту немесе рөлдердегі қате туралы тез түсінік береді.

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

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

Кірудің жиі сөніп қалу себебі — redirect URI. Қосымша бірнеше доменде өмір сүреді (ішкі және сыртқы, тесті және өндіріс, әртүрлі поддомендер), ал клиентте бір адрес көрсетілген. Нәтижесінде пайдаланушылардың бір бөлігі логиннен кейін қате алады немесе бағытталу циклында қалады. Бұл мәселені каноникалық домен мен қолайлы callback адрес списогымен шешеді, бірақ «барлығына арналған шаблондарды» қосудың қажеті жоқ.

Екінші тор — құқықтар. Барлығына «Қызметкерлер» сияқты кең топ берсеңіз, рөлдер тез арада шашылып, біреу күтпеген жерден әкімшілік қолжетімдігі алып қалады. Рөлдерді (не істеуге болады) және топтарды (кімге) бөлу керек, сервис тіркелгілерін адамдардан ажырату қажет.

Үшінші себеп — серверлердегі уақыт. Егер Keycloak, балансировщик және қосымшаның сағаттары сай болмаса, токендер «әлі күшіне енбеген» немесе «мерзімі өткен» болып есептелуі мүмкін. Бұл әсіресе жаңартудан кейін кездейсоқ ақаулар ретінде көрінеді.

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

Қауіпсіздік үшін әкімшілік әрекеттер аудитін ұмыту маңызды емес. Әйтпесе тергеу кезінде "кім рөл мэппингін өзгертті, кім MFA-ны өшірді немесе жаңа redirect URI қосты" деген сұрақтарға жауап жоқ болады.

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

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

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

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

Минималды тексерулер тізімі:

• Әр қосымша үшін протокол (OIDC немесе SAML), адрестер, жауапты иесі, қажетті claims/атрибуттар және қолжетімдікті беретін топтар бекітілсін.
• Тест контурында кіру, шығу, сессия таймауттары, токендерді жаңарту және "қызметкер жұмыстан шықса қолжетімдігін алып тастау" сценарийі тексерілген болсын.
• Рөлдер мен топтар қарапайым тілмен сипатталған және "минималды қажетті құқық" принципі бойынша тексерілген болсын.
• MFA саясаттары анық: қайда міндетті, қай жерде ерекшелік (мысалы, сервис тіркелгілері) және қалай қалпына келтіру жасалатыны белгілі болуы керек.
• Аудит және қауіпсіздік оқиғалары қосылған, журналдар орталықтандырылған сақтауға түседі, сақтау талаптарға сай және журналдарға қолжетімділік шектелген.

Соңында қысқа тергеу сценарийін іске қосыңыз. Тест қолданушысын алып, журналдардан мына сұрақтарға жауап табуға тырысыңыз: қашан кірді, қай IP мен user-agent-пен, қай клиенттерге кірген, кім оның рөлдерін өзгертті — егер 10–15 минут ішінде жауап табылмаса, нақты инцидентте жағдай күрделенеді.

Мысал: бірнеше ішкі сервисі бар ұйымға SSO

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

Қосылу әдетте күрделілігі бойынша біртіндеп жүреді. Алдымен портал OIDC арқылы қосылады — бұл заманауи веб-қосымша үшін тез шешім және көрінетін пайда әкеледі. Содан кейін Service Desk SAML арқылы қосылады (осылайша ескі немесе қораптық жүйені интеграциялау жиі кездеседі). Барлық жерде кіру тұрақты жұмыс істей бастағаннан кейін ғана MFA қосылады — бірден үш жерде емес.

Рөлдерді процесс иелері түсінетіндей атаған жөн:

• Қызметкер: порталға және өз деректеріне негізгі қолжетімділік
• Басшы: өтініштерді мақұлдау, өз бөліміне есептерге қолжетімділік
• Оператор: Service Desk-тегі билеттермен жұмыс
• Әкімші: баптауларды басқару, бірақ "бәріне қолжетімділік" емес

Қақтығыстар туындаған жағдайда Қауіпсіздік көбіне екі жайтты сұрайды: "кім және неге деректерді көрген" және "пароль ауыстыруы әрекеті жүрді ме". Осы үшін кіру және әкімшілік әрекеттерді Keycloak-та алдын ала қосып, сақтау қажет: сәтті және сәтсіз логиндер, brute force блоктау, токен беру, пароль өзгерту, MFA байлау/қалпына келтіру, сондай-ақ рөлдер мен топтарды өзгерту. Журналдарда уақыт, пайдаланушы, client (қай қосымша), IP және user-agent болуы маңызды.

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

Келесі қадамдар: пилот, іске қосу және қолдау

Пилоттан бастаңыз — ол жылдам нәтиже береді және интеграциялардың нақты күрделілігін көрсетеді. 2–4 ішкі қосымшаны таңдаңыз: біреуі OIDC бойынша, біреуі SAML бойынша және мүмкіндігінше персоналды деректерге қолжетімділігі бар бір сервис. Бастапқы модельге 3–5 рөл жеткілікті (пайдаланушы, басшы, әкімші, қолдау, аудит).

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

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

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

Егер қосымшалар көп, SAML конфигурациялары күрделі және Қауіпсіздік аудит талаптары қатал болса, интеграторды тартқан оңай. Мұнда маңыздысы протоколдың «ұсақ-түйектігі» емес, тәртіп: сертификаттардың өмірлік циклі, атрибуттарды мэппингі, құқық беру ережелері және тұрақты эксплуатация.

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