Positive Hack Days, profile picture
Uploaded byPositive Hack Days
2,115 views

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

Документ обсуждает моделирование безопасности управления доступом и информационными потоками, включая различные модели, такие как дискреционное, мандатное, ролевое и атрибутное управление доступом. Рассматриваются важные элементы моделей, их реализация на практике и недостатки существующих подходов. Также обсуждаются примеры скрытых каналов и способы их использования для передачи информации в системах безопасности.

Embed presentation

Downloaded 38 times
Моделирование безопасности управления доступом и информационными потоками на основе ДП-моделей Денис Колегов Кафедра защиты информации и криптографии Томский государственный университет 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

More Related Content

PDF
Моделирование безопасности управления доступом и информационными потоками на ...
byDenis Kolegov
 
PDF
Разработка и реализация механизма мандатного управления доступом в СУБД MySQL...
byDenis Kolegov
 
PDF
О построении иерархического ролевого управления доступом (SibeCrypt 2012)
byDenis Kolegov
 
PDF
23may 1845 valday young school tkachenko 'development and implementation of t...
byPositive Hack Days
 
PPT
Контент ориентированное программирование
byksmster
 
PDF
ук 03.002.01 2011
byetyumentcev
 
PDF
Применение виртуализации для динамического анализа
byPositive Hack Days
 
PDF
Flash умер. Да здравствует Flash!
byPositive Hack Days
 
Моделирование безопасности управления доступом и информационными потоками на ...
byDenis Kolegov
 
Разработка и реализация механизма мандатного управления доступом в СУБД MySQL...
byDenis Kolegov
 
О построении иерархического ролевого управления доступом (SibeCrypt 2012)
byDenis Kolegov
 
23may 1845 valday young school tkachenko 'development and implementation of t...
byPositive Hack Days
 
Контент ориентированное программирование
byksmster
 
ук 03.002.01 2011
byetyumentcev
 
Применение виртуализации для динамического анализа
byPositive Hack Days
 
Flash умер. Да здравствует Flash!
byPositive Hack Days
 

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

PPT
+ презентация лекций
byGulnaz Shakirova
 
PDF
RBAC & ABAC: гибридное решение для управления правами доступа
byCUSTIS
 
PDF
Безопасность ОС
byEvgeniy Mironov
 
PDF
Информационная безопасность банковских безналичных платежей. Части 7 и 8 — Ба...
byimbasoft ru
 
PDF
Организация защищенного доступа к данным
byIvan Ignatyev
 
PPTX
Total Privileged Account Manager (Иван Рудницкий, БАКОТЕК)
byBAKOTECH
 
PPT
средства разграничения доступа
bytrenders
 
PPT
лабораторная работа №3
byGulnaz Shakirova
 
PDF
Эффективный контроль административного доступа к АСУ ТП
byКомпания УЦСБ
 
PDF
Разработка и реализация мандатного механизма управления доступом в СУБД MySQL...
byDenis Kolegov
 
PPTX
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
byCUSTIS
 
PDF
Ib strategy 06
byКомпания УЦСБ
 
PDF
2015 08 26 ИБ Стратегия обороны серия №7
byКомпания УЦСБ
 
PDF
ИБ Стратегия обороны. Серия №3
byКомпания УЦСБ
 
PDF
ИБ Стратегия обороны. Серия №4 ч.2
byКомпания УЦСБ
 
PDF
Автоматизированное Управление Привилегированным Доступом: Эволюция Управления...
bySelectedPresentations
 
PDF
ИБ Стратегия обороны. Серия №4 ч.1
byКомпания УЦСБ
 
PDF
Требования в области информационной безопасности и соответствующие им решения...
byCisco Russia
 
PDF
Термины и определения в области защиты персональных данных
byПавел Семченко
 
PPTX
Доклад на v воронежском форуме ver. 0.3
byjournalrubezh
 
+ презентация лекций
byGulnaz Shakirova
 
RBAC & ABAC: гибридное решение для управления правами доступа
byCUSTIS
 
Безопасность ОС
byEvgeniy Mironov
 
Информационная безопасность банковских безналичных платежей. Части 7 и 8 — Ба...
byimbasoft ru
 
Организация защищенного доступа к данным
byIvan Ignatyev
 
Total Privileged Account Manager (Иван Рудницкий, БАКОТЕК)
byBAKOTECH
 
средства разграничения доступа
bytrenders
 
лабораторная работа №3
byGulnaz Shakirova
 
Эффективный контроль административного доступа к АСУ ТП
byКомпания УЦСБ
 
Разработка и реализация мандатного механизма управления доступом в СУБД MySQL...
byDenis Kolegov
 
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
byCUSTIS
 
Ib strategy 06
byКомпания УЦСБ
 
2015 08 26 ИБ Стратегия обороны серия №7
byКомпания УЦСБ
 
ИБ Стратегия обороны. Серия №3
byКомпания УЦСБ
 
ИБ Стратегия обороны. Серия №4 ч.2
byКомпания УЦСБ
 
Автоматизированное Управление Привилегированным Доступом: Эволюция Управления...
bySelectedPresentations
 
ИБ Стратегия обороны. Серия №4 ч.1
byКомпания УЦСБ
 
Требования в области информационной безопасности и соответствующие им решения...
byCisco Russia
 
Термины и определения в области защиты персональных данных
byПавел Семченко
 
Доклад на v воронежском форуме ver. 0.3
byjournalrubezh
 

More from Positive Hack Days

PPTX
Типовая сборка и деплой продуктов в Positive Technologies
byPositive Hack Days
 
