Мен қазір бағдарламалық жасақтама жеткізушісінде жұмыс істеймін, әсіресе қол жеткізуді басқару шешімдері. Ал менің «өткен өмірдегі» тәжірибем тұтынушы тарапымен - ірі қаржы ұйымымен байланысты. Ол кезде біздің ақпараттық қауіпсіздік бөліміндегі қолжетімділікті бақылау тобы IdM-де үлкен құзыреттіліктермен мақтана алмады. Бұл процесте біз көп нәрсені үйрендік, компаниядағы ақпараттық жүйелердегі пайдаланушылардың құқықтарын басқарудың жұмыс механизмін құру үшін көптеген соққылардан өтуге тура келді.
Өзімнің еңбекпен тапқан тұтынушы тәжірибемді жеткізушінің білімі мен құзыретімен біріктіре отырып, мен сіздермен негізінен қадамдық нұсқаулармен бөліскім келеді: үлкен компанияда рөлге негізделген қол жеткізуді басқару моделін қалай құру керек және бұл нәтижеде не береді . Менің нұсқауларым екі бөліктен тұрады: біріншісі модельді құруға дайындалу, екіншісі - шын мәнінде құрастыру. Міне, бірінші бөлім, дайындық бөлімі.
NB Үлгіні қалыптастыру, өкінішке орай, нәтиже емес, процесс. Дәлірек айтқанда, компанияда қол жеткізуді басқару экожүйесін құру процесінің бір бөлігі. Сондықтан ойынға ұзақ дайындалыңыз.
Алдымен, оны анықтайық - рөлге негізделген қол жеткізуді басқару дегеніміз не? Сізде ондаған, тіпті жүздеген мың қызметкерлері (субъектілері) бар ірі банк бар делік, олардың әрқайсысында жүздеген ішкі банктік ақпараттық жүйелерге (объектілерге) ондаған қол жеткізу құқығы бар. Енді нысандардың санын субъектілердің санына көбейтіңіз - бұл алдымен құрастыру керек, содан кейін басқару керек қосылымдардың ең аз саны. Мұны шынымен қолмен жасауға бола ма? Әрине, бұл мәселені шешу үшін рөлдер құрылды.
Рөл - белгілі бір жұмыс тапсырмаларын орындау үшін пайдаланушыға немесе пайдаланушылар тобына қажет рұқсаттар жиынтығы. Әрбір қызметкердің бір немесе бірнеше рөлдері болуы мүмкін және әрбір рөлде сол рөлдегі пайдаланушыға рұқсат етілген біреуден көпке дейін рұқсаттар болуы мүмкін. Рөлдер нақты лауазымдарға, бөлімдерге немесе қызметкерлердің функционалдық міндеттеріне байланысты болуы мүмкін.
Рөлдер әдетте әрбір ақпараттық жүйедегі қызметкерлердің жеке рұқсаттарынан құрылады. Содан кейін әрбір жүйенің рөлдерінен жаһандық бизнес рөлдері қалыптасады. Мысалы, «несие менеджері» бизнес рөліне банктің клиенттік кеңсесінде қолданылатын ақпараттық жүйелердегі бірнеше бөлек рөлдер кіреді. Мысалы, негізгі автоматтандырылған банк жүйесі, кассалық модуль, электрондық құжат айналымы жүйесі, қызмет менеджері және т.б. Іскерлік рөлдер, әдетте, ұйымдық құрылымға, басқаша айтқанда, компанияның бөлімшелерінің жиынтығына және олардағы лауазымдарға байланысты. Жаһандық рөлдік матрица осылай қалыптасады (мен төмендегі кестеде мысал келтіремін).
Айта кету керек, коммерциялық құрылымдағы әрбір лауазымның қызметкерлеріне барлық қажетті құқықтарды қамтамасыз ете отырып, 100% үлгі үлгісін құру мүмкін емес. Иә, бұл қажет емес. Өйткені, үлгі-өнеге статикалық бола алмайды, өйткені ол үнемі өзгеріп тұратын ортаға байланысты. Және сәйкесінше ұйымдық құрылым мен функционалдық өзгерістерге әсер ететін компанияның кәсіпкерлік қызметіндегі өзгерістерден. Және ресурстармен толық қамтамасыз етілмегендіктен және лауазымдық нұсқаулықтарды сақтамаудан және қауіпсіздік есебінен пайдаға ұмтылудан және басқа да көптеген факторлардан. Сондықтан, лауазымға тағайындалған кезде қажетті негізгі құқықтар үшін пайдаланушы қажеттіліктерінің 80% -на дейін жаба алатын үлгі үлгісін құру қажет. Қажет болған жағдайда олар қалған 20% кейінірек бөлек өтінімдер бойынша сұрай алады.
Әрине, сіз: «100% үлгі алатындар жоқ па?» деп сұрауыңыз мүмкін. Неліктен бұл, мысалы, жиі өзгерістерге ұшырамайтын коммерциялық емес құрылымдарда - кейбір ғылыми-зерттеу институтында болады. Немесе қауіпсіздік бірінші орында тұрған қауіпсіздік деңгейі жоғары әскери-өнеркәсіптік кешен ұйымдарында. Бұл коммерциялық құрылымда болады, бірақ жұмысы айтарлықтай статикалық және болжамды процесс болып табылатын жеке бөлімшенің шеңберінде болады.
Рөлдік басқарудың басты артықшылығы - эмиссиялық құқықтарды жеңілдету, өйткені рөлдер саны ақпараттық жүйені пайдаланушылар санынан айтарлықтай аз. Және бұл кез келген салаға қатысты.
Бөлшек сауда компаниясын алайық: онда мыңдаған сатушылар жұмыс істейді, бірақ олардың N жүйесінде бірдей құқықтар жиынтығы бар және олар үшін бір ғана рөл жасалады. Компанияға жаңа сатушы келгенде, оған барлық қажетті өкілеттіктері бар жүйеде қажетті рөл автоматты түрде тағайындалады. Сондай-ақ, бір рет басу арқылы мыңдаған сатушылардың құқықтарын бірден өзгертуге болады, мысалы, есепті жасау үшін жаңа опцияны қосыңыз. Әрбір тіркелгіге жаңа құқықты байланыстыра отырып, мың операция жасаудың қажеті жоқ - бұл опцияны рөлге қосыңыз және ол барлық сатушылар үшін бір уақытта пайда болады.
Рөлге негізделген басқарудың тағы бір артықшылығы - сәйкес келмейтін рұқсаттарды беруді жою. Яғни, жүйеде белгілі бір рөлге ие қызметкер бір уақытта басқа рөлге ие бола алмайды, оның құқықтары біріншідегі құқықтармен біріктірілмеуі керек. Жарқын мысал қаржылық операцияны енгізу және бақылау функцияларын біріктіруге тыйым салу болып табылады.
Рөлге негізделген қол жеткізуді басқару қалай пайда болғанына қызығушылық танытатын кез келген адам жасай алады
тарихқа үңілу
Тарихқа үңілсек, IT қауымдастығы қол жеткізуді басқару әдістері туралы алғаш рет 70 ғасырдың XNUMX-жылдарында ойлаған. Қолданбалар ол кезде өте қарапайым болғанымен, дәл қазіргідей барлығы оларға қол жеткізуді ыңғайлы түрде басқарғысы келді. Пайдаланушы құқықтарын беріңіз, өзгертіңіз және бақылаңыз - олардың әрқайсысына қандай рұқсат бар екенін түсінуді жеңілдету үшін. Бірақ ол кезде біртұтас стандарттар болған жоқ, қол жеткізуді басқарудың алғашқы жүйелері әзірленді және әр компания өз идеялары мен ережелеріне негізделді.
Қол жеткізуді басқарудың көптеген әртүрлі үлгілері қазір белгілі, бірақ олар бірден пайда болған жоқ. Осы саланың дамуына зор үлес қосқандарға тоқталайық.
Бірінші және ең қарапайым модель Дискрециялық (таңдамалы) қол жеткізуді басқару (DAC – дискрециялық қол жеткізуді басқару). Бұл модель қол жеткізу процесінің барлық қатысушыларының құқықтарды бөлісуін білдіреді. Әрбір пайдаланушы белгілі бір нысандарға немесе операцияларға қол жеткізе алады. Мәні бойынша бұл жерде құқық субъектілерінің жиынтығы объектілердің жиынтығына сәйкес келеді. Бұл модель тым икемді және оны ұстау тым қиын болып табылды: қол жеткізу тізімдері ақырында үлкен және басқару қиынға айналады.
Екінші модель Міндетті қол жеткізуді басқару (MAC - Міндетті қол жеткізуді басқару). Бұл модельге сәйкес әрбір пайдаланушы деректер құпиялылығының белгілі бір деңгейіне берілген рұқсатқа сәйкес нысанға рұқсат алады. Сәйкесінше, объектілер құпиялылық деңгейіне қарай жіктелуі керек. Бірінші икемді модельден айырмашылығы, бұл, керісінше, тым қатал және шектеуші болып шықты. Кәсіпорында әртүрлі ақпараттық ресурстар көп болған кезде оны пайдалану ақталмайды: әртүрлі ресурстарға қол жеткізуді саралау үшін бір-біріне сәйкес келмейтін көптеген категорияларды енгізуге тура келеді.
Осы екі әдістің айқын жетілмегендігіне байланысты АТ қауымдастығы ұйымдық қатынасты басқару саясатының әртүрлі түрлерін қолдау үшін икемді және сонымен бірге азды-көпті әмбебап үлгілерді әзірлеуді жалғастырды. Содан кейін пайда болды үшінші рөлге негізделген қол жеткізуді басқару моделі! Бұл тәсіл ең перспективалы болып шықты, өйткені ол пайдаланушының жеке басын растауды ғана емес, сонымен қатар оның жүйелердегі операциялық функцияларын да талап етеді.
Алғашқы нақты сипатталған үлгі құрылымын 1992 жылы АҚШ Ұлттық стандарттар мен технологиялар институтынан американдық ғалымдар Дэвид Феррайло мен Ричард Кун ұсынған. Содан кейін термин алғаш рет пайда болды RBAC (Рөлге негізделген қол жеткізуді басқару). Бұл зерттеулер мен негізгі құрамдас бөліктердің сипаттамасы, сондай-ақ олардың өзара қарым-қатынастары Халықаралық ақпараттық технологиялар стандарттары комитетімен (INCITS) бекітілген, бүгінгі күнге дейін күшінде тұрған INCITS 359-2012 стандартының негізін құрады.
Стандарт рөлді «рөлге тағайындалған пайдаланушыға тағайындалған өкілеттік пен жауапкершілікке қатысты кейбір байланысты семантикасы бар ұйым контекстіндегі жұмыс функциясы» ретінде анықтайды. Құжат RBAC негізгі элементтерін – пайдаланушыларды, сеанстарды, рөлдерді, рұқсаттарды, операцияларды және объектілерді, сондай-ақ олардың арасындағы байланыстар мен өзара байланыстарды белгілейді.
Стандарт рөлдік үлгі құру үшін ең аз қажетті құрылымды қамтамасыз етеді - құқықтарды рөлдерге біріктіру, содан кейін осы рөлдер арқылы пайдаланушыларға рұқсат беру. Нысандар мен операциялардан рөлдерді құру механизмдері сипатталған, рөлдер иерархиясы және өкілеттіктердің мұрагерлік тәртібі сипатталған. Өйткені, кез келген компанияда компанияның барлық қызметкерлеріне қажетті негізгі өкілеттіктерді біріктіретін рөлдер бар. Бұл электрондық поштаға, EDMS, корпоративтік порталға және т.б. қол жеткізу болуы мүмкін. Бұл рұқсаттарды «қызметкер» деп аталатын бір жалпы рөлге қосуға болады және жоғары деңгейлі рөлдердің әрқайсысында барлық негізгі құқықтарды қайта-қайта тізімдеудің қажеті болмайды. «Қызметкер» рөлінің мұрагерлік сипаттамасын көрсету жеткілікті.
Кейінірек стандарт үнемі өзгеріп отыратын ортаға қатысты жаңа қолжетімділік атрибуттарымен толықтырылды. Статикалық және динамикалық шектеулерді енгізу мүмкіндігі қосылды. Статикалық рөлдерді біріктірудің мүмкін еместігін білдіреді (жоғарыда аталған операцияларды бірдей енгізу және басқару). Динамикалық шектеулерді параметрлерді өзгерту арқылы анықтауға болады, мысалы, уақыт (жұмыс/жұмыс емес сағаттар немесе күндер), орналасқан жер (кеңсе/үй) және т.б.
Оны бөлек атап өткен жөн атрибутқа негізделген қол жеткізуді басқару (ABAC - Attribute-based access control). Тәсіл атрибуттарды ортақ пайдалану ережелерін пайдалану арқылы рұқсат беруге негізделген. Бұл модельді бөлек қолдануға болады, бірақ ол классикалық рөлдік үлгіні белсенді түрде толықтырады: белгілі бір рөлге пайдаланушылардың, ресурстар мен құрылғылардың атрибуттары, сондай-ақ уақыт немесе орын қосылуы мүмкін. Бұл азырақ рөлдерді пайдалануға, қосымша шектеулер енгізуге және мүмкіндігінше минималды қатынасты жасауға, демек қауіпсіздікті жақсартуға мүмкіндік береді.
Мысалы, егер ол белгілі бір аймақта жұмыс істейтін болса, бухгалтерге шоттарға кіруге рұқсат етілуі мүмкін. Содан кейін маманның орналасқан жері белгілі бір анықтамалық мәнмен салыстырылады. Немесе пайдаланушы рұқсат етілгендер тізіміне енгізілген құрылғыдан кірген жағдайда ғана тіркелгілерге рұқсат бере аласыз. Үлгіге жақсы қосымша, бірақ көптеген ережелер мен рұқсаттар немесе шектеулер кестелерін жасау қажеттілігіне байланысты өздігінен сирек пайдаланылады.
Менің «өткен өмірімнен» ABAC қолданудың мысалын келтірейін. Біздің банктің бірнеше филиалдары болды. Бұл филиалдардағы клиенттік кеңселердің қызметкерлері дәл осындай операцияларды орындады, бірақ негізгі жүйеде тек өз аймағындағы шоттармен жұмыс істеуге тура келді. Біріншіден, біз әр аймақ үшін бөлек рөлдерді жасай бастадық - және қайталанатын функционалдығы бар, бірақ әртүрлі тіркелгілерге қол жетімділігі бар мұндай рөлдер өте көп болды! Содан кейін пайдаланушыға арналған орын төлсипатын пайдалану және оны тексеру үшін тіркелгілердің белгілі бір ауқымымен байланыстыру арқылы жүйедегі рөлдердің санын айтарлықтай азайттық. Нәтижесінде банктің барлық басқа аумақтық бөлімшелеріндегі сәйкес лауазымдарға қайталанған бір филиалға ғана рөлдер қалды.
Енді қажетті дайындық қадамдары туралы сөйлесейік, онсыз жұмыс үлгісін құру мүмкін емес.
1-қадам. Функционалдық модельді құру
Сіз функционалдық үлгіні - әрбір бөлімнің және әрбір лауазымның функционалдығын егжей-тегжейлі сипаттайтын жоғары деңгейлі құжатты жасаудан бастауыңыз керек. Әдетте, ақпарат оны әртүрлі құжаттардан енгізеді: лауазымдық нұсқаулықтар және жеке бөлімшелер үшін ережелер - департаменттер, бөлімдер, бөлімдер. Функционалдық үлгі барлық мүдделі бөлімдермен (бизнес, ішкі бақылау, қауіпсіздік) келісілуі және компания басшылығымен бекітілуі керек. Бұл құжат не үшін? Үлгі алатын адам оған сілтеме жасай алуы үшін. Мысалы, сіз жүйеден босатылған және «ортақ бөлгішке дейін қысқартылған» қызметкерлердің қолданыстағы құқықтарына негізделген үлгі үлгісін құрасыз. Содан кейін жүйенің бизнес иесімен алынған рөлдерді келісу кезінде сіз функционалдық үлгідегі белгілі бір нүктеге сілтеме жасай аласыз, оның негізінде осы немесе басқа құқық рөлге кіреді.
2-қадам. Біз АТ жүйелерін тексереміз және басымдықтарды белгілеу жоспарын жасаймыз
Екінші кезеңде оларға қол жеткізу қалай ұйымдастырылғанын түсіну үшін АТ жүйелеріне аудит жүргізу керек. Мысалы, менің қаржылық компаниям бірнеше жүздеген ақпараттық жүйелерді басқарды. Барлық жүйелерде рөлге негізделген басқарудың кейбір негіздері болды, көпшілігінің кейбір рөлдері болды, бірақ көбінесе қағазда немесе жүйелік каталогта болды - олар бұрыннан ескірген және оларға қол жеткізу нақты пайдаланушы сұраулары негізінде берілген. Әрине, бірден бірнеше жүздеген жүйеде үлгі құру мүмкін емес, бір жерден бастау керек. Біз оның жетілу деңгейін анықтау үшін қол жеткізуді басқару процесіне терең талдау жасадық. Талдау процесінде ақпараттық жүйелерге басымдық беру критерийлері әзірленді - сынилік, дайындық, пайдаланудан шығару жоспарлары және т.б. Олардың көмегімен біз осы жүйелер үшін үлгі үлгілерін әзірлеуді/жаңартуды жоспарладық. Содан кейін біз қол жеткізуді басқаруды автоматтандыру үшін Identity Management шешімімен біріктіру жоспарына рөлдік үлгілерді енгіздік.
Сонымен, жүйенің критикалық деңгейін қалай анықтауға болады? Өзіңізге келесі сұрақтарға жауап беріңіз:
- Жүйе компанияның негізгі қызметі тәуелді операциялық процестермен байланысты ма?
- Жүйенің бұзылуы компания активтерінің тұтастығына әсер ете ме?
- Жүйенің максималды рұқсат етілген тоқтап қалу уақыты қандай, ол үзілістен кейін белсенділікті қалпына келтіру мүмкін емес?
- Жүйедегі ақпараттың тұтастығын бұзу қаржылық жағынан да, беделі үшін де қайтымсыз салдарға әкелуі мүмкін бе?
- Алаяқтыққа сын. Функционалдылықтың болуы, егер дұрыс бақыланбаса, ішкі/сыртқы алаяқтық әрекеттерге әкелуі мүмкін;
- Бұл жүйелер үшін қандай заң талаптары мен ішкі ережелер мен процедуралар бар? Сәйкес келмегені үшін реттеуші органдардан айыппұл салынады ма?
Біздің қаржылық компанияда біз осындай аудит жүргіздік. Басшылық ең жоғары басымдық тізімінде тұрған ақпараттық жүйелердегі бар пайдаланушылар мен құқықтарды бірінші кезекте қарау үшін Access құқықтарын шолу аудит процедурасын әзірледі. Бұл процестің иесі ретінде қауіпсіздік бөлімі тағайындалды. Бірақ компаниядағы қол жеткізу құқықтарының толық бейнесін алу үшін процеске IT және бизнес бөлімдерін тарту қажет болды. Міне, дау-дамай, түсінбеушілік, кейде тіпті саботаж да басталды: ешкім қазіргі міндеттерінен қол үзіп, бір қарағанда, түсініксіз істерге араласқысы келмейді.
NB Дамыған АТ процестері бар ірі компаниялар АТ аудит процедурасымен таныс болуы мүмкін - IT процестеріндегі кемшіліктерді анықтауға және процестерді озық тәжірибеге (ITIL, COBIT, IT) сәйкес жақсарту үшін бақылау орнатуға мүмкіндік беретін АТ жалпы бақылаулары (ITGC) Басқару және т.б.) Мұндай аудит АТ пен бизнеске бір-бірін жақсы түсінуге және бірлескен даму стратегиясын жасауға, тәуекелдерді талдауға, шығындарды оңтайландыруға және жұмысқа неғұрлым тиімді тәсілдерді әзірлеуге мүмкіндік береді.
Аудиттің бағыттарының бірі ақпараттық жүйелерге логикалық және физикалық қол жеткізу параметрлерін анықтау болып табылады. Алынған мәліметтерді біз үлгі үлгісін құруда одан әрі пайдалану үшін негіз ретінде алдық. Осы аудиттің нәтижесінде бізде АТ жүйелерінің тізілімі болды, онда олардың техникалық параметрлері анықталып, сипаттамалар берілді. Сонымен қатар, әрбір жүйе үшін оның мүдделері үшін жұмыс істейтін бизнес бағыты бойынша меншік иесі анықталды: ол осы жүйе қызмет ететін бизнес-процестерге жауапты болды. Сондай-ақ нақты АЖ үшін бизнес қажеттіліктерін техникалық жүзеге асыруға жауапты АТ-сервис менеджері тағайындалды. Кәсіпорын үшін ең маңызды жүйелер және олардың техникалық параметрлері, іске қосу және пайдаланудан шығару мерзімдері және т.б. жазылды.Бұл параметрлер үлгі құруға дайындық процесінде өте пайдалы болды.
3-қадам Әдістеме құру
Кез келген бизнестің табысының кілті - дұрыс әдіс. Сондықтан үлгіні қалыптастыру үшін де, аудит жүргізу үшін де біз бөлімдер арасындағы өзара әрекеттесуді сипаттайтын әдістемені құруымыз керек, компанияның ережелерінде жауапкершілікті белгілейміз және т.б.
Алдымен қол жетімділік пен құқықтарды беру тәртібін белгілейтін барлық қолда бар құжаттарды тексеру керек. Жақсы түрде, процестер бірнеше деңгейде құжатталуы керек:
- жалпы корпоративтік талаптар;
- ақпараттық қауіпсіздік салаларына қойылатын талаптар (ұйым қызметінің бағыттарына байланысты);
- технологиялық процестерге қойылатын талаптар (нұсқаулар, қол жеткізу матрицалары, нұсқаулар, конфигурация талаптары).
Біздің қаржылық компанияда біз көптеген ескірген құжаттарды таптық, оларды енгізіліп жатқан жаңа процестерге сәйкес келтіруге тура келді.
Басшылықтың бұйрығымен жұмыс тобы құрылды, оның құрамына қауіпсіздік, IT, бизнес және ішкі бақылау өкілдері кірді. Бұйрықта топты құру мақсаттары, қызмет бағыты, қызмет ету мерзімі және әр тараптың жауаптылары көрсетілген. Сонымен қатар, біз аудит әдістемесін және үлгі үлгісін құру тәртібін әзірледік: олар облыстардың барлық жауапты өкілдерімен келісілді және компания басшылығымен бекітілді.
Жұмыстарды орындау тәртібін, орындалу мерзімін, жауапкершілігін және т.б. сипаттайтын құжаттар. - бастапқыда барлығына түсінікті бола бермейтін мақсатқа жету жолында ешкімде «неге бұлай істеп жатырмыз, бұл бізге не үшін керек және т.б.» деген сұрақтардың болмайтынына кепілдік. және процесті «секіруге» немесе баяулатуға мүмкіндік болмайды.
Қадам 4. Қолданыстағы қол жеткізуді басқару үлгісінің параметрлерін түзетіңіз
Біз қол жеткізуді басқару тұрғысынан «жүйелік төлқұжат» деп аталатын құжатты жасаймыз. Негізінде, бұл оған қол жеткізуді басқарудың барлық алгоритмдерін жазатын белгілі бір ақпараттық жүйедегі сауалнама. IdM класындағы шешімдерді енгізген компаниялар мұндай сауалнамамен таныс болуы мүмкін, өйткені жүйелерді зерттеу осы жерден басталады.
Жүйе мен иелері туралы кейбір параметрлер АТ тізілімінен сауалнамаға жіберілді (2-қадамды қараңыз, аудит), бірақ жаңалары да қосылды:
- тіркелгілер қалай басқарылады (тікелей дерекқорда немесе бағдарламалық интерфейстер арқылы);
- пайдаланушылардың жүйеге қалай кіретіні (бөлек тіркелгіні пайдалану немесе AD тіркелгісін, LDAP және т.б. пайдалану);
- жүйеге қол жеткізудің қандай деңгейлері қолданылады (қолданбалы деңгей, жүйе деңгейі, желілік файл ресурстарының жүйелік қолданылуы);
- жүйе жұмыс істейтін серверлердің сипаттамасы мен параметрлері;
- қандай есептік жазбаны басқару операцияларына қолдау көрсетіледі (блоктау, атын өзгерту және т.б.);
- жүйе пайдаланушысының идентификаторын құру үшін қандай алгоритмдер немесе ережелер қолданылады;
- персоналды басқару жүйесіндегі қызметкердің жазбасымен байланысты орнату үшін қандай атрибутты пайдалануға болады (аты-жөні, персонал нөмірі және т.б.);
- барлық ықтимал тіркелгі атрибуттары және оларды толтыру ережелері;
- жүйеде қандай қол жеткізу құқықтары бар (рөлдер, топтар, атомдық құқықтар және т.б. кірістірілген немесе иерархиялық құқықтар бар ма);
- қол жеткізу құқықтарын бөлу тетіктері (лауазымы, бөлімшелері, функционалдығы және т.б. бойынша);
- Жүйеде құқықтарды бөлу ережелері бар ма (SOD – Segregation of Duties) және олар қалай жұмыс істейді;
- жүйеде жұмыста болмау, ауыстыру, жұмыстан босату, қызметкерлер деректерін жаңарту және т.б. оқиғалар қалай өңделеді.
Бұл тізімді әр түрлі параметрлерді және қол жеткізуді басқару процесіне қатысатын басқа объектілерді егжей-тегжейлі көрсете отырып жалғастыруға болады.
5-қадам. Рұқсаттардың бизнеске бағытталған сипаттамасын жасаңыз
Үлгіні құру кезінде бізге қажет болатын тағы бір құжат - ақпараттық жүйедегі пайдаланушыларға оның артында тұрған бизнес функциясының егжей-тегжейлі сипаттамасымен берілуі мүмкін барлық мүмкін өкілеттіктер (құқықтар) туралы анықтамалық. Көбінесе жүйедегі билік әріптер мен сандардан тұратын белгілі бір атаулармен шифрланады және бизнес қызметкерлері бұл белгілердің артында не жатқанын анықтай алмайды. Содан кейін олар IT-қызметіне барады, сонда... олар да сұраққа жауап бере алмайды, мысалы, сирек қолданылатын құқықтар туралы. Содан кейін қосымша сынақтан өту керек.
Бизнес сипаттамасы әлдеқашан бар болса немесе осы құқықтардың топтар мен рөлдерге тіркесімі болса жақсы. Кейбір қолданбалар үшін әзірлеу сатысында осындай анықтаманы жасау ең жақсы тәжірибе болып табылады. Бірақ бұл жиі бола бермейді, сондықтан біз барлық ықтимал құқықтар туралы ақпаратты жинау және оларды сипаттау үшін IT бөліміне қайта барамыз. Біздің нұсқаулықта сайып келгенде мыналар болады:
- қол жеткізу құқығы қолданылатын объектіні қоса алғанда, уәкілетті органның атауы;
- объектімен жасауға рұқсат етілген әрекет (қарау, өзгерту және т.б. шектеу мүмкіндігі, мысалы, аумақтық негізде немесе клиенттер тобы бойынша);
- авторизация коды (авторизацияны пайдалана отырып орындауға болатын жүйе функциясының/сұраныстың коды және атауы);
- уәкілетті органның сипаттамасы (өкілдікті қолдану кезіндегі АЖ-дағы әрекеттердің толық сипаттамасы және олардың процесс үшін салдары;
- рұқсат күйі: «Белсенді» (егер рұқсат кем дегенде бір пайдаланушыға тағайындалған болса) немесе «Белсенді емес» (рұқсат пайдаланылмаса).
6-қадам Жүйелерден пайдаланушылар мен құқықтар туралы деректерді жүктеп алып, оларды персонал көзімен салыстырамыз
Дайындықтың соңғы кезеңінде барлық пайдаланушылар мен олардың қазіргі уақыттағы құқықтары туралы ақпараттық жүйелерден деректерді жүктеп алу қажет. Мұнда екі ықтимал сценарий бар. Біріншіден: қауіпсіздік бөлімі жүйеге тікелей қол жеткізе алады және тиісті есептерді жүктеп алу мүмкіндігі бар, бұл жиі бола бермейді, бірақ өте ыңғайлы. Екіншіден: біз АТ-қа қажетті форматта есептерді алу үшін сұраныс жібереміз. Тәжірибе көрсеткендей, АТ-пен келісімге келіп, бірінші рет қажетті деректерді алу мүмкін емес. Ақпарат қажетті формада және форматта алынғанша бірнеше тәсілдерді жасау қажет.
Қандай деректерді жүктеп алу керек:
- Төлем алушы
- Ол тағайындалған қызметкердің толық аты-жөні
- Күй (белсенді немесе блокталған)
- Тіркелгіні жасау күні
- Соңғы пайдалану күні
- Қолжетімді құқықтар/топтар/рөлдер тізімі
Осылайша, біз жүйеден барлық пайдаланушылармен және оларға берілген барлық құқықтармен жүктеп алдық. Және олар барлық бұғатталған тіркелгілерді дереу алып тастады, өйткені үлгі құру жұмысы тек белсенді пайдаланушылар үшін жүргізіледі.
Содан кейін, егер сіздің компанияңызда жұмыстан босатылған қызметкерлерге кіруді блоктаудың автоматтандырылған құралдары болмаса (бұл жиі орын алады) немесе әрқашан дұрыс жұмыс істемейтін патчворк автоматтандыруы болса, сіз барлық «өлі жандарды» анықтауыңыз керек. Әңгіме әлдеқашан жұмыстан шығарылған, қандай да бір себептермен құқықтары бұғатталмаған қызметкерлердің есепшоттары туралы болып отыр – бұғаттау керек. Ол үшін жүктелген деректерді персонал көзімен салыстырамыз. Персоналды түсіру сонымен қатар персонал базасын жүргізетін бөлімнен алдын ала алынуы керек.
Бөлек, қожайындары кадр базасында табылмаған, ешкімге бекітілмеген, яғни иесіз шоттарды бөлек қою керек. Бұл тізімді пайдалана отырып, бізге соңғы пайдалану күні қажет болады: егер ол жақында болса, біз әлі де иелерін іздеуіміз керек. Бұған ешкімге тағайындалмаған, бірақ кез келген процестермен байланыстырылған сыртқы мердігерлердің шоттары немесе қызмет тіркелгілері кіруі мүмкін. Есептік жазбалардың кімге тиесілі екенін білу үшін сіз барлық бөлімдерге жауап беруді сұрайтын хаттар жібере аласыз. Иелері табылған кезде біз олар туралы деректерді жүйеге енгіземіз: осылайша барлық белсенді тіркелгілер анықталады, ал қалғандары блокталады.
Жүктеп салуларымыз қажетсіз жазбалардан тазартылып, тек белсенді тіркелгілер ғана қалған кезде, біз белгілі бір ақпараттық жүйе үшін үлгі жасауды бастай аламыз. Бірақ мен бұл туралы келесі мақалада айтамын.
Авторы: Людмила Севастьянова, Solar inRights промоутерлік менеджері
Ақпарат көзі: www.habr.com