Международный секретариат G-Global г.Астана, ул.Темирказык, 65, офис 116 тел.: 7(7172) 278903

К.М. Сагиндыков1, А.Д. Ақанов2А. Б. Жамкеева3, Ж.А. Мужтабина4

Л.Н.Гумилев атындағы Еуразия ұлттық университеті, Астана, Қазақстан1

Қазақ инновациялық гуманитарлық-заң университеті, Семей, Қазақстан2

Л.Н.Гумилев атындағы Еуразия ұлттық университеті, Астана, Қазақстан3

 

МЕТОД ОБЕСПЕЧЕНИЯ ДОСТУПА К ДАННЫМ РЕЛЯЦИОННЫХ СИСТЕМ НА УРОВНЕ СТРОК ОТНОШЕНИЯ

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

Ключевые слова: безопасность, реляционная база данных, мандатный и дискреционный контроль доступа, триггер, представление данных

In the given article the author has shown the method of increasing safety of information systems realized in the active relational databases environments. The method is based on restriction of access to table records for selecting, updating and deleting operations.

Keywords: security, relation database, mandatory and discretionary access control, trigger, view

 

           ВВЕДЕНИЕ

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

Взаимодействие пользователей и приложений с БД осуществляется под контролем системы управления базами данных (СУБД), которая в первую очередь и определяет уровень безопасности информационной системы (ИС). Большинство известных корпоративных СУБД соответствуют классу безопасности C «Оранжевой книги» Министерства обороны США [1], который требует управления доступом именованных пользователей к именованным объектам. Это требование частично обеспечивает стандарт SQL, который эти СУБД поддерживают. Язык SQL включает средства управления доступом к данным, но, к сожалению, в рамках этого стандарта, разграничение доступа к поименованным информационным объектам БД (таблицам, представлениям, процедурам и т. п.) ограничивается полным набором данных, предоставляемым тем или иным объектом, тогда как существуют задачи, требующие более детального управления доступом.

Эту проблему решают недавно появившиеся на рынке СУБД, которые предлагают безопасность уровнем выше, основанную на мандатном доступе к данным или, иначе, на механизме меток безопасности. Данный подход основан на рекомендациях «Оранжевой книги». Примером этого подхода может служить СУБД INGRES/Enhanced Security (INGRES с повышенной безопасностью), имеющая класс безопасности В1.

Одним из вариантов повышения безопасности функционирующих ИС является переход на другую СУБД с вышеупомянутыми специализированными возможностями. Такой переход обычно связан с многочисленными трудностями и не всегда целесообразен.

Рассмотри методику повышения безопасности БД с помощью детализированного доступа к данным. Методика применима к любой активной реляционной СУБД. Объектом защиты данной методики являются данные, а именно данные строки первичного источника данных — таблицы. В работе используются следующие основные понятия: метка безопасности (LabelSecurity) — признак строки, определяющий уровень доступа к ней; пользователь — действующее лицо БД, относительно которого организуется защита строки. В зависимости от конкретного пользователя, значения метки, правил доступа и типа запрашиваемой операции разрешается или запрещается доступ к строке.

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

Рисунок 1. Концептуальная схема доступа

           В настоящее время получили распространение следующие 2 подхода в управлении доступом к данным:

Дискреционная защита обеспечивает доступ к данным вплоть до столбца таблицы, а мандатная — до строки (в частных случаях — до ячейки таблицы) (рисунок 2). Между столбцом и строкой, помимо прочих, существует одно важное отличие: столбец — это часть структуры таблицы, по своей природе статичной, а строка — это часть данных, по своей природе динамичных. Таким образом, в первом случае защита происходит относительно структуры, а во втором — относительно семантики данных.

Как было упомянуто выше, стандартные реляционные системы предлагают только дискреционный контроль доступа. Но свойство «активности» современных СУБД позволяет реализовать и более детализированный контроль доступа. То есть предлагается с помощью средств активной БД выполнить надстройку БД, включающую политику безопасности, правила доступа и выполняющую контроль за доступом к данным (рисунок 1), причем относительно самих данных.

Политика безопасности может быть любой и зависеть от правил, принятых в той или иной корпорации. Правила могут требовать классической мандатной безопасности, модели Bell- LaPadule или любой другой модели, специфичной для конкретной корпорации и основанной на сложных взаимосвязях между объектами системы. Для того, чтобы организовать развитую систему безопасности нужно заранее учесть, что политика безопасности может быть очень многогранной и опираться на различные факторы, например, на иерархию пользователей, географические факторы и т.п.

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

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

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

 

Рисунок 2. Представление иерархии пользователей в виде таблицы

