• Like
Моделирование безопасности управления доступом и информационными потоками на основе ДП-моделей
Upcoming SlideShare
Loading in...5
×

Моделирование безопасности управления доступом и информационными потоками на основе ДП-моделей

  • 407 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
407
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Моделирование безопасности управления доступом и информационными потоками на основе ДП-моделей Денис Колегов Кафедра защиты информации и криптографии Томский государственный университет Positive Hack Days IV 21 – 22 мая 2014
  • 2. Содержание • Терминология • Особенности разработки систем с мандатным управлением доступом на основе модели BLP • Модели как примитивы – Построение иерархической ролевой модели RBAC-H – Аутентификация HTTP-сообщений в рамках модели ABAC • Основные элементы ДП-моделей • Реализация ДП-моделей на практике 2
  • 3. Зачем нужны модели? • Оценка безопасности IT-технологии (Common Criteria, EAL5+) – Строгое доказательство того, что в рамках формальной модели политики безопасности невозможно перейти в небезопасное состояние – Демонстрация (доказательство) соответствия между функциональной спецификацией функций безопасности и моделью ПБ • Разработка механизмов управления доступом – ОС и СУБД – АСУ ТП – WEB-приложения, ERP-системы • Модели как примитивы в разработке (RBAC-A, RBAC-H, ДП-модели) • Формальная доказуемость корректности программной реализации политики управления доступом • Научное изложение и обоснование результатов исследований 3
  • 4. Терминология в области управления доступом 4
  • 5. Виды управления доступом • Дискреционное (DAC) – Управление доступом к сущностям (но не к информации в них), реализуемое их субъект-владельцами • Мандатное (MAC) – Управление доступом осуществляется только специальными субъектами – LBAC (MLS) и TE • Ролевое (RBAC) – Управление доступом субъектов к сущностям только через роли, но не напрямую – Может реализовывать MAC или DAC • Атрибутное (ABAC) – Обобщает все виды управления доступом 5
  • 6. Дискреционная политика • Управление доступом субъектом-владельцем (DAC или IBAC) • Каждая сущность имеет владельца-пользователя • Пользователь может передавать права доступа другим пользователям • Виды – Строгое (Linux) – Либеральное (MySQL) 6
  • 7. Дискреционная политика • Все сущности должны быть идентифицированы • Задана матрица доступов • Любой субъект, обладающий специальным правом доступа к сущности, может передать имеющиеся у него права доступа к этой сущности другим субъектам • Субъект обладает правом доступа к сущности КС в том, и только в том случае, когда в соответствующей ячейке матрицы доступов содержится данное право доступа 7
  • 8. Мандатная политика • Строгое (системное) управление доступом и информационными потоками • Основные виды – TE (DTE) – LBAC (MLS) – Тематическое – Ролевое – Мандатное ролевое • Защита от информационных потоков «сверху-вниз» 8
  • 9. Виды мандатных политик s2file2 s1 writem write file1 read read Low High TE LBACMLS 9
  • 10. Мандатная политика (LBAC) • Все сущности должны быть идентифицированы • Задана решетка уровней конфиденциальности информации • Каждой сущности присвоен уровень конфиденциальности • Каждому субъекту системы присвоен уровень доступа • Субъект может получить доступ к сущности – уровень доступа субъекта позволяет предоставить ему данный доступ к сущности с заданным уровнем конфиденциальности – реализация доступа не приведет к возникновению информационных потоков от сущностей с высоким уровнем конфиденциальности к сущностям с низким уровнем конфиденциальности 10
  • 11. Ролевая политика • Ролевые политики позволяют построить управление доступом, учитывающее специфику выполняемых пользователем операций в системе • Права доступа не могут быть назначены субъекту и использованы субъектом напрямую • Развитие модели – NIST RBAC (2000 г.) – Sandhu (1996 г.) – Ferraiolo, Kuhn (1992 г.) • Виды – дискреционное – мандатное – атрибутное 11
  • 12. Ролевая политика • Все сущности должны быть идентифицированы • Задано множество ролей, представляющих собой некоторое множество прав доступа к сущностям • Каждый субъект обладает множеством разрешенных (авторизованных) для него ролей • Субъект может получить право доступа к сущности если он авторизован на одну из ролей, которая содержит данное право доступа к заданной сущности 12
  • 13. Ролевая политика • Пользователь с ролью User Manager может понизить роль пользователя admin с Administrator до Guest • Сначала происходит удаление учетной записи с ролью Administrator, а затем ее создание с ролью Noaccess • Нарушение основного принципа RBAC – назначения прав через механизм ролей /* A User Manager may not change an administrator */ if (ctx->role()->id() == schema::ROLE_USER_MANAGER) { if ((role == schema::ROLE_ADMINISTRATOR) || (prev_role == schema::ROLE_ADMINISTRATOR)) { stringstream msg; msg << "User (" << ctx->username() << ") may not change the role " "of Administrator (" << user_name << ")."; …}} 13
  • 14. Атрибутная политика • Обобщает все известные виды политик управления доступом • Основа для единого механизма управления доступом в системе • Права доступов субъектов к сущностям не назначаются, а «вычисляются» в зависимости от свойств субъекта и сущности • Области использования ABAC – ADC для веб-приложений – ABE для облаков – Операционные системы (ABACα) 14
  • 15. Атрибутная политика • Все сущности (субъекты и объекты) идентифицированы • Заданы множества атрибутов сущностей, атрибутов внешней среды и видов доступа • Каждой сущности соответствует некоторое множество атрибутов 15 • Субъект может получить доступ к сущности, если истинен логический предикат, соответствующий доступу субъекта к сущности, вычисленный от атрибутов сущностей и внешней среды
  • 16. Скрытые каналы • Изначально рассматривались только в рамках безопасности систем с мандатным управлением доступом • В настоящее время трактуются более широко ‒ CWE-385 – Каналы управления для ботнетов – Оракулы – Тайминговые атаки • Скрытые каналы (информационные потоки) – По памяти – По времени • Примеры – Поток на основе сокетов – Поток на основе времени модификации файла – Поток на основе HTTP заголовков для кэширования 16
  • 17. Поток через сокеты • Если субъекту S1 нужно передать 1, то он создает сокет на порту X. Если нужно передать 0, то он ничего не делает • Субъект S2 также создает сокет на порту X • В случае успеха – был передан 0, иначе – 1 17 s1 read writet write /fs/virtual/file1 s2 write file2 read socket_x chroot /fs/virtual
  • 18. Поток через время модификации • Если субъекту S2 нужно передать 1, то он последовательно создает или удаляет файл в /dir. Если нужно передать 0, то он ничего не делает • Субъект S1 считывает время модификации /dir через stat • Если время модификации с момента последней проверки изменилось, то передан 1, иначе – 0 18 S2: touch /dir/tmp rm –rf /dir/tmp S1: stat /dir s2 write writet readr nonsecret s1 readr secret create / /dir (700) ˅ ˅ /dir/tmp ownr, writer delete
  • 19. Потоки по времени в HTTP • Субъект Server читает данные из data – Если необходимо передать 0, то он не предпринимает никаких действий – Если необходимо передать 1, то Server меняет содержимое web page. При этом веб-сервер изменит заголовок Last-Modified • Субъект Agent делает запрос к странице web page и считывает нужный HTTP заголовок – Если заголовок изменился, то передана 1 – Иначе передан 0 19 httpddata server web page Last-Modified agent data read read writet read write writet writet
  • 20. • Существует ли алгоритм, позволяющий в общем случае определить, что система безопасна? • Харрисон, Руззо и Ульман “Protection in Operating System”, 1976 • Теорема: задача проверки безопасности произвольных систем ХРУ алгоритмически неразрешима – Задача проверки получения субъектом S права доступа к сущности E алгоритмически не разрешима. • Идея доказательства – представление МТ в виде системы ХРУ Фундаментальные результаты 20
  • 21. Фундаментальные результаты • Jones, Lipton, Snyder “A linear time algorithm for deciding security”, 1976 – Описан широкий класс теоретико-графовых моделей, для которых задача проверки безопасности алгоритмически разрешима за полиномиальное время • Модель Take-Grant – Системы с дискреционным управлением доступом – Анализ путей распространения прав доступом – Первоначально ориентированы на СУБД 21
  • 22. Особенности разработки систем с мандатным управлением доступом на основе модели BLP 22
  • 23. Недостатки модели BLP • Основная модель для систем с мандатным управлением • Отсутствие логической связи условий выполнения свойств безопасности – разработчик при добавлении нового функционала может добавить даже абсурдное свойство и противоречий в модели не возникнет • Отсутствие правил перехода из состояния в состояние – уязвимость в политики «low water mark», Z-система • Отсутствуют механизмы защиты от информационных потоков по времени при кооперации субъектов – поток через clipboard – поток через жесткие ссылки • Модель BLP создавалась для ОС Multics – поток через procfs 23
  • 24. Пример политики «low water mark» • В модели BLP не определяется порядок действий системы при переходе из одного состояния в другое • Политика low-watermark – По запросу субъекта ему ВСЕГДА необходимо предоставить доступ на запись в сущность – При этом уровень конфиденциальности сущности понижается до уровня доступа субъекта – Очевидно, что “стирание” информации при доступе на запись является существенным требованием, НО и без него модель остается формально безопасной 24 write H L read, write secret
  • 25. Поток через доступ на чтение 25 • Если субъекту Sх необходимо передать 1, то он открывает файл File в Dir на чтение • Субъект Sy пытается удалить открытый на чтение файл или директорию в которой он содержится. Если это удалось, то был передан 0, иначе 1 x read sx   write fs(sx) = fc(sx) = fo(x) = High write read write dir  delete write    fs(sy) = fc(sy) = fo(y) = Low sy write y fo(dir) = fo(file) = Low file  write
  • 26. Поток через clipboard • Субъект Sy записывает в clipboard какую-либо строку, например, «Тест» • Если субъекту Sх необходимо передать 0, то он не предпринимает никаких действий, иначе, когда надо передать 1, субъект Sх записывает в clipboard любые данные • Субъект Sy считывает данные из clipboard. Если получена строка «Тест», то был передан 0, иначе, если получена пустая строка, то передана 1 26
  • 27. Поток через “жесткие ссылки” • Пусть существует сущность-контейнер Dhigh и сущность-контейнер Dlow, содержащая сущность-файл Flow • Если субъекту-процессу Shigh необходимо передать 0, он ничего не предпринимает, когда надо передать 1, он создает «жесткую» ссылку на Flow в Dhigh • Субъект-процесс Slow запрашивает число «жестких» ссылок на сущность-файл Flow. Если оно не изменилось, то передан 0, иначе - передана 1 27
  • 28. Поток через procfs • Если процессу S1 нужно передать 1, то он создает дополнительную нить. При этом сам процесс никак не взаимодействует с файловой системой для создания запрещенного потока • Все операции выполняет доверенный субъект – ядро ОС 28 s1: pthread_create read writet write file1 s2 write file2 read /proc/pid1/status kernel
  • 29. Модели как примитивы 29
  • 30. Модели как примитивы • Модели безопасности могут быть использованы в качестве примитивов для построения других моделей • Это позволяет – Cтроить более адекватные модели – Эффективно реализовывать управление доступом, учитывая специфику системы и требования безопасности • Примеры – LBAC на основе RBAC – DAC на основе RBAC – RBAC-A: RBAC и ABAC – ДП-модели: Take-Grant, СВС, BLP, ИПС, RBAC 30
  • 31. Объединение моделей • Разработка механизма управления доступом на основе простого соединения двух моделей может привести к появлению новых недостатков • Согласование свойств моделей безопасности • Соединение RBAC и BLP – Потоки по времени “сверху-вниз” с использованием назначения и отзыва прав доступа ролей – Потоки по времени “сверху-вниз” с использованием механизма ограничений – При этом в модели BLP вообще отсутствуют механизмы защиты от потоков по времени 31
  • 32. Модель для АСУ ТП • Политика доступа – Субъект обладает правом доступа к объекту если его уровень иерархии не меньше уровня иерархии объекта • Свойства системы – Иерархичность – Идентичный состав – Большое число объектов – Большое число пользователей – Большое число ролей – Большое число неэлементарных прав доступа 32
  • 33. RBAC-H для АСУ ТП Типы • T = {(T1, T2)} • Каждый объект имеет тип Роли с учетом типов • ENG={(T1, w)} • DISP={(T2, r)} Функция ролей субъектов • roles(si)={ENG}, i=1, 3, 5 • roles(si)={DISP}, i=2, 4, 6 Критерий доступа: Пользователь s имеет доступ к объекту o если и только если выполнены условия: • H(o)≤H(s) • Привилегия (type(o),p) содержится в одной из ролей, на которую авторизован s 33
  • 34. Модель RBAC-H 34 • Роли рассматриваются как набор прав доступа к сущностям или типам сущностей • Доступ субъекта к сущности осуществляется при выполнении условий доступа с учетом иерархии сущностей и прав доступа роли • Может быть использована совместно с атрибутивным управлением доступом
  • 35. Аутентификация HTTP-сообщений • Протокол HTTP не имеет механизмов аутентификации сообщений (запросов и ответов) – Аутентичность источника запроса – Целостность данных • Требования – Контроль целостности имен и значений параметров – Валидация параметров в заданном алфавите – Возможность контроля данных, генерируемых на клиенте • Модель ABAC – Атрибут – свойство сущности, выраженное в виде «имя:значение» – Объект – ресурс или запрашиваемая сущность – Субъект – механизм, функционирующий от имени пользователя 35
  • 36. Элементы ABAC • O – объекты, соответствующие HTTP-ресурсам и идентифицируемые тройкой (scheme, authority, path) в URI • OA – атрибуты объекта, соответствующие разрешенным «параметрам» доступа к ресурсу • S – субъект-сессии, соответствующие HTTP-запросам и сессиям • SA – атрибуты субъект-сессии, соответствующие «параметрам» и заголовкам • OP – методы GET, POST, PUT, DELETE, … 36
  • 37. Модель ABAC • Аутентификатор сущности – строка, построенная по атрибутам сущности в соответствии с политикой безопасности • Auth = {упорядоченный список имен параметров} + {cписок (имя параметра = значение) + список (имя параметра = #)} + идентификатор субъекта + идентификатор объекта + операция • Атрибут объекта mac = h(kr, auth, time) • HTTP-сообщение является аутентичным, если и только если mac = h(kr, auth, time) ≡ mac’= h(kr, auth’, time) 37
  • 38. Реализация ABAC 38 • Параметры протокола – k – долговременный ключ сервера – kr – одноразовый случайный ключ сервера – idr – идентификатор объекта – ids – идентификатор субъекта – LP – политика безопасности – time – текущее значение времени • Действия протокола (ids, idr) – Client → Server: начальный запрос к ресурсу – Client ← Server: ответ с атрибутами mac = h(kr, auth, time) и Ek(LP, time, kr) – Client → Server: запрос к idr’, mac, Ek(P, time, kr)
  • 39. Основные элементы ДП-моделей 39
  • 40. Анализ основных моделей Свойство системы TG BLP СВС ИПС Различие в условиях реализации потоков по памяти и по времени ‒ ‒ ‒ ‒ Наличие иерархической структуры сущностей и возможность ее использования для реализации потоков по времени + ‒ + ‒ Возможность кооперации субъектов + ‒ ‒ ‒ Возможность реализации доверенных субъектов с различными условиями функционирования ‒ + ‒ + Возможность противодействия доверенными субъектами при передаче прав доступа или реализации запрещенных потоков недоверенными субъектами + ‒ ‒ ‒ Возможность изменения вида преобразования данных, реализуемого субъектом ‒ ‒ ‒ + Необходимость реализации различных правил управления доступом для распределенных компонент ‒ ‒ ‒ ‒ Возможность идентификации вида преобразования данных реализуемого субъектом ‒ ‒ ‒ ‒ 40
  • 41. Общие характеристики • ДП-модели – формальные модели безопасности управления доступом и информационными потоками • П.Н. Девянин «Анализ безопасности управления доступом и информационными потоками в компьютерных системах», 2006 г. • Основные использованные модели – Take-Grant – СВС – BLP и ее расширения – ИПС – RBAC 41
  • 42. Основные ДП-модели 42
  • 43. Общие характеристики • Моделируемая система представляется абстрактной системой – Каждое состояние системы - граф доступов – Переход из состояния в состояние - правила преобразования • Вместо множества объектов рассмотрено множество сущностей (объектов и контейнеров) с заданной на нем иерархией 43 G  z G’  z writer  writer writet  writet x  y x   y  ├ rename_entity(x, y, z)  … writet writet …   r r s  y’ s   y’
  • 44. Доверенные субъекты • Особенность построения отечественных защищенных систем, в которых можно говорить лишь о частичном доверии к компонентам системы • Функциональность доверенных субъектов можно верифицировать • Доверенные субъекты – Имеют или могут получить права доступа ко всем сущностям – Не передают права доступа недоверенным субъектам – Не участвуют в реализации запрещенных потоков по времени – Не создают субъектов 44
  • 45. Ассоциированные сущности • Модель ИПС, Щербаков А.Ю. • Сущности – ФАС – сущность, данные в которой влияют на вид преобразования данных реализуемого субъектом – ПАС – сущность, данные в которой определяют вид преобразования данных реализуемого субъектом • Предположения – Если субъект S1 реализовал поток по памяти от себя к ФАС с S2 , то S1 получает право владения к S2 – Если субъект S1 реализовал поток по памяти к себе от ПАС с S2, то S1 получает право владения к S2 45
  • 46. Ассоциированные сущности Субъект-нарушитель Субъект-сессия ПАС: пароли, Cookies writem ownr writem readr Секретный файлreadr 46 ФАС: уязвимость в коде, библиотеки 1 2 31
  • 47. readr readr y   c y   c   … …   b    d s    … …   b s   readr readr x   a x   a Блокирующие доступы 47 writet writet read write Доверенные субъекты через доступы могут препятствовать реализации запрещенных потоков по времени через иерархию сущностей
  • 48. Пример правил преобразований 48
  • 49. Построение ДП-модели • Исходные данные – Политики управления доступом и информационными потоками – Модель угроз – Свойства и особенности функционирования системы • Формулирование предположений модели на основе модели угроз и свойств системы • Описание элементов модели (сущности, субъекты, иерархия сущностей, права доступа, уровни безопасности, роли и т.д.) • Задание правил преобразований – Де-юре – формальная спецификация функций управления доступом в системе в соответствии с требованиями ПБ – Де-факто – теоретические исследования 49
  • 50. Построение ДП-модели • Формализация понятия безопасности системы в форме логических предикатов – can_share_own(x, y) – может ли субъект X получить право доступа владения к сущности Y? – can_write(x,y) – возможна ли реализация запрещенного потока по памяти от сущности X к сущности Y? • Доказательство безопасности системы в рамках построенной модели в форме теоремы • Разработка методов обеспечения безопасности системы в рамках модели 50
  • 51. Реализация ДП-моделей на практике 51
  • 52. Проекты • Отечественная защищенная ОС Astra Linux Special Edition – Мандатная сущностно-ролевая ДП-модель ОС GNU/Linux (МРОСЛ ДП-модель) – Мандатное и ролевое управление доступом и информационными потоками – Принципиально новые элементы и механизмы RBAC • MAC MySQL – ДП-модель MySQL c мандатным управлением доступом – Решение уровня DAM (Database Firewall) – Мандатный контроль целостности 52
  • 53. ДП-модель СУБД MySQL • СУБД MySQL изначально имеет дискреционное управление доступом • В связи с особенность архитектуры MySQL субъект-сессия не может одновременно выполнять запросы на чтение и запись • Исключение составляют потенциально опасные в политике MLS запросы – «INSERT INTO … VALUES((SELECT…), …)» – «INSERT … SELECT» – «UPDATE … SET … = (SELECT …)» • Множество способов реализации запрещенных потоков по времени 53
  • 54. Пример потока по памяти в MySQL • Cубъект Shigh реализует запрещенный информационный поток по памяти – INSERT into shared (data) SELECT secret.data from secret • Субъект Slow читает секретные данные из общедоступной таблицы – SELECT shared.data from shared 54 shigh shared select writem insert secret slow select insert nonsecret HIGH LOW writem
  • 55. Пример потока по времени в MySQL • Если субъекту Shigh нужно передать 1, то он блокирует общедоступную таблицу на запись. Если нужно передать 0, то субъект ничего не делает • Субъект Slow запрашивает доступ к общедоступной таблице. В случае успеха он считывает 0, иначе – 1 shigh shared read writet lock tables write secret slow read write nonsecret HIGH LOW 55 shigh “READ” bit from secret; LOCK TABLES shared write; UNLOCK TABLES; slow SELECT * from shared; “WRITE” bit to nonsecret;
  • 56. ДП-модель СУБД MySQL • Ограничения – Информационные потоки рассматриваются в рамках СУБД – Рассматриваются только информационные потоки по памяти, порождаемые SQL-операторами SELECT, INSERT, UPDATE и DELETE – Информационные потоки по времени не рассматриваются • Предположения – Уровни конфиденциальности сущностей наследуются – Уровень конфиденциальности контейнера не меньше уровня конфиденциальности, содержащихся в нем сущностей • Учет специфики MySQL – Субъект не может реализовывать доступ к нескольким сущностям одновременно – Конкретизация видов прав доступа и видов доступов – SQL-операторы, нарушающие *-свойство 56
  • 57. МРОСЛ ДП-модель • Учет специфики ОС GNU/Linux – Виды прав доступа и виды доступов Rr = {readr, writer, executer, ownr} и Ra = {reada, writea} – Жесткие ссылки – Разделяемые контейнеры – Сущности дырки (/dev/null или /dev/zero) – сущности- объекты, в которых записываемые данные не сохраняются • Более 30 де-юре правил преобразования состояний • Правила администрирования системы • Описание модели - http://journals.tsu.ru/pdm/ 57
  • 58. Реализация RBAC • Реализация ролей как сущностей-контейнеров (директорий) в файловой системе – Иерархия ролей – аналог файловой системы – Права на роли • ownr – владеть ролью • readr – получать роль • writer – изменять множество прав доступа роли • executer – право обращаться к подчиненным ролям в иерархии • Роли считаются источниками и приемниками информационных потоков по памяти и по времени • Для администрирования ролей впервые задается через административные права доступа административных ролей 58
  • 59. Реализация ролей как директорий • Иерархия ролей – аналог иерархии сущностей • Ролевое администрирование – управление правами доступа (readr, writer, executer, ownr) индивидуальных административных ролей учетной записи пользователя к ролям • Авторизация на роль – административные доступы субъект-сессий на чтение reada к ролям • Изменение прав доступа роли – административные доступы субъект- сессий на запись writea к ролям • Доступы к ролям – контролируются едиными мандатными управлением доступом и контролем целостности, ролевым управлением доступом • Информационные потоки по времени – анализируются (в том числе, между сущностями и ролями) 59
  • 60. Базовый подход • Построение формальной ДП-модели • В соответствии с целями безопасности формулирование и обоснование условий безопасности системы • Получение из формальной модели спецификаций (предусловия и постусловия) функций, реализующих механизм управления доступом • Обоснование корректности реализации функций непосредственно в программном коде. Верификация программного кода 60
  • 61. Благодарю за внимание! Вопросы? Колегов Денис Доцент кафедры защиты информации и криптографии Томский государственный университет E-mail: dnkolegov@gmail.com Twitter: dnkolegov 61
  • 62. Литература • Bishop M. Computer Security: Art and Science. - ISBN 0-201-44099-7, 2002. - 1084 p. • Девянин П.Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками. Учебное пособие для вузов. 2-е изд. – М.: Горячая линия-Телеком, 2013. – 338 с.: ил. • Гайдамакин Н.А. Теоретические основы компьютерной безопасности. http://elar.urfu.ru/bitstream/10995/1778/5/1335332_schoolbook.pdf • Щербаков А.Ю. Современная компьютерная безопасность. Теоретические основы. Практические аспекты. Учебное пособие. - М.: Книжный мир, 2009. - 352 с. • Журнал «Прикладная дискретная математика» (ТГУ). - http://journals.tsu.ru/pdm/ 62
  • 63. Основные работы по ДП-моделям • Девянин П.Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками. Учебное пособие для вузов. 2-е изд. – М.: Горячая линия- Телеком, 2013. – 338 с.: ил. • Девянин П.Н. Анализ безопасности управления доступом и информационными потоками в компьютерных системах. – М.: Радио и связь, 2006. – 176 с. • Колегов Д.Н., Ткаченко Н.О., Чернов Д.В. Разработка и реализация мандатных механизмов управления доступом в СУБД MySQL // Прикладная дискретная математика. 2013. № 6. С. 62–67. • Колегов Д.Н. Построение иерархического ролевого управления доступом // Прикладная дискретная математика. 2012. № 3. С. 70–77. • Колегов Д. Н. Анализ безопасности информационных потоков по памяти в компьютерных системах с функционально и параметрически ассоциированными сущностями // Прикладная дискретная математика. – 2009. – №1(3). – С. 117 – 126. • Смольянинов В.Ю. Правила преобразования состояний СУБД ДП-модели // Прикладная дискретная математика. 2013, № 1, С.50-68. • Шумилин А.В. Основные элементы мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в СУБД PostgreSQL ОС специального назначения Astra Linux Special Edition // Прикладная дискретная математика. 2013. № 3. С. 52 – 67. 63
  • 64. Зарубежные ресурсы • www.sacmat.org • www.profsandhu.com • www.csrc.nist.gov/rbac/ • http://csrc.nist.gov/projects/abac/ • http://secappdev.org • http://nob.cs.ucdavis.edu/bishop/ • http://csrc.nist.gov/publications/secpubs/rainbow/ 64