PPTX
Методика определения неиспользуемых ресурсов виртуальных машин и автоматизаци...
byPositive Hack Days
 
PPTX
Развитие сообщества Open DevOps Community
byPositive Hack Days
 
PPTX
Инструмент ChangelogBuilder для автоматической подготовки Release Notes
byPositive Hack Days
 
PPTX
Использование анализатора кода SonarQube
byPositive Hack Days
 
PDF
Теоретические основы Application Security
byPositive Hack Days
 
PDF
Credential stuffing и брутфорс-атаки
byPositive Hack Days
 
PDF
SOC для КИИ: израильский опыт
byPositive Hack Days
 
PDF
Мастер-класс «Трущобы Application Security»
byPositive Hack Days
 
PPTX
Требования по безопасности в архитектуре ПО
byPositive Hack Days
 
PDF
Honeywell Industrial Cyber Security Lab & Services Center
byPositive Hack Days
 
PDF
Эвристические методы защиты приложений
byPositive Hack Days
 
PDF
Формальная верификация кода на языке Си
byPositive Hack Days
 
PPTX
Механизмы предотвращения атак в ASP.NET Core
byPositive Hack Days
 
PDF
Уязвимое Android-приложение: N проверенных способов наступить на грабли
byPositive Hack Days
 
PPTX
Автоматизация построения правил для Approof
byPositive Hack Days
 
PPTX
От экспериментального программирования к промышленному: путь длиной в 10 лет
byPositive Hack Days
 
PPTX
Аналитика в проектах: TFS + Qlik
byPositive Hack Days
 
PPTX
Как мы собираем проекты в выделенном окружении в Windows Docker
byPositive Hack Days
 
PDF
Формальные методы защиты приложений
byPositive Hack Days
 
Типовая сборка и деплой продуктов в Positive Technologies
byPositive Hack Days
 
Методика определения неиспользуемых ресурсов виртуальных машин и автоматизаци...
byPositive Hack Days
 
Развитие сообщества Open DevOps Community
byPositive Hack Days
 
Инструмент ChangelogBuilder для автоматической подготовки Release Notes
byPositive Hack Days
 
Использование анализатора кода SonarQube
byPositive Hack Days
 
Теоретические основы Application Security
byPositive Hack Days
 
Credential stuffing и брутфорс-атаки
byPositive Hack Days
 
SOC для КИИ: израильский опыт
byPositive Hack Days
 
Мастер-класс «Трущобы Application Security»
byPositive Hack Days
 
Требования по безопасности в архитектуре ПО
byPositive Hack Days
 
Honeywell Industrial Cyber Security Lab & Services Center
byPositive Hack Days
 
Эвристические методы защиты приложений
byPositive Hack Days
 
Формальная верификация кода на языке Си
byPositive Hack Days
 
Механизмы предотвращения атак в ASP.NET Core
byPositive Hack Days
 
Уязвимое Android-приложение: N проверенных способов наступить на грабли
byPositive Hack Days
 
Автоматизация построения правил для Approof
byPositive Hack Days
 
От экспериментального программирования к промышленному: путь длиной в 10 лет
byPositive Hack Days
 
Аналитика в проектах: TFS + Qlik
byPositive Hack Days
 
Как мы собираем проекты в выделенном окружении в Windows Docker
byPositive Hack Days
 
Формальные методы защиты приложений
byPositive Hack Days
 

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

  • 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.
  • 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.
  • 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.
    Пример политики «lowwater 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.
  • 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.
  • 40.
    Анализ основных моделей Свойствосистемы TG BLP СВС ИПС Различие в условиях реализации потоков по памяти и по времени ‒ ‒ ‒ ‒ Наличие иерархической структуры сущностей и возможность ее использования для реализации потоков по времени + ‒ + ‒ Возможность кооперации субъектов + ‒ ‒ ‒ Возможность реализации доверенных субъектов с различными условиями функционирования ‒ + ‒ + Возможность противодействия доверенными субъектами при передаче прав доступа или реализации запрещенных потоков недоверенными субъектами + ‒ ‒ ‒ Возможность изменения вида преобразования данных, реализуемого субъектом ‒ ‒ ‒ + Необходимость реализации различных правил управления доступом для распределенных компонент ‒ ‒ ‒ ‒ Возможность идентификации вида преобразования данных реализуемого субъектом ‒ ‒ ‒ ‒ 40
  • 41.
    Общие характеристики • ДП-модели– формальные модели безопасности управления доступом и информационными потоками • П.Н. Девянин «Анализ безопасности управления доступом и информационными потоками в компьютерных системах», 2006 г. • Основные использованные модели – Take-Grant – СВС – BLP и ее расширения – ИПС – RBAC 41
  • 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.
  • 49.
    Построение ДП-модели • Исходныеданные – Политики управления доступом и информационными потоками – Модель угроз – Свойства и особенности функционирования системы • Формулирование предположений модели на основе модели угроз и свойств системы • Описание элементов модели (сущности, субъекты, иерархия сущностей, права доступа, уровни безопасности, роли и т.д.) • Задание правил преобразований – Де-юре – формальная спецификация функций управления доступом в системе в соответствии с требованиями ПБ – Де-факто – теоретические исследования 49
  • 50.
    Построение ДП-модели • Формализацияпонятия безопасности системы в форме логических предикатов – can_share_own(x, y) – может ли субъект X получить право доступа владения к сущности Y? – can_write(x,y) – возможна ли реализация запрещенного потока по памяти от сущности X к сущности Y? • Доказательство безопасности системы в рамках построенной модели в форме теоремы • Разработка методов обеспечения безопасности системы в рамках модели 50
  • 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