Lightweight implementation of abac mechanism on database firewall.pdf В настоящее время политики безопасности для приложений являются, как правило, ролевыми (RBAC), атрибутными (ABAC) или гибридными, сочетающими в себе как ролевое, так и атрибутное управление доступом. Для каждого управления доступом в отдельности имеются или создаются детально проработанные стандарты [1, 2], но они ориентированы на реализацию в конечных системах, а не в защитных экранах приложений, а потому не могут быть использованы без существенной адаптации как к условиям функционирования защитных экранов в режиме прокси-сервера, так и к самим защищаемым системам управления базами данных (СУБД). Задача ставится следующим образом. Имеется СУБД и заданная политика безопасности, которая не может быть реализована встроенными механизмами управления доступом этой СУБД. Необходимо реализовать эту политику безопасности без изменения конфигурации, исходного кода и данных на СУБД. Такая реализация называется неинвазивной и была предложена авторами в работах [3, 4]. Для решения поставленной задачи строится легковесный механизм атрибутно-ролевого управления доступом - ABAC-hte. Реализуемый механизм состоит из следующих структурных элементов в терминологии NIST ABAC [1]. Policy Enforcement Point (PEP) отвечает за получение и пар-синг SQL-запросов от клиента к серверу СУБД и формирование запросов средствами протокола HTTP к PDP. Policy Decision Point (PDP) вычисляет решение о возможности получения доступа субъекта к сущности. Policy Information Point (PIP) реализует получение всех атрибутов субъектов и сущностей для принятия решения PDP. Policy Administration Point (PAP) отвечает за администрирование, представлления и хранения политики безопасности. В рамках реализации получены и используются следующие новые результаты. Для связи атрибутного и ролевого управления доступом впервые используется механизм проекций. Пусть е1,...,ем - сущности, г1,...,г^ - права доступа, ro/e1,..., ro/eK - роли, где ro/ek = {(e^, rj)} для некоторых i е {1,..., M}, j е {1,..., N}, k е {1,...,K}. Проекцией ролей на сущность e^ будем называть набор вида pr(ej) = {(ro/ek, rj) : (ei,rj-) е ro/ek}. Данный механизм позволяет более легко реализовать гибридное атрибутное и ролевое управление доступом. Политика безопасности представляет собой набор правил, составленных на специальном языке AF Rules, ориентированном на применение в графических пользовательских интерфейсах и представленном в нотации JSON. Правило состоит из условия и решения, которое применяется при выполненном условии. Правила проверяются в порядке их записи в политике. Условие правила может содержать атрибуты объектов Сессии (session), Пользователя (user), Ресурса (resource) и Окружения (env), логи-чесие операторы, операторы сравнения. Возможны два вида решения: разрешить или запретить. Последнее правило является правилом по умолчанию, условие данного правила всегда выполняется. Существует также возможность сконфигурировать способ выбора решения в политике [5]: 1) firstApplicable - будет выбрано первое решение из правила, условия которого выполнены; 2) permitOverrides - будет выбрано первое «разрешающее» правило. В отсутствие «разрешающих» правил или в случае невыполнения их условий возвращается решение по умолчанию; 3) denyOverrides - будет выбрано первое «запрещающее» правило. В отсутствие «запрещающих» правил или в случае невыполнения их условий возвращается решение по умолчанию. В примере, приведённом ниже, проверяется наличие группы у пользователя, и если такая задана, то группа пользователя сравнивается с группой ресурса. При этом сравнение предполагает использование иерархии групп, которая описывается отдельно в виде дерева. Если группы не сравнимы с точки зрения заданной иерархии, то условие не выполняется. Если группа пользователя ниже по иерархии группы ресурса, то условие не выполняется. В остальных случаях последняя часть условия будет выполнена. В правиле может быть описан способ сравнения уровней, что позволяет реализовать управление доступом на основе меток. Группы - иерархическая структура, которая позволяет отразить внутреннюю структуру организации. Тэги позволяют определить принадлежность субъекта к какому-либо отделу внутри организации. С точки зрения ролевого механизма наиболее интересен способ задания ролей. Для создания и назначения роли необходимо конфигурируемой сущности присвоить имя роли и привилегии. Пример конфигурации для таблицы test из базы данных test_db приведён ниже; здесь роль с именем gen_dir разрешает доступы типа select,insert,delete и update к сущности test_dbtest. 1 { 2 "id " : { 3 " database":"test_db " , 4 "table " :"test" 5 }, 6 "level": 3, 7 "tags": ["accounting"], 8 "privileges":[ 9 { 10 "name":"gen_dir " , 11 "rights":["select","insert", "delete", "update"] 12 } 13 ] 14 } Для использования политики PAP в механизме управления доступом правила транслируются из формата JSON в код на языке Python с помощью разработанного транслятора. Сгенерированный модуль содержит функцию checkAccess, которая применяет все проверки, описанные в правилах политики, и в случае выполнения условий возвращает решение о предоставлении доступа. Таким образом, в работе представлены результаты очередного этапа разработки легковесной системы ролевого и атрибутного управления доступом, ориентированной на применение в защитных экранах приложений. В системе разработаны новые механизмы: 1) проекции ролей, 2) проверки доступа по иерархии разрешающих и запрещающих ролей генерации, 3) генерации кода на основе политики безопасности.

Скачать электронную версию публикации