8. Контрольные вопросы

1. Дайте определение транзакции. Приведите примеры транзакций.

2. Перечислите и охарактеризуйте свойства транзакций.

3. Какие возможны варианты завершения транзакций.

4. Какие операторы языка SQL служат для работы с транзакциями в расширенной модели транзакций?

5. Можно ли в триггерах использовать команды управления транзакциями?

6. Для чего предназначен журнал транзакций?

7. В каких случаях выполняется восстановление БД по журналу транзакций?

8. Какие варианты ведения журналов транзакций существуют?

9. В чем заключаются различия вариантов ведения журнала транзакций: протокола с отложенными обновлениями и протокола с немедленными обновлениями.

10. Какие проблемы возникают при параллельной работе пользователей с БД?

11. Какие объекты БД могут быть заблокированы для реализации принципа изолированности пользователей?

12. Возможно ли задание вида блокировки в запросах?

13. Какие виды захвата объектов несколькими транзакциями существуют? Какие из них являются совместимыми?

14. В чем заключается проблема тупиков?

10. Безопасность данных и привилегии

    1. Принципы защиты баз данных от несанкционированного доступа

Безопасность данных является одной из важнейших задач при хранении информации в СУБД. В языке SQL используются следующие основные принципы защиты данных:

• Все операции над данными выполняются от имени конкретного пользователя. СУБД может отказаться выполнить запрашиваемые действия в зависимости от того, какой пользователь запрашивает это действие.

• СУБД разрешает пользователям осуществлять действия над одними объектами и запрещает делать это с другими.

• В SQL используется система привилегий, то есть прав пользователя на проведение тех или иных действий над определенным объектом БД.

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

Пользователи могут быть объединены в группы. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC, для которой должен быть определен стандартный минимальный набор прав. По умолчанию предполагается, что каждый новый пользователь, если специально не указано иное, относится к группе PUBLIC.

В последних версиях ряда коммерческих СУБД появилось понятие роли. Роль – это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера БД. Имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс.

В самом общем виде концепция обеспечения безопасности БД заключается в следующем: необходимо поддерживать проверку подлинности (аутентификацию) пользователя и проверку полномочий или прав пользователя .

Проверка подлинности означает достоверное подтверждение того, что пользователь, пытающийся выполнить некоторое действие действительно тот, за кого себя выдает.

Проверка полномочий основана на том, что каждому пользователю информационной системы соответствует набор действий, которые он может выполнять по отношению к определенным объектам.

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

Система назначения полномочий имеет иерархический характер. Самыми высокими полномочиями обладает системный администратор или администратор сервера БД. Традиционно только этот тип пользователя может создавать других пользователей и наделять их определенными полномочиями.

В ряде СУБД вводится следующий уровень иерархии пользователей - это администратор БД.

Далее схема предоставления полномочий строится по следующему принципу: каждый объект БД имеет владельца – пользователя, который создал данный объект. Владелец объекта обладает всеми правами – полномочиями на данный объект, в том числе он имеет право предоставлять другим пользователям полномочия по работе с данным объектом или забирать у них ранее предоставленные полномочия.

2. SQL- операторы для назначения и отмены полномочий пользователей

В стандарте SQL определены 2 оператора GRANT и REVOKE соответственно предоставления и отмены привилегий.

Оператор предоставления привилегий имеет следующий формат:

GRANT {<список действий>|ALL PRIVILEGES}

ON <имя объекта> TO {<имя пользователя>|PUBLIC}

[WITH GRANT OPTION]

Список действий определяет набор действий из допустимого перечня для данного объекта. Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.

Параметр <имя объекта > задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям.

Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, DELETE, INSERT, UPDATE. При этом операция обновления может быть ограничена несколькими столбцами.

Например, если некоторый пользователь владеет таблицей STUDENTS и хочет разрешить пользователю USER1 выполнить запрос к ней, он должен выполнить следующую команду:

GRANT SELECT ON STUDENTS TO USER1

Теперь пользователь USER1 может выполнять запросы к таблице STUDENTS, но не может изменять данные в таблице.

Если нескольким пользователям необходимо предоставить несколько привилегий, списки привилегий и пользователей разделяются запятыми:

GRANT SELECT, INSERT ON STUDENTS TO USER1, USER

