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

Недавно, на одном из вебинаров Келли рассказал о возможностях аудита, которые поставляются с программным обеспечением базы данных, и о том, как администраторы баз данных (DBA) могут использовать их для создания контрольного журнала SQL Server, который документирует подробности работы в системах для обеспечения безопасности, соответствия нормативным требованиям и администрирования.

Одним из многих инструментов аудита, предлагаемых SQL Server, является трассировка по умолчанию. Эта функция находится в режиме обслуживания, и Microsoft не рекомендует использовать ее в новых приложениях. Но, по словам Келли, бывшего администратора баз данных SQL Server, который в настоящее время работает в качестве архитектора данных в AgFirst Farm Credit Bank в Колумбии, S.C., она все еще может предоставить некоторую полезную информацию

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

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

Расширенные события предлагают новый трек аудита

Для аудита в новых приложениях Microsoft рекомендует использовать инструмент мониторинга производительности SQL Server Extended Events вместо функции трассировки по умолчанию. Инструмент Extended Events был введен в SQL Server 2008, чтобы уменьшить влияние обработки процессов настройки и аудита производительности базы данных. Технология стала более полезной после добавления набора графических интерфейсов в SQL Server 2012.

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

Пользователи по-прежнему могут создавать трассировки на уровне клиента с помощью SQL Server Profiler, а трассировки на стороне сервера - с помощью SQL Trace, но Microsoft отказалась от этих инструментов. По словам Келли, трассировки, построенные с их помощью, имеют тенденцию быть довольно тяжелыми с точки зрения производительности, и они были заменены расширенными событиями в SQL Server 2012. «Если вы хотите проводить аудит вещей, которые являются новыми функциями в любой из версий после SQL Server 2008 R2 единственный способ проверить его, единственный способ обнаружить и использовать его - это Extended Events», - отметил он.

Варианты записи базы данных логинов

По словам Келли, в случае входа в систему SQL Server автоматически настраивается на запись всех неудачных попыток, но пользователи могут настроить его под свои нужды. Система может быть переконфигурирована для отслеживания всех успешных входов в систему или неудачных и успешных попыток. Если у вас есть альтернативная система отслеживания, вы даже можете отключить механизм SQL Server.

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

По словам Келли, изменить настройки SQL Server для аудита входов в систему относительно просто. Сначала перейдите в SQL Server Management Studio и щелкните правой кнопкой мыши на Server. Выберите Properties, затем выберите  Security. На вкладке « Security» можно выбрать один из четырех параметров аудита входа в систему: None, Failed logins only, Successful logins only или Both failed and successful logins. «SQL Server должен быть перезапущен после внесения любых изменений; иначе он не будет собирать данные так, как вы хотите», - сказал он.

Альтернативные инструменты аудита

Дополнительные механизмы аудита, доступные администраторам баз данных, включают управление на основе политик, которое Келли назвал «в основном групповой политикой для SQL Server». Функцию управления на основе политик можно использовать для принудительного применения параметров политики в ядре базы данных SQL Server, но он сказал, что его лучше всего использовать в качестве «системы проверки», поскольку он может проверять почти все в экземпляре SQL Server.

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

Триггеры языка определения данных и триггеры входа в систему также можно использовать для создания контрольного журнала SQL Server в системах баз данных. Например, их можно включить, если кто-то попытается войти в систему или изменить систему. Но Келли сказал, что триггеры следует использовать с осторожностью, поскольку они могут добавить накладные расходы на обработку и неожиданно заблокировать процессы. «Часто лучше просто провести аудит для происходящего события», а затем исправить проблему, добавил он.

По словам Келли, сбор данных изменений (CDC) изначально не предназначался для аудита. Его первоначальная цель заключалась в том, чтобы записывать изменения данных в таблицах SQL Server, чтобы пользователям приходилось только обрабатывать то, что было изменено, для обновления хранилища данных. Тем не менее, по словам Келли, CDC можно использовать при аудите, поскольку он также позволяет администраторам баз данных читать файлы журнала базы данных. Однако он добавил, что это не является поддерживаемым использованием технологии и должно быть сделано только в качестве крайней меры.

Одной из ключевых вещей, которые хотят знать аудиторы базы данных, является то, какие пользователи имеют доступ к базе данных и какой доступ имеют эти пользователи. Келли сказал, что есть два основных уровня представлений каталога безопасности для основных пользователей: sys.server_principals и sys.database_principals. В частности, sys.server_principals соответствует логинам. Он описал два представления каталога как “кусок хлеба” администратора базы данных, когда пытался определить, кто на самом деле имеет доступ к наборам данных и - что более важно - кто должен иметь доступ.

No Comments