Градимо модел контроле приступа заснован на улогама. Први део, припремни

Тренутно радим за продавца софтвера, посебно решења за контролу приступа. А моје искуство "из прошлог живота" повезано је са страном купца - великом финансијском организацијом. Тада се наша група за контролу приступа у одељењу информационе безбедности није могла похвалити великим компетенцијама у ИдМ-у. Много смо научили у том процесу, морали смо да ударимо много неравнина да бисмо изградили радни механизам за управљање корисничким правима у информационим системима у компанији.

Комбинујући своје тешко стечено корисничко искуство са знањем и компетенцијама добављача, желим да поделим са вама у суштини упутства корак по корак: како да креирате модел контроле приступа заснован на улогама у великој компанији и шта ће то дати као резултат . Моје инструкције се састоје из два дела: први се припрема за прављење модела, други се заправо гради. Ево првог дела, припремног дела.

НБ Изградња узора, нажалост, није резултат, већ процес. Или боље речено, чак и део процеса стварања екосистема контроле приступа у компанији. Зато се спремите за игру на дуже време.

Прво, хајде да то дефинишемо – шта је контрола приступа заснована на улогама? Претпоставимо да имате велику банку са десетинама, па чак и стотинама хиљада запослених (ентитета), од којих сваки има десетине права приступа стотинама интерних банкарских информационих система (објеката). Сада помножите број објеката са бројем субјеката - ово је минимални број веза који морате прво да изградите, а затим да контролишете. Да ли је то заиста могуће урадити ручно? Наравно да не – улоге су створене да реше овај проблем.

Улога је скуп дозвола које су кориснику или групи корисника потребне за обављање одређених радних задатака. Сваки запослени може имати једну или више улога, а свака улога може садржати од једне до више дозвола које су дозвољене кориснику у оквиру те улоге. Улоге могу бити везане за одређене позиције, одељења или функционалне задатке запослених.

Улоге се обично креирају из појединачних овлашћења запослених у сваком информационом систему. Тада се од улога сваког система формирају глобалне пословне улоге. На пример, пословна улога „кредитни менаџер“ ће укључивати неколико одвојених улога у информационим системима који се користе у канцеларији за клијенте банке. На пример, као што су главни аутоматизовани банкарски систем, готовински модул, систем електронског управљања документима, сервис менаџер и други. Пословне улоге су, по правилу, везане за организациону структуру – другим речима, за скуп подела предузећа и позиција у њима. Овако се формира глобална матрица улога (дајем пример у табели испод).

Вреди напоменути да је једноставно немогуће изградити 100% узор, пружајући сва потребна права запосленима на свакој позицији у комерцијалној структури. Да, ово није неопходно. На крају крајева, узор не може бити статичан, јер зависи од окружења које се стално мења. И од промена у пословним активностима компаније, што, сходно томе, утиче на промене у организационој структури и функционалности. И од недостатка пуног обезбеђења ресурса, и од непоштовања описа послова, и од жеље за профитом на уштрб безбедности, и од многих других фактора. Због тога је потребно изградити узор који може да покрије до 80% потреба корисника за неопходним основним правима приликом распоређивања на позицију. А они ће моћи, ако буде потребно, да затраже преосталих 20% касније у посебним апликацијама.

Наравно, можете се запитати: „Зар не постоји таква ствар као 100% узори?“ Па, зашто, то се дешава, на пример, у непрофитним структурама које нису подложне честим променама – у неком истраживачком институту. Или у организацијама војно-индустријског комплекса са високим нивоом безбедности, где је безбедност на првом месту. То се дешава у комерцијалној структури, али у оквиру посебне дивизије, чији је рад прилично статичан и предвидљив процес.

Основна предност управљања заснованог на улогама је поједностављење издавања права, јер је број улога знатно мањи од броја корисника информационог система. И ово важи за било коју индустрију.

Узмимо малопродајну компанију: она запошљава хиљаде продаваца, али они имају исти скуп права у систему Н, и за њих ће бити креирана само једна улога. Када нови продавац дође у компанију, аутоматски му се додељује потребна улога у систему, који већ има сва потребна овлашћења. Такође, једним кликом можете променити права за хиљаде продаваца одједном, на пример, додати нову опцију за генерисање извештаја. Нема потребе да радите хиљаду операција, повезујући ново право са сваким налогом - само додајте ову опцију у улогу и она ће се појавити за све продавце у исто време.