На основе политики безопасности и иерархии пользователей строятся правила доступа. Несмотря на то, что правила доступа напрямую зависят от политики безопасности и иерархии пользователей, их все же целесообразнее хранить в специальной таблице правил, а не вычислять в процессе работы. Это оправдывается следующими обстоятельствами: во-первых, реляционными операторами сложно реализовать рекурсивное вычисление множества, а во- вторых, в случае предварительного вычисления необходимый доступ будет предоставляться быстрее. Кроме того, что немаловажно, в случае необходимости можно создавать правила доступа, не соответствующие политике доступа. Таблица правил доступа Access_Rules представлена на рисунке 3.

 

Рисунок 3. Таблица правил доступа

Таблица содержит правила доступа пользователей по отношению ко всем возможным операциям и меткам строки . Если для пользователя в таблице правил доступа не существует правила с данной меткой для заданной операции, то требуемый доступ запрещается. Трактовать запись в таблице правил можно следующим образом: пользователь User_ID имеет доступ на операцию Action ко всем строкам, помеченными меткой User_Label.

Формирование правил доступа происходит на основе политики доступа. При создании и исполнении иерархии пользователей множество правил Rrules для нового пользователя можно представить в математическом виде:

где Rown — правила доступа к «собственным» данным, определяемые по формуле

;

Rother  – правила доступа к данным других собственников, определяемые как

Ru – идентификатор нового пользователя User_ID;

Rp – идентификатор родительского пользователя Parent_User_ID;

Добавление множества правил Rrules в таблицу Access_Rules реализовано с помощью следующего триггера, который срабатывает каждый раз при пополнении иерархии пользователей. Текст триггера представлен ниже:

CREATE TRIGGER TI_CREATE_AccRules

AFTER INSERT ON Users

REFERENCING NEW AS n FOR EACH ROW MODE DB2SQL

BEGIN ATOMIC

INSERT INTO Access_Rules (User_Label, User_ID, Action, Level)

SELECT n.User_ID, n.User_ID, Action, 0

FROM Politics

WHERE LevelQty IS NULL OR LevelQty >=0;

INSERT INTO Access_Rules (User_Label, User_ID, Action, Level)

SELECT n.User_Label, a.User_ID, p.Action, a.Level+1

FROM Politics p, Access_Rules a

WHERE a.User_Label=n. User_ID AND  p.Action=a.Action

AND (p.LevelQty>=a.Level+1 OR p.LevelQty IS NULL) AND a.User_Label<>n.User_Label;

END;

В процессе функционирования системы возможно изменение иерархии пользователей. В этом случае система должна автоматически перенастраивать правила доступа. В случае изменения положения пользователя в иерархии нужно написать дополнительную процедуру. При удалении пользователя перенастройку правил можно легко реализовать через каскадное удаление по ссылке между таблицами Users и Access_Rules .

Принцип управления доступом пользователя к строке математически можно сформулировать следующим образом: пользователь имеет право на действие со строкой, если метка строки (User_Label) находится в соответствующем действию и зависящем от конкретного пользователя множестве S Action :

где Action — запрашиваемое действие (операция Update, Delete или Select);

SAction — множество меток, с которыми пользователь может совершить действие Action. Вычисление SAction выполняется по формулам:

где USER — переменная специального регистра СУБД, содержащая имя пользователя и инициируемая на время соединения пользователя с СУБД; ActionName — название операции из списка {Update, Delete, Select}.

Защищаемая таблица Stuff представлена на рисунке 4. В таблице меткой является поле User_Label, содержащее идентификатор пользователя и обозначающее собственника записи.

 

Рисунок 4. Структура и данные «защищаемой» таблицы

Чтение записей можно ограничить с помощью механизма представлений, создавая на каждую защищаемую таблицу по представлению. Предполагается, что все остальные действия (изменение, добавление, удаление) будут производится через эти представления, так как на исходные таблицы доступ запрещен для всех пользователей.

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

 

CREATE VIEW My_Stuff AS

SELECT * FROM Stuff

WHERE User_Label IN (SELECT User_Label FROM Access_Rules

WHERE Action='Select'

AND User_ID IN (SELECT User_ID

FROM Users

WHERE User_Name=USER));

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

DBSYSADM (User_ID=1) — 15 строк (полный набор данных);

DEM (User_ID=2)

— 6

строк;

KLASIFIK (User_ID=4)

— 3

строки;

PETER (User_ID=6)

— 3 строки.

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

CREATE TRIGGER TU_SAVE_STUFF

NO CASCADE BEFORE UPDATE on Stuff

REFERENCING OLD AS o NEW AS n FOR EACH ROW MODE DB2SQL WHEN (o.User_Label NOT IN (

SELECT User_Label FROM Access_Rules

WHERE Action='Update' AND User_ID IN (

SELECT User_ID FROM Users WHERE User_Name=USER)))

