Защита баз данных

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

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

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

ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC } [WITH GRANT OPTION ]

Здесь список действий определяет набор действий из общедопустимого  перечня действий над объектом данного  типа.

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

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

<имя_пользователя> или  PUBLIC определяет, кому предоставляются  данные привилегии.

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

Рассмотрим пример, пусть  у нас существуют три пользователя с абсолютно уникальными именами userl, user2 и user3. Все они являются пользователями одной БД.

User1 создал объект Таb1, он является владельцем этого  объекта и может передать права  на работу с эти объектом  другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные  в Таb1 (например, таблицу новых  заказов), а пользователь user 3 является  большим начальником (например, менеджером  отдела), который должен регулярно  просматривать введенные данные.

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

Общий формат оператора назначения привилегий для объекта типа таблица  будет иметь следующий синтаксис:

GRANT {[SELECT][.INSERT][,DELETED[.UPDATE (<список  столбцов>)]} ON <имя таблицы>

ТО {<имя_пользователя> PUBLIC }

[WITH GRANT OPTION ]

Тогда резонно будет выполнить  следующие назначения:

GRANT INSERT

ON Tab1

ТО user2 GRANT SELECT

ON Tab1

TO user3

Эти назначения означают, что  пользователь user2 имеет право только вводить новые строки в отношение  Таb1> а пользователь user3 имеет право  просматривать все строки в таблице  Таb1.

При назначении прав доступа  на операцию модификации можно уточнить, значение каких столбцов может изменять пользователь. Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги. Предположим, что цена задается в столбце COST таблицы  Таb1. Тогда операция назначения привилегий пользователю user3 может измениться и выглядеть следующим образом:

GRANT SELECT. UPDATE (COST) ON Tab1 TO user3

Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права  по работе с созданной таблицей Таb1.

GRANT ALL PRIVILEGES

ON Tab1

TO user4 WITH GRANT OPTION

В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Таb1 в отсутствие владельца объекта пользователя user1. Поэтому в случае появления  нового оператора пользователя user5 он может назначить ему права  на ввод новых строк в таблицу  командой

GRANT INSERT

ON Tab1 TO user5

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

GRANT SELECT. UPDATE. DELETE

ON Tab1

TO user4 WITH GRANT OPTION,

то пользователь user4 не сможет передать полномочия на ввод данных пользователю user5, потому что эта операция не входит в список разрешенных для него самого.

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

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

Для отмены ранее назначенных  привилегий в стандарте SQL определен  оператор REVOKE. Оператор отмены привилегий имеет следующий синтаксис:

REVOKE {<список операций | ALL PRIVILEGES} ON <имя_объекта>

FROM {<список пользователей  | PUBLIC } {CASCADE | RESTRICT }

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

Например, при использовании  операции:

REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE

будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.

Параметр RESTRICKT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в  операторе REVOKE. Но при наличии делегированных привилегий этот оператор не будет  выполнен. Так, например, операция:

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

не будет выполнена, потому что пользователь user4 передал часть  своих полномочий пользователю user5.

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

Поэтому корректным будет  следующее использование оператора REVOKE:

REVOKE INSERT ON Tab! TO user2.user4 CASCADE

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

По умолчанию действие, соответствующее запуску (исполнению) хранимой процедуры, назначается всем членам группы PUBLIC.

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE.

REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE И  теперь мы можем назначить  новые права пользователю user4.

GRANT EXECUTE ON COUNT_EX TO user4

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

GRANT CREATE TABLE. ALTER TABLE, DROP TABLE ON OB_LIB TO user1

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

В некоторых СУБД пользователь может получить права создавать  БД. Например, в MS SQL Server системный администратор  может предоставить пользователю main_user право на создание своей БД на данном сервере. Это может быть сделано  следующей командой:

GRANT CREATE DATABASE

ON SERVERJ) TO main user

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

Для того чтобы разрешить  пользователю создавать объекты  внутри этой БД, используется понятие  системной привилегии, которая может  быть назначена одному или нескольким пользователям. Они выдаются только на действия и конкретный тип объекта. Поэтому- если вы, как системный администратор, предоставили пользователю право создания таблиц (CREATE TABLE), то для того чтобы он мог создать триггер для таблицы, ему необходимо предоставить еще одну системную привилегию CREATE TRIGGER. Система защиты в Oracle считается одной из самых мощных, но это имеет и обратную сторону — она весьма сложная. Поэтому задача администрирования в Oracle требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

Реализация защиты в некоторых СУБД

Архитектура защиты Access

Если у вас имеется  опыт работы с защитой, используемой на сервере или большой ЭВМ, структура  защиты в Access покажется вам знакомой. Вы можете указать пользователей, которым  предоставляется или, наоборот, не разрешается  доступ к объектам базы данных. Кроме  того, вы можете определить группы пользователей  и назначить разрешения на уровне группы, чтобы облегчить построение защиты для большого числа пользователей. Пользователю достаточно быть членом группы, чтобы получить права доступа, установленные для неё.

