ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ В СОВРЕМЕННЫХ СУБД

 

Жарова Б., студентка 3 курса специальности «Информационные системы»

КГУ им. А. Байтурсынова

Бевз И.А., ст.преподаватель кафедры ИС КГУ им. А. Байтурсынова

 

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

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

Дискреционное управление доступам (discretionary access control) — разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.

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

CREATE USER IDENTIFIED пользователь BY пароль

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

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

Предложения управления привилегиями:

- назначение привилегии:

GRANT привилегия [ON объект] TO субъект [WITH GRANT OPTION]

- отмена привилегии:

REVOKE привилегия [ON объект] FROM субъект

Если субъект=пользователь, то привилегия назначается ему явно. Если субъект=роль, то для управления привилегиями используются соответственно:

GRANT ROLE имя_роли [ON объект] TO субъект [WITH GRANT OPTION]

REVOKE ROLE имя_роли [ON объект] FROM субъект

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

GRANT привилегия [ON объект] TO PUBLIC

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

REVOKE привилегия [ON объект] FROM PUBLIC

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

Oracle предусматривает меры по обеспечению безопасности для своих БД. Наиболее важным является контроль доступа к БД. Стандартный пакет СУБД компании включает функцию виртуального надзора за приложением (Virtual Private Database); с помощью этой функции можно установить контроль доступа для каждого отдельного поля БД, что позволяет обеспечить одновременную работу различных пользователей, причем каждый из них не будет иметь доступ к информации других. 

Для дополнительной защиты БД Oracle предлагает опцию Oracle Label Security, благодаря которой можно произвести более четкое разграничение доступа, например, определив временной интервал, в течение которого может быть открыт доступ к той или иной информации. 

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

При управлении доступом к таблицам и представлениям набор привилегий в реализации СУБД определяется производителем.

Привилегии выборки и модификации данных:

SELECT — привилегия на выборку данных; 

INSERT — привилегия на добавление данных; 

DELETE — привилегия на удаление данных; 

UPDATE — привилегия на обновление данных (можно указать определенные столбцы, разрешенные для обновления).

Привилегии изменения структуры таблиц:

ALTER — изменение физической/логической структуры базовой таблицы (изменение размеров и числа файлов таблицы, введение дополнительного столбца и т.п.);

INDEX — создание/удаление индексов на столбцы базовой таблицы; 
ALL — все возможные действия над таблицей.

В реализациях могут присутствовать другие разновидности привилегий, например:

CONTROL (IBM DB2) — комплексная привилегия управления структурой таблицы; 
REFERENCES — привилегия создания внешних ключей; 

RUNSTAT — выполнение сбора статистической информации по таблице.

        А вот Microsoft SQL Server может использовать аутентификацию как базы данных, так и операционной системы.

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

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

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

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

 

Список использованных источников:

1. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных.: Санкт-Петербург, 2004 г.