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

Моментално работам за продавач на софтвер, конкретно решенија за контрола на пристап. И моето искуство „од минатиот живот“ е поврзано со страната на клиентот - голема финансиска организација. Во тоа време, нашата група за контрола на пристап во одделот за безбедност на информации не можеше да се пофали со големи компетенции во IdM. Научивме многу во процесот, моравме да наидеме на многу нерамнини за да изградиме работен механизам за управување со корисничките права во информациските системи во компанијата.

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

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

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

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

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

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

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

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

Да земеме малопродажна компанија: таа вработува илјадници продавачи, но тие го имаат истиот збир на права во системот N и ќе им се создаде само една улога. Кога ќе дојде нов продавач во компанијата, автоматски му се доделува потребната улога во системот, кој веќе ги има сите потребни овластувања. Исто така, со еден клик можете да ги промените правата за илјадници продавачи одеднаш, на пример, да додадете нова опција за генерирање извештај. Нема потреба да правите илјада операции, поврзувајќи ново право на секоја сметка - само додадете ја оваа опција во улогата и таа ќе се појави за сите продавачи во исто време.

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

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

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

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

Вториот модел е Задолжителна контрола на пристап (MAC - Задолжителна контрола на пристап). Според овој модел, секој корисник добива пристап до објект во согласност со издадениот пристап до одредено ниво на доверливост на податоците. Според тоа, предметите треба да се категоризираат според нивното ниво на доверливост. За разлика од првиот флексибилен модел, овој, напротив, се покажа како премногу строг и рестриктивен. Неговата употреба не е оправдана кога компанијата има многу различни информациски ресурси: за да се разликува пристапот до различни ресурси, ќе мора да воведете многу категории кои нема да се преклопуваат.

Поради очигледните несовршености на овие два методи, ИТ заедницата продолжи да развива модели кои се пофлексибилни и во исто време повеќе или помалку универзални за поддршка на различни видови на организациски политики за контрола на пристап. И тогаш се појави третиот модел за контрола на пристап заснован на улоги! Овој пристап се покажа како најперспективен бидејќи бара не само овластување за идентитетот на корисникот, туку и неговите оперативни функции во системите.

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

Стандардот ја дефинира улогата како „работна функција во контекст на организација со одредена поврзана семантика во однос на авторитетот и одговорноста доделени на корисникот доделен на улогата“. Документот ги утврдува основните елементи на RBAC - корисници, сесии, улоги, дозволи, операции и објекти, како и односите и меѓусебните врски меѓу нив.

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

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

Одделно, треба да се каже за Контрола на пристап базирана на атрибути (ABAC - Контрола на пристап базирана на атрибути). Пристапот се заснова на давање пристап користејќи правила за споделување атрибути. Овој модел може да се користи одделно, но доста често активно го надополнува класичниот модел на улоги: на одредена улога може да се додадат атрибути на корисници, ресурси и уреди, како и време или локација. Ова ви овозможува да користите помалку улоги, да воведете дополнителни ограничувања и да го направите пристапот што е можно помал, а со тоа и да ја подобрите безбедноста.

На пример, на сметководителот може да му се дозволи пристап до сметките ако работи во одреден регион. Потоа, локацијата на специјалистот ќе се спореди со одредена референтна вредност. Или можете да дадете пристап до сметките само ако корисникот се најави од уред вклучен во списокот со дозволени. Добар додаток на модел, но ретко се користи самостојно поради потребата да се создадат многу правила и табели со дозволи или ограничувања.

Дозволете ми да ви дадам пример за користење на ABAC од мојот „минат живот“. Нашата банка имаше неколку филијали. Вработените во канцелариите на клиентите во овие филијали ги извршуваа токму истите операции, но мораа да работат во главниот систем само со сметки во нивниот регион. Прво, почнавме да создаваме посебни улоги за секој регион - и имаше толку многу такви улоги со функционалност за повторување, но со пристап до различни сметки! Потоа, со користење на атрибут локација за корисникот и поврзување со одреден опсег на сметки за прегледување, значително го намаливме бројот на улоги во системот. Како резултат на тоа, улогите останаа само за една филијала, кои беа реплицирани за соодветните позиции во сите други територијални поделби на банката.

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

Чекор 1. Направете функционален модел

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

Чекор 2. Ние вршиме ревизија на ИТ системи и изготвуваме план за приоритизација

Во втората фаза, треба да извршите ревизија на ИТ системи за да разберете како е организиран пристапот до нив. На пример, мојата финансиска компанија управуваше со неколку стотици информациски системи. Сите системи имаа некои зачетоци на управување засновано на улоги, повеќето имаа одредени улоги, но главно на хартија или во системскиот директориум - тие беа одамна застарени, а пристапот до нив беше одобрен врз основа на вистинските барања на корисниците. Секако, едноставно е невозможно да се изгради модел на улоги во неколку стотици системи одеднаш; треба да започнете од некаде. Спроведовме длабинска анализа на процесот на контрола на пристап за да го одредиме неговото ниво на зрелост. Во текот на процесот на анализа беа развиени критериуми за приоретизирање на информациските системи - критичност, подготвеност, планови за деактивирање итн. Со нивна помош го подредивме развојот/ажурирањето на моделите за улоги за овие системи. А потоа вклучивме модели на улоги во планот за интеграција со решението за управување со идентитетот за автоматизирање на контролата на пристапот.

