Joiner‑Mover‑Leaver (JML): қызметкерлер рұқсаттарын автоматтандыру

Қызметкерлерді қабылдау, перевод және жұмыстан шығару кезіндегі рұқсаттар мәселесі

Көп компанияларда рұқсаттар әлі күнге дейін қолмен беріледі. HR IT‑ға хат жібереді, жетекші қызметкерді чаттарға қосады, әкімшер «естен шығарып» әр түрлі жүйелерде қажетті белгілерді қояды. Бір бөлігі хаттарда жоғалады, бір бөлігі «қасиет үшін» беріледі, сонда жаңа адам бірінші күннен жұмыс істей алады.

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

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

Түсінікті Joiner‑Mover‑Leaver (JML) процесі жағдайды өзгертеді. Ол онбордингті жеделдетеді, переводтарды болжамды етеді және жұмыстан шығару кезінде тәуекелдерді азайтады. Ең бастысы — шешімдер хаттар мен адамның жадына тәуелді болмайды.

Joiner, Mover, Leaver қарапайым тілмен

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

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

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

Leaver (жұмыстан шығару) — ең сезімтал кезең. Бұл жерде әрекеттерді үш деңгейге бөлу ыңғайлы:

• Бірден: кірісті жабу (есептік жазба, пошта, VPN, қашықтықтан қолжетімділік, токендер мен кілттер).
• Келесі бірнеше сағат ішінде: критикалық жүйелерге қолжетімділікті бұғаттау (қаржы, HR, CRM, бастапқы код).
• Істер тапсырудан кейін: ортақ жәшіктердің, файлдардың, тапсырмалардың және сыртқы қызметтердегі есептік жазбалардың жаңа иесін тағайындау.

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

JML‑процесіне қандай деректер мен жүйелер қатысады

JML қолмен «қосымша істер»сіз жұмыс істеуі үшін қайдан оқиға келетінін және өзгерістер қай жаққа шығарылатынын алдын ала анықтау қажет. «Деректер → шешім → әрекет» тізбегі қаншалықты айқын болса, қателер мен дау‑тартыстар соғұрлым аз болады.

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

Қызметкерлер каталогы (біртұтас карточка) тұрақты идентификатор мен ағымдағы атрибуттарды қамтуы тиіс: статус, бөлім, лауазым, жетекші, орналасқан жер, жұмыс түрі. Бекітілмеген ID болмаған жағдайда есептік жазбалар дубльденіп, рұқсаттарды «сол Ивановқа емес» тұлғаға қайтару қаупі туындайды.

Мақсатты жүйелер, яғни рұқсаттар тікелей сақталатын жүйелерге корпоративтік пошта мен күнтізбе, VPN және қашықтықтан қолжетімділік, файл ресурстары, бизнес жүйелер (ERP/CRM, бухгалтерия, СЭД), сервис‑деск жатады.

Логтар мен аудит — толық автоматтандыру болса да міндетті. Қай уақытта кім бастады, кім мақұлдады және қай кезде өзгерістер қолданылғанын көру мүмкін болуы керек. Минимум ретінде тіркелуі тиіс: оқиға мен оның көзі, қандай рұқсаттар берілген/алынған және қандай ереже бойынша, кім мақұлдаған, кім орындаған (жүйе/админ), сондай‑ақ қолмен жасалған ерекшеліктер мен себебі.

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

Рөлдер мен жауапкершілік: кім неге жауапты

JML көбіне технологиядан емес, ролдердің анық болмауынан құрылады. Оқиғаны кім тіркейді, рұқсаттарды кім таңдайды және тәуекелдерді кім бақылайтыны анық болмаса, артық рұқсаттар, кешігулер және дау‑дамайлар пайда болады.

HR: оқиға көзі және нақты деректер

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

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

Жетекші рұқсаттардың нақты жұмысқа сай болуын қамтамасыз етеді. Оған жүйелерді тізіп беру қажет емес — оның міндеті рөл (профиль) таңдау және шынайы қажеттілік болса ерекшеліктерді растау.

