21. Методы защиты базы данных

Защита данных – предотвращение случайного или НСД к ним; гарантия того, что действия пользователей разрешены

Поддержание целостности данных – предотвращение их разрушения при санкционированном доступе; гарантия того, что действия пользователей корректны

Аспекты проблемы защиты данных:

- правовые, общественные и этические (например, имеет ли некоторое лицо юридическое право запрашивать информацию о выделенном клиенту кредите)

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

- организационные (например, каким образом на предприятии, являющемся владельцем системы, принимается решение о том, кому разрешено иметь доступ к тем или иным данным)

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

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

- возможности ОС (например, стирает ли используемая ОС содержимое ОП и дисковых файлов после прекращения работы с ними)

- аспекты, имеющие отношение непосредственно к самой СУБД (например, поддерживает ли используемая СУБД концепцию владельца данных)

Основные требования по безопасности в БД

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

Требования по управлению доступом в БД

Управление доступом в БД – защита данных в БД от НСД

Требования по безопасности, связанные с доступом к БД:

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

- пользователи, которые авторизованы для работы с БД, должны иметь гарантированный доступ к соответствующим данным

- управляемость доступом. Пользователь должен иметь доступ только к тем данным, для работы с которыми он имеет уровень полномочия

Объект доступа – любой элемент БД, доступ к которому субъектов доступа может быть произвольно ограничен

Субъект доступа – любая сущность, способная инициировать выполнение операций над объектами (обращаться к объектам по некоторым методам доступа).

Метод доступа к объекту – операция, определенная для этого объекта (чтение, запись, добавление, удаление, модификация)

Разграничение доступа субъектов к объектам – совокупность правил, определяющая для каждой тройки «субъект-объект-метод», разрешен ли доступ данного субъекта к данному объекту по данному методу

Пользователи могут быть ограничены различными методами доступа к одним и тем же данным

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

Большинство современных СУБД имеют встроенные средства, позволяющие администратору системы определять права пользователей по доступу к различным частям БД. При этом имеется возможность не только предоставить доступ тому или иному пользователю, но и указать разрешенный тип доступа: что именно может делать конкретный пользователь с конкретными данными

Задание прав. Команда GRANT

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

GRANT устанавливает права на объекты базы данных пользователям, ролям или другим объектам базы данных. Когда объект создается, права на него имеет только его создатель и только он может выдавать права другим пользователям или объектам

Для доступа к таблице или обзору пользователь или объект нуждается в правах на SELECT, INSERT, UPDATE, DELETE или REFERENCES. Все права могут быть даны опцией ALL

Для вызова процедуры в приложении пользователь должен иметь права на EXECUTE. Пользователи могут получить разрешение выдавать права другим пользователям передачей прав по списку <userlist>, который задается опцией WITH GRANT OPTION. Пользователь может выдавать другим только те права, которыми располагает сам

Права могут быть даны всем пользователям опцией PUBLIC на месте списка имен пользователей. Указание опции PUBLIC распространяется только на пользователей, а не на объекты базы данных

Права могут быть ликвидированы пользователем, выдавшим их, через команду REVOKE. Если права были выданы с помощью ALL, то и ликвидированы они могут быть только в режиме ALL, если права были выданы с помощью PUBLIC, то и ликвидированы они могут быть только в режиме PUBLIC

Следующая команда передает права пользователю на SELECT и DELETE. Опция WITH GRANT OPTION дает права на их дальнейшую передачу

Примеры:

GRANT SELECT, DELETE ON TBOOK TO MISHA WITH GRANT OPTION;

Эта команда дает право на выполнение процедуры другой процедуре и пользователю.

GRANT EXECUTE ON PROCEDURE PAUTHOR TO PROCEDURE PBOOKAUTHOR, MISHA;

GRANT SELECT, DELETE ON TBOOK TO MISHA WITH GRANT OPTION;

Ликвидация прав. Команда REVOKE

