Изграждане на ролеви модел за контрол на достъпа. Част първа, подготвителна

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

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

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

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

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

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

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

Разбира се, можете да попитате: „Какво, изобщо няма 100% ролеви модели?“ Е, защо, това се случва например в структури с нестопанска цел, които не са обект на чести промени - в някой изследователски институт. Или в организации на военно-промишления комплекс с високо ниво на сигурност, където сигурността е на първо място. Това се случва и в търговска структура, но в рамките на едно звено, чиято работа е доста статичен и предвидим процес.

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

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

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

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

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

Първият и вероятно най-простият модел е Дискреционен (селективен) контрол на достъпа (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, одит), но са добавени нови:

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

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

Стъпка 5: Създайте бизнес-ориентирано описание на разрешение

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

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

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

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

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

Какви данни трябва да бъдат качени:

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

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

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

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

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

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

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