Главная Случайная страница


Полезное:

Как сделать разговор полезным и приятным Как сделать объемную звезду своими руками Как сделать то, что делать не хочется? Как сделать погремушку Как сделать так чтобы женщины сами знакомились с вами Как сделать идею коммерческой Как сделать хорошую растяжку ног? Как сделать наш разум здоровым? Как сделать, чтобы люди обманывали меньше Вопрос 4. Как сделать так, чтобы вас уважали и ценили? Как сделать лучше себе и другим людям Как сделать свидание интересным?


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Можливість несанкціонованого одержання інформації під дією дестабілізуючих факторів, незважаючи на застосування засобів ЗІ Рij. 5 page





восьмий етап – розробка документації СМІБ, полягає у визначенні переліку документів (процедур, записів, інструкцій), а також у розробці

управлінських процедур (стандарт на розробку документів, управління документацією, записами; коригувальні і попереджуючі заходи; внутрішній

аудит; управління персоналом та ін);

технічних процедур (придбання, розвиток і підтримка інформаційних систем; управління доступом; реєстрація та аналіз інцидентів; резервне копіювання; управління знімними носіями та ін);

управлінських записів (звіти про внутрішні аудити, аналіз СМІБ з боку вищого керівництва; звіт про аналіз ризиків; звіт про роботу комітету з інформаційної безпеки; звіт про стан коригувальних і запобіжних дій; договору; особисті справи співробітників та ін);

технічних записів (реєстр активів; план підприємства; план фізичного розміщення активів; план комп’ютерної мережі; журнал реєстрації резервного копіювання; журнал реєстрації факту технічного контролю після змін в операційній системі; логи ІС; логи системного адміністратора; журнал реєстрації інцидентів; журнал реєстрації тестів з безперервності бізнесу та ін);

інструкцій, положень (правила роботи з ПК, правила роботи з інформаційною системою, правила поводження з паролями, інструкція з відновлення даних з резервних копій, політика віддаленого доступу, правила роботи з переносним обладнанням та ін.);

дев’ятий етап – навчання персоналу, полягає у навчанні керівників підрозділів, а також всього персоналу вимогам ІБ;

десятий етап – розробка та прийняття заходів щодо забезпечення роботи СМІБ, полягає у впровадженні засобів захисту (адміністративних, навчальних і технічних);

одинадцятий етап – внутрішній аудит СМІБ, полягає у підборі команди внутрішнього аудиту СМІБ, плануванні внутрішнього аудиту СМІБ, проведенні внутрішнього аудиту СМІБ;

дванадцятий етап – аналіз СМІБ з боку вищого керівництва, полягає у проведенні аналізу СМІБ з боку вищого керівництва;

тринадцятий етап – офіційний запуск СМІБ, полягає в підписанні наказу про введення СМІБ в дію;

чотирнадцятий етап - оповіщення зацікавлених сторін (клієнтів, партнерів, ЗМІ тощо) про запуск СМІБ.

Отже, впровадження стандарту ISO/IEC 27001 дозволить дати відповіді на наступні питання:

1) які на сьогоднішній день інформаційні ризики підприємства і як вони впливають на бізнес-процеси? Як ці ризики мінімізувати?;

2) які інформаційні активи є в компанії, і що захищати в першу чергу?;

3) що робити, якщо трапиться непередбачена ситуація?

 

Запитання для самоконтролю

 

1. Які дії містить процес управління безпекою інформаційних технологій?

2. Як треба приймати цілі безпеки, стратегії і методики?

3. Що містить методика безпекипо суті?

4. Що належать до активів організації?

5. Наведіть приклади засобів безпеки?

6. Що є метою програми компетентності безпеки?

7. Які етапи має програми компетентності безпеки в межах організації?

8. Які питання забезпечення інформаційної безпеки організації розглядає стандарту ISO/IEC 17799:2005 (BS 7799-1:2002)?

9. Наведіть контрольні питання організації безпеки?

10. Наведіть контрольні питання з захист доступу сторонніх організацій?

11. Наведіть контрольні питання класифікації і управління активами?

12. Наведіть контрольні питання класифікації інформації?

