К построению и контролю соблюдения политик безопасности распределенных компьютерных систем на основе механизмов доверия А. А. Иткес В. Б. Савкин Институт проблем информационной безопасности МГУ

2 Постановка задачи Разработка методов объединения политик безопасности, основанных на отношениях доверия. Разработка дополнительного модуля ядра Linux, позволяющего задавать отношения доверия между узлами распределенной информационной системы без использования серверов аутентификации.

3 Определение отношения доверия Пусть A - информационная система. Обозначим S(A) - множество субъектов системы A. Отношением доверия между информационными системами A и B называется подмножество T A,B прямого произведения множеств S(A) и S(B). Если пара (a,b) принадлежит T A,B, то субъект a может получить доступ к объектам системы B посредством субъекта b.

4 Примеры отношений доверия WEB-клиент может получить доступ (на чтение) к файловой системе удаленного компьютера посредством WEB-сервера. Приложение может получить доступ на запись к файлам системных журналов посредством демона syslogd. Взаимодействие узлов в сети, основанной на Active Directory, также базируется на отношениях доверия.

5 Применение отношений доверия при объединении политик безопасности. Рассмотрены 3 вида политик: Ролевая модель разграничения доступа. Многоуровневая модель разграничения доступа. Модель разграничения доступа Type-Enforcement.

6 Применение отношений доверия при объединении политик безопасности Скажем, что информационная система C является корректным объединением систем A и B, если множество объектов системы C является объединением множеств объектов систем A и B и ограничение политики безопасности системы C на систему A или B совпадает соответственно с политикой безопасности системы A или B.

7 Ролевая модель разграничения доступа В системе зафиксированы следующие множества: P - множество привилегий. R - множество ролей, каждой роли соответствует некоторое подмножество множества P. U - множество пользователей. Каждому пользователю соответствует множество доступных ему ролей. E - множество сеансов. Каждому сеансу соответствует запустивший его пользователь и некоторое подмножество его ролей.

8 Ролевая модель разграничения доступа Так как отношения доверия определяются с использованием субъектов систем, необходимы вспомогательные построения: Каждый субъект s, не являющийся пользователем, соотнесен с некоторым сеансом e. При этом субъекту s приписывается подмножество ролей e.

9 Объединение ролевых моделей разграничения доступа Любое корректное объединение ролевых политик безопасности информационных систем A и B может быть выражено с помощью пары отношений доверия T A,B и T B,A.

10 Многоуровневая модель разграничения доступа На информационной системе A задана многоуровневая модель разграничения доступа, если существует решетка L и каждому объекту O системы A приписан элемент l O решетки L, называемый уровнем секретности O. Субъект S имеет доступ на запись к объекту O тогда и только тогда, когда уровень секретности O выше уровня секретности S. Субъект S имеет доступ на чтение к объекту O тогда и только тогда, когда уровень секретности O ниже уровня секретности S.

11 Объединение многоуровневых моделей разграничения доступа Система C может являться корректным объединением систем A и B только в том случае, если решетки ценностей систем A и B вложены в решетку ценностей системы С. Система C может являться корректным объединением систем A и B, построенным с помошью отношений доверия только в том случае, если решетки ценностей систем A и B изоморфны решетке ценностей системы C.

12 Модель разграничения доступа Type-Enforcement Каждому объекту системы приписаны две метки: тип и класс. Решение о предоставлении доступа субъекта к объекту принимается на основании типа субъекта, типа объекта, класса объекта и вида доступа.

13 Объединение моделей разграничения доступа Type- Enforcement Любое корректное объединение Type-Enforcement политик безопасности информационных систем A и B может быть выражено с помощью пары отношений доверия T A,B и T B,A.

14 Недостатки простых отношений доверия На практике, один субъект может доверять другому не полностью, совершая от его имени только некоторые операции. Простые отношения доверия позволяют объединять не все виды политик безопасности.

15 Ограниченные отношения доверия Пусть каждому субъекту b информационной системы B приписана решетка доверия L b. Ограниченным отношением доверия между системами A и B называется подмножество T A,B прямого произведения множеств S(A) и S(B), в котором каждому элементу (a,b) приписан элемент l(a,b) решетки доверия L b,, называемый уровнем доверия.

16 Ограниченные отношения доверия Каждой операции, которую может выполнять субъект S B, приписан минимальный уровень доверия. Запрос субъекта S A выполняется, если уровень доверия S B к S A выше минимального уровня доверия для указанного запроса.

17 Применение ограниченных отношений доверия для объединения многоуровневых политик безопасности Любое корректное объединение многоуровневых политик безопасности информационных систем A и B может быть выражено с помощью пары ограниченных отношений доверия между системами A и B.

18 Недостатки моделей, основанных на ограниченных отношениях доверия Решетки доверия на практике крайне велики и сложны. Уязвимости программного обеспечения позволяют злоумышленнику заставить субъект выполнять операции, не предусмотренные разработчиками приложения, вне зависимости от уровня доверия.

19 Разработка программных средств работы с отношениями доверия Контекстом безопасности субъекта называется метка, однозначно определяющая права доступа указанного субъекта ко всем объектам. Система должна допускать задание отношений доверия между контекстами безопасности компонент распределенной системы, которым соответствуют допустимые отношения доверия между субъектами.

20 Модуль безопасности SELinux Дополнительный модуль безопасности для ядра Linux 2.6. Система включена в текущую версию ядра Linux, то есть не требует дополнительной установки. Поддерживаются модели безопасности: ролевая, Type-Enforcement и многоуровневая. Контекстом безопасности является тройка (пользователь,роль,тип) при условии, что MLS модель не используется. Основным элементом, однако, является тип.

21 Основные технические решения Информация о метке безопасности субъекта может быть передана в области данных сообщения, либо в заголовке. Принято решение помещать информацию о метке безопасности в поле опций IP-сообщения. Передается не символьное имя типа, а целочисленный идентификатор.

22 Основные технические решения Возможно использование нескольких таблиц соответствия типов (то есть соответствия между символическими именами типов, используемыми в системе, и целочисленными идентификаторами, передаваемыми по сети). Выбор таблицы доверия типов и таблицы соответствия типов в зависимости от адреса удаленной системы и индекса используемого интерфейса.

23 Основные технические решения Для настройки таблиц соответствия типов и задания отношений доверия используется подсемейство протокола Netlink. В данный момент разработка системы не закончена.

24 Направления будущих исследований Объединение «смешанных» политик безопасности (например, SELinux с включенной поддержкой MLS). Разработка инструментальных средств задания политики безопасности для распределенных систем.