Пользователи и роли

Поддержка авторизации доступа к данным в языке SQL

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

 

В языке SQL (SQL:1999) имеются контролировать доступ к разным объектам базы данных, в том числе, к следующим объектам:

· таблицам;

· столбцам таблиц;

· представлениям;

· доменам;

· наборам символов*;

· порядкам сортировки символов (collation);

· преобразованиям (translation);

· триггерам;

· подпрограммам, вызываемым из SQL;

· определенным пользователями типам.

 

В совокупности в SQL:1999 может поддерживаться девять видов защиты разных объектов в соответствии со следующими возможными действиями:

 

Вид защиты и соответствующее действие Название привилегии Применимо к следующим объектам
Просмотр SELECT Таблицы, столбцы, подпрограммы, вызываемые из SQL
Вставка INSERT Таблицы, столбцы
Модификация UPDATE Таблицы, столбцы
Удаление DELETE Таблицы
Ссылка REFERENCES Таблицы, столбцы
Использование USAGE Домены, определенные пользователями типы, наборы символов, порядки сортировки символов, преобразования
Инициирование TRIGGER Таблицы
Выполнение EXECUTE Подпрограммы, вызываемые из SQL
Подтипизация UNDER Структурные типы

 

При разработке средств контроля доступа к объектам баз данных создатели SQL придерживались принципа сокрытия информации об объектах, содержащихся в схеме базы данных, от пользователей, которые лишены доступа к этим объектам. Другими словами, если некоторый пользователь не обладает, например, привилегией на просмотр таблицы PRO, то при выполнении операции SELECT * FROM PRO он получит такое же диагностическое сообщение, как если бы таблица PRO не существовала. Если бы в случае отсутствия этой таблицы и в случае отсутствия привилегии доступа выдавались разные диагностические сообщения, то непривилегированный пользователь получил бы данные о том, что интересующая его таблица существует, но он лишен к ней доступа.

 

В Лекции 12 мы бегло упоминали, что в SQL-ориентированной системе каждому зарегистрированному в системе пользователю соответствует его уникальный идентификатор (в стандарте используется термин идентификатор авторизации, authorization identifier – authID). Как мы отмечали, в стандарте SQL:1999 не зафиксированы точные правила представления идентификатора пользователя, хотя обычно в реализациях SQL ниладическая функция CURRENT USER выдает текстовую строку, содержащую регистрационное имя пользователя, как оно сохраняется в файлах соответствующей операционной системы (ОС). Привилегии доступа к объектам базы данных могут предоставляться пользователям, представляемых своими идентификаторами, а также ролям* (см. следующий подраздел), выполнение которых, в свою очередь, может предоставляться пользователям. Кроме того, в SQL поддерживается концепция псевдоидентификатора (или идентификатора псевдо-) пользователя PUBLIC, который соответствует любому приложению или пользователю, зарегистрированному в системе баз данных. “Пользователю” PUBLIC могут предоставляться привилегии доступа к объектам базы данных, как и любому другому пользователю.

 

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

 

Во многих реализациях поддерживаются привилегии уровня DBA (DataBase Administrator) для возможности выполнения операций DDL – Data Definition Language (CREATE, ALTER и DROP над объектами, входящими в схему базы данных). В стандарте SQL требуется лишь соблюдение следующих правил:

· Любые пользователь или его роль могут выполнять любые операции DDL внутри схемы, которой владеют*.

· Не допускается выполнение каких-либо операций DDL внутри схемы, которой не владеет пользователь или роль, пытающиеся выполнить соответствующую операцию.

· Эти правила не допускают исключений.

 

Как говорилось в начале этого раздела, любой пользователь характеризуется своим идентификатором авторизации. В стандарте ничего не говорится о том, что authID должен быть идентичен регистрационному имени пользователя в смысле операционной системы. Согласно стандарту SQL:1999 authID строится по тем же правилам, как и любой другой идентификатор, и может включать до 128 символов. Тем не менее, во многих реализациях SQL, выполненных в среде ОС семейства UNIX, длина authID составляет не более 8 символов, как это свойственно ограничениям на длину регистрационного имени в этих ОС.

 

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

 

Итак, authID может являться либо идентификатором пользователя, либо идентификатором роли. Попробуем разобраться в сути термина роль. При работе с большими базами данных в больших организациях часто сотни служащих производят одни и те же операции над базой данных. Конечно, для этого каждый из этих служащих должны быть зарегистрированным пользователем соответствующей системы баз данных и, тем самым, обладать собственными authID. Используя базовые средства авторизации доступа (зафиксированные в стандарте SQL/92), можно предоставить каждому пользователю группы одни и те же привилегии доступа к требуемым объектам базы данных. Но схема авторизации доступа при этом становится очень сложной*. В некотором смысле имя роли идентифицирует динамически образуемую группу пользователей системы баз данных, каждый из которых обладает, во-первых, привилегией на исполнение данной роли и, во-вторых, всеми привилегиями данной роли для доступа к объектам базы данных. Другими словами, наличие ролей упрощает построение и администрирование системы авторизации доступа. Проиллюстрируем это на рис. 18.1.

 
 

 


(a) Определение привилегий пользователей без использования роли

 

 
 

 

 


(b) Определение привилегий пользователей с использованием роли

 

Рис. 18.1. Привилегии, пользователи и роли

 

Каждая стрелка на рис. 18.1 соответствует мандату доступа (паре < authID, набор_привилегий_доступа_к_ объекту_БД>), который требуется сохранять в каталоге базы данных и проверять при попытке доступа от имени authID. Как видно, в случае (a) требуется сохранение и проверка n*m мандатов, где n – число пользователей в группе, а m – число объектов базы данных, для которых пользователи группы должны иметь одни и те же привилегии. В случае (b) число требуемых для корректной работы мандатов равно лишь n+m, и схема авторизации резко упрощается.

 

Группы пользователей, объединенных одной ролью, являются динамическими, поскольку в SQL поддерживаются возможности предоставления пользователю привилегии на исполнение данной роли и лишения пользователя этой привилегии (см. ниже в этом разделе). Более того, имеются возможности предоставления заданной роли A всех или части привилегий другой роли B. Естественно, что при этом привилегии изменяются у всех пользователей, которые могут исполнять роль A.