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

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

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

CREATE SECURITY RULE SR3

/* Создать правило безопасности SR3 */

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

/* Позволить обновление ( S#, SNAME, CITY ) и удаление */

ON S WHERE S, CITY <> 'London'

/* Для поставщиков не из Лондона */

ТО Jim, Fred, Mary

/* Для пользователей: Джим, Фред, Мери */

ON ATTEMPTED VIOLATION REJECT ;

/* He выполнять при нарушении этого правила */

В этом примере подчеркивается, что (в общем случае) правила безопасности об­ладают пятью компонентами.

1. Имя (например, SR3 — "suppliers rule 3" (правило поставщиков 3)). Правило бу­дет зарегистрировано в системном каталоге под этим именем. Это имя также, ве­роятно, появится в любом системном сообщении или сообщении о состоянии сис­темы в ответ на нарушение этого правила.

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

3. Диапазон, к которому это правило применяется, заданный с помощью директивы ON. В данном примере в качестве диапазона рассматриваются все кортежи по­ставщиков не из Лондона.

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

5. Реакция на нарушение правил, заданная директивой ON ATTEMPTED VIOLATION, сообщает системе, что делать, если пользователь нарушил правила безопасности. В дан­ном примере реакция на нарушение правил заключается в отказе выполнить запраши­ваемые действия (конечно, без предоставления какой-либо диагностической информа­ции). Такая реакция, очевидно, наиболее распространена в практических ситуациях, по­этому ее можно считать реакцией, принятой по умолчанию. Но вообще, с помощью про­цедуры может быть организована реакция самой произвольной сложности.

Ниже приводится полная синтаксическая запись правила безопасности (с исполь­зованием квадратных скобок для указания необязательных элементов).

CREATE SECURITY RULE правило

GRANT список_привилегий_через_запятую

ON выражение

ТО список_пользователей_через_запятую

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

Пояснения:

1. В приведенном выражении правило обозначает имя нового правила безопасности.

2. В качестве привилегий можно/ использовать одну из перечисленных ниже:

RETRIEVE [( список_атрибутов_через_запятую) ] INSERT

UPDATE [ (список_а1рибутов_через_запятую) ]

DELETE

ALL

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

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

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

5. Обозначение действие подразумевает процедуру произвольной сложности. Как упоминалось выше, по умолчанию принимается отказ в выполнении запрашиваемого действия. Однако в более сложных ситуациях может оказаться полезным применить другое действие; например, в некоторых случаях может потребоваться завершить выполнение программы или заблокировать клавиатуру пользователя. Также может быть полезно записать все происшедшие нарушения правил безо­пасности в специальном файле регистрации (т.е. выполнить так называемое отслеживание угроз). Это может быть нужно для выполнения последующего ана­лиза таких попыток, а также для предостережения против нелегального проникно­вения в данную систему. Более подробно вопросы контрольного следа выполняе­мых процессов обсуждаются немного ниже.

Конечно, в системе должен быть также предусмотрен способ устранения сущест­вующих правил безопасности:

DESTROY SECURITY BULB правило ;

Например, в некотором частном случае такое правило может иметь следующий вид:

DESTROY SECURITY RULE SR3 ;

Для простоты изложения предположим, что при удалении некоторого отношения бу­дут автоматически устранены все правила безопасности, связанные с этим отношением.

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

1. CREATE SECURITY RULE EX1

GRANT RETRIEVE ( S#, SNAME, CITY )

ON S

TO Jacques, Anne, Charley ;

Пользователи Jacques, Anne, Charley могут видеть "вертикальное подмножество", точнее, подмножество атрибутов или не зависящее от некоторого значения под­множество базового отношения S. Этот пример, таким образом, является приме­ром правила безопасности, характеризующегося независимостью от значения.

2. CREATE SECURITY RULE EX2

GRANT RETRIEVE, INSERT, UPDATE (SNAME, STATUS), DELETE

ON S WHERE S.CITY = 'Paris'

TO Dan, Misha ;

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

3. CREATE SECURITY RULE EX3

GRANT RETRIEVE

ON S WHERE EXISTS SP EXISTS P

(S.S# = SP.S# AND SP.P# = P.P# AND P.CITY = 'Rome')

TO Giovanni ;

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

4. CREATE SECURITY RULE EX4

GRANT RETRIEVE ( S#, SNAME ) ON S WHERE S.STATUS > 50

TO Judy, Paul ;

Атрибут STATUS используется здесь для указания диапазона, но он не виден пользователям (Judy и Paul), которые в лучшем случае всего лишь являются по­ставщиками со значением статуса больше 50.

5. Предположим, что SSQ является представлением, которое задается приведенным ниже способом. (В главе 3 реляционная алгебра использовалась в качестве основы для определения представлений. Здесь вместо алгебры используется исчисление, но всего лишь для определения правил безопасности.)

CREATE VIEW SSQ AS

( S.S#, SUM (SP WHERE SP.S# = S.S#, QTY) AS SQ ) ;

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

CREATE SECURITY RULE EX5

GRANT RETRIEVE

ON SSQ

TO Fidel ;

Таким образом, пользователь Fidel увидит статистический итог базового отноше­ния SP. (Обратите внимание, что методами обеспечения безопасности регулирует­ся как доступ к базовым отношениям, так и доступ к представлениям.).

6. Допустим, что SSS является представлением, которое задается следующим способом:

CREATE VIEW SSS AS

(S.S#, S.SNAME) WHERE S.STATUS > 50 ;

Тогда приведенное ниже правило будет похоже на правило из пункта 4:

CREATE SECURITY RULE EX6

GRANT RETRIEVE

ON SSS

TO Judy, Paul ;

Однако оно будет иметь другой эффект, поскольку в пункте 4 пользователи Judy и Paul могут непосредственно задавать запросы для базового отношения S, а в дан­ном примере это возможно только для представления SSS. Обратите внимание, что здесь (так же как и в предыдущем примере) представление использовано для сокрытия некоторой информации.

7. CREATE SECURITY RULE EX7

GRANT RETRIEVE, UPDATE (STATUS)

ON S

WHERE DAY () IN ('МОП', 'Tue', 'Wed', “Thu', 'Fri')

AND TIME () > TIME '9:00 am'

AND TIME () S TIME '5:00 рm'

TO Purchasing ;

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

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

DATE() — значение = текущая дата

USER() — значение = идентификатор текущего пользователя

TERMINAL() — значение = идентификатор терминала,

с которого поступил запрос

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

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

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

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

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

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

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

пользователь, задавший операцию;

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

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

старые значения;

новые значения.

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

// В некоторых системах контрольный след может физически сохраняться в файле восстановления данных (подробнее файл восстановления данных описан в главе 13), а в других системах — в отдельном файле. В лю­бом случае пользователи должны иметь возможность обращаться к контрольному следу с помощью традици­онного языка реляционных запросов (конечно, при условии, что эти запросы санкционированы!).//