Карпова Т.С. Базы данных: модели, разработка, реализация

Подождите немного. Документ загружается.

281

не

будет

выполнена,

потому

чю

пользователь

user4

передал

часть

своих

полно-

мочий,

пользователю

userS.

Посредством

оператора

REVOKE

можно

отобрать

все или

только некоторые

из ра-

нее

присвоенных привилегий

по

работе

конкретным объектом.

При

этом

из

описания синтаксиса оператора отмены привилегий

видно,

что

можно отобрать

привилегии одним оператором сразу

нескольких пользователей

или у

целой

группы

PUBLIC.

Поэтому

корректным

будет

следующее

использование

оператора

REVOKE:

REVOKE

INSERT

Tabl

user2.user4

CASCADE

При

работе

другими

объектами

изменяется список операций»

которые

исполь-

зуются

операторах

GRANT

REVOKE.

По

умолчанию

дейсгвие,

соответствующее

запуску

(исполнению)

хранимой про-

цедуры,

назначается всем членам группы

PUBLIC.

Если

вы

хотите изменить

это

условие,

после создания

хранимой,

процедуры

необходимо записать оператор

REVOKE.

REVOKE EXECUTE

COUNTJX

PUBLIC

CASCADE

теперь

мы

можем назначить новые права пользователю user4.

GRANT

EXECUTE

COUHTJX

user4

Системный администратор может разрешить некоторому

пользователю

созда-

вать

изменять таблицы

некоторой

БД.

Тогда

он

может записать оператор

предоставления

прав

следующим

образом:

GRANT

CREATE.

TABLE.

ALTER

TABLE.

DROP

TABLE

OBJ.IB

userl

этом случае пользователь

userl

может

создавать,

изменять

или

удалять

табли-

цы

в'БД

LIB,

однако

он не

может

разрешить

создавать

или

изменять

таблицы

этой

БД

другим

пользователям,

потому

что ему

дано разрешение

без

права

де-

легирования

своих возможностей.

некоторых

СУБД пользователь может получить права создавать

БД.

Напри-

мер,

в MS

SQ.L

Server системный администратор может предоставить пользова-

телю

main

user

право

на

создание

своей

БД на

данном

сервере.

Это

может

быть

сделано

следующей

командой:

GRANT

CREATE

DATABASE

SERVERJ

main

user

282

Глава

13.

Защита

информации

базах

данных

По

принципу

иерархии

пользователь

main_user,

создан

свою

БД,

теперь может

предоставить

права

на

создание

пли

изменение

любых объектов

этой

БД

дру-

гим

пользователям.

СУБД,

которые

поддерживают

однобазовую

архитектуру,

такие

разрешения

недопустимы.

Например,

СУБД

Oracle

на

сервере

создается

только

одна

БД,

но

пользователи

могут работать

на

уровне подсхемы

(части

таблиц

БД и

свя-

занных

ними

объектов).

Поэтому

там

вводится

понятие

системных

привиле-

гий.

Их

очень

много,

различных

привилегии.

Для

того чтобы разрешить

пользователю

создавать

объекты внутри

этой

БД,

используется

понятие

системной

привилегии,

которая может быть

назначена

од-

ному

пли

нескольким

пользователям.

Они

выдаются только

на

действия

кон-

кретный

тип

об-ьекта.

Поэтому- если

вы, как

системный

администратор,

предо-

ставили

пользователю

право

создания

таблиц

(CREATE TABLE),

то для

того чтобы

он

мог

создать

триггер

для

таблицы,

ему

необходимо

предоставить

еще

одну

системную

привилегию

CREATE TRIGGER.

Система

защиты

Oracle считается

од-

ной

из

самых

мощных,

но это

имеет

обратную сторону

— она

весьма

сложная,

Поэтому

задача

администрирования

Oracle

требует

хорошего

знания

как

се-

мантики

принципов

поддержки

прав

доступа,

так и

физической

реализации

