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

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

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

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

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

соответствии с правилами стандарта 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.

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

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

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