Базы данных. Вводный курс

Сергей Кузнецов

Назад Содержание Вперёд

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

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

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

• таблицам;
• столбцам таблиц;
• представлениям;
• доменам;
• наборам символов¹⁶⁹⁾;
• порядкам сортировки символов (collation);
• преобразованиям (translation);
• триггерам;
• подпрограммам, вызываемым из SQL;
• определенным пользователями типам.

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

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

Таблица 22.1.

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

В лекции 16 мы бегло упоминали, что в 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 внутри схемы, которой не владеет пользователь или роль, пытающиеся выполнить соответствующую операцию.
• Эти правила не допускают исключений.

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

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

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

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

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

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

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

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

22.2.2. Применение идентификаторов пользователей и имен ролей

В этом подразделе мы вынуждены использовать понятие SQL-сессии, которое более последовательно обсуждается в третьем основном разделе лекции 22.4. Подключения и сессии. Как и в предыдущих лекциях, посвященных языку SQL, мы можем оправдать подобную нелогичность только рекурсивной природой стандарта SQL¹⁷³⁾.

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

В стандарте не специфицированы все способы ассоциирования authID с SQL-сессией. Определено лишь то, что если сессия образуется с помощью оператора CONNECT (см. раздел 22.4. Подключения и сессии), то authID указывается в качестве параметра соответствующей операции. Для реализаций SQL допускается, чтобы пользовательский идентификатор SQL-сессии совпадал с регистрационным именем пользователя с точки зрения операционной системы или являлся идентификатором, специально устанавливаемым специалистами организации, ответственными за обеспечение безопасности. Кроме того, допускается наличие в реализации оператора SET SESSION AUTHORIZATION, применение которого приводит к смене пользовательского идентификатора SQL-сессии. В начале SQL-сессии значение текущего идентификатора пользователя SQL-сессии совпадает со значением пользовательского идентификатора SQL-сессии, и такая ситуация сохраняется до тех пор, пока пользовательский идентификатор SQL-сессии не будет каким-либо образом изменен. Значение текущего пользовательского идентификатора SQL-сессии возвращается вызовом ниладической функции SESSION_USER (лекция 17).

Для каждой SQL-сессии существует также текущее имя роли (это имя можно получить путем вызова функции CURRENT_ROLE). Сразу после образования сессии текущему имени роли соответствует неопределенное значение, что трактуется как «роль для сессии не назначена». Имеется несколько способов подмены пользовательского идентификатора и/или имени роли SQL-сессии. При этом если задается идентификатор пользователя, то одновременно полагается, что неявно указывается имя роли, имеющее неопределенное значение. Если же задается имя роли, то, за несколькими исключениями, считается, что неявно указывается идентификатор пользователя, имеющий неопределенное значение. Более подробно мы обсудим подобные возможности ниже в этом разделе.

Если либо текущий идентификатор пользователя, либо текущее имя роли содержат неопределенное значение, то тот идентификатор или то имя, у которого значение не является неопределенным, используется в качестве текущего authID SQL-сессии. Если ни текущий идентификатор, ни текущее имя не содержат NULL, то текущим authID сессии служит текущий идентификатор пользователя.

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

22.2.3. Создание и ликвидация ролей

Для создания новой роли используется оператор CREATE ROLE, определяемый следующим синтаксическим правилом:

CREATE ROLE role_name
   [ WITH ADMIN { CURRENT_USER | CURRENT_ROLE } ]

Имя создаваемой роли должно отличаться от любого идентификатора авторизации, уже определенного и сохраненного в базе данных. В случае успешного создания роли некоторый authID получает привилегию на исполнение данной роли. Если в операторе CREATE ROLE не содержится раздел WITH ADMIN, то привилегию на исполнение роли получает текущий идентификатор пользователя SQL-сессии, если значение этого идентификатора отлично от NULL; иначе привилегия на исполнение роли дается текущему имени роли сессии.

Если в состав оператора включается раздел WITH ADMIN, то можно выбрать, будет ли являться владельцем роли authID, соответствующий текущему идентификатору пользователя SQL-сессии, или authID, соответствующий текущему имени роли (при условии, что соответствующие текущий идентификатор или текущее имя не содержат NULL). Кроме того, включение этого раздела означает, что authID-владелец роли получает право на передачу привилегии исполнения данной роли другим authID.

В соответствии со стандартом SQL:1999, привилегии, требуемые для выполнения оператора CREATE ROLE, определяются в реализациях SQL. Например, в некоторых реализациях выполнение этой операции разрешается только администратору базы данных.

Существующую роль можно ликвидировать с помощью оператора

DROP ROLE role_name

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

---

169   Напомним, что в этом курсе мы не касаемся вопросов интернационализации и локализации языка SQL.

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

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

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

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

Назад Содержание Вперёд