Access хранит информацию  о защите в двух местах. Во  время установки программа Setup создаст в папке \Program Files\Microsoft Ofice\0ffice стандартный файл рабочей  группы (System.mdw), который впоследствии  используется по умолчанию при  запуске Access. Этот файл содержит  информацию обо всех пользователях  и группах. При создании базы  данных Access сохраняет сведения о  правах, предоставляемых конкретным  пользователям и группам, в  файле базы данных.

Общая структура защиты Access отображена на рисунке 1. Учётные записи пользователей и групп хранятся в файле рабочей группы. Разрешение на доступ к конкретным объектам сохраняются  в файле базы данных.

Рис. 1

Расположение текущего файла  рабочей группы хранится в реестре Windows. Можно использовать служебную  программу Wrkadm.exe (администратор рабочих  групп) для изменения текущего или  определения нового файла рабочей  группы. Кроме того, можно выбирать нужный файл рабочей группы во время  выполнения приложения, задав соответствующий  параметр командной строки в ярлыке запуска. Если вам приходится часто  запускать в сети совместно используемое защищенное приложение, нужно позаботиться о том, чтобы системный администратор задал вашу рабочую группу, используемую по умолчанию, как общий файл в сетевой папке.

Каждая рабочая группа имеет уникальный внутренний идентификатор, генерируемый Access при определении  файла рабочих групп. Любая база данных, созданная пользователем  рабочей группы, «принадлежит» как  этому пользователю, так и рабочей  группе. Каждый пользователь и группа также имеет уникальный внутренний идентификатор, но можно дублировать  один и тот же код пользователя и группы в нескольких рабочих  группах. Когда вы назначаете право  доступа к объекту своей базы данных, Access сохраняет в ней внутренний идентификатор пользователя или  группы вместе с информацией о  доступе. Таким образом, предоставленные  вами права перемещаются вместе с  файлом базы данных при копировании  его в другую папку или на другой компьютер.

MS SQL Server

Организация защиты

В критических для бизнеса  приложениях, когда сервер СУБД должен быть постоянно доступен для клиентов, большинство профилактических работ  по поддержке базы данных приходится выполнять фактически в режиме on - line. MS SQL Server обладает возможностями  динамического резервного копирования  данных, т. е. даже когда эти данные используются и изменяются клиентами. В случае сбоя оборудования, отключения питания и т. д. механизм автоматического  восстановления MS SQL Server восстанавливает  все базы данных до их последнего целостного состояния без вмешательства  администратора. Все завершенные, но не отраженные в базе транзакции из журнала транзакций применяются  к базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя, вычищаются из журнала.

Говоря о симметричной архитектуре, операции резервного копирования  и восстановления могут распараллеливаться на несколько потоков и выполняться  одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится  свой поток. Параллельное резервное  копирование поддерживает до 32 одновременных  резервных устройств (backup devices), что  позволяет быстро создавать страховочные копии баз данных даже очень большой  емкости. Возможность резервного копирования  и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место  и время, не выполняя копирование  всей базы ради только некоторых ее объектов. Однако резервное копирование  отдельной таблицы требует наложения  на нее блокировки exclusive в отличие  от резервного копирования всей базы или журнала транзакций, которые  могут выполняться независимо от степени активности пользователей. Резервным копиям может быть назначен предельный срок хранения или дата утраты актуальности, до наступления  которой место, занятое на устройстве этими копиями, не может использоваться для размещения других резервных  копий при инициализации устройства. В качестве резервных устройств  могут также применяться временные  устройства, не входящие в состав базы и не имеющие записей в системной  таблице sysdevices:

DECLARE @tomorrow char(8)

SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) , 1)

DUMP DATABASE pubs

TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs.dmp'

WITH INIT, EXPIREDATE=@tomorrow, STATS

Для небольшой базы данных ее журнал транзакций обычно хранится на том же устройстве, что и сама база, и архивируется вместе с ней. Журналирование транзакций ведется  по принципу write-ahead, что означает, что  любое изменение сначала отражается в журнале транзакций и лишь потом  попадает собственно в базу. В случае нахождения журнала транзакций на отдельном  устройстве существует возможность  отдельного резервного копирования  журнала транзакций. Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется  ежедневно, а страховая копия  всей базы может делаться раз в  неделю, так как архивирование  журнала транзакций происходит значительно  быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает  его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая  журнал транзакций, полезна в случае его переполнения, которое можно  контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при  его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование  транзакций не представляет интереса, можно включить опцию очистки  последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в  периодической записи данных из кэша на диск, чтобы не допускать грязных  данных. Такого рода события постоянно  генерируются MS SQL Server или возникают  по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных  команде DUMP TRANSACTION TRUNCATE_ONLY.