CC BY
10
Научни трудове на Съюза на учените в България - Пловдив. Серия В. Техника и технологии. Том XVII, ISSN 1311 -9419 (Print); ISSN 2534-9384 (Online), 2019. Scientific Works of the Union of Scientists in Bulgaria - Plovdiv. Series C. Technics and Technologies. Vol. XVII., ISSN 1311 -9419 (Print); ISSN 2534-9384 (Online), 2019
МОДЕЛ TROBAC ЗА КОНТРОЛ НА ДОСТЪПА В СОФТУЕРНИ СИСТЕМИ ЗА УПРАВЛЕНИЕ НА ДОКУМЕНТИ
Неделчо Андонов, Емил Хаджиколев, СтанкаХаджиколева Пловдивски университет „П. Хилендарски"
TROBAC MODEL FORACCESS CONTROL IN DOCUMENT MANAGEMENT SAFTWAIH SYSTNMS Nedelcho Andonov, E oiiHaSzhikoleE, AtanFa Aadzhikoleva PlovdivUoiversity „Paisii Hilendarski"
Abstract: This paper gives an overview of some popular access control models used for authorization in software systems. It presents some models based on attributes, roles, tasks, organizations etc. The TROBAC model that expands the ROBAC model is proposed. It adds abstract layer for object typification, aimed in facilitating search, access and automated processing of objects.
Keywords: access control model, roles and organization based access control, typified ROBAC model
увок
Моделът за контрол на достъпа е част от цялостния процес по идентификация, автентификация и авторизация (identification, authentication, authorization) на потребителите на една софтуерна система. Чрез него се определят механизмите за задаване на права на идентифициран и доверен потребител върху конкретни обекти и функционалности на системата. През последните години са създадени множество стандартни модели за контрол на достъпа, подходящи за употреба в различни типове приложения.
В образователните институции и в частност във висшите училища се изпълняват множество бизнес процеси, софтуерната поддръжка на които се извършва от разнородни системи. Не винаги е удачно и възможно изграждането на единна система, поддържаща разнообразни дейности като прием на кандидат-студенти, административно обслужване на служители и студенти, управление на човешките ресурси, осигуряване качеството на образователния процес и др. Обективната преценка за ефективността от обединяване на общодостъпни дейности с такива, изискващи високи нива за сигурност и в частност недостъпност от външни системи, също е от значение.
Необходимостта от интегрирана университетска система за управление на документи възникна при изграждането на софтуерна система за осигуряване на качеството на обучението и акредитация (Hadzhikoleva et al., 2016). За съставянето на доклад-самооценка, необходим за стартиране на акредитационна процедура, е необходимо издирването на множество доказателствени документи и справки, създавани и съхранявани в различни софтуерни системи със затворен или отворен достъп. Основни проблеми при това са търсенето на актуални версии на документи и необходимост от многократно повторяеми дейности по събиране и обновяване на доказателствените материали (за различните акредитационни процедури). Създаването на интегрирана система със строга типизация на университетските документи (Hadzhikolev et al., 2018) би улеснило и автоматизирало
дейностите по търсене и рефериране на актуални единични документи или списъци с еднотипни документи, създавани и обработвани от различни организационни звена.
Проведеното от нас проучване на готови софтуерни решения за изграждане на документни хранилища и на системи за управление на документи показа, че не предоставят достатъчно функционалности за моделиране на необходимите ни същности и взаимовръзки между тях. Естествено решение в такъв случай е разработването на собствена система, което включва и реализацията на подходящ модел за контрол на достъпа, базиран на идентифицираните в предметната област същности и зависимости между тях.
Съществуващите стандартни модели за контрол на достъпа не поддържат всички желани от нас елементи, поради което предлагаме нов - TROBAC, разширяващ модела ROBAC (Zhang et al., 2006). Той е фокусиран върху възможността за детайлно моделиране на основните обекти и субекти на документната система. Въвеждането на строга типизация на обектите има за цел контрол на персонализирания достъп на потребителите до ресурсите на системата, улесняване на търсенето и достъпването на документите чрез уеб услуги, и интеграцията с други университетски приложения.
МОДЕЛИ ЗА КОНТРОЛ НА ДОСТЪПА
Моделите за контрол на достъпа определят механизми за задаване на права на потребителите за изпълнение на операции, осъществявани върху различни ресурси.
Основни елементи в моделите за контрол на достъпа са:
• обекти (ресурси), до които се осигурява достъп - файлове, данни, процеси, задачи и др.
• субекти, осъществяващи достъпа - потребители, приложения, процеси и др.
• операции, които могат да се осъществяват от субектите върху обектите - четене, модифициране, верифициране, запис и др.
• разрешения (permissions) - определят права за това, кой потребител, какви операции може да изпълнява върху обектите.
Множество стандартизирани и придобили популярност модели определят различни начини за задаване на правата за достъп до конкретни обекти, специфични операции, дейности и др. в една софтуерна система.
Access control lists (ACL) е механизъм, който имплементира контрол на достъпа до даден ресурс, като изброява кои потребители или приложения получават достъп до ресурса, както и какви операции са разрешени за съответните приложения - напр. четене, запис, изпълнение и др. (Network Working Group, 2007). За разлика от него, моделът Discretionary Access Control (DAC) се основава на идеята за собственост върху ресурсите. Собственикът на обекта определя кои субекти имат достъп до обекта. Този модел се нарича дискретен, защото контролът на достъпа се основава на личната преценка на собственика на обекта. Правата за достъп до даден ресурс се определят чрез списък за контрол на достъпа.
При mandatory access control (MAC), системата (а не потребителите) определя кои субекти могат да имат достъп до конкретните обекти за данни. Моделът се основава на етикети за сигурност. На субектите се дава разрешение за достъп (тайно, строго секретно, конфиденциално и т.н.), а обектите с данни получават класификация за сигурност (тайна, строго секретна, поверителна и т.н.). Данните за разрешение и класификация се съхраняват в етикетите за сигурност, които са свързани с конкретните субекти и обекти. Когато системата взема решение за контрол на достъпа, тя се опитва да съпостави разрешенията на обекта с класификацията на обекта (Department of Defense, 1985).
В Role-based Access Control (RBAC) правата за извършване на определени дейности са разрешени за определени роли. Потребителите на системата получават определени роли. За всяка роля са определени права за изпълнение на определени функции на софтуерната система. По този начин, потребителите не получават права директно, а ги придобиват чрез
своята роля (или роли). Управлението на индивидуалните потребителски права се свежда до задачата за определяне на подходящи роли за профила на потребителя (INCITS, 2012).
При Attribute-based access control (ABAC) заявките на субект да изпълни операции върху обекти се изпълняват или отхвърлят въз основа на конкретни атрибути на субекта и обекта, условия на средата и набор от политики, които са специфицирани в термините на тези атрибути и условия (NIST, 2014). Този модел поддържа логическа булева схема, в която правилата съдържат "IF, THEN" синтаксис за това, кой прави заявката, ресурса и действието. За разлика от RBAC, който използва предварително дефинирани роли, свързани със специфичен набор от привилегии, и с които се свързват субекти, ключовата разлика с ABAC е концепцията за политики, които изразяват комплексно множество от булеви правила, които могат да оценят много различни атрибути.
Organization-based access control (OrBAC) позволява на дизайнера на политиката да определи политика за сигурност, независимо от изпълнението. Избраният метод за постигане на тази цел е въвеждането на абстрактни нива за роли, дейности и изгледи вместо конкретните, съответно, субект, действие и обект. Всяка политика за сигурност е параметризирана и се определя за дадена организация (The SERES team, 2013).
Role and Organization Based Access Control (ROBAC) е модел, който има за цел да надгради RBAC чрез дефиниране на политики за сигурност, обхващащи множество организации. За разлика от модел RBAC, при който правата на потребителя зависят само от неговата роля, при ROBAC правата се определят от съвкупността от две характеристики -ролята на потребителя и принадлежности му към конкретна организация (Zhang et al., 2006; Zhang et al., 2008).
Върху стандартните модели са създадени множество хибридни модели за контрол на достъпа, специализирани за конкретни домейни и ситуации - базирани на работа в екип (Thomas, 1997), работа по задачи (Thomas & Sandhu, 1997) и др.
МОДЕЛ TROBAC ЗА КОНТРОЛ НА ДОСТЪПА НА УНИВЕРСИТЕТСКАТА СИСТЕМА ЗА УПРАВЛЕНИЕ НА ДОКУМЕНТИ
Предложният от нас модел за контрол на достъпа TROBAC (Typified ROBAC) (фиг. 1) на университетска система за управление на документи, е базиран на фамилията модели ROBAC, като са използвани специфични за конкретния домейн (документна система) имена на обекти и асоциации. Към основния модел са добавени различни групи и типове елементи - типове звена, стандарти, категории, роли/типове звена и др. Типизацията предоставя възможност за по-добра скалируемост при нарастване на броя на конкретните типове и елементите в тях. Специфични за документната системата характеристики като стандарти и категории са свързани с моделирането на типове документи и улесняват насоченото търсене (по мета-информация, стандарти, категории и др.).
Основните обекти и принципи в университетската система за управление на документа, описани подробно в (Hadzhikolev et al., 2018), са:
1. Един потребител може да има няколкороли в различни звена на организацията.
2. Йерархично зависими звена определят структурни единици от организацията.
3. Типове звена - определят общи политики за сигурност, правила за валидни взаимовръзки между звената и възможност за наследяване на права в йерархията от типове звена - нагоре и/или надолу.
4. Роли - определят общи права за сигурност и достъп до ресурси за определен тип структурни звена.
5. Документи - притежават характеристики като тип на документа, стандарт, категории и др.
6. Типове документи - определят общи права за достъп до всички документи от съответния тип и „валидни" типове звена, с права за запис.
7. Операции върху типове документи с възможности за специфициране - за запис (редактиране, публикуване, потвърждение и др.) и четене (четене само на заглавието на документ, четене на заглавието и метаданни и др.).
8. Видове операции - частни (private) - за потребители от звеното собственик на документа или от звена нагоре и надолу в йерархията на звеното собственик, и публични (public) - за всички останали потребители, които не принадлежат на звеното собственик на документа или от звена нагоре и надолу в йерархията на звеното собственик).
9. Позволения (permissions) - правата за достъп (достъпните операции) на един потребител до документ се определят от неговата роля, принадлежност към звена (и съответните им типове звена) и типа на документа (и съответното звено и тип, за което е регистриран документа).
Конкретните звена и роли на потребител влияят върху неговите частни позволения (private permissions) за конкретни документи, а типа на звено, към което той принадлежи, определят неговите публични позволения (public permissions). Типовете звена оказват влияние и при задаване на правата върху типове документи. Конкретните права за изпълнение на операции върху документ зависят, от една страна, от типовете звена, асоциирани с типа документ, а от друга - от типовете звена, указани за ролите на потребителя.
Фиг. 1. Модел TROBAC за контрол на достъпа до документи в документна система
Въвеждаме означения за някои от обектите и основните им характеристики, като при необходимост те може да бъдат разширявани. За унификация използваме следните означения: id - уникален идентификатор на обект, пате - име на обекта (при различни реализации е възможно името да е единствен уникален идентификатор); parent -идентификатор на родителски обект в дадена йерархия или целия родителски обект. Определяме следните множества от обекти и асоциации, и техни основни характеристики:
• R - множеството от всички роли. Една роля г £ R се определя като наредено множество от характеристики r = (id, name, parent).
• UT - множеството от всички типове звена в организацията. Тип звено ut = (id,name, parent) £ UT.
• RUT £ Rx UT - множеството от валидни асоциации между роли и типове звена. Примерни елементи на множеството (зададени опростено) са двойките („ректор", „университет"), („декан", „факултет") и др.
• U - множеството от всички звена. Звено и = ( id, name , ut , рarent) E U,
където иt - съответния на звеното тип звено.
• RU £ R X U - множеството от валидни асоциации между роли и звена. Примерни елементи на множеството (зададени опростено) са двойките („ректор", „Моят университет"), („декан", „Факултет по Физика") и др.
• S - множеството от всички стандарти. Стандарт
( ) , където - множество от
характеристики за описание на документ. Свойствата се използват за задаване характеристиките на документ и се описват с име, тип и др.
• DТ - множеството от всички типове документи. Тип документ dt = ( ) , където - стандарт, от който произхожда типа документ.
• DТUT £ DТ X UT - множеството от валидни асоциации между типове документи и типове звена. Документи от определен тип могат да бъдат създавани само за звена от свързан с него тип звено.
• User s - множеството от всички потребители. Един потребител usеr = (i d,nam е,р r о р er t i es) E U s er s, където p гор e г t i es e множество от характеристики на потребителя.
• UsersR U £ USERS X R U - множеството от текущи асоциации между потребители и валидни двойки роли-звена.
• D - множеството от всички документи. Документ d = ( i d, nam e, d t, и, l о g, d t_p ro р e rt i es) E D , където d t - идентификатор на типа документ, и - звено, за което е създаден документа, lоg - log за действията на потребителите върху документа, dt _ргор ert i es - множество от асоциации между свойства, определени от стандарта за документа и съответните им стойности за текущия документ.
• Ор - множеството от всички операции. Операция ор = ( id, name , type) E
О р, където type E * "pr i vat e" , "pub I ic "} е тип на операцията. В една система операциите, които извършва потребителя са краен (и обикновено предварително фиксиран, което в случая не е от значение) брой. Поради това е удачно да представим операциите като наредено множество от конкретни операции (о р 1,ор2, ■ ■ ,0рорпит),орпит E N.
• Ор А - нареденч двойки операция-достъпност (accessibility). Една наредена двойка ( ), където е идентификатор на операция, характеристиката enab le d E В оо le an U *" Not A pp I i cab le "} = * "true/ 1 /ye s/ o n "," fal s e/О/по/oíГ,"No t App l i cab l e" } и описва възможен ли е достъпа до операцията в конкретна ситуация.
• ОpАs - множество от всички достъпности за операции. Аналогично на множеството от операции , определяме един елемент на като наредена последователност от opnuт на брой двойки „операция-достъпност", при което позициите на операциите в двете множества ( Ор и ОpАs) са еднакви: орas =
(( ор i, enabled J,(ор2, enabled2), ■ ■., (орорnum, enabledор^т)). Поради
въведената подредба на елементите в множеството за различни изчисления е удачно и лесно използването само на проекцията върху достъпностите: 71enabled(ОрАs) за цялото множество или за конкретен елемент л enabled(орas).
• Р £ DТUT X Ор Аs X R - множеството от всички позволения за изпълнение на операции (вж. табл. 1). Едно позволение р = (dtut, орas,r) E Р, където dtut -идентификатор на валидна асоциация от тип документ и тип звено, -достъпности за операциите, - идентификатор на роля.
Предпоставки за определянето на права в документната система са:
• множество от операции, описани в системата и реализирани с подходяща бизнес логика;
• типове - типове документи, типове звена и роли към типове звена;
• конкретни представители на типовете - документи, звена и потребители с роли към указани звена.
Определянето на правата в документната система преминава през няколко
i:
• Администриране на глобални права на роли върху типове документи към типове звена;
• Задаване на роли към звена на потребителите - от администратор или външна система;
• Автоматизирано изчисляване правата на потребител на база ролите му и глобалните права.
Администрирането на глобални права включва два под-етапа (вж. табл. 1):
• Типизиране на собствеността - определяне на множеството DTUT Е DT X UT.
За всеки тип документ се определят типове звена-собственици. Документи от определен тип може да се задават само за асоцииран към него тип звено. Напр. документи от тип „Протокол от заседание на Факултетен съвет" може да бъдат създавани само за звена от тип „Факултет".
• Задаване на глобални permissions - определяне на множеството от всички permissions Р Е DTUT X OpAs X R. Администратор конфигурира достъпността на операциите, които ролите имат върху двойките тип документ-тип звено.
Тип документ Протокол от заседание на Факултетен съвет
Тип звено Факултет
Роля / Тип звено Private операции Public операции
Роля Ниво. Тип звено Запис Четене Четене
Ректор 0. Университет X ✓ ✓
Декан 1. Факултет ✓ ✓ ✓
Секретар на декан 1. Факултет ✓ ✓ X
Член на факултет 1. Факултет X ✓ X
Член на катедра 2. Катедра X ✓ X
Библиотекар 1. Библиотека NA NA X
Нерегистриран 0. Без звено NA NA X
Табл. 1. Примерни права за достъп до тип документ „Протокол от заседание на Факултетен съвет" към тип звено „Факултет"
Автоматизираното изчисляване на правата на потребител може да се извършва за конкретен документ, тип документ или за всички типове едновременно:
• Определяне на позволенията на потребителя - определяне на множеството от всички позволения за потребител Р(шег) ЯР. В табл. 2 са представени всички права на потребител - Р(изег, йЬ) £ Р(шег) - върху конкретен тип документ. Те са подмножество на глобалните права за типа документ (табл. 1), което е определено от ролите на потребителя.
• Определяне на обобщени (aggregate) позволения на потребителя върху тип документ. Един потребител може да има едновременно няколко роли при една сесия в системата. При това обаче, не е важно коя точно роля дава позволение за изпълнение на конкретна операция върху конкретен документ. Обобщените права определят правата на потребител като комбинация - извършвана чрез логическо ИЛИ върху проекциите по характеристиката enabled - на отделните права по роли. При това, логического ИЛИ се прилага върху всички роли за всяка отделна операция. В резултат се получава само една комбинация от достъпности за операции за всеки тип документ (виж последния ред на табл. 2).
• Определяне на позволенията на потребител върху конкретен документ -конкретните права на потребител върху документ се изчисляват на база обобщените права на потребителя, определени за типа на документа.
В табл. 2 са показани базираните на табл. 1 възможни операции за конкретен потребител, притежаващ роли {Декан, Член на факултет, Член на катедра} и за типа документ „Протокол от заседание на Факултетен съвет". От съществено значение за доброто функциониране на системата е правилното дефиниране на ролите и задаването на принадлежност на потребителите към тях. Когато потребител е член на катедра, директно или индиректно трябва да се укаже, че той е член и на съответния факултет и други по-горни нива в йерархията от звена на организацията.
Потребител user1
Тип документ Протокол от заседание на Факултетен съвет
Тип звено Факултет
Роля / Звено: Тип Private операции Public операции
Роля на userj Ниво. Звено: Тип Запис Четене Четене
Декан 1. Химически факултет: Факултет ✓ ✓ ✓
Член на факултет 1. Химически факултет: Факултет X ✓ X
Член на катедра 2. Органична химия: Катедра X ✓ X
Обобщени права (логическо или): ✓ ✓ ✓
Табл. 2. Примерни права на служител userj върху тип документ „Протокол от заседание на Факултетен съвет"
В табл. 3 са показани примерни обобщени операции за различни потребители. Обикновено собственикът на документ има частни права за запис и четене на документ (user! и user3). Някои потребители могат да разглеждат документа от указания тип, качени от други звена - операции public read за потребителите userj и user2. Потребителите user3 и user4 може да четат документи от собственото звено, но не и от чуждите, а потребителят user5 не може да работи с документи от дадения тип.
Тип документ dtj
Тип звено Факултет
Потребител Private операции Public операции
Запис Четене Четене
user1 ✓ ✓ ✓
user2 X ✓ ✓
user3 ✓ ✓ X
user4 X ✓ X
user5 X X X
Табл. 3. Примерни обобщени права на потребители върху тип документ dtj
ЗАКЛЮЧЕНИЕ
За създаването на университетска система за управление на документа има два основни подхода: конфигуриране на готово софтуерно решение или създаване на собствена технология. Първият подход има предимства като бързо и лесно стартиране на приложението. Основен недостатък е невъзможността да се моделират всички необходими специфични обекти, субекти и връзки между тях. При моделирането на университетска система за управление на документи, сме идентифицирали основни същности, които не могат да бъдат моделирани с готови софтуерни решения. Поради това, изграждането на собствена технология за управление на документи е валидната алтернатива за нас.
Изборът на модел за контрол на достъпа е важна част от създаването на всяка софтуерна система. Използването на стандартни модели за контрол на достъпа, при определените от нас същности и взаимовръзки в документна система, могат да бъдат използвани с известни модификации. Предложеният от нас модел TROBAC е модификация на стандартния модел ROBAC, при който са добавени типизация на звена, категоризации и стандарти за типове документи.
Благодарности: Работата е финансирана от проект СП17-ФМИ-005 „Студентска школа за ИКТ иновации в бизнеса и обучението" към Фонд „Научни изследвания" при Пловдивския университет „П. Хилендарски".
ЛИТЕРАТУРА
Department of Defense. (1985). Department of Defense Trusted Computer System Evaluation Criteria, DoD 5200.28-STD.
kadzhikoiev, A., kadzhikoieva, F., Arozova, M. (2018). Digital Model of a Document in a University Document Repository, Proceedings of the XX-th International Symposium on Electrical Apparatus and Technologies SIELA 2018, 3 - 6 June 2018, Bourgas, Bulgaria.
kadzhikoiev, A., kadzhikoieva, F., Andonov, N. (2018). Challenges in Creating University Digital Document Repositories. COMPUSOFT, An international journal of advanced computer technology, 7(11), November-2018 (Volume-VII, Issue-XI), pp. 2846-2851.
kadzhikoieva, F., kadzhikoiev, A. (2016). The COMPASS-OK Model for Quality Assurance in Higher Education, International Journal of Applied Engineering Research, Volume 11, Number 11 (2016) pp 7326-7332, ISSN 0973-4562.
InterNationai Committee for Information Hechnoiogy Ftandards. (2012). INCITS 359-2012, Information Technology - Role Based Access Control.
Nationai Institute of Ftandards and Hechnoiogy. (2014). Guide to Attribute-based access control (ABAC) Definition and Considerations. NIST Special Publication 800-162.
Network Working Group. (2007). Internet Security Glossary. Available at: https://tools.ietf.org/html/rfc4949, last access 1.11.2018.
The FOEOF team. (2013). OrBAC: Organization Based Access Control. Available at: http://orbac.org/, last access 1.11.2018.
Thomas, R., Fandhu, E. (1997). Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management, Proceedings of the IFIP WG11.3 Workshop on Database Security, Lake Tahoe, California, August 11-13, 1997.
Thomas, R. (1997). Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments, RBAC'97 Proceedings of the second ACM workshop on Role-based access control, Fairfax, Virginia, USA — November 06 - 07, 1997, pp 13-19.
Zhang, Z., Zhang, X., Fandhu, R. (2008). Handbook of Research on Social and Organizational Liabilities in Information Security, Chapter 6: Towards a Scalable Role and Organization Based Access Control Model with Decentralized Security Administration, pp. 94-117.
Zhang, Zh., Zhang, X., Fandhu, R. (2006). ROBAC: Scalable Role and Organization Based Access Control Models, Proceedings of the International Conference on Collaborative Computing: Networking, Applications and Worksharing, 17-20 Nov. 2006, Atlanta, GA, USA.
