ВВЕДЕНИЕ Современную жизнь, а тем более ... представить без информационных технологий. Мир ...

ВВЕДЕНИЕ
Современную жизнь, а тем более современный бизнес невозможно
представить без информационных технологий. Мир окутан информационными потоками, имеющими разную среду для ее передачи. Сбор, анализ и
хранение информации – это первостепенные задачи не только современного
человека, но и общества в целом, в том числе и бизнеса. При этом одной из
основных проблем внедрения информационных технологий является
обеспечение защиты и безопасности информации.
В настоящее время существует огромная масса технологий, методов и
средств по сбору, передаче, хранению, анализу и защите информации. Одним
из аспектов обеспечения защиты и безопасности данных является
организация контрольного слежения за действиями с данными и за работой
технических средств, работающих с данными (аудит и мониторинг).
Одним из самых распространенных средств для хранения, анализа и
защиты информации являются системы управления базами данных (СУБД).
В СУБД имеется возможность организации аудита и мониторинга для
отслеживания действий пользователей и обеспечения безопасности
информации в базах данных.
В современных серверах БД имеются как встроенные, так и
дополнительные средства проведения аудита и мониторинга.
Сервер баз данных MS SQL Server является одним из самых
распространенных серверов баз данных, имеет различные средства
организации аудита и мониторинга.
Данная работа посвящена организации и анализу аудита и мониторинга
в СУБД в сервере БД MS SQL Server 2008 на примере тестовой базы данных.
Целями работы являются:
- анализ работы аудита и мониторинга в различных СУБД;
- проектирование и реализация тестовой базы данных для книжного
магазина;
- обеспечение непротиворечивости и целостности данных в созданной
базе данных;
- организация аудита и мониторинга в тестовой базе данных;
- анализ результатов и возможностей аудита и мониторинга в СУБД;
- расчет экономической эффективности проекта;
- определение норм безопасности и охраны труда.
8
1 Аудит и мониторинг в серверах баз данных
1.1 Серверы баз данных
Серверы БД относятся к числу сложных существующих программных
продуктов, предназначенных для работы в вычислительной сети. Рабочая
станция пользователя представляет собой клиента (обслуживаемая сторона),
а СУБД выполняется на сервере (обслуживающая сторона). В такой системе
обработка данных распределяется между двумя вычислительными
системами.
Программа - сервер баз данных является центральной с точки зрения
доступа к данным. Именно поэтому большая часть функций, которая должна
быть реализована в приложениях баз данных, ложится на сервер баз данных.
Основные функции, которые должна выполнять программа - сервер баз
данных:
- выполнять клиентские запросы по извлечению и модификации
данных;
- обеспечивать одновременный доступ к данным нескольких
пользователей;
- обеспечивать идентификацию пользователей и разграничение прав
доступа разных пользователей к разным данным;
- обеспечивать целостность и непротиворечивость данных в случае
аппаратных и программных сбоев;
- защищать данные от несанкционированного доступа;
- предоставлять дополнительные средства администрирования
системой.
Рассмотрим эти требования более подробно по отношению к
вытекающим из них функций сервера БД [1,2].
Выполнять клиентские запросы по извлечению и модификации
данных. Это основная функция сервера баз данных. Механизм реализации
этой функции может быть скрыт от пользователя, то есть пользователь
(точнее, работающая с ним программа-клиент) просто формулирует, что ему
нужно, а сервер баз данных исполняет этот запрос.
Предоставлять механизм одновременного доступа к данным
нескольких пользователей. При многопользовательском доступе к данным,
используемым в технологии клиент-сервер, возникают дополнительные
задачи, которые должны быть решены. К таким задачам относится,
например, блокировка данных. Блокировка означает, что часть данных в
некоторые моменты времени должна быть закрыта для модификации или
даже
для
чтения
другим
пользователем.
Другой
аспект
многопользовательского доступа - это распараллеливание доступа. То есть
сервер баз данных должен уметь обрабатывать несколько запросов
одновременно. В этом аспекте сервер баз данных аналогичен многозадачной
операционной системе.
9
Обеспечивать идентификацию и разграничение прав доступа
разных пользователей к разным данным. В реальных системах баз,
данных должно существовать разграничение по правам доступа к данным.
Какие-то пользователи могут и читать, и модифицировать данные, какие-то
пользователи могут только читать, а кто-то вообще может только вводить
данные, а читать не имеет право. Таким образом, сервер баз данных должен,
во-первых, уметь понимать команды, которые описывают такое
разграничение прав, а во-вторых, в процессе обслуживания запросов
пользователя контролировать соблюдение этих разграничений.
Обеспечивать целостность и непротиворечивость данных в случае
аппаратных и программных сбоев. В случае внезапного выключения и
последующего включения компьютера, на котором работает сервер баз
данных, информация не должна быть искажена или потеряна. Аналогично,
если будет случайно выключен компьютер, на котором работает программаклиент, сервер баз данных должен определить этот факт и снять те
блокировки, которые данная программа-клиент установила, отменить
незавершенные транзакции и, возможно, выполнить другие действия.
Что касается программных сбоев, то здесь надо различать умышленные
попытки исказить информацию, или случайные ошибки в программах,
которые могут привести к таким же последствиям. Например, списывание
денег с банковского счета должно приводить или к зачислению этой суммы
на другой счет, или к появлению расходного документа. То есть нельзя
просто так списать или начислить деньги на счет. Кроме того, при
программировании банковской системы в нее может закрасться ошибка,
которая может привести к рассогласованию данных. Поэтому сервер баз
данных должен уметь проверять корректность производимых манипуляций с
данными.
Защищать данные от несанкционированного доступа. В
современных системах баз данных все данные или, по крайней мере, их
значительная часть является конфиденциальной. Помимо разграничения
доступа для разных категорий пользователей, сервер баз данных должен
обеспечивать защиту от попыток получить доступ к данным тем лицам,
которые не являются пользователями информационной системы.
Предоставлять средства администрирования. В реальной системе
баз данных должен быть предусмотрен механизм восстановления системы
после стихийных бедствий. Чтобы не потерять накопленные данные, должна
существовать процедура архивирования и восстановления данных. Кроме
того, существует вероятность, что в процессе проектирования системы не
были предусмотрены какие-то типы запросов, и при их реализации
оказалось, что они работают слишком медленно. Следовательно, сервер баз
данных должен уметь управлять ресурсами и производительностью. Вся
деятельность данного типа относится к администрированию сервера баз
данных. Качественный сервер баз данных должен предоставлять
достаточный набор возможностей по администрированию, а именно,
10
возможность настройки по производительности, средства анализа потока
запросов и определения причин недостаточной скорости работы, средства
созданий резервных копий (архивов) и восстановления с них и т.д.
В настоящее время все серверы реляционных БД являются SQLсерверами, их количество достаточно велико. SQL-серверы - это СУБД с
архитектурой клиент-сервер на основе языка SQL. Для персональных
компьютеров (ПК) SQL-серверы создаются для того, чтобы справляться с
гигантскими базами данных и многопользовательскими нагрузками, которые
были традиционной сферой деятельности больших ЭВМ, мини-ЭВМ и
микропроцессорных серверов на базе ОС Unix. Файл-серверная архитектура
обработки данных, в которой все данные передаются по сети рабочей
станции, просто недостаточно эффективна, чтобы справиться с задачами
такого масштаба. Технология клиент-сервер позволяет внешним средствам
работы с базами данных передавать функции SQL-обработки базовому
серверу. Клиенту назад отправляется только результат, что существенно
снижает нагрузку на сеть.
Специфика сервера базы данных заключается в том, что данные, как
правило, обрабатываются транзакционно, т.е. система запрашивает
небольшой объем данных, проводит над ними операцию и затем сохраняет.
Это накладывает определенные требования к аппаратной части сервера БД, а
именно:
 большой объем оперативной памяти для кэширования наиболее