13. Наведіть контрольні питання захисту персоналу?

14. Наведіть контрольні питання реагування на інциденти безпеки?

15. Наведіть контрольні питання фізичного захисту і захисту середовища?

16. Наведіть контрольні питання з безпеки обладнання?

17. Наведіть контрольні питання загальних засобів безпеки?

18. Наведіть контрольні питання управління діяльністю?

19. Наведіть контрольні питання операційних процедур та відповідальність?

20. Наведіть контрольні питання планування потужності і приймання систем?

21. Наведіть контрольні питання з захисту від зловмисного коду?

22. Наведіть контрольні питання роботи поза офісу?

23. Наведіть контрольні питання управління мережею?

24. Наведіть контрольні питання управління доступом?

25. Наведіть контрольні питання у правління доступом працівників?

26. Наведіть контрольні питання управління доступом у операційній системі?

27. Наведіть контрольні питання з маркування і безпеки носіїв інформації?

28. Наведіть контрольні питання з обміну інформацією і ПЗ?

29. Наведіть контрольні питання розробки і підтримання системи?

30. Наведіть контрольні питання управління безперервністю бізнесу?

31. Наведіть контрольні питання відповідальності?

32. Наведіть контрольні питання аудиту політики ІБ технічної відповідності?

33. Наведіть контрольні питання рекомендацій по аудиту систем?

34. Наведіть контрольні питання із захисту системних файлів?

35. Стандарт ISO/IEC 27001. Сертифікація.

36. Стандарт ISO/IEC 27001. Впровадження.


РОЗДІЛ 8

МОДЕЛІ ПОЛІТИКИ БЕЗПЕКИ

Політика безпеки – це якісний або якісно-кількісний опис властивостей захищеності в термінах, що представляють ІС (рис. 8.1). Опис ПБ повинен включати або враховувати властивості загрози, об’єкта атаки та каналу дії.

 
 

 


Рис. 8.1. Класифікація моделей безпеки за типами загроз

 

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

Положення, інструкції

Рис. 8.2. Система документів, що забезпечують реалізацію політики безпеки

 

Термін «політика безпеки» може бути застосований до організації, ІС, операційної системи (ОС), послуги, що реалізується системою (набору функцій) для забезпечення захисту від певних загроз тощо. Чим менший об’єкт, щодо якого вживається цей термін, тим конкретніші й формальніші стають правила. Політика інформаційної безпеки є частиною загальної ПБ організації і може успадковувати, зокрема, положення державної політики у сфері захисту інформації. Під нею слід розуміти набір законів, правил, обмежень, рекомендацій тощо, які регламентують порядок обробки інформації та спрямовані на захист такої інформації від певних внутрішніх і зовнішніх загроз. Побудова ПІБ передбачає виконання таких кроків:

визначення структури цінностей і проведення аналіз ризику інформації;

визначення правил для будь-якого процесу користування певним видом доступу до елементів інформації, які мають певну оцінку цінностей.

ПІБ може бути викладена як на описовому рівні, так і за допомогою певної формальної мови. Вона є необхідною (а іноді й достатньою) умовою безпеки системи. Формальний вираз політики безпеки називають моделлю ПІБ. Основна мета створення ПІБ й опису її у вигляді формальної моделі – визначення умов, яким має підпорядковуватися поведінка системи, вироблення критерію безпеки і проведення формального доведення відповідності системи цьому критерію при додержанні встановлених правил і обмежень. Серед моделей ПІБ найвідомішими є дискреційна, мандатна та рольова моделі. Загальний підхід щодо їх формування полягає в поділі множини сутностей, що становлять систему, на множини суб’єктів і об’єктів (у різних моделях визначення понять «об’єкт» і «суб’єкт» можуть істотно відрізнятися). Взаємодії в системі моделюються встановленням відношень певного типу між суб’єктами та об’єктами. Множина типів відношень визначається у вигляді набору операцій, які суб’єкти можуть здійснювати над об’єктами.

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

 

8.1. Дискреційна модель політики інформаційної безпеки

 

