Създаване на ролев модел за управление на достъпа. Част първа, подготвителна

Сега работя в компания за софтуерни решения, особено в областта на управлението на достъпа. Предишният ми опит е свързан с клиента – голяма финансова организация. Тогава нашата група по контрол на достъпа в отдела за информационна безопасност не можеше да се похвали с големи компетенции в областта на IdM. Учихме много в процеса и трябваше да преминем през редица предизвикателства, за да изградим работещ механизъм за управление на правата на потребителите в информационите системи на компанията.

Комбинирайки опита си от клиента с познанията и компетенциите на вендорите, искам да споделя с вас собствена стъпка по стъпка инструкция: как да изградите ролеви модел за управление на достъпа в голяма компания и какво ще постигнете в края. Инструкцията ми се състои от две части: първата – подготвяме се да строим модела, втората – всъщност изграждаме модела. Пред вас е първата част, подготвителната.

Забележка. Изграждането на ролеви модел е, за съжаление, не резултат, а процес. По-точно, това е част от процеса на създаване на екосистема за управление на достъпа в компанията. Така че се настройте за дългосрочна игра.

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

Ролята е набор от правомощия, необходими на потребителя или група потребители за изпълнението на определени работни задачи. Всеки служител може да има една или повече роли, а всяка роля може да съдържа от едно до много правомощия, които са разрешени на потребителя в рамките на тази роля. Ролите могат да бъдат свързани с определени длъжности, подразделения или функционални задачи на служителите.

Ролите обикновено се създават от отделни права на служител в всяка информационна система. След това от ролите на всяка система се формират глобални бизнес роли. Например, бизнес ролята „кредитен мениджър“ ще включва няколко отделни роли в информационните системи, които се използват в клиентския офис на банката. Кажете, в такива системи като основната автоматизирана банкова система, касовия модул, системата за електронен документооборот, сервис-мениджъра и други. Бизнес ролите, като правило, са свързани с организационно-щатната структура – по-просто казано, с набор от подразделения на компанията и длъжностите в тях. Така се формира глобалната роля матрица (примерът е предоставен в таблицата по-долу).

Струва си да се отбележи, че да се изгради 100% роля модел, осигурявайки всички необходими права на служителите за всяка длъжност в търговската структура просто е невъзможно. Да, и не е нужно. Защото ролевият модел не може да бъде статичен, тъй като зависи от постоянно променящата се среда. И от измененията в бизнес дейността на компанията, които, съответно, влияят на промените в организационната структура и функционала. И от отсъствието на пълно осигуряване с ресурси, и от неспазване на длъжностните инструкции, и от стремежа към печалба за сметка на безопасността, и от много други фактори. Поради това е необходимо да се изгражда ролева модел, който може да покрие до 80% от потребностите на потребителите в необходимите основни права при назначаване на длъжност. А останалите 20% те могат, ако е необходимо, да искат по-късно чрез отделни заявления.

Разбира се, можете да попитате: "Но какво, наистина не съществуват 100% ролеви модели?" Е, защо не, такива се срещат, например, в неправителствени структури, които не подлежат на чести промени – в някакво НИИ. Или в организации на военно-промишления комплекс с висок защитен ниво, където сигурността е на първо място. Случва се и в търговска структура, но в рамките на отделно взето подразделение, чиито процеси са достатъчно статични и предсказуеми.

Главният плюс на ролевото управление е опростяване на предоставянето на права, тъй като броят на ролите е значително по-малък от броя на потребителите на информационната система. И това е вярно за всяка индустрия.

Да вземем ритейл компания: в нея работят хиляди продавачи, но набор прав в системата N за тях е един и същ, и за тях ще бъде създадена само една роля. Дойде нов продавач в компанията - автоматично му се назначава необходимата роля в системата, в която вече има всички необходими правомощия. По същия начин с един клик могат да се променят правата за хиляди продавачи наведнъж, например, да се добави нова опция за генериране на отчет. Не е нужно да се правят хиляди операции, свързвайки новото право с всяко съдебно дело - достатъчно е да внесете тази опция в роля, и тя ще се появи у всичките продавачи едновременно.

Още едно предимство на ролевото управление – изключване на предоставянето на несъвместими правомощия. Тоест служител, който има определена роля в системата, не може едновременно да има друга роля, правата на която не трябва да се съчетават с правата в първата. Ясен пример – забраната на съвмесването на функции на въвеждане и контрол на финансова операция.

