Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE 2
EMBED WangImage.Document
Тема 8.
Безопасность баз данных. Механизмы защиты.
8.1. Основные аспекты безопасности БД.
Основной формой организации информационных массивов в ИВС являются базы данных.
Базу данных можно определить как совокупность взаимосвязанных хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одною или нескольких приложений. В отличие от файловой системы организации и использования информации, БД существует независимо от конкретной программы и предназначена для совместного использования многими пользователями. Такая централизация и независимость данных в технологии БД потребовали создания соответствующих СУБД - сложных комплексов программ, которые обеспечивают выполнение операций корректного размещения данных, надежного их хранения, поиска, модификации и удаления.
С точки зрения эталонной модели взаимодействия открытых систем любая система управления распределенными базами данных (РБД) есть компонента специального программного обеспечения информационно-вычислительной сети, использующая свои собственные протоколы только на прикладном уровне. В связи с этим обеспечение безопасности РБД косвенно реализуется сетевой ОС, а точнее, ее механизмами и средствами нижних уровней. Однако все указанные механизмы и средства инвариантны конкретным способам представления информации в БД (в конечном итоге, моделям данных), возможностям СУБД и их языковых средств по доступу к данным, а также возможностям, предоставляемым прикладным программам по работе с базами данных. Подобная инвариантность приводит к тому, что в случае непринятия специальных мер все пользователи СУБД имеют равные права по использованию и обновлению всей информации, имеющейся в базе данных. В то же время указанная информация, как и при ее неавтоматизированном накоплении и использовании, должна быть категорирована, как минимум, по грифу секретности, группам пользователей, которым она доступна, а также по операциям над нею, которые разрешены указанным группам. Реализация подобного категорирования требует разработки и включения в состав СУБД специальных механизмов, краткому рассмотрению которых и посвящен настоящий подраздел.
Считается, что принятие решения о доступе к той или иной информации, имеющейся в БД, может зависеть от следующих факторов:
1) времени и точки доступа;
2) наличия в БД определенных сведений;
3) текущего состояния СУБД;
4) полномочий пользователя;
5) предыстории обращения к данным.
В первом случае доступ к БД с каждого терминала ИВС может быть ограничен некоторым фиксированным отрезком времени, за пределами которого любая попытка обращения к БД с этого терминала является запрещенной. Во втором случае пользователь может получить из БД интересующие его сведения только при условии, что база данных содержит некоторую взаимосвязанную с ними информацию определенного содержания. Например, можно установить ограничения, согласно которым сведения о заработной плате некоторого лица выдаются пользователю только тогда, когда это лицо состоит на государственной службе или, когда размер этой платы не превышает определенного значения. В третьем случае, например, обновление информации в некоторой БД может быть разрешено пользователю только в те моменты времени, когда она не обновляется другими пользователями. В четвертом случае для каждого пользователя прикладной программы устанавливаются индивидуальные права на доступ к различным элементам (разделам) базы данных. Эти права регламентируют операции, которые пользователь может выполнять над указанными элементами. Например, пользователю может быть разрешен отбор элементов БД, содержащих информацию о товарах, предлагаемых на бирже, но запрещено обновление этих сведений. В основе пятого из перечисленных факторов лежит то обстоятельство, что интересующую его информацию пользователь может получить не непосредственным отбором тех или иных элементов БД, а косвенным путем, то есть посредством анализа и сопоставления ответов СУБД на последовательно вводимые запросы (команды на обновление данных). В связи с этим для обеспечения безопасности информации в БД в общем случае необходимо учитывать предысторию обращения к данным.
Механизмы, обеспечивающие безопасность информации в БД на основе анализа перечисленных факторов, разрабатываются в рамках определенной политики безопасности, которая, в свою очередь, вырабатывается, исходя из соображений юридического характера, особенностей функционирования организационных структур, использующих базу данных, и т.п. При этом указанные механизмы должны быть, по возможности, достаточно гибкими с тем, чтобы их можно было эффективно использовать независимо от возможных изменений политики безопасности.
Существуют два в известном смысле противоположных подхода к политике безопасности. Первый, соответствующий так называемой политике минимума привилегий, состоит в том, чтобы в максимальной степени ограничить круг лиц, допущенных к информации в БД. При этом указанные лица получают доступ только к тем сведениям, которые необходимы им для выполнения служебных обязанностей. Существо второго подхода состоит в том, чтобы, наоборот, обеспечить максимальное использование информации, имеющейся в БД. При этом категорирование данных по грифу секретности по-прежнему имеет место, однако в остальном ограничения на доступ к информации таковы, что каждому пользователю доступен как можно более широкий круг сведений.
Первым шагом при разработке политики безопасности является определение информационного объекта - минимальной единицы информации, которой оперируют механизмы обеспечения безопасности БД. Выбор информационного объекта зависит как от принятого подхода к политике безопасности, так и от модели данных, положенной в основу СУБД. Так, информационным объектом применительно к реляционным системам может быть целое отношение, атрибут отношения либо значение атрибута. В сетевых и иерархических СУБД информационным объектом может быть запись либо элемент (поле) записи. Очевидно, что использование более мелких информационных объектов позволяет реализовать прецизионные механизмы обеспечения безопасности и, таким образом, более избирательную политику безопасности.
Защищаемую информацию в БД принято делить на контекстно-зависимую (контекстно-чувствительную) и контекстно-независимую. Контекстно-независимой считается информация, принятие решений на доступ к которой определяется первыми тремя из перечисленных выше факторов и не связано с использованием полномочий пользователя и предыстории его обращений к базе данных. Всю остальную информацию принято относить к контекстно-чувствительной.
Механизмы обеспечения безопасности контекстно-независимой информации реализуются достаточно просто и поэтому наиболее широко распространены в реальных СУБД. Из них представляют определенный интерес механизмы представлений и модификации запроса, обеспечивающие защиту информации с учетом конкретного содержимого БД. Для удобства изложения при рассмотрении существа этих механизмов мы будем придерживаться понятийного аппарата реляционной модели данных.
Механизм представлений, который был впервые реализован в одной из наиболее развитых реляционных СУБД System R (SQL/DS) [1], основывается на выделении каждому пользователю собственной подсхемы схемы базы данных и работе только с этой подсхемой. Так, если БД содержит отношения АНКЕТА и ЗАРПЛАТА со схемами АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ, ПОЛ, СЕМЕЙНОЕ-ПОЛОЖЕНИЕ, ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ, НАДБАВКА-ЗА-ВЫСЛУГУ-ЛЕТ, ПРЕМИЯ, НАЛОГ, ОБЩАЯ-СУММА), то одной группе пользователей могут быть выделены подсхемы отношений АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО.ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ) а другой - только подсхема первого отношения АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ). Администрация БД работает с полными схемами обоих отношений. При этом, естественно, значения атрибутов, не входящих в выделенные подсхемы, соответствующим пользователям недоступны.
Механизм модификации запроса, поддерживаемый, в частности, другой эффективной реляционной СУБД INGRES [2,3], основывается на принудительном (невидимом пользователю) приформировывании к тексту запроса дополнительных условий отбора, исключающих возможность получения сведений, доступ к которым пользователю запрещен. СУБД обрабатывает модифицированный таким образом запрос и выдает пользователю ответ, в котором содержатся только разрешенные элементы информации. Указанные условия отбора могут быть установлены и, как правило, устанавливаются индивидуально для каждого пользователя. Так, применительно к БД, содержащей отношения с приведенными выше схемами, подобные условия могут иметь следующий вид: ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) & ДАТА-РОЖДЕНИЯ >31.12.1931 для отношения АНКЕТА и ОБЩАЯ СУММА < 1500 для отношения ЗАРПЛАТА. Первое позволяет выдавать пользователю сведения только о младших и старших научных сотрудниках и заведующих секторами, родившихся в 1932-м и последующих годах. Второе условие позволяет выдавать сведения о заработной плате только тех сотрудников, которые получают менее 1500 рублей. При поступлении от пользователя запроса вида АНКЕТА: ДАТА-РОЖДЕНИЯ<01.01.1963 & ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) он будет преобразован в АНКЕТА: ДАТА-РОЖДЕНИЯ<01.01.1963 & ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) & ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) & ДАТА-РОЖДЕНИЯ >31.12.1931. При этом пользователь получит анкетные данные только о заведующих секторами, родившихся в 1932-1962 г.г., тогда как затребованные им сведения о заведующих отделами, родившихся до 1962 г., а также о заведующих секторами, родившихся до 1932 г., не будут включены в ответ.
Описанные механизмы, вообще говоря, не делают различия между операциями, выполняемыми над защищаемой информацией: считается, что информационный объект либо доступен пользователю, либо недоступен, причем в первом случае пользователь может выполнять над объектом любые операции, а во втором - никакие. Более тонкие механизмы реализуют избирательную защиту информации, когда для каждой операции и каждого пользователя определяется свое множество информационных объектов, над которыми она может быть выполнена пользователем. Например, одному из пользователей могут быть разрешены внесение, удаление и отбор любых элементов отношения АНКЕТА и отбор любых элементов отношения ЗАРПЛАТА. В это же время другому пользователю может быть разрешено внесение и удаление элементов отношения АНКЕТА, значениями атрибута ДОЛЖНОСТЬ, в которых не являются ЗАВЕДУЮЩИЙ ОТДЕЛОМ и ЗАВЕДУЮЩИЙ СЕКТОРОМ, а также отбор элементов отношения ЗАРПЛАТА по сотрудникам, не занимающим указанные должности.
Механизмы обеспечения безопасности контекстно-чувствительной информации существенно сложнее и в настоящее время находятся в стадии теоретической проработки и экспериментальных программных реализаций [4].
8.2. Основные требования по безопасности в базах данных
Основные требования по безопасности данных, предъявляемые к БД и СУБД, во многом совпадают с требованиями, предъявляемыми к безопасности данных в компьютерных системах. Поэтому некоторые из механизмов защиты БД (рис.8.1.) идентичны механизмам, используемым для защиты ОС.
Тем не менее, специфические особенности технологии БД определяют ряд требований по безопасности, характерных именно для БД. Основные требования можно разделить на требования по управлению доступом и требования по управлению целостностью данных.
Требования по управлению доступом в базах данных
Под управлением доступом в БД понимается защита данных в БД от НСД. Обычно выделяют следующие требования по безопасности, связанные с доступом в БД.
1. Возможность контроля доступа. В СУБД должны быть предусмотрены механизмы установления субъекта, осуществляющего тот или иной доступ к конкретному элементу данных, а также тип осуществленного доступа.
2. Доступность данных. Пользователи, которые авторизованы для работы с БД, должны иметь гарантированный доступ к соответствующим данным.
3. Управляемость доступом. Пользователь должен иметь доступ только к тем данным, для работы с которыми он имеет полномочия. При этом пользователи могут быть ограничены различными типами доступа (чтение, модификация, добавление, удаление и т.п.) к одним и тем же данным.
Требования по управлению целостностью в базах данных
Под управлением целостностью в БД понимается защита данных в БД от неверных (в отличие от несанкционированных) изменений и разрушений. Поддержание целостности БД состоит в том, чтобы обеспечить в каждый момент времени корректность (правильность) как самих значений всех элементов данных, так и взаимосвязей между элементами данных в БД.
С поддержанием целостности связаны следующие основные требования.
1.Обеспечение достоверности. В каждый элемент данных информация заносится точно в соответствии с описанием этого элемента. Должны быть предусмотрены механизмы обеспечения устойчивости элементов данных и их логических взаимосвязей к ошибкам или неквалифицированным действиям пользователей.
2. Управление параллелизмом. Нарушение целостности БД может возникнуть при одновременном выполнении операций над данными, каждая из которых в отдельности не нарушает целостности БД. Поэтому должны быть предусмотрены механизмы управления данными, обеспечивающие поддержание целостности БД при одновременном выполнении нескольких операций.
3. Восстановление. Хранимые в БД данные должны быть устойчивы по отношению к неблагоприятным физическим воздействиям (аппаратные ошибки, сбои питания и т.п.) и ошибкам в программном обеспечении. Поэтому должны быть предусмотрены механизмы восстановления за предельно короткое время того состояния БД, которое было перед появлением неисправности.
Вопросы управления доступом и поддержания целостности БД тесно соприкасаются между собой, и во многих случаях для их решения используются одни и те же механизмы. Различие между этими аспектами обеспечения безопасности данных в БД состоит в том, что управление доступом связано с предотвращением преднамеренного разрушения БД, а управление целостностью - с предотвращением непреднамеренного внесения ошибки.
Рис. 8.1. Механизмы защиты баз данных
8.3. Управление доступом в базах данных. Способы управления.
Большинство систем БД представляют собой средство единого централизованного хранения данных. Это значительно сокращает избыточность данных, упрощает доступ к данным и позволяет более эффективно защищать данные. Однако в технологии БД возникает ряд проблем, связанных, например, с тем, что различные пользователи должны иметь доступ к одним данным и не иметь доступа к другим. Поэтому, не используя специальные средства и методы, обеспечить надежное разделение доступа в БД практически невозможно.
Большинство современных СУБД имеют встроенные средства, позволяющие администратору системы определять права пользователей по доступу к различным частям БД, вплоть до конкретного элемента. При этом имеется возможность не только предоставить доступ тому или иному пользователю, но и указать разрешенный тип доступа: что именно может делать конкретный пользователь с конкретными данными (читать, модифицировать, удалять и т.п.), вплоть до реорганизации всей БД.
Кратко охарактеризуем некоторые механизмы управления доступом, используемые в различных БД.
Использование замков и ключей доступа
Рассмотрим сущность данного механизма доступа на примере сетевой модели КОДАСИЛ, которая была предложена в докладах и отчетах рабочей группы по БД DBTG Ассоциации по языкам систем обработки данных CODASIL в 1969-78 годах [5].
В работах указанной группы, наряду с обоснованием основ ных требований и конструктивных решений по архитектуре БД, нашли отражение и вопросы обеспечения безопасности БД. В частности, был описан подход к управлению доступом в БД с использованием замков (ACCESS CONTROL LOCK) и ключей управления (ACCESS CONTROL KEY).
Согласно предложенному подходу при определении данных указываются наборы (виды) операций над данными и замки управления доступом. Замок управления доступом представляет собой средство идентификации пользователя. В случае указания правильного ключа пользователь получает право выполнять над данными соответствующие операции. Пример задания замков управления доступом в модели КОДАСИЛ приведен на рис.8.2.
Использование рассмотренного способа позволяет осуществлять гибкое управление доступом в БД, однако его использование затрудняется по следующим основным причинам:
1) пользователь вынужден многократно предъявлять ключи управления доступом;
2) изменение замка управления доступом оказывает влияние на большое количество пользователей, причем степень этого влияния трудно оценить;
Таблицы управления доступом
Таблицы (списки) управления доступом широко используются в компьютерных системах, например, в ОС для управления доступом к файлам. Особенность использования этого средства для защиты БД состоит в том, что в качестве объектов зашиты выступают не только отдельные файлы (области в сетевых БД, отношения в реляционных БД), но и другие структурные элементы БД: элемент, поле, запись, набор данных.
По сравнению с использованием замков и ключей управление доступом на основе таблиц доступа (матриц доступа) имеет следующие достоинства:
1) возможность построения таблицы непосредственно пользователем БД;
2) отсутствует необходимость указания ключей управления доступом;
3) простота изменения таблицы доступа.
ОБ ЪЯВЛЕНИЕ В CXЕMЕ БАЗЫ ДАННЫХ ЗАМКА УПРАВЛЕНИЯ
ДОСТУПОМ
RECORD NAME IS
01 СЛУЖАЩИЙ
10 ЛИЧНЫЙ НОМЕР Р1С 9(6)
ACCESS CONTROL LOCK
FOR MODIFY IS АДМИНИСТРАТОР
10 ФАМИЛИЯ Р1С X(12)
ACCESS CONTROL LOCK
FOR DELETE IS "КТО" (строка символов
. объявлена в качестве
. замка для удаления
. записи)
ПРЕДЪЯВЛЕНИЕ КЛЮЧА УПРАВЛЕНИЯ В ПРОГРАММЕ ПОЛЬЗОВАТЕЛЯ
PROCEDURE DIVISION
DECLERATIVES.
USE FOR ACCESS CONTROL ON ERASE FOR СЛУЖАЩИЙ.
.
.
.
MOVE "КТО" TO DB ACCESS CONTROL KEY
.
.
.
END DECLARATIVES.
.
.
.
ERASE S.
Рис.8.2. Пример использования замков и ключей управления доступом.
При использовании динамического управления доступом пользователю предоставляется возможность управления доступом путем использования специальных команд. Такой механизм управления представляет собой расширение предыдущего способа в том смысле, что пользователь сам динамически формирует таблицы управления доступом.
Примером системы с механизмом защиты, реализующим динамическое управление доступом, является реляционная СУБД DB[6]. При создании нового отношения в БД владелец этого отношения имеет абсолютное право доступа к нему, включая право определять представления, основанные на этом отношении. Никто другой таких прав не имеет. У пользователя-владельца есть возможность предоставить право работы с отношением или его представлением другому пользователю. Это осуществляется командой ORANT (разрешение), имеющей следующий вид:
GRANT <вид операции над данными> ON <о6ъект>
ТО <су6ъект>
[WITH GRANT OPTION] (передача права определения полномочий другим пользователям).
Для отмены прав доступа другим пользователям пользователь владелец должен выдать команду REVOKE:
REVOKE <вид операции над данными>
ON <о6ъект>
FROM <су6ъект>.
В архитектуре современных БД принято выделять три основных уровня представления данных о предметной области (см. рис. 8.3.) [7]:
- концептуальный (уровень администратора);
- внешний (уровень прикладных программистов, конечных пользователей);
- внутренний (уровень системных программистов).
Одной из функций внешней схемы является управление доступом, так как она ограничивает поле зрения пользователя пределами некоторой области. На рис.8.4 представлен пример внешней схемы, заданной отношением реляционной модели данных. Из рисунка видно, что в отношении RI не содержится атрибут ЗАРПЛАТА, а в отношении R2 содержится информация о сотрудниках кафедры. Поэтому право доступа к БД со стороны пользователей, использующих отношения R1 и R2 в качестве внешних схем, автоматически (системой управления БД) ограничивается рамками соответствующих отношений.
Рис. 8.3. Отображение предметной области в схемах БД
Рис. 8.4. Пример использования внешней схемы при управлении доступом
Проблема предположения в базах данных
Заканчивая рассмотрение механизмов управления доступом в БД, следует особо выделить проблему предположения [8,9].
Наличие такой проблемы обусловлено тем, что взаимосвязанность хранимых в БД данных, в отличие от файловых систем, приводит к возможности получения одних данных по значениям других. Действительно, читая какой-либо файл в среде ОС, пользователь, за редким исключением, не может определить содержимое других файлов. Иная ситуация в БД, где за счет санкционированного доступа к элементам данных пользователь имеет возможность определить значения других данных, к которым он доступа не имеет. Существует множество способов построения предположений в среде БД: по суммам, по счетчикам, по линейным зависимостям и т.п.
Борьба с предположениями достаточно сложна и разработка механизмов защиты от них зачастую требует привлечения развитых методов современной логики и информатики. Суть большинства механизмов защиты состоит в том, чтобы не дать пользователю накопить объем незащищенной информации, достаточный для построения предположений о содержании защищенной от него информации. Однако ограничение с этой целью доступа пользователя к БД может привести к нарушению требования доступности данных для санкционированного пользователя, то есть страдать от этого будут пользователи, не помышляющие о каких-либо предположениях.
Кроме того, постоянное накапливание информации о том, какие сведения известны каждому пользователю, не только является дорогостоящим и сложным, но зачастую и не позволяет своевременно обнаружить опасность построения предположений, если пользователи имеют возможность обмениваться информацией друг с другом.
8.4. Управление целостностью данных
Нарушение целостности данных может быть вызвано рядом причин:
-сбои оборудования, физические воздействия или стихийные бедствия;
-ошибки санкционированных пользователей или умышленные действия несанкционированных пользователей;
- программные ошибки СУБД или ОС;
- ошибки в прикладных программах;
- совместное выполнение конфликтных запросов пользователей и др.
Нарушение целостности данных возможно и в хорошо отлаженных системах. Поэтому важно не только не допустить нарушения целостности, но и своевременно обнаружить факт нарушения целостности и оперативно восстановить целостность после нарушения.
Ограничения целостности данных
Составной частью лежащих в основе БД моделей данных являются ограничения - набор правил выполнения операций, гарантирующих их корректность (правильность). Важнейшими из этих ограничений являются ограничения целостности.
В теории реляционных запросов выделяют три основных типа ограничений целостности.
1. Ограничения целостности объекта. Значение ключа отношения, идентифицирующего объект либо его часть, не должно быть пустым (неопределенным) значением.
2. Ограничения целостности ссылок. Значение атрибута, отображающего связи между объектами и являющегося внешним ключом отношения, обязательно должно быть значением атрибута, описывающего соответствующий объект и являющегося ключом отношения.
3. Ограничения целостности приложений. К этому типу относятся ограничения, связанные с конкретными приложениями и реальными данными. Примерами ограничений целостности приложений могут служить:
а) статические ограничения, то есть ограничения на значения элементов данных, которые должны выполняться для каждого состояния БД;
6) ограничения перехода - ограничения, накладываемые на диапазон изменения элементов данных;
в) ограничения для кортежей (записей) ограничения, проверку которых можно осуществить, используя отдельные кортежи отношения (записи).
г) ограничения для множеств - ограничения, относящиеся к итоговым и средним значениям, получаемым из множества кортежей (записей);
д) безотлагательные ограничения - ограничения, допускающие возможность проверки их правильности одновременно с изменением значений данных;
е) отложенные ограничения - ограничения, для которых проверка выполнения имеет смысл по окончании логически объединенных в одну транзакцию операций.
Многие современные СУБД имеют механизмы, позволяющие установить подобного рода ограничения на значения данных в процессе описания данных, и механизмы проверки соблюдения требований в процессе эксплуатации БД. Наличие таких механизмов существенно сокращает риск непреднамеренных ошибок пользователей при работе с данными. Если ограничения целостности нарушаются, то изменение или занесение данных в БД не производится.
Механизмы ограничения целостности элементов данных также служат серьезным препятствием для преднамеренного искажения значений данных.
В качестве примера средств построения механизма ограничения целостности БД можно указать предложения KEY и CHECK языка описания данных модели КОДАСИЛ (см. рис.6.5.)
С помощью предложения CHECK можно объявить уникальный (системный) ключ для каждой записи в БД. С помощью предложения CHECK можно также записать различные ограничения статического типа. В приведенном примере этот тип ограничений специфицирован для атрибута ОКЛАД: значение этого атрибута не должно превышать 500000. Кроме того, для записи члена набора ПРИНАДЛЕЖНОСТЬ с помощью CHECK объявлено ограничение на целостность связей между элементами данных. Отметим, что ограничения последнего вида в модели применимы лишь к связям между владельцем и членами одного набора. Поэтому с помощью предложения CHECK записать ограничения целостности связей в общем случае, а также ограничения перехода и ограничения для множеств нельзя.
ОПИСАНИЕ ЗАПИСИ С ДАННЫМИ О СЛУЖАЩЕМ
/. ОПИСАНИЕ ЗАПИСИ С ДАННЫМИ О СЛУЖАЩЕМ
RECORD NAME IS СЛУЖАЩИЙ
KEY SK IS NBCA Каждый объект (запись)
DUPLICATES NOT ALLOWED идентифицируется
10 NBCA TYPE CHARACTER 8 уникальным ключом
NВСА
10 ФАМИЛИЯ TYPE CHARACTER 25
.
.
.
10 N_ПРИH TYPE CHARACTER 12
10 ОКЛАД TYPE DECIMAL
СHECK IS ОКЛАД NOT < 500000
.
.
.
2.0ПИСАНИЕ НАБОРА ПРИНАДЛЕЖНОСТЬ
SET NAME IS ПРИНАДЛЕЖНОСТЬ
OWNER ПОДРАЗДЕЛЕНИЕ
MEMBER СЛУЖАЩИЙ
CHECK IS N_ПРИН
IS=N ПОДР IN OWNER ПОДРАЗДЕЛЕНИЕ
Значение атрибута N_ПРИН в члене набора ПРИНАДЛЕЖНОСТЬ должно равняться значению атрибута N_ ПОДР в записи владельца данного члена.
Рис. 8.5. Ограничения целостности в модели КОДАСИЛ.
Более широкие возможности по заданию и проверке выполнения ограничений целостности существуют в реляционных системах, использующих язык структурированных запросов SQL, причем любой запрос пользователя на SQL перед его выполнением может быть модифицирован таким образом, чтобы не было возможности нарушить любые ограничения целостности [6,10].
Поддержание целостности на основе приведенных выше ограничений целостности представляет собой достаточно сложную проблему в системе БД даже с одним пользователем. В системах, ориентированных на многопользовательский режим работы, возникает целый ряд новых проблем, связанных с параллельным выполнением конфликтующих запросов пользователей. Прежде чем рассмотреть механизмы защиты БД от ошибок, возникающих в случае конфликта пользовательских запросов, раскроем ряд понятий, связанных с управлением параллелизмом-
Важнейшим средством механизма защиты целостности БД выступает объединение совокупности операций, в результате которых БД из одного целостного состояния переходит в другое целостное состояние, в один логический элемент работы, называемый транзакцией. Суть механизма транзакций состоит в том, что до завершения транзакции все манипуляции с данными проводятся вне БД, а занесение реальных изменений в БД производится лишь после нормального завершения транзакции.
Сточки зрения безопасности данных такой механизм отображения изменений в БД очень существенен. Если транзакция была прервана, то специальные встроенные средства СУБД осуществляют так называемый откат возврат БД в состояние, предшествующее началу выполнения транзакции (на самом деле откат обычно заключается просто в невыполнении изменений, обусловленных ходом транзакции, в физической БД).
Если выполнение одной транзакции не нарушает целостности БД, то в результате одновременного выполнения нескольких транзакций целостность БД может быть нарушена. Представленный на рис. 8.6 пример иллюстрирует данное утверждение: в результате выполнения двух транзакций значение элемента данных должно увеличиться на 2, но если не предпринять никаких дополнительных мер по управлению выполнением транзакций, то их выполнение даст неверный результат.
Чтобы избежать подобного рода ошибок, СУБД должна поддерживать механизмы, обеспечивающие захват транзакциями модифицируемых элементов данных до момента завершения модификации, так называемые блокировки. При этом гарантируется, что никто не получит доступа к модифицируемому элементу данных, пока транзакция не освободит его.
Применение механизма блокировок приводит к новым проблемам управления параллелизмом, в частности, к возникновению ситуаций клинча двух транзакций (аналогично клинчу двух процессов в ОС).
Объектами блокировок могут быть значения отдельных атрибутов, кортежи отношений (записи), целые отношения (файлы), наборы данных БД. Причем, если некоторая транзакция пытается блокировать объект, который уже блокирован другой транзакцией, то ей придется ждать, пока не будет снята блокировка объекта транзакцией, установившей эту блокировку. Иными словами, блокировку объекта может выполнять только одна транзакция.
Транзакция W. называется правильно оформленной, если она удовлетворяет следующим условиям.
1. Перед обработкой объекта должна быть выполнена его блокировка.
2. После обработки объект должен быть обязательно разблокирован (освобожден).
повторная блокировка.
Для поддержания целостности БД необходимо соблюдать определенные правила выполнения блокировок.
Для совокупности транзакций W1 = < а11, а12 , ..., а1M1 >,
W2 = < а2, а21,…, а2M2 >, ..., WN = < аN1, аN2, …,аNMN > порядок выполнения
элементарных операции аIJ (i = 1, N) называют расписанием выполнения
совокупности элементарных операций. Элементарными операциями могут служить операции: изменить объект х, блокировать х, разблокировать х и др.
|
Значение элемента в БД |
5 |
5 |
5 |
5 |
6 |
6 |
|
Транзакция 1 |
Чтение элемента |
|
Прибавить 1 |
|
Запись элемента |
|
|
Транзакция 2 |
Чтение элемента |
|
Прибавить 1 |
|
Запись элемента |
|
|
3начение элемента для транзакции 1 |
5 |
5 |
6 |
6 |
6 |
|
|
Значение элемента для транзакции 2 |
5 |
5 |
6 |
6 |
б |
Рис.8.6. Пример нарушения целостности при параллельном выполнении транзакций.
Если элементарные операции аIJ обязательно являются смежными в расписании выполнения совокупности элементарных операций, то такое расписание называется последовательным. Последовательное расписание не нарушает целостности БД, однако такое расписание низкоэффективно.
Расписание, выполнение которого дает результаты, эквивалентные результатам последовательного расписания, называется сериализуемым.
Расписание правильно оформленных транзакций, в котором повторная блокировка ранее блокированного объекта происходит после его разблокировки, называется легальным расписанием. Легальное расписание обеспечивает одновременное (параллельное) выполнение нескольких транзакций. Однако легальное расписание не всегда является сериализуемым, то есть целостность БД не гарантируется.
Совокупность транзакций, для которой все легальные расписания являются сериализуемыми, называется надежной. Конструктивное определение надежной совокупности транзакций связано с понятием двухфазной блокировки. Если интервалы блокирования всех объектов в транзакции накладываются друг на друга, то говорят, что такая транзакция подчиняется требованиям двухфазной блокировки. Таким образом, двухфазная блокировка представляет собой требование, согласно которому в каждой транзакции все операции блокирования объектов должны предшествовать всем операциям разблокирования.
Если транзакции W1, W2 ,…, WN являются правильно оформленными и для них выполняется двухфазная блокировка, то совокупность (W1 , W2 ,...,WN) - надежная. Это является достаточным условием сериализуемости расписания.
Различные типы блокировок обеспечивают разные уровни целостности данных.
Очевидно, что не все операции, выполняемые в транзакции, изменяют значения объектов (например, операция записи изменяет значение объекта, а операция чтения - не изменяет). Это различие целесообразно учитывать при организации блокировок объектов.
Рассмотрим подробнее случаи, возникающие при одновременном выполнении двух транзакций W1 и W2 .
1. Транзакции W1 и W2 изменяют значение объекта. В рассматриваемом случае могут возникнуть следующие ситуации:
а) нарушение целостности, называемое потерей обновления и вызванное наложением изменяемых значений одинаковых объектов (пример на рис.8.6);
6) возникновение по какой-либо причине ошибки в значении объекта, изменяемого операцией в W1 , что может привести к ошибке выполнения W2. В таком случае невозможно исключить только результат W1 (сделать откат W1). Подобное нарушение целостности называют взаимозависимостью восстановления.
2. Транзакция W1 изменяет значение объекта,
транзакция W2 считывает значение объекта.
В этом случае могут возникнуть следующие ситуации:
а) изменение транзакцией W1 значения объекта, уже считанного транзакцией W2. В такой ситуации говорят, что для W2 отсутствует воспроизводимость считывания;
б) возникновение отказа перед окончанием транзакции W1 , что полностью исключает изменения, обусловленные выполнением W1. В этом случае возможен откат в состояние, которое было перед выполнением W1 . Взаимозависимость в этом случае отсутствует, но существует возможность считывания в транзакции W2 неправильных значений объекта. В такой ситуации говорят, что транзакция W1 загрязняет транзакцию W2.
3. Транзакция W1 считывает значение объекта,
транзакция W2 изменяет значение объекта.
В этом случае нет гарантии, что при повторном считывании значения объекта транзакцией W1 будет получено то же значение объекта, что и при первом считывании. В отличие от п.2(а), здесь W2 не гарантирует воспроизводимость считывания для W1.
4. Транзакции W1 и W2 считывают значение объекта. Рассмотренные случаи показывают необходимость нескольких уровней целостности, определяющих соответствующий вид и период блокировки:
а) при изменении значений объекта должна осуществляться монопольная блокировка. При такой блокировке никакие другие одновременно выполняемые транзакции не имеют возможности считать либо изменить значение объекта;
б) при использовании монопольной блокировки целесообразно не освобождать объект до окончания данной транзакции.
В противном случае могут возникать потери обновления, взаимозависимосгь восстановления и другие нежелательные последствия;
в) при одновременном выполнении транзакций, в которых осуществляется только выборка значений объектов, используется совместная блокировка. В этом случае одновременно выполняемые транзакции могут выполнять считывание значения объекта, но им запрещено выполнять изменение этого значения.
Таблица 8.1. иллюстрирует использование возможных вариантов блокировки одинаковых объектов при одновременном выполнении транзакций. Знаки "—" и "+" в таблице указывают, соответственно, допустима или нет следующая попытка блокировки объектов (знак "+" указывает на то, что требования блокировки по отношению к объекту конкурируют между собой).
Можно указать три способа разрешения конфликтных ситуаций:
1) перевести конкурирующую транзакцию в состояние ожидания разблокирования объекта;
2) прекратить выполнение конкурирующей транзакции;
3) прекратить выполнение предшествующей транзакции и продолжить выполнение конкурирующей транзакции.
Использование любого из перечисленных способов для организации параллельного выполнения совокупности правильно оформленных транзакций, удовлетворяющих ограничению двух фазной блокировки, гарантирует целостность БД.
Таблица 8.1.
|
Вид первоначальной блокировки |
Вид последующей блокировки |
||
|
Нет |
Совместная блокировка |
Монопольная блокировка |
|
|
Нет |
…. |
… |
… |
|
Совместная блокировка |
…. |
… |
+ |
|
Монопольная блокировка |
…. |
+ |
+ |
Известно, что при использовании первого способа (наиболее часто применяемого в СУБД) может возникнуть тупиковая ситуация (клинч), при которой каждая из одновременно выполняемых транзакций ожидает, когда ей будет предоставлена возможность заблокировать объект, в данный момент времени заблокированный какой-либо другой транзакцией. При этом ни одна из транзакций не может разблокировать объект, необходимый для продолжения другой транзакции.
Для предотвращения возникновения тупиковой ситуации необходимо, чтобы каждая транзакция единовременно запрашивала все нужные ей блокировки на начальной стадии своего выполнения. Другим простым способом обнаружения тупиковой ситуации является обнаружение совокупности транзакций, которые находятся в состоянии ожидания дольше определенного промежутка времени. Если при этом обнаруживается тупиковая ситуация, то она устраняется путем отката и рестарта какой-либо из попавших в эту ситуацию транзакций.
8.5. Восстановление данных
Как уже отмечалось, возникновение сбоев в аппаратном или программном обеспечении может вызвать необходимость восстановления и быстрого возвращения в состояние, по возможности близкое к тому, которое было перед возникновением сбоя (ошибки). К числу причин, вызывающих необходимость восстановления, зачастую относится и возникновение тупиковой ситуации.
Можно выделить три основных уровня восстановления.
1. Оперативное восстановление, которое характеризуется возможностью восстановления на уровне отдельных транзакций при ненормальном окончании ситуации манипулирования данными (например, при ошибке в программе).
2. Промежуточное восстановление. Если возникают аномалии в работе системы (системно-программные ошибки, сбои программного обеспечения, не связанные с разрушением БД), то требуется восстановить состояние всех выполняемых на момент возникновения сбоя транзакций.
3. Длительное восстановление. При разрушении БД в результате дефекта на диске восстановление осуществляется с помощью копии БД. Затем воспроизводят результаты выполненных с момента снятия копии транзакций и возвращают систему в состояние на момент разрушения.
Транзакция и восстановление
Прекращение выполнения транзакции вследствие появления сбоя нарушает целостность БД. Если результаты такого выполнения транзакции потеряны, то имеется возможность их воспроизведения на момент возникновения сбоя. Таким образом, понятие транзакции играет важную роль при восстановлении (см. рис.8.7.).
Для восстановления целостности БД транзакции должны удовлетворять следующим требованиям:
1) необходимо, чтобы транзакция или выполнялась полностью, или не выполнялась совсем;
2) необходимо, чтобы транзакция допускала возможность возврата в первоначальное состояние, причем, для обеспечения независимого возврата транзакции в начальное состояние, монопольную блокировку необходимо осуществлять до момента завершения изменения всех объектов;
3) необходимо иметь возможность воспроизведения процесса выполнения транзакции, причем, для обеспечения этого требования, совместную блокировку необходимо осуществлять до момента завершения просмотра данных всеми транзакциями.
В процессе выполнения любой транзакции наступает момент ее завершения. При этом все вычисления, сделанные транзакцией в ее рабочей области, должны быть закончены, копия результатов ее выполнения должна быть записана в системный журнал. Подобные действия называют операцией фиксации.
При появлении сбоя целесообразнее осуществлять возврат не в начало транзакции, а в некоторое промежуточное положение. Точку, куда происходит такой возврат, называют точкой фиксации (контрольной точкой).
Пользователь может установить в процессе выполнения транзакции произвольное количество таких точек- Если в ходе выполнения транзакции достигается точка фиксации, то СУБД автоматически осуществляет указанную
выше операцию.
Основным средством, используемым при восстановлении, является системный журнал, в котором регистрируются все изменения, вносимые в БД каждой транзакцией. Возврат транзакции в начальное состояние состоит в аннулировании всех изменений, которые осуществлены в процессе выполнения транзакции. Такую операцию называют откатом. Для воспроизведения результатов выполнения транзакции можно, используя системный журнал, восстановить значения проведенных изменений в порядке их возникновения, либо выполнить транзакцию повторно.
Воспроизведение результатов выполнения транзакции с использованием системного журнала называется раскруткой. Раскрутка является достаточно сложной, но необходимой операцией механизмов восстановления современных БД. Кроме того, откат и раскрутка используются для устранения тупиковых ситуаций, когда необходимо произвести аннулирование изменений одной из конкурирующих транзакции.
Промежуточное восстановление
Если появляется сбой из-за ошибки оператора или ОС (СУБД), то выполняемые в это время транзакции полностью исключаются и возникает необходимость в перезапуске системы с некоторого предыдущего момента времени. Для этого в системе организуются контрольные точки. Контрольная точка служит для осуществления отката транзакций и является границей, с которой перезапускают систему. Момент возникновения сбоя нельзя предугадать, следовательно, контрольные точки необходимо устанавливать периодически.
Рис. 8.7. Восстановление и транзакция
Существует два типа контрольных точек.
1. Контрольная точка, условием установления которой является отсутствие в данный момент времени выполняющихся транзакций- Если транзакция выполняется, то начало новых транзакций задерживается, и контрольная точка устанавливается после завершения выполняющейся транзакции. При появлении сбоя осуществляется откат в состояние, соответствующее последней установленной контрольной точке. Раскрутка транзакции, завершившейся между контрольной точкой и точкой появления сбоя, осуществляется с использованием системного журнала.
Длительное восстановление
Если при возникновении сбоя внешнего запоминающего устройства БД разрушается, операция отката транзакций в начальное состояние становится бессмысленной. Для восстановления БД после такого сбоя периодически формируется дамп (точная копия физических файлов всей БД). С помощью дампа воспроизводится состояние БД на момент снятия копии, после чего осуществляется раскрутка до последней перед сбоем контрольной точки. Для раскрутки используется системный журнал.
В некоторых случаях получение дампов БД реализуется средствами ОС. Однако более эффективной является загрузка/выгрузка средствами СУБД. В процессе выгрузки данные извлекаются из БД и в строго определенном формате записываются в обычные файлы (запись данных в файлы может осуществляться в другом формате). При этом за счет описания и заполнения избыточных данных создается возможность восстановления связей между конкретными значениями данных в процессе проведения обратной операции - загрузки БД. Средства загрузки/выгрузки, помимо возможности создания резервных копий БД, выполняют еще одну важную функцию: в некоторых случаях они позволяют реструктурировать БД и улучшить эксплуатационные характеристики базы данных.
1. Какие механизмы защиты являются общими для ОС и БД (СУБД)?
2. Перечислите характерные для технологии БД требования по безопасности данных.
3. Чем отличается управление доступом от управления целостностью БД?
4. Сформулируйте основные недостатки положений КОДАСИЛ по защите БД.
5. В чем заключается сходство и различие механизмов управления доступом к БД, использующих таблицы (матрицы) доступа и внешнюю схему БД?
6. Предложите способы выявления косвенного предоставления права доступа для систем с динамическим управлением доступом (на примере СУБД DB).
7. Перечислите нарушения целостности БД, связанные с параллельным выполнением транзакций.
8. Назовите достаточное условие сериализуемости расписания выполнения транзакций.
9. Перечислите способы, позволяющие избежать тупиковых ситуаций. Перечислите способы выхода из состояния клинча транзакций.
10. Перечислите уровни восстановления БД. В чем заключается сущность каждого уровня?
Литература
1. Blasgen M.W., Eswaran К.P. Storage and access in relational, data bases //IBM Systems Journal, Vol. 16 (1977), No.4. P.363-378.
2. Stonebraker М. Performance enhancements to a relational database System //ACM TODS, Vol.8 (1983), No.2. P.167-185.
3. Rowe LA., Stonebraker M.R. The Postgres datamodel //Very Large Data Bases: Proc. of the 13th Int. Conf. - Brighton. England, 1987. P. 83-96.
4. Denning D.E., Aki S.G., Morgenstern М., Neumann P.G., Schell R.R., Heckmann M. Views for multilevel database security/ / Security and Privacy : Proc. jf the 1986 IEEE Symp. - Wash. : IEEE Comp. Society Press, 1986. P. 156-172.
5. Олле Т.В. Предложения КОДАСИЛ по управлению базами данных.- М.: Финансы и статистика, 1981. 286 с.
6. Дейт К. Руководство по реляционной СУБД DB-.- М.: Финансы и статистика , 1988.-320 с.
7. Haгao М., Катаяма Т., Уэмура С. Структуры и базы данных.- М.: Мир, 1986.- 197 с.
8. Голубев В.В-, Дубров П.А., Павлов Г.А- Механизмы защиты операционных систем и систем управления базами данных // Зарубежная радиоэлектроника, 1989.- N12.- С. 36-47.
9. Моисеенков И.И. Безопасность компьютерных систем // Компьютер Пресс, 1991.- N12.- С. 57-61.
10. Дейт К. Введение в системы баз данных.- М.: Наука, 1980.-464 с.
11. Бородаев В.А., Кустов В.Н. Банки и базы данных.-Л.: ВИКИ им. А.Ф.Можайского, 1989. 224 с.
12. Уэлдон Дж.Л. Администрирование баз данных.- М.: Финансы и статистика, 1984.- 207 с.