этих

возможностей.

Реализация

системы

защиты

MS SQL

Server

SQL

server

6.5

поддерживает

режима

проверки

при

определении

прав пользо-

вателя:

Стандартный

(standard),

Интегрированный

(integrated

security).

Смешанный

(mixed).

Стандартный режим защиты

предполагает,

что

каждый

пользователь

должен

иметь

учетную

запись

как

пользователь

домена

Server.

Учетная

запись

пользовате-

ля

домена

включает

имя

пользователя

и его

индивидуальный

пароль.

Пользова-

тели

доменов

могут быть

объединены

группы.

Как

пользователь

домена

поль-

зователь

получает

доступ

определенным

ресурсам домена.

качестве

одного

из

ресурсов

домела

рассматривается

SQL

Server.

По

для

доступа

к SQL

Server

пользователь

должен

иметь

учетную

запись

пользователя

MS SQL

Server.

Эта

учетная

запись

также

должна

включать

уникальное

имя

пользователя

сервера

его

пароль.

При

подключении

операционной

среде

пользователь

задает

слое

имя

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

При

подключении

серверу

баз

данных

поль-

зователь задает свое

уникальное

имя

пользователя

SQL

Server

свой

пароль.

Интегрированный

режим

предполагает,

что для

пользователя

задастся

только

одна

учетная

запись

операционной

системе,

как

пользователя

домена,

а ад-

Server

идентифицирует

пользователя

по

его

данным

лтой

учетной

записи.

этом

случае

пользователь

задает

только

одно

свое

имя

одни

пароль.

Реализация

системы

защиты

в MS

SQLServer

283

случае

смешанного

режима

часть

пользователей

может

быть

подключена

серверу

использованием

стандартного

режима,

часть

использованием

интегрированного

режима.

В MS SQL

Server

7.0

оставлены

только

режима;

интегрированный,

называе-

мый

Windows

Authentication

Mode (Windows

Authentication),

смешан-

ный,

Mixed Mode (Windows

Authentication

and SQL

Server

Authentication).

Алгоритм

проверки

аутентификации

пользователя

в MS SQL

Server

7.0

приве-

ден

па

рис.

13,1.

Рис.

13.1.

Алгоритм проверки

аутентификации

пользователя

в MS SQL

Server

7,0

При

попытке

подключения

серверу

БД

сначала

проверяется,

какой

метод

аутентификации

определен

для

данного

пользователя.

Если

определен

Windows

Authentication

Mode,

то

проверяется,

имеет

ли

данный

пользователи

домена

доступ

ресурсу

SQL

Server,

если

он

имеет

доступ,

то

выполняется

по-

284

Глава

13.

Защита

информации

базах данных

лытка

подключения

использованием имени пользователя

пароля, опреде-

ленных

для

пользователя домена; если данный пользователь

имеет

права

под-

ключения

к SQL

Server,

то

подключение выполняется успешно,

противном

случае пользователь получает

сообщение

том,

что

данному пользователю

не

разрешено

подключение

к SQL

Server.

При

использовании смешанного

режима

аутентификации

средствами

SQL

Server

проводится последовательная

проверка

имени

пользователя (login)

его

пароля

(password);

если

эти

параметры зада-

ны

корректно,

то

подключение

завершается

успешно,

противном случае

поль-

зователь также получает сообщение

невозможности подключиться

к SQL

Server.

Для

СУБД

Oracle

всегда

используется

дополнение

имени пользрвателя

пароля

операционной

среде

его имя и

пароль

для

работы

сервером

БД.

Проверка

полномочий

Второй задачей

при

работе

с БД, как

указывалось ранее, является проверка пол-

номочий

пользователей.

Полномочия пользователей хранятся

специальных

системных

таблицах,

и их

проверка осуществляется ядром СУБД

при

выполне-

нии

каждой операции. Логически

для

каждого пользователя

каждого объекта

БД как бы

строится

