Описание формальной модели децентрализованной системы разграничения доступа

Введение

В своей предыдущей работе под названием «Выработка требований к децентрализованной системе разграничения доступа» [1] я рассматривал системы разграничения доступа и новый подход к их разработке. Этот подход заключается в вынесении элемента, отвечающего за принятие решений о разрешении или запрете доступа субъектов к объектам, вовне рабочей станции, на которой производится разграничение доступа. Этот элемент располагается на другой рабочей станции, и может использоваться для разграничения доступа на нескольких машинах. Такой подход был назван «децентрализация системы разграничения доступа», т.к. система дробится на несколько (минимум 2) элемента, разнесенных по разным рабочим станциям.

Рабочая станция, на которой располагается элемент системы разграничения доступа, отвечающий за принятие решений, была названа «сервер принятия решений о доступе» или просто «сервер» (в контексте данной системы), а рабочие станции, на которых производится разграничение доступа, были названы «подконтрольные объекты», или сокращённо «ПКО».

В работе [1] рассматривались особенности проектирования системы разграничения доступа с использованием «децентрализованного» подхода. Анализировалось какие ещё могут быть элементы у такой системы, как они должны между собой взаимодействовать и за что отвечать. В результате работы были сформированы следующие требования к децентрализованной системе разграничения доступа:

1. Система должна состоять отдельных модулей, общающихся друг с другом через определённое API. Среди этих модулей обязательно должны быть модуль принятия решений о доступе, модуль хранения политик доступа, модуль-перехватчик запросов доступа субъектов к объектам, модуль управления политиками, модуль транспортной системы для передачи сообщений.
2. Решения о доступе субъектов к объектам принимает центральный модуль, политики также хранятся централизованно.
3. Задержка, вносимая работой системы не должна ощущаться пользователем: она должна быть того же порядка, что и время обращения к диску или меньше.
4. Модули должны уметь проводить взаимную аутентификацию.
5. Данные, передаваемые в запросах модулей друг к другу должны быть защищены.

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

Целью данной работы является создание модели децентрализованной системы разграничения доступа и исследование её на предмет выполнения выдвинутых требований.

Помимо списка критериев, в результате работы [1] был предложен пример того, как может выглядеть децентрализованная система разграничения доступа:

 

Рис. 1. Пример того, как может выглядеть новая система

В данном примере, все модули общаются друг с другом через менеджер сообщений. Работа строится следующим образом: сначала администратор через АРМ управления настраивает базу данных политик. Затем, в процессе работы, агенты, перехватывая события обращаются к серверу принятия решений. Он делает запрос в БД политик, и на основе полученных оттуда данных даёт агенту ответ.

Вербальная модель

Опишем вербальную модель децентрализованной системы разграничения доступа. Для этого возьмём за основу приведенный выше пример.

Выделим следующие элементы:

• Сервер принятия решений о доступе – компонент системы, отвечающий за принятие решения о доступе субъекта к объекту. При получении сервер обращается к базе данных политик и принимает решение о разрешении/запрете доступа
• Агент перехвата событий доступа на ПКО – элемент, располагающийся на рабочей станции, перехватывающий события доступа. При перехвате события агент отправляет запрос на сервер и по ответу сервера разрешает или запрещает доступ
• Менеджер сообщений – элемент, ответственный за обработку, хранение и передачу сообщений между элементами
• База данных политик – отдельный элемент, хранящий в себе политики доступа, на основе которых сервер принимает решения о доступе субъектов к объектам
• Элемент «АРМ управления политикам» будем называть «модуль управления политиками», для данной модели не требуется указывать конкретную реализацию данного элемента, будет это АРМ или ПО - не важно. Модуль управления политиками – это элемент, системы, используя который пользователь системы сможет настраивать политики. Доступ к базе данных должен быть разграничен и предоставляться только тем пользователям, у которых есть на это право. Логично будет возложить обязанность проверки доступа на сервер принятия решений о доступе. В таком случае запрос от модуля управления политиками нужно направить сначала на сервер, а сервер, проверив права пользователя, выполнит запрос к базе и вернет результат модулю управления.

