Безопасность и целостность, или
Худший враг себе - это ты сам

Сергей Кузнецов

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

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

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

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

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

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

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

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

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

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

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

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

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