Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Аудит базы данных

Аудит базы данных

Классификация подходов к аудиту баз данных, а также к реализации структуры журнала аудита. Обоснование выбора программного обеспечения для разработки подсистемы аудита. Разработка подсистемы аудита базы данных информационной системы сопровождения ремонта.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 30.06.2017
Размер файла 987,2 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

Размещено на http://www.allbest.ru/

Содержание

  • Введение
  • 1. Обзор подходов к аудиту баз данных
    • 1.1 Классификация подходов к аудиту баз данных
    • 1.2 Аудит на уровне сервера
    • 1.3 Аудит на уровне базы данных
    • 1.4 Аудит базы данных с помощью триггеров
    • 1.5 Аудит базы данных по журналу транзакций
    • 1.6 Обоснование выбора подхода к аудиту БД разрабатываемой подсистемы
  • 2. Обзор подходов к реализации структуры журнала аудита
    • 2.1 Размещение журнала аудита в отдельном файле
    • 2.2 Размещение журнала аудита в дополнительных таблицах
    • 2.3 Обоснование выбора структуры журнала аудита
  • 3. Обоснование выбора ПО для разработки подсистемы аудита
    • 3.1 Анализ и выбор СУБД
    • 3.2 Выбор среды разработки
  • 4. Обзор встроенных в СУБД средств отслеживания изменений БД
    • 4.1 Журнал транзакций
    • 4.2 Change Tracking (CT)
    • 4.3 Change Data Capture (CDC)
    • 4.4 SQL Server Audit
    • 4.5 SQL Server Profiler
  • 5. Обзор существующих программ для аудита
  • 6. Разработка подсистемы аудита БД информационной системы сопровождения ремонта
    • 6.1 Инфологическое проектирование
    • 6.2 Логическое проектирование
    • 6.3 Физическое проектирование
  • 7. Разработка приложения
    • 7.1 Средства для работы с базами данных
      • 7.1.1 BDE
      • 7.1.2 InterBase
      • 7.1.3 dbExpress
      • 7.1.4 ADO
    • 7.2 Реализация приложения
    • 7.3 Описание форм
      • 7.3.1 Форма «Выбор БД»
      • 7.3.2 Форма «Подсистема аудита»
      • 7.3.3 Диалоговое окно для настроек
  • 8. Тестирование подсистемы аудита
  • Заключение
  • Список использованных источников
  • Приложение 1 Листинг главной процедуры
  • Приложение 2 Листинг триггера
  • Приложение 3 Листинг процедуры фильтрации

Введение

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

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

- получение информации о том, кто, когда и откуда производил изменения структуры БД и/или данных;

- отслеживание истории изменения структуры БД и/или данных;

- уведомление об изменениях структуры БД и/или данных.

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

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

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

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

1. Обзор подходов к аудиту баз данных

1.1 Классификация подходов к аудиту баз данных

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

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

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

По компонентам:

- на уровне сервера;

- на уровне базы данных.

По способу нахождения изменений:

- с помощью триггеров;

- по журналу транзакций.

1.2 Аудит на уровне сервера

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

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

1.3 Аудит на уровне базы данных

Обычно у каждой информационной системы есть администратор, который сопровождает ее с помощью SQL-интерфейса, и его действия не фиксируются в журнале операций, производимых на уровне сервера. Таким образом сложно отследить возможные несанкционированные действия со стороны администратора. Также сама система не может быть полностью защищена от уязвимостей, позволяющих ее взломать, что может привести к нежелательным изменениям в базе данных, которые не будут отображаться в журнале событий [2].

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

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

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

1.4 Аудит базы данных с помощью триггеров

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

С помощью триггеров можно реализовать отслеживание и протоколирование операций, связанных как с изменением данных в базе, так и с изменением структуры базы данных. События, связанные с изменением данных в таблицах базы данных или представлениях, описываются такими операциями DML (Data Manipulation Language), как INSERT, DELETE или UPDATE. Триггеры, срабатывающие на эти события языка обработки данных DML, называются триггерами DML. Триггеры же, активирующиеся в ответ на события, связанные с изменениями в структуре базы данных, например, CREATE, DROP, ALTER и т.д., называются триггерами DDL (Data Definition Language) [2].

Кроме триггеров, отслеживающих изменение в структуре базы данных и данных в ней, существуют триггеры входа, которые срабатывают в ответ на событие LOGON. Это событие возникает при установке пользовательских сеансов. Триггеры входа можно использовать не только для проверки подлинности при входе и управления сеансами сервера, но и для отслеживания различных попыток входа в систему.

Метод мониторинга с помощью триггеров также используется и в некоторых встроенных средствах аудита СУБД, в которых система создает набор триггеров по определенным параметрам в автоматическом режиме. Примерами таких решений для отслеживания изменений структуры базы данных или данных в ней является встроенное в СУБД Oracle средство AUDIT или средство Change Tracking, встроенное в SQL Server.

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

1.5 Аудит базы данных по журналу транзакций

В связи с некоторыми недостатками аудита с помощью триггеров распространение также получил подход к мониторингу изменений в базе данных, основанный на работе с журналом транзакций, из которого можно извлечь информацию об операциях DDL и DML. Для некоторых СУБД существуют системы аудита по журналу транзакций, созданные в виде отдельных продуктов, например, Change Data Capture или Oracle Audit Vault. Эти системы обладают возможностью отслеживать изменения, зафиксированные в журнале транзакций, применять различные фильтры для выборки интересующих пользователя записей, формировать удобные отчеты с этими изменениями в разных форматах и т.д.

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

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

1.6 Обоснование выбора подхода к аудиту БД разрабатываемой подсистемы

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

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

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

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

2. Обзор подходов к реализации структуры журнала аудита

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

2.1 Размещение журнала аудита в отдельном файле

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

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

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

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

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

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

2.2 Размещение журнала аудита в дополнительных таблицах

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

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

Вышеизложенный метод усложняется путем разделения обработки трех операций INSERT, DELETE и UPDATE [5]. При этом полученная информация сохраняется в трех дополнительных таблицах для каждой таблицы базы данных. В первую таблицу записывается общая информация об изменениях (кем были внесены изменения, с какого компьютера, удачна ли была попытка изменения). Первая таблица связана с двумя другими отношением один-к-одному. Во вторую таблицу заносится полная строка данных при операциях вставка (INSERT) и удаление (DELETE). Третья таблица предназначена для фиксирования измененного значения при операции UPDATE. В результате получается наиболее подробный вариант аудита, без значительных потерь производительности. Недостатком является множество дополнительных таблиц.

Другим вариантом структуры журнала аудита является создание единой таблицы, в которой фиксируются все изменения [6]. Такая таблица может содержать первичный ключ модифицируемой таблицы, ее название, название измененного поля и его новое значение. В случае отслеживания изменения структуры базы данных таблица содержит тип события (создание, удаление или изменение объекта), тип объекта, название объекта. Данный метод позволяет реализовать универсальные для всех таблиц триггеры, но неэффективно расходует ресурсы системы, так как содержит много избыточной информации для каждой записи. Кроме того, возникает проблема записи значений различных типов в поле с фиксированным типом. Эта проблема может быть решена несколькими способами:

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

2) Запись в поле с универсальным типом (sql_variant). При таком подходе каждая запись таблицы аудита содержит значение измененного столбца для конкретной таблицы. Также используется явное или неявное приведение типов, однако при этом снижается скорость взаимодействия с журналом аудита.

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

2.3 Обоснование выбора структуры журнала аудита

Структура журнала аудита выбирается на основе оценки важности следующих критериев:

- влияние аудита на производительность системы;

- необходимый размер журнала;

- скорость взаимодействия системы с журналом;

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

- сложность реализации с учетом особенностей базы данных, подлежащей аудиту.

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

3. Обоснование выбора ПО для разработки подсистемы аудита

3.1 Анализ и выбор СУБД

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

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

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

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

- резервное копирование и восстановление данных в случае различных сбоев.