Всички, които се интересуват как изобщо се е появило ролевото управление на достъпа, могат
да се потопят в историята
Ако се обърнем към историята, ИТ-общността за първи път е започнала да мисли за методи за управление на достъпа още през 70-те години на XX век. Въпреки че приложенията тогава бяха достатъчно прости, но, както и сега, всички много искаха удобно управление на достъпа до тях. Да предоставят, променят и контролират правата на потребителите – просто, за да се разбере по-добре какъв достъп има всеки от тях. Но по това vreme не съществуваха никакви общи стандарти, разработваха се първите системи за управление на достъпа и всяка компания се основаваше на своите собствени представления и правила.

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

Първият и, вероятно, най-прост модел – Дискреционно (избирателно) управление на достъпа (DAC – Дискреционно управление достъпа). Този модел предвижда споделяне на правата от всички участници в процеса на достъп. Всеки потребител получава достъп до конкретни обекти или операции. Почти тук множеството субекти на правата отговарят на множеството обекти. Този модел беше признат за твърде гъвкав и сложен за поддържане: списъците за достъп с времето стават огромни и трудни за контролиране.

Вторият модел е Задължително управление на достъпа (MAC — Mandatory access control). Според този модел всеки потребител получава достъп до обект в съответствие с оформения достъп до определено ниво на конфиденциалност на данните. Съответно обектите трябва да бъдат категоризирани по ниво на конфиденциалност. В отличие от първия гъвкав модел, този, обратно, се оказа твърде строг и ограничителен. Неговото приложение не оправдава себе си, когато в компаниите има множество разнообразни информационни ресурси: за да се разграничат достъпите до различни ресурси, ще се наложи въвеждане на множество категории, които няма да се пресичат.

Във връзка с очевидната недостатъчност на тези два метода ИТ-общността продължи разработката на модели, по-гъвкави и в същото време по-или по-малко универсални за поддръжка на различни типове организационни политики за контрол на достъпа. И тогава се появи третият модел за управление на достъпа на базата на роли! Този подход се оказа най-перспективен, тъй като изисква не само идентификация на потребителя, но и неговите работни функции в системите.

Първото ясно описано строителство на ролевия модел беше предложено от американските учени Дейвид Ферраило и Ричард Кун от Националния институт за стандарти и технологии на САЩ през 1992 година. Тогава за първи път се появи терминът RBAC (Role-based access control). Тези изследвания и описания на основните компоненти, както и междувъздействията им, легнаха в основата на действащия и до днешен ден стандарт INCITS 359-2012, одобрен от Международния комитет по стандартизация на информационните технологии (INCITS).

Стандартът дефинира ролята като "длъжностна функция в контекста на организацията с определена свързана семантика относно правомощията и отговорностите, възложени на потребителя, назначен на ролята". Документът установява основните елементи на RBAC – потребители, сесии, роли, разрешения, операции и обекти, а също така отношенията и взаимовръзките между тях.

В стандарта е предоставена минимално необходимата структура за изграждане на ролеви модел – обединяване на правата в роли и след това предоставяне на достъп на потребителите чрез тези роли. Определени са механизмите за създаване на роли от обекти и операции, описани са иерархията на ролите и наследяването на правомощия. В крайна сметка, във всяка компания има роли, които обединяват елементарни правомощия, необходими на всички служители. Това може да бъде достъп до електронна поща, към СЕД, към корпоративен портал и т.н. Тези правомощия могат да бъдат включени в една обща роля, наречена "служител", и няма да е нужно в всяка от по-високите роли да изброявате всички елементарни права отново и отново. Достатъчно е просто да посочите атрибута за наследяване на ролята "служител".

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

Отделно трябва да се обсъди управление на достъпа на базата на атрибути (ABAC — управление на достъпа, основано на атрибути). Подходът се основава на предоставянето на достъп чрез правила за споделяне на атрибути. Тази модел може да се използва самостоятелно, но много често активно допълва класическия ролеви модел: към определена роля могат да се добавят атрибути на потребители, ресурси и устройства, както и време или местоположение. Това позволява да се използват по-малко роли, да се въведат допълнителни ограничения и достъпът да бъде минимално достатъчен, а следователно да се повиши сигурността.

