35
обеспеченных принадлежностью к некоторой роли.
Фиксированные роли базы данных оказывают непосредственное влияние
на доступ к объекту, так как определяют права на изменение, создание, запись и
управление объектами и пользователями базы данных.
Однако распознание пользователя в SQL Server еще не дает права
пользователю на оперирование базами данных, расположенных на сервере. При
этом назначение прав на оперирование базой данных также не гарантирует
распознавание сервером.
Таким образом, например, процесс перемещения базы данных и ее
разрешений на другой сервер невозможен без параллельного перемещения
регистрационных записей сервера, так как в результате могут возникнуть казусы
с пользователями, которые определены в базе данных, но не зарегистрированы
на сервере.
2.4 Восстановление и создание резервных копий, целостность базы данных
Перед настройкой резервного копирования следует определиться с
моделью восстановления. Оптимальный выбор предполагает оценку требований
к восстановлению и критичность потери данных путем сопоставления их с
накладными расходами на выполнение той или иной модели.
Базу данных MS SQL можно разбить на две части: собственно, базу
данных и лог транзакций к ней. База данных состоит из служебных и
пользовательских данных на данный момент времени, в состав лога транзакций
входит история всех модификаций базы данных за определенный интервал
времени; наличие лога транзакций дает возможность выполнить откат состояния
базы на любой момент времени.
Для применения в производственных средах дается возможность выбора
из двух моделей восстановления – простой и полной. Также в наличии имеется
модель с неполным протоколированием, однако ее использование целесообразно
только в качестве дополнения к полной модели на время крупномасштабных
массовых операций, когда отсутствует необходимость в восстановлении базы на
указанный период времени.
36
Простая модель выполняет резервное копирование только базы данных,
значит, восстановление состояния базы данных возможно только на момент
создания резервной копии, все модификации во временном интервале между
созданием последней резервной копии и сбоем будут утеряны. Однако простая
схема обладает небольшими накладными расходами: необходимым является
только хранение копии базы данных, при этом производится автоматическое
усечение лога транзакций, и, следовательно, не происходит увеличение его в
размерах. Помимо этого, процесс восстановления является простым и требует
достаточно ограниченного времени.
Полная модель дает возможность выполнить восстановление базы на
любой произвольный момент времени, однако предполагает, что помимо
резервных копий базы, осуществляется хранение копии лога транзакций за весь
период, для которого может появиться необходимость в восстановлении. В
процессе активной работы с базой размер лога транзакций, и, как результат,
размер архивов, могут быть достаточно велики. Сложность процесса
восстановления и продолжительность по времени также существенно выше.
Выбирая модель восстановления, необходимо осуществить сравнение
затрат на восстановление и затрат, необходимых для хранения резервных копий,
помимо этого, необходимо учесть степень наличия и квалификации персонала,
ответственного за выполнение восстановления. Процесс восстановления при
полной модели предполагает наличие у персонала высокой квалификации и
определенных знаний, тогда как при простой схеме достаточным является
следование инструкции.
Для баз, имеющих небольшой объем добавления информации,
целесообразным является использование простой модели с большой частотой
копий, позволяющей выполнять быстрое восстановление и продолжение работы
с ручным вводом потерянных данных. Использование полной модели оправдано
в случае недопустимости потери данных и значительных затрат на их возможное
восстановление.
Далее следует остановиться на видах резервных копий.
37
Под полной копией базы данных понимается содержимое базы данных и
часть активного лога транзакций за тот период, за который было выполнено
формирование резервной копии (другими словами, информация обо всех
незавершенных и текущих транзакциях). Полная копия дает возможность
осуществлять полное восстановление базы данных на момент создания
резервной копии.
Полная копия обладает одним существенным недостатком, который
заключается в хранении всей информации базы данных. При необходимости
частого создания резервных копий очень остро встает вопрос неэффективного
использования дискового пространства, поскольку большая часть хранилища
содержит абсолютно одинаковые данные. Чтобы устранить этот недостаток,
используются так называемые разностные копии базы данных, содержащие
только информацию, которая подверглась изменению с момента последнего
полного копирования.
Следует обратить внимание, что в разностную копию входят данные от
момента последнего полного копирования, то есть каждая из последующих
разностных копий состоит из данных предыдущей (однако они могут быть
изменены), что ведет к постоянному росту размера копии. Одна полная и одна
разностная копия (чаще всего, последняя) являются достаточным набором для
восстановления. При выборе количества разностных копий следует
руководствоваться приростом их размера, при достижении размера разностной
копии половины полной целесообразным является создание новой полной
копии.
Резервная копия журнала транзакций используется только при полной
модели восстановления, в ее состав входит копия журнала транзакций с момента
создания предыдущей копии.
Нельзя не упомянуть один важный аспект – отсутствие связи между
копиями журнала транзакция и копиями базы данных, а также отсутствие в
копиях журнала транзакций информации предыдущих копий, следовательно,
при восстановлении базы данных необходимым является наличие непрерывной
38
цепочки копий того периода, в течение которого предполагается выполнение
отката состояния базы. При этом внутри этого интервала должен располагаться
момент, на который было выполнено последнее успешное копирование.
Чтобы понимать процессы восстановления и цели разных видов
резервных копий, целесообразно подробнее остановиться на устройстве и работе
журнала транзакций. Как известно, транзакцией называют логическую операцию
(минимально возможную), имеющую смысл и выполняемую только полностью.
При таком подходе обеспечивается непротиворечивость и целостность данных в
любых ситуациях, поскольку недопустимым является промежуточное состояние
операции. Ответственность за контроль над любыми модификациями в базе
возлагается на журнал транзакций.
При выполнении любой операции осуществляется добавление в журнал
транзакций записи о начале транзакции, каждая из записей получает уникальный
номер (
LSN
) из неразрывной последовательности, любая модификация данных
влечет добавление соответствующей записи в журнал, а о завершении операции
в журнале свидетельствует отметка о фиксации (закрытии) транзакции.
При каждом из запусков система выполняет анализ журнала транзакций
с откатом всех незафиксированных транзакций, вместе с этим осуществляется
накат изменений, зафиксированных в журнале, на запись которых на диск еще
не была выполнена. Благодаря этому появляется возможность использования
кэширования и отложенной записи без опаски за целостность данных даже в
ситуациях, когда системы резервного питания отсутствуют.
Часть журнала, содержащая активные транзакции и используемая для
восстановления данных, имеет название активной части журнала. В ее начале
находится номер, называемый минимальным номером восстановления (
MinLSN
)
В самом простом случае
MinLSN
является номером записи первой из
незавершенных транзакций.
Практика показывает, что данные закрытой транзакции могут быть еще
не сохранены на диск и перемещение
MinLSN
приведет к невозможности
восстановлению данной операции. Для избегания подобных ситуаций
39
существует понятие контрольной точки. Создание контрольной точки
осуществляется автоматически при наступлении ряда следующих условий:
выполнение в базе данных операций, имеющих минимальную
регистрацию, например, выполнение операции массового копирования для базы
данных, которая соответствует модели восстановления с неполным
протоколированием;
остановка экземпляра SQL Server при помощи инструкции
SHUTDOWN
или при остановке служюы SQL Server (
RMSSQLSERVE
). И для того,
и для другого случая будет осуществлено создание контрольной точки каждой
из баз данных в экземпляре SQL Server;
создание резервной копии базы данных;
выполнение действия, которое требует отключения базы данных. В
качестве примеров можно указать присвоение значения
ON
параметру
CLOSEAUTO_
и закрытие последнего соединения пользователя с базой данных,
а также изменение параметра базы данных, которое требует перезапуска базы
данных;
при периодическом создании экземпляром SQL Server в каждой из
баз данных автоматических контрольных точек для уменьшения времени
восстановления базы данных;
удаление или добавление файлов баз данных с применением
инструкции
DATABASEALTER
;
выполнение инструкции
CHECKPOINT
. Срабатывание контрольной
точки осуществляется в текущей базе данных соединения.
В соответствии с порядком следования событий,
MinLSN
присваивается
значение или номера записи контрольной точки, или начала самой старой из
незавершенных операций.
Целесообразно подробнее остановиться на моделях восстановления. Для
примера, рассматривается случай наличия в простой модели на момент сбоя
одной полной и двух разностных копий (рисунок 4).
40
02.12.2018 03.12.2018 04.12.2018
05.12.2018
05.12.2018
Сбой
02.12.2018 03.12.2018 04.12.2018
Полное
копирование
Разностное
копирование
Рисунок 4. Простая модель восстановления
Выполнение резервного копирования производилось раз в сутки и
создание последней копии произошло в ночь с четвертого на пятое декабря. Сбой
произошел вечером пятого декабря до момента создания очередной копии. В
данном случае необходимым является последовательное восстановление полной
и последней разностной копии, при этом произойдет потеря данных за
последний рабочий день. Если в силу каких-либо причин данные копии от
четвертого декабря тоже будут повреждены, существует возможность
восстановления предыдущей копии, однако будет потерян еще один день
работы. Вместе с тем, повреждение копии за третье декабря никак не отразится
на возможности успешного восстановления данных на вечер четвертого декабря
при наличии соответствующей копии.
Теперь будет рассмотрена аналогичная ситуация в случае использования
полной модели восстановления (рисунок 5). Резервные копии выполняются
также один раз в сутки в соответствии с принципом «полная копия +
разностные», помимо этого, несколько раз в сутки осуществляется копирование
лога транзакций.
41
02.12.2018 03.12.2018 04.12.2018
05.12.2018
05.12.2018
Сбой
02.12.2018 03.12.2018 04.12.2018
Полное
копирование
Разностное
копирование
Копирование
журнала транзакций
Рисунок 5. Полная модель восстановления
Процесс восстановления при использовании подобной модели
представляется более сложным. Прежде всего, необходимым является ручное
создание резервной копии заключительного фрагмента журнала (на рисунке 5
выделена красным цветом), то есть фрагмент журнала с момента прошлого
создания копии и до сбоя. Если это не будет осуществлено, то восстановление
базы представляется возможным только до состояния на момент создания
последней копии журнала транзакций.
При этом повреждение файла копии журнала за прошлый день не будет
препятствовать восстановлению актуального состояния базы, однако внесет
ограничения на момент создания последней копии, то есть текущие сутки.
После этого осуществляется последовательное восстановление полной и
разностной копии, а также цепочки копий журнала транзакций, которая создана
после резервного копирования, последней восстанавливается копия
заключительного фрагмента журнала, что дает возможность восстановления
базы прямо на момент сбоя или произвольный момент, который ему
предшествует.
В случае повреждения последней разностной копии, то при
использовании простой модели это вызовет потерю еще одного из рабочих дней,
42
использование полной модели даст возможность восстановления предпоследней
копии, после чего потребуется еще выполнить восстановление всей цепочки
копий лога транзакций от момента предпоследней копии и до аварии. Глубина
восстановления находится в соответствии с глубиной непрерывной цепочки
логов.
Вместе с тем, при повреждении одной из копий лога транзакций, можно
допустить, предпоследней, восстановление данных является возможным только
на момент последней резервной копии плюс период в неповрежденной цепочке
копий журналов. Например, если создание журналов осуществлялось в 12, 14, 16
часов и поврежденным является журнал, который создавался в 14 часов, то при
наличии суточной копии существует возможность восстановления базы до
момента окончания непрерывной цепочки, то есть до 12 часов.
2.5 Выводы по второй главе
Во второй главе работы были рассмотрены встроенные средства
безопасности MS SQL Server.
Исследована структура обеспечения безопасности для MS SQL Server.
Определено, что в системе безопасности MS SQL Server реализуется ролевой и
дискреционный подходы к управлению доступом и обладает двумя уровнями:
уровнем сервера и уровнем базы данных.
Выяснено, что не существует некоторого универсального решения,
которое будет на протяжении долгого времени предоставлять достаточный
уровень защиты базы данных при работе внутри клиент-серверной архитектуры.
Построение политики безопасности нельзя рассматривать как набор
разрозненных мероприятий, которые ориентированы на защиту от конкретной
угрозы. Это должен быть именно комплекс мер, так как прочность защиты
строится на базе взаимосвязи всех технологий.
Рассмотрены технологии реализации контроля и разграничения доступа
MS SQL Server. Уровень базы данных для пользователя реализует два сценария
предоставления привилегий: прикрепление фиксированной роли базы данных,
назначение привилегий я помощью оператора SQL GRANT.
43
Изучены технологии восстановления и создания резервных копий, а
также обеспечения целостности базы данных с использованием встроенных
инструментов MS SQL Server.
44
Глава 3. Разработка политики безопасности для ООО «СТП»
3.1 Исследование технологий работы ООО «СТП» и организации
деятельности сети в компании
Основным направлением деятельности предприятия Общество с
ограниченной ответственностью «СТП» является осуществление технической
поддержки информационных систем предприятий и организаций, серверной и
сетевой инфраструктуры.
Основным клиентом ООО «СТП» является «Национальный медицинский
исследовательский центр нейрохирургии имени академика Николая
Николаевича Бурденко».
Помимо основной деятельности предприятием ООО «СТП» разработан
ряд собственных программных продуктов, среди которых следует особо
выделить приложение «Электронная история болезней (e-med)», являющейся
современным программным обеспечением для медицинских центров. Данное
приложение позволяет:
осуществлять хранение практически неограниченного количества
историй болезней в электронном виде;
прикреплять в историю болезни пациента не только его фотографии,
но и всех его анализов, рентгеновских снимков, результатов УЗИ и др;
вести описание всех жалоб клиента, его прежних заболеваний,
наличие аллергии, диагнозов и произведенного лечения;
хранить данные амбулаторной карты пациента № 025/У, а также
медицинскую карту стоматологического больного № 043/У;
формировать различную отчетность.
Предприятие ООО «СТП» имеет иерархическую структуру, во главе
находится генеральный директор. Однако, при необходимости разработки
проектов большого масштаба в структуре предприятия допустимым является
применение политики ролей.
Организационная структура предприятия имеет вид, представленный на
рисунке 6.