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