    глава    15 
  
    Безопасность

    15.1. Введение 

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

    15.2. Общие соображения 

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

    394	Часть IV. Защита данных 

    В современных СУБД поддерживается один из двух широко распространенных 
подходов к вопросу обеспечения безопасности данных, а именно избирательный 
подход или обязательный подход. В обоих подходах единицей данных или "объектом 
данных", для которых должна быть создана система безопасности, может быть как 
вся база данных целиком или какой-либо набор отношений, так и некоторое 
значение данных для заданного атрибута внутри некоторого кортежа в 
определенном отношении. Эти подходы отличаются следующими свойствами: 
    •   В случае избирательного управления некий пользователь обладает 
различными правами (привилегиями или полномочиями) при работе с разными 
объектами. Более того, разные пользователи обычно обладают и разными правами 
доступа к одному и тому же объекту. Поэтому избирательные схемы 
характеризуются значительной гибкостью. 
    •   В случае обязательного управления, наоборот, каждому объекту данных 
присваивается некоторый классификационный уровень, а каждый пользователь 
обладает некоторым уровнем допуска. Следовательно, при таком подходе доступом 
к определенному объекту данных обладают только пользователи с соответствующим 
уровнем допуска. Поэтому обязательные схемы достаточно жестки и статичны. 
    Далее в этой главе будут подробно описаны вначале избирательные, а затем 
обязательные схемы. 
    Независимо от того, какие схемы используются —избирательные или 
обязательные, все решения относительно допуска пользователей к выполнению тех 
или иных операций принимаются на стратегическом, а не техническом уровне. 
Поэтому они находятся за пределами досягаемости самой СУБД, и все, что может в 
такой ситуации сделать СУБД, — это только привести в действие уже принятые 
ранее решения. Исходя из этого, можно отметить следующее: 
    1.   Результаты стратегических решений должны быть известны системе (т.е. 
выполнены на основе утверждений, заданных с помощью некоторого подходящего 
языка) и сохраняться в ней (путем сохранения их в каталоге в виде правил 
безопасности, которые также называются полномочиями). 
    2.  Очевидно, должны быть некоторые средства регулирования запросов 
доступа по отношению к соответствующим правилам безопасности. (Здесь под 
"запросом доступа" подразумевается комбинация запрашиваемой операции, 
запрашиваемого объекта и запрашивающего пользователя.) Такая проверка 
выполняется подсистемой безопасности СУБД, которая также называется 
подсистемой полномочий. 
    3.  Для того чтобы разобраться, какие правила безопасности к каким 
запросам доступа применяются, в системе должны быть предусмотрены способы 
опознания источника этого запроса, т.е. опознания запрашивающего пользователя. 
Поэтому в момент входа в систему от пользователя обычно требуется ввести не 
только его идентификатор (например, имя или должность), но также и пароль 
(чтобы подтвердить свои права на заявленные ранее идентификационные данные). 
Обычно предполагается, что пароль известен только системе и некоторым лицам с 
особыми правами. 
    В отношении последнего пункта стоит заметить, что разные пользователи 
могут обладать одним и тем же идентификатором некоторой группы. Таким образом, 
в системе могут поддерживаться группы пользователей и обеспечиваться 
одинаковые права доступа для пользователей одной группы, например для всех лиц 
из расчетного отдела. Кроме того, операции добавления отдельных пользователей 
в группу или их удаления из нее могут выполняться независимо от операции 
задания привилегий для этой группы. Обратите внимание, однако, что местом 
хранения информации о принадлежности к группе также является системный каталог 
(или, возможно, база данных). 

    Глава 15. Безопасность	395 


    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 список_привиле1ий_через_запятую ON       вьраженче 
    ТО       список_пользователей_через_запятую [ ON ATTEMPTED VIOLATION 
действие ]   ; 

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

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

    396 Часть IV. Защита данных 

    Привилегии извлечения RETRIEVE, вставки INSERT, обновления UPDATE и 
удаления DELETE очевидны без дополнительных разъяснений. (Хотя это утверждение 
не совсем верно. Привилегия извлечения RETRIEVE необходима для упоминания 
соответствующего объекта, например в определении представления или ограничении 
целостности, так же как и для самого извлечения. Эту привилегию, возможно, 
уместнее было бы назвать REFERENCE (упоминание), однако это название уже 
задействовано в описании ограничений целостности.) Если вместе с привилегией 
RETRIEVE задан список атрибутов, то она применяется только к заданным 
атрибутам. Привилегия UPDATE со списком атрибутов определяется аналогично. 
Спецификация ALL является сокращенной записью использования всех привилегий— 
RETRIEVE (со всеми атрибутами), INSERT, UPDATE (со всеми атрибутами) и DELETE. 
    3.  Обозначение выражение подразумевает выражение реляционного исчисления 
(или реляционной алгебры, хотя в данном случае для большей определенности 
используется термин "исчисление"), в котором задан диапазон данного правила. 
Один из объектов списка в этом выражении должен точно идентифицировать одну 
переменную диапазона, соответствующую точно одному отношению. Таким образом, 
диапазон правила безопасности всегда является некоторым подмножеством кортежей 
единственного отношения. (Поэтому, как уже обсуждалось в предыдущих главах, 
было бы удобно использовать некоторое сокращение для имени отношения. Оно 
могло бы также использоваться в качестве неявно заданного имени переменной 
диапазона для отношения с таким же именем. Такое сокращение было использовано 
в исходном примере, подобные ему сокращения будут использоваться и в других примерах.) 
    4.  Обозначение пользователь служит идентификатором некоторого 
пользователя, известного системе. Для него также может быть задана директива 
ALL (обозначающая всех известных пользователей). 
    5.  Обозначение действие подразумевает процедуру произвольной сложности. 
Как упоминалось выше, по умолчанию принимается отказ в выполнении 
запрашиваемого действия. Однако в более сложных ситуациях может оказаться 
полезным применить другое действие; например, в некоторых случаях может 
потребоваться завершить выполнение программы или заблокировать клавиатуру 
пользователя. Также может быть полезно записать все происшедшие нарушения 
правил безопасности в специальном файле регистрации (т.е. выполнить так 
называемое отслеживание угроз). Это может быть нужно для выполнения 
последующего анализа таких попыток, а также для предостережения против 
нелегального проникновения в данную систему. Более подробно вопросы 
контрольного следа выполняемых процессов обсуждаются немного ниже. 
    Конечно, в системе должен быть также предусмотрен способ устранения 