Још једна предност управљања заснованог на улогама је елиминисање издавања некомпатибилних овлашћења. Односно, запослени који има одређену улогу у систему не може истовремено имати другу улогу, чија права не треба комбиновати са правима из прве. Упечатљив пример је забрана комбиновања функција уноса и контроле финансијске трансакције.

Свако кога занима како је настала контрола приступа заснована на улогама може
зарони у историју
Ако погледамо историју, ИТ заједница је први пут размишљала о методама контроле приступа још 70-их година XNUMX. века. Иако су тада апликације биле прилично једноставне, као и сада, сви су заиста желели да им лако управљају приступом. Доделите, промените и контролишете корисничка права – само да бисте лакше разумели који приступ има свако од њих. Али у то време није било заједничких стандарда, развијали су се први системи контроле приступа, а свака компанија се заснивала на сопственим идејама и правилима.

Сада је познато много различитих модела контроле приступа, али се нису појавили одмах. Да се ​​задржимо на онима који су дали значајан допринос развоју ове области.

Први и вероватно најједноставнији модел је Дискрециона (селективна) контрола приступа (ДАЦ – Дискрециона контрола приступа). Овај модел подразумева дељење права свих учесника у процесу приступа. Сваки корисник има приступ одређеним објектима или операцијама. У суштини, овде скуп субјеката права одговара скупу објеката. Утврђено је да је овај модел превише флексибилан и претежак за одржавање: листе приступа на крају постају огромне и тешко их је контролисати.

Други модел је Обавезна контрола приступа (МАЦ - обавезна контрола приступа). Према овом моделу, сваки корисник добија приступ објекту у складу са издатим приступом одређеном нивоу поверљивости података. Сходно томе, објекте треба категорисати према њиховом нивоу поверљивости. За разлику од првог флексибилног модела, овај се, напротив, показао превише строгим и рестриктивним. Његова употреба није оправдана када компанија има много различитих информационих ресурса: да бисте разликовали приступ различитим ресурсима, мораћете да уведете много категорија које се неће преклапати.

Због очигледних несавршености ове две методе, ИТ заједница је наставила да развија моделе који су флексибилнији и истовремено мање-више универзални за подршку различитим типовима организационих политика контроле приступа. А онда се појавило трећи модел контроле приступа заснован на улози! Овај приступ се показао као најперспективнији јер захтева не само ауторизацију идентитета корисника, већ и његове оперативне функције у системима.

Прву јасно описану структуру узора предложили су амерички научници Давид Фераило и Рицхард Кухн са америчког Националног института за стандарде и технологију 1992. године. Тада се први пут појавио термин РБАЦ (контрола приступа заснована на улогама). Ове студије и описи главних компоненти, као и њихови односи, чинили су основу стандарда ИНЦИТС 359-2012, који је и данас на снази, одобрен од стране Међународног комитета за стандарде информационих технологија (ИНЦИТС).

Стандард дефинише улогу као „радну функцију у контексту организације са неком повезаном семантиком у вези са овлашћењима и одговорностима додељеним кориснику који је додељен улози“. Документ утврђује основне елементе РБАЦ-а – кориснике, сесије, улоге, дозволе, операције и објекте, као и односе и међусобне везе између њих.

Стандард обезбеђује минималну неопходну структуру за изградњу узора – комбиновање права у улоге и затим додељивање приступа корисницима преко ових улога. Наведени су механизми за састављање улога из објеката и операција, описана је хијерархија улога и наслеђивање овлашћења. На крају крајева, у било којој компанији постоје улоге које комбинују основна овлашћења која су неопходна за све запослене у компанији. Ово може бити приступ е-пошти, ЕДМС, корпоративном порталу, итд. Ове дозволе могу бити укључене у једну општу улогу која се зове „запослени“, и неће бити потребе да се изнова и изнова наводе сва основна права у свакој од улога вишег нивоа. Довољно је једноставно назначити карактеристику наслеђивања улоге „запосленог“.

Касније је стандард допуњен новим атрибутима приступа који се односе на окружење које се стално мења. Додата је могућност увођења статичких и динамичких ограничења. Статички подразумевају немогућност комбиновања улога (исти унос и контрола операција поменутих горе). Динамичка ограничења се могу одредити променом параметара, на пример, времена (радни/нерадни сати или дани), локације (канцеларија/кућа) итд.