некоторая условная матрица,

где по

одному измерению

расположены

объекты,

а по

другому

—

пользователи.

На

пересечении

каждого

столбца

каждой строки расположен перечень разрешенных операций

для

дан-

ного

пользователя

над

данным объектом.

первого взгляда кажется,

что эта мо-

дель проверки достаточно

устойчивая.

Но

сложность возникает тогда, когда

мы

используем косвенное обращение

объектам. Например, пользователю

user_N

не

разрешен

доступ

таблице

ТаЫ,

но

этому пользователю разрешен запуск хра-

нимой

процедуры

SP_N,

которая

делает

выборку

из

этого объекта.

По

умолчанию

все

хранимые процедуры запускаются

под

именем

их

владельца.

Такие проблемы

должны

решаться организационными методами.

При

разреше-

нии

доступа некоторых

пользователей

необходимо

помнить

возможности кос-

венного

доступа.

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

не

была чисто технической задачей,

это

комплекс

организационно-технических

мероприятий, которые должны обес-

печить

максимальную

конфиденциальность информации,

хранимой

в БД.

Кроме

того,

при

работе

сети существует

еще

проблема проверки подлинности

полномочий.

Эта

проблема состоит

следующем. Допустим, процессу

даны

полномочия

по

работе

с БД, а

процессу

такие

полномочия

не

даны.

Тогда

напрямую процесс

не

может обратиться

к БД, но

он

может обратиться

процессу

1 и

через пего

получить

доступ

информации

из БД.

Поэтому

безопасной среде должна присутствовать модель проверки подлин-

ности,

которая обеспечивает

подтверждение

заявленных

пользователями

или

про-

цессами

идентификаторов. Проверка полномочий приобрела

еще

большее

зна-

чение

условиях массового

распространения

распределенных

вычислении.

При

Проверка

полномочий

285

существующем

высоком уровне связности вычислительных систем необходимо

контролировать

все

обращения

системе.

Проблемы проверки подлинности обычно

относят

сфере безопасности комму-

никаций

сетей, поэтому

мы не

будем

их

здесь более обсуждать,

за

исключени-

ем

следующего

замечания.

целостной

системе компьютерной безопасности,

где

четкое

выполнение

программы защиты информации обеспечивается

за

счет

взаимодействия

соответствующих

средств

операционных системах, сетях,

'ба-

зах

данных, проверка

подлинности

имеет прямое отношение

безопасности

баз

данных.

Заметим,

что

модель

безопасности, основанная

на

базовых механизмах провер-

ки

полномочий

проверки

подлинности,

не

решает таких проблем,

как

укра-

денные пользовательские идентификаторы

пароли

или

злонамеренные дейст-

вия

некоторых

пользователей, обладающих

полномочиями,

—

например, когда

программист, работающий

над

учетной системой, имеющей

полный

доступ

учетной

базе

данных,

встраивает

в код

программы

«Троянского

коня»

целью

хищения

или

намеренного изменения информации, хранимой

в БД.

Такие

во-

просы

выходят

за

рамки нашего обсуждения средств защиты

баз

данных,

но

следует

тем не

менее представлять себе,

что

программа обеспечения

информа-г

ционной

безопасности должна охватывать

не

только

технические

области (та-

кие

кик

защита сетей)

баз

данных

операционных систем),

но

проблемы

фи-

зической защиты,

надежности

персонала

(скрытые

проверки),

аудит, различные

процедуры поддержки

безопасности,

выполняемые вручную

или

частично

авто-

матизированные.

ГЛАВА

Обобщенная

архитектура

СУБД

Мы

рассмотрели

отдельные

аспекты работы

СУБД.

Теперь попробуем кратка

обобщить

все,

что

узнали,

построим

некоторую

условную

обобщенную

струк-

туру

СУБД.

На

рис.

МЛ

изображена

такая

структура.

Здесь

условно

показано,

что

СУБД

должна

управлять

внешней