Все привилегии имеют одинаковый синтаксис, кроме команд UPDATE и REFERENCES, в которых можно дополнительно указывать имена полей. Например, если пользователю разрешается изменять только поле STIP, то команда будет иметь следующий вид:

GRANT UPDATE(STIP) ON STUDENTS TO USER1

При использовании привилегии REFERENCES следуют тому же правилу, что и для UPDATE. Когда пользователю предоставляется привилегия REFERENCES, он может создавать внешние ключи, ссылающиеся на столбцы таблицы как на родительские ключи. Например, можно предоставить пользователю USER1 право использовать таблицу STUDDENTS как таблицу родительского ключа с помощью следующей команды:

GRANT REFERENCES NOM_ZACH ON STUDENTS TO USRER1

Эта команда дает пользователю право использовать поле NOM_ZACH в качестве родительского ключа по отношению к любым внешним ключам в его таблицах.

Для предоставления всех прав при использовании таблицы STUDENTS:

GRANT ALL ON STUDENTS TO USER1.

Для предоставления всем пользователям права просматривать таблицу STUDENTS:

GRANT SELECT ON STUDENTS TO PUBLIC.

Любой пользователь, добавляемый к системе, получает все привилегии, назначенные как PUBLIC.

Для того чтобы пользователь USER1 мог передавать свою привилегию SELECT другим пользователям:

GRANT SELECT ON STUDENTS TO USER1

WITH GRANT OPTION

Для удаления привилегий используется команда REVOKE. Например, для удаления привилегий пользователя USER1 используется команда:

REVOKE SELECT ON STUDENTS TO USER1

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

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

Привилегии также задаются на запуск хранимых процедур. Например, для предоставления привилегии на запуск процедуры COUNT_STUD:

GRANT EXECUTE ON COUNT_STUD TO USER1

Системный администратор может разрешить некоторому пользователю создавать и изменять таблицы БД. Для этого он должен записать оператор представления прав следующим образом:

GRANT CREATE TABLE, ALTER TABLE,DROP TABLE

O N<имя БД> TO USER1

В некоторых СУБД пользователь может получить право создавать БД. Например, в MS SQL SERVER может предоставить пользователю USER1 право создания своей БД на данном сервере. Для этого используется команда:

GRANT CREATE DATABASE

ON SERVER_0

TO USER1

По принципу иерархии теперь пользователь USER1, создав свою БД, может предоставить права на создание или изменение любых объектов в этой БД другим пользователям.

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

Существуют привилегии, которые не определены в терминах объектов данных. Такие привилегии называются привилегиями системы или правами БД. Они чаще всего включают в себя право создавать объекты данных, отличающиеся от базовых таблиц и представлений. В системе всегда имеются некоторые типы пользователей, которые автоматически имеют большинство или даже все привилегии, а также имеют возможность передать свой статус. В частности таким пользователем является администратор БД. В общем случае имеется 3 базовых привилегии системы:

• CONNECT – состоит из права зарегистрироваться и права создавать представления и синонимы, если пользователю переданы соответствующие привилегии объекта;

• RESOURCE- состоит из права создавать базовые таблицы;

• DBO – привилегия пользователя, дающая самые высокие полномочия в БД.

Некоторые системы имеют, кроме того, специального пользователя, иногда называемого SYSADMIN, SYS или SA, который имеет наивысшие полномочия. Фактически это специальное имя, а не просто пользователь с особой привилегией. Желательно, чтобы только один человек имел право зарегистрироваться с этим именем.

Команда GRANT пригодна для использования, как с привилегиями объекта, так и с системными привилегиями. Так, администратор БД может передать привилегию для создания таблицы пользователю USER:

GRANT RESOURCE TO USER

Первоначально пользователь USER создается администратором БД с автоматически предоставлением ему привилегий CONNECT. В этом случае обычно добавляется предложение IDENTIFIED BY, указывающее пароль. Например, для первоначальной регистрации пользователя администратор БД вводит следующую команду:

GRANT CONNECT TO USER IDENTIFIED BY <пароль>

Это приведет к созданию пользователя с именем USER, даст ему право зарегистрироваться и назначит ему пароль. Если новый пользователь будет создавать базовые таблицы, для него потребуется также предоставить привилегию RESOURCE.