CC BY
6
УДК 681.3.068 ГРНТИ 50.41.21
DOI: 10.47501/ITNOU.2022.1.36-40
В. Л. Волушкова
Тверской государственный университет
САМООБУЧАЮЩАЯСЯ СИСТЕМА КОНТРОЛЯ ДОСТУПА К БД ORACLE
Часто возникают ситуации, когда назначение прав доступа клиентам стандартными средствами БД ORACLE, не удовлетворяют всем требованиям к системе. Поэтому возникает задача создать собственные средства назначения прав доступа. В данной работе представлена дополнительная система контроля доступа, основанная на самообучении.
Ключевые слова: клиентские права доступа к БД; Oracle Database; триггер; PL SQL.
SELF-LEARNING DATABASE ACCESS CONTROL SYSTEM ORACLE
Often there are situations when the assignment of access rights to clients by standard means of the ORACLE database does not satisfy all the requirements for the system. Therefore, the task arises to create our own means of assigning access rights. This paper presents an additional access control system based on self-learning. Keywords: DB user access rights, Oracle DB, tracing SQL statements.
Рассмотрим стандартные способы контроля доступа к БД ORACLE. Как только создается пользователь в БД, возникает проблема с его правами доступа к различным данным. Ограничить права доступа можно средствами контроля доступа к данным, а именно назначением прав и ролей базы данных [1][2]. После того, как администратор БД назначил права доступа к конкретным данным по своему усмотрению, остаются не решенными ряд задач.
Такие задачи возникают, например, когда необходимо реализовать защиту подключений к действующей БД, только что выпущенной в production. Количество вновь зарегистрированных пользователей достаточно большое. Трудно понять, какие данные необходимы конкретному пользователю, какие права он должен иметь для манипулирования с этими данными? Так же хотелось бы ограничить количество компьютеров (хостов), с которых данный пользователь может регистрироваться в БД.
Для решения всего вышеперечисленного был создан программный продукт Database firewall. В основе Database firewall лежит триггер, срабатывающий на коннект к БД. После включения Database firewall, система контроля доступа к БД ORACLE будет выглядеть следующим образом (рис.1).
V. L. Volushkova
Tver State University
Система контроля доступа
о
'access all 3wed
DB
DISCONNECT
access denied
Рисунок 1. Система контроля доступа
Триггер будет проверять соответствие подключения к БД прописанным в системе правилам. Правила включают в себя три метрики:
• основная - учетная запись в ОС, с которой идет соединение
• дополнительная - хост, с которого идет подключение
• схема (данные) к которой идет подключение.
Работу Database firewall можно изобразить в виде схемы, представленной на рис.2.
Рисунок 2. Схемаработы триггера по подключению пользователя
Проверка имени хоста введена для того, чтобы пользователи не подключались с нескольких рабочих станций.
Проверка схемы подключения введена для того, чтобы пользователи самостоятельно не разрешали доступ к своим данным другим клиентам БД. По правилам системы контроля доступа ORACLE, пользователь схемы может открывать доступ к своим данным другому пользователю без ведома администратора БД. Для исключения этого ввели схему проверки.
Имеется проблема с доступом к схемам. Нецелесообразно прописывать доступ пользователя к каждой схеме отдельно. Если в системе необходимо запретить доступ пользователя к нескольким схема, а к остальным, т.е. большинству, разрешить, то проще перечислить запрещенные схемы. Такому пользователю легче разрешить все схемы, и сделать список запрещенных схем. Тип доступа к схемам ALLOW. И наоборот, если все запрещено, а разрешено только несколько схем. Сначала запретить все, а по-
том создать список разрешенных схем. Тип доступа к схемам DENY. Тоже самое проделано с хостами.
Для системы созданы четыре таблицы: USERS, OBJECTS, RIGHTS, ACCESSLOG. Назначение таблиц понятно из их названий.
Таблица USERS хранит информацию о пользователях и содержит следующие
поля:
id, user_login - учетная запись пользователя операционной системы, username- ФИО пользователя ,
hostaccess - тип доступа с хостов, возможные значения ALLOW, DENY schema access - тип доступа к схемам, возможные значения ALLOW, DENY
В таблице OBJECTS хранится информация о хостах, схемах и группах. Надо отметить, что в DB ORACLE нет понятия USER. Есть понятие схема, которое включает в себя пользователя и объекты (таблицы, представления, сиквенсы и т.д). Поэтому появилась таблица OBJECTS. Группа - это особый объект, который в одних случаях имеет свойства пользователя, когда группе присваиваются права на хосты и схемы, в других случаях - выступает в роли объекта - когда пользователь включается в группу.
В таблице RIGHTS хранится информация о правах, предоставленных пользователю (или группе) в виде связки id пользователя (или группы) - id объекта (группа, хост или схема). У одного пользователя может быть несколько хостов, схем, групп, один хост (схема) может относиться к нескольким пользователям, т.е. реализована почти классическая связка многие-ко-многим. Связи таблиц показаны на рисунке 3.
Рисунок 3. Схема данных основных таблиц Так как физически информация о группах хранится в таблице OBJECTS (iobj_type=G), более корректно говорить, что на схеме данных под users подразумевается объединение таблицы пользователей USERS и таблицы OBJECTS с ohj type =G. При назначении группе хостов и схем в таблице RIGHTS: ugid - это id группы, objid - это id хоста или схемы. При добавлении пользователя в группу: ug id - это id пользователя, obj id - id группы. При непосредственном назначении пользователю хоста или схемы (не через принадлежность к группе) ug id - это id пользователя, obj id - id хоста или схемы.
В таблице ACCESS LOG сохраняется информация обо всех не успешных попытках доступа пользователей к БД, а также сохраняется информация об успешных попытках доступа, но только для тех пользователей, у которых включено логгирование. Данные в таблицу заносятся основным триггером Database firewall.
Теперь, зная о структуре таблиц системы, можно описать некоторые моменты работы с этими таблицами схемы, изображенной на рис.2. Под шагами будем понимать номер блока на рисунке, «выбор учетной записи» - 1 шаг, и т.д.
1. Выполняется проверка учетной записи - наличие записи в таблице USERS с user login = учетной записи пользователя в ОС.
2. Далее идет проверка с какого хоста идет подключение. Необходимо отметить, что у пользователя может быть два режима доступа с хостов, тип доступа определяется в поле hostaccess таблицы USERS. Если hostaccess = ALLOW, доступ разрешен только с хостов, которые определены для пользователя в таблице RIGHTS (непосредственно или через принадлежность к группам), с остальных хостов - доступ запрещен. Если host_access=DENY, доступ запрещен с хостов, которые определены для пользователя в таблице RIGHTS непосредственно или через принадлежность к группам, с остальных хостов - доступ разрешен. Кроме того, доступ с хоста может быть запрещен для всех пользователей (поле is_blocked таблицы OBJECTS = F)
Таким образом:
• Если хост заблокирован - триггер генерирует ошибку HOST BLOCKED и переходит к шагу 5.
• Если тип доступа ALLOW и хост не найден - триггер генерирует ошибку ALLOW HOST NOT FOUND и переходит к шагу 5.
• Если тип доступа DENY и хост найден - триггер генерирует ошибку DENY HOST FOUND ипереходит к шагу 5.
• Иначе - проверяем дальше.
3. Далее идет проверка схемы к которой идет подключение. Необходимо отметить, что у пользователя может быть два режима доступа к схемам, тип доступа определяется полем schemaaccess таблицы USERS. Если sche-ma_access=ALLOW, доступ разрешен только к схемам, которые определены для пользователя в таблице RIGHTS (как непосредственно, так и через принадлежность к группам), к остальным схемам - доступ запрещен. Если тип доступа DENY - доступ запрещен к схемам, которые определены для пользователя через таблицу RIGHTS (как непосредственно, так и через принадлежность к группам), к остальным схемам доступ разрешен. Кроме того, доступ к схеме может быть запрещен для всех пользователей (поле is_blocked таблицы OBJECTS = Y)
Таким образом:
• Если схема заблокирована - триггер генерирует ошибку SCHEMA BLOCKED и переходит к шагу 5
• Если тип доступа ALLOW и схема не найдена - триггер генерирует ошибку ALLOW SCHEMA NOTFOUND и переходит к шагу 5.
• Если тип доступа DENY и схема найдена - триггер генерирует ошибку DENY SCHEMA FOUND ипереходит кшагу 5.
• Иначе - все проверки завершены, идем дальше.
4. Если для пользователя задано логгирование (поле is logging = Y в таблице USERS), то триггер добавляет запись в таблицу ACCESS LOG с информацией
о разрешенном подключении (USERLOGIN, HOST NAME, SCHEMANAME) STATUS = SUCCESS и переходит к шагу 6, если логгирование для пользователя не включено - просто переходим к шагу 6.
5. Триггер добавляет соответствующую запись в ACCESS LOG {status = ABORT), выдает сообщение об ошибке, закрывает подключение и завершает свою работу.
6. Доступ разрешен. Триггер успешно завершает свою работу.
Теперь рассмотрим вопрос, как заполняются таблицы?
Их может заполнить вручную администратору БД. Администратор БД занесет в таблицу USERS пользователя, назначить ему в таблице OBJECTS хост, схему, тип доступа к схема ALLOW/DENY, и т.д.
Можно таблицы заполнить автоматически и таким образом осуществить самообучение. Режим заполнения пустых таблиц реализован в основном триггере системы под названием тестовый режим.
В тестовом режиме происходит следующее. На вход триггера поступает информация о пользователе. Если пользователь не найден в таблице USER , то он добавляется в таблицу с правами «все разрешено», если хоста нет в таблице OBJECTS, то он добавляется также с правами «все разрешено», если нет схемы, то добавляется запись в OBJECTS. Доступ к таким схемам разрешен всем.
По окончанию тестового режима мы получим множество зарегистрированных пользователей системы Database firewall. Теперь администратор БД может вручную скорректировать таблицы системы для правильной работы пользователей. Корректировать всегда легче, чем создавать. Не надо искать права доступа к схемам - как правило пользователи работают с нужными им данными. Не надо прописывать привязку пользователей к компьютерам - вряд ли пользователи меняли хаотично свои компьютеры во время тестового периода. Тестовый период можно включить только один раз и лучше всего сразу после установки БД как действующей.
Автор считает, что в данной работе новыми являются следующие положения и результаты:
1. Дополнительная защита данных от некорректных действий пользователя.
2. Обучение системы защиты, с дальнейшей корректировкой прав доступа.
3. Программный продукт, который позволяет оптимизировать доступ к данным и производить дополнительную защиту БД.
Литература
1. Кайт Томас, Кун Дарл. Oracle для профессионалов. - Диалектика / Вильяме, 2016г., 960с.
2. Управление доступом к базе данных Oracle - [Электронный ресурс] https://oracle-dba.ru/docs/architecture/schemas/user-permissions/
Сведения об авторах Information about authors
ВераЛьвовна Волушкова Vera Volushkova
к.т.н., доцент PhD
Тверской государственныйуниверситет, Tver State University
Тверь, Россия Tver, Russia
Эл. почта: ■w2lvera@gmail.com E-mail: ■w2lvera@gmail.com