Внесём ещё одно изменение – запросы от сервера в базу направим напрямую, а не через менеджер сообщений, так как СУБД сама сможет обработать все запросы, и, учитывая, что источник только один – сервер, это не вызовет сложностей, а мы таким образом уменьшим задержку отклика системы при приятии решений.

Поскольку подразумевается использование атрибутной политики, не будем выделять каких-то пользователей системы отдельно. Владельцы системы смогут настроить права пользователей как угодно гибко.

Все пользователи будут взаимодействовать с системой либо через модуль управления политиками, и при наличии соответствующих прав читать и/или изменять политики, либо косвенно через агенты на ПКО, получая разрешения или запреты от системы в соответствии с настройками политики в базе.

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

Формальная модель

Формально опишем список основных функций сервера и агента.

Основной задачей агента является перехват события доступа и его обработка:

bool HandleInterrupt(string userName, string processName, string objectName, string accessType);

– обработчик события доступа, выполняет предобработку, собирает необходимые дополнительные данные для запроса на сервер из системы и посылает запрос на сервер. В случае положительного ответа разрешает дальнейшее исполнение. Среди дополнительных данных – имя ПКО, текущее время и возможно ещё какие-то нужные для решения данные. Часть данных, такие как имя ПКО, считывается при старте агента и хранится в памяти в процессе работы, другая часть, такая как время – получается из системы в момент обработки.

AccessResult AskAccess(string userName, string pcName, string processName, string objectName, , string accessType, DateTime eventTime, Dictionary<string, string> params);

– запрос разрешения. Функция отправляет набор данных, необходимых для принятия решения, на сервер и возвращает полученный ответ. В AccessResult хранится сам факт разрешения или запрета и некая дополнительная информация при необходимости.

Основными задачами сервера являются ответ агентам на запрос доступа и взаимодействие с модулем управления политиками:

AccessResult HandleAccess(string userName, string pcName, string processName, string objectName , string accessType, DateTime eventTime, Dictionary<string, string> params);

– функция-обработчик запроса на доступ. Получает данные, пришедшие с агента, выполняет запрос в бд, выполняет при необходимости дополнительную пред- и постобработку, вызывает функцию принятия решения.

PolicyInfo GetPolicy(string userName, string pcName, string processName, string objectName , string accessType);

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

AccessResult AccessResolution(string userName, string pcName, string processName, string objectName, , string accessType, DateTime eventTime, Dictionary<string, string> params, PolicyInfo info);

– функция, принимающая по всем собранным данным решение о разрешении/запрете доступа.

List<PolicyInfo> HandleGetPolicy(AuthInfo authInfo);

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

List<PolicyInfo> GetPolicy();

– функция, возвращающая описание политик из базы, если у пользователя есть соответствующие права.

bool HandleSetPolicy(AuthInfo authInfo, PolicyInfo policyInfo);

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

bool SetPolicy(PolicyInfo);

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

У модуля управления политиками две основные задачи – это отображение пользователю списка политик и внесение изменений:

List<PolicyInfo> AskPolicyInfo(AuthInfo authInfo);

– отправка запроса на получение списка политик на сервер

bool AskChangePolicy(AuthInfo authInfo, PolicyInfo policyInfo);

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

 

Итак, процесс принятия решения о доступе на ПКО будет выглядеть следующим образом (с перечислением ключевых моментов передачи данных):

 

На ПКО:

1) вызов HandleInterrupt,

2) вызов AskAccess

3) отправка запроса размером порядка ~кб по сети

 

На сервере:

4) вызов AccessResult

5) вызов GetPolicy(string userName, string pcName, string processName, string objectName , string accessType,);

и обращение в БД и получение ~кб данных

6) вызов AccessResolution

7) отправка ответа размером порядка ~кб по сети

 

На ПКО:

8) завершение прерывания соответственно полученному ответу

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

В модуле управления:

1) вызов AskPolicyInfo

2) передача порядка ~кб данных по сети

 

На сервере:

3) вызов HandleGetPolicy

4) вызов GetPolicy(string userName, string pcName, string processName, string objectName , string accessType,); для проверки прав у запрашивающего и получение ~кб данных из БД

