4. VAR SSQ VIEW

SUMMARIZE SP PER S { S# } ADD SUM (QTY) AS SQ ;

AUTHORITY EX4 GRANT RETRIEVE ON SSQ TO Fidel ;

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

5. AUTHORITY ЕХ5

GRANT RETRIEVE, UPDATE (STATUS) ON S

WHEN DAY 0 IN (Mon, Tue, Wed, Thu, Fri)

AND NOW 0 > TIME 09:00:00

AND NOW 0 < TIME 17:00:00 TO Purchasing ;

Здесь синтаксис определения полномочий расширен предложением WHEN, позволяющим задать некоторые контекстные элементы управления . Дополнительно предполагается, что система предоставляет две встроенные функции (получения названия текущего дня недели DAY() и текущего времени NOW{)), которые не имеют аргументов. Данное определение полномочий гарантирует, что значение статуса поставщика может быть изменено любым пользователем из группы Purchasing (работники отдела приема заказов) только в рабочие дни и в рабочее время. Это пример так называемого контекстно-зависимого полномочия, поскольку поступивший запрос на доступ будет или не будет нарушать установленные офаничения в зависимости от состояния контекста (в данном случае это комбинация дня недели и времени суток).

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

DATE() Возвращает текущую дату

USER() Возвращает идентификатор пользователя, выдавшего запрос TERMINAL () Возвращает идентификатор терминала, с которого поступил запрос

С концептуальной точки зрения несколько полномочий объединяются одно с другим по принципу связи логических утверждений с помощью оператора OR (Или). Иначе говоря, поступивший запрос на получение доступа (включаюший комбинацию запрашиваемой операции, запрашиваемого объекта и имени запрашивающего пользователя) принимается тогда и только тогда, когда он удовлетворяет хотя бы одному из существующих полномочий. Например, если в одном определении полномочий утверждается, что пользователю Nancy разрешается считывать сведения о цвете деталей, а в другом определении указывается, что этот же пользователь имеет право доступа к сведениям о весе деталей, это не значит, что ему разрешается считывать сведения о цвете и весе деталей одновременно (для этого пофебуется определить дополнительное полномочие).

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

Модификация запроса

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

DEFINE PERMIT RETRIEVE ON Р ТО U WHERE P.CITY = London

(Оператор DEFINE PERMIT будет подробно описан ниже.) Теперь предположим, что пользователь U вводит приведенный ниже запрос на языке QUEL.

RETRIEVE ( P.PI, P.WEIGHT ) WHERE P.COLOR = Red

Используя приведенное выще разрещение (PERMIT) для комбинации переменной-отнощения Р и пользователя U, сохраняемое в системном каталоге, СУБД INGRES автоматически преобразует приведенный выще запрос в запрос следующего вида.

RETRIEVE ( P.PI, P.WEIGHT ) WHERE P.COLOR = Red

AND P.CITY = London

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

Кратко описанный выще процесс модификации запроса полностью идентичен методу, используемому для реализации представлений [8.20], а также (особенно в случае прототипа системы Ingres) ограничений целостности [9.15]. Таким образом, важное преимущество данного подхода заключается в том, что его достаточно просто реализовать (в основном, благодаря тому, что необходимый для этого программный код уже присутствует в системе). Другое его преимущество - сравнительно высокая эффективность, так как увеличение накладных расходов (по крайней мере, частично), связанных с реализацией ограничений защиты, приходится на время компиляции, а не на время выполнения программы. Еще одно преимущество данного подхода состоит в

том, что при его использовании отсутствуют определенные неудобства, свойственные подходу, реализованному в языке SQL, когда для одного пользователя требуется задавать разные привилегии при обращении к разным частям одной и той же переменной-отношения (см. раздел 16.6).

Единственный недостаток этого подхода заключается в tOM, что не всем офаничениям зашиты можно придать столь простую форму. В качестве простейшего обратного примера предположим, что пользователю U запрещен доступ к переменной-отношению Р. Тогда любая достаточно простая модифицированная форма приведенного выше определения полномочий на выборку данных непременно создаст иллюзию, что переменной-отношения Р просто не сушествует. В результате система обязательно выдаст сообщение об ошибке приблизительно следующего содержания: Вам не разрешен доступ к указанной переменной-отношению . (Или, вероятно, система просто скроет истину и лукаво сообщит: Такой переменной-отношения не существует .)

В общем виде синтаксис оператора определения полномочий DEFINE PERMIT выглядит так.

DEFINE PERMIT <список названий операторов >

ON <имя переменной-отношения> [ ( <список имен атрибутов> ) ]

ТО <идентификатор пользователя> [ AT <список имен терминалов> ] [ FROM <времЯ> ТО <времЯ> ] [ ON <день> ТО <день> ] [ WHERE <логическое выражение> ]

Таким образом, концептуально синтаксис оператора определения полномочий DEFINE PERMIT очень похож на синтаксис оператора определения полномочий AUTHORITY, за исключением того, что он разрешает указание дополнительных условий в предложении WHERE. Ниже приведен пример подобного определения.

DEFINE PERMIT APPEND, RETRIEVE, REPLACE

Замечание. Операторы добавления (APPEND) и замены (REPLACE) являются аналогами операторов вставки (INSERT) и обновления (UPDATE) соответственно.

Контрольное слежение

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