существующих правил безопасности: 

    DESTROY SECURITY RULE правило ; 

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

    DESTROY SECURITY RULE SR3 ; 

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

    1. CREATE SECURITY RULE EX1 
    GRANT RETRIEVE ( S#, SNAME, CITY ) 
    ON S 
    TO Jacques, Anne,  Charley ; 

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

    Глава 15. Безопасность 397 


    2. CREATE SECURITY ROLE EX2 
    GRANT RETRIEVE, INSERT, OPDATE (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 ЕХ4 
    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.St, 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. Обратите внимание, 
что здесь (так же как и в предыдущем примере) представление использовано для 
сокрытия некоторой информации. 

    398	Часть IV. Защита данных 


    7. CREATE SECURITY RULE EX7 
    GRANT RETRIEVE, UPDATE (STATUS) 
    ON    S 
    WHERE DAY () IN ('Mon1, 'Tue', 'Wed', 'Thu', 'Fri') 
    AND TIME () > TIME '9:00 am' 
    AND TIME () < TIME '5:00 pm' TO    Purchasing ; 

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

    DATEQ     — значение = текущая дата 
    USERQ     — значение = идентификатор текущего пользователя 
    TERMINALQ — значение = идентификатор терминала, с которого поступил запрос 

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

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

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

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

    Глава 15. Безопасность	399 

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

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

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

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

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

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

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

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

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

    400	Часть IV. Защита данных 

    предположим, что пользователю U не разрешен допуск к отношению Р. Тогда 
никакая простая "модифицированная" форма приведенного выше правила извлечения 
не будет избавлена от иллюзии, что отношения Р не существует. Наоборот, 
обязательно появится сообщение об ошибке приблизительно следующего содержания: 
"Вам не разрешен доступ к данному отношению". 
    В общем виде правила безопасности на языке QUEL формулируются с помощью 
синтаксиса на основе директивы DEFINE PERMIT: 

    DEFINE PERMIT	список_операторов_через_запятую 
    ON	отношение [   (слисок_атрибутов_через_3сэлятую)   ] 
    ТО	пользователь 
    [ AT	терминалы ] 
    [  FROM	время ТО время ] 
    [ ON	день ТО день ] 
    [ WHERE	условие ] 

    Таким образом, правило DEFINE PERMIT очень похоже на правило CREATE 
SECURITY RULE за исключением того, что вместо простого использования условий в 
директиве WHERE для контекстно-зависимого управления (например, для времени и 
даты) добавлены особые синтаксические директивы. Ниже приводится пример 
правила, построенного согласно заданному синтаксису: 

    DEFINE PERMIT APPEND, RETRIEVE, REPLACE 
    ON	S ( SNAME, CITY) 
    TO	Joe 
    AT	TTA4 
    FROM	9:00 TO 17:30 
    ON	Sat TO Sun 
    WHERE	S.STATUS < 50 
    AND	S.Sff = SP.Pt 
    AND	SP.Ptt = P.P# 
    AND	P. COLOR = "Red" 

    Операторы добавления APPEND и замены REPLACE аналогичны директивам вставки 
INSERT и обновления UPDATE соответственно. 
    Правила безопасности сохраняются в каталоге системы INGRES под числовыми 
идентификаторами (например, О, 1, 2 и т.д.). Эти идентификаторы можно 
обнаружить с помощью запроса к каталогу (для получения помощи предусмотрена 
специальная справочная команда HELP, хотя вместо нее может также 
использоваться обычный оператор извлечения RETRIEVE языка QUEL). Для 
устранения приведенного выше правила необходимо также прежде всего указать 
соответствующий идентификатор. Например, для идентификатора 27 это правило 
безопасности может быть устранено с помощью следующего утверждения: 

    DESTROY PERMIT S 27 


    15.5. Обязательное управление доступом 

    Методы обязательного управления доступом применяются к базам данных, в 
которых данные имеют достаточно статичную или жесткую структуру, свойственную, 
например, правительственным или военным организациям. Как уже отмечалось, 
основная идея заключается в том, что каждый объект данных имеет некоторый 
уровень классификации, например: секретно, совершенно секретно, для служебного 
пользования и т.д., а каждый пользователь имеет уровень допуска с такими же 
градациями, что и в уровне классификации. Предполагается, что эти уровни 
образуют строгий иерархический порядок, например: совершенно секретно > 
секретно > для служебного пользования и т.д. Тогда на основе этих сведений 
можно сформулировать два очень простых правила безопасности. 
    1.  Пользователь / имеет доступ к объекту у, только если его уровень 
допуска больше или равен уровню классификации объекта/ 
    2.  Пользователь / может модифицировать объекту, только если его уровень 
допуска равен уровню классификации объекта/ 

    Глава 15. Безопасность	401 

    Правило 1 достаточно очевидно, а правило 2 требует дополнительных 
разъяснений. Прежде всего следует отметить, что по-другому второе правило 
можно сформулировать так: любая информация, записанная пользователем /, 
автоматически приобретает уровень, равный уровню классификации /. Такое 
правило необходимо, например, для того, чтобы предотвратить запись секретных 
данных, выполняемую пользователем с уровнем допуска "секретно", в файл с 
меньшим уровнем классификации, что нарушает всю систему секретности. 
    В последнее время методы обязательного управления доступом получили 
широкое распространение. Дело в том, что согласно требованиям министерства 
обороны США (U.S. Department of Defense — DoD) в любой используемой в этом 
ведомстве системе должно поддерживаться обязательное управление доступом. 
Поэтому разработчикам и поставщикам СУБД пришлось вступить в соперничество за 
разработку методов такого управления. Сами требования к такому управлению 
изложены в двух важных публикациях министерства, которые неформально 
называются "оранжевой" книгой (Orange Book) [15.1] и "розовой" книгой 
(Lavender Book) [15.2]. В "оранжевой" книге перечислен набор требований к 
безопасности для некой "надежной вычислительной базы" (Trusted Computing Base 
— ТСВ), а в "розовой" книге дается интерпретация этих требований для систем 
управления базами данных. 
    Заданные в [15.1, 15.2] методы управления обязательным доступом на самом 
деле являются частью более общей классификации уровней безопасности, которые 
будут изложены здесь в очень краткой форме. Прежде всего в этих документах 
определяется четыре класса безопасности (security classes) — D, С, В и А. 
Среди них класс D наименее безопасный, класс С — более безопасный, чем класс 
D, и т.д. Говорят, что класс D обеспечивает минимальную защиту, класс С — 
избирательную, класс В — обязательную, а класс А — проверенную защиту. 
    •   Избирательная защита. Класс С делится на два подкласса— С1 и С2 (где 
подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают 
избирательное управление доступом в том смысле, что управление доступом 
осуществляется по усмотрению владельца данных (точно так же, как это было 
описано выше в этой главе). 
    • Согласно требованиям класса С1 необходимо разделение данных и 
пользователя, т.е. наряду с поддержкой концепции взаимного доступа к данным 
здесь возможно также организовать раздельное использование данных пользователями. 
    • Согласно требованиям класса С2 необходимо дополнительно организовать 
учет на основе процедур входа в систему, аудита и изоляции ресурсов. 
    •   Обязательная защита. Класс В содержит требования к методам 
обязательного управления доступом и делится на три подкласса— В1, В2 и ВЗ (где 
В1 является наименее, а ВЗ — наиболее безопасным подклассом). 
    • Согласно требованиям класса В1 необходимо обеспечить "отмеченную защиту" 
(это значит, что каждый объект данных должен содержать отметку о его уровне 
классификации, например: секретно, для служебного пользования и т.д.), а также 
неформальное сообщение о действующей стратегии безопасности. 
    • Согласно требованиям класса В2 необходимо дополнительно обеспечить 
формальное утверждение о действующей стратегии безопасности, а также 
обнаружить и исключить плохо защищенные каналы передачи информации. (Подробнее 
вопросы управления выводом обсуждаются в комментариях к [15.6].) 
    • Согласно требованиям класса ВЗ необходимо дополнительно обеспечить 
поддержку аудита и восстановления данных, а также назначение администратора 
режима безопасности. 
    •   Проверенная зашита. Класс А является наиболее безопасным и согласно 
его требованиям необходимо математическое доказательство того, что данный 
метод обеспечения безопасности совместимый и адекватен заданной стратегии 
безопасности (!). 

    402	Часть IV. Защита данных 

    Хотя некоторые коммерческие СУБД обеспечивают обязательную защиту на 
уровне класса В1, обычно они обеспечивают избирательное управление на уровне 
класса С2. 
    Терминология. СУБД, в которых поддерживаются методы обязательной защиты, 
часто называются системами с многоуровневой защитой [15.12, 15.15], а также 
надежными системами [15.17]. 

    15.6. Шифрование данных 

    Замечание. Большая часть изложенного в этом разделе материала впервые была 
опубликована в несколько иной форме в [15.4]. 
    До сих пор в этой главе подразумевалось, что предполагаемый нелегальный 
пользователь пытается незаконно проникнуть в базу данных с помощью обычных 
средств доступа, имеющихся в системе. Теперь следует рассмотреть случай, когда 
такой пользователь пытается проникнуть в базу данных, минуя систему, т.е. 
физически перемещая часть базы данных или подключаясь к коммуникационному 
каналу. Наиболее эффективным методом борьбы с такими угрозами является 
шифрование данных, т.е. хранение и передача особо важных данных в 
зашифрованном виде. 
    Для обсуждения основных концепций кодирования данных следует ввести 
некоторые новые понятия. Исходные (незакодированные) данные называются 
открытым текстом. Открытый текст шифруется с помощью специального алгоритма 
шифрования. В качестве входных данных для такого алгоритма выступают открытый 
текст и ключ шифрования, а в качестве выходных — зашифрованная форма открытого 
текста, которая называется зашифрованным текстом. Если детали алгоритма 
шифрования могут быть опубликованы или, по крайней мере, могут не утаиваться, 
то ключ шифрования обязательно хранится в секрете. Именно зашифрованный текст, 
который непонятен тем, кто не обладает ключом шифрования, хранится в базе 
данных и передается по коммуникационному каналу. 
    Пример. Пусть в качестве открытого текста дана следующая строка: 

    AS KINGFISHERS CATCH FIRE 

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

    ELIOT 

    с приведенным ниже алгоритмом шифрования. 
    1.  Разбейте открытый текст на блоки, длина которых равна длине ключа шифрования: 
    AS+KI NGFIS HERS+ CATCH +FIRE 
    (здесь пробелы обозначены знаком "+"). 
    2.  Замените каждый символ открытого текста целым числом в диапазоне 
00-26, используя для пробела число 00, для А — число 01, ..., для Z — число 
26. В результате получится строка цифр 
    0119001109 1407060919 0805181900 0301200308 0006091805 
    3.  Повторите этап 2 для ключа шифрования 
    0512091520 
    4.  Теперь значения для каждого символа в каждом блоке открытого текста 
(зашифрованного в пункте 2) просуммируйте с соответствующими значениями 
каждого символа ключа шифрования (зашифрованного в пункте 3), причем для 
каждой суммы таких двух значений посчитайте и запишите остаток от деления на 27: 
    0119001109	1407060919	0805181900 0301200308	0006091805 
    0512091520	0512091520	0512091520 0512091520	0512091520 
    0604092602	1919152412	1317000720 0813021801	0518180625 

    Глава 15. Безопасность	403 

    5.  Замените каждое число в нижней строке пункта 4 соответствующим 
текстовым символом: 

    FDIZB SSOXL MQ+GT HMBRA ERRFY 

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

    Стандарт шифрования данных 

    Приведенный выше пример основан на использовании процедуры подстановки: 
ключ шифрования применялся для того, чтобы определить, какой символ 
зашифрованного текста следует подставить вместо каждого символа открытого 
текста. Подстановка — один из двух основных традиционно используемых способов 
шифрования, в качестве второго выступает процедура перестановки, когда символы 
открытого текста просто переставляются в несколько иной последовательности. Ни 
один из этих способов не является безопасным сам по себе, но алгоритмы на 
основе их комбинации могут обеспечить достаточно высокую степень безопасности. 
Одним из таких алгоритмов является довольно общеизвестный стандарт шифрования 
данных (Data Encryption Standard —DES), который был впервые принят в качестве 
федерального стандарта США в 1977 году [15.3]. 
    Согласно этому стандарту открытый текст делится на блоки по 64 бита и 
каждый блок шифруется с помощью 64-битового ключа (в действительности этот 
ключ состоит из 56 бит данных плюс 8 бит четности, так что при этом существует 
не 264, а только 256 возможных ключей.) Сначала блок шифруется с помощью 
перестановки, затем уже перемешанный таким образом блок подвергается 
последовательности из 16 сложных шагов подстановки, и наконец, к нему еще раз 
применяется процедура перестановки, обратная начальной, которая и приводит к 
получению заключительного результата. Подстановка на /-м шаге контролируется 
непосредственно не исходным ключом шифрования К, а ключом Ki, который 
вычисляется на основе значений К и /. Более подробно этот материал излагается 
в [15.3]. 
    Стандартом шифрования данных предусматривается, что алгоритм расшифровки 
идентичен алгоритму шифрования за исключением того, что ключи Ki применяются в 
обратном порядке. 

    Шифрование на основе открытого ключа 

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

    404	Часть IV, Защита данных 

    рования, так и ключ шифрования, поэтому любой желающий может преобразовать 
открытый текст в зашифрованный. Однако в секрете хранится ключ расшифровки (в 
методике открытого ключа используется два ключа: один для шифрования, другой 
для расшифровки). Более того, ключ расшифровки не может быть просто выведен из 
ключа шифрования, поэтому лицо, выполнившее шифрование исходного текста, не 
сможет расшифровать его без специального разрешения. 
    Первоначальная идея использования такой методики принадлежит Диффи и 
Хельману (Diffie and Hellman) [15.7], однако здесь для демонстрации этой 
методики будет описан подход, развитый Райвестом, Шамиром и Адлеманом (Rivest, 
Shamir, Adleman) [15.14]. В основе этого подхода, названного по первым буквам 
их фамилий RSA-схемой, лежит два приведенных ниже факта. 
    1. Существует быстрый алгоритм определения, является ли данное число простым. 
    2.  Не существует быстрого алгоритма разложения данного составного числа 
(т.е. числа, которое не является простым) на простые множители. 
    В [15.10] приведен пример, в котором для определения, является ли данное 
число из 130 цифр простым числом, потребовалось 7 минут вычислений на 
некотором компьютере, тогда как для поиска (на том же компьютере) двух простых 
множителей числа, получаемого умножением двух простых чисел, состоящих из 63 
цифр, потребуется около 40 квадрильонов лет (1 квадрильон = 1 000 000 000 000 000). 
    RSA-схема включает приведенную ниже последовательность действий. 
    1.  Выберите два произвольных и разных больших простых числа р и q, а 
затем вычислите их произведение r=p*q. 
    2.  Выберите произвольное большое целое число е, которое является взаимно 
простым по отношению к произведению (р-\) * (<7—1), а также служит ключом шифрования. 
    Замечание. Выбрать число е достаточно просто: например, для него подойдет 
любое простое число, которое больше чисел/? и q. 
    3.  Выберите в качестве ключа расшифровки число d, которое является 
"обратным относительно умножения" на е по модулю (р-1) * (<?-!), т.е. такое 
число, для которого выполняется соотношение 
    d * е = 1 modulo  (р - 1)   *   (д - 1). 
    Алгоритм вычисления d для заданных чисел е, р и q достаточно прост и 
полностью приведен в [15.14]. 
    4.  При этом могут быть преданы огласке числа г и е, но не d. 
    5.  Для шифрования части открытого текста Р (который для простоты 
рассматривается как целое число, меньше /•) замените его зашифрованным текстом 
согласно формуле 
    С = f modulo r. 
    6.  Для расшифровки части зашифрованного текста С замените его открытым 
текстом согласно формуле 
    Р = Cd modulo r. 
    В [15.14] доказывается работоспособность этой схемы, т.е. возможность 
расшифровки текста С с использованием числа d для восстановления исходного 
открытого текста Р. Однако, как упоминалось ранее, вычисление d для известных 
чисел г и е (а не р и q} практически неосуществимо. Поэтому любой пользователь 
может зашифровать открытый текст, но только пользователи с санкционированным 
доступом (обладающие числом d) могут расшифровать зашифрованный текст. 
    Для иллюстрации этого метода следует рассмотреть приведенный ниже простой 
пример, в котором по очевидным причинам используются только малые целые числа. 
    Пример. Пусть р = 3, q = 5, тогда г = 15, а произведение (р— 1) * (q-\) — 
8. Пусть е = 11 (простое число, большее/? и q). Вычисляя d согласно формуле 

    Глава 15. Безопасность	405 

    d * 11 = 1 modulo 8, получим d=3. 
    Теперь допустим, что открытый текст Р состоит из целого числа 13, тогда 
зашифрованный текст С будет иметь следующий вид: 
    С = F modulo r = 1311 modulo 15 = 1,792,160,394,037 modulo 15 = 7 
    А исходный открытый текст Р может быть получен с помощью обратной процедуры: 
    Р = Cd modulo r = 73 modulo 15 = 343 modulo 15 = 13 
    Поскольку числа е и d взаимно обратны, то в методах шифрования на основе 
открытого ключа также можно "подписывать" сообщения, чтобы получатель был 
уверен в том, что сообщение получено именно от того лица, которым оно 
отправлено (т.е. такая "подпись" не может быть подделана). Допустим, что 
пользователи А и В общаются друг с другом с помощью метода шифрования на 
основе открытого ключа. Пусть они предали гласности по одному алгоритму 
шифрования (с включением в каждом из них соответствующего ключа шифрования), 
но хранят в секрете друг от друга алгоритм и ключ расшифровки. Например, пусть 
алгоритмы шифрования А и В названы соответственно АША и АШВ, а соответствующие 
алгоритмы расшифровки — АРА и АРВ. Следует отметить, что алгоритмы шифрования 
и расшифровки АША и АРА, так же как и алгоритмы АШВ и АРВ, являются взаимно обратными. 
    Теперь предположим, что пользователь А хочет послать часть открытого 
текста Р пользователю В. Вместо вычисления результата АШВ(Р) и отправки его 
пользователю В, пользователь А применяет для открытого текста Р сначала 
алгоритм расшифровки АРА, а затем зашифровывает результат и в зашифрованном 
виде С передает его: 
    С = АШВ   ( АРА   (   Р )   ). 
    После получения зашифрованного текста С пользователь В применяет алгоритм 
расшифровки АРВ, а затем алгоритм шифрования АША с получением в результате 
части открытого текста Р: 
    АША ( АРВ ( С ) ) 
    = АША ( АРВ ( АШВ ( АРА ( Р ) ) ) ) 
    = АША ( АРА ( Р ) ) — поскольку АШВ и АРВ взаимно исклкнают друг друга 
    = Р	— поскольку АРА и АША взаимно исклкнают друг друга 
    Таким образом, пользователь В знает, что полученное им сообщение 
действительно пришло от пользователя А, поскольку алгоритм шифрования АША 
приведет к получению результата Р, только если в процессе шифрования 
использовался алгоритм расшифровки АРА. Причем никто, даже пользователь В, не 
сможет подделать подпись пользователя А. 

    15.7. Поддержка мер обеспечения безопасности в языке SQL 

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

    406	Часть IV. Защита данных 


    Представления и безопасность 

    Продемонстрируем использование представлений для обеспечения безопасности 
с помощью описанных на языке SQL примеров 1-5, аналогичных приведенным в 
разделе 15.3. 

    1. CREATE VIEW EX1 AS SELECT S.S#, S.SNAME, S.CITY FRCM S ; 

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

    GRANT SELECT ON ЕХ1 Jacques, Anne, Charley ; 

    Здесь следует указать на одно явное различие между языком SQL и 
гипотетической схемой, описанной в разделе 15.3. Поскольку правила 
безопасности заданы на основе директивы GRANT, а не с помощью CREATE RULE, 
этим правилам в SQL не присваиваются имена. (Хотя в стандарте языка SQL 
правилам целостности, наоборот, предусмотрено присвоение имен. Подробнее это 
описано в главе 16.) 

    2. CREATE VIEW EX2 AS 
    SELECT S.S#, S.SNAME, S.STATUS, S.CITY 
    FRCM  S 
    WHERE S.CITY = 'Paris' ; 

    Соответствующее предоставление привилегий задается с помощью следующей 
директивы GRANT: 

    GRANT SELECT, INSERT, UPDATE ( SNAME, STATUS ), DELETE Ш ЕХ2 TO Dan, Misha ; 

    3. CREATE VIEW EX3 AS 
    SELECT S.S#, S.SNAME, S.STATUS, S.CITY FROM  S WHERE EXISTS 
    ( SELECT * FRCM SP WHERE EXISTS 
    ( SELECT * FROM P WHERE S.S# = SP.Stt AND   SP.P# = P.P# AND   P.CITY = 
'Rome') ) ; 

    Соответствующее предоставление привилегий задается с помощью приведенной 
ниже директивы GRANT: 

    GRANT SELECT ON EX3 TO Giovanni  ; 

    4.    CREATE VIEW EX4  AS 
    SELECT  S.S#,   S.SNAME 
    FROM       S 
    WHERE     S.STATUS  >  50   ; 

    Соответствующее предоставление привилегий задается с помощью директивы GRANT: 

    GRANT SELECT ON EX4 TO Judy, Paul ; 
    5. CREATE VIEW SSQ AS 
    SELECT S.S#, ( SELECT SUM (SP.OTY) 
    FRCM SP 
    WHERE SP.Stt = S.S#   )   AS SQ FRCM S  ; 

    Соответствующее предоставление привилегий задается с помощью директивы GRANT: 

    GRANT SELECT ON SSQ TO Fidel ; 

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

    Глава 15. Безопасность	407 

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

    Директивы GRANT и REVOKE 

    Механизм представлений языка SQL позволяет различными способами разделить 
базу данных на части таким образом, чтобы очень важная информация была скрыта 
от несанкционированных пользователей. Однако этот режим задается не с помощью 
параметров операций, на основе которых санкционированные пользователи 
выполняют те или иные действия с заданной частью данных. Эта функция (как было 
показано выше) выполняется с помощью директивы GRANT. 
    Обратите внимание, что создателю любого объекта автоматически 
предоставляются все привилегии в отношении этого объекта. Например, создателю 
таблицы В автоматически разрешается выбирать (SELECT), вставлять (INSERT), 
обновлять (UPDATE), удалять (DELETE) и ссылаться (REFERENCES) на таблицу В 
(ниже эти привилегии разъясняются подробнее). Более того, эти привилегии в 
каждом случае даются "с предоставлением санкции", т.е. они могут быть 
предоставлены какому-нибудь другому пользователю. 
    Ниже приводится синтаксис утверждения GRANT: 
    GRANT список_прив11лепт_через_запятую ON объект ТО 
список_пользователей_через_запятую ( WITH GRANT OPTION ]   ; 
    Пояснения: 
    •  Среди допустимых привилегий могут содержаться операции использования 
(USAGE), выбора (SELECT), вставки (INSERT), обновления (UPDATE), удаления 
(DELETE) и ссылки (REFERENCES). Привилегия USAGE необходима для указания 
использования некоторого заданного домена, привилегия REFERENCES — для 
обращения в ограничениях целостности к специально заданной таблице. Роль 
других привилегий очевидна. Однако следует отметить, что привилегии вставки 
(INSERT) и обновления (UPDATE) (но не привилегии выбора (SELECT), что весьма 
странно) могут задаваться для специально заданных столбцов. 
    •   В качестве объекта можно использовать следующее выражение: 

    DOMAIN domain [ TABLE ] table 

    В данном контексте — в отличие от других случаев, встречающихся в языке 
SQL, — ключевое слово TABLE относится как к представлениям, так и к таблицам. 
    •   Список пользователей, разделенных запятыми, может быть заменен 
ключевым словом PUBLIC, которое означает всех пользователей, известных системе. 
    •   Если задана директива WITH GRANT OPTION, это значит, что указанные 
пользователи наделены особыми полномочиями для заданного объекта— правом 
предоставления полномочий. Это, в свою очередь, означает, что для работы с 
данным объектом они могут наделять полномочиями других пользователей. Конечно, 
директива WITH GRANT OPTION может быть задана, только если пользователь, 
задающий утверждение GRANT, обладает необходимыми полномочиями. 
    Если пользователь А наделяет некоторыми полномочиями другого пользователя 
В, то впоследствии он может отменить эти полномочия для пользователя В. Отмена 
полномочий выполняется с помощью директивы REVOKE с приведенным ниже синтаксисом. 
    REVOKE  [ GRANT OPTION TOR ] список_привилеп1Й_ч?рез_запятую ON объект 
FROM список_пользователей_через_запятую параметр; 

    408	Часть IV. Защита данных 

    Здесь директива GRANT OPTION FOR означает, что отменяются только 
полномочия, назначаемые (передаваемые) другим пользователям; список привилегий 
и список пользователей используются так же, как и в утверждении GRANT, а в 
качестве параметра используется либо RESTRICT, либо CASCADE. Ниже приведены 
некоторые примеры использования этого выражения. 
    1. REVOKE SELECT ON EX1 FROM Jacques, Дппе, Charley RESTRICT ; 
    2. REVOKE SELECT, INSERT, UPDATE (SNAME, STATUS), DELETE ON EX2 FROM Dan, 
Misha CASCADE ; 
    3. REVOKE SELECT ON EX3 FRCM Giovanni RESTRICT ; 
    4. REVOKE SELECT ON EX4 FRCM Judy, Paul CASCADE ; 
    5. REVOKE SELECT ON SSQ FROM Fidel RESTRICT ; 
    Параметры RESTRICT и CASCADE. Допустим, что р является некоторой 
привилегией для некоторого объекта и пользователь А передает р пользователю В, 
который, в свою очередь, передает ее пользователю С. Что произойдет, если 
пользователь А теперь отменит привилегию р для пользователя В? Если эта отмена 
состоится, то привилегия р для пользователя С останется "покинутой", поскольку 
она была производной от привилегии р пользователя В, который уже не обладает 
ею. Основное предназначение параметров RESTRICT и CASCADE заключается в 
предотвращении ситуаций с возникновением покинутых привилегий. Благодаря 
заданию параметра RESTRICT не разрешается выполнять операцию отмены 
привилегии, если она приводит к появлению покинутой привилегии. Параметр 
CASCADE указывает на последовательную отмену всех привилегий, производных от данной. 
    Наконец, при удалении домена, таблицы, столбца или представления 
автоматически будут удалены также и все привилегии в отношении этих объектов 
со стороны всех пользователей. 

    15.8. Резюме 

    В это'й главе рассматривались различные аспекты проблемы безопасности базы 
данных. Во введении были показаны различия между понятиями безопасности и 
целостности. Так, под безопасностью подразумевается, что санкционированным 
пользователям разрешается выполнять необходимые действия, а под целостностью — 
корректность этих действий. Иначе говоря, безопасность включает защиту данных 
от несанкционированного доступа, изменения или разрушения. 
    Безопасность обеспечивается подсистемой безопасности СУБД, которая 
проверяет соответствие всех запросов правилам безопасности, хранимым в 
системном каталоге. Сначала рассматривались избирательные схемы, в которых 
доступ к заданному объекту определялся владельцем объекта. Для каждого правила 
безопасности в избирательной схеме задается имя, множество привилегий 
(RETRIEVE, UPDATE и т.д.), диапазон (в основном данные, к которым применяются 
эти правила, задаются с помощью специального условного выражения), множество 
пользователей и реакция на нарушение правил безопасности (обычно это просто 
операция отмены REJECT). Такие правила могут использоваться для обеспечения 
зависящего от конкретного значения управления, не зависящего от конкретного 
значения управления, контекстно-зависимого управления. Контрольный след 
выполняемых операций может использоваться для регистрации попыток 
несанкционированного проникновения сквозь систему безопасности. В данной главе 
было представлено краткое описание ме тода воплощения таких правил на основе 
модификации запроса, который был впервые применен в системе INGRES на базе 
языка QUEL. 
    Затем кратко рассматривались методы обязательного управления, согласно 
которым каждый объект обладает уровнем классификации и каждый пользователь 
имеет уровень допуска. Помимо описания правил безопасности для такой схемы, 
также кратко рассматривалась классификация мер безопасности, 
регламентированная министерством обороны США [15.1, 15.2]. 

    Глава 15. Безопасность	409 

    Затем были описаны методы шифрования данных на основе подстановок и 
перестановок, а также приведены разъяснение стандарта шифрования данных и 
краткое описание методов шифрования на основе открытого ключа. В частности, 
был представлен простой пример RSA-схемы на основе простых чисел. Кроме того, 
была описана концепция применения цифровых подписей. 
    После этого были кратко описаны меры безопасности, которые поддерживаются 
в стандарте языка SQL, в частности использование представлений для сокрытия 
информации, а также применение директив GRANT и REVOKE для управления тем, 
какие привилегии заданы, каким пользователям и для каких объектов (домены, 
таблицы, представления). 
    В заключение, вероятно, стоит отметить, что от большого количества мер 
безопасности в СУБД не будет никакого толку, если их легко преодолеть. 
Например, в системе DB2 фирмы IBM меры безопасности были бы совершенно 
бесполезны, если бы было возможно осуществить доступ к данным системы DB2 с 
помощью обычной программы системы MVS на основе запросов VSAM (дело в том, 
что, как будет показано далее в этой книге, данные системы DB2 физически 
хранятся в файлах формата VSAM). Поэтому система DB2 находится в полной 
гармонии с другими совместимыми системами, например MVS и VSAM, причем с 
полным соблюдением мер безопасности. Хотя подробное изложение этого вопроса 
выходит за рамки данной главы, эту особенность все же стоит упомянуть. 

    Упражнения 

    15.1. Базовое отношение STATS выглядит следующим образом: 
    STATS (USERID, SEX, DEPENDENTS, JOB, SALARY, TAX, AUDITS) PRIMARY KEY (OSERID) 
    Используя гипотетический язык, представленный в разделе 15.3, запишите 
правила безопасности для перечисленных ниже привилегий: 
    а) пользователь Ford обладает правом извлечения целого отношения; 
    б) пользователь    Smith    обладает   правом    вставки    и   удаления   
 целого отношения; 
    в) каждый пользователь обладает правом извлечения только своего 
собственного кортежа; 
    г) пользователь Nash обладает правом извлечения целого отношения и 