На данный момент существует несколько классификаций СУБД: по модели данных (реляционные, иерархические, сетевые, объектно_ориентированные, объектно_реляционные), по степени распределенности (локальные и распределенные) и по способу доступа к базе данных (файл_серверные и клиент_серверные) [8].

Что касается классификации по первому признаку, то очевидно, что большинство разработчиков ориентируются на реляционные СУБД.

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

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

В файл_серверных СУБД данные обычно располагаются в каталогах одного компьютера, который постоянно подключен к сети. СУБД же располагается на каждой рабочей станции, и доступ СУБД к данным реализуется через локальную сеть. Преимуществом таких СУБД является легкость их установки, простота использования, отсутствие потребности в дополнительном программном обеспечении и небольшая нагрузка на процессор файлового сервера. Но в связи с тем, что файл-серверные СУБД имеют несколько упрощенную архитектуру, они не имеют возможности поддерживать все функции СУБД, например, в них нет функции автоматического восстановления данных после возможных сбоев, не ведется журнал транзакций и т.п. К недостаткам таких СУБД можно также отнести высокую загруженность локальной сети и сложность обеспечения высокой надежности и безопасности данных. Следовательно, файл-серверные СУБД используются для решения относительно несложных задач, например, предполагающих небольшое количество пользователей или небольшое количество обрабатываемых данных. Тем не менее такие СУБД имеют довольно широкую область применения и используются для ведения персональных баз данных и в небольших организациях, расположенных чаще всего в одном здании, с небольшим количеством пользователей и невысокой частотой обновления данных. В таких условиях использование файл-серверных СУБД является вполне оправданным. На сегодняшний день существует довольно много файл-серверных СУБД, но наиболее распространенными из них являются Microsoft Access, Borland dBase, Corel Paradox, Microsoft FoxPro и др.

По описанным выше особенностям и недостаткам файл_серверных СУБД для крупных организаций их использование является неприемлемым. В этом случае целесообразно использовать клиент_серверные СУБД. Они позволяют клиенту и серверу обмениваться информацией следующим образом: клиент посылает запрос на сервер базы данных, который располагается на машине с данными, сервер базы данных в свою очередь принимает этот запрос, отыскивает в данных нужную информацию и передает ее клиенту. При этом большая часть вычислительной нагрузки ложится на сервер, следовательно, недостатком клиент_серверных СУБД являются повышенные требования к серверу. Также к минусам таких СУБД можно отнести сложность их установки и сопровождения, но для крупных предприятий, на которых и используются клиент_серверные СУБД, эти недостатки не играют особой роли. К тому же они обладают рядом значительных преимуществ. Одним из них является то, что такие СУБД гораздо менее требовательны к пропускной способности компьютерной сети и обладают большей производительностью, чем файл_серверные СУБД, так как сервер производит поиск данных по параметрам запросов, которые передает ему клиент, а результат выполнения этих запросов обычно намного меньше по объему, чем фрагменты файлов. Также к достоинствам клиент_серверных СУБД можно отнести удобство управления и возможность обеспечения таких важных для больших организаций характеристик, как высокая безопасность и надежность. Примерами клиент_серверных СУБД являются Oracle Database, MySQL, Interbase, Microsoft SQL Server и т.д.

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

В настоящее время абсолютными лидерами на рынке СУБД, отвечающих заданным параметрам, являются компании Oracle, Microsoft и IBM. Их общая доля на рынке составляет около 90%, а наиболее часто используемыми СУБД являются Oracle Database, IBM DB2 и Microsoft SQL Server [9].

Корпорация Oracle с начала ее основания специализировалась на создании реляционных СУБД. На данный момент Oracle занимает одну из лидирующих позиций на рынке СУБД и лидирует на платформах UNIX и Windows. Причиной популярности продуктов Oracle, в том числе и СУБД Oracle Database, являются высокие эксплуатационные характеристики СУБД. К ним можно отнести поддержку большого количества платформ, очень высокую надежность, высокую скорость обработки данных, наличие большого спектра средств разработки, администрирования и мониторинга, ориентацию на Интернет_технологии и многое другое. Однако минусами СУБД Oracle является высокая стоимость самой СУБД и ее сопровождения, потребность в высококвалифицированном персонале для поддержки базы данных, сложность администрирования и использования. Тем не менее все затраты на внедрение и освоения данной СУБД впоследствии окупаются надежной и эффективной работой.

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

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