IT және ИБ ережелер мен шектемелерді анықтайды: қай рөл қай топтарға береді, қандай рұқсаттар қауіпті, қандай рұқсаттар бөлек келісімді және мерзімді талап етеді (мысалы, әкімші рұқсаттары немесе қаржылық деректер). Олар сондай‑ақ ерекшеліктерді бақылайды: кім сұраған, кім мақұлдаған, қандай мерзімге және келесі переводта не болатыны.

Сервис‑деск өтініштер мен SLA‑ны бақылаудың бір арнасы ретінде ыңғайлы. Автоматтандыру жағдайында да ол «диспетчер» болып қала береді: SLA‑ларды бақылайды, уақытша айналып өту әрекеттерін тіркейді және рұқсаттар шынымен берілген/қайтарылғанда ғана процесті жабады.

Қолжетімділік моделі: рөлдер, топтар және келісім ережелері

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

HR мен IT үшін түсінікті стандартты рөлдерден бастаңыз (бухгалтер, кадршы, сату менеджері, инженер, бөлім бастығы, колл‑центр операторы). Әр рөлге нақты топтар (AD/IAM) мен негізгі жүйелердегі рұқсаттар бекітілсін. Рұқсаттарды "пайдаланушыға жеке" емес, топ арқылы беру маңызды — әйтпесе перевод пен жұмыстан шығаруда "қуықтар" қалады.

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

Базалық рұқсаттарды рөл мен бөлімге қарай автоматты түрде беру жиі мүмкін. Кеңейтілгендерге көбіне жетекшінің мақұлдауы қажет, ал артықшылықты рұқсаттарға жүйе иесінің немесе ИБ‑ның бөлек келісімі керек.

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

Қадамдап: найм кезінде рұқсаттарды қалай автоматтандыруға болады

Joiner кезеңінің автоматтандырылуының принципі қарапайым: рұқсаттар хаттар мен өтініштер бойынша емес, HR‑оқиғасы мен айқын ережелер негізінде берілуі керек.

1) Процесті HR оқиғасынан бастаңыз

HR қабылдауды рәсімдеп, шығу күнін көрсеткенде қолжетімділіктерге тапсырма құрылуы керек. Тапсырманың иесі (әдетте IT немесе ИБ) және мерзімі болуы тиіс, мысалы "бірінші жұмыс күні сағат 10:00‑ге дейін".

2) Деректерді тексеріп, рөл тағайындаңыз

Рұқсаттарды бермес бұрын негізгі өрістерді тексеріңіз: бөлім, лауазым, жетекші, орналасқан жер, жұмыс түрі. Сол бойынша рөл шаблоны таңдалады.

3) Базалық рұқсаттар — автоматты, ерекшеліктер — келісілген түрде

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

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

4) Қызметкер мен жетекшіні хабардар етіңіз

Қызметкерге не істейтіні жайлы қысқа нұсқаулық қажет: қайсысы жұмыс істейді, қалай кіру, мәселе шықса қай жаққа жазу. Жетекшіге — қызметкердің «жұмысқа дайын» екендігі туралы растау.

5) Рұқсат фактісін растау және аудитты тіркеу

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

Қадамдап: перевод кезінде рұқсаттарды қалай басқару керек (Mover)

Перевод — қулықты кезең: рұқсаттар бұрыннан бар, және олардың бір бөлігі байқалмай-ақ артық болады.

1) Нені өзгергенін нақты тіркеңіз

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

2) Алдымен артықтарды алып тастаңыз, содан кейін жаңаларын қосыңыз

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

Өзгерістен кейін «сұр аймақтарды» тексеріңіз: ортақ қалталар, таратылымдар, командалық чаттар және күнтізбе құқықтары — дәл сол жерде ең кең рұқсаттар қалуы мүмкін.

3) Мерзімдерді ескеріңіз: бірден немесе перевод күнінде

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

4) Тарих пен «кім растағанын» сақтаңыз

Не болғанын, не болғанын, кім растағанын және қашан қолданылғанын сақтау жұмыс дауларында және аудиттерде көмектеседі.

Қадамдап: жұмыстан шығару кезінде рұқсаттарды қауіпсіз қалай қайтару керек (Leaver)

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

1) Бірден өшіру қажет нәрсе (жұмыстан шығару күні)

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

"Қолданушыны бұғаттау" жеткіліксіз болуы мүмкін. Белсенді сессиялар мен токендерді қайтармайынша, қатынас сессия аяқталғанға дейін сақталуы мүмкін.