обновления только атрибутов SALARY и TAX; 
    д) пользователь Todd обладает правом извлечения только атрибутов USERID, 
SALARY и TAX; 
    е) пользователь Ward обладает таким же правом извлечения, что и 
пользователь Todd, а также правом обновления только атрибутов SALARY и TAX; 
    ж) пользователь Pope обладает всеми  правами  (извлечения,  обновления, 
вставки и удаления) только для всех кортежей проповедников; 
    з) пользователь Jones обладает правом удаления кортежей для лиц, 
выполняющих работу общего характера, т.е. такую, которая выполняется более чем 
10 лицами; 
    и) пользователь King обладает правом извлечения данных о минимальной и 
максимальной зарплате для работы заданного класса. 
    15.2. Рассмотрите, как следует расширить синтаксис утверждения CREATE 
SECURITY RULE для включения в него управления такими операциями, как создание 
(CREATE BASE RELATION) и удаление базового отношения (DESTROY BASE RELATION), 
создание (CREATE VIEW) и удаление представления (DESTROY VIEW), создание 
(CREATE SECURITY RULE) и удаление правила безопасности (DESTROY SECURITY RULE) 
и т.д. 

    410	Часть IV. Защита данных 

    15.3. Расшифруйте приведенный ниже зашифрованный текст, созданный в стиле, 