Основою дискреційної політики інформаційної безпеки (ДПІБ) є дискреційний механізм управління доступом (Discretionary Access Control - DAC). Він визначається такими властивостями:

усі суб’єкти й об’єкти мають бути однозначно ідентифіковані;

права доступу суб’єкта до об’єкта системи визначаються на основі деякого зовнішнього відносно системи правила і реалізуються шляхом безпосереднього звертання суб’єктів до об’єктів на основі певних атрибутів доступу.

Для реалізації такого механізму в системі має бути:

забезпечено контрольований доступ ідентифікованих суб’єктів до об’єктів;

задано явне і однозначне перерахування допустимих типів доступів;

реалізовано механізм управління, який втілює дискреційні правила доступу та обмежує розповсюдження прав на доступ;

забезпечено управління доступом для кожної пари суб’єкт-об’єкт;

забезпечено можливість санкціонованої зміни як правил та прав розмежування доступу, так і списків користувачів та об’єктів.

Дискреційна політика інформаційної безпеки реалізується за допомогою матриці доступу, яка фіксує множину об’єктів та суб’єктів, доступних кожному суб’єкту. Матриця доступів (рис. 8.3) – це матриця розмірності S*O, у котрій рядки відповідають суб’єктам, а стовпці – об’єктам. При цьому кожен елемент матриці доступів M[s,o] визначає права доступу суб’єкта до об’єкту.

 

Множина дозволених методів доступу

Рис. 8.3. Матриця доступу дискреційної політики безпеки

 

Існує декілька варіантів завдання матриці доступу:

листи можливостей (privilege list, profile): для кожного суб’єкта створюється лист (файл) усіх об’єктів, до якого він має доступ;

листи контролю доступу (access control list – АСЕ): для кожного об’єкта створюється список усіх суб’єктів, що мають доступи до нього.

Найбільш відомими модель ДПІБ є модель Харрісона-Руссо-Ульмана (рис. 8.4) та модель Take-Grant.

У першій з них ІС з дискреційним управлінням доступом описується певною кількістю матриць доступів, кожна з яких відповідає стану системи, і командами перетворення матриць доступів. Кожна з команд задається певною кількістю параметрів, умовою виконання і кінцевої послідовністю примітивних операторів, перетворюючих матрицю доступів. Застосування команди переводить систему із стану в подальший стан. У моделі ХРУ аналізуються умови, при виконанні яких можлива перевірка безпеки системи. Методом представлення даних є матриця доступу. Метою моделювання є представлення прав доступу.

 

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

 

Модель Take-Grant вивчається в два етапи. На першому етапі розглядається класична модель Take-Grant, в якій аналізуються алгоритмічно перевіряються умови передачі прав доступу. На другому етапі розглядається розширена модель Take-Grant, в якій аналізуються умови реалізації в комп’ютерних системах інформаційних потоків. Ціль моделі - дати відповідь на питання про можливості одержання прав доступу суб’єктом системи на об’єкт у стані, описаному графом доступів. У цей час модель Take-Grant одержала продовження як розширена модель Take-Grant, у якій розглядаються шляхи виникнення інформаційних потоків у системах з дискреційним розмежуванням доступу. Позначимо елементи моделі: O – множина об’єктів, S – множина суб’єктів, R = {r1, r2, r3, r4,..., rn } U {t,g} – множина прав доступу, де t – право брати, g – право давати. G = (S, O, E) – кінцевий граф. У класичній моделі Take-Grant описуються чотири де-юре правила перетворень графів доступів (табл. 8.1). Методом представлення даних для даної моделі є граф доступу. Метою моделювання є аналіз шляхів поширення прав доступу.

 

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

нездатність витримати атаки із застосуванням “троянського коня”;

неспроможність заздалегідь задати перелік усіх суб’єктів і об’єктів з метою автоматичного визначення прав;

неспроможність забезпечити контроль розповсюдження прав доступу;

нездатність визначити правила розповсюдження прав доступу та провести аналіз їх впливу на безпеку ІС.

Отже, матриця доступів не є тим механізмом, який дозволив би реалізувати якісну і чітку систему захисту інформації в інформаційній системі.

8.2. Мандатна модель політики інформаційної безпеки

 

Основу мандатної (повноважної) політики інформаційної безпеки (МПІБ) становить мандатне управління доступом (Mandatory Access Control – МАС). Принципи мандатного управління:

всі суб’єкти й об’єкти повинні бути однозначно ідентифіковані;

у системі має бути визначено лінійно упорядкований набір міток чутливості;

кожному об’єкту системи має бути присвоєна мітку чутливості (секретності), яка визначає цінність інформації, що міститься в ньому;

кожному суб’єкту системи має бути присвоєна мітка чутливості (секретності), яка визначає рівень довіри до нього в ІС й дорівнює максимальному рівню чутливості об’єктів, до яких цьому суб’єкту дозволений доступ (називається рівнем допуску);

право доступу суб’єкта до об’єкта визначається шляхом порівняння їхніх міток.

Для цього в системі повинен бути реалізований:

процес запиту і отримання класифікаційних міток;

мандатний принцип контролю зчитування і записування

механізм санкціонованої зміни як правил та прав розмежування доступу, так і списків користувачів та об’єктів;

диспетчер доступу (звернень), тобто засіб, що контролює усі звернення, а також розмежовує доступ відповідно до заданого принципу розмежування.

Основна мета МПІБ – запобігання витоку інформації від об’єктів з високим рівнем доступу до об’єктів з низьким рівнем доступу, тобто протидія виникненню в ІС інформаційних каналів згори вниз. Саме поняття решітки цінностей L і поняття інформаційного потоку є основою мандатної політики інформаційної безпеки.

Цінність інформаційних об’єктів (або їх мітки рівня секретності) часто дуже важко визначити. Однак досвід показує, що в будь-якій ІС майже завжди для будь-якої пари об’єктів Х та Υ можна сказати, який з них більш цінний. Визначення цінності об’єктів для МПІБ можна здійснювати шляхом їх порівняння. Тобто, можна вважати, що таким чином фактично визначається деяка однозначна функція с(Х) (тобто, відображення {c: O®L}), яка дозволяє для будь-яких об’єктів X і Υ сказати, що коли Υ більш цінний об’єкт, ніж X, то c(Y) > с(Х). І навпаки, якщо c(Y) > с(Х), то Υ - більш цінний об’єкт, ніж X.

Означення. МПІБ вважає інформаційний потік X®Y дозволеним тоді і тільки тоді, коли c(Y)>c(X) в решітці L. Тобто, потік інформації від X до Υ дозволяється, якщо с(Х) < c(Y), і не дозволяється, якщо с(Х) > c(Y).

Визначення. У системі з двома доступами r і w МПІБ визначається такими правилами доступу: та

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

Пристрій мандатного контролю називають монітором звернень. Мандатний контроль, який ще називають обов’язковим, оскільки його має проходити кожне звернення суб’єкта до об’єкта, організується так: монітор звернень порівнює мітки рівня секретності кожного об’єкта з мітками рівня доступу суб’єкта. За результатом порівняння міток приймається рішення про допуск. Найчастіше МПІБ описують у термінах, поняттях і визначеннях властивостей моделі Bell - LaPadula (рис. 8.6).

 

 

Модель призначена для управління суб’єктами, тобто активними процесами, що запитують доступ до інформації, і об’єктами, тобто файлами, поданнями, записами, полями або іншими сутностями даної інформаційної моделі. В моделі об’єкти піддаються класифікації, а кожен суб’єкт зараховується до одного з рівнів допуску до класів об’єктів. Класи й рівні допуску спільно називаються класами або рівнями доступу. Клас доступу складається з двох компонентів. Перший з них – це ієрархічний компонент. Другий компонент являє собою деяку множину неієрархічних категорій, які можуть ставитися до будь-якого рівня ієрархії, своєрідний опис рівня ієрархії. Так, наприклад, у військових відомствах США застосовується наступна ієрархія класів (зверху вниз): абсолютно секретно; секретно; конфіденційно; без грифа таємності. Другий компонент міг би, наприклад, приймати значення з наступного списку: тільки з опуском по ядерній зброї; не для іноземних урядів; – не для підрядників.

