Подсистема аудита SQL Server (Database Engine)
Аудит экземпляра ядра СУБД SQL Server или отдельной базы данных включает в себя отслеживание и ведение журнала событий, происходящих в ядре СУБД. Подсистема аудита SQL Server позволяет проводить аудит сервера, который может предусматривать спецификации аудита серверов для событий на уровне сервера и спецификации аудита баз данных для событий на уровне базы данных. События аудита могут записываться в журналы событий или файлы аудита.
В Управляемом экземпляре SQL Azure эта функция T-SQL имеет определенные изменения в поведении. Подробные сведения обо всех изменениях поведения T-SQL см. в статье Различия T-SQL между Управляемым экземпляром SQL Azure и SQL Server.
Для SQL Server есть несколько уровней аудита в зависимости от нормативных или стандартных требований для вашей установки. Подсистема аудита SQL Server предоставляет средства и процессы, необходимые для включения, хранения и просмотра аудитов на различных объектах серверов и баз данных.
Группы действий аудита сервера можно записывать для всего экземпляра, а также группы действий аудита базы данных либо действия аудита базы данных для каждой базы данных. Событие аудита будет происходить каждый раз при обнаружении действия, подлежащего аудиту.
Все выпуски SQL Server поддерживают аудиты на уровне сервера. Все выпуски поддерживают аудит уровня базы данных, начиная с SQL Server 2016 (13.x) с пакетом обновления 1 (SP1). Раньше аудит на уровне базы банных был доступен только в выпусках Enterprise Edition, Developer Edition и Evaluation Edition. Дополнительные сведения см. в разделе Функции, поддерживаемые различными выпусками SQL Server 2016.
Этот раздел относится к SQL Server. Сведения о базе данных SQL см. в статье «Начало работы с аудитом базы данных SQL».
Компоненты подсистемы аудита SQL Server
Аудит — это сочетание в едином пакете нескольких элементов для определенной группы действий сервера или базы данных. Компоненты аудита SQL Server объединяются для создания выходных данных, которые называются аудитом, так же, как определение отчета в сочетании с графическими элементами и элементами данных создает отчет.
Аудит SQL Server использует расширенные события для создания аудита. Дополнительные сведения о расширенных событиях см. в разделе Расширенные события.
Аудит SQL Server
Объект Подсистема аудита SQL Server объединяет отдельные экземпляры действий или групп действий уровня сервера или базы данных, за которыми нужно проводить наблюдение. Аудит выполняется на уровне экземпляра SQL Server. Для каждого экземпляра SQL Server можно выполнить несколько аудитов.
При определении аудита задается место для вывода результатов. Оно называется назначением аудита. Аудит создается в отключенном состоянии и не выполняет автоматический аудит никаких действий. После включения аудита назначение аудита начинает получать от него данные.
Спецификация аудита сервера
Объект Спецификация аудита сервера принадлежит аудиту. Вы можете создать одну спецификацию аудита сервера для каждого аудита, так как оба создаются в области экземпляра SQL Server.
Спецификация аудита сервера собирает множество групп действий уровня сервера, вызываемых компонентом расширенных событий. В спецификацию аудита сервера можно включить группы действий аудита . Группы действий аудита — это предопределенные группы действий, которые являются атомарными событиями, происходящими в ядре СУБД. Эти действия передаются аудиту, который регистрирует их в целевом объекте.
Группы действий аудита уровня базы данных описываются в разделе Действия и группы действий подсистемы аудита SQL Server.
Спецификация аудита базы данных
Объект спецификации аудита базы данных также принадлежит аудиту SQL Server. Для аудита вы можете создать одну спецификацию аудита базы данных для каждой базы данных SQL Server.
Спецификация аудита базы данных включает действия аудита уровня базы данных, вызываемые компонентом расширенных событий. В спецификацию аудита базы данных можно добавлять либо группы действий аудита, либо события аудита. События аудита — это атомарные действия, которые могут быть проверены подсистемой SQL Server. Группы действий аудита — это стандартные группы действий. Оба находятся в области базы данных SQL Server. Эти действия передаются аудиту, который регистрирует их в целевом объекте. Не включайте объекты области сервера, такие как системные представления, в пользовательскую спецификацию аудита базы данных.
Группы действий подсистемы аудита уровня базы данных и действия подсистемы аудита описываются в разделе Действия и группы действий подсистемы аудита SQL Server.
Назначение
Результаты аудита отправляются цели, которая может быть файлом, журналом событий безопасности Windows или журналом событий приложений Windows. Журналы необходимо периодически просматривать и архивировать, чтобы у цели оставалось достаточно места для создания дополнительных записей.
Любой прошедший проверку пользователь может осуществлять чтение и запись в журнале событий приложений. Для работы с журналом событий приложений необходимо меньше разрешений, чем для работы с журналом событий безопасности Windows; журнал событий приложений менее защищен, чем журнал событий безопасности Windows.
Для записи в журнал безопасности Windows требуется добавить учетную запись службы SQL Server в политику создания аудита безопасности. По умолчанию в эту политику входят учетные записи «Локальная система», «Локальная служба» и «Сетевая служба». Этот параметр можно настроить с помощью оснастки политики безопасности (secpol.msc). Кроме того, политика безопасности Аудит доступа к объектам должна быть включена для регистрации как успешных , так и неуспешныхдействий. Этот параметр можно настроить с помощью оснастки политики безопасности (secpol.msc). В Windows Vista или Windows Server 2008 (и более поздних версиях) можно задать более детализированную политику, созданную в командной строке, с помощью программы политики аудита (AuditPol.exe). Дополнительные сведения по включению функции записи в журнал безопасности Windows см. в разделе Запись событий подсистемы аудита SQL Server в журнал безопасности. Дополнительные сведения о программе Auditpol.exe см. в статье базы знаний 921469 Использование групповой политики для детальной настройки аудита безопасности. Журналы событий Windows являются глобальными для операционной системы Windows. Дополнительные сведения о журналах событий Windows см. в разделе Общие сведения о средстве просмотра событий. Если для аудита необходимы более точные разрешения, используйте назначение «двоичный файл».
Если данные аудита сохраняются в файл, то для предотвращения подмены можно ограничить доступ к файлу следующим образом.
- Учетная запись службы SQL Server должна иметь разрешение на чтение и запись.
- Администраторам аудита обычно требуется разрешение на чтение и запись. Здесь подразумевается, что администраторы аудита — это учетные записи Windows, предназначенные для администрирования файлов аудита, в том числе копирования их в другие общие папки, резервного копирования и других операций.
- Агенты чтения аудита должны иметь разрешение только для чтения файлов аудита.
Даже если ядро СУБД записывается в файл, другие пользователи Windows могут читать файл аудита, если у них есть разрешение. Ядро СУБД не принимает монопольную блокировку, которая предотвращает операции чтения.
Так как ядро СУБД может получить доступ к файлу, имена входа SQL Server с разрешением CONTROL SERVER могут использовать ядро СУБД для доступа к файлам аудита. Чтобы зарегистрировать пользователей, читающих файлы аудита, определите аудит в функции master.sys.fn_get_audit_file. В этом разделе записываются имена входа с разрешением CONTROL SERVER, который обращается к файлу аудита через SQL Server.
Если администратор аудита скопирует файл в другое место (в целях архивирования или по другой причине), то список управления доступом к новому месту следует сократить до следующего набора разрешений:
- администратор аудита — чтение и запись;
- агент чтения аудита — только чтение.
Рекомендуется создавать отчеты аудита из отдельного экземпляра SQL Server, например экземпляра SQL Server Express, к которому имеют доступ только администраторы аудита или средства чтения аудита. Используя отдельный экземпляр ядра СУБД для создания отчетов, вы можете предотвратить доступ несанкционированных пользователей к записи аудита.
Можно обеспечить дополнительную защиту от несанкционированного доступа путем шифрования папки, в которой хранится файл аудита, с применением шифрования диска Windows BitLocker или шифрованной файловой системы Windows (EFS).
Дополнительные сведения о записях аудита, записываемых в целевое назначение, см. в разделе Записи подсистемы аудита SQL Server.
Общие сведения об использовании подсистемы аудита SQL Server
Для определения аудита можно использовать SQL Server Management Studio или Transact-SQL. После создания и включения аудита он начнет вести записи в целевое назначение.
Просматривать журналы событий Windows можно с помощью программы Средство просмотра событий в Windows. Для целевых объектов файлов можно использовать средство просмотра файлов журнала в SQL Server Management Studio или функцию fn_get_audit_file для чтения целевого файла.
Обычно процесс создания и использования аудита происходит следующим образом.
- Создайте аудит и определите цель.
- Создается либо спецификация аудита сервера, либо спецификация аудита базы данных, которая сопоставляет аудит. Включается спецификация аудита.
- Включите аудит.
- Производится считывание событий аудита с помощью Просмотр событийWindows, Средства просмотра журналаили функции fn_get_audit_file.
Рекомендации
В случае ошибки при инициализации аудита сервер не будет запущен. В этом случае его можно запустить, если в командную строку включить параметр -f.
Если ошибка аудита вызывает отключение сервера или не дает ему запуститься, поскольку для аудита был задан режим ON_FAILURE=SHUTDOWN, то в журнал будет записано событие MSG_AUDIT_FORCED_SHUTDOWN. Поскольку выключение происходит при первом возникновении этого события, это событие будет записано один раз. Это событие записывается после получения сообщения об ошибке, означающего, что аудит вызвал отключение. Администратор может обойти отключение, вызванное аудитом, путем запуска SQL Server в режиме отдельного пользователя с помощью флага -m . При запуске в однопользовательском режиме будет произведено изменение настроек любого аудита, запускающегося в этом сеансе, для которого было задано условие ON_FAILURE=SHUTDOWN. Такие аудиты будут запускаться с условием ON_FAILURE=CONTINUE. При запуске SQL Server с помощью флага -m сообщение MSG_AUDIT_SHUTDOWN_BYPASSED будет записано в журнал ошибок.
Дополнительные сведения о параметрах запуска службы см. в разделе Параметры запуска службы Database Engine.
Присоединение базы данных с определенным аудитом
При присоединении базы данных, имеющей спецификацию аудита с идентификатором GUID, который не существует на сервере, такая спецификация аудита получит состояние потерянная . Поскольку в экземпляре сервера не существует аудита с совпадающим идентификатором GUID, события аудита записываться не будут. Исправить эту ситуацию можно, используя команду ALTER DATABASE AUDIT SPECIFICATION для присоединения потерянной спецификации аудита к существующему аудиту сервера. Также можно использовать команду CREATE SERVER AUDIT для создания на сервере нового аудита с указанным идентификатором GUID.
Можно подключить базу данных с спецификацией аудита, определенной в другом выпуске SQL Server, который не поддерживает аудит SQL Server, например SQL Server Express, но не записывает события аудита.
Зеркальное отображение баз данных и подсистема аудита SQL Server
Если для базы данных определена спецификация аудита базы данных и используется зеркальное отображение базы данных, то в нее будет включена спецификация аудита базы данных. Для правильной работы на зеркальном экземпляре SQL необходимо выполнить настройку следующих элементов.
- Чтобы спецификация аудита базы данных могла создавать записи аудита, на зеркальном сервере должен присутствовать аудит с тем же идентификатором GUID. Это можно настроить с помощью команды CREATE AUDIT WITH GUID GUID =>
- При использовании в качестве цели двоичного файла учетная запись службы зеркального сервера должна обладать необходимыми разрешениями на место назначения, куда производится запись аудиторского следа.
- При использовании в качестве целей журналов событий Windows политика безопасности на компьютере, на котором расположен зеркальный сервер, должна разрешать учетной записи службы доступ к журналу событий безопасности или приложений.
Администраторы аудита
Члены предопределенной роли сервера sysadmin определены как пользователь dbo в каждой базе данных. Действия аудита администраторов выполняются как действия аудита пользователя dbo .
Создание аудита и работа с ним на Transact-SQL
Для реализации всех аспектов аудита SQL Server можно использовать инструкции DDL, динамические административные представления и функции и представления каталога.
Инструкции языка определения данных DDL
Чтобы создать, изменить или удалить спецификацию аудита, можно использовать следующие инструкции DDL.
| Инструкции DDL | Description |
|---|---|
| ALTER AUTHORIZATION | Изменяет владельца защищаемой сущности. |
| ALTER DATABASE AUDIT SPECIFICATION | Изменяет объект спецификации аудита базы данных с помощью компонента аудита SQL Server. |
| ALTER SERVER AUDIT | Изменяет объект аудита сервера с помощью компонента аудита SQL Server. |
| ALTER SERVER AUDIT SPECIFICATION | Изменяет объект спецификации аудита сервера с помощью компонента аудита SQL Server. |
| CREATE DATABASE AUDIT SPECIFICATION | Создает объект спецификации аудита базы данных с помощью компонента аудита SQL Server. |
| CREATE SERVER AUDIT | Создает объект аудита сервера с помощью компонента аудита SQL Server. |
| CREATE SERVER AUDIT SPECIFICATION | Создает объект спецификации аудита сервера с помощью компонента аудита SQL Server. |
| DROP DATABASE AUDIT SPECIFICATION | Удаляет объект спецификации аудита базы данных с помощью компонента аудита SQL Server. |
| DROP SERVER AUDIT | Удаляет объект аудита сервера с использованием подсистемы аудита SQL Server. |
| DROP SERVER AUDIT SPECIFICATION | Удаляет объект спецификации аудита сервера с помощью компонента аудита SQL Server. |
Динамические представления и функции
В следующей таблице перечислены динамические представления и функции, которые можно использовать для аудита SQL Server.
| Динамические представления и функции | Description |
|---|---|
| sys.dm_audit_actions | Возвращает строку для каждого действия аудита, которое можно сообщить в журнале аудита и каждой группе действий аудита, которую можно настроить в рамках аудита SQL Server. |
| sys.dm_server_audit_status | Предоставляет сведения о текущем состоянии аудита. |
| sys.dm_audit_class_type_map | Возвращает таблицу, которая сопоставляет поле class_type в журнале аудита с полем class_desc в представлении sys.dm_audit_actions. |
| fn_get_audit_file | Возвращает сведения из файла аудита, созданного аудитом сервера. |
Представления каталога
В следующей таблице перечислены представления каталога, которые можно использовать для аудита SQL Server.
| Представления каталога | Description |
|---|---|
| sys.database_audit_specifications | Содержит сведения о спецификациях аудита базы данных в аудите SQL Server на экземпляре сервера. |
| sys.database_audit_specification_details | Содержит сведения о спецификациях аудита базы данных в аудите SQL Server на экземпляре сервера для всех баз данных. |
| sys.server_audits | Содержит одну строку для каждого аудита SQL Server в экземпляре сервера. |
| sys.server_audit_specifications | Содержит сведения о спецификациях аудита сервера в подсистеме аудита SQL Server на экземпляре сервера. |
| sys.server_audit_specifications_details | Содержит сведения о спецификации аудита сервера (действия) в аудите SQL Server на экземпляре сервера. |
| sys.server_file_audits | Содержит расширенные сведения о типе аудита файлов в аудите SQL Server на экземпляре сервера. |
Разрешения
Каждая функция и команда аудита SQL Server имеют отдельные требования к разрешениям.
Чтобы создать, изменить или удалить аудит сервера или спецификацию аудита сервера, участникам на уровне сервера требуется разрешение ALTER ANY SERVER AUDIT или CONTROL SERVER. Чтобы создать, изменить или удалить спецификацию аудита базы данных, участникам базы данных требуется разрешение ALTER ANY DATABASE AUDIT либо разрешение ALTER или CONTROL на эту базу данных. Кроме того, участникам необходимо разрешение на подключение к базе данных либо разрешение ALTER ANY SERVER AUDIT или CONTROL SERVER.
Разрешение VIEW ANY DEFINITION предоставляет доступ на просмотр представлений аудита на уровне сервера, а разрешение VIEW DEFINITION — на уровне базы данных. В случае отказа в этих разрешениях возможность просматривать представления каталога переопределяется, даже если субъект имеет разрешения ALTER ANY SERVER AUDIT или ALTER ANY DATABASE AUDIT.
Дополнительные сведения о предоставлении прав и разрешений см. в разделе GRANT (Transact-SQL).
Члены роли sysadmin могут изменять любой компонент аудита; члены роли db_owner могут изменять спецификации аудита в базе данных. Аудит SQL Server проверяет, что вход, создающий или изменяющий спецификацию аудита, имеет по крайней мере разрешение ALTER ANY DATABASE AUDIT. Однако при присоединении базы данных проверка не производится. Следует считать, что спецификации аудита базы данных настолько надежны, насколько надежны участники, имеющие роли sysadmin или db_owner.
Связанные задачи
Темы, тесно связанные с аудитом
Свойства сервера (страница «Безопасность»)
Описание включения аудита входа для SQL Server. Записи аудита хранятся в журнале приложений Windows.
Параметр конфигурации сервера «c2 audit mode»
Объясняет режим аудита соответствия безопасности C2 в SQL Server.
Категория событий Security Audit (приложение SQL Server Profiler)
Объясняет события аудита, которые можно использовать в SQL Server Profiler. Дополнительные сведения см. в разделе Start SQL Server Profiler.
Трассировка SQL
Объясняет, как трассировка SQL может использоваться из собственных приложений для создания трассировок вручную, а не с помощью SQL Server Profiler.
Триггеры DDL
Объясняется, как можно использовать триггеры языка DDL для отслеживания изменения в базах данных.
Действия и группы действий подсистемы аудита SQL Server
Функция аудита SQL Server позволяет выполнять аудит групп событий и отдельных событий уровня сервера и баз данных. Дополнительные сведения см. в статье Аудит SQL Server (ядро СУБД).
Аудиты SQL Server состоят из нуля или нескольких элементов действия аудита. Эти элементы действий аудита могут быть как группами действий, например Server_Object_Change_Group, так и отдельными действиями, например операциями SELECT для таблицы.
Server_Object_Change_Group включает операции CREATE, ALTER и DROP для любого серверного объекта (базы данных или конечной точки).
У операций аудита могут быть следующие категории действий.
- Уровня сервера. Эти действия включают серверные операции, например изменения управления и операции входа и выхода из системы.
- Уровень базы данных. Эти действия включают в себя операции языка обработки данных (DML) и языка DDL.
- Уровня аудита. Эти действия включают в себя действия, происходящие во время аудита.
Некоторые действия, выполняемые на компонентах аудита SQL Server, внутренне проверяются в определенном аудите, и в этих случаях события аудита происходят автоматически, так как событие произошло в родительском объекте.
Следующие действия подлежат аудиту по своей природе.
- Изменение состояния подсистемы аудита сервера (включение или отключение)
Это событие по своей природе не подлежат аудиту.
- CREATE SERVER AUDIT SPECIFICATION
- ALTER SERVER AUDIT SPECIFICATION
- DROP SERVER AUDIT SPECIFICATION
- CREATE DATABASE AUDIT SPECIFICATION
- ALTER DATABASE AUDIT SPECIFICATION
- DROP DATABASE AUDIT SPECIFICATION
Все операции аудита отключаются при первоначальном создании.
Группы действий аудита уровня сервера
Группы действий аудита на уровне сервера — это действия, аналогичные классам событий аудита безопасности SQL Server. Дополнительные сведения см. в разделе SQL Server Event Class Reference.
В следующей таблице приведены группы действий аудита уровня сервера и представлены эквивалентные классы событий SQL Server (если возможно).
Это событие вызывается для объектов схемы. Эквивалентно Audit Object Derived Permission Event Class.
Это событие возникает при вызове участником хранимых процедур sp_defaultdb или sp_defaultlanguage или инструкций ALTER LOGIN. Эквивалентно Audit Addlogin Event Class.
Это событие вызывается хранимыми процедурами sp_addlogin и sp_droplogin. Также эквивалентно Audit Login Change Property Event Class.
Рекомендации
Группы действий уровня сервера охватывают действия в экземпляре SQL Server. Например, если соответствующая группа будет возвращена в спецификацию аудита сервера, то будет производиться запись любой проверки доступа к объекту схемы в любой базе данных. В спецификации аудита базы данных производится запись доступа только к объектам схемы этой базе данных.
Действия уровня сервера не позволяют проводить подробную фильтрацию действий уровня базы данных. Для точной фильтрации действий необходим аудит уровня базы данных, например аудит действий SELECT в таблице Customers, производимых от лица имен входа в группе Employee. Не включайте объекты области сервера, такие как системные представления, в пользовательскую спецификацию аудита базы данных.
Из-за накладных расходов, связанных с включением аудита уровня транзакций, начиная с SQL Server 2016 (13.x) с пакетом обновления 2 (SP2) и SQL Server 2017 (14.x) CU4, аудит уровня транзакций отключен по умолчанию, если вы не включили соответствие общим критериям. При отключении соответствия стандарту Common Criteria вы по-прежнему сможете добавить действие из TRANSACTION_GROUP в спецификацию аудита, но оно фактически не будет собирать какие-либо действия транзакции. Если вы планируете настроить любые действия аудита из TRANSACTION_GROUP, убедитесь, что инфраструктура аудита на уровне транзакций включена путем включения общего соответствия критериям, начиная с SQL Server 2016 (13.x) с пакетом обновления 2 (SP2) и SQL Server 2017 (14.x) CU4 и более поздних версий. Обратите внимание, что в SQL Server 2016 (13.x) аудит на уровне транзакций также может быть отключен с флагом трассировки 3427, начиная с накопительного пакета обновления 1 (SP1) CU2.
Группы действий аудита уровня базы данных
Группы действий аудита уровня базы данных похожи на классы событий аудита безопасности SQL Server. Дополнительные сведения о классах событий см. в разделе SQL Server Event Class Reference.
В следующей таблице описываются группы действий аудита уровня базы данных и предоставляются эквивалентные классы событий SQL Server (где возможно).
Действия аудита уровня базы данных
Действия аудита уровня базы данных поддерживают аудит напрямую в базе данных, схеме или в объектах схемы, например в таблицах, представлениях, хранимых процедурах, функциях, расширенных хранимых процедурах, очередях, синонимах. Не подлежат аудиту типы, коллекции схем XML, база данных и схема. Аудит объектов схемы можно настроить для схемы и базы данных. Это означает, что будет выполнен аудит событий всех объектов схемы, содержащихся в указанной схеме или базе данных. В следующей таблице описываются действия аудита уровня базы данных.
| Действие | Description |
|---|---|
| ВЫБРАТЬ | Это событие возникает при вызове инструкции SELECT. |
| ОБНОВИТЬ | Это событие возникает при вызове инструкции UPDATE. |
| ВСТАВИТЬ | Это событие возникает при вызове инструкции INSERT. |
| DELETE | Это событие возникает при вызове инструкции DELETE. |
| ВЫПОЛНИТЬ | Это событие возникает при вызове инструкции EXECUTE. |
| ПРИЕМ | Это событие возникает при вызове инструкции RECEIVE. |
| ССЫЛКИ | Это событие возникает при проверке разрешения REFERENCES. |
Рекомендации
- Действия аудита уровня базы данных не применяются к столбцам.
- Если обработчик запросов параметризует запрос, параметр может отображаться в журнале событий аудита вместо значений столбца запроса.
Группы действий аудита уровня аудита
Также можно производить аудит действий, происходящих во время аудита. Это можно осуществлять как в области сервера, так и в области базы данных. В области базы данных это справедливо только для спецификаций аудита базы данных. В следующей таблице описываются группы действий аудита уровня аудита.
CREATE SERVER AUDIT
ALTER SERVER AUDIT
DROP SERVER AUDIT
CREATE SERVER AUDIT SPECIFICATION
ALTER SERVER AUDIT SPECIFICATION
DROP SERVER AUDIT SPECIFICATION
CREATE DATABASE AUDIT SPECIFICATION
ALTER DATABASE AUDIT SPECIFICATION
Основные функции для создания журнала аудита SQL Server в базах данных
Независимо от размера вашей организации, в системах баз данных, таких как 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 соответствует логинам. Он описал два представления каталога как “кусок хлеба” администратора базы данных, когда пытался определить, кто на самом деле имеет доступ к наборам данных и — что более важно — кто должен иметь доступ.
Аудит СУБД Microsoft SQL Server с расширенными фильтрами
В этой. статье расскажем об инструменте для гранулярного аудита запросов ApexSQL Audit. Инструмент может быть эффективен, например, когда стоит задача аудита SQL Server с точностью до ключей оператора SELECT, имени таблицы, базы данных или представления.
Чтобы настроить аудит, добавим БД в интерфейсе ApexSQL Audit и выберем операторы:
Затем, в фильтре объектов создадим список того, что нужно включить в аудит и проверим таблицы/представления/объекты для аудита. Выберем как можно больше параметров, используя фильтры в интерфейсе. По завершении примени изменения, затем переключимся на Расширенный фильтр (5).
Расширенный фильтр покажет опции, которые были выбраны с помощью фильтра в интерфейсе. Чтобы добавить фильтры ключевых слов, нажмём зеленый значок +:
В интерфейсе есть кнопка «indent/outdent», которая прикрепит критерии и прикрепит их к уровням выше и ниже. Начнём с добавления фильтра с условием AND и выберем «Text Data» в качестве поля. Это будет соответствовать ключам в операторе SELECT (или другом операторе). Мы будем используем оператор «Содержит», а затем введем текст:
Если необходимо сопоставить несколько ключевых слов, добавьте еще одну строку в фильтр, используя зеленый значок +. Затем можно сделать отступ и использовать оператор OR, как показано на скриншоте ниже. Нажмите «Apply», когда закончите. Фильтр можно также экспортировать, чтобы его сохранить.
Теперь пришло время проверить. Запустим несколько операторов SQL, которые совпадают и не совпадают с фильтром.
Используйте «Default complete auditing report» с диапазоном времени, установленным на «last 1 minute» при тестировании, чтобы не получить большой набор данных.
Расширенные фильтры — мощный инструмент аудита, который позволяет выполнять большинство релевантных задач. Ниже ссылки на дополнительную информацию по ApexSQL Audit.
Если хотите попробовать ApexSQL Audit или другие продукты Quest — оставьте заявку в форме обратной связи.