Например, на счетите на счетите, ако той работи в определен регион. Тогава местоположението на специалиста ще бъде сравнявано с определена еталонна стойност. Или може да се разреши достъп до сметките само ако потребителят се удостоверява от устройство, регистрирано в списъка на разрешените. Добро допълнение към ролевия модел, но рядко се използва самостоятелно, поради необходимостта от създаване на много правила и таблици с разрешения или ограничения.

Ще дам пример за използването на ABAC от моята "прошла" работа. В нашата банка имаше няколко филиала. Служителите на клиентските офиси в тези филиали извършваха абсолютно идентични операции, но трябваше да работят в основната система само със сметките на своя регион. Първоначално започнахме да създаваме отделни роли за всеки регион — и такива роли с повтаряща се функционалност, но с достъп до различни сметки се получиха наистина много! Тогава, използвайки атрибута за местоположение на потребителя и свързвайки го с конкретен диапазон от сметки за проверка, значително намалихме броя на ролите в системата. В резултат останаха роли само за един филиал, които се тиражираха на съответните длъжности в останалите териториални подразделения на банката.

А сега нека поговорим за необходимите предпоставки, без които просто не може да се изгради функциониращ ролеви модел.

Стъпка 1. Създаваме функционален модел

Започнете с създаването на функционален модел – документ на високо ниво, в който подробно е описан функционалът на всяко подразделение и всяка длъжност. Обикновено информацията в него идва от различни документи: длъжностни характеристики и правила за отделни подразделения – отдели, управления, департаменти. Функционалният модел трябва да бъде одобрен от всички заинтересовани подразделения (бизнес, вътрешен контрол, сигурност) и утвърден от ръководството на компанията. Каква е целта на този документ? Той служи за справка на ролевия модел. Например, планирате да изградите ролеви модел на база вече наличните права на служителите – експортирани от системата и „приведени към единен знаменател“. Тогава при одобрение на получените роли с бизнес собственика на системата можете да посочите конкретен параграф от функционалния модел, на базата на който в ролята се включва съответното право.

Стъпка 2. Аудит на ИТ системите и изготвяне на план за приоритизация

На втория етап следва да се извърши аудит на ИТ системите, за да се разбере как е организиран достъпът до тях. Например, в моята финансова компания на разположение бяха няколко стотин информационни системи. Във всички системи имаше някакви зачатъци на ролево управление, в повечето – някакви роли, но основно на хартия или в справочника на системата – те отдавна бяха остарели и достъпът до тях се предоставяше по фактически искания на потребителите. Естествено, изграждането на ролеви модел едновременно в няколко стотин системи е просто невъзможно, трябва да се започне отнякъде. Ние проведохме задълбочен анализ на процеса на управление на достъпа, за да определим нивото на неговата зрялост. По време на анализа бяха изработени критерии за приоритизация на информационните системи – критичност, готовност, планове за изтегляне от експлоатация и т.н. С тяхна помощ изградихме реда за разработване/актуализиране на ролевите модели за тези системи. След това – включихме ролевите модели в плана за интеграция с решението за управление на идентичността, за да автоматизираме управлението на достъпа.

И така, как да определим критичността на системата? Отговорете си на следните въпроси:

• Свързана ли е системата с оперативните процеси, от които зависят основните дейности на компанията?
• Дали нарушаването на функционирането на системата ще повлияе на цялостността на активите на компанията?
• Какво е максимално допустимото време на простои на системата, след което възстановяването на дейността е невъзможно?
• Може ли нарушение на целостността на информацията в системата да доведе до необратими последици, както финансови, така и репутационни?
• Критичност към измамите. Наличие на функционалност, при недостатъчен контрол на която, е възможно извършването на вътрешни/външни измамнически действия;
• Какви са изискванията на законодателството, както и на вътрешните правила и процедури към тези системи? Ще има ли глоби от регулаторите за несъответствия?

В своята финансова компания проведохме одит по следния начин. Ръководството разработи процедура за одит на преглед на правата за достъп, за да се справи с настоящите потребители и права, първо в онези информационни системи, които попаднаха в списъка на най-приоритетните. Отделението по сигурност беше определено за собственик на този процес. Но за да се получи пълната картина на правата за достъп в компанията, беше необходимо да се включат в процеса и IT и бизнес отделенията. И тук започнаха спорове, недоразумения и понякога дори саботаж: никой не иска да се откъсне от текущите си задължения и да се ангажира с неща, които на пръв поглед изглеждат неясни.

Забележка. Големи компании с развити IT процеси със сигурност са запознати с процедурата за IT одит – IT general controls (ITGC), която позволява да се открият недостатъци в IT процесите и да се установи контрол, за да се подобрят процесите според best practice (ITIL, COBIT, IT Governance и др.) Такъв одит позволява на IT и бизнеса да се разберат по-добре и да разработят съвместна стратегия за развитие, да анализират рисковете, да оптимизират разходите, да изработят по-ефективни подходи в работата.



Едно от направленията на одит е определянето на параметрите на логическия и физически достъп до информационните системи. Получените данни взехме за основа за по-нататъшна употреба при изграждането на ролевата модел. В резултат на такъв одит получихме регистър на ИТ-системите, в който бяха определени техните технически параметри и дадени описания. Освен това за всяка система беше определен собственик от бизнес направление, в чиито интереси тя се експлоатираше: именно той отговаряше за бизнес процесите, които тази система обслужваше. Също така беше назначен мениджър на ИТ-службата, отговорен за техническата реализация на нуждите на бизнеса във конкретната ИС. Бяха фиксирани най-критичните за компанията системи и техните технически параметри, срокове за въвеждане и извеждане от експлоатация и др. Тези параметри много помогнаха в процеса на подготовка за изграждане на ролевата модел.

Стъпка 3 Създаваме методология

Залог на успеха на всяко начинание е правилно избраният метод. Поради това и за изграждането на ролевата модел, и за провеждането на одита ни е необходимо да създадем методология, в която ще опишем взаимодействието между подразделенията, ще закрепим отговорността в регламентите на компанията и т.н.
Преди всичко трябва да проучим всички налични документи, които установяват реда на предоставяне на достъп и права. По принцип, процесите трябва да бъдат документирани на няколко нива:

• общи корпоративни изисквания;
• изисквания към областите на ИБ (зависят от сферите на дейност на организацията);
• изисквания към технологичните процеси (инструкции, матрици за достъп, методически указания, изисквания към конфигурациите).

В нашата финансова компания открихме много остарели документи – наложи се да ги приведем в съответствие с внедряваните нови процеси.

По заповед на ръководството беше създадена работна група, в която влязоха представители на направленията за сигурност, ИТ, бизнес и вътрешен контрол. В заповедта бяха определени целите на създаването на групата, посоката на дейността, срокът на съществуване и отговорните от всяка страна. Освен това разработихме методология за провеждане на одит и реда за изграждане на ролевия модел: те бяха одобрени от всички отговорни представители на направленията и одобрени от ръководството на компанията.

Документите, които описват реда за извършване на работи, сроковете, отговорностите и т.н. – са ключът към това, че по пътя към желаната цел, която в началото не е очевидна за всички, никой да не задава въпросите «защо го правим, за какво ни е нужно това и т.н.» и да няма възможност за «изплъзване» или забавяне на процеса.

Стъпка 4. Фиксираме параметрите на съществуващия модел за управление на достъпа

Съставяме т.нар. «паспорт на системата» в частта за управление на достъпа. По същество, това е въпросник за конкретна информационна система, в който са фиксирани всички алгоритми за управление на достъпа до нея. Компаниите, които вече са внедрили решения от клас IdM, сигурно са запознати с подобен въпросник, тъй като именно с него започва проучването на системите.

Част от параметрите за системата и собствениците преминаха в въпросника от регистъра на ИТ (виж стъпка 2, одит), но се добавиха и нови:

• как се управляват потребителските акаунти (директно в БД или чрез програмни интерфейси);
• как потребителите влизат в системата (с помощта на отделен акаунт или с използване на акаунт AD, LDAP или др.);
• какви нива на достъп до системата се използват (ниво на приложението, системно ниво, използване на мрежови файлови ресурси от системата);
• описание и параметри сървъри, на които работи системата;
• какви операции по управление на акаунтите се поддържат (блокиране, преименуване и т.н.);
• по какви алгоритми или правила се формира идентификаторът на потребителя в системата;
• по какъв атрибут може да се установи връзка с записа за служителя в кадровата система (Име, табелни номер или др.);
• всички възможни атрибути на акаунта и правилата за тяхното попълване;
• какви права за достъп съществуват в системата (роли, групи, атомарни права и др., има ли вложени или йерархични права);
• механизми за разделяне на права за достъп (по длъжности, подразделения, функции и др.);
• има ли в системата правила за разграничаване на правата (SOD – Segregation of Duties) и как те функционират;
• как се обработват в системата събития като отсъствие, преназначаване, уволнение, обновяване на данни за служителите и т.н.

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