Одвојено, треба рећи о контрола приступа заснована на атрибутима (АБАЦ - Аттрибуте-басед аццесс цонтрол). Приступ се заснива на давању приступа коришћењем правила дељења атрибута. Овај модел се може користити одвојено, али прилично често активно допуњује класични узор: одређеној улози се могу додати атрибути корисника, ресурса и уређаја, као и време или локација. Ово вам омогућава да користите мање улога, уведете додатна ограничења и учините приступ што је могуће мањим, а самим тим и побољшате безбедност.

На пример, рачуновођи се може дозволити приступ рачунима ако ради у одређеном региону. Тада ће се локација специјалисте упоредити са одређеном референтном вредношћу. Или можете дати приступ налозима само ако се корисник пријави са уређаја који је укључен у листу дозвољених. Добар додатак узору, али се ретко користи самостално због потребе за креирањем многих правила и табела дозвола или ограничења.

Дозволите ми да вам дам пример коришћења АБАЦ-а из мог „прошлог живота“. Наша банка је имала неколико експозитура. Запослени у клијентским канцеларијама у овим филијалама обављали су потпуно исте операције, али су морали да раде у главном систему само са рачунима у свом региону. Прво смо почели да креирамо засебне улоге за сваки регион – а било је толико таквих улога са понављајућим функцијама, али са приступом различитим налозима! Затим, коришћењем атрибута локације за корисника и повезивањем са одређеним опсегом налога за преглед, значајно смо смањили број улога у систему. Као резултат тога, улоге су остале само за једну филијалу, које су пресликане на одговарајуће позиције у свим осталим територијалним одељењима банке.

Хајде сада да разговарамо о неопходним припремним корацима, без којих је једноставно немогуће изградити радни узор.

Корак 1. Креирајте функционални модел

Требало би да почнете са креирањем функционалног модела – документа највишег нивоа који детаљно описује функционалност сваког одељења и сваке позиције. По правилу, информације у њега улазе из различитих докумената: описа послова и правилника за поједине јединице - одељења, одељења, одељења. Функционални модел мора бити усаглашен са свим заинтересованим одељењима (пословање, интерна контрола, безбедност) и одобрен од руководства компаније. Чему служи овај документ? Да би се узор могао на то позивати. На пример, градићете узор на основу постојећих права запослених – истоварен из система и „сведен на заједнички именитељ“. Затим, када се договарате о примљеним улогама са власником пословања система, можете се позвати на одређену тачку у функционалном моделу, на основу које је ово или оно право укључено у улогу.

Корак 2. Вршимо ревизију ИТ система и правимо план приоритета

У другој фази, требало би да извршите ревизију ИТ система да бисте разумели како је организован приступ њима. На пример, моја финансијска компанија је управљала са неколико стотина информационих система. Сви системи су имали неке рудименте управљања заснованог на улогама, већина је имала неке улоге, али углавном на папиру или у системском директоријуму - били су одавно застарели, а приступ им је одобрен на основу стварних захтева корисника. Наравно, једноставно је немогуће изградити узор у неколико стотина система одједном, од негде се мора почети. Спровели смо детаљну анализу процеса контроле приступа да бисмо утврдили ниво његове зрелости. Током процеса анализе развијени су критеријуми за одређивање приоритета информационих система – критичност, спремност, планови за разградњу итд. Уз њихову помоћ поставили смо развој/ажурирање узора за ове системе. Затим смо укључили узоре у план за интеграцију са решењем за управљање идентитетом за аутоматизацију контроле приступа.

Како онда одредити критичност система? Одговорите себи на следећа питања:

• Да ли је систем повезан са оперативним процесима од којих зависе основне активности компаније?
• Да ли ће поремећај система утицати на интегритет имовине компаније?
• Које је максимално дозвољено време застоја система, до којег је немогуће вратити активност након прекида?
• Може ли нарушавање интегритета информација у систему довести до неповратних последица, како финансијских тако и репутационих?
• Критичност према превари. Присуство функционалности, ако није правилно контролисано, може довести до интерних/спољних лажних радњи;
• Који су правни захтеви и интерна правила и процедуре за ове системе? Да ли ће регулатори бити кажњени за непоштовање?

