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