Главная » SQL, Базы данных » ИЗБИРАТЕЛЬНАЯ СХЕМА УПРАВЛЕНИЯ ДОСТУПОМ

0

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

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

AUTHORITY SA3

GRANT RETRIEVE { S#, SNAME, CITY }, DELETE ON S

TO Jim, Fred, Mary ;

2 В современной версии языка Tutorial D [3.3] намеренно не предусмотрено никаких средств определения полномочий, однако используемый в данном разделе гипотетический язык можно рассматривать ка к   " выдер   ж анный   в ду х е "   яз ыка    T u t o r i a l   D .

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

1.  Имя (в данном примере SA3, "suppliers authority three" — полномочия поставщика с номером 3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.

2.  Одна или несколько привилегий, задаваемых в конструкции GRANT.

3.  Задаваемое в конструкции ON имя переменной отношения, к которой применяются полномочия.

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

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

AUTHORITY <authority name> GRANT  <privilege   commalist> ON <relvar name>

TO <user ID commalist> ;

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

RETRIEVE  [                                                                                {    <attribute name commalist>   }    ]   • INSERT  [  {                                                                                <attribute name commalist>    }    ] DELETE

UPDATE  [  {                                                                                <attribute name  commalist>    }    ] ALL

Смысл привилегий RETRIEVE (выборка, без уточнения), INSERT (вставка, без уточнения), DELETE (удаление) и UPDATE (обновление, без уточнения) очевиден без дополнительных пояснений (возможно, что это не совсем так; следует отметить, что привилегия RETRIEVE требуется также просто для указания соответствующего объекта, например, в определении представления или в  ограничении целостности, а также для выборки как таковой). Если с ключевым словом RETRIEVE задан разделенный запятыми список атрибутов <attribute  name  commalist>, то эта привилегия распространяется только на указанные атрибуты. Разделенные запятыми списки имен атрибутов в определениях привилегий INSERT и UPDATE имеют тот же смысл. Спецификация ALL является сокращенной записью предоставления всех привилегий — RETRIEVE (по всем атрибутам), INSERT (по вcем атрибутам), DELETE и UPDATE (по всем атрибутам).

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

отношения, а также определение и удаление самих полномочий). Подробное описание этих операций исключено для экономии места.

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

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

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

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

DROP  AUTHORITY  <authority name>   ;

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

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

1.          AUTHORITY  EX1

GRANT RETRIEVE ( Р#, PNAME, WEIGHT ) ON P

TO Jacques, Anne, Charley ;

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

2.          AUTHORITY  EX2

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

TO Dan, Misha ;

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

3.          VAR SSPPO VIEW

(S JOIN SP JOIN (P WHERE CITY = ‘Oslo’) { P# } )

{ ALL BUT P#, QTY } ;

AUTHORITY EX3

GRANT RETRIEVE ON SSPPO TO Lars ;

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

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   EX5

GRANT RETRIEVE, UPDATE    (STATUS) ON S

WHEN DAY () IN (‘Мои’,    ‘Tue’, ‘Wed’, ‘Thu’, ‘Fri’)

AND NOW () > TIME    ’09:00:00′

AND NOW () < TIME ’17:00:00”

TO  ACCOUNTING ;

Здесь  синтаксис  определения  полномочий  AUTHORITY  расширен  для  включения конструкции WHEN, позволяющей задать некоторые контекстные  элементы управления. Дополнительно предполагается, что в системе предусмотрены два нуль-арных оператора  (так  называются  операторы,  не   имеющие  явно  заданных  операндов), которые называются DAY() и NOW О и имеют очевидную интерпретацию. Определение полномочий ЕХ5 гарантирует, что значение статуса поставщика может быть изменено любым пользователем из  группы ACCOUNTING (работники бухгалтерского отдела) только в рабочие дни и в рабочее время. Это — пример так называемого контекстнозависимого полномочия, поскольку поступивший запрос на доступ будет или не будет нарушать  установленные  ограничения  в  зависимости  от  состояния   контекста   (в данном случае это комбинация дня недели и времени суток).

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

■     TODAY (). Возвращает текущую дату

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

■     TERMINAL (). Возвращает идентификатор терминала, с которого поступил запрос.

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

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

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

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

DEFINE PERMIT RETRIEVE ON P TO U WHERE P.CITY = "London"

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

RETRIEVE ( Р.Р#, P.WEIGHT ) WHERE                                        P.COLOR = "Red"

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

RETRIEVE ( Р.Р#, P.WEIGHT ) WHERE     P.COLOR = "Red" AND P.CITY = "London"

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

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

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

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

и сообщит: "Такой переменной отношения не существует".) Но самый лучший способ заключается в том, чтобы сообщить пользователю: "Либо такой переменной отношения

не существует, либо вы не имеете права доступа к ней".

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

DEFINE  PERMIT «operation name  commalist>

ON <relvar name>   [   (   <attribute name commalist>   )

] TO  <user ID>

[  AT <terminal  ID commalist>  ]

[  FROM <time> TO <time>  ]

[  ON <day> TO  <day>  }

[  WHERE  <bool  exp>  ]

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

DEFINE PERMIT RETRIEVE, APPEND, REPLACE ON S ( S#, CITY ) TO Joe AT TTA4

FROM 9:00 TO 17:00

ON Sat TO Sun

WHERE S.STATUS < 50

AND S.S# = SP.P#

AND SP.P# = P.P# AND P.COLOR = "Red"

Примечание.  Операторы  добавления  (APPEND) И  замены  (REPLACE) языка  QUEL

являются аналогами операторов вставки (INSERT) и обновления (UPDATE), соответственно.

Контрольный журнал

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

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

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

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

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

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

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

■     исходные значения изменяемых данных (старые значения);

■     модифицированные значения данных (новые значения).

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии