Система управления базами данных (СУБД) используется для создания, редактирования и совместного использования БД.
Обычно функционал такого ПО направлен на:
Существует большое количество информационных систем, содержащих БД. Разработчикам сложно отследить все возможные изменения в них. Еще сложнее создать простое и эффективное решение, не влияющее на производительность рабочих процессов, для автоматического отслеживания этих изменений.
Проверка безопасности СУБД позволяет оценить, насколько защищена конфиденциальная информация компании от внешних и внутренних угроз. Кроме того, это один из способов оценки эффективности IT-системы. При проведении аудита системы управления БД выясняется информация о действиях пользователей в БД: попытки авторизации, доступ к ценной информации, любые изменения содержимого в БД.
Аудит (ревизия, проверка) – совокупность мер, в результате которых оцениваются два параметра, определяющие эффективность информационного массива: безопасность и рациональность.
В зависимости от частоты проведения выделяют:
Ревизия преследует следующие цели:
Регулярные ревизии так же важны для безопасности и защиты БД, как и правильно установленный межсетевой экран или новейшее антивирусное программное обеспечение. В результате аудита безопасности можно выявить уязвимости, найти пробелы в защите.
Полный перечень событий, проверяемых специалистами по информационной безопасности, выглядит следующим образом:
В IT-системах компаний, особенно в тех, где данные регулярно обновляются, необходимо отслеживать любые изменения в структуре БД.
Есть несколько подходов к аудиту баз данных. Рассмотрим самые популярные. Условно они делятся на два вида:
1. Аудит по компонентам: на уровне сервера и на уровне БД.
2. По методу обнаружения изменений: с использованием триггеров и журнала транзакций.
Большинство IT-систем имеют три уровня: «Клиент – Сервер приложений – Сервер данных». Мониторинг пользовательских операций обычно проводят на уровне сервера приложений. Он включает контроль любых попыток входа в систему, запись восстановления или резервного копирования БД, учет времени создания или удаления базы данных.
Проверка на уровне сервера играет важную роль в защите системы, поскольку позволяет предотвратить серьезный инцидент, отслеживая неудачные или неправомерные попытки входа в систему. Необходимо также контролировать изменения данных на уровне операций, выполняемых в самой базе с помощью различных команд SQL.
У каждой БД есть администратор, который управляет ей через SQL-интерфейс. При этом его действия не записываются в журнал операций, выполняемых на уровне сервера. Поэтому в ходе этой проверки невозможно увидеть неправомерные действия со стороны сисадмина.
На данный момент не существует программного обеспечения, полностью защищенного от хакерских атак и несанкционированных действий пользователей. Особую опасность представляет промышленный шпионаж, так как пользователь с правами системного администратора может внести изменения в базы данных и удалить запись об этом из журнала операций.
Кроме несанкционированных действий пользователей, еще одной проблемой защиты СУБД являются ошибки при внесении изменений в базу данных или ее структуру. Так, например, многие пользователи недостаточно компетентны, чтобы добавлять, изменять или удалять таблицы с помощью команд SQL. Поэтому в структуру СУБД необходимо встраивать скрипты, которые помогут управлять действиями пользователей, автоматизировать их работу и сократить количество ошибок.
Контроль действий на уровне БД повышает защитные свойства системы. Однако есть еще один важный нюанс, который нужно учитывать при выборе метода мониторинга событий. Дело в том, что многие программы для проведения аудита снижают производительность СУБД. Поэтому выбирать методы проверки нужно с учетом того, как они повлияют на работоспособность системы и скорость обработки данных.
Базы данных часто страдают от действий инсайдеров: сотрудники после конфликта с руководством удаляют из БД критически важные данные, взламывают базу, чтобы украсть данные клиентов на продажу. Как защититься?
Одним из самых известных и часто используемых методов отслеживания изменений в базе данных является проверка при помощи триггера. Триггер – это специальная программа, которая запускается сервером автоматически при любом действии по изменению данных в БД. Обычно триггеры устанавливаются вместе с серверным программным обеспечением и хранятся непосредственно на сервере.
Используя триггеры, можно отслеживать и регистрировать операции, связанные как с изменениями данных, так и с модификациями в структуре БД.
Действия, которые связаны с изменениями данных в таблицах или приложениях БД, описываются операциями DML (Data Manipulation Language), такими как INSERT, DELETE или UPDATE. Для их мониторинга существуют триггеры DML и DDL.
Помимо триггеров, которые отслеживают модификации в структуре базы данных, есть триггеры доступа, срабатывающие на действие LOGON. Они могут использоваться не только для аутентификации в системе, но также для мониторинга попыток доступа к ней.
Триггеры часто используются в качестве одного из инструментов встроенных систем отслеживания изменений в СУБД. В этом случае система автоматически определяет, какие триггеры нужно запускать для выполнения проверки по заданным пользователем параметрам. Например, средством для мониторинга изменений в БД является AUDIT, встроенный в Oracle. Отслеживать изменения можно и посредством триггера Change Tracking, встроенного в SQL Server.
Главный минус триггеров – в ощутимой нагрузке на IT-систему. Это связано с тем, что запись о результатах проверки добавляется в контрольную таблицу одновременно с каждым действием, которое совершает пользователь. Поэтому при проведении мониторинга с применением триггеров рекомендуется изначально задать в условиях проверки, что отслеживание изменений ведется не по всем таблицам БД, а только по тем, которые содержат наиболее важные данные. Это особенно касается компаний, где большое количество сотрудников имеет доступ к базе данных и регулярно вносит в нее изменения. В этом случае использование триггеров для проверки всех таблиц сильно снизит производительность IT-системы.
На фоне недостатков ревизии с применением триггеров широкое распространение получил метод отслеживания изменений в БД по журналу событий, из которого извлекается информация о проведенных действиях DDL и DML. Для некоторых систем управления БД разработаны отдельные продукты для проверки журналов событий, к примеру, Change Data Capture или Oracle Audit Vault. Эти программы «вычитывают» записи об изменениях в журнале событий. При этом можно настроить фильтры для выбора записей, интересных пользователю, создавать полные отчеты по изменениям.
Отслеживание журнала событий не влияет на производительность IT-системы. Однако это тоже сложный процесс, связанный с преобразованием и анализом данных.
Одно из ключевых преимуществ проверки по журналу событий – то, что журнал содержит все версии данных и перечень выполненных операций, которые были изменены в течение длительного времени. А значит, можно восстановить историю изменений за нужный период. Тем не менее, поддержка этого свойства сервером может повлиять на КПД IT-системы, поскольку выполнение таких запросов включает анализ большого количества заархивированных файлов журнала событий.
Проверка SQL Server выдает более детальную информацию о транзакциях, чем Сhange Tracking и Change Data Capture. Эта программа выдает информацию о том, кто работал с базой данных и какие изменения внес, а также выступает в роли фильтра транзакций (отслеживает нежелательные действия и фиксирует это в отдельный список). В то же время SQL Server Audit не записывает имя хоста или IP-адрес ПК, сгенерировавшего действие, и для некоторых событий (таких как SELECT и UPDATE) информация о данных, к которым было применено это действие, не отслеживается.
SQL Server Audit отслеживает и регистрирует действия на двух уровнях – на сервере и в базе данных. Уровни проверки устанавливаются независимо друг от друга, что дает большую гибкость и детализацию проверки. Результаты проверки сохраняются в двоичных файлах, в журнале транзакций операционной системы или журнале транзакций SQL-сервера.
Чтобы отследить все транзакции, нужно создать объект проверки на установочном экземпляре SQL-сервера. В нем можно указать несколько объектов проверки. После этого для каждого объекта следует установить спецификацию аудита сервера или аудита БД. Эта спецификация позволит определить, какие действия пользователей или события следует проверить. При этом нужно учитывать, что спецификация уровня БД выдает больше данных о действии и обеспечивает лучшую фильтрацию данных, чем спецификация уровня сервера.
Существует несколько вспомогательных программ, разработанных для облегчения мониторинга изменений информации в БД. Это Lumigent Entegra, ApexSQL Audit и NetWrix SQL Server Change Reporter, предназначенные специально для SQL-сервера.
Основные функции программ для проверки:
Все программы для проверки баз данных, включая интегрированные в СУБД инструменты для отслеживания изменений, безусловно, имеют свои преимущества и недостатки. Лучше пригласить сторонних специалистов в области аудита, которые подберут самую эффективную программу для проверки IT-системы вашей компании.
Журнал, в котором фиксируются все изменения в системе, называется журналом проверок. Он особенно нужен в тех случаях, когда много пользователей работают с одними и теми же таблицами.
В журнале проверок ведется хронологическая запись событий: вставки, обновления и удаления в указанный набор таблиц. В нем содержатся данные для восстановления, анализа и проверки последовательности сред и событий, которые сопровождают действие или приводят к транзакции на протяжении всего аудита данных.
Структура журнала проверок выбирается исходя из следующих критериев:
Важно знать, что отслеживание по журналу проверок позволяет извлечь информацию о ранее совершенных действиях в базе. Если изменения по какому-либо объекту до этого не наблюдались, то проверяющий может проверить действия в БД за истекший период по журналу событий. Эта функция важна, но ее поддержка сервером негативно влияет на производительность системы, так как выполнение таких запросов требует сканирования огромного числа (десятки тысяч) таблиц и файлов.
Приглашение специалистов для оценки состояния базы данных является одним из самых частых запросов СБ копаний. Предварительно составляется список проблем и слабых мест в IT-системе. В ходе проверки специалисты оценивают характеристики и конфигурацию оборудования, операционной системы и программного обеспечения, установленных расширений. Затем определяют профиль нагрузки, устанавливают специализированные инструменты и контролируют работу системы под нагрузкой. Обнаруживают проблемные зоны системы, тестируют параметры конфигурации СУБД. По результатам проделанной работы заказчик получает заключение с рекомендациями по настройке системы и оптимизации параметров.
Проверка защиты систем специалистами включает как классические подходы к анализу рисков и обучение требованиям защиты СУБД, так и разработку стандартов безопасности, учитывающих специфику системы компании.
Практика показала, что привлечение независимых экспертов в области ревизий БД более эффективно, чем самостоятельные проверки со стороны сотрудников фирмы.
В результате заказчик получает отчет с подробным описанием состояния системы, оценкой ее уровня защиты и рекомендациями по информационной безопасности.
Периодичность проверок зависит от:
В среднем проверки проводятся с периодичностью 1-2 раза в год. Этого достаточно, чтобы оценить уровень защиты СУБД и своевременно выявить ошибки.
Что касается инструментов проверки, то они выбираются в соответствии с установленным программным обеспечением и мощностью серверного оборудования. Компании, обрабатывающие незначительный объем данных, могут использовать только средства, встроенные в систему управления БД. Крупным организациям необходимо использовать дополнительные инструменты – программы и скрипты.
06.08.2020
Подпишитесь на нашу рассылку и получите
свод правил информационной безопасности
для сотрудников в шуточных