REVOKE ликвидирует права доступа к объектам БД. Отметим некоторые ограничения при использовании команды REVOKE. Ликвидировать права может только тот пользователь, кто их выдал. Одному пользователю могут быть переданы одни и те же права на объект базы данных от любого числа разных пользователей. Команда REVOKE влечет за собой лишение выданных ранее именно этим пользо-вателем прав. Права, выданные всем пользователям опцией PUBLIC, мо-гут быть ликвидированы командой REVOKE только с опцией PUBLIC

Следующая команда ликвидирует у пользователя права на удаление из таблицы:

REVOKE DELETE ON ТВООК FROM MISHA;

А эта команда отменяет право на выполнение процедуры другой процедуре и пользователю:

REVOKE EXECUTE ON PROCEDURE PAUTHOR FROM PROCEDURE PBOOKAUTHOR, MISHA;

Создание группы управления правами – роли

Прежде всего, разберемся с понятием роли. Рассмотрим некоторое множество команд предоставления прав (GRANT) и дадим ему имя. В этом случае вместо перечисления команд GRANT можно, указав имя, сослаться на это множество. Такой подход позволяет одной командой передать пользователю права сразу на несколько объектов. Если пользователей много, то действия по отслеживанию всех их прав становятся достаточно громоздкими и работа с такими множествами существенно ее облегчает. Особенно удобно то, что вместо предоставления прав на какой-либо новый объект или ограничения ранее предоставленных прав каждому из пользователей, можно провести такое изменение в нашем поименованном множестве, которым и является роль

Процедура работы с ролями включает несколько этапов

- создание роли, то есть объявление ее в базе (создание имени и пустого множества)

- формирование списка прав, связанных с ролью (включение элементов – прав в множество)

- формирование прав пользователей на основе ролей

- связывание пользователей с ролями, то есть передача им множества прав, описанных в роли

Формирование прав пользователей на основе ролей

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

Копирование и восстановление БД

Регулярное выполнение операций копирования БД предназначено, прежде всего, для обеспечения возможности восстановления данных после сбоев. Учитывая, что база данных InterBase физически организована в виде одного файла (при наличии файлов тени – нескольких файлов), проблем с копированием базы нет. Единственно, о чем следует помнить, так это о том, что при проведении копирования внешними программами все пользователи должны быть отключены от базы

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

Использование резервной копии InterBase и особенности восстановления утилитой gbak или диспетчером серверов (Server Manager в InterBase 4-5 или IBConsole в InterBase 6) дают ряд преимуществ. При резервном копировании и восстановлении помимо собственно копирова-ния выполняется также ряд дополнительных действий, а именно:

Выполняется сборка "мусора" (удаляются устаревшие версии записей) и чистка таблицы транзакций от транзакций, завершенных

откатом (rollback).

Балансируются индексы.

Освобождается пространство, занимаемое удаленными записями,

и упаковываются оставшиеся данные.

Это позволяет несколько уменьшить размер базы данных и ускорить работу с данными.

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

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

В результате копирования средствами InterBase получается платформно-независимый, устойчивый снимок БД

Благодаря этому данные могут быть переданы в другую операционную систему. Это важно, поскольку различные платформы имеют аппаратно-зависимые форматы файла базы данных и поэтому базы данных не могут быть просто скопированы для переноса на другую платформу. Создание переносимых резервных копий особенно полезно в гетерогенных средах. Необходимо только помнить, что нельзя гарантировать, что копия базы новой версии InterBase пригодна для переноса в старую версию.

Новые версии InterBase могут иметь отличия в физической организации данных. Чтобы модернизировать существующие базы к новой структуре, необходимо:

Перед установкой новой версии InterBase скопировать БД, использующие старую версию утилит копирования

Установить новую версию сервера InterBase.

Как только новая версия установлена, восстановить БД новой версией InterBase. Восстановленные базы данных теперь готовы

использовать все новые возможности сервера InterBase.