В результате рассмотрения трех лидирующих СУБД, их основных характеристик, достоинств и недостатков, можно сделать вывод о том, что все они имеют очень широкие возможности и не уступают друг другу в таких важных характеристиках, как производительность, высокая скорость обработки данных и масштабируемость. Одной из наиболее важных отличительных особенностей Microsoft SQL Server от Oracle Database и IBM DB2 является то, что она не является мультиплатформенной, однако стоимость данной СУБД и ее сопровождения несколько ниже. Возможности же для аудита базы данных есть во всех трех, представленных выше СУБД: в них есть как поддержка хранимых процедур и триггеров, так и встроенных средств аудита, кроме того все три продукта имеют системы аудита, выпускаемые в виде отдельных продуктов, осуществляющие мониторинг данных по журналу транзакций.

Очевидно, что при выборе СУБД основным критерием является оценка того, насколько она удовлетворяет основным требованиям, предъявляемым к информационной системе и программному обеспечению. Разрабатываемую подсистему аудита планируется использовать на платформе Windows. И ввиду того, что Microsoft SQL Server не уступают другим СУБД, удовлетворяет требованиям информационной системы сопровождения ремонта и уже используется на предприятии, подсистема аудита базы данных для этой информационной системы будет разработана с использованием именно этой СУБД.

3.2 Выбор среды разработки

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

Приложение будет реализовано с помощью такой среды разработки программного обеспечения, как Delphi XE2. Эта среда разработки используется для быстрой (RAD) разработки программного обеспечения для различных операционных систем. Язык Delphi сочетает в себе возможности объектно_ориентированного языка, мощную визуальную платформу для разработки, быструю компиляцию, подключение к разнородным базам данных и т.д. Одним из главных достоинств среды разработки Delphi является совокупность простоты языка и генерации машинного кода, за счет чего и достигается высокая скорость разработки приложений. Именно из_за этих плюсов, а также наличия всего необходимого для разработки интерфейса для подсистемы аудита базы данных, была выбрана среда разработки Delphi XE2.

4. Обзор встроенных в СУБД средств отслеживания изменений БД

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

- уменьшение времени на реализацию системы аудита;

- отсутствует необходимость в изменении структуры базы данных;

- имеются встроенные средства очистки данных;

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

4.1 Журнал транзакций

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

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

Физическая архитектура журнала транзакций содержит части, которые называются виртуальными файлами журналов. Это вспомогательные средства для облегчения внутреннего управления журналом транзакций. Физически записи журнала хранятся в одном или нескольких LDF_файлах, которые и образуют журнал транзакций.

Основной целью файла LDF является обеспечение концепции ACID (атомарность, согласованность, изолированность, долговечность).

Атомарность (Atomicity) гарантирует, что никакая транзакция не будет зафиксирована в системе частично, а будут выполнены все ее подоперации или не будет выполнено ни одной.

Согласованность (Consistency) означает, что система находится в согласованном состоянии перед началом транзакции и должна оставаться в нем после завершения транзакции.

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

Долговечность (Durability) означает, что, если пользователь получил подтверждение о выполнении транзакции от системы, он может быть уверен в том, что сделанные им изменения не будут отменены из_за какого_либо сбоя.

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

Microsoft SQL Server не выполняет протоколирование в случаях, когда могут возникнуть проблемы с недостатком дискового пространства при обнаружении быстрого увеличения журнала транзакций.

Для некоторых операций, например, CREATE INDEX, Microsoft SQL Server не ведет журналирование для каждой новой страницы. Вместо этого Microsoft SQL Server записывает достаточно информации, чтобы определить, как CREATE INDEX отработал, и принять решение фиксации изменения или осуществления отката.

4.2 Change Tracking (CT)

Функция Change Tracking не предназначена для получения всей информации об изменениях, она предназначена, чтобы определить, была изменена строка или нет с наименьшими затратами ресурсов системы.

