С.Д. Кузнецов - Основы баз данных (1121716), страница 86
Текст из файла (страница 86)
В общем случае база данных является слишком дорогостоящим предметом, чтобы можно было использовать ее в автономном режиме. Обычно с достаточно большой базой данных (параллельно или последовательно) работает много приложений и пользователей, и не для всех них было бы разумно обеспечивать равноправный доступ к хранящимся данным. В языке 801 (Я)1:!999) предусмотрены возможности контроля доступа к разным объектам базы данных, в том числе к следующим объектам: ° таблицам; ° столбцам таблиц; ° представлениям; ° доменам; ° наборам символов*; ° порядкам сортировки символов (сойайоп); ° преобразованиям (ггапв1абоп); ° тризтерам; ° подпрограммам, вызываемым из ВОЙ; ° определенным пользователями типам. В совокупности в ВО):1999 может поддерживаться девять видов зашиты разных объектов в соответствии со следующими возможными действиями (см.
табл. ! 8.1). При разработке средств контроля доступа к объектам баз данных создатели Я.)Е придерживались принципа сокрытия информации об объектах, содержащихся в схеме базы данных, от пользователей, которые лишены доступа к этим объектам. Другими словами, если некоторый пользователь не обладает, например, привилегией на просмотр таблицы рко, то при выполнении операции ядьяст * рпон рпо он получит такое же диагностическое сообщение, как если бы таблица рпо не существовала. Если бы в случае отсутствия этой таблицы и в случае отсутствия привилегии доступа выдавались разные диагностические сообщения, то непривилегированный пользователь получил бы данные о том, что интересуюшая его таблица существует, но он лишен доступа к ней.
В лекции 12 мы бегло упоминали, что в ВО(.-ориентированной системе каждому зарегистрированному в системе пользователю соответствует его уникальный идентификатор (в стандарте используется термин идентификатор авторизации, аиг)зог(гаг(оп (депгт5ег — аидз10). Как мы отмечали, в стандарте ВО).:!999 не зафиксированы точные правила представления идентификатора пользователя, хотя обычно в реализациях ' Напомним, что в этом курсе мы ие касаемся вопросов интернационализации и локализа- ции языка Втзц 413 Основы баз данных Курс Таблица (8Д.
Вид защиты и Название соответствующе привилегии действие Применимо к следующим обвея там Просмотр Таблицы, столбцы, подпрограммы, вызываемые из ВОЬ яеьест Таблицы, столбцы Вставка тняеРт Таблицы, столбцы Таблицы Модификация яюлте Удаление пеьете Ссылка Таблицы, столбцы еегееенсея Использование ЯЯггЯе Домены, определенные пользователями типы, наборы символов, порядки сортировки символов, преобразования Инициирование тетЯЯее Таблицы Подпрограммы, вызываемые ИЗЯН Выполнение ехеснте Подтипизация 1ллзее Структурные типы * Как будет воказано в следующем подразлеле, термин роль в языке ЯОЬ полностью соот- ветствует своему:китейскому смыслу И в мире баз ланных люди большей частью играют чью-то роль, а не нрелставляют себя лично. 414 БОЬ ниладическая функция СЯЕЕЕнт ЯЯЕЕ выдает текстовую строку, содержащую регистрационное имя пользователя, как оно сохраняется в файлах соответствующей операционной системы (ОС).
Привилегии доступа к объектам базы данных могут предоставляться пользователям, представляемым своими идентификаторами, а также ролям* (см. следующий подраздел), выполнение которых, в свою очередь, может предоставляться пользователям. Кроме того, в Я)Ь поддерживается концепция псевдоидентификатора (или идентификатора псевдо) пользователя р11ВЬТС, который соответствует любому приложению или пользователю, зарегистрированному в системе баз данных. «Пользователю» рцвьтс могут предоставляться привилегии доступа к объектам базы данных, как и любому другому пользователю.
В модели контроля доступа Я1Ь создатель любого объекта базы данных автоматически становится владельцем этого объекта. При этом владелец объекта может идентифицироваться либо своим идентификатором пользователя, либо именем своей роли. Вообще говоря, владелец объекта Лекция 18 Авторизация доступа к данным, управление транзакциями и сессиями обладает полным набором привилегий для выполнения действий над объектом (с одним исключением, которое мы обсудим в данном разделе позже). Владелец объекта, помимо прочего, обладает привилегией на передачу всех (или части) своих привилегий другим пользователям или ролям.
В частности, влалелец объекта может передать другим пользователям или ролям привилегию на передачу привилегий последуюшим пользователям или ролям (эти действия с передачей привилегии на передачу привилегий могут продолжаться рекурсивно). Во многих реализациях поддерживаются привилегии уровня Рвл (РагаВаве Ас!лз(п(зггасог) для возможности выполнения операций РРР— Раса Ре((п(с(сп Рапдца9е (СКЕАТЕ, АРТЕК и РКОР над объектами, ВХО- дящими в схему базы данных). В стандарте 8ОЕ требуется лишь соблюдение следуюших правил. ° Любые пользователь или его роль могут выполнять любые операции РРР внутри схемы, которой владеют'.
° Не допускается выполнение каких-либо операций РРР внутри схемы, которой не владеет пользователь или роль, пытающиеся выполнить соответствуюшую операцию. ° Зги правила не допускают исключений. Пользователи и роли Как говорилось в начале это~о раздела, любой пользователь характеризуется своим идентификатором авторизации (ацг)зтР). В стандарте ничего не говорится о том, что ацГЫР должен быть идентичен региспзрационному имени пользователя в смысле операционной системы. Согласно стандарту БОЕ:1999, ацгЫР строится по тем же правилам, что и любой другой идентификатор, и может включать до!28 символов.
Тем не менее во многих реализациях ВО(., выполненных в среде ОС семейства 0М!Х, длина ацГЫР составляет не более восьми символов, как это свойственно ограничениям на длину регистрационного имени в этих ОС. В стандарте языка Ь0Е не специфицированы средства создания идентификаторов авторизации. Если говорить более точно, в стандарте не определяется какой-либо явный способ создания допустимых идентификаторов пользователей. Идентификатор авторизации может являться либо идентификатором пользователя, либо именем роли, а для создания ролей в БОЕ поддерживаются соответствуюшие средства (см.
ниже). Но в соответствии с правилами стандарта ЯЯ), все ацс)ттР должны отслеживаться СУБД (имеются в виду все ацг)ттР, для которых сушествует хотя ' В соответствии со стандартом, любые зарегистрированные в системе пользователь или роль автоматически являются владельцами части схемы базы данных, имена обьектов котороя начинаются с соответствуюшего идентификатора, зв которым следует символ «а. 4!5 Курс Основы баз данных бы одна привилегия). И в стандарте поддерживаются точные правила порождения и распространения привилегий. Привилегии по отношению к обьекту базы данных предоставляются системой владельцу схемы при создании объекта в этой схеме, и привилегии могут явно передаваться от имени одного апгьтР другому апгьтР при наличии у первого апг ьтР привилегии на передачу привилегий.
Итак, апгйтР может являться либо идентификатором пользователя, либо идентификатором роли. Попробуем разобраться в сути термина роль. При работе с большими базами данных в крупных организациях часто сотни служащих производят над базой данных одни и те же операции. Конечно, для этого каждый из служащих должен быть зарегистрированным пользователем соответствующей системы баз данных, и тем самым, обладать собственным апгптР. Используя базовые средства авторизации доступа (зафиксированные в стандарте Я.)1./92), можно предоставить кахсдому пользователю группы одни и те же привилегии доступа к требуемым объектам базы данных. Но схема авторизации доступа при этом становится очень сложной*. В некотором смысле имя роли идентифицирует динамически образуемую группу пользователей системы баз данных, каждый из которых обладает, во-первых, привилегией на исполнение данной роли и, во-вторых, всеми привилегиями данной роли для доступа к объектам базы данных, Другими словами, наличие ролей упрощает построение и администрирование системы авторизации доступа.
Проиллюстрируем это на рис. 18.!. Каждая стрелка на рис. 18.1 соответствует мандату доступа (паре <апгьтР, набор привилегий доступа к объекту едл), которыйтребуется сохранять в каталоге базы данных и проверять при попытке доступа от имени апгьтР. Как видно, в случае (а) требуется сохранение и проверка п*ю мандатов, где и — число пользователей в группе, а щ — число объектов базы данных, для которых пользователи группы должны иметь одни и те же привилегии. В случае (Ь) число требуемых для корректной работы мандатов равно лишь пьгл, и схема авторизации резко упрощается.
Группы пользователей, объединенных одной ролью, являются динамическими, поскольку в БОЕ поддерживаются возможности предоставления пользователю привилегии на исполнение данной роли и лишения пользователя этой привилегии (см. ниже в этом разделе). Более того, имеются возможности предоставления заданной роли 1 всех или части привилегий другой роли 1. Естественно, что при этом привилегии изменяются у всех пользователей, которые могут исполнять роль 1.
"Для каждого объекта базы данных и для каждого пользователя, обладающего какими-либо привилегиями лостуяа к этому объекту, требуется хранить список его привилегий. Если учесть есле и возможность передачи привилегий от одного пользователя к другому, то образуется произвольно сложный граф, за которым трудно следить администраторам базы данных. 416 Лекция 18 Авторизация доступа к данным, управление транзакциями и сессиями Рис. 18.1. Привилегии, пользователи и роли Более того, имеются возможности предоставления заданной роли л всех или части привилегий другой роли в.
Естественно, что при этом привилегии изменяются у всех пользователей, которые могут исполнять роль л. Применение идентификаторов пользователей и имен ролей В этом подразделе мы вынуждены использовать понятие ЯЯЕ-сессии, которое более последовательно обсуждается в третьем основном разделе лекции. Как и в предыдуших лекциях, посвяшенных языку БОЕ, мы можем оправдать подобную нелогичность только рекурсивной природой стандарта Я.П.*, Итак, в любой момент заданная БЯ1:сессия ассоциируется с идентификатором пользователя, называемым идентификатором пользователя ЯА-сессии и с именем роли, называемым именелг рсьти ЯДА-сессии.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
