Системные правила безопасности

Привилегии создания объектов по умолчанию принадлежат АБД, одной из обязанностей которого является проектирование структуры БД. Однако в ряде случаев следует разрешить пользователям создавать собственные объекты (наделить авторским правом).

Пользователю могут понадобиться различные объекты – домены, базовые и производные отношения, правила целостности, формы ввода данных, отчётные формы, правила безопасности и т.д. Однако не следует перегружать входной язык системы специальными конструкциями для предоставления привилегий на создание всех возможных типов объектов. Достаточно предусмотреть возможность явного предоставления прав на создание базовых отношений. Права создания объектов, необходимых для определения и использования базовых отношений, следуют из привилегии создания отношений. Их можно специально не оговаривать. Привилегии создания объектов могут быть предоставлены командой:

CREATE SECURITY RULE имя_правила

GRANT CREATE BASE RELATION

TO ID;

Эта команда создаёт объект базы данных – правило безопасности с указанным именем. Правило сохраняется в системном каталоге, связывается с ID и предоставляет ему указанные привилегии.

Пример.

CREATE SECURITY RULE SystemSR1

GRANT CREATE BASE RELATION

TO Иванов;

Это правило разрешает системе создавать от имени ID Иванов базовые отношения. Владельцем этих отношений является Иванов. Он распоряжается ими без ограничений.

Объектные правила безопасности

Объектные привилегии по умолчанию принадлежат автору объектов. Он может предоставить их другому ID, сформулировав соответствующее правило безопасности.

Правило должно иметь уникальное имя и указывать:

· список предоставляемых привилегий;

· объект защиты, на который оно распространяется;

· список ID, которым предоставляется право осуществлять указанные операции над указанным объектом;

· действие, которое должно быть выполнено при попытке нарушения правила.

Оператор создания правила может выглядеть так:

CREATE SECURITY RULE имя_правила

GRANT список_привилегий

ON диапазон

TO список _ID

[ ON ATTEMPTED VIOLATION действие ];

привилегия::= RETREIVE [ (список_атрибутов) ]

| INSERT

| DELETE

| UPDATE [ (список_атрибутов) ]

| REFERENCE

| ALL

Предложение GRANT определяет набор привилегий, предоставляемых правилом. Привилегии RETRIEVE, INSERT, DELETE разрешают соответственно извлекать, добавлять и удалять кортежи объекта, UPDATE – обновлять значения атрибутов, REFERENCE – использовать ссылки на объект в определениях других объектов БД. Если указан список_атрибутов, то действие привилегии распространяется только на указанные атрибуты. Спецификация ALL означает предоставление всех перечисленных привилегий.

Предложение ON указывает объект защиты. Здесь диапазон – это всегда подмножество кортежей точно одного именованного отношения. Оно задаётся реляционным выражением. Для определённости будем считать, что это выражение реляционного исчисления.

Необязательное предложение ON ATTEMPTED VIOLATION действие определяет реакцию системы на попытку нарушения правила. По умолчанию – это отказ в выполнении затребованного действия, но могут быть предусмотрены и более сложные процедуры. Например: завершить работу приложения; заблокировать клавиатуру пользователя и сообщить о попытке лицу, ответственному за безопасность и т.п.

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

Примеры.

CREATE SECURITY RULE SR1