Значи, како да ја одредите критичноста на системот? Одговорете си на следниве прашања:

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

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

NB Големите компании со развиени ИТ процеси веројатно се запознаени со процедурата за ИТ ревизија - IT general controls (ITGC), која ви овозможува да ги идентификувате недостатоците во ИТ процесите и да воспоставите контрола за да ги подобрите процесите во согласност со најдобрата практика (ITIL, COBIT, IT Управување итн.) Таквата ревизија им овозможува на ИТ и бизнисот подобро да се разберат меѓусебно и да развијат заедничка развојна стратегија, да ги анализираат ризиците, да ги оптимизираат трошоците и да развијат поефективни пристапи за работа.



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

Чекор 3 Направете методологија

Клучот за успехот на секој бизнис е вистинскиот метод. Затоа, и за да изградиме модел и да спроведеме ревизија, треба да создадеме методологија во која ќе ја опишеме интеракцијата помеѓу одделенијата, ќе воспоставиме одговорност во регулативите на компанијата итн.
Прво треба да ги испитате сите достапни документи кои ја утврдуваат процедурата за давање пристап и права. На добар начин, процесите треба да се документираат на неколку нивоа:

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

Во нашата финансиска компанија најдовме многу застарени документи, моравме да ги донесеме во согласност со новите процеси што се спроведуваат.

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

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

Чекор 4. Поправете ги параметрите на постоечкиот модел за контрола на пристап

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

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

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

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

Чекор 5. Направете бизнис-ориентиран опис на дозволите

Друг документ што ќе ни треба при градењето на модел за улоги е референтна книга за сите можни овластувања (права) кои можат да им се доделат на корисниците во информацискиот систем со детален опис на деловната функција што стои зад него. Често, властите во системот се шифрирани со одредени имиња што се состојат од букви и бројки, а вработените во деловните субјекти не можат да сфатат што се крие зад овие симболи. Потоа одат во ИТ сервисот, а таму... исто така не можат да одговорат на прашањето, на пример, за ретко користените права. Потоа треба да се направи дополнително тестирање.

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

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

Чекор 6 Преземаме податоци за корисниците и правата од системите и ги споредуваме со изворот на персоналот

Во последната фаза на подготовка, треба да преземете податоци од информатичките системи за сите корисници и правата што тие моментално ги имаат. Тука има две можни сценарија. Прво: одделот за безбедност има директен пристап до системот и има средства за преземање релевантни извештаи, што не се случува често, но е многу погодно. Второ: испраќаме барање до ИТ да прима извештаи во бараниот формат. Искуството покажува дека не е можно да се договорите со ИТ и да ги добиете потребните податоци од прв пат. Потребно е да се направат неколку пристапи додека информациите не се добијат во посакуваната форма и формат.

Кои податоци треба да се преземат:

• Име на сметката
• Целосно име на работникот на кој му е доделено
• Статус (активен или блокиран)
• Датум на креирање сметка
• Датум на последна употреба
• Список на достапни права/групи/улоги

Така, добивме преземања од системот со сите корисници и сите права што им беа доделени. И тие веднаш ги оставија настрана сите блокирани сметки, бидејќи работата на градење на модел ќе се врши само за активни корисници.

Потоа, ако вашата компанија нема автоматизирани средства за блокирање на пристапот до отпуштените вработени (ова често се случува) или има автоматизација на крпеница која не секогаш работи правилно, треба да ги идентификувате сите „мртви души“. Станува збор за сметки на веќе отпуштени вработени, чии права поради некоја причина не се блокирани - тие треба да бидат блокирани. За да го направите ова, ги споредуваме поставените податоци со изворот на персоналот. Растоварувањето на персоналот исто така мора да се добие однапред од одделот што ја одржува базата на податоци за персоналот.

Одделно, неопходно е да се издвојат сметки чии сопственици не се пронајдени во базата на податоци за персоналот, а не се доделени на никого - односно без сопственици. Користејќи ја оваа листа, ќе ни треба датумот на последната употреба: ако е сосема неодамнешен, сепак ќе треба да ги бараме сопствениците. Ова може да вклучува сметки на надворешни изведувачи или сметки за услуги кои не се доделени на никого, но се поврзани со какви било процеси. За да дознаете на кого припаѓаат сметките, можете да испратите писма до сите одделенија барајќи од нив да одговорат. Кога ќе се најдат сопствениците, внесуваме податоци за нив во системот: на овој начин, сите активни сметки се идентификуваат, а останатите се блокирани.

Штом нашите прикачувања се исчистат од непотребните записи и остануваат само активни сметки, можеме да започнеме да градиме пример за одреден информациски систем. Но, јас ќе ви кажам за ова во следната статија.

Автор: Људмила Севастијанова, менаџер за промоција Solar inRights

Извор: www.habr.com