подобном тому, который был использован в примере этой главы со строкой AS 
KINGFISHERS CATCH FIRE, но с использованием другого 5-символьного ключа шифрования. 
    FNWAL JPVJC FPEXE ABWNE AYEIP SUSVD 
    15.4. Испытайте RSA-схему шифрования на основе открытого ключа с р = 7, q 
= 5 и е = 17 для открытого текста Р = 3. 
    15.5. Какие проблемы могут возникнуть при использовании шифрования? 
    15.6. Используя язык SQL, запишите решения для упр. 15.1. 
    15.7. Запишите утверждения SQL для удаления привилегий, заданных в решении 
для предыдущего упражнения. 

    Список литературы 

    Обширный обзор по методам обеспечения безопасности представлен в [15.9], а 
более подробное техническое описание этой темы — в [15.5]. Остальные 
приведенные здесь ссылки указывают на технические документы, статьи, учебные 
пособия и научно-исследовательские работы по различным аспектам проблемы 
обеспечения безопасности. 
    15.1. U.S. Department of Defense. Trusted Computer System Evaluation 
Criteria ("оранжевая" книга). — DoD National Computer Security Center, 1985. 
    15.2. U.S. Department of Defense. Trusted Database Management System 
Interpretation ("розовая" книга). — DoD National Computer Security Center, 1991. 
    15.3. U.S. Department of Commerce/National Bureau of Standards. Data 
