В основе большинства современных информационных систем лежат базы данных. Они представляют собой структурированную по определенному принципу информацию: статистические данные, информацию о товарах и потребителях, идентификационные коды и т.д. Чтобы пользователи могли оперативно найти необходимую информацию, массивы данных формируются в таблицы.
Базы данных чаще всего формируются, наполняются, изменяются и структурируются путем использования специального языка программирования – SQL. В переводе на русский эта аббревиатура обозначает «язык структурированных запросов». SQL активно используется самыми известными и крупными компаниями по разработке программного обеспечения: Microsoft, IBM, Oracle и др. Поэтому, когда пользователей обучают принципам работы с базами данных, основной упор идет именно на базы данных, написанные на SQL.
Чтобы информационная система, приложение или программа, в основе которой лежат базы данных, работала исправно, необходимо периодически проводить аудит базы данных. Он представляет собой проверку состояния информационной системы, ее работоспособности, уровня защиты и производительности. Без аудита системы работа программного обеспечения будет нарушена из-за многочисленных ошибок и сбоев. Поэтому регулярное проведение проверок является залогом работоспособности ПО.
Аудит базы данных проводится с помощью специальных программ. Есть разные подходы к проведению аудита. Выбор зависит от целей проверки, сложности самой базы данных, количества и объема содержащейся в ней информации.
На данный момент нет строгой классификации подходов к аудиту. Принято делить их на две категории: проверку по компонентам информационной системы и по методу выявления изменений в базе данных. У каждого способа аудита свои цели, преимущества и недостатки. Рассмотрим оба.
При проведении аудита во внимание берется один из компонентов информационной системы. К этим компонентам относятся серверы данных и непосредственно базы данных. Поэтому аудит базы данных по компонентам информационной системы можно разделить на аудит сервера данных и аудит систем баз данных.
Аудит сервера данных представляет собой совершение ряда операций, позволяющих обеспечить максимальную продуктивность и безопасность базы данных. К таким операциям относится:
Основным плюсом проведения аудита сервера данных является то, что таким образом можно надежно защитить информационной системы от несанкционированного доступа. Это делается путем отслеживания попыток входа в систему незарегистрированных пользователей или зарегистрированных пользователей, допускающих многочисленные ошибки при авторизации. Однако такой защиты информационной системы недостаточно для обеспечения полной информационной безопасности. Поэтому аудит сервера данных обычно совмещают с аудитом базы данных.
Для отслеживания пользовательских операций в БД на профессиональном уровне рекомендуем использовать Database Monitor. Узнать больше.
Аудит базы данных на уровне сервера проводит системный администратор или группа разработчиков, обслуживающих информационную систему. Они вносят коррективы в программный код, меняя содержание и структуру базы данных. При этом операции администраторов на уровне сервера не контролируются. Это значит, что злоумышленник, получивший права администратора при проникновении в систему, может серьезно ей навредить. Кроме того, сам администратор может случайно совершить ошибку, которая приведет к потере защиты или работоспособности приложения. Чтобы избежать этого, разрабатывается второй уровень защиты, который осуществляется с помощью аудита непосредственно базы данных.
Для проведения аудита базы данных, который заключается в отслеживании несанкционированных операций, совершенных администратором, создаются специальные журналы операций. В них отражаются такие действия как изменение строк и столбцов таблиц, содержащихся в них данных, удаление таблиц и т.д. С помощью специального программного обеспечения создаются алгоритмы, анализирующие правильность работы информационной системы, выявляющие ошибки, оценивающие общую безопасность и работоспособность приложения. Таким образом благодаря аудиту баз данных по компонентам информационной системы повышается степень защиты системы, оптимизируется ее работа и снижается количество ошибок.
Недостатком этой методики аудита можно считать то, что при проведении такой проверки нужно обязательно оценивать ее влияние на работу системы. Если программное обеспечение, внедренное в систему для проведения аудита и защиты данных, негативно влияет на производительность системы, то его следует доработать или заменить на более подходящее. Часто во время проведения аудита пользователи не могут полноценно использовать систему, так как ее производительность падает до минимального уровня. В некоторых случаях исправить это не получается и разработчикам приходится обращаться к другой методике аудита базы данных – аудиту путем выявления изменений.
О том, какую роль выполняет отслеживание изменений в базе данных, уже было сказано выше. Однако методики такого аудита могут быть различными. Каждая из них обладает своими преимуществами и недостатками.
Существует две основных методики аудита путем выявления изменений. Это проведение аудита с помощью триггеров и проведение аудита по журналу транзакций. Рассмотрим каждую методику в отдельности.
Триггер – это многозначное понятие, которое в области аудита базы данных обозначает процесс регистрации изменений массивов данных. Триггер запускается автоматически. Поводом для запуска триггера становится любое действие пользователя или администратора, направленное на изменение данных в системе.
Особенностью использования триггеров в аудите является то, что они регистрируют все изменения. Это значит, что в протокол попадают и изменения данных, и изменения в структуре таблиц. Также существуют триггеры, регистрирующие другие действия пользователей: попытки авторизации, установку пользовательских сеансов и т.д.
В зависимости от того, какую функцию выполняет триггер в аудите системы, определяется его название. Например, изменение данных в системе описывается с помощью языка обработки данных DML. Соответственно, триггеры получают одноименное с этим языком название. То же самое касается триггеров, регистрирующих изменение таблиц. Структура данных меняется с помощью языка обработки данных DDL. Поэтому триггеры, регистрирующие изменение таблиц, называются триггерами DDL.
Преимущество использования триггеров заключается в том, что они интегрируются в систему данных еще на этапе разработки программных продуктов, то есть являются встроенными инструментами аудита. Однако в этом заключается и основной минус этой методики, так как встроенные инструменты аудита отслеживают и регистрируют большую часть совершаемых с базами данных операций, тем самым снижая производительность системы. Поэтому триггеры нуждаются в предварительной настройке.
Задача настройки триггеров состоит в том, чтобы определить и установить перечень операций, которые обладают наибольшим значением для сохранения работоспособности системы и обеспечения защиты данных. Таким образом будет создан баланс между безопасностью данных и производительностью системы.
Еще одним недостатком метода аудита базы данных с помощью триггеров является то, что в некоторых СУБД использовать этот метод невозможно из-за большого количества данных, пользователей и функций системы. В этом случае используется другой метод выявления изменений – журнал транзакций.
С помощью журнала транзакций также можно отследить все действия пользователей, связанные с изменением данных и структуры таблиц. Примером такой системы проверок являются методики, разработанные для Oracle Audit Vault и Change Data Capture. Они позволяют:
Преимущество методики в том, что ведение журнала транзакций практически не влияет на производительность системы. Кроме того, в нем сохраняется вся информация об изменениях данных, даже если ПО неоднократно обновляли. Благодаря этому разработчики могут проанализировать производительность разных модификаций продукта и обеспечить пользователям доступ к информации обо всех изменениях данных.
В СУБД Oracle мониторинг базы данных осуществляется с помощью триггеров. Запись действий ведется от пользователей nondatabase user и database user.
Пользователь nondatabase user представляет собой оператора определенного приложения, который авторизуется в системе посредством атрибута CLIENT_IDENTIFIER. Пользователь database user является пользователем всей СУБД.
Особенностью аудита в данном случае является то, что изменения данных регистрируются по-разному в зависимости от того, кто их совершил: nondatabase user или database user. Причем мониторинг действий nondatabase user сложнее с точки зрения количества операций проверок.
В зависимости от целей проверки, администратор системы может настроить разные триггеры. Так, например, Audit Trail предназначен для:
Триггер регистрирует кем, где, когда и как было выполнено то или иное действие.
Для проведения полномасштабной проверки и контроля безопасности используется триггер Standard Audit. Он обладает более широким функционалом.
***
Чтобы обеспечить защиту данных и сохранить высокую производительность системы, необходимо правильно выбрать способ проведения мониторинга. Для этого нужно проанализировать преимущества и недостатки существующих методик проверки, после чего выбрать наиболее подходящую.
03.08.2020
Подпишитесь на нашу рассылку и получите
свод правил информационной безопасности
для сотрудников в шуточных