SIGNAL SQLSTATE '111' ('You can''t change this record');

Триггер, предупреждающий несанкционированное удаление строк, имеет вид:

CREATE TRIGGER TD_SAVE_STUFF

NO CASCADE BEFORE DELETE on Stuff

REFERENCING OLD AS o            FOR EACH ROW MODE DB2SQL

WHEN (o.User_Label NOT IN (

SELECT User_Label FROM Access_Rules

WHERE Action='Delete' AND User_ID IN (

SELECT User_ID FROM Users WHERE User_Name=USER) ) )

SIGNAL SQLSTATE '110' ('You can''t delete this record');

Рассмотренная выше защита на чтение, изменение и удаление таблицы Stuff может быть применена для других таблиц БД, если они отвечают той же политике доступа и иерархии пользователей. Использование специальных таблиц Users, Access_Rules и Politics будет в таком случае многократным. Как видно из рассмотренного примера, для этого достаточно для каждой таблицы создать по одному представлению и по два триггера. Представления и триггеры являются настолько универсальными, что их можно использовать как шаблоны для распространения контроля доступа на другие таблицы. Если при изменении политики доступа меняется принцип доступа, то с помощью шаблонов его довольно несложно распространить на все таблицы.

ЗАКЛЮЧЕНИЕ

В реляционных СУБД возможно реализовать детализированный доступ к данным. Совместное использование детализированного и дискреционного доступа обеспечивает гибкость управления безопасностью в БД. Политика доступа может быть построена согласно любым правилам корпорации и учитывать сложные взаимосвязи между объектами и субъектами системы. Управлять правилами доступа могут не только администраторы безопасности, а также и другие пользователи в пределах своей компетенции, согласно правилам корпорации. Предлагаемый подход реализуется стандартными средствами: триггерами и представлениями. Математический аппарат системы — реляционная алгебра. Данный подход не слишком сильно усложняет структуру БД и не требует дорогостоящей поддержки.

ЛИТЕРАТУРА

  • Потапов А.Е., Манухина Д.В., Соломатина А.С., Бадмаев А.И., Яковлев А.В., Нилова А.С. Безопасность локальных баз данных на примере SQL Server Compact // Вестн. Тамбов. ун-та. Серия: Естественные и технические науки. 2014. № 3. С. 915–917.
  • Бортовчук Ю.В., Крылова К.А., Ермолаева Л.В. Информационная безопасность в современных системах управления базами данных // Современные проблемы экономического и социального развития. 2010. № 6. С. 224–225.
  • Горбачевская Е.Н., Катьянов А.Ю., Краснов С.С. Информационная безопасность средствами СУБД Oracle // Вестн. ВУиТ. 2015. № 2 (24). С. 72–85.
  • Кузнецов С.Д. Базы данных: учебник для студ. М.: Ака-демия, 2012. 496 с.
  • Ткаченко Н.О. Реализация монитора безопасности СУБД MySQL в dbf/dam системах // ПДМ. Приложение. 2014. № 7. С. 99–101.
  • Полтавцева М.А. Задача хранения прав доступа к данным в РСУБД на примере Microsoft SQL Server // Актуальные направления фундаментальных и прикладных исследований: матер. V Междунар. науч.-практич. конф. 2015. С. 118–120.
  • Баранчиков А.И., Баранчиков П.А., Пылькин А.Н. Алгоритмы и модели доступа к записям БД. М.: Горячая линия–Телеком, 2011. 182 с.
  • Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита. М.: ДМК Пресс, 2014. 336 с.
  • Смирнов С.Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с.
  • Зегжда П.Д. Обеспечение безопасности информации в условиях создания единого информационного пространства // Защита информации. Инсайд. 2007. № 4 (16). С. 28–33.
  • Зегжда Д.П., Калинин М.О. Обеспечение доверенности информационной среды на основе расширения понятия «целостность» и управления безопасностью // Проблемы информ. безопасности. Компьютерные системы. 2009. № 4. С. 7–16.
  • Полтавцева М.А., Зегжда Д.П., Супрун А.Ф. Безопасность баз данных: учеб. пособие. СПб: Изд-во СПбПУ, 2015. 125 re.

Партнеры G Global

  • 001.jpg
  • 002.png
  • 003.png
  • 004.jpg
  • 005.jpg
  • 006.jpg
  • 007.jpg
  • 009.png
  • 651995c4b029cb9668e2ac4e379463ba.jpg
  • id1353.jpg
  • IOFS_logo.png
  • kaznu.png
  • logo-gglobal.png
  • the-brettonwoods-committee.png
  • Без названия.jpg