GRANT RETREIVE (S#, Sn, Ci)

ON S

TO Иван, Андрей;

Это правило наделяет ID Иван и Андрей правом извлечения (просмотра) значений атрибутов S#, Sn, Ci во всех кортежах отношения S. При любой попытке указанных ID извлечь значения статуса поставщика будет выдано сообщение об ошибке. Операция не будет выполнена. Подчеркнем, что в общем случае это не эквивалентно привилегии на просмотр всех кортежей проекции отношения на указанные атрибуты.

CREATE SECURITY RULE SR2

GRANT RETREIVE, INSERT, DELETE, UPDATE (St)

ON S WHERE Ci = ‘Яя’

TO Боря;

ID Боря имеет право просматривать, добавлять, удалять кортежи отношения S, а также изменять значения статуса поставщиков из Яи. Если он попытается добавить кортеж со значением Ci, отличающимся от ‘Яя’, то система не допустит этого и зарегистрирует попытку нарушения правила SR2.

В общем случае предикат, определяющий диапазон действия правила, может ссылаться на любые отношения БД. Следующее правило разрешает ID Коля извлекать кортежи отношения S, содержащие сведения о поставщиках, поставивших что-либо для какого-либо изделия, производимого в Томске.

CREATE SECURITY RULE SR3

GRANT RETREIVE

ON S WHERE EXISTS SPJ

(EXISTS J

(S.S# = SPJ.S#

AND J.J# =SPJ.J#

AND J.Ci = ‘Томск’)

)

TO Коля;

Следующий пример демонстрирует так называемое контекстно зависимое правило. Оно разрешает выполнять любые действия с кортежами отношения S всем пользователям группы Отдел_снабжения, но только в рабочее время.

CREATE SECURITY RULE SR4

GRANT ALL

ON S WHERE Day() IN (‘пн’, ‘вт’, ‘ср’, ‘чт’, ‘пт’)

AND Time() > ‘09:00’

AND Time() < ’17:00’

TO Отдел_снабжения;

Здесь мы предполагаем, что существуют встроенные функции Day() и Time(), возвращающие текущие значения даты и времени в строковом формате. Кроме того, считается, что система обеспечивает регистрацию групп пользователей, имеющих общий ID и одинаковые права доступа.

Если для одной и той же пары (ID, объект) определено несколько различных правил безопасности, то запрос на доступ выполняется тогда и только тогда, когда логическая сумма всех правил принимает значение ‘истина’. Определяя систему правил безопасности, следует иметь это в виду.

Пусть наряду с SR4 определено следующее правило:

CREATE SECURITY RULE SR7

GRANT RETREIVE

ON S

TO Отдел_снабжения;

Тогда пользователи отдела снабжения смогут извлекать данные о поставщиках в любое время. Временные ограничения накладываются на все привилегии, кроме RETREIVE.

Контрольный след операций

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

– системный номер терминала, с которого поступил запрос;

– ID запросившего пользователя;

– системные дату и время запуска операции;

– исходный текст запроса;

– вовлечённые в запрос базовые отношения, кортежи и атрибуты;

– начальные значения;

– конечные значения.

Контрольный след является частью служебной базы данных системы. Администратор БД (и только он!) получает доступ к нему с помощью обычного языка запросов. Имея эту информацию, он может обнаружить факт несанкционированного доступа, устранить внесённые искажения данных, выявить бреши в системе защиты и, возможно, идентифицировать нелегитимного пользователя.

В настоящем подразделе мы обсудили проблемы и способы санкционирования доступа к данным. В подразделах 5.4 и 5.5 обсуждаются подходы к управлению параллелизмом и восстановлению данных. Они основаны на понятии транзакции – некоторой совокупности операций, которую система воспринимает как единое целое. В следующем подразделе обсуждается это понятие.

Транзакции и управление данными

Понятие транзакции

В общем случае единичное обновление данных нарушает целостность БД. Например, пусть отношение P «учебной» БД содержит атрибут TQt, значениями которого являются суммарные объёмы поставок деталей. Пусть регистрируется новая поставка, т.е. выполняется операция вставки кортежа в отношение SPJ:

INSERT VALUES (‘S8’, ‘P2’, ‘J3’, 200) INTO SPJ;

Эта операция должна сопровождаться обновлением значения атрибута TQt в соответствующем кортеже отношения P:

UPDATE (P WHERE Pnum = ‘P2’) TQt:= TQt + 200;

иначе будет нарушена целостность данных.

Если состояние БД до исполнения оператора INSERT было целостным, то и после исполнения оператора UPDATE оно окажется целостным.

Под транзакцией понимается выполняемая от имени определённого ID последовательность операций манипулирования данными, переводящая БД из целостного начального состояния в целостное конечное состояние. При этом промежуточные состояния БД не обязательно целостные.

Свойства транзакции

Атомарность и согласованность. Для того чтобы обеспечить целостность БД, система должна воспринимать транзакции как неделимые (атомарные) порции работы. Другими словами, транзакция не может быть выполнена частично. Если в процессе обработки транзакции возник какой-то сбой, то все выполненные до этого момента обновления данных должны быть отменены. Следовательно, транзакция ни в каком случае не может нарушить целостность данных.

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

Долговечность. Никакие необратимые изменения в физической базе данных не могут происходить до завершения транзакции. Говорят, что транзакция завершилась успешно, если в процессе исполнения не возникла какая-либо аварийная ситуация, и все проверки ограничений целостности дали положительный результат. В этом случае все произведённые обновления данных должны быть сохранены (зафиксированы) в ФБД.

Система гарантирует фиксацию обновлений успешно завершившейся транзакции даже в том случае, если в следующий момент времени произойдёт системный сбой. В случае неуспешного завершения транзакции по любой причине система гарантирует отсутствие каких-либо следов её работы в ФБД (откат транзакции).

Транзакция обладает свойством долговечности: обновления данных, произведённые успешно завершившейся транзакцией, становятся постоянными и не могут быть утеряны или отменены ни при каких обстоятельствах.

Изолированность. Многопользовательская система, как правило, одновременно поддерживает сеансы работы нескольких ID. Некоторые из них могут пытаться получить доступ к одним и тем же данным в одном и том же интервале времени. В связи с этим возникает проблема управления одновременным доступом к БД. Должна быть выбрана такая стратегия управления, которая обеспечивала бы «взаимную невидимость» пользователей.

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

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

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

Другими словами, изолированная транзакция А может получить доступ к объекту, обрабатываемому транзакцией B только после завершения В, и наоборот.

Определение транзакции

Подводя итог сказанному в п. 5.3.2, можем сформулировать следующее определение:

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

Для обозначения этого набора свойств часто используется русскоязычная аббревиатура АСИД или аналогичная англоязычная ACID.

Управление транзакциями

Под управлением транзакциями будем понимать действия системы, направленные на поддержание свойств АСИД.

Атомарность обеспечивается специальной подсистемой СУБД, которая называется диспетчером (администратором) транзакций.

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

BEGIN TRANSACTION;

сообщающее диспетчеру о том, что начинается новая транзакция.

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

COMMIT TRANSACTION;

сообщает диспетчеру, что транзакция завершилась успешно и результаты должны быть зафиксированы, а оператор

ROLLBACK TRANSACTION;

сообщает, что в процессе выполнения транзакции возникла ошибка и должен быть произведён откат.

Используя эти операторы, можно оформить обновление таблиц SPJ и P (см. п. 5.3.1) так:[2]

BEGIN TRANSACTION;

INSERT VALUES (‘S8’, ‘P2’, ‘J3’, 200) INTO SPJ;

IF ошибка THEN GO TO UNDO;

UPDATE (P WHERE Pnum = ‘P2’) TQt:= TQt + 200;

IF ошибка THEN GO TO UNDO;

COMMIT TRANSACTION;

GO TO FINISH;

UNDO: ROLLBACK TRANSACTION;

FINISH: RETURN;

Как видно из этого текста, оператор COMMIT выполняется лишь в том случае, когда оба обновления выполнены, и база данных приведена в новое согласованное состояние. Если же в процессе выполнения хотя бы одного обновления возникла ошибка, то все изменения в БД отменяются.

Замечание. Операции обновления РБД неэлементарны по определению, т.к. их операндами являются множества кортежей. Например, операция

UPDATE (S WHERE Ci = ‘Томск’) St = St * 2;

действует на все кортежи отношения S, содержащие значение ‘Томск’ в поле Ci.

Более того, операции обновления часто неявно затрагивают несколько связанных отношений в соответствии с объявленными правилами целостности. Например, если для отношения SPJ объявлено каскадное удаление внешнего ключа Snum, то операция

DELETE (S WHERE Ci = ‘Яя’);

неявно вызовет операцию

DELETE (SPJ WHERE NOT EXISTS S (SPJ.Snum = S.Snum));

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

Оператор обновления РБД порождает серию физических операций обновления элементов данных. Если в процессе выполнения этой серии произойдёт сбой, то система должна возвратить БД в начальное состояние, то есть система должна гарантировать атомарность отдельных операций обновления.

Поддержание согласованности обеспечивается механизмом проверки ограничений целостности. Можно выделить два вида ограничений целостности: немедленно проверяемые и откладываемые.

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

Откладываемые ограничения целостности – это ограничения, затрагивающие несколько отношений. Их называют ограничениями на базу данных. Примером может служить ограничение ссылочной целостности или ограничение на значения атрибута TQt (см. п. 5.3.1). Последнее неформально можно записать так: «Для каждого кортежа P значение атрибута TQt равно сумме значений атрибута Qt из всех тех кортежей SPJ, в которых SPJ.Pnum = P.Pnum.» Очевидно, это ограничение невозможно проверить, выполнив только одну операцию – вставку кортежа в отношение SPJ или обновление значения атрибута TQt. Подобные ограничения должны (и могут) быть проверены лишь после выполнения некоторой логически замкнутой группы операций обновления.

Таким образом, откладываемые ограничения, в отличие от немедленно проверяемых, соответствуют уровню транзакции. Подобные ограничения проверяются при завершении транзакции, точнее говоря, после того, как диспетчер транзакций примет оператор COMMIT. Их нарушение вызывает автоматическую отмену обновлений, т.е. замену COMMIT на ROLLBACK.

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

Используя механизм блокировок, можно добиться того, чтобы результат параллельного исполнения некоторой группы (независимых) транзакций был эквивалентен результату их последовательного исполнения в некотором порядке. Эффективность этого механизма зависит от того, какой смысл вложен разработчиками в понятие «объект блокировки» и какие типы блокировок поддерживаются.

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

На самом деле отдельная транзакция T практически никогда не использует все отношения БД. Обычно объектом обработки в конкретном интервале времени является некоторое подмножество кортежей C. Те транзакции, которым в этом интервале не нужны элементы C, вполне могут обрабатываться параллельно с T, т.е. их операторы могут чередоваться с операторами T в произвольном порядке. Более того, если две транзакции намерены только читать одно и то же множество кортежей, то нет никаких причин запрещать им это делать одновременно.

Реально между транзакциями T1 и T2 могут существовать следующие виды конфликтов доступа:

W-W – транзакция T2 пытается изменять объект, изменённый незакончившейся транзакцией T1;

R-W – транзакция T2 пытается изменять объект, прочитанный незакончившейся транзакцией T1;

W-R – транзакция T2 пытается читать объект, изменённый незакончившейся транзакцией T1.

Практические методы управления параллелизмом основываются на учете этих конфликтов. Наиболее часто используемые реализации механизма блокировок обсуждаются в п. 5.4.

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

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

Любые механизмы восстановления исходят из того, что результаты транзакций, зафиксированных до момента сбоя, должны быть сохранены в восстановленном состоянии БД, а результаты незафиксированных транзакций должны отсутствовать. Процедуры восстановления зависят от типа сбоя (см. п. 5.1). Мы обсудим их ниже в п. 5.5.