Encryption Standard. — Federal Information Processing Standards Publication 
46, 1977. В работе дано определение официального стандарта шифрования данных 
(Data Encryption Standard — DES), используемого как федеральными учреждениями 
США, так и всеми желающими. Этот алгоритм шифрования/расшифровки используется 
на аппаратном уровне, например в микропроцессоре. При этом устройства с таким 
микропроцессором демонстрируют весьма высокую интенсивность обмена данными. В 
настоящее время существует несколько таких коммерческих устройств. 
    15.4. Date. C.J. Security // С. J. Date. An Introduction to Database 
Systems: Volume II.— Reading. Mass.: Addison-Wesley, 1983. 
    15.5. Denning D.E. Cryptography and Data Security. — Reading, Mass.: 
Addison-Wesley, 1983. 
    15.6. Denning D.E., Denning P.J. Data Security // ACM Сотр. Surv. — 1979. 
— 11, № 3. 
    Прекрасное учебное пособие, посвященное методам обеспечения безопасности с 
описанием избирательных и обязательных методов управления доступом (здесь они 
называются методами управления потоком), методов шифрования данных и 
управления выводом (эта проблема характерна для статистических баз данных). 
Здесь стоит несколько подробнее остановиться на последней из перечисленных 
выше проблем. Статистической базой данных (в излагаемом здесь контексте) 
называется база данных, в которой допускаются запросы для вывода некоторой 
итоговой информации (например, сумм и средних значений), но не допускаются 
запросы для вывода индивидуальной информации. Например, в такой базе данных 
запрос "Какова средняя зарплата программистов?" будет разрешен, а запрос 
"Какую зарплату получает программист Петров?" — нет. 
    Основная проблема такой базы данных заключается в том, что в ней на основе 