Інший приклад відноситься до приватної компанії, де можливі такі рівні ієрархії (зверху вниз): секретно; для обмеженого поширення; конфіденційно; для службового користування; для необмеженого поширення. Другий компонент для тієї ж компанії міг би включати такі категорії:не для субпідрядників; фінансові дані корпорації; дані по зарплаті.

Ясно, що можна визначити матрицю взаємозв’язків між ієрархічними й неієрархічними компонентами. Наприклад, якщо деякий об’єкт класифікований як зовсім секретний, але йому не приписаний ніякий неієрархічний компонент, то він може надаватися іноземним урядам. У той же час секретний об’єкт може мати категорію "не для іноземних урядів", отже не повинен їм надаватися. Однак у моделі Белла-ЛаПадули створюються "ґрати", де неієрархічні компоненти кожного рівня ієрархії автоматично приписуються до наступного більш високого рівня ієрархії (так назване "зворотне спадкування"). Також існує правило що дозволяє суб’єктові мати доступ на запис до об’єкта тільки в тому випадку, якщо рівень допуску цього суб’єкта такий же або більше низький, чим клас об’єкта - операнда операції запису. Це означає, що інформація, що належить якому-небудь рівню, ніколи не може бути записана в який-небудь об’єкт, що має більше низький рівень, ніж її джерело, оскільки це могло б потенційно привести по необережності до руйнування класифікації інформації в розглянутій системі. Методом представлення даних є визначення двох компонентів. Перший з них – це ієрархічний компонент. Другий компонент являє собою деяку множину неієрархічних категорій. Мета моделювання є управління суб’єктами, тобто активними процесами, що запитують доступ до інформації. Основна теорема безпеки Белла-ЛаПадули приведена на рис. 8.7.

До переваг цієї та інших моделей МПІБ можна віднести високий ступінь надійності, прості та ясні для розуміння розробниками і користувачами правила, стійкість до атак типу «троянський кінь», можливість точного математичного доказу того, що дана система в заданих умовах підтримує ПІБ. Недоліком мандатної (повноважної) політики інформаційної безпеки є виняткова складність для практичної реалізації і значні вимоги до ресурсів обчислювальної системи. Тим не менш МПІБ прийнята всіма розвинутими державами світу. Вона розроблялася, головним чином, для збереження секретності (тобто конфіденційності) інформації у військових організаціях. Питання ж цілісності за її допомогою не розв’язуються або розв’язуються частково, як побічний результат захисту секретності.

 

8.3. Рольова модель політики інформаційної безпеки

 

Рольову політику інформаційної безпеки (РПІБ - Role Base Access Control) не можна віднести ані до дискреційної, ані до мандатної, тому що управління доступом у ній здійснюється як на основі матриці прав доступу для ролей, так і за допомогою правил, які регламентують призначення ролей користувачам та їх активацію під час сеансів. Отже, рольова модель (рис. 8.8) є цілком новим типом політики, яка базується на компромісі між гнучкістю керування доступом, характерною для ДПІБ, і жорсткістю правил контролю доступу, що притаманна МПІБ.

 

Рис. 8.8. Рольова політика безпеки

 

У РПІБ класичне поняття суб’єкт заміщується поняттями користувач і роль. Користувач – це людина, яка працює з системою і виконує певні службові обов’язки. Роль – це активно діюча в системі абстрактна сутність, з якою пов’язаний обмежений, логічно зв’язаний набір повноважень, необхідних для здійснення певної діяльності. РПІБ застосовується досить широко, тому що вона, на відміну від інших більш строгих і формальних політик, є дуже близькою до реального життя. Справді, по суті, користувачі, що працюють у системі, діють не від свого власного імені – вони завжди виконують певні службові обов’язки, тобто виконують деякі ролі, які аж ніяк не пов’язані з їх особистістю. Тому цілком логічно здійснювати управління доступом і призначати повноваження не реальним користувачам, а абстрактним (не персоніфікованим) ролям, які представляють учасників певного процесу обробки інформації. Такий підхід до ПБ дозволяє врахувати розподіл обов’язків і повноважень між учасниками прикладного інформаційного процесу, оскільки з точки зору РПБ має значення не особистість користувача, що здійснює доступ до інформації, а те, які повноваження йому необхідні для виконання його службових обов’язків.