У нашој финансијској компанији смо урадили овакву ревизију. Менаџмент је развио процедуру ревизије за преглед права приступа да прво погледа постојеће кориснике и права у оним информационим системима који су били на листи највишег приоритета. Одељење безбедности је додељено као власник овог процеса. Али да би се добила потпуна слика о правима приступа у компанији, било је неопходно укључити ИТ и пословна одељења у процес. И ту су почели спорови, неспоразуми, а понекад и саботаже: нико не жели да се отргне од својих садашњих обавеза и упусти у неке, на први поглед, несхватљиве активности.

НБ Велике компаније са развијеним ИТ процесима вероватно су упознате са процедуром ИТ ревизије – ИТ генералним контролама (ИТГЦ), која вам омогућава да идентификујете недостатке у ИТ процесима и успоставите контролу како бисте унапредили процесе у складу са најбољом праксом (ИТИЛ, ЦОБИТ, ИТ Управљање итд.) Таква ревизија омогућава ИТ и бизнису да се боље разумеју и развију заједничку развојну стратегију, анализирају ризике, оптимизују трошкове и развију ефикасније приступе раду.



Једна од области ревизије је утврђивање параметара логичког и физичког приступа информационим системима. Добијене податке узели смо као основу за даљу употребу у изградњи узора. Као резултат ове ревизије, имали смо регистар ИТ система у коме су утврђени њихови технички параметри и дати описи. Поред тога, за сваки систем је идентификован власник из пословног правца у чијем је интересу функционисао: он је био одговоран за пословне процесе којима је овај систем служио. Именован је и менаџер ИТ сервиса, задужен за техничку имплементацију пословних потреба за одређени ИС. Забележени су најкритичнији системи за компанију и њихови технички параметри, рокови пуштања у рад и декомисије итд. Ови параметри су били од велике помоћи у процесу припреме за креирање узора.

Корак 3 Креирајте методологију

Кључ успеха сваког посла је прави метод. Дакле, и да бисмо изградили узор и да бисмо спровели ревизију, потребно је да направимо методологију у којој ћемо описати интеракцију између одељења, успоставити одговорност у прописима компаније итд.
Прво морате испитати све доступне документе који утврђују процедуру за давање приступа и права. На добар начин, процеси треба да буду документовани на неколико нивоа:

• општи корпоративни захтеви;
• захтеви за области информационе безбедности (у зависности од области активности организације);
• захтеви за технолошке процесе (упутства, приступне матрице, смернице, конфигурациони захтеви).

У нашој финансијској компанији нашли смо доста застарелих докумената које смо морали да ускладимо са новим процесима који се примењују.

По налогу руководства формирана је радна група у којој су били представници безбедности, информатике, пословања и интерне контроле. У наредби су наведени циљеви стварања групе, правац деловања, период постојања и одговорни са сваке стране. Поред тога, развили смо методологију ревизије и процедуру за конструисање узора: сагласни су од стране свих одговорних представника области и одобрени од стране менаџмента компаније.

Документи који описују поступак извођења радова, рокове, одговорности итд. - гаранција да на путу ка запаженом циљу, који у почетку није свима очигледан, нико неће имати питања „зашто то радимо, зашто нам је то потребно, итд.“ и неће бити прилике да се „скочи“ или успори процес.

Корак 4. Поправите параметре постојећег модела контроле приступа

Израђујемо такозвани „системски пасош“ у смислу контроле приступа. У суштини, ово је упитник о одређеном информационом систему, који бележи све алгоритме за контролу приступа њему. Компаније које су већ имплементирале решења ИдМ класе вероватно су упознате са таквим упитником, јер ту почиње проучавање система.

Неки параметри о систему и власницима ушли су у упитник из ИТ регистра (погледајте корак 2, ревизија), али су додати и нови:

• како се управља налозима (директно у бази података или преко софтверских интерфејса);
• како се корисници пријављују на систем (користећи посебан налог или користећи АД налог, ЛДАП, итд.);
• који нивои приступа систему се користе (ниво апликације, ниво система, системско коришћење ресурса мрежних датотека);
• опис и параметре сервера на којима систем ради;
• које операције управљања налогом су подржане (блокирање, преименовање, итд.);
• који алгоритми или правила се користе за генерисање идентификатора корисника система;
• који атрибут се може користити за успостављање везе са евиденцијом запосленог у кадровском систему (пуно име, број особља, итд.);
• све могуће атрибуте налога и правила за њихово попуњавање;
• која права приступа постоје у систему (улоге, групе, атомска права, итд., да ли постоје угнежђена или хијерархијска права);
• механизми за поделу права приступа (по позицији, одељењу, функционалности итд.);
• Да ли систем има правила за сегрегацију права (СОД – Сегрегатион оф Дутиес) и како она функционишу;
• како се у систему обрађују догађаји одсуства, премештаја, отпуштања, ажурирања података о запосленима итд.

