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

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

on

  • 260 views

 

Statistics

Views

Total Views
260
Views on SlideShare
260
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Моделирование безопасности управления доступом и информационными потоками на основе ДП-моделей Денис Колегов Кафедра защиты информации и криптографии Томский государственный университет 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
  • Виды мандатных политик s2file2 s1 writem write file1 read read Low High TE LBACMLS 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 httpddata 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 31
  • 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