Контроль доступа к системному каталогу в СУБД «Ред база даных » Текст научной статьи по специальности «Компьютерные и информационные науки»

Контроль доступа к системному каталогу в субд «ред база данных»

© СИМАКОВ Роман Александрович

кандидат технических наук, директор по производству ООО «Ред Софт Муром»

Ш +7(920)900-65-02, И roman.simakov@red-soft.biz

© СМИРНОЕ Артем Вячеславович

студент Муромского института Владимирского государственного университета

@ +7(905) 141-46-42, ИЗ artyom.smimov(@,red-soft.biz

В статье рассматривается устройство механизма защиты метаданных в СУБД «Ред База Данных». Приводятся примеры его использования в виде написания условий фильтрации, а также рассматривается пример использования фильтрации строк таблиц для реализации мандатного доступа пользователей к данным.

Ключевые слова: база данных, защита метаданных, мандатный доступ

Вс

н

► современных условиях любая деятельность сопряжена с оперированием большими объемами информации, которое производится широким кругом лиц. Защита данных от несанкционированного доступа является одной из приоритетных задач при проектировании любой информационной системы. Следствием возросшего в последнее время значения информации стали высокие требования к конфиденциальности данных. Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом в этой области. Обеспечение информационной безопасности СУБД приобретает решающее значение при выборе конкретного средства обеспечения необходимого уровня безопасности организации в целом. Но защита данных - это не единственная проблема, решаемая в СУБД, полезно, а иногда и необходимо, сокрытие структуры базы данных, исходных кодов хранимых

процедур, триггеров, отображений - то есть важна защита и метаданных [1, 2].

Различные СУБД имеют свои подходы к решению данной задачи. Например, в SQL Server 2005 системные объекты находятся в скрытой базе mssqlsystemresource, при этом пользователям доступны представления Catalog Views для обращения к системным таблицам. Данные из этих представлений фильтруются в зависимости от того, кто делает запрос. Имеется и специальное разрешение VIEW DEFINITION, позволяющее обойти сокрытие метаданных всей БД, схемы или конкретного объекта.

Системный каталог в СУБД «Firebird» представляет собой набор таблиц с префиксом RDB$. Доступ к ним осуществляется точно так же, как и к пользовательским таблицам, соответственно, не имеется никаких ограничений на чтение по строкам: любой пользователь может получить полную информацию об объектах.

В рамках развития проекта СУБД «Ред База Данных», исходный код которой основан на ядре Firebird, был реализован механизм фильтрации системного каталога на уровне ядра.

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

CREATE TRIGGER name FOR {table | view}

[ACTIVE | INACTIVE]

{BEFORE | AFTER} <action_

list>

[POSITION number]

AS

<trigger body>

<action list> ::= <action> [OR <action> [OR <action>]]

<action> ::= INSERT | UPDATE

| DELETE | SELECT

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

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

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

Создание/изменение фильтра по строкам: ALTER TABLE table SET RECFILTER (<condition>);

где table - имя таблицы, для которой создается фильтр; <condition> - условие фильтрации строки таблицы.

Удаление фильтра по строкам:

ALTER TABLE table DROP RECFILTER;

где table - имя таблицы, для которой создается фильтр;

Создание/изменение фильтра по столбцам:

ALTER TABLE table SET COLFILTER <col name> (<condition>) [POSITION number];

где table - имя таблицы, для которой создается фильтр; <col_name> - имя столбца; <condition> - условие фильтрации этого столбца, number - позиция триггера на выборку (порядок фильтрации).

Удаление фильтра по столбцам:

ALTER TABLE table DROP COLFILTER <col name>;

где table — имя таблицы, из которой удаляется фильтр; <col_name> - имя столбца.

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

CREATE TABLE table [EXTERNAL [FILE] «<filespec>»]

( < co l _de f> [ , < co l _de f> |

<tconstraint> ...], [COLFILTER <col_ name> (<condition>), ...]) [, RECFILTER

(<condition>)];

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

ALTER TABLE test_table SET RECFILTER (new.some field > 10);

создаст системный триггер на выборку для таблицы test_table. Тело триггера заполняется специальным BLR-кодом, недоступным из DDL, который исполняется при невыполнении условия new.some_field > 10, позволяя пропустить строку таблицы и не допуская ее попадения в результирующий набор данных.

ALTER TABLE test_table SET TOLFILTER another field (new.some field < 10);

создаст системный триггер на выборку из таблицы test_table, при этом тело триггера заполняется кодом, обнуляющим поле another_ field во время выборки, если не исполняется заданное условие.

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

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

6з

лучения этой информации были реализованы специальные системные функции:

Системная функция проверки DML прав на объекты возвращает ИСТИНА, если пользователь имеет какие-либо DML-права на объект (чтение, запись, выполнение и т. д.).

CHECK_DML_RIGHTS(<right_type> ON <object type> <object name> [, field name>]), где:

<right_type> - ANY, INSERT, SELECT, UPDATE, DELETE, GRANT, REFERENCES, EXECUTE

<object_type> TABLE, PROCEDURE, GENERATOR ,VIEW

<object name> - имя объекта <field_name> - имя поля для типа объекта TABLE, VIEW.

Системная функция проверки DDL- прав на объекты возвращает ИСТИНА, если пользователь с именем <owner_name> имеет какие-либо DDL-права на объекты типа <object_type> (в эти права не входит право CREATE, рассматриваются права только на существующие объекты).

CHECK_DDL_RIGHTS(<right_type> ON

<object type> WITH OWNER <owner name>),

где:

<right_type> - ANY, ALTER, DROP <object type> - TABLE, VIEW, PROCEDURE, FUNCTION, GENERATOR, EXCEPTION, SEQUENCE, DOMAIN, EXCEPTION, ROLE, SHADOW

С помощью данных функций можно легко определить, имеет ли текущий пользователь права на тот или иной объект базы данных.

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

Некоторые примеры фильтров системного каталога:

Фильтрация строк таблицы RDB$RELATIONS:

ALTER TABLE rdb$relations SET RECFILTER(

CHECK_DML_RIGHTS(ANY ON TABLE new.rdb$relation name) = 1

OR CHECK_DDL_RIGHTS(ALTER ON TABLE WITH OWNER new.rdb$owner name) = 1 );

Здесь проверяются два вида прав на каждую таблицу: DDL и DML, и при наличии любого DML-права или DDL-права на модификацию таблицы пользователь начинает видеть эту таблицу в системном каталоге.

Ф и л ь т р а ц и я с т р о к та б л и ц ы RDB$TRIGGERS, основанная на работе предыдущего фильтра:

ALTER TABLE rdb$triggers SET RECFILTER(

(SELECT count(rdb$relation name) FROM rdb$relations

WHERE rdb$relation_name = new.rdb$relation name ) > 0 );_

Этот фильтр использует работу предыдущего фильтра (на фильтрацию RDB$RELATIONS): если связанная с триггером таблица видна пользователю в системном каталоге, то виден и триггер.

Фильтрация столбца RDB$TRIGGER_ SOURCE таблицы RDB$TRIGGERS:

ALTER TABLE rdb$triggers

SET COLFILTER rdb$trigger_ source (

CHECK_DDL_RIGHTS(ALTER ON TABLE WITH OWNER

(SELECT FIRST 1 rdb$owner_name FROM rdb$triggers as tr

JOIN rdb$relations as rl ON rl.rdb$relation name = tr.rdb$relation name

WHERE tr.rdb$relation name = new.rdb$relation name)

) = 1

);

Фильтрация столбца RDB$TRIGGER_BLR таблицы RDB$TRIGGERS:

ALTER TABLE rdb$triggers

SET COLFILTER rdb$trigger_blr

(

CHECK_DDL_RIGHTS(ALTER ON TABLE WITH OWNER

(SELECT FIRST 1 rdb$owner_name FROM rdb$triggers as tr

JOIN rdb$relations as rl ON rl.rdb$relation name = tr.rdb$relation name

WHERE tr.rdb$relation name = new.rdb$relation name)

) = 1

);

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

Разработанные фильтры на строки и столбцы могут использоваться не только для системных таблиц. Одним из альтернативных применений фильтрации может быть разграни-

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

Представим, что все данные в БД имеют четыре уровня секретности:

- не секретно;

- для служебного пользования;

- секретно;

- совершенно секретно.

Соответственно, каждый пользователь

имеет четыре аналогичных уровня допуска к данным, причем пользователь с более низким уровнем допуска не может получить данные более высокого уровня [3, 4].

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

CREATE TABLE user info(user name VARCHAR(32), privacy_level INT);

Данная таблица доступна только администратору БД. Первое поле в ней содержит имя пользователя, совпадающее с системным именем пользователя, второе — уровень допуска.

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

CREATE PROCEDURE user_can_ access(privacy level INT)

RETURNS(result INT)

AS

DECLARE VARIABLE tmp INT = 0;

BEGIN

SELECT privacy level FROM user

info

WHERE user name = USER

INTO :tmp;

result =

CASE

WHEN (tmp >= :privacy level)

THEN 1

ELSE 0 END;

SUSPEND;

END!!

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

CREATE TABLE data(some data VARCHAR(50), privacy level INT)

RECFILTER((SELECT * FROM user_ can access(new.privacy level)) = 1);

Первый столбец содержит некоторые данные, а второй — уровень их секретности. Фильтр на строки содержит проверку, имеет ли текущий пользователь доступ к данным определенной секретности. Уровень секретности данных берется из строки таблицы, а уровень допуска автоматически выбирается для текущего пользователя из таблицы user_info.

Для проверки работы механизма остается лишь наполнить таблицы данными и дать пользователям права на их чтение и модификацию.

Предположим, у нас уже заведены пользователи USER1 и USER2, назначим им уровни допуска 0 и 3 соответственно.

INSERT INTO user info

VALUES('USER1', 0);

INSERT INTO user info

VALUES('USER2', 3);

А также добавим несколько строк в таблицу data с различными уровнями секретности.

INSERT INTO data VALUES ( ' Non secret', 0);

INSERT INTO data

VALUES('Confidential', 1);

INSERT INTO data VALUES('Secret',

2);

INSERT INTO data VALUES('Secret too', 2);

INSERT INTO data VALUES ( 'Top secret', 3);

Ml ШЛА

£■* gca ї+w tftwy floa

e ± Ї ♦ L-- □ □ / U И г

I SELECT *

2FJWH PATA

*

1

ІЯІН1 "Л

VOM IIAIA PHMWCY HUM

1 Шп Ы<!+1 Q

1''1ли:Э;п ліжЛгі

Рис. 1. Работа фильтра для пользователя USER1

Теперь посмотрим, как работа фильтра отражается на выборке данных.

Для первого пользователя, имеющего самый низкий уровень доступа, из таблицы data была выбрана только одна строка, с несекретными данными (рис. 1). Для второго же

- с наивысшим уровнем доступа, были выбраны все данные (рис. 2). Работа фильтра действует не только на выборку - отфильтрованные строки

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

и! НІЛ

£Ф1 и** ЦШ№| Йг*я

Уі Ї ♦ 1-і ЇЗ В

\ SELECT *

2FHGH DAT ft

і

SHL-ІПЕЇ Jj\j '

ЧОМГ ПАТА. PfiMACV Е ГУЛ

1 МйПИС4И а

jr С n nflcf я гтйл 1 1

І-ЙКІЛ 2

4 S-tc itf 3

5. T:p кі-'іді 1

uSrt«,2(3Lai:jlhD»?^:n4f3f1»flTi4wrt:M‘K«^'a ї іа« C*lch*d 2: IQ Тгзлязсіна iWaJ

Рис. 2. Работа фильтра для пользователя ТОЕЯ2

Таким образом, СУБД получила достаточно гибкий, основанный на простых условиях, механизм контроля доступа к системному каталогу. Администратор БД может использовать как

заготовленные, поставляемые с СУБД, условия фильтрации, так и свои. Также отмечено, что фильтрация по столбцам и строкам может использоваться не только на системных данных, на основе нее возможно создание системы разделения доступа к записям пользовательских таблиц.

Библиографический список

1. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации [Сайт]. URL: http://www.fstec.ru/_d0cs/d0c_3_3_001. htm (дата обращения: 20.02.2009).

2. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации [Сайт]. URL: http://www.fstec. ru/ docs/doc 3 3 003.htm (дата обращения: 20.02.2009).

3. гост р 50739-95. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования. Госстандарт России. - М.: Издательство стандартов, 1995.

4. Руководство по разработке профилей защиты и заданий по безопасности [Сайт]. URL: http:// www.fstec.ru/_spravs/_spc/d0c_3_3_019.htm (дата обращения: 20.02.2009).

1

1 подписной индекс

I по каталогу агентства I

1 «роспечать» \

| 36829 |

Ч

ъттту/тттттттттттттятттттттттттттяттттттш'