Розмежування доступу до даних

: вимоги


Ми вже знаємо, що для всебічного опису діяльності навіть невеликого підприємства потрібні сотні моделей. Але якщо завдання, яке вирішується за допомогою моделювання, і не переслідує мети всебічного опису діяльності компанії, як правило, вона все одно вирішується шляхом застосування аж ніяк не однієї-єдиної моделі – не дарма ж придумано так багато різних типів цих самих моделей.


Як тільки кількість моделей бізнес-процесів, потрібних для вирішення завдань підприємства, перевищує десяток, а авторів моделей стає більше ніж один, питання розмежування доступу авторів моделей до даних стає дуже актуальним.


По-перше, розмежування доступу до даних знижує можливі збитки від ненавмисного їх пошкодження тими ж авторами моделей. Це означає, що при організації робіт з моделювання потрібні кошти, що дозволяють або забороняють певним учасникам та групам редагувати конкретні моделі.


По-друге, нерідко дані, які використовуються при моделюванні, можуть носити конфіденційний характер (наприклад, організаційна структура підприємства, інформаційні системи, що застосовуються при автоматизації ключових процесів, відомості про топології локальної мережі) і їх бажано надавати обмеженому числу користувачів. Це означає, що потрібні кошти, що дозволяють дозволити або заборонити користувачам не тільки редагувати певні моделі, а й переглядати їх, а в ряді випадків – і знати про їхнє існування.


По-третє, при вирішенні ряду завдань можуть знадобитися не всі надані обраним засобом моделювання типи моделей, об'єктів, зв'язків між ними, і в цьому випадку було б бажано обмежити доступ користувачів до цих типів, щоб у них не виникло спокуси створити модель або об'єкт, що відноситься до не передбаченого проектом типу – наприклад зробити недоступними відповідні інтерфейсні елементи або елементи списків у засобі моделювання.


: можливі реалізації

Як врахувати перераховані вище вимоги? Одним з варіантів реалізації першого і другого вимог при використанні засобів моделювання, що зберігають моделі в окремих файлах, може бути застосування засобів розмежування доступу до файлів, що надаються операційною системою відповідного файлового сервера. У цьому випадку кошти управління доступу до моделей представляють собою засоби адміністрування операційної системи. Це означає наступне: або завдання з розмежування доступу до моделей покладаються на системного адміністратора, або права адміністрування відповідних папок надаються комусь із членів проектної групи. Обидва організаційних рішення мають свої переваги і недоліки, проте, оскільки переважна більшість сучасних засобів моделювання (включаючи і такий популярний в нашій країні інструмент, як Microsoft Office Visio 2007) Як і раніше зберігає свої моделі в окремих файлах, вони застосовуються досить широко.


Якщо ж засіб моделювання зберігає дані в серверної СУБД, завдання з розмежування доступу до моделей, як правило, вирішується аж ніяк не засобами адміністрування СУБД. Причина цього полягає в наступному. З одного боку, розмежування доступу до даних користувачів СУБД зазвичай здійснюється на рівні таблиць, уявлень і процедур. З іншого боку, модель даних такої СУБД, який би підхід до її створення не був обраний, все ж таки навряд чи виявиться спроектованої таким чином, що для кожної моделі буде створена окрема таблиця. Подібний підхід до проектування суперечить всім розумним принципам, включаючи принцип нормалізації даних, але ж він такий популярний саме тому, що проходження йому спрощує їх введення та супровід. Швидше за все, в гіпотетичній базі даних, що зберігає моделі, повинна бути таблиця зі списком моделей. Розмежування доступу до моделей у цьому випадку означає, що різним користувачам потрібні різні права на різні записи у цій таблиці, а засоби адміністрування СУБД такий можливості не надають.


Існують різні шляхи вирішення цього завдання: від створення в базі даних уявлень, що залежать від облікового запису користувача, що звертається до цього поданням, до реалізації подібних засобів захисту поза СУБД в серверах проміжної ланки. При будь-якому способі реалізації розмежування доступу до даних, обраному розробниками засоби моделювання, ними ж поставляються і відповідні засоби управління обліковими записами і правами користувачів.


Прикладом реалізації обмеження доступу до даних за допомогою сервера проміжної ланки є засоби моделювання сімейства ARIS компанії IDS Scheer. Як ми вже згадували в попередній статті даного циклу, продукти даного сімейства здійснюють зберігання моделей у серверної СУБД, доступною клієнтським застосуванням за допомогою звернення до сервера проміжної ланки. Засоби управління обліковими записами і правами користувачів вбудовані в самі інструменти моделювання цього сімейства (рис. 1).