Ова листа се може наставити, са детаљима о различитим параметрима и другим објектима који су укључени у процес контроле приступа.

Корак 5. Направите пословно оријентисан опис дозвола

Други документ који ће нам бити потребан при изградњи узора је приручник о свим могућим овлашћењима (правама) која се могу доделити корисницима у информационом систему са детаљним описом пословне функције која стоји иза тога. Често су ауторитети у систему шифровани одређеним именима која се састоје од слова и бројева, а пословни запослени не могу да схвате шта се крије иза ових симбола. Онда оду у ИТ службу, а тамо... такође не могу да одговоре на питање, на пример, о ретко коришћеним правима. Затим је потребно извршити додатна испитивања.

Добро је ако већ постоји опис пословања или чак ако постоји комбинација ових права у групе и улоге. За неке апликације, најбоља пракса је креирање такве референце у фази развоја. Али то се не дешава често, па поново идемо у ИТ одељење да прикупимо информације о свим могућим правима и опишемо их. Наш водич ће на крају садржати следеће:

• назив органа, укључујући објекат на који се односи право приступа;
• радња која је дозвољена да се уради са објектом (гледање, промена, итд., могућност ограничења, на пример, по територијалној основи или групи клијената);
• ауторизациони код (шифра и назив системске функције/захтева који се може извршити коришћењем ауторизације);
• опис овлашћења (детаљан опис радњи у ИС-у при примени овлашћења и њихових последица по процес;
• статус дозволе: „Активно“ (ако је дозвола додељена најмање једном кориснику) или „Није активно“ (ако се дозвола не користи).

Корак 6. Преузимамо податке о корисницима и правима из система и упоређујемо их са кадровским извором

У завршној фази припреме потребно је да преузмете податке из информационих система о свим корисницима и правима која тренутно имају. Овде постоје два могућа сценарија. Прво: одељење безбедности има директан приступ систему и има средства за преузимање релевантних извештаја, што се не дешава често, али је веома згодно. Друго: шаљемо захтев ИТ-у да добије извештаје у траженом формату. Искуство показује да није могуће договорити се са ИТ и добити потребне податке из првог пута. Неопходно је направити неколико приступа док се информација не добије у жељеном облику и формату.

Које податке треба преузети:

• Назив налога
• Пуно име и презиме запосленог коме је додељено
• Статус (активан или блокиран)
• Датум креирања налога
• Датум последње употребе
• Листа доступних права/група/улога

Дакле, добили смо преузимања из система са свим корисницима и свим правима која су им додељена. И одмах су оставили све блокиране налоге, јер ће се рад на изградњи узора обављати само за активне кориснике.

Затим, ако ваша компанија нема аутоматизована средства за блокирање приступа отпуштеним запосленима (ово се често дешава) или има сложену аутоматизацију која не функционише увек исправно, морате да идентификујете све „мртве душе“. Реч је о рачунима запослених који су већ отпуштени, чија права из неког разлога нису блокирана – треба их блокирати. Да бисмо то урадили, поредимо учитане податке са извором особља. Искрцај особља се такође мора унапред добити од одељења које води базу података о кадру.

Одвојено, потребно је издвојити рачуне чији власници нису пронађени у кадровској бази података, никоме нису додељени - односно без власника. Користећи ову листу, биће нам потребан датум последње употребе: ако је прилично скорашњи, и даље ћемо морати да тражимо власнике. Ово може укључивати налоге спољних уговарача или услужне налоге који нису никоме додељени, али су повезани са било којим процесом. Да бисте сазнали коме припадају налози, можете послати писма свим одељењима тражећи од њих да одговоре. Када се пронађу власници, уносимо податке о њима у систем: на тај начин се идентификују сви активни налози, а остали блокирани.

Чим наши отпремљени подаци буду очишћени од непотребних записа и остану само активни налози, можемо почети да градимо узор за одређени информациони систем. Али о томе ћу вам рећи у следећем чланку.

Аутор: Људмила Севастјанова, менаџер промоције Солар инРигхтс

Извор: ввв.хабр.цом