Наприклад, у реальній системі обробки інформації системний адміністратор, менеджер баз даних і прості користувачі. У такій ситуації РПБ дає змогу розподілити повноваження між цими ролями відповідно до їх службових обов’язків: ролі адміністратора призначаються спеціальні повноваження, які дозволять йому контролювати роботу системи і керувати її конфігурацією, роль менеджера баз даних дозволяє здійснювати керування сервером БД, а права простих користувачів необхідним для запуску прикладних програм. Крім того, кількість ролей у системі може не відповідати кількості реальних користувачів - один користувач, якщо він має різні повноваження, може виконувати (водночас або послідовно) кілька ролей, а кілька користувачів можуть користуватися однією й тією ж роллю, якщо вони виконують однакову роботу.

Принципи рольового управління:

усі суб’єкти і об’єкти повинні бути однозначно ідентифікованими;

у системі має бути визначено набір ролей у системі;

кожній ролі має бути встановлено певний обсяг повноважень;

доступ суб’єктів до об’єктів має здійснюватися на підставі певних правил в рамках певної ролі.

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

авторизація в даному сеансі користувача з однієї або декількома дозволеними (призначеними на другому етапі організації доступу) для нього ролями;

дозвіл або заборона суб’єктам користувача доступу до об’єктів системи в рамках повноважень відповідних ролей, з котрими авторизований в даному сеансі користувач.

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

У базовій моделі рольового розмежування прав доступу визначаються такі множини: U – множина користувачів, R – множина ролей, P – множина повноважень на доступ до об’єктів, що може бути подана у вигляді матриці доступу, S – множина сеансів роботи користувача із системою. Множина повноважень P у загальному вигляді задається спеціальними механізмами, що об’єднують операції доступу та об’єкти доступу, наприклад, запитами на обробку даних у СУБД, або іншими іменованими процедурами обробки даних, в тому числі можливо високого логічного рівня.

Для названих множин визначають такі відношення:

 

PA Í P ´ R – відображає множину повноважень на множину ролей, встановлюючи для кожної ролі набір наданих їй повноважень

 

UA Í U ´ R – відображає множину користувачів на множину ролей, встановлюючи для кожного користувача набір доступних йому ролей.

 

Відображення P*R і U*R забезпечують перший і другий етапи процесів організації системи рольового доступу. При цьому відображення U*R може реалізовуватися механізмами однією з базових політик розмежування доступу - матрицею "Користувачі-Ролі", або на основі співвідношення ступенів допуску користувачів і грифів конфіденційності ролей, або на основі співвідношення дозволених тематик користувача і тематики ролей.

Управління доступом в ІС здійснюється на основі введення таких функцій:

 

user: S → U – значенням функції u = user(s) є користувач u U, що здійснює даний сеанс роботи з системою;

 

roles: S → R – значенням функції r = roles(s) є набір ролей r R з доступних користувачеві u, по яких користувач працює (здійснює доступ) у даному сеансі s S;

permissions: S → P – значенням функції p = Fpermissions(s) є набір повноважень p P, доступних за всіма ролям, задіяним користувачем у даному сеансі s S.

 

Основне правило (критерій безпеки) рольового доступу визначається наступним чином: система функціонує безпечно, тоді і тільки тоді, коли будь-який користувач u U, що працює в сеансі s S, може здійснювати дії (операції, процедури) в рамках повноваження p P за умови

 

p P, де P = permissions(s).

 

З формулювання критерію безпеки моделі РПІБ виходить, що управління доступом здійснюється головним чином не за допомогою призначення повноважень ролям, а шляхом задання відношення UA, яке призначає ролі користувачам, і функції roles, що визначає доступний в сеансі набір ролей. Тому числені інтерпретації рольової моделі відрізняються видом функцій user, roles і permission, a також обмеженнями, що накладаються на відношення РА та UA.

Date: 2015-06-11; view: 999; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию