Моделирование безопасности

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

информационными потоками на

основе ДП-моделей

Денис Колегов Кафедра защиты информации и криптографии

Томский государственный университет Positive Hack Days IV

21 – 22 мая 2014

Содержание

• Терминология

• Особенности разработки систем с мандатным

управлением доступом на основе модели BLP

• Модели как примитивы – Построение иерархической ролевой модели RBAC-H

– Аутентификация HTTP-сообщений в рамках модели ABAC

• Основные элементы ДП-моделей

• Реализация ДП-моделей на практике

2

Зачем нужны модели?

• Оценка безопасности IT-технологии (Common Criteria, EAL5+) – Строгое доказательство того, что в рамках формальной модели политики

безопасности невозможно перейти в небезопасное состояние

– Демонстрация (доказательство) соответствия между функциональной спецификацией

функций безопасности и моделью ПБ

• Разработка механизмов управления доступом – ОС и СУБД

– АСУ ТП

– WEB-приложения, ERP-системы

• Модели как примитивы в разработке (RBAC-A, RBAC-H, ДП-модели)

• Формальная доказуемость корректности программной реализации

политики управления доступом

• Научное изложение и обоснование результатов исследований

3

Терминология в области

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

4

Виды управления доступом

• Дискреционное (DAC)

– Управление доступом к сущностям (но не к информации в них),

реализуемое их субъект-владельцами

• Мандатное (MAC)

– Управление доступом осуществляется только специальными

субъектами

– LBAC (MLS) и TE

• Ролевое (RBAC)

– Управление доступом субъектов к сущностям только через роли, но

не напрямую

– Может реализовывать MAC или DAC

• Атрибутное (ABAC)

– Обобщает все виды управления доступом

5

Дискреционная политика

• Управление доступом субъектом-владельцем (DAC или IBAC)

• Каждая сущность имеет владельца-пользователя

• Пользователь может передавать права доступа другим

пользователям

• Виды

– Строгое (Linux)

– Либеральное (MySQL)

6

Дискреционная политика

• Все сущности должны быть идентифицированы

• Задана матрица доступов

• Любой субъект, обладающий специальным правом доступа к

сущности, может передать имеющиеся у него права доступа к

этой сущности другим субъектам

• Субъект обладает правом доступа к сущности КС в том, и

только в том случае, когда в соответствующей ячейке матрицы

доступов содержится данное право доступа

7

Мандатная политика

• Строгое (системное) управление доступом и

информационными потоками

• Основные виды

– TE (DTE)

– LBAC (MLS)

– Тематическое

– Ролевое

– Мандатное ролевое

• Защита от информационных потоков «сверху-вниз»

8

Виды мандатных политик

s2 file2

s1

writem

write

file1

read

read

Low

High

TE

LBAC MLS

9

Мандатная политика (LBAC)

• Все сущности должны быть идентифицированы

• Задана решетка уровней конфиденциальности информации

• Каждой сущности присвоен уровень конфиденциальности

• Каждому субъекту системы присвоен уровень доступа

• Субъект может получить доступ к сущности

– уровень доступа субъекта позволяет предоставить ему данный доступ к

сущности с заданным уровнем конфиденциальности

– реализация доступа не приведет к возникновению информационных

потоков от сущностей с высоким уровнем конфиденциальности к

сущностям с низким уровнем конфиденциальности

10

Ролевая политика

• Ролевые политики позволяют построить управление доступом,

учитывающее специфику выполняемых пользователем

операций в системе

• Права доступа не могут быть назначены субъекту и

использованы субъектом напрямую

• Развитие модели

– NIST RBAC (2000 г.)

– Sandhu (1996 г.)

– Ferraiolo, Kuhn (1992 г.)

• Виды

– дискреционное

– мандатное

– атрибутное 11

Ролевая политика

• Все сущности должны быть идентифицированы

• Задано множество ролей, представляющих собой некоторое

множество прав доступа к сущностям

• Каждый субъект обладает множеством разрешенных

(авторизованных) для него ролей

• Субъект может получить право доступа к сущности если он

авторизован на одну из ролей, которая содержит данное право

доступа к заданной сущности

12

Ролевая политика

• Пользователь с ролью 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

Атрибутная политика

• Обобщает все известные виды политик управления доступом

• Основа для единого механизма управления доступом в системе

• Права доступов субъектов к сущностям не назначаются, а

«вычисляются» в зависимости от свойств субъекта и сущности

• Области использования ABAC

– ADC для веб-приложений

– ABE для облаков

– Операционные системы (ABACα)

14

Атрибутная политика

• Все сущности (субъекты и объекты)

идентифицированы

• Заданы множества атрибутов сущностей,

атрибутов внешней среды и видов

доступа

• Каждой сущности соответствует

некоторое множество атрибутов

15

• Субъект может получить доступ к сущности, если истинен

логический предикат, соответствующий доступу субъекта к

сущности, вычисленный от атрибутов сущностей и внешней

среды

Скрытые каналы

• Изначально рассматривались только в рамках безопасности систем с

мандатным управлением доступом

• В настоящее время трактуются более широко ‒ CWE-385

– Каналы управления для ботнетов

– Оракулы

– Тайминговые атаки

• Скрытые каналы (информационные потоки)

– По памяти

– По времени

• Примеры

– Поток на основе сокетов

– Поток на основе времени модификации файла

– Поток на основе HTTP заголовков для кэширования 16

Поток через сокеты

• Если субъекту 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

Поток через время модификации

• Если субъекту 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

Потоки по времени в HTTP

• Субъект Server читает данные из data – Если необходимо передать 0, то он не предпринимает никаких действий

– Если необходимо передать 1, то Server меняет содержимое web page. При

этом веб-сервер изменит заголовок Last-Modified

• Субъект Agent делает запрос к странице web page и считывает нужный

HTTP заголовок – Если заголовок изменился, то передана 1

– Иначе передан 0

19

httpd data server web page Last-Modified agent data

read read writet read write

writet

writet

• Существует ли алгоритм, позволяющий в общем случае определить,

что система безопасна?

• Харрисон, Руззо и Ульман “Protection in Operating System”, 1976

• Теорема: задача проверки безопасности произвольных систем ХРУ

алгоритмически неразрешима

– Задача проверки получения субъектом S права доступа к сущности E

алгоритмически не разрешима.

• Идея доказательства – представление МТ в виде системы ХРУ

Фундаментальные результаты

20

Фундаментальные результаты

• Jones, Lipton, Snyder “A linear time algorithm for deciding security”,

1976

– Описан широкий класс теоретико-графовых моделей, для которых

задача проверки безопасности алгоритмически разрешима за

полиномиальное время

• Модель Take-Grant

– Системы с дискреционным управлением доступом

– Анализ путей распространения прав доступом

– Первоначально ориентированы на СУБД

21

Особенности разработки систем с

мандатным управлением доступом

на основе модели BLP

22

Недостатки модели BLP

• Основная модель для систем с мандатным управлением

• Отсутствие логической связи условий выполнения свойств

безопасности

– разработчик при добавлении нового функционала может добавить даже

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

• Отсутствие правил перехода из состояния в состояние – уязвимость в политики «low water mark», Z-система

• Отсутствуют механизмы защиты от информационных потоков по

времени при кооперации субъектов

– поток через clipboard

– поток через жесткие ссылки

• Модель BLP создавалась для ОС Multics

– поток через procfs

23

Пример политики «low water mark»

• В модели BLP не определяется порядок действий системы при

переходе из одного состояния в другое

• Политика low-watermark

– По запросу субъекта ему ВСЕГДА необходимо предоставить доступ на

запись в сущность

– При этом уровень конфиденциальности сущности понижается до уровня

доступа субъекта

– Очевидно, что “стирание” информации при доступе на запись является

существенным требованием, НО и без него модель остается формально

безопасной

24

write

H

L

read, write

secret

Поток через доступ на чтение

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

Поток через clipboard

• Субъект Sy записывает в clipboard какую-либо строку, например, «Тест»

