Вопросы безопасности и санкционирования доступа к базам данных

5.  Вопросы безопасности и санкционирования доступа к базам данных.

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

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

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

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

В современных базах данных дела обстоят несколько лучше (хотя и не идеально). Во-первых, уже во многих СУБД поддерживается понятие домена (множества значений некоторого типа данных). При определении столбца таблицы можно указать домен допустимых значений этого столбца, и после этого система следит за тем, чтобы в столбце содержались только допустимые значения. (Конечно, это не значит, что по ошибке нельзя поместить в поле записи допустимое, но неверное значение.) Во-вторых, для столбца, для таблицы или для нескольких таблиц одновременно можно определить одно или несколько ограничений целостности. Ограничение целостности – это логическое выражение, которое должно быть истинным при целостном состоянии базы данных. Система не допускает выполнения операций обновления базы данных, в результате которых нарушается хотя бы одно ограничение целостности. В-третьих, в некоторых системах появилась поддержка триггеров – хранимых процедур, написанных на процедурном расширении языка SQL (например, PL/SQL в Oracle), которые автоматически вызываются при выполнении специфицированных операций обновления базы данных и служат для поддержания ее целостности.

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

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

Кстати, нужно, наверное, заметить, что как обычно случается в программировании, передовой в мире СУБД подход темпоральных баз данных в большой степени основан на старых идеях операционных систем компании Digital RSX и VMS. В этих системах каждое обновление файла приводило к созданию его новой версии, и все предыдущие версии сохранялись до явного уничтожения. Ох, и мороки было чистить залежи своих файлов, когда число версий доходило до сотни. Частенько случалось по ошибке уничтожить именно правильную версию. Темпоральные СУБД не допускают уничтожения существующих вариантов записей, но чтобы не переполнить магнитные диски, приходится время от времени архивировать наиболее старую часть активной порции базы данных.

До сих пор в качестве примера распространенного вида ошибок фигурировал случай, когда неправильно обновлялось индивидуальное поле некоторой записи. Однако часто возникают ситуации, когда совокупные данные записи становятся неверными по той причине, что значения нескольких полей должны изменяться согласованно. Расширим немного пример базы данных марок автомобилей. Пусть каждая запись содержит еще одно поле – класс автомобиля. Например, пусть при весе до 3,5 тонн автомобиль относится к классу B, а при большем весе – к классу С. Конечно, это ограничение целостности, и его можно сформулировать, например, на языке SQL. Конечно, можно определить триггер, который будет автоматически изменять значение класса автомобиля в зависимости от устанавливаемого значения его веса. Но все это ужасно громоздко.

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

В случае ООБД конструирование базы данных состоит в разработке структуры и методов объектов. Поэтому можно написать методы таким образом, чтобы при работе с любым объектом было невозможно нарушить его целостность. Например, ООБД марок автомобилей состояла бы из объектов, внутреннее состояние которых представляло бы собой записи той же структуры, как и раньше, а в число методов входил бы метод «Изменить вес автомобиля». Тогда код этого метода автоматически изменял бы и класс автомобиля при возникновении соответствующего условия. Кстати, заметим, что отсутствовал бы метод «Изменить класс автомобиля», значение класса было бы доступно только по чтению. Ошибочные состояния объектов все равно возможны, поскольку никто не мешает обратиться к методу «Изменить вес автомобиля» с неверными, хотя и правдоподобными параметрами. Как и прежде, единственным способом сохранить возможность доступа к последнему варианту объекта с правильным состоянием является использование техники темпоральных баз данных.

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

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

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

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

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

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

Привилегии предоставляются с помощью предложения GRANT (предоставить), общий формат которого имеет вид

GRANT привилегии ON объект TO пользователи;

В нем «привилегии» – список, состоящий из одной или нескольких привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все привилегии); «объект» – имя и, если надо, тип объекта (база данных, таблица, представление, индекс и т.п.); «пользователи» – список, включающий один или более идентификаторов санкционирования, разделенных запятыми, либо специальное ключевое слово PUBLIC (общедоступный).

К таблицам (представлениям) относятся привилегии SELECT, DELETE, INSERT и UPDATE [(столбцы)], позволяющие соответственно считывать (выполнять любые операции, в которых используется SELECT), удалять, добавлять или изменять строки указанной таблицы (изменение можно ограничить конкретными столбцами). Например, предложение

GRANT SELECT, UPDATE (Труд) ON Блюда TO cook;

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

Если пользователь USER_1 предоставил какие-либо привилегии другому пользователю USER_2, то он может впоследствии отменить все или некоторые из этих привилегий. Отмена осуществляется с помощью предложения REVOKE (отменить), общий формат которого очень похож на формат предложения GRANT:

REVOKE привилегии ON объект FROM пользователи;

Например, можно отобрать у пользователя cook право изменения значений столбца

5. Перспективы развития сетевых баз данных

Термин «системы следующего (или третьего) поколения» вошел в жизнь после опубликования группой известных специалистов в области БД «Манифеста систем баз данных третьего поколения». Cторонники этого направления придерживаются принципа эволюционного развития возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения.

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

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

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

Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только условно (например, иногда объектно-ориентированную СУБД O2 относят к системам следующего поколения), можно отметить три направления в области СУБД следующего поколения. Чтобы не изобретать названий, будем обозначать их именами наиболее характерных СУБД.

1.    Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам организации СУБД (если не считать упоминавшейся коренной переделки системы управления внешней памятью).

2.    Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется вплоть до самых базисных слоев системы.

3.    Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.

В целом можно сказать, что СУБД следующего поколения – это прямые наследники реляционных систем.

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

1.    Браун М., Ханикатт Д. “HTML 3.2”, К., 1996

Вьюкова Н.И., Галатенко В.А., “Информационная безопасность систем управления базами данных”, СУБД № 1 1996

3.    Грабер М., “Справочное руководство по SQL”, М., 1997

4.    Дейта К. “Введение в системные баз данных”, М., 1999

5.    Дунаев С.Б. “Intranet-технологии.”, М., 1997

6.    Кириллов В.В. “Структуризованный язык запросов (SQL)”, М.,1997

7.    Кузнецов С.Д. “Основы современных баз данных”, К., 1999

8.    Кузнецов С.Д. “Безопасность и целостность или, Худший враг себе - это ты сам”, СПб., 1998

9.    Мейер М. “Теория реляционных баз данных”, М.,1996

10.  ЦНИТ НГУ. “Использование технологий WWW для доступа к базам данных”, Н., 1997

11.  Шпеник М., Следж О. и др. “Руководство администратора баз данных Microsoft SQL Server 7.0”, М., 1999

"SQL Полное руководство" К., 1998