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

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

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

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

Пользователи могут быть объединены в группы. Любой из пользователей может входить сразу в несколько групп. Стандартом определяется понятие группы PUBLIC, для которой должен быть определен стандартный минимальный набор прав. Предполагается, что каждый вновь создаваемый пользователь, если не указано другое, относится к группе PUBLIC. Наличие групп позволяет упростить управление полномочиями, когда их можно изменять не для каждого отдельного пользователя, а для целой группы сразу.

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

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

Элементарные концепции обеспечения безопасности базы данных исключительно просты. Существуют два фундаментальных принципа: проверка полномочия и проверка подлинности (аутентификация).

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

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

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

В ряде СУБД вводится также понятие администратора базы данных. Это имеет место в тех СУБД, где один сервер может управлять множеством баз данных (например, MS SQL Server, Sybase). В СУБД Oracle применяется однобазовая архитектура, поэтому там вводится понятие подсхемы – части общей схемы базы данных и вводится пользователь, имеющий доступ к подсхеме.

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

С другой стороны, в стандарте SQL определены две команды для работы с правами: GRANT (предоставить права) и REVOKE (лишить прав).

Оператор предоставления прав GRANT имеет следующий синтаксис:

GRANT {список_действий | ALL PRIVILEGES}

ON имя_объекта TO {имя_пользователя | PUBLIC}

[WITH GRANT OPTION]

Список действий определяет набор допустимых действий из общедопустимого перечня действия для данного объекта данных. Использование значения ALL PRIVILEGES означает, что будут разрешены все действия из перечня допустимых для данного объекта данных.

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

Необязательный параметр WITH GRANT OPTION определяем режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. При этом передавать права пользователь сможет только в рамках разрешенных ему действий.

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

GRANT {[SELECT][, INSERT][, DELETE][, UPDATE (список_столбцов)]}

ON имя_таблицы

TO {имя_пользователя | PUBLIC}

[WITH GRANT OPTION]

В качестве практического примера рассмотрим следующую ситуацию. Пусть пользователь admin создал таблицу students базы данных, в которую пользователь dean (декан) должен иметь возможность вносить новые записи, а пользователь professor (преподаватель) – просматривать записи. Тогда для предоставления соответствующих прав необходимо выполнить две следующие операции:

GRANT INSERT

ON students

TO dean

GRANT SELECT

ON students

TO professor

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

GRANT UPDATE (group_num)

ON students

TO dean

Если предполагается, что в случае отсутствия администратора его обязанности по надзору за таблицей students будет замещать пользователь senior_user, то передача прав будет осуществляться следующей командой:

GRANT ALL PRIVILEGES

ON students

TO senior_user

WITH GRANT OPTION

В этом случае senior_user может сам предоставить привилегии, например, другому пользователю secretary:

GRANT UPDATE (group_num)

ON students

TO secretary

Если же передача прав пользователю senior_user была бы ограниченной:

GRANT SELECT, INSERT, DELETE

ON students

TO senior_user

WITH GRANT OPTION

то пользователь senior_user уже не мог быть передать права на обновление строк никакому другому пользователю.

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

Отмена ранее присвоенных привилегий осуществляется с помощью оператора REVOKE. Синтаксис его использования следующий:

REVOKE {список_операций | ALL PRIVILEGES}

ON имя_объекта

FROM {список_пользователей | PUBLIC}

{CASCADE | RESTRICT}

Параметры CASCADE и RESTRICT определяют способ отмены привилегий. Параметр CASCADE отменяет привилегии не только непосредственно указанного в запросе пользователя, но и всех тех пользователей, которым он мог передать права, используя параметр WITH GRANT OPTION.

Следующий запрос отменит привилегии не только пользователя senior_user, но и пользователя secretary, которому он эти права передал уже сам:

REVOKE ALL PRIVILEGES

ON students

FROM senior_user CASCADE

Параметр RESTRICT ограничивает отмену привилегий только тем пользователем, который непосредственно указан в запросе. Однако, он не будет выполнении при наличии пользователя, которому были переданы права пользователем, указанным в запросе. Например, запрос в следующем примере не будет выполнен, так как senior_user передал часть прав пользователю secretary:

REVOKE ALL PRIVILEGES

ON students

FROM senior_user RESTRICT

Поэтому корректным будет выполнение следующего запроса:

REVOKE UPDATE

ON students

FROM senior_user, secretary

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

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

REVOKE EXECUTE

ON count_ex

FROM PUBLIC CASCADE

После выполнения этого запроса права на запуск процедуры можно назначать уже конкретным пользователям:

GRANT EXECUTE

ON count_exams

TO senior_user

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

GRANT CREATE TABLE, ALTER TABLE, DROP TABLE

ON db_university

TO admin_deputy

В некоторых базах данных можно также передать права на создание баз данных:

GRANT CREATE DATABASE

ON server

TO admin_deputy