16.2. Избирательная схема управления доступом

Повторяя сказанное выше, следует еще раз отметить, что во многих СУБД поддер- живается либо избирательная, либо мандатная схема управления доступом, либо оба эти типа одновременно. Однако точнее все же будет сказать, что в действительности в большинстве СУБД поддерживается только избирательная схема доступа и лишь в не- которых— только мандатная. Поскольку на практике избирательная схема доступа встречается гораздо чаще, основное внимание в этой главе уделяется именно ей.

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

AUTHORITY SA3

GRANT RETRIEVE ( S#, SNAME, CITY ), DELETE ON S

TO Jim, Fred, Mary ;

/* Разрешить выборку атрибутов { Si, SNAME, CITY ) и удаление */ /* данных из таблицы поставщиков пользователям Джим, Фред и Мэри */

Этот пример иллюстрирует тот факт, что в общем случае полномочия доступа вклю- чают четыре компонента.

² В исходном варианте языка Tutorial D [3.3] не предусмотрено никаких средств определения полномочий, однако используемый в данном разделе гипотетический язык можно рассматривать как "выдержанный в духе " языка Tutorial D.

1. Имя (в данном примере— SA3). Устанавливаемые полномочия будут зарегистри- рованы в системном каталоге под этим именем.

2. Одна или более привилегий, задаваемых в предложении GRANT (в нашем примере это привилегия RETRIEVE (только для некоторых атрибутов) и привилегия DELETE).

3. Задаваемое в предложении ON имя переменной-отношения, к которой применя- ются полномочия (в нашем примере это переменная-отношение S).

4. Один или более имен пользователей (точнее, идентификаторов пользователей), которым предоставляются указанные привилегии по отношению к переменной- отношению, задаваемой с помощью фразы ТО.

Ниже приводится общий синтаксис оператора определения полномочий.

AUTHORITY <ит полномочие GRANT <список привилегии ON <ит переменной-отношения> ТО <список идентификаторов пользователей^ ;

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

RETRIEVE [ (<список имен атрибутов>) ] INSERT [ (<список имен атрибутов>) ] UPDATE [ (<список имен атри6утов>) ] DELETE ALL

Смысл привилегий RETRIEVE (выборка), INSERT (вставка), UPDATE (обновление) и DELETE (удаление) очевиден без дополнительных разъяснений³. Если при указании при- вилегии RETRIEVE определен список атрибутов, то она применяется только к заданным атрибутам. Списки имен атрибутов в определениях привилегий INSERT и UPDATE имеют тот же смысл. Спецификация ALL является сокращенной записью предоставления всех привилегий — RETRIEVE (по всем атрибутам), INSERT (по всем атрибутам), UPDATE (по всем атрибутам) и DELETE.

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

³ Хотя и не вполне, поскольку наличие привилегии RETRIEVE необходимо также в случае ссылки на некоторый объект (например, в определении представления или ограничения целост- ности), а не только для выполнения операции выборки.

Что произойдет, если пользователь попытается выполнить с объектом операцию, не имея на это необходимых полномочий? В простейшем случае достаточно просто отвергнуть эту попытку (конечно, предоставив пользователю соответствующее ди- агностическое сообщение). На практике такой вариант применяется наиболее часто, поэтому его можно понимать как используемый по умолчанию. Однако в более сложных ситуациях может оказаться полезным применить некоторое другое дейст- вие, например завершить выполнение программы или заблокировать клавиатуру пользователя. Также может иметь смысл фиксация всех подобных попыток в специ- альном журнале регистрации (т.е. проведение отслеживания угроз). Впоследствии эти данные могут оказаться полезным для выявления попыток обнаружения брешей

в системе защиты, а также следов возможного нелегального проникновения в систе- му (подробнее вопросы контрольного слежения за процессами в системе обсужда- ются в конце этого раздела).

Безусловно, необходимо также предусмотреть способ отмены существующих пол- номочий.

DROP AUTHORITY <имя полномочие ;

В частности, для нашего примера он может выглядеть следующим образом. DROP AUTHORITY SA3 ;

Для простоты изложения предположим, что при удалении некоторой переменной-от- ношения автоматически удаляются и все полномочия, предоставленные по отношению к ней.

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

1. AUTHORITY ЕХ1

GRANT RETRIEVE { Pi, PNAME, WEIGHT ) ON P

TO Jacques, Anne, Charley ;

Пользователи Jacques, Anne и Charley получают право доступа к указанному "вертикальному подмножеству" данных в базовой переменной-отношении Р. Таким об- разом, это пример предоставления полномочий, не зависящих от значения данных.

2. AUTHORITY ЕХ2

GRANT RETRIEVE, UPDATE (SNAME, STATUS), DELETE ON LS

TO Dan, Misha ;

Упоминаемая здесь переменная-отношение LS является представлением (представ- лением "поставщиков из Лондона"; см. рис. 9.4 в главе 9). Пользователи Dan и Misha получают доступ к "горизонтальному подмножеству" данных в базовой переменной- отношении S. Это пример предоставления полномочий, зависящих от значений данных. Обратите внимание, что хотя пользователи Dan и Misha могут удалить (DELETE) некоторые кортежи поставщиков (через представление LS), они не могут вставить (INSERT) их, а также не имеют права обновлять (UPDATE) атрибуты Si и CITY.

3. VAR SSPPR VIEW

(S JOIN SP JOIN (P WHERE CITY = 'Rome') { Pi } }

{ ALL BUT Pi, QTY } ;

AUTHORITY EX3 GRANT RETRIEVE ON SSPPR TO Giovanni ;

Это еще один пример полномочий, зависящих от значения данных: пользователь Giovanni получает доступ к информации о поставщиках, но только о тех, которые поставляют детали, хранящиеся в Риме.

4. VAR SSQ VIEW

SUMMARIZE SP PER S { SI } 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 () IN ('Mon', 'Tue', 'Wed', 'Thu', 'Fri')

AND NOW () > TIME '09:00:00'

AND NOW () < TIME '17:00:00' TO Purchasing ;

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

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

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

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

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

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

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

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

DEFINE PERMIT RETRIEVE ON P TO 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).

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

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

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

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

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

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

DEFINE PERMIT APPEND, RETRIEVE, REPLACE

ON S ( SI, CITY)

TO Joe

AT TTA4

FROM 9:00 TO 17:00

ON Sat TO Sun

WHERE S.STATUS < 50

AND S.SI = SP.Pl

AND SP.Pf = P.PI

AND P.COLOR = 'Red'

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

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

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

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

Метод контрольного слежения предусматривает использование особого файла или базы данных, в которую СУБД автоматически помещает сведения обо всех операциях, выполненных пользователями при работе с основной базой данных. В одних системах данные контрольного слежения могут физически записываться в файл системного журнала, используемого для восстановления (см. главу 14), в других системах эти све- дения помещаются в отдельный файл. В любом случае пользователям должен быть предоставлен механизм доступа к информации контрольного слежения, желательно с помощью средств обычного языка реляционных запросов (конечно, при условии, что эти запросы санкционированы!). Типичная запись в файле контрольного слежения может содержать такую информацию:

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

имя терминала, с которого была затребована операция;

имя пользователя, затребовавшего операцию;

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

переменные-отношения, кортежи и атрибуты, вовлеченные в процесс выполнения операции;

исходные значения измененных данных; новые значения измененных данных.

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