интенсивно используемых участков базы данных;
 высокопроизводительная дисковая подсистема, характеризующаяся в
первую очередь способностью обрабатывать большое количество мелких
запросов в единицу времени (IOps - inputs/outputs per second);
 высокая вычислительная мощность для обработки информации.
Современные операционные системы и приложения способны
адресовать до 64Гб и более. Двухпроцессорные серверы способны
оснащаться 128Гб оперативной памяти, а четырех- и восьмипроцессорные до 256Гб.
Современные процессоры стали значительно производительнее, чем 23 года назад благодаря внедрению технологии многоядерности. Сейчас
сервер с 8-ю ядрами (фактически процессорами) доступен практически
каждой организации. Благодаря этому, появилась возможность обрабатывать
существенные объемы информации на относительно недорогом
оборудовании. В настоящий момент существуют четырехпроцессорные и
восьмипроцессорные серверы стандартной архитектуры x86 с поддержкой
четырех и даже шестиядерных процессоров, что позволяет иметь в одной
системе до 32-х ядер.
Низкие затраты на повышение производительности центрального
процессора, увеличение емкости жестких дисков и памяти сделало
неизбежным переход к серверам на базе ПК (ПК-серверам). 32-разрядные
ОС, такие, как Microsoft Windows NT, NetWare и OS/2 обеспечивают
11
высокую производительность и сохранность данных, относительную
легкость использования на ПК-серверах, а применение графических средств
на компьютере клиента существенно упрощает составление запроса на языке
SQL. В настоящее время для персональных компьютеров наибольшее
распространение получили SQL-серверы: Oracle, Sybase, Informix, Ingres,
Watcom (Anywhere), DB2/2 (версия DB2 для персональных компьютеров),
InterBase, Microsoft SQL Server, MySQL и др.
В большинстве случаев SQL-серверы входят в состав функционально
полных серий продуктов, реализующих технологию баз данных.
Например, серия Oracle включает серверы баз данных, эффективно
управляющие своими ресурсами, информацией в базе данных,
обслуживающие множество клиентов, обращающихся к базе данных с
запросами и посылающих данные по сети. Oracle Database Server - объектнореляционная система управления базами данных компании Oracle. К
ключевым особенностям СУБД Oracle относят кроссплатформенность,
надежность и эффективность. СУБД Oracle имеет множество важных
средств, которые делают его не только исключительной СУБД, но и
превосходным сервером баз данных, который можно с успехом применять в
вычислениях баз данных клиент-сервер. Последняя версия обеспечивает
пятикратное увеличение скорости при работе в сети и поддержку
многосерверного
режима.
Система
построена
на
основе
самонастраивающейся адаптируемой многопотоковой архитектуры.
Cерия продуктов Informix включает семейство серверов реляционных
баз данных Informix OnLine, которые обеспечивают аналогичные
возможности и имеют встроенный механизм параллелизма, что позволяет
использовать преимущества мультипроцессорных систем для параллельной
обработки данных.
СУБД Ingres является одной из первых реляционных систем. Проект и
экспериментальный вариант были разработаны в университете Беркли С
самого начала СУБД Ingres разрабатывалась как мобильная система,
функционирующая в среде ОС UNIX. Первая версия Ingres была рассчитана
на 16-разрядные компьютеры и работала главным образом на машинах серии
PDP. Это была первая СУБД, распространяемая бесплатно для использования
в университетах. Впоследствии Ingres была перенесена в среду ОС UNIX
BSD, которая также была разработана в университете Беркли. Семейство
СУБД Ingres из университета Беркли принято называть "университетской
Ingres". В начале 80-х была образована компания RTI (Relational Technology
Inc.) для доведения университетских прототипов до уровня коммерческих
продуктов. С этого момента стали различать университетскую и
коммерческую СУБД Ingres. В настоящее время коммерческая Ingres
поддерживается, развивается и продается компанией Computer Associates.
Сейчас это одна из развитых коммерческих реляционных СУБД.
12
Достаточно много серверов баз данных разрабатывается и в качестве
отдельного программного продукта, например, Microsoft SQL Server, MySQL
и др.
Microsoft SQL Server - система управления реляционными базами
данных (СУБД), разработанная корпорацией Microsoft. Основной
используемый язык запросов Transact, создан совместно Microsoft и Sybase.
Transact-SQL
является
реализацией
стандарта ANSI/ISO по
структурированному языку запросов (SQL) с расширениями. Используется
для работы с базами данных размером от персональных до крупных баз,
данных масштаба предприятия; конкурирует с другими СУБД в этом
сегменте рынка.
MySQL - свободная реляционная система управления базами данных.
Разработку новых версий и поддержку MySQL осуществляет
корпорация Oracle, получившая права на торговую марку при поглощении
компании Sun Microsystems, которая ранее приобрела шведскую
компанию MySQL AB, разработавшую первоначальную версию MySQL.
PostgreSQL - свободная объектно-реляционная система управления
базами данных. Существует в реализациях для множества UNIXlike платформ,
различные BSD-системы, HP-X,
IRIX, Linux, MacOSX,
Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows и т.д.
Рассмотрим физическую организацию серверов баз данных. Как
правило, они включают следующие компоненты:
- подсистема взаимодействия с клиентским приложением. Данный
модуль отвечает за поддержание связи с клиентом. Как правило, механизм
его работы выглядит следующим образом. Подсистема взаимодействия
"прослушивает" сеть в ожидании клиентских запросов на установление
соединения. Когда такой запрос обнаруживается, порождается новый
процесс, который будет обеспечивать связь с данным клиентом. Клиенту
сообщается идентификатор данного процесса, в дальнейшем клиент передает
свои запросы и получает данные взаимодействуя с этим интерфейсным
процессом. После того, как клиент закрывает соединение, обслуживавший
его процесс прекращается. Характеристики интерфейсных процессов зависят
от операционной системы, под которой исполняется сервер базы данных;
- подсистема синтаксического разбора запросов. Данный модуль
отвечает за компиляцию поступающих от клиентов через интерфейсные
процессы запросов во внутренний код, который будет исполняться сервером.
При ошибках компиляции соответствующие сообщения передаются клиенту.
Наиболее современные СУБД позволяют сохранять откомпилированный код
запросов некоторое время. Это позволяет избежать стадии компиляции при
повторном обращении клиента к запросу;
- подсистема планирования выполнения запросов. Данный модуль
должен составить такой план выполнения запроса, чтобы он был обработан
наиболее быстро. Для этого анализируются условия выборок и соединений,
устанавливается порядок их выполнения. Пусть, например, надо извлечь
13
одного сотрудника из списка работников, в качестве критерия поиска
задаются его имя и фамилия. Возможны два плана выполнения запроса: (1)
вначале делается выборка всех сотрудников с данным именем, из нее
извлекаются записи, содержащие данную фамилию; (2) - наоборот, вначале
делается выборка по фамилии, затем по имени. Поскольку множество имен,
как правило, меньше множества фамилий, во втором случае запрос будет
обработан быстрее, т.к. на втором этапе здесь мы получим меньшую
выборку. Планировщики запросов ведущих СУБД отслеживают информацию
о распределении значений в таблицах. План выполнения запроса включается
в его откомпилированный код;
- подсистема выполнения транзакций. Здесь выполняется
оптимизированный код запроса, обновляются индексы, выполняются в
случае необходимости триггеры и хранимые процедуры. Как правило,
несколько запросов могут исполняться параллельно, при этом
обеспечивается необходимый уровень их изоляции. Также ведется журнал
транзакций, обеспечивается их завершение и корректный откат;
- подсистема управления памятью. Этот компонент отвечает за
считывание данных с диска в оперативную память, синхронизацию
обновлений с данными диске и т.д. Он может использовать файловые
функции операционной системы, но часто СУБД имеет свои собственные
низкоуровневые средства доступа к дискам.
1.2 Аудит и мониторинг в серверах баз данных
На сегодняшний день защита баз данных является одной из самых
актуальных и сложных задач в проблеме обеспечения информационной
безопасности. Согласно последним оценкам ведущих аналитических
агентств, большая часть современных атак нацелена на информацию из баз
данных, так как именно в базах данных содержится ценная для организаций
информация [3]. Угрозы хранящейся в базах данных информации возникают
не только извне, но и изнутри со стороны легальных пользователей. Средства
учета и наблюдения (auditing) - обеспечивают возможность обнаружить и
зафиксировать важные события, связанные с безопасностью, или любые
попытки создать, получить доступ или удалить системные ресурсы.
Контрольное слежение за выполняемыми действиями в системе при
работе с конфиденциальными данными или при выполнении критических
операций называется аудитом. Контрольный след используется для
обнаружения нарушителя, если противоречивость данных приводит к
подозрению, что совершено несанкционированное вмешательство в базу
данных. Несмотря на разграничение прав доступа пользователей существует
необходимость контроля (аудита) их действий в базе данных.
Очень близким к понятию аудита является понятие мониторинга. Для
наблюдения за работой ОС, ее служб, служб сервера баз данных, хранимых
процедур, времени нахождения пользователя в системе и т.д., вводится
мониторинг. Результаты мониторинга используются для оптимизации работы
14
сервера баз данных, для оптимизации работы пользователей, для
отслеживания тенденций роста или снижения производительности и
выявления их причин (в том числе и злонамеренных действий).
Аудит и мониторинг критических (в плане безопасности) действий
пользователей снижает риск внутренних угроз. Реализация аудита и
мониторинга в различных SQL – серверах выполняется своими встроенными
механизмами.
Для сохранения контрольного следа обычно используется особый
файл, в который система автоматически записывает все выполненные
пользователем операции при работе с обычной базой данных. Файлы
контрольного слежения являются системными. Их часто называют
журналами аудита.
1.3 Аудит и мониторинг в Oracle Database Server
Аудит действий пользователей в СУБД Oracle.
Oracle предоставляет возможность всестороннего аудита всех
операций, происходящих в базе данных, - команду AUDIT. Информация
аудита записывается либо в специальную таблицу в схеме SYS (SYS.AUD$),
либо (в зависимости от применяемой системы) в журнал аудита
операционной системы.
Разрешается проводить аудит операций трех разных типов [4]:
- попыток регистрации в базе данных (аудит подключений);
- определенных операций с базой данных (аудит действий);
- обращения к определенным объектам (аудит объектов).
Во время аудита база данных по умолчанию должна регистрировать
как успешные, так и неуспешные команды. Этот режим можно изменить при
установке аудита любого типа.
Аудит подключений.
Можно осуществлять аудит всех попыток соединения с базой данных.
Аудит попыток регистрации задается командой AUDIT SESSION
Чтобы производить аудит только тех попыток регистрации, которые
завершаются или успешно, или неуспешно, воспользуйтесь одной из
следующих команд:
AUDIT SESSION WHENEVER SUCCESSFUL
AUDIT SESSION WHENEVER NOT SUCCESSFUL
Если записи аудита хранятся в таблице SYS.AUD$, их можно
просмотреть через представление словаря данных DBAAUDITSESSION этой
таблицы.
Для запрещения аудита сеанса применяется команда NOAUDIT
SESSION
Аудит операций.
Любая команда DDL, оказывающая воздействие на некоторый объект
базы данных, например, на таблицу, представление или индекс, может быть
подвергнута аудиту. При этом нетрудно сгруппировать операции CREATE,
15
ALTER и DROP, воздействующие на объекты. Группирование команд
снижает объем административной работы, необходимой для установки и
поддержки параметров аудита.
Так, для аудита всех команд, воздействующих на роли, нужно
ввести команду AUDIT ROLE
Чтобы отменить заданную установку, следует ввести NOAUDIT ROLE
Существуют группы аудита SQL-команд. Каждую группу можно
применять для аудита всех SQL-команд, входящих в нее. Например, с
помощью команды AUDIT ROLE, приведенной выше, будет осуществляться
аудит команд CREATE ROLE, ALTER ROLE и DROP ROLE.
Также можно осуществлять отдельный аудит для каждой команды,
указанной операторным параметром. ORACLE предлагает следующие
группы операторных параметров:
- CONNECT аудит всех случаев регистрации в ORACLE и
отсоединения от ORACLE;
- DBA аудит команд, для выполнения которых необходимы
полномочия администратора базы данных;
- RE-аудит операций создания и удаления таблиц, кластеров, SOURCE
представлений, индексов, табличных областей, типов и синонимов;
- ALL аудит всех этих команд.
Аудит объектов.
Помимо системных операций, выполняемых над объектами, аудиту
можно подвергать операции SELECT, INSERT, UPDATE и DELETE,
выполняемые над конкретными таблицами.
Конструкция, добавляемая для аудита объектов, - BY SESSION (на
сеанс) или BY ACCESS (по доступу). Она определяет, нужно ли вносить
запись аудита однажды для каждого сеанса или каждый раз при обращении к
объекту. Например, если пользователь выполнил над одной и той же
таблицей четыре различных оператора UPDATE, результатом аудита по
доступу будет внесение четырех записей аудита - по одной на каждое
обращение к таблице. Однако если в той же самой ситуации применить
конструкцию BY SESSION, то будет внесена только одна запись аудита.
Поэтому аудит по доступу может намного увеличить частоту внесения
записей аудита. Он используется достаточно редко и, как правило, для
измерения числа отдельных операций, выполняемых в течение
определенного временного интервала; после завершения тестирования
следует установить для аудита состояние BY SESSION.
Возможности аудита Oracle.
Для решения задачу аудита базы данных Oracle можно применять не
только команды аудита. Могут быть применены и другие технологии. Ниже
представлены некоторые основные методы, которые могут быть
использованы для аудита базы данных Oracle.
Аудит Oracle.
16
Все привилегии, которые могут быть предоставлены пользователю или
роли базы данных могут быть проконтролированы. Сюда включено доступ на
чтение, запись и удаление объектов на табличном уровне. Для более
детализованного аудита можно задействовать триггеры.
Системные триггеры.
Эта возможность была представлена начиная с Oracle 8 и разрешает
выполнение операций триггера, когда имеет место системное событие. Сюда
включены запуск и останов базы данных, попытки входа и выхода, создание,
изменение и удаление объектов схемы. С помощью автономных транзакций,
можно записывать в журнал упомянутые системные события.
Update, delete и insert триггеры.
Использование этих триггеров позволяет понять действия
пользователей на более детальном уровне. Для того, чтобы отслеживать
изменения в базе на уровне столбца и строки, можно написать триггеры,
которые позволят полностью сохранять данные, до или после выполненного
действия. Использование этого типа контроля очень ресурсоемко, так как
создается и хранится много дополнительных записей. Следует учесть, что
этот метод не позволяет отследить доступ на чтение.
Детализированный (Fine-grained) аудит.
Проблему отслеживания доступа на чтение решает детализированный
аудит. Данная возможность основана на внутренних триггерах,
срабатывающих, при разборе какой-нибудь части SQL-предложения. Это
очень эффективно, так как SQL-предложение разбирается один раз для
аудита и выполнения. Эта возможность использует предикаты, которые
определены и проверяются каждый раз, когда происходит доступ к
соответствующим объектам. Fine-grained аудит управляется PL/SQL пакетом,
который называется DBMS_FGA. Созданная PL/SQL процедура выполняется
каждый раз, когда выполняется, соответствующее ей, действие с предикатом.
Этот метод позволяет контролировать не только DML-операции на уровне
строк и столбцов, но и предложения чтения. Следует предостеречь
читателей, в том, что для использования этой возможности необходим
некоторый опыт программирования.
Системные журналы.
СУБД Oracle генерирует много журнальных файлов, и многие из них
могут содержать полезную информацию для проведения аудита. Например,
alert log используется для записи информации о запуске и останове базы, а
также о вносимых структурных изменениях, таких как добавление файла
данных в базу.
17