двух допустимых запросов можно сформировать недопустимый запрос. В качестве 
примера ниже приводится два допустимых запроса. 

    Глава 15. Безопасность	411 

    1.  Сколько существует программистов в возрасте между 25 и 30 годами, 
которые проживают в Смоллвилле и получили образование в области современных 
языков программирования в университете Метрополиса? 
    2.  Какова средняя зарплата программистов в возрасте между 25 и 30 годами, 
которые проживают в Смоллвилле и получили образование в области современных 
языков программирования в университете Метрополиса? 
    Если два этих запроса сформировать в один и результатом первой части 
запроса (первого вопроса) будет " 1", то вторая часть запроса будет 
недопустима (поскольку на нее должна быть выдана точная зарплата данного 
программиста). Более подробные пояснения по данной проблеме приводятся в [15.4]. 
    15.7. Diffe W., Hellman M.E. New Directions in Cryptography // IEEE Trans. 
on Information Theory. — 1976. — IT-22. 
    В статье излагаются теоретические основы для так называемых схем 
шифрования на основе открытого ключа. Как разъясняется в этой главе, в обычных 
схемах шифрования, например в стандарте шифрования данных DES [15.3], ключ 
шифрования держится в секрете. В схеме с открытым ключом, наоборот, 
используется два различных ключа: один для шифрования, другой для расшифровки. 
Причем в секрете держится только ключ расшифровки, а вывести его из ключа 
шифрования невозможно. Следовательно, в таких схемах каждый может создавать 
зашифрованные сообщения, но никто, кроме получателя, не может расшифровать его 
(даже создатель этого сообщения). 
    15.8. Fagin R. On an Authorization Mechanism // ACM TODS. — 1978. — 3, № 3. 
    Подробное изложение поправки к [15.11] о некоторых условиях, способных 