Функции резервного копирования и восстановления базы данных можно осуществлять несколькими способами:

Копирование можно выполнить диспетчером серверов (Server Manager) или IBConsole в зависимости от используемой версии.

Для этого используются пункты меню Tasks - Backup. Далее выбираются нужные режимы копирования.

Для восстановления используются пункты меню Tasks - Restore.

Далее выбираются нужные режимы копирования.

Можно также использовать утилиту командной строки gbak, хотя при работе в среде Windows это весьма неудобно.

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

gbak [-B] [options] database target

Синтаксис утилиты для восстановления имеет следующий вид.

tgbak {-C|-R} [options] source database

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

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

 

 Аспекты защиты данных: обеспечение безопасности и секретности данных

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

Причины, вызывающие необходимость восстановления БД:

- пользовательская ошибка

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

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

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

- сбой носителя может возникнуть при попытке записи или чтения файла, требуемого для работы БД

Основные средства физической защиты данных – резервное копирование и журналы транзакций

Резервное копирование – периодическое сохранение файлов БД на внешние носители в момент, когда их состояние является непротиворечивым

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

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

Полная резервная копия включает всю БД. Частичная резервная копия включает часть БД, определенную пользователем. В резервную копию входят только те блоки памяти, которые действительно содержат данные

Резервное копирование может быть полным и инкрементным. Полная копия (level 0 backup) включает все блоки данных БД или табличной области. Инкрементная копия состоит только из тех блоков, которые изменились со времени последнего резервного копирования. Создание инкрементной копии происходит быстрее, чем полной, но возможно только после проведения полного резервного копирования

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

Журнал транзакций – служебный файл или группа файлов, где хранятся записи обо всех завершенных транзакциях с привязкой по времени

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

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

- журнал транзакций и блоки данных, возможно, содержат изменения, которые не были подтверждены. Изменения неподтвержденных транзакций во время восстановления должны быть удалены из файлов данных

Чтобы разрешить эту ситуацию, СУБД выполняет восстановление после сбоев в два этапа:

- прокрутка вперед: применение к файлам данных всех изменений, зарегистрированных в журнале транзакций. Прокрутка вперед обрабатывает столько файлов журнала транзакций, сколько необходимо, чтобы привести БД в состояние на требуемый момент времени. Если вся необходимая информация повторения находится в активном журнале транзакций, СУБД выполняет этот шаг восстановления автоматически при запуске базы данных. После прокрутки вперед файлы данных содержат все как подтверждённые, так и неподтвержденные изменения, которые были зарегистрированы в журнале транзакций

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

Функция секретности данных – их защита от преднамеренного искажения и/или доступа пользователей или посторонних лиц. Для этого вся информация делится на общедоступные и конфиденциальные данные, доступ к которым разрешен только для отдельных групп лиц. Решение этого вопроса относится к компетенции юридических органов или администрации предприятия, для которого создаётся БД, и является внешней функцией по отношению к БД

Санкционирование доступа к данным осуществляется администратором БД, в обязанности которого входит:

- классификация данных в соответствии с их использованием

- определение прав доступа отдельных групп пользователей к отдельным группам данных

- организация системы контроля доступа к данным

- тестирование вновь создаваемых средств защиты данных

- периодическое проведение проверок правильности работы системы защиты, исследование и предотвращение сбоев в ее работе

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

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

Управление доступом к БД. Предоставление прав доступа (привилегий) в системах, поддерживающих язык SQL, осуществляется с помощью двух команд: GRANT (предоставление одной или нескольких привилегий пользователю) и REVOKE (отмена привилегий)

Чтобы упростить процесс управления доступом, многие СУБД предоставляют возможность объединять пользователей в группы или определять роли. Роль – совокупность привилегий, предоставляемых пользователю и/или другим ролям. Такой подход позволяет предоставить конкретному пользователю определенную роль или соотнести его определённой группе пользователей, обладающей набором прав в соответствии с задачами, которые на нее возложены