5) AccessResolution для проверки прав у запрашивающего

в зависимости от ответа AccessResolution, если прав недостаточно:

6) завершение HandleGetPolicy с результатом в виде пустого списка

7) отправка ответа размером порядка ~кб по сети

В модуле управления:

8) сообщение пользователю об отказе

в зависимости от ответа AccessResolution, если прав хватает:

6) вызов GetPolicy() и получение данных порядка ~10 мб из БД

7) завершение HandleGetPolicy с заполненным списком в качестве результата

8) отправка ответа размером порядка ~10 мб по сети

В модуле управления:

9) отображение данных пользователю

Процесс редактирования политик в модуле управления политиками выглядит аналогично процессу получения списка.

В результате на основе вербальной модели была сформирована формальная. Но у неё есть недостаток – она не описывает элементы и процессы, которые удовлетворяют критериям 4 и 5 и непонятно, выполняется ли пункт 3. Добиться соответствия критериям 4 и 5 можно дополнив модель описанием соответствующих процессов, а для оценки выполнимости критерия 3 нужно будет исследовать полученную модель.

Нужно защитить передаваемые данные от несанкционированного доступа, для этого можно использовать различные инструменты, но так или иначе, будь это защита канала или шифрование данных элементами системы при отправке, добавится задержка на шифрование данных при запросе и при возврате ответа.

Для выполнения критерия 5 необходимо аутентифицировать данные, приходящие от сервера. Для этого на его стороне данные нужно будет подписать. И таким образом на одной стороне добавится ещё задержка на выполнение подписи.

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

Теперь исследуем модель на выполнение пункта 3 требований к децентрализованной системе разграничения доступа.

Рассмотрим обращение пользователя к файлу размером 1 мб.

Задержка на чтение с SSD составит порядка 1 мс [2]

Обращение на чтение к оперативной памяти будет на несколько порядков меньше (микросекунды), оно пренебрежимо мало.

Шифрование данных – один из наиболее затратных процессов. Скорость шифрования сильно зависит от алгоритма и конкретной реализации, но существуют реализации, обеспечивающие шифрование со скоростью порядка скорости чтения с диска, что нас устраивает. К тому же следует учесть, что объём данных, которые нужно зашифровать, в среднем гораздо меньше данных, которые будут вычитаны с диска (в данном рассматриваем случае – на 3 порядка) что ещё уменьшит порядок задержки.

Передача данных порядка 1кб по сети 1gb – порядка 10мкс, что так же пренебрежимо мало.

Расшифрование данных того же порядка, что и шифрование.

Доступ к базе данных быстрее доступа к диску напрямую за счёт индексации и кэширования и им тоже можно пренебречь, т.к. в данном случае объём вычитываемых данных относительно мал.

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

В обратную сторону снова будет шифрование данных, а также подпись.

На стороне агента – расшифрование и проверка подписи.

Заключение

Итак, самыми длительными в процессе обработки запроса доступа являются криптографические операции, проводимые несколько раз. Но, поскольку объём данных, над которыми проводятся эти операции существенно меньше, можно сделать вывод, что при выборе верных реализаций криптографии требование к системам разграничения доступа под номером 3 будет выполнено.

Таким образом, мы получили модель системы, удовлетворяющую всем выдвинутым критериям.

В дальнейшем, создав прототип системы можно проверить гипотезу о том, что требование 3 будет успешно выполняться.  

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

Список литературы.

1. Чадов А. Ю. Выработка требований к децентрализованной системе разграничения доступа. Вопросы защиты информации, 2018. №3.С.13-16.
2. Latency Numbers Every Programmer Should Know [Электронный ресурс] URL: https://gist.github.com/jboner/2841832 (дата обращения: 14.09.20).

Автор: Чадов А. Ю.

Дата публикации: 13.11.2020

Библиографическая ссылка: Чадов А. Ю. Описание формальной модели децентрализованной системы разграничения доступа // Комплексная защита информации: материалы XXV научно-практической конференции, 15–17 сентября 2020 г., М.: Медиа Группа «Авангард», 2020. С. 115–121.

---