привести к отмене привилегии, которую нельзя отменить с помощью механизма, 
описанного в [15.11]. 
    15.9. Fernandez E.B., Summers R.C., Wood С. Database Security and 
Integrity.— Reading, Mass.: Addison-Wesley, 1981. 
    15.10. Gardner M. A New Kind of Cipher That Would Take Millions of Years 
to Break // Scientific American. — 1977. — 237, № 2. 
    15.11. Griffiths P.P., Wade B.W. An Authorization Mechanism for a 
Relational Data Base System //ACM TODS. — 1976. — 1, № 3. 
    Описание механизмов предоставления (GRANT) и отмены (REVOKE) привилегий, 
впервые предложенных для системы System R. Эта схема в несколько измененном 
виде теперь включена в основу стандарта языка SQL. 
    15.12. Jajodia S., Sandhu R. Toward a Multilevel Secure Relational Data 
Model // Proc. 1991 ACM SIGMOD Intern. Conf. on Management of Data. — Denver, 
Col., 1991. 
    Как объяснялось в этой главе, "многоуровневая структура" в контексте 
системы безопасности относится к системе, в которой поддерживаются методы 
обязательного управления доступом. В статье сделано утверждение о том, что вся 
текущая деятельность в этой области в основном выполняется спонтанно, 
поскольку не существует единого мнения в отношении основных концепций. Кроме 
того, в этой работе подчеркивается необходимость положить начало формальным 
принципам многоуровневых систем. Эти вопросы являются более тонкими, чем может 
показаться на первый взгляд. Например, предположим, что некоторому 
пользователю не положено знать о существовании некоторых поставщиков 
(например, поставщиков со статусом выше 20). В таком случае предоставление 
пользователю возможности организовать представление базового отношения S, из 
которого исключены такие поставщики, могло бы прийти в противоречие с фактом 
существования таких поставщиков. Дело в том, что попытка вставить данные о 
новом поставщике в это представлени е может закончиться неудачно, если он 
имеет такой же номер, которым уже обладает некоторый скрытый поставщик. 

    412	Часть IV. Защита данных 

    15.13. Lempel A. Cryptology in Transition // ACM Сотр. Surv. — 1979.— 11, 
№4 (Special Issue on Cryptology). 
    Прекрасное учебное пособие по шифрованию и связанным с этой темой вопросам. 
    15.14. Rivest R.L., Shamir A., Adleman L. A Method for Obtaining Digital 
Signatures and Public-Key Cryptosystems // CACM. — 1978. —21, № 3. 
    15.15. Smith K., Winslett M. Entity Modeling in the MLS Relational Model 
// Proc. 18th Intern. Conf. on Very Large Data Bases. — Vancouver, Can., 1992. 
    Сокращение MLS в заголовке статьи обозначает "многоуровневую защиту" 
("multilevel secure" — MLS). В статье сделано ударение на значении баз данных 
с такой защитой и предлагается директива нового типа (BELIEVED BY) для 
указания операций извлечения и обновления по отношению к некоторому особому 
состоянию базы данных, которое воспринимается или "принимается [как точно 
соответствующее]" некоторым пользователем. В статье сделано утверждение, что 
этот подход поможет разрешить несколько проблем, существовавших при 
использовании прежних подходов. 
    15.16. Stonebraker M.R., Wong E. Access Control in a Relational Data Base 
Management System by Query Modification // Proc. ACM National Conference. — 1974. 
    В статье впервые предложен механизм модификации запросов на основе системы 
INGRES (здесь используется термин "query modification"). 
    15.17. Thuraisingham В.  Current Status of R&D in Trusted Database 
Management Systems // ACM SIGMOD. — 1992. —21, № 3. 
    Краткий обзор и обширный набор ссылок на работы о "надежных" или 
многоуровневых системах. 

    Ответы к некоторым упражнениям 

    15.1. a) CREATE SECURITY RULE ААА 
    GRANT RETRIEVE ON STATS TO Ford ; 
    6) CREATE SECURITY RULE BBB 
    GRANT INSERT, DELETE ON STATS TO Smith ; 
    B) CREATE SECURITY RULE CCC GRANT   RETRIEVE 
    ON      STATS WHERE STATS.USERID = USER {) TO      ALL ; 
    Обратите внимание на использование в этом правиле встроенной функции USER. 
    Г) CREATE SECURITY RULE ODD 
    GRANT   RETRIEVE, UPDATE ( SALARY, TAX ) ON      STATS TO     Nash ; 
    Д) CREATE SECURITY RULE EEE 
    GRANT   RETRIEVE ( USERID, SALARY, TAX ) ON      STATS TO     Todd ; 
    б) CREATE SECURITY RULE FFF 
    GRANT   RETRIEVE ( USERID, SALARY, TAX ) , 
    UPDATE ( SALARY, TAX ) ON      STATS TO     Ward ; 
    Ж) CREATE SECURITY RULE, GGG GRANT   AIL 
    ON     STATS WHERE STATS.JOB = 'Проповедник1 TO     Pope ; 

    Глава 15. Безопасность	413 

    3) RANGE OF TX IS STATS ; CREATE SECURITY RULE HHH GRANT   DELETE ON      
STATS WHERE 
    COUNT ( TX WHERE TX.JOB = STATS.JOB ) > 10 TO     Jones ; 
    И) CREATE VIEW SALS AS ( STATS.JOB, 
    MAX ( TX.SAL WHERE TX.JOB = STATS.JOB ) AS MAXSAL, MIN (TX.SAL WHERE 
TX.JOB = STATS. JOB ) AS MINSAL ) ; CREATE SECURITY RULE III 
    GRANT RETRIEVE ON SALS TO King ; 
    Обратите внимание, что для записи данного правила не требуется 
использовать представление. 
    15.2. Здесь необходимо отметить, что пользователя, который обладает 
привилегией создания нового базового отношения и действительно создает такое 
отношение, следует рассматривать как владельца этого нового отношения. 
Владелец данного базового отношения не только автоматически наделяется всеми 
возможными привилегиями на это отношение, включая не только операции RETRIEVE, 
INSERT, UPDATE и DELETE, но и обладает правом наделять такими полномочиями для 
данного отношения других пользователей. 
    15.3. Открытый текст имеет следующий вид: 
    EYES I DARE NOT MEET IN DREAMS 
    Какой был использован ключ шифрования? 
    15.5. Проблема заключается в том, что в системе, в которой выполняется 
шифрование, данные внутри системы должны обрабатываться в открытом виде 
(например, чтобы корректно выполнялись операции сравнения). Поэтому все еще 
существует риск открытого доступа к очень важным данным с помощью параллельно 
работающих приложений или потери данных при сбросе состояния памяти на внешний 
носитель. Кроме того, существует несколько технических проблем, связанных с 
индексированием зашифрованных данных и ведением файла протокола для таких данных. 
    15.6. a) GRANT SELECT ON STATS TO Ford ; 
    6) GRANT INSERT, DELETE ON STATS TO Smith ; 
    B) CREATE	VIEW                  MINE                  AS SELECT  STATS. * 
FROM    STATS 
    WHERE   STATS. USER! D	=             USER GRANT SELECT ON MINE TO PUBLIC ; 
    Обратите внимание, что в стандарте SQL поддерживается встроенная функция USER. 
    Г) GRANT SELECT, UPDATE ( SALARY, TAX ) ON STATS TO Nash ; 
    Д) CREATE VIEW UST AS 
    SELECT  STATS.USERID, STATS.SALARY, STATS.TAX FROM    STATS ; GRANT SELECT 
    ON UST TO Todd ; 
    e) GRANT SELECT, UPDATE { SALARY, TAX ) ON UST TO Ward ; 
    Ж) CREATE VIEW PREACHERS AS SELECT STATS.* FROM STATS 
    WHERE   STATS.JOB = 'Проповедник' ; GRANT ALL PRIVILEGES ON PREACHERS TO 
Pope ; 
    Обратите внимание на использование в данном примере сокращения ALL 
PRIVILEGES (все привилегии). (Директива ALL PRIVILEGES не означает буквально 

    414	Часть IV. Защита данных 

    все привилегии, а лишь все те привилегии для данного объекта, которые 
некий пользователь может предоставить другому пользователю с помощью директивы GRANT.) 
    3) CREATE VIEW SPECIALISTS AS SELECT   STX.* FROM      STATS AS STX WHERE 
( SELECT COUNT(*) 
    FROM    STATS AS STY 
    WHERE   STY.JOB = STX.JOB ) > 10 ; 
    GRANT DELETE ON SPECIALISTS TO Jones ; 
    И) CREATE VIEW SALS AS 
    SELECT STATS.JOB, 
    MAX ( STATS.SALARY ) AS MAXSAL, MIN ( STATS.SALARY ) AS MINSAL FROM   
STATS GROUP  BY STATS.JOB ; GRANT SELECT ON SALS TO King ; 
    15.7. a) REVOKE SELECT ON STATS FROM Ford RESTRICT ; 
    6) REVOKE INSERT, DELETE ON STATS FRCM Smith RESTRICT ; B) REVOKE SELECT 
ON MINE FRCM PUBLIC RESTRICT ; 
    Г) REVOKE SELECT, UPDATE ( SALARY, TAX ) 
    ON STATS FRCM Nash RESTRICT ; 
    Д) REVOKE SELECT ON UST FRCM Todd RESTRICT ; 
    e) REVOKE SELECT, UPDATE ( SALARY, TAX ) 
    ON UST FRCM Ward RESTRICT ; 
    ж) REVOKE ALL PRIVILEGES ON PREACHERS FRCM Pope RESTRICT ; 3) REVOKE 
DELETE ON SPECIALISTS FRCM Jones RESTRICT ; и) REVOKE SELECT ON SALS FRCM King 
RESTRICT ; 

    Глава 15. Безопасность	415 