• Если субъекту Sх необходимо передать 0, то он не предпринимает никаких

действий, иначе, когда надо передать 1, субъект Sх записывает в clipboard любые

данные

• Субъект Sy считывает данные из clipboard. Если получена строка «Тест», то был

передан 0, иначе, если получена пустая строка, то передана 1

26

Поток через “жесткие ссылки”

• Пусть существует сущность-контейнер Dhigh и сущность-контейнер Dlow, содержащая

сущность-файл Flow

• Если субъекту-процессу Shigh необходимо передать 0, он ничего не предпринимает,

когда надо передать 1, он создает «жесткую» ссылку на Flow в Dhigh

• Субъект-процесс Slow запрашивает число «жестких» ссылок на сущность-файл Flow.

Если оно не изменилось, то передан 0, иначе - передана 1

27

Поток через procfs

• Если процессу S1 нужно передать 1, то он создает дополнительную нить.

При этом сам процесс никак не взаимодействует с файловой системой для

создания запрещенного потока

• Все операции выполняет доверенный субъект – ядро ОС

28

s1: pthread_create read

writet

write

file1

s2 write

file2

read

/proc/pid1/status

kernel

Модели как примитивы

29

Модели как примитивы

• Модели безопасности могут быть использованы в качестве

примитивов для построения других моделей

• Это позволяет

– Cтроить более адекватные модели

– Эффективно реализовывать управление доступом,

учитывая специфику системы и требования безопасности

• Примеры

– LBAC на основе RBAC

– DAC на основе RBAC

– RBAC-A: RBAC и ABAC

– ДП-модели: Take-Grant, СВС, BLP, ИПС, RBAC

30

Объединение моделей

• Разработка механизма управления доступом на основе

простого соединения двух моделей может привести к

появлению новых недостатков

• Согласование свойств моделей безопасности

• Соединение RBAC и BLP

– Потоки по времени “сверху-вниз” с использованием назначения и

отзыва прав доступа ролей

– Потоки по времени “сверху-вниз” с использованием механизма

ограничений

– При этом в модели BLP вообще отсутствуют механизмы защиты от

потоков по времени

31

Модель для АСУ ТП

• Политика доступа

– Субъект обладает правом доступа к

объекту если его уровень иерархии не

меньше уровня иерархии объекта

• Свойства системы

– Иерархичность

– Идентичный состав

– Большое число объектов

– Большое число пользователей

– Большое число ролей

– Большое число неэлементарных прав

доступа

32

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

Модель RBAC-H

34

• Роли рассматриваются как набор прав доступа к сущностям или

типам сущностей

• Доступ субъекта к сущности осуществляется при выполнении

условий доступа с учетом иерархии сущностей и прав доступа

роли

• Может быть использована совместно с атрибутивным

управлением доступом

Аутентификация HTTP-сообщений

• Протокол HTTP не имеет механизмов аутентификации

сообщений (запросов и ответов)

– Аутентичность источника запроса

– Целостность данных

• Требования

– Контроль целостности имен и значений параметров

– Валидация параметров в заданном алфавите

– Возможность контроля данных, генерируемых на клиенте

• Модель ABAC

– Атрибут – свойство сущности, выраженное в виде «имя:значение»

– Объект – ресурс или запрашиваемая сущность

– Субъект – механизм, функционирующий от имени пользователя

35

Элементы ABAC

• O – объекты, соответствующие HTTP-ресурсам и

идентифицируемые тройкой (scheme, authority, path) в URI

• OA – атрибуты объекта, соответствующие разрешенным

«параметрам» доступа к ресурсу

• S – субъект-сессии, соответствующие HTTP-запросам и

сессиям

• SA – атрибуты субъект-сессии, соответствующие «параметрам»

и заголовкам

• OP – методы GET, POST, PUT, DELETE, …

36

Модель ABAC

• Аутентификатор сущности – строка, построенная по атрибутам

сущности в соответствии с политикой безопасности

• Auth = {упорядоченный список имен параметров} +

{cписок (имя параметра = значение) +

список (имя параметра = #)} +

идентификатор субъекта +

идентификатор объекта +

операция

• Атрибут объекта mac = h(kr, auth, time)

• HTTP-сообщение является аутентичным, если и только если

mac = h(kr, auth, time) ≡ mac’= h(kr, auth’, time)

37

Реализация 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

Анализ основных моделей

Свойство системы TG BLP СВС ИПС

Различие в условиях реализации потоков по памяти и по

времени ‒ ‒ ‒ ‒

Наличие иерархической структуры сущностей и возможность ее

использования для реализации потоков по времени + ‒ + ‒

Возможность кооперации субъектов + ‒ ‒ ‒

Возможность реализации доверенных субъектов с различными

условиями функционирования ‒ + ‒ +

Возможность противодействия доверенными субъектами при

передаче прав доступа или реализации запрещенных потоков

недоверенными субъектами + ‒ ‒ ‒

Возможность изменения вида преобразования данных,

реализуемого субъектом ‒ ‒ ‒ +

Необходимость реализации различных правил управления

доступом для распределенных компонент ‒ ‒ ‒ ‒

Возможность идентификации вида преобразования данных

реализуемого субъектом ‒

‒

‒

‒

40

Общие характеристики

• ДП-модели – формальные модели безопасности управления

доступом и информационными потоками

• П.Н. Девянин «Анализ безопасности управления доступом и

информационными потоками в компьютерных системах», 2006 г.

• Основные использованные модели

– Take-Grant

– СВС

– BLP и ее расширения

– ИПС

– RBAC

41

Основные ДП-модели

42

Общие характеристики

• Моделируемая система представляется абстрактной системой

– Каждое состояние системы - граф доступов

– Переход из состояния в состояние - правила преобразования

• Вместо множества объектов рассмотрено множество сущностей

(объектов и контейнеров) с заданной на нем иерархией

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

Ассоциированные сущности

• Модель ИПС, Щербаков А.Ю.

• Сущности

– ФАС – сущность, данные в которой влияют на вид преобразования

данных реализуемого субъектом

– ПАС – сущность, данные в которой определяют вид

преобразования данных реализуемого субъектом

• Предположения

– Если субъект S1 реализовал поток по памяти от себя к ФАС с S2 , то

S1 получает право владения к S2

– Если субъект S1 реализовал поток по памяти к себе от ПАС с S2, то

S1 получает право владения к S2

45

Ассоциированные сущности

Субъект-нарушитель

Субъект-сессия

ПАС: пароли, Cookies

writem

ownr

writem

readr

Секретный файл readr

46

ФАС: уязвимость в коде, библиотеки

1

2

3 1

readr readr y c y c … … b d s

… … b s

readr readr

x a x a

Блокирующие доступы

47

writet writet

read

write

Доверенные субъекты через доступы могут препятствовать реализации

запрещенных потоков по времени через иерархию сущностей

Пример правил преобразований

48

Построение ДП-модели

• Исходные данные

– Политики управления доступом и информационными потоками

– Модель угроз

– Свойства и особенности функционирования системы

• Формулирование предположений модели на основе модели угроз и

свойств системы

• Описание элементов модели (сущности, субъекты, иерархия

сущностей, права доступа, уровни безопасности, роли и т.д.)

• Задание правил преобразований

– Де-юре – формальная спецификация функций управления

доступом в системе в соответствии с требованиями ПБ

– Де-факто – теоретические исследования

49

Построение ДП-модели

• Формализация понятия безопасности системы в

форме логических предикатов

– can_share_own(x, y) – может ли субъект X получить право

доступа владения к сущности Y?

– can_write(x,y) – возможна ли реализация запрещенного

потока по памяти от сущности X к сущности Y?

• Доказательство безопасности системы в рамках

построенной модели в форме теоремы

• Разработка методов обеспечения безопасности

системы в рамках модели

50

Реализация ДП-моделей на

практике

51

Проекты

• Отечественная защищенная ОС Astra Linux Special

Edition

– Мандатная сущностно-ролевая ДП-модель ОС GNU/Linux

(МРОСЛ ДП-модель)

– Мандатное и ролевое управление доступом и

информационными потоками

– Принципиально новые элементы и механизмы RBAC

• MAC MySQL

– ДП-модель MySQL c мандатным управлением доступом

– Решение уровня DAM (Database Firewall)

– Мандатный контроль целостности

52

ДП-модель СУБД MySQL

• СУБД MySQL изначально имеет дискреционное управление

доступом

• В связи с особенность архитектуры MySQL субъект-сессия не

может одновременно выполнять запросы на чтение и запись

• Исключение составляют потенциально опасные в политике MLS

запросы

– «INSERT INTO … VALUES((SELECT…), …)»

– «INSERT … SELECT»

– «UPDATE … SET … = (SELECT …)»

• Множество способов реализации запрещенных потоков по

времени

53

Пример потока по памяти в 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

Пример потока по времени в 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;

ДП-модель СУБД MySQL

• Ограничения

– Информационные потоки рассматриваются в рамках СУБД

– Рассматриваются только информационные потоки по памяти, порождаемые

SQL-операторами SELECT, INSERT, UPDATE и DELETE

– Информационные потоки по времени не рассматриваются

• Предположения

– Уровни конфиденциальности сущностей наследуются

– Уровень конфиденциальности контейнера не меньше уровня

конфиденциальности, содержащихся в нем сущностей

• Учет специфики MySQL

– Субъект не может реализовывать доступ к нескольким сущностям

одновременно

– Конкретизация видов прав доступа и видов доступов

– SQL-операторы, нарушающие *-свойство

56

МРОСЛ ДП-модель

• Учет специфики ОС GNU/Linux

– Виды прав доступа и виды доступов Rr = {readr, writer,

executer, ownr} и Ra = {reada, writea}

– Жесткие ссылки

– Разделяемые контейнеры

– Сущности дырки (/dev/null или /dev/zero) – сущности-

объекты, в которых записываемые данные не сохраняются

• Более 30 де-юре правил преобразования состояний

• Правила администрирования системы

• Описание модели - http://journals.tsu.ru/pdm/ 57

Реализация RBAC

• Реализация ролей как сущностей-контейнеров (директорий) в

файловой системе

– Иерархия ролей – аналог файловой системы

– Права на роли

• ownr – владеть ролью

• readr – получать роль

• writer – изменять множество прав доступа роли

• executer – право обращаться к подчиненным ролям в иерархии

• Роли считаются источниками и приемниками информационных

потоков по памяти и по времени

• Для администрирования ролей впервые задается через

административные права доступа административных ролей

58

Реализация ролей как директорий

• Иерархия ролей – аналог иерархии сущностей

• Ролевое администрирование – управление правами доступа (readr,

writer, executer, ownr) индивидуальных административных ролей

учетной записи пользователя к ролям

• Авторизация на роль – административные доступы субъект-сессий на

чтение reada к ролям

• Изменение прав доступа роли – административные доступы субъект-

сессий на запись writea к ролям

• Доступы к ролям – контролируются едиными мандатными управлением

доступом и контролем целостности, ролевым управлением доступом

• Информационные потоки по времени – анализируются (в том числе,

между сущностями и ролями)

59

Базовый подход

• Построение формальной ДП-модели

• В соответствии с целями безопасности формулирование и

обоснование условий безопасности системы

• Получение из формальной модели спецификаций (предусловия

и постусловия) функций, реализующих механизм управления

доступом

• Обоснование корректности реализации функций

непосредственно в программном коде. Верификация

программного кода

60

Благодарю за внимание!

Вопросы?

Колегов Денис Доцент кафедры защиты информации и криптографии

Томский государственный университет

E-mail: dnkolegov@gmail.com

Twitter: dnkolegov

61

Литература

• 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

Основные работы по ДП-моделям

• Девянин П.Н. Модели безопасности компьютерных систем. Управление доступом и

информационными потоками. Учебное пособие для вузов. 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

Зарубежные ресурсы

• 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