Рис. 1. Засоби управління обліковими записами в ARIS Business Architect

Для реалізації третьої вимоги при моделюванні теж можна застосовувати різні технології. Так, для Microsoft Office Visio 2007 можна формувати набори символів для конкретного проекту і рекомендувати авторам моделей використовувати лише їх. Але набагато більш надійною є реалізація, що не припускає ніяких рекомендацій, то є технічно обмежує доступ до типів моделей і об'єктів. Подібна можливість реалізована, наприклад, у все тих же інструментах сімейства ARIS. Вона полягає у створенні так званих методологічних фільтрів – XML-документів, що містять допустимі списки моделей, об'єктів, символів і зв'язків. Подібні фільтри створюються виходячи з потреб конкретного проекту, а потім користувачам присвоюються права на доступ до моделей із застосуванням цих фільтрів. Таким чином, користувачеві при моделюванні стають доступні тільки типи моделей, об'єктів і зв'язків, заздалегідь визначені у фільтрі, через який він "бачить" моделі в базі даних, з якою працює (рис. 2 і 3).

Рис. 2. Засоби створення методологічного фільтра в ARIS Business Architect: обмеження доступних користувачеві типів моделей

 

Рис. 3. Засоби створення методологічного фільтра в ARIS Business Architect: обмеження доступних користувачеві символів для вибраних типів моделей

Фільтр містить константи – коди типів моделей, об'єктів, зв'язків, символів, дозволених до застосування користувачем, який звертається до даних за допомогою цього фільтра. Нижче наведено фрагмент подібного фільтра:

<!DOCTYPE ArisFilter SYSTEM “ArisFilterExport.dtd”>


<ArisFilter version=”1.0″ arisversion=”7.0.1.169217″>


   <Guid>f98555a9-6158-11d4-8582-00005a4053ff</Guid>


   <InfoData>


<Info LocaleId="1033" Name="Easy Filter" Desc="This filter offers a selection of basic model types of the requirements definition."/>


<Info LocaleId="1049" Name="Простой фільтр" Desc="Фільтр містить основні моделі, пов'язані з рівнем визначення требованій."/>


   </InfoData>


   <FilterData FilterType=”method” Key=”EASYFILTER”>


      <ModelList>


         <Model ModelTypeNum=”1″>


<Symbols> 3,0 2,1 58,2 143,3 12,4 209,5 145,6 </ Symbols>


<CxnOcc CxnBaseTypeNum="296"> 209,209,31 </ CxnOcc>


<CxnOcc CxnBaseTypeNum="17"> 209,3,27 </ CxnOcc>



<Attributes> 1,1 55,2 9,3 942,4 152,5 938,6 381,7 389,8 </ Attributes>


            <NCAttributes></NCAttributes>


         </Model>



      </ModelList>


      <ObjectList>


      <Object ObjTypeNum=”17″>


<Attributes> 1,1 55,2 28,3 9,4 8,5 942,6 152,7 938,8 943,9 153,10 939,11 389,12 1009,13 </ Attributes>


            <NCAttributes></NCAttributes>


            <Assigns>158</Assigns>


         </Object>        


Створивши необхідний набір фільтрів, можна вказати, які з них дозволені до застосування конкретним користувачем, – у результаті він просто буде позбавлений технічної можливості створити модель, об'єкт або зв'язок, не передбачену у фільтрах, які йому дозволено застосовувати (рис. 4). Заборонені до застосування моделі, об'єкти і зв'язку просто перестануть з'являтися в списках майстрів створення моделей, в діалогових панелях установки властивостей зв'язку, на палітрі інструментів, використовуваної при малюванні моделей.

Рис. 4. Засоби присвоєння користувачеві прав на методологічні фільтри в ARIS Business Architect

Реалізація розмежування доступу до даних в ARIS є сьогодні, мабуть, найбільш близькою до ідеальної. Відзначимо, однак, що подібна реалізація найбільш цікава і потрібна у великомасштабних проектах, в яких є як мінімум кілька учасників і число моделей хоча б перевищує десяток. При вирішенні ж менш масштабних задач моделювання подібні засоби можуть виявитися надмірними.


Загалом зазначимо, що, вибираючи інструмент, дуже важливо оцінити можливий масштаб робіт, потрібний для вирішення як поточних завдань, так і завдань у наступних проектах. Адже випадки, коли компанія почала з п'яти моделей Microsoft Office Visio 2007, А закінчила величезним архівом з декількох сотень подібних моделей, супровід якого (включаючи і забезпечення розмежування доступу до даних) коштувало величезних зусиль, відомі багатьом консультантам по моделювання бізнес-процесів …

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*