Стъпка 5. Създаваме бизнес ориентирано описание на правомощията

Още един документ, който ще ни е необходим при изграждането на ролевия модел, е справочник с всички възможни правомощия (права), които могат да бъдат предоставени на потребителите в информационната система с подробно описание на бизнес функцията, която стои зад тях. Често правомощията в системата са кодирани с определени наименования, състоящи се от букви и цифри, и служителите в бизнеса не могат да разберат какво се крие зад тези символи. Тогава те се обръщат към ИТ отдела, а там... също не могат да отговорят на въпроса, например, за рядко използвани права. Тогава се налага провеждане на допълнителни тестове.

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

• наименование на правомощието, включително обекта, към който се прилага правото на достъп;
• действие, което е разрешено да се извършва с обекта (преглед, промяна и т.н., възможност за ограничение, например, по териториален признак или по група клиенти);
• код на правомощието (код и име на функцията/заявката на системата, които могат да се изпълнят с помощта на правомощието);
• описание на правомощието (подробно описание на действията в ИС при прилагане на правомощието и последствията от тях за процеса;
• статус на правомощието: «Активно» (ако правомощието е назначено поне на един потребител) или «Не активно» (ако правомощието не се използва).

Стъпка 6 Извличаме от системите данни за потребителите и правата и ги съпоставяме с кадровия източник

В последния етап на подготовката е необходимо да се извлекат данни от информационните системи за всички потребители и правата, които имат в текущия момент. Тук са възможни два сценария. Първият: имаме директен достъп до системата от подразделението по сигурността и налични средства за извличане на съответните отчети, което не е често, но е много удобно. Вторият: изпращаме запитване до ИТ отдела за получаване на отчети в необходимия формат. Практиката показва: не успяваме да се договорим с ИТ и да получим необходимите данни от първия път. Нужни са няколко опита, докато информацията бъде получена в необходимия вид и формат.

Какви данни е необходимо да се извлекат:

• Име на учетната запись
• Име и фамилия на служителя, към когото е закрепена
• Статус (активна или блокирана)
• Дата на създаване на учетната запись
• Дата на последна употреба
• Списък на наличните права/групи/роли

Така, получихме извлечения от системата с всички потребители и всички права, които им са предоставени. И веднага отложихме всички блокирани акаунти, тъй като работата по изграждането на ролевата модел ще се води само от активни потребители.

След това, ако във вашата компания няма автоматизирани средства за закриване на достъпа на уволнените служители (такова често се среща) или има парче автоматизация, която не винаги сработва коректно, е необходимо да се открият всички „мъртви души“. Става въпрос за учетни записи на вече уволнени служители, правата на които по някаква причина не са блокирани—тях трябва да се блокират. За това съпоставяме извлечените данни с кадровия източник. Кадровата извлеченост също трябва предварително да бъде получена от подразделението, което води кадровата база.

Отделно е необходимо да се отделят акаунтите, чиито собственици не са намерени в кадровата база, не са закрепени за никого – т.е. безстопанствени. За този списък ще ни трябва дата на последна употреба: ако тя е сравнително свежа, все пак ще се наложи да потърсим собствениците. Тук могат да влизат акаунти на външни изпълнители или служебни акаунти, които не са закрепени за никого, но са свързани с някакви процеси. За уточняване на принадлежността на акаунтите може да се разпратят писма до всички подразделения с молба за отзив. Когато собствениците бъдат намерени, внасяме данните им в системата: така всички активни акаунти ще бъдат идентифицирани, а останалите блокираме.

След като нашите експорти са почистени от ненужни записи и са останали само активни акаунти, можем да преминем към изграждане на ролевата модел за конкретната информационна система. Но за това ще разкажа в следващата статия.

Автор: Людмила Севастьянова, мениджър по промоции в Solar inRights

Източник: habr.com