памятью,

которой

расположены

файлы

данными,

файлы

журналов

файлы

системного

каталога.

другой

стороны,

СУБД

управляет

оперативной

памятью,

которой

распо-

лагаются

буфера

данными,

буфера

журналов,

данные

системного каталога,

которые

необходимы

для

поддержки

целостности

проверки

привилегий

поль-

зователей.

Кроме

того,

оперативной

памяти

по

время

работы

СУБД

распола-

гайся

информация,

которая

соответствует

текущему

состоянию

обработки

за-

просов,

там

хранятся

планы

выполнения

скомпилированных

запросов

т. д.

Модуль

управления

внешней памятью

обеспечивает'

создание

необходимых

струк-

тур

внешней

памяти

как для

хранения

данных,

непосредственно

входящих

БД,

так

для

служебных

целей,

например

для

ускорения

доступа

данным

неко-

торых случаях

(обычно

для

этою

используются

индексы).

Как мы

рассматрива-

ли

ранее,

некоторых

реализациях

СУБД

активно

используются

возможности

существующих

файловых систем,

других работа

производится

вплоть

до

уров-

ня

устроштв

внешней

памяти.

Но

подчеркнем,

что в

развитых

СУБД

пользова-

тели

любом

случае

не

обязаны

знать,

попользует

ли

СУБД

файловую

систему,

если

использует,

о как

организованы

файлы,

частности,

СУБД

поддержи-

вает

собственную

систему

именования

объектов

БД,

Модуль

управления

буферами

оперативной

памяти

предназначен

для

решения

задач

эффективной

буферизации,

когорая

используется

практически

для

выпол-

нения

всех остальных

функции

СУБД.

Условно

оперативную

память,

которой

управляет

СУБД,

можно

представить

как

совокупность

буферов,

хранящих

страницы

данных,

буферов,

хранящих

страни-

цы

журналов

транзакций

область совместно

используемого

пула

(см.

рис.

14.2).

Последняя

область

содержит

фрагменты

системного

каталога,

которые

необхо-

димо

постоянно

держать

оперативной

памяти,

чтобы ускорить обработку

за-

просов

пользователей,

область

операторов

SQL с

курсорами.

Фрагменты

сие-

287

темного

каталога

некоторых

реализациях

иазышогся

словарем

данных.

стандарте

SQ.L2

определены

общие

требования

системному

каталогу.

Системный

каталог

реляционных

СУБД

представляет

собой

совокупность

спе-

циальных

таблиц,

KOTopi.iMii

шшдест

сама

СУБД.

Таблицы

системного

каталога

создаются

автоматически

при

установке

программного

обеспечения

серкера

БД.

Все

системные

таблицы

обычно

объединяются

некоторым

специальным

«сис-

темным

идентификатором

пользователя».

При

обработке

ЯфЬзаиросов

СУБД

постоянно

обращается

этим

таблицам.

некоторых

СУБД

разрешен

ограни-

ченный

доступ

пользователей

ряду

системных

таблиц,

однако

только

режи-

ме

чтения.

Только

системны!!

администратор

имеет

некоторые права

па

моди-

фикацию

данных

некоторых

системных

таблицах.

Каждая

таблица

системного

каталога

содержит

информацию

об

отдельных

структурных

элементах

БД, В

стандарте

SQL2

определен!.!

следующие

систем-

ные

таблицы:

288

Глава

14.

Обобщенная архитектура СУБД

Таблица 14.1.

Содержание

системного

каталога

по

стандарту

SQL2

Системная

таблица

USERS

SCHEMA

DATA_TYPE_DESCRIPTION

DOMAINS

DOMAIN_CONSTRAINS

TABLES

VIEWS

COLUMNS

VIEW_TABLE_USAGE

VIEW_COLUMNJJSAGE

TABLE_CONSTRAINS

KEY_COLUMN_USAGE

REFERENTIAL_CONSTRAINTS

CHECK_