2) Кейінірек жабылатындар (іскерлікті тапсырудан кейін)

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

3) Құрылғылар мен физикалық тасымалдағыштар

Ноутбук, телефон, токендер, смарт‑карталар мен пропускты бөлек өңдеңіз. Мүлікті қайтару процеске енгізілсін: қабылдау, құрамын тексеру, жұмыс деректерін жою, қажет болса қауіпсіз түрде тазалау және қайта орнату.

4) Мердігерлер мен уақытша қызметкерлер

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

5) ИБ үшін бақылау және есеп беру

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

JML‑ді бұзатын жиі қателер мен тұзақтар

Үлкен қателіктер көбіне «жаман құралдан» емес, тәртіпсіздіктен шығады: бір жерде рұқсатты рәсімдеуді кейінге қалдырған, бір жерде алып тастауды ұмытқан, бір жерде есептік жазба бірнешеге бөлінген.

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

Перевод кезінде инерция да жиі әсер етеді: ескі құқықтарды «қалай болса солай» қалдырып, жаңа рұқсаттарды қосады. Соның нәтижесінде қауіпті қабаттасулар (мысалы, сатып алу мен қаржы) пайда болады. Дұрысы — әр өзгеріс сайын ағымдағы құқықтарды мақсатты профильмен салыстырып, артықтарын жою.

Тағы бір тұзақ — біртұтас идентификатордың болмауы. HR‑дағы, пошталаудағы және домендегі әр түрлі ФИО форматтары есептік жазбалардың дубльденуіне әкеледі. Кейін «Иванов И.И.» жұмыстан шығарса, активті «ivanov.i» есептік жазбасы критикалық жүйелерге қатынауды сақтап қалуы мүмкін.

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

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

JML‑ды автоматтандыруға дайындыққа арналған қысқа чек‑лист

Автоматтандыруға кіріспес бұрын процестер мен деректер дайын екеніне сеніңіз. Әйтпесе автоматтандыру тек хаосты тездетеді.

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

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

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

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

Практикалық мысал: бір қызметкерді қабылдау, перевод және жұмыстан шығару

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

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

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

3 айдан кейін Аннаны перевод жасайды (Mover). Триггер — HR‑да бөлім мен орналасқан жердің өзгеруі. Процесс ескі филиалға қатысты барлығын алып тастап, бас кеңсенің қажеттерін қосады. Топтар, қалталар, жұмыс кеңістіктері, профильдік жүйелердегі рұқсаттар және лицензиялар өзгереді. Егер филиалдық жоба қалтасына 2 аптаға қатынасты сақтау керек болса, бұл мерзімі көрсетілген уақытша ерекшелік ретінде рәсімделеді.

Жұмыстан шығару күні (Leaver) есептік жазба бірден бұғатталып, белсенді сессиялар аяқталып, токендер мен критикалық жүйелерге қатынастар басымдық тәртібімен қайтарылады. Пошта мен файлдар үшін иесі тағайындалып, шектеулі мерзімге автожауап қосылып, компания ережелері бойынша архивке жіберіледі.

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

Келесі қадамдар: JML‑ды жұмысты тоқтатпай қалай іске қосу керек

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

Жүйелер тізімінен бастаңыз (пошта, AD, 1С, CRM, файл сақтау, салалық сервистер) және 10–20 ең жиі қолданылатын рөльді бөліп алыңыз. Содан кейін бір өтініш арнасын бекітіңіз (мысалы, сервис‑деск) және түсінікті статустар, келісім ережелерін сипаттаңыз, мерзімдерді орнатыңыз (бірінші күнге дайындық және жұмыстан шығару кезінде өшіру жылдамдығы), минималды автоматтандыруды баптаңыз (есептік жазбаны құру, топтарға қосу, типтік құқықтарды алу) және бір бөлімде пилот өткізіңіз.

Көмек қажет болса, GSE.kz (gse.kz) жүйелік интегратор ретінде рөлдер мен ережелер сипаттамасына, HR мен IT‑ны байланыстыруға және қолдауды ұйымдастыруға қосыла алады. Бұл әсіресе рұқсаттар көп және процестің тұрақты жұмыс істеуі 24/7 маңызды болғанда пайдалы.