Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Лекции по курсу. В 4 частях. Ч.4. Учебное пособие
.pdf
данных с момента создания последней резервной копии. Журнал транзакций необходим для восстановления изменений в базе данных после
резервной копии.
Как часто следует проводить резервное копирование? Ответ на этот вопрос зависит от многих факторов. Для небольшой базы данных можно создавать полную резервную копию несколько раз в день без ущерба
для
пользователей. Для больших и интенсивно использующихся баз данных
полное резервное копирование проводят один-два раза в неделю и дополняют ежедневными дифференциальными или инкрементальное копиями.
5.2.2. ЖУРНАЛИЗАЦИЯ. ВОССТАНОВЛЕНИЕ ДАННЫХ
Одной из функций СУБД является надежное хранение данных.
Под надежностью хранения понимается способность СУБД восстановить последнее согласованное состояние базы данных после любого аппаратного или программного сбоя.
Наличие буферного кеша СУБД, а также других буферов в оперативной памяти увеличивает производительность, но уменьшает надежность. При сбое питания или СУБД
содержимое буферного кеша в оперативной памяти пропадает и данные, измененные и находящиеся в буфере, но еще не записанные на диск, теряются. Это недопустимо и противоречит свойству долговечности транзакций.
Поэтому для восстановления базы данных нужно располагать некоторой дополнительной информацией (избыточностью), и эта информация
должна храниться особо надежно.
Методом поддержания такой избыточной информации является аппарат журнализации изменений базы данных. В процессе работы СУБД постоянно помещает записи в журнал
транзакций, позволяющий в случае необходимости повторно выполнить
потерянные операции и восстановить данные в согласованном состоянии.
Журнализация изменений – функция СУБД, обеспечивающая восста-
новление базы данных в предыдущее согласованное состояние в
случае
логических или физических отказов. Журнал (log) – особая часть базы
данных, недоступная пользователям и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо
всех изменениях основной части базы данных. Журнал транзакций защищает все объекты, работа с которыми
ведется в оперативной памяти:
таблицы, индексы и другие объекты, статус транзакций.
61
При выполнении любой операции формируется запись журнала, содержащая минимально необходимую информацию для того, чтобы операцию можно было выполнить повторно. Такая запись должна попасть
в журнал во внешней памяти раньше, чем будут записаны изменяемые
операцией данные в таблицы. Только после этого информация об изменениях переносится из оперативной во внешнюю
память в таблицы данных (протокол Write Ahead Log – WAL). По журналу можно восстановить базу данных после сбоя.
Однако в журнал транзакций не попадают данные о временных таб-
лицах (такие таблицы доступны только создавшему их пользователю и
только на время сеанса или транзакции) и о нежурнализируемых табли-
цах (такие таблицы ничем
не отличаются от обычных, кроме того, что
не защищены журналом).
Журнал транзакций содержит копию каждой записи или страницы
базы данных перед ее изменением (исходные образы) и копии всех записей после их изменения (конечные образы данных). В записи журнала
хранятся:
порядковый номер;
идентификатор транзакции;
тип операции;
объект
изменений;
указатель вперед;
указатель назад;
старое значение (исходный образ);
время начала и завершения.
Ниже приведен пример содержимого журнала транзакций.
№
Иденти-
п/п
фикатор
1 ОТ1 0 2 9:12 START
2 ОТ1 1 4 9:13 UPDATE Заказчик Ста-
3 ОТ2 0 8 9:16 START
Указа-
тель
назад
Указа-
тель
вперед
Время Операция
Объект
измене-
ний
Ста-
значе-
рое
значение
рое
ние
Новое
значе-
ние
Новое
значение
62
Окончание таблицы
№
Иденти-
п/п
фикатор
4 ОТ1 2 5 9:17 UPDATE Товар 10 Ста-
5 ОТ1 4 7 9:17 INSERT Заказ 12 Значе-
6 КТ1 0 9 9:18 START
7 ОТ1 5 0 9:19 COMMIT
8 ОТ2 3 0 9:20 COMMIT
9 КТ1 6 10 9:21 UPDATE Заказ 85 Ста-
10 КТ2 9 0 9:21 COMMIT
Указа-
тель
назад
Указа-
тель
вперед
Время Операция
Объект
измене-
ний
Ста-
значе-
рое
значение
рое
значение
рое
ние
Новое
значе-
ние
Новое
значение
ние
Новое
значение
В приведенных обозначениях START – начало транзакции,
COMMIT – ее окончание, INSERT, UPDATE, DELETE – действия транзакции. Все операции каждой транзакции связаны между собой указателями. Например, в строке 7 транзакция ОТ1 ссылается на строку 5, которая является предыдущим действием этой транзакции. Указатель вперед ссылается на следующее изменение, выполненное данной транзакцией.
В строке 4 указатель вперед указывает на строку 5. Нуль в поле
указателя означает конец списка.
Как вы понимаете, объем журнала транзакций за время работы сервера может достигнуть гигантских размеров. Хранить его целиком
и просматривать при сбое совершенно нереально. Для уменьшения времени на повторное выполнение транзакций используют контрольные
точки (КТ – checkpoint
). Это точка времени синхронизации между базой
данных и журналом транзакций. Для создания контрольной точки СУБД
несколько раз в час прерывает обработку текущих запросов, принудительно сбрасывает на диск все буферы с данными, включая буферы,
в которых хранится состояние транзакций (рис. 5.1). Это гарантирует,
что изменения всех транзакций до момента контрольной точки
63
находятся на диске. В журнале транзакций делается запись о контрольной точке.
Рис. 5.1. Использование аппарата контрольных точек
Процесс создания контрольной точки может занимать много времени, но при этом резко сокращает время на восстановление данных
в случае сбоя. Собственно, «точка», о которой говорится, – это начало
процесса, но точка считается выполненной только после того как записаны все буферы с данными, которые имелись на момент начала процесса.
Таким
образом, использование журнала транзакций гарантирует попадание на диск всех изменений до контрольной точки, а использование
аппарата контрольных точек ограничивает размер журнала транзакций.
Во второй части курса лекций отмечалось, что различают:
так называемые мягкие сбои, характеризуемые потерей одной или
нескольких транзакций, но физически не разрушающие базу данных системы
в целом (например, в случае аварийного выключения питания);
жесткие сбои, характеризуемые потерей информации на носите-
лях внешней памяти.
При жестком сбое используется метод наката (rollforward), при
мягком – метод отката (rollback).
В случае мягкого сбоя СУБД проверяет журнал транзакций и запускает процесс восстановления, начиная с последней контрольной точки.
Процесс
восстановления состоит из двух этапов: повторного выполнения завершенных транзакций (REDO) и отмены незавершенных (UNDO).
В первом случае повторно выполняются транзакции, сведения о которых записаны в журнал транзакций, но изменения не внесены в область
данных. Во втором случае изменения, выполненные незавершенной
транзакцией, о чем можно судить по записям в
журнале транзакций, от-
меняются – происходит откат транзакции.
64
Решение вопроса о том, какую транзакцию следует отменить, а какую выполнить повторно, при перезагрузке системы после мягкого сбоя
заключается в следующем. На рис. 5.2 показаны пять возможных вариантов выполнения транзакций до аварийного сбоя системы.
Рис. 5.2. Пример анализа транзакций
Очевидно, что при перезагрузке системы транзакции T3 и T5 должны
быть отменены (они еще не закончились); транзакции T2 и T4 – выполнены повторно (не закончились до КТ), а транзакции типа T1 вообще не
включаются в процесс перезагрузки, так как обновления попали в БД
еще до момента T
, т. е. зафиксированы еще до КТ.
c
Алгоритм восстановления выглядит следующим образом.
1. Создаются два списка транзакций: UNDO (отменить) и REDO (по-
вторить). В список UNDO заносятся все транзакции, выполняющиеся
в момент T
(Т2, Т3), а список REDO остается пустым.
c
2. Осуществляется поиск в журнале транзакций, начиная с записи
контрольной точки.
3. Если в журнале транзакций обнаружена запись Begin Transaction
о начале транзакции T, то эта транзакция также добавляется в список
UNDO (T4 и T5).
4. Если в журнале транзакций обнаружена запись Commit об окон-
чании
транзакции T, то эта транзакция добавляется в список REDO
(T2 и T4) и исключаются из UNDO.
5. Когда достигается конец журнала транзакций, в REDO остаются
T2 и T4, в списке UNDO остаются T3 и T5.
6. После этого система просматривает журнал транзакций, отменяя
транзакции из списка UNDO, а затем просматривает снова вперед, повторно выполняя транзакции
из списка REDO.
65
При восстановлении после жесткого сбоя используется метод
наката (rollforward): cначала база данных восстанавливается до состо-
яния, сохраненного в резервной копии. После этого выполняются все
правильные (зафиксированные) изменения в базе данных по журналу
транзакций, как описано выше.
5.2.3. АУДИТ БАЗЫ ДАННЫХ
Угроза безопасности данных может исходить как от неавторизованных, так и от авторизованных пользователей базы данных. Это могут
быть и злоумышленники извне, пытающиеся получить доступ к данным, и несанкционированные действия работающих или ранее работавших сотрудников. Поэтому отслеживание информации о том, кто, когда
и какие действия выполнял с базой данных
, очень важно, поскольку позволяет вовремя обнаружить и предотвратить инцидент либо расследовать его. Одним из способов сбора и накопления такой информации является аудит баз данных.
Аудит базы данных – процедура выявления некорректных или неавторизованных действий пользователей. Все коммерческие СУБД имеют
специальные средства аудита базы данных, позволяющие отслеживать
все
выполняемые операции в базе данных и связывать каждую операцию с определенным пользователем и определенным сеансом работы.
Хранится эта информация в специальных контрольных журналах.
Эти журналы используются для обнаружения источника нарушений
безопасности системы.
К базовым методам аудита относят:
трассировку;
анализ журналов транзакций;
мониторинг работы сервера и сетевого трафика
сервера баз дан-
ных.
К числу протоколируемых событий в методе трассировки относятся:
аутентификация пользователей (как успешная, так и неудачная);
предоставление прав доступа к базе данных;
создание, изменение и удаление объектов базы данных, вставка,
редактирование и удаление данных;
нарушения ссылочной целостности при модификации данных;
выполнение хранимых
процедур;
66
попытки осуществить потенциально опасные операции без нали-
чия соответствующих прав;
различного рода исключительные ситуации и ошибки в работе
программного обеспечения.
Недостатком метода трассировки является снижение производи-
тельности в нагруженных системах.
Каждая современная СУБД использует журналы транзакций для регистрации всех изменений в базе данных с целью восстановления. Журналы
транзакций могут быть также использованы для интерпретации
и анализа, чтобы определить, какие данные были изменены, когда и какими пользователями.
В случае аудита, основанного на мониторинге сервера баз данных,
перехват и анализ SQL-инструкций выполняются не на уровне сети,
а непосредственно на уровне сервера. Этот подход позволяет отслеживать все SQL-инструкции,
выполняемые ядром СУБД. Такой подход
не влияет на производительность системы и допускает гибкую
настройку аудита на уровне определения интересующих инструкций.
5.3. ЗАЩИТА ДАННЫХ СРЕДСТВАМИ ЯЗЫКА SQL
К этой группе средств защиты можно отнести представления, хра-
нимые процедуры и функции, триггеры.
5.3.1. ПРЕДСТАВЛЕНИЯ
Представления – это виртуальные таблицы, с помощью которых
действительная структура базы данных может быть скрыта от тех или
иных групп пользователей. В результате некоторые пользователи не будут иметь сведений о таблицах, атрибутах или строках таблиц, которые
недоступны через данное представление. Применение представлений
позволяет предоставить каждому пользователю или группе пользователей
ограниченный набор данных, скрывая поля и записи с конфиденциальной информацией. Тем самым ограничивается доступ к данным на
уровне записей, в дискреционной модели разграничения доступа. Разрешение на доступ к представлению должно быть явно предоставлено
или отозвано, независимо от прав доступа к таблицам, из которых оно
строится, реализуя тем самым принцип
минимальных привилегий.
67
Представления создаются оператором языка SQL CREATE VIEW
и широко используются в многопользовательских СУБД MS SQL
Server, DB2, Oracle, PostgreSQL.
С помощью представлений можно ограничить доступ к данным, вы-
давая только часть из них. Это может быть:
подмножество строк базовой таблицы. Например, можно опреде-
лить представление, которое содержит информацию о студентах конкретного факультета, и при этом скрыть
информацию о студентах дру-
гих факультетов;
подмножество столбцов базовой таблицы. Например, можно
определить представление, которое содержит все столбцы таблицы студентов, за исключением столбцов с конфиденциальной информацией;
подмножество строк и столбцов базовой таблицы;
подмножество столбцов, являющихся соединением более чем од-
ной базовой таблицы;
статистическая сводка данных по
базовой таблице. Например,
можно определить представление, содержащее только среднюю успеваемость по группам.
Перечислим преимущества использования представлений.
Повышение защищенности данных. Это позволяет ужесточить
контроль доступа отдельных категорий пользователей к информации
в базе данных.
Обеспечение целостности данных. Если в операторе CREATE
VIEW будет указана фраза WITH CHECK OPTION, то СУБД будет кон
-
тролировать, чтобы в исходные таблицы базы данных не была введена
ни одна из строк, не удовлетворяющих предложению WHERE в определяющем запросе.
Ограничение доступа к данным. Пользователь видит некоторую
упрощенную модель с необходимыми ему данными.
Упрощение структуры сложных запросов.
5.3.2. ПРОЦЕДУРЫ, ФУНКЦИИ, ТРИГГЕРЫ
Хранимые процедуры и функции – это объекты базы данных, которые компилируются и хранятся в ней наряду с таблицами данных.
При этом одна процедура может быть использована в любом количестве
клиентских приложений. что позволяет существенно экономить трудо-
68
затраты на создание прикладного программного обеспечения и эффективно применять стратегию повторного использования кода.
Использование хранимых процедур и функций, как и использование
представлений, позволяет повысить защищенность данных. Доступ
пользователям к данным может быть предоставлен исключительно
через ограниченный набор хранимых процедур, прямой доступ к таблицам предоставляется исключительно узкому кругу пользователей
(
администраторам базы данных, разработчикам программного обеспечения). Хранимые процедуры могут также поддерживать дополнительную логику при выполнении операций над данными, связанную
с проверкой нетривиальных ограничений или с формированием аудиторского следа. Помимо основного преимущества – повышения безопасности можно отметить следующие достоинства использования
хранимых процедур:
повышение производительности: процедуры хранятся в скомпи
-
лированном и оптимизированном виде, а следовательно, выполнение
процедуры происходит быстрее, чем запуск аналогичного кода динамического SQL;
использование хранимых процедур позволяет снизить объем пе-
редаваемых данных: для вызова хранимой процедуры достаточно указать ее имя и значения параметров, а не передавать полный текст запроса;
хранимые процедуры, выполняющие однотипные
действия, могут
переноситься между базами данных с незначительной модификацией,
что позволяет повторно использовать код процедур.
Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Триггеры в основном предназначены для обеспечения целостности и непротиворечивости данных,
а также для отката транзакций.
С точки зрения безопасности данных
триггеры в первую очередь
стоит рассматривать как дополнительный инструмент обеспечения целостности данных. Их используют, когда ограничения целостности
и значений по умолчанию не позволяют добиться нужного уровня функциональности. Часто требуется реализовывать сложные алгоритмы проверки данных, отслеживать изменения значений таблицы, чтобы нужным образом изменять связанные данные. Кроме того,
триггеры могут
69
использоваться для формирования аудиторского следа, например, при
операциях модификации данных записывать в таблицу аудита пользователя факт изменения данных и время изменения.
5.3.3. ПРОТИВОДЕЙСТВИЕ SQL-ИНЪЕКЦИЯМ
Ранее отмечалось, какой урон могут нанести SQL-инъекции. К ме-
тодам противодействия SQL-инъекциям относятся следующие.
1. Фильтрация пользовательского ввода
Самым очевидным решением противодействия SQL-инъекциям является фильтрация пользовательского ввода перед формированием исполняемых запросов.
Например, для числовых значений можно использовать преобразование ввода пользователя к целому типу данных, для строковых данных
выполнять
фильтрацию спецсимволов и ключевых слов или фильтра-
цию по регулярным выражениям и т. п.
Такой подход подразумевает либо использование готовых классов
фильтрации данных, либо их самостоятельную разработку. Недостатком этого подхода можно назвать то, что существуют определенные методы, позволяющие обойти такого рода фильтры, так называемая
обфускация SQL-инъекций.
Обфускация – это
приведение неполного текста или исполняемого
кода программы к виду, сохраняющему ее функциональность, но затрудняющему анализ, понимание алгоритмов работы и декомпиляцию
при модификации. В контексте SQL-инъекций использование этого термина предполагает маскировку спецсимволов и ключевых слов в тексте
пользовательского ввода.
Для обходов различных известных фильтров существуют различные
приемы, например:
замена
логических операций AND и OR их символьными анало-
гами && и ||;
использование кодов вместо их прямого написания;
двойное кодирование символов, использование строковых функ-
ций, добавление SQL-комментариев в текст пользовательского ввода;
вложенное дублирование ключевых слов.
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]