Change Tracking определяет ID измененной строки, но не предоставляет информацию об измененных значениях. Поэтому при операциях UPDATE или DELETE нельзя узнать исходное значение до обновления или удаления записи. Изменения в вычисляемых столбцах, выполнение оператора SELECT и доступ к объекту базы данных также не отслеживаются.

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

4.3 Change Data Capture (CDC)

Change Data Capture также собирает информацию об изменениях данных - вставке, удалении и обновлении, но предоставляет более подробную информацию, чем Change Tracking. Для операций INSERT и DELETE Change Data Capture захватывает всю строку, которая была вставлена или удалена. Для операции UPDATE, эта функция захватывает две строки - до и после обновления, таким образом доступны как старые, так и новые значения.

Функция Change Data Capture не требует изменения структуры существующих таблиц, вся информация сохраняется в таблицах изменений. Первые столбцы таблицы изменений хранят определенную информацию о транзакции, в том числе тип операции (удаление, вставка, обновление) и идентификатор измененного столбца. Остальные столбцы идентичны исходной таблице и хранят захваченную информацию. Если структура исходной таблицы изменяется, структура таблицы изменений, соответственно, обновляется.

Как и в Change Tracking, в Change Data Capture есть встроенные средства очистки, которые удаляют устаревшую информацию по истечении заданного времени. Другое сходство между этими двумя функциями заключается в том, что ни одно из них не предоставляет информацию о том, кто и когда изменил данные.

4.4 SQL Server Audit

SQL Server Audit предоставляет более подробную информацию о событиях, чем Change Tracking и Change Data Capture. Эта функция предоставляет информацию о том, кто совершил манипуляции в базе данных, что было изменено и когда, а также обеспечивает фильтрацию отслеживаемых событий. В то же время SQL Server Audit не фиксирует имя хоста или IP_адрес компьютера, вызвавшего событие, а для некоторых действий (например, SELECT и UPDATE) не отслеживаются сведения о данных, к которым было применено это действие.

SQL Server Audit отслеживает и протоколирует события на двух уровнях - уровне сервера и уровне базы данных. Уровни аудита настраиваются независимо друг от друга, что обеспечивает большую гибкость и тщательность аудита. Результаты аудита могут быть сохранены в двоичном файле, журнале событий Windows или журнале событий SQL Server.

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

4.5 SQL Server Profiler

Инструмент SQL Profiler предназначен для отслеживания всех событий, происходящих в SQL Server. Он используется для анализа производительности работы базы данных и поиска проблем при выполнении запросов. Profiler также может быть применен для аудита, в том числе и аудита безопасности.

SQL Profiler имеет визуальный интерфейс и позволяет сохранять информацию о каждом событии в таблицу или файл аудита в формате XML. События делятся на несколько категорий: активность обычного пользователя, действия администратора базы данных, события сервера и т.д. Регистрируемая информация содержит дату и время события, идентификатор пользователя, тип события, результат, источник, имена объектов, к которым осуществляется доступ.

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

5. Обзор существующих программ для аудита

Существует ряд сторонних продуктов, предназначенных для упрощения отслеживания изменений данных в базах данных. Log Explorer, Lumigent Entegra, ApexSQL Audit и NetWrix SQL Server Change Reporter разработаны специально для SQL Server.

Ключевыми функциями NetWrix являются:

- фиксирование изменений, вносимых в базы данных, таблицы, схемы, пользователей, полномочия, сохраненные процедуры, логины и другие объекты SQL Server;

- фиксирование всех изменений, вносимых в содержимое базы данных;

- фиксирование на ранних стадиях неавторизованных и нежелательных изменений, которые могут привести к «падению» сервера и базы данных;

- отображение в отчетах информации о том, кто совершил изменение, когда это произошло, где и с какой рабочей станции;

- создание отчетов по запросам;

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

Log Explorer использует журналы транзакций SQL Server вместе с журналами пользователей, таким образом получая всю необходимую информацию. Log Explorer предоставляет следующие возможности:

- фиксирование всех изменений базы данных;