CONSTRAINTS

CHECKJTABLEJJSAGE

Содержание

Одна

строка

для

каждого

идентификатора

пользователя

зашифрованным

паролем

Одна

строка

для

каждой

информационной

схемы

Одна

строка

для

каждого

домела

или

столбца,

имеющего

определенный

тип

данных

Одна строка

для

каждого домена

Одна строка

для

каждого ограничивающего

условия,

наложенного

па

домен

Одна строка

для

каждой таблицы

указанием

имени,

владельца, количества

столбцов,

размеров данных

столбцов,

и т. д.

Одна строка

для

каждого представления

указанием

имени,

имени

владельца, запроса, который

определяет представление

и т, д.

Одна строка

для

каждого столбца

указанием

имени

столбца,

имени

таблицы

или

представления,

которому

он

относится, типа

данных

столбца,

его

размера,

допустимости

или

недопустимости

неопределенных

значений

(NULL

) и т. д.

Одна строка

для

каждой

таблицы,

на

которую

имеется ссылка

каком-либо представлении

(если

представление многотабличное,

то для

каждой

таблицы

заносится

одна

строка)

Одна

строка

для

каждого столбца,

па

который

имеется ссылка

некотором

представлении

Одна

строка

для

каждого

условия

ограничения,

заданного

каком-либо

определении

таблицы

Одна

строка

для

каждого

сюлбца,

на

который

наложено

условие

уникальности

который

присутствует

определении

первичного

или

внешнего

ключа

(если

первичный

или

введший

ключ

заданы

несколькими

столбцами,

то для

каждого

из них

задается

отдельная

строка)

Одна

строка

для

каждого

внешнего

ключа,

присутствующего

определении таблицы

Одна

строка

для

каждого

условия

проверки,

заданного

определении

таблицы

Одна

строка

для

каждой

таблицы,

на

коюрую

имеется

ссылка

условиях

проверки,

ограничительном

условии

для

домена

или

всей

таблицы

289

Системная

таблица

CHECK_COLUMN_USAGE

ASSERTIONS

TABLE_PRIVILEGES

COLUMNJPRIVILEGES

USAGE__PRIVILEGES

CHARACTER

SETS

COLLATIC-KS

TRANSLATIONS

SQL_LAGUAGES

Содержание

Одна

строка

для

каждого

столбца,

на

который

имеегс'я

ссылка

условии

проверки,

ограничительном

условии

для

домена

или

ином

ограничительном

условии

Одна

строка

для

каждого

декларативного

утверждения

целостности

Одна

строка

для

каждой

привилегии,

предоставленной

на

какую-либо

таблицу

Одна

строка

для

каждой

привилегии,

предоставленной

на

какой-либо

столбец

Одна

строка

для

1саждой

привилегии,

представленной

па

какой-либо

домен,

набор

символов

и т. д.

Одна

строка

для

каждого

заданного

набора

символов

Одна

строка

для

заданной

последовательности

Одна

строка

для

каждого

заданного

преобразования

Одна

строка

для

каждого

заданного

языка,

поддерживаемого

СУБД

Стандарт

SQL2

не

требует,

ртобы

рУБД

точности

поддерживала

требуемый

набор системных

таблиц.

Стандарт

ограничивается требованием

того,

чтобы

для

рядовых

пользователей

.были

доступны

декоторые

специальные

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

системного каталога. Поэтому

системные

таблицы

организованы

по-разному

разных

СУБД

имеют различные

имена,

но

большинство СУБД

предо-ставля-

гот ряд

основных

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

Кроме того, системный каталог отражает некоторые

дополнительные

возможно-

сти,

предоставляемые

конкретными

СУБД. Так,

например,

системном катало-

ге

Oracle

присутствуют таблицы

синонимов,

Область

SQL

содержит данные

связывания,

временные буферы, дерево разбора

план

выполнения

для

каждого оператора SQL, переданного серверу

БД. Об-

ласть разделяемого пула

ограничена

размере,

поэтому,

возможно,

в ней не

мо-

гут

поместиться

вес

оператора

SQL, которые были выполнены

момента запус-

ка

сервера

БД.

Ядро СУБД удаляет старые,

давно

не

используемые операторы,

освобождая память

под

новые

операторы

SQL. Если

пользователь

выполняет

запрос, план

выполнения

которого

уже

хранится

разделяемом пуле,

то

СУБД

не

производит

его

разбор

построение нового плана,

она

сразу запускает

его на

выполнение,

возможно,

новыми параметрами.

Модуль

управления

транзакциями

поддерживает механизмы фиксации

отката

транзакций,

он

связан

модулем управления буферами оперативной памяти

обеспечиваег

сохранение

всей информации, которая требуется после мягких

или

жестких сбоев

системе. Кроме

того,

модуль

управления

транзакциями содер-

жит

специальный механизм поиска тупиковых

ситуаций

или

взаимоблокировок

реализуег

одну

из

принятых стратегий принудительного завершения транзак-

ций

для

развязывания

тупиковых

ситуаций.

290

Глава

14.

Обобщенная архитектура

СУБД

Особое

внимание

надо

обратить

на

модуль

поддержки

SQL.

Эю

практически

транслятор

языка

SQL и

блок

оптимизации

запросов.

общем,

оптимизация

запросов может быть разделена

на

синтаксическую

се-

мантпческую.

Методы синтаксической

оптимизации запросов

Методы

синтаксической

оптимизации

запросов

связаны

построением

некото-

рой

экпнвалентной

формы,

называемой

иногда

канонической

формой,

которая

требует

меньших

затрат

на

выполнение

запроса,

но

дает

результат,

полностью

эквивалентный

исходному запросу.

методам,

используемым

при

синтаксической

оптимизации

запросов, относят-

ся

следующие:

Логические

преобразования

запросов.

Прежде

всего

это

относится

преоб-

разованию

предикатов,

входящих

условие

выборки,

Предикаты,

содержа-

щие

операции

сравнения

простых

значений.

Такой

предикат

имеет

вид

ариф-

метическое

выражение

ОС

арифметическое

выражение,

где

ОС —

операция

сравнения,

арифметические

выражения

левой

правой частей

общем

случае

содер-

жат

имена

полей отношений

константы

(в

языке

SQL

среди

констант

мо-

гут

встречаться

имена

переменных

объемлющей

программы,

значения

ко-

торых

становятся

известными

только

при

реальном

выполнении

запроса).

Канонические

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

могут быть

различными

для

предикатов

раз-

ных

типов. Ясли

предикат

включает

только

одно

имя

поля,

то его

канониче-

ское

представление

может, например, иметь

вид

имя

поля

ОС

константное

ариф-

метическое

выражение

(эта

форма предиката

—

простои

предикат

селекции

—

очень

полезна

при

выполнении

следующего

этапа

оптимизации).

Если

на-

чальное

представление

предиката

имеет

вид

fn+l°)*R.B

ОС 100

здесь

п -

переменная

языка,

R.B

имя

столбца

отношения

ОС

допус-

тима»

операция

сравнения.

Каноническим

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

такого

предиката

может

быть

R.B ОС

100/<п-И2)

этом случае

мы

один

раз для

заданного значения

переменной

вычисляем

выражение

скобках

правую часть

операции

сравнения

100/(п

+12),

а по-

том

каждую строку можем

сравнивать

полученным

значением.

Если

предикат

включает

точности

два

имени поля

разных

отношений

(или

двух разных

вхождений

одного

отношения),

то

его

каноническое

представле-

ние

может иметь

вид

имя

поля

ОС

арифметическое

выражение,

где

арифметическое

вмрнжччше

правой

части включает только

константы

второе

имя

поля

(JTO

тоже

форма, полезная

для

выполнения

следующего шага

оптимизации,