- отмена или повтор транзакции, внесение необходимых изменений;

- откат строки к определенному моменту времени;

- поиск по удаленным записям;

- анализ нагрузки на систему.

У Log Explorer также есть дополнительное преимущество - мгновенное уведомление о изменениях объектов. Программа работает на сервере, отслеживает эти события, а затем отправляет подробные отчеты по электронной почте.

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

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

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

Самым популярным продуктом компании ApexSQL является Universal Studio. Полный пакет программных инструментов Universal Studio включает в себя следующие функции:

- ведение аудита баз данных и их восстановление;

- перевод данных в пакеты T_SQL сценариев, их запуск и установка;

- разработка и очистка неиспользуемых процедур;

- документация в формате .doc;

- внедрение и редактирование SQL Server;

- генерация кода;

- синхронизация баз данных;

- создание отчетов в HTML.

Программа ApexSQL Audit входит в пакет Universal Studio и предназначена для мониторинга информации и отчетности на SQL_сервере, автоматически генерируя триггерную схему для проведения аудита базы данных Microsoft SQL Server.

ApexSQL Audit обладает следующими ключевыми особенностями:

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

- настраиваемое создание отчетов;

- мониторинг изменений схемы базы данных;

- поддержка SQL 2005;

- сформированные отчеты могут быть переведены в форматы Excel, txt, HTML, а также их можно распечатать;

- просмотр объектов DDL непосредственно из приложения и много других функций и возможностей.

ApexSQL Log - это инструмент Universal Studio, способный читать активные журналы транзакций, отдельные LDF_файлы и резервные копии журналов транзакций, как обычных, так и хранящихся в сжатом виде. Данный инструмент может просматривать все операции (как DML, так и DDL) и анализировать, какие данные были изменены с помощью этих операций. Кроме того, можно просматривать логическое содержание LDF_файла, создавать Undo/Redo скрипты, историю изменения любой строки в базе данных и многое другое.

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

Основные преимущества ApexSQL Log:

- объединение разных источников с данными журнала транзакций в один общий документ;

- объединение активного журнала транзакций с его резервными копиями и отдельными LDF_файлами для получения более подробной информации об изменениях;

- полная реконструкция операции UPDATE, в том числе вывод строки до и после изменения;

- просмотр истории всех операций DML над строками, включая время и пользователя, который внес изменения;

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

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

- для чтения и работы с LDF_файлами не требуются знания T_SQL.

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

6. Разработка подсистемы аудита БД информационной системы сопровождения ремонта

6.1 Инфологическое проектирование

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

Разрабатываемая в рамках ВКР подсистема аудита создается для базы данных информационной системы сопровождения ремонта. Данная информационная система предназначена для автоматизации следующих задач работы сервисного ремонтного центра:

- организации точного учета ремонтируемых изделий;

- организации складского учета используемых материалов и комплектующих;

- отслеживания при помощи информационной системы нахождения и состояния ремонтируемых изделий на участке ремонта;

- сбора статистической информации по проводимым ремонтным работам, частоте отказов и видам дефектов;

- формирования складских отчетов, документов сопровождения сменного элемента.

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

В соответствии с поставленной задачей, методом аудита и структурой журнала аудита, выбранными ранее, подсистема аудита строится с учетом следующих особенностей:

1. Подсистема разрабатывается с помощью СУБД Microsoft SQL Server 2014.

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

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

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

5. Общая таблица для аудита связана со второй таблицей отношением один_к_одному, а с третьей - отношением один_ко_многим.

6.2 Логическое проектирование

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

Как уже было отмечено ранее журнал аудита представляет собой систему из трех таблицы, создаваемых для каждой таблицы базы данных (таблица AuditInf - таблица для записи общей информации об изменяемых данных; таблица UpdateLog предназначена для фиксации изменений, произошедших в результате выполнения операции изменения (UPDATE); для фиксации изменений данных при выполнении операций вставка (INSERT) и удаление (DELETE) служит таблица InstDelLog). Таблицы аудита реализуются согласно схеме, представленной на рисунке 1.

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены