Microsoft SQL Server: настройка источника (SQL Audit)

Данное руководство описывает процесс настройки сбора и отправки событий Microsoft SQL Server (MS SQL) в R-Vision SIEM.

Данный метод аудита является самодостаточным. Внедрение дополнительных инструментов сбора не требуется, так как вся цепочка событий регистрируется в рамках единой конфигурации SQL Server Audit.

Предварительные требования

Сетевая доступность сервера СУБД (Microsoft SQL Server) источника по целевому порту и протоколу для каждой ноды кластера SIEM.
Учетная запись в СУБД с правами на чтение базы данных.

Настройка Microsoft SQL Server

Настройка аудита на стороне MS SQL Server

Для настройки аудита на стороне MS SQL Server выполните следующие шаги:

Создайте директорию для хранения файлов аудита, например C:\SQLAudit\.

В среде SQL Server Management Studio (SSMS) выполните скрипт под учетной записью с правами sysadmin. Данный скрипт создает объект аудита с оптимальными промышленными лимитами (ротация на 30 файлов по 512 МБ, суммарный буфер около 15 ГБ).

USE [master];
GO

-- 1. Создаем объект аудита (указывает путь размещения бинарных логов)
IF NOT EXISTS (SELECT * FROM sys.server_audits WHERE name = 'AUDIT_Security_Prod')
BEGIN
    CREATE SERVER AUDIT [AUDIT_Security_Prod]
    TO FILE (
        FILEPATH = N'C:\SQLAudit\',      -- Папка должна физически существовать на сервере
        MAXSIZE = 512 MB,                -- Максимальный размер одного файла .sqlaudit
        MAX_ROLLOVER_FILES = 30          -- Лимит ротации файлов (безопасный буфер под SIEM)
    )
    WITH ( QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE );
END
GO

-- 2. Активируем аудит сервера
ALTER SERVER AUDIT [AUDIT_Security_Prod] WITH (STATE = ON);
GO

-- 3. Пересоздаем спецификацию аудита (определяет перечень собираемых событий)
IF EXISTS (SELECT * FROM sys.server_audit_specifications WHERE name = 'SAS_Security_Prod')
BEGIN
    ALTER SERVER AUDIT SPECIFICATION [SAS_Security_Prod] WITH (STATE = OFF);
    DROP SERVER AUDIT SPECIFICATION [SAS_Security_Prod];
END
GO

CREATE SERVER AUDIT SPECIFICATION [SAS_Security_Prod]
FOR SERVER AUDIT [AUDIT_Security_Prod]
    -- Полный аудит запросов на уровне сервера (DDL и DML)
    ADD (BATCH_COMPLETED_GROUP),
    ADD (SCHEMA_OBJECT_ACCESS_GROUP),
    -- Аудит сессий информационной безопасности
    ADD (SUCCESSFUL_LOGIN_GROUP),
    ADD (FAILED_LOGIN_GROUP),
    ADD (LOGOUT_GROUP)
WITH (STATE = ON);
GO

Учетная запись, под которой запущена служба Windows SQL Server (например, NT SERVICE\MSSQLSERVER), должна иметь полные права (Read/Write) на папку, указанную в параметре FILEPATH (C:\SQLAudit\).

Поиск или создание технической базы данных

Перед созданием функции интеграции необходимо определить целевую базу данных. Разворачивать служебную функцию внутри бизнес-баз (например, баз ERP или CRM) категорически запрещено.

Для поиска существующей административной СУБД выполните в среде SSMS следующий запрос:

SELECT
    name AS [Database_Name],
    database_id AS [ID],
    create_date AS [Create_Date],
    state_desc AS [Status]
FROM sys.databases
ORDER BY database_id ASC;

Определите целевую базу:
- Если техническая СУБД существует, ищите базы с именами dba, admin, monitoring, AuditTest или msdb (системная база данных под database_id = 4).
- Если на сервере отсутствуют технические базы, создайте новую изолированную базу данных специально для нужд информационной безопасности:
  CREATE DATABASE [DBA_Monitoring]; GO

Создание выделенной учетной записи для SIEM

Для подключения коннектора R-Vision создайте изолированную учетную запись. Использование учетных записей с правами администратора (sa) в целях безопасности категорически запрещено.

В среде SSMS под учетной записью администратора СУБД выполните следующий скрипт. Замените AuditTest на имя вашей выбранной технической базы, а Strong_Password_Here — на надежный пароль:

USE [master];
GO

-- 1. Создаем имя входа (Login) на уровне всего SQL-сервера
IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = 'audit_user')
BEGIN
    CREATE LOGIN [audit_user]
    WITH PASSWORD = N'Strong_Password_Here',
    DEFAULT_DATABASE = [AuditTest], -- Указываем техническую базу по умолчанию
    CHECK_EXPIRATION = OFF,          -- Отключаем истечение срока пароля для служебной учетки
    CHECK_POLICY = ON;
END
GO

USE [AuditTest]; -- Переключаемся в техническую базу данных
GO

-- 2. Создаем пользователя (User) внутри конкретной технической базы данных
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = 'audit_user')
BEGIN
    CREATE USER [audit_user] FOR LOGIN [audit_user];
END
GO

После создания учетной записи выдавать ей стандартные роли резервного копирования или чтения данных (db_datareader) не требуется. Все необходимые минимальные права на чтение логов будут выданы автоматически на следующем шаге командой GRANT SELECT ON dbo.GetServerAuditLogs TO [audit_user];.

Создание параметризованной функции интеграции

В целевой базе данных (например, AuditTest), к которой будет подключаться коннектор SIEM, выполните скрипт создания функции.

Настроенный аудит является централизованным (уровня сервера). Он автоматически собирает события со всех баз данных на данном экземпляре SQL Server.

Функцию dbo.GetServerAuditLogs необходимо создать строго в одной технической или административной базе данных, например, AuditTest, к которой подключается коннектор R-Vision. Создавать ее в других базах данных не требуется — через эту точку входа SIEM будет получать логи по всему серверу. Название целевой СУБД для каждого события будет передаваться в системном поле database_name.

Функция принимает от R-Vision три чекпоинта одновременно, что позволяет СУБД переходить к нужной строке на диске и полностью исключает зацикливание на одинаковых оффсетах бинарных страниц. Внутри функции настроена фильтрация для исключения собственных запросов SIEM.

USE AuditTest;
GO

IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.GetServerAuditLogs') AND type = 'IF')
    DROP FUNCTION dbo.GetServerAuditLogs;
GO

CREATE FUNCTION dbo.GetServerAuditLogs (
    @TargetOffset BIGINT = NULL,
    @TargetFile NVARCHAR(260) = NULL,
    @TargetSeq INT = NULL
)
RETURNS TABLE
AS
RETURN
(
    SELECT
        -- Системные поля SQL Server без изменений названий
        event_time, action_id, class_type, [statement], succeeded,
        server_principal_name, database_name, schema_name, object_name,
        host_name, client_ip, application_name, affected_rows, response_rows,
        session_id, connection_id, session_server_principal_name, server_instance_name,
        sequence_number, file_name, audit_file_offset, additional_information
    FROM sys.fn_get_audit_file('C:\SQLAudit\*', DEFAULT, DEFAULT)
    WHERE server_principal_name <> N'audit_user' -- Исключаем саму SIEM
      AND server_principal_name <> N'NT SERVICE\SQLTELEMETRY' -- Исключаем телеметрию MS
      AND server_principal_name <> N'NT SERVICE\MSSQLSERVER'   -- Исключаем саму службу СУБД (при необходимости)
      AND server_principal_name <> N'NT SERVICE\SQLSERVERAGENT' -- Исключаем планировщик Agent (при необходимости)

      -- Инкрементальный фильтр по трем координатам состояния
      AND (
          @TargetFile IS NULL
          OR @TargetFile = 'default'
          OR @TargetOffset = 0
          OR file_name > @TargetFile
          OR (file_name = @TargetFile AND audit_file_offset > @TargetOffset)
          OR (file_name = @TargetFile AND audit_file_offset = @TargetOffset AND sequence_number > ISNULL(@TargetSeq, 0))
      )
);
GO

-- Делегирование прав на выполнение пользователю коннектора
GRANT SELECT ON dbo.GetServerAuditLogs TO [audit_user];
GO

Если служебная учетная запись SIEM-системы отличается от audit_user, обязательно замените ее имя в строке фильтрации WHERE server_principal_name <> N'<account_name>'.

Расчет параметров буфера и интервала опроса

Для обеспечения непрерывности сбора и исключения деградации производительности СУБД параметры ротации файлов на SQL Server и интервал опроса в R-Vision должны рассчитываться на основе текущей интенсивности событий (EPS — Events Per Second).

Методика замера текущей интенсивности событий (EPS)

Перед финализацией параметров буфера необходимо измерить реальную нагрузку (EPS) на конкретном экземпляре СУБД в периоды пиковой бизнес-активности.

Если аудит уже включен и работает хотя бы несколько часов, точную среднюю нагрузку можно вычислить простым математическим запросом. Скрипт считает количество событий за последний час и делит их на 3600 секунд.

Выполните запрос в SSMS:

USE [master];
GO

DECLARE @MinTime DATETIME2;
DECLARE @MaxTime DATETIME2;
DECLARE @TotalEvents BIGINT;

-- Выкачиваем метаданные за последний час
SELECT
    @MinTime = MIN(event_time),
    @MaxTime = MAX(event_time),
    @TotalEvents = COUNT_BIG(*)
FROM sys.fn_get_audit_file('C:\SQLAudit\*', DEFAULT, DEFAULT)
WHERE event_time >= DATEADD(hour, -1, GETUTCDATE());

-- Считаем EPS
SELECT
    @MinTime AS [Start_UTC],
    @MaxTime AS [End_UTC],
    @TotalEvents AS [Total_Events_Count],
    DATEDIFF(second, @MinTime, @MaxTime) AS [Total_Seconds],
    CAST(CAST(@TotalEvents AS FLOAT) / ISNULL(NULLIF(DATEDIFF(second, @MinTime, @MaxTime), 0), 1) AS NUMERIC(10,2)) AS [Average_EPS];
GO

Расчет объема локального буфера СУБД

Средний размер одного бинарного события SQL Server Audit на диске составляет 500 байт (0,5 КБ).

Формулы расчета:

Объем логов в секунду: Интенсивность (EPS) * 0,5 КБ = Скорость записи (КБ/с);
Объем логов в сутки: Скорость записи (КБ/с) * 86400 с / 1024 / 1024 = Объем (ГБ/сутки);
Необходимый буфер: Объем (ГБ/сутки) * Время_автономии (суток) = Общий_размер_буфера (ГБ).

Пример расчета для нагрузки 200 EPS с обеспечением автономии на выходные (2 суток)

Конфигурация ротации под целевой буфер. Для удержания около 15—16 ГБ логов на диске устанавливаются параметры:

MAXSIZE = 512 MB (один файл заполняется примерно за 1,5 часа).
MAX_ROLLOVER_FILES = 30 (30 файлов * 512 МБ = 15 ГБ).

Расчет интервала опроса и размера пачки

Главное правило стабильности инкрементального сбора: объем данных, генерируемый СУБД за интервал паузы, должен быть строго меньше, чем лимит считывания за один запрос (TOP X). В противном случае сборщик логов начнет отставать от реального времени.

Формула проверки стабильности: Пауза_опроса (с) * Интенсивность (EPS) < Лимит_выборки (TOP)

Рекомендация для высоконагруженных систем

Для промышленной среды и высоконагруженных систем (200+ EPS) рекомендуется использовать интервал опроса 15 секунд и лимит TOP 10000. При такой настройке SQL Server тратит на отдачу пакета логов из оперативной памяти менее 0,01 секунды, выполняя один прыжок по диску раз в 15 секунд. Нагрузка на процессор (CPU) и диски (I/O) СУБД составляет менее 0,1%, что полностью безопасно для высоконагруженных боевых серверов.

Настройка в R-Vision SIEM

Для настройки сбора и нормализации событий источника в R-Vision SIEM выполните следующие шаги:

В интерфейсе R-Vision SIEM создайте секрет со строкой подключения. Для этого:
1. Перейдите в раздел Ресурсы → Секреты.
2. Нажмите на кнопку Создать ().
3. В раскрывшемся окне создания секрета заполните поля:
  - Название: введите название секрета.
  - Описание (опционально): опишите, для чего будет использоваться секрет.
  - Тип секрета: выберите вариант Строка подключения.
  - Строка подключения: введите строку вида:
    
    jdbc:sqlserver://<address>\<instance>:<port>;encrypt=false;databaseName=<database>;user=<user>;password=<password>;
    
    Здесь:
    
    <address> — адрес сервера базы данных.
    
    <instance> — опциональная сущность сервера СУБД. Для использования сущность должна быть заранее создана с помощью SQL Server Management Studio.
    
    <port> — порт подключения.
    
    <database> — имя базы событий аудита.
    
    <user> — логин пользователя базы данных.
    
    <password> — пароль пользователя базы данных.
    
    Пример 1. Пример строки подключения:
    
    jdbc:sqlserver://10.150.15.34\MSSQLSERVER1:1433;encrypt=false;databaseName=AuditTest;user=audit_user;password=P@ssw0rd;
4. Нажмите на кнопку Создать.
Создайте новый конвейер в коллекторе.

Добавьте на конвейер элемент Точка входа для событий аудита команд MS SQL со следующими параметрами:

Название: введите название точки входа.
Тип точки входа: выберите вариант Database.
Драйвер базы данных: выберите вариант MS SQL.
Адрес подключения: выберите созданный ранее секрет.

SQL-запрос: введите запрос вида:

SELECT TOP 10000
    bcalv.*,
    N'MSSQL' AS appname,
    @@SERVERNAME AS dvchost
FROM dbo.GetServerAuditLogs(?, ?, ?) bcalv
ORDER BY bcalv.event_time ASC, bcalv.audit_file_offset ASC, bcalv.sequence_number ASC;

Интервал запроса, секунд: введите значение 15.
Поле идентификатора: добавьте три параметра строго в соответствии со следующей спецификацией:
- Ключ 1: audit_file_offset со значением 0;
- Ключ 2: file_name со значением default;
- Ключ 3: sequence_number со значением 0.
  
  При первом обращении R-Vision передаст стартовый массив [0, default, 0], функция автоматически инициализирует чтение с начала первого доступного файла, а со второй итерации перейдет на точечный инкрементальный сбор.

Максимальное количество строк: введите значение 10000.

Приведенные параметры актуальны для СУБД с интенсивностью потока логов EPS < 666. При превышении этого порога рекомендуется пересчитать параметры в соответствии с методикой, описанной в разделе Расчет параметров буфера и интервала опроса.

Добавьте на конвейер элемент Нормализатор с правилом Microsoft SQL Server Audit (идентификатор правила: RV-N-368).
Соедините нормализатор с точкой входа.
Добавьте на конвейер элемент Конечная точка типа Хранилище событий.
Соедините конечную точку с нормализатором.
Сохраните и установите конфигурацию конвейера.

Пример конфигурации конвейера:

microsoft sql server audit pipeline

После настройки передачи событий, если настройка выполнена корректно, в хранилище начнут поступать события из журналов SQL Server.

Найти события источника в хранилище можно по следующему фильтру:

normalization_rule_name = "Microsoft SQL Server Audit"

Рекомендации по оптимизации производительности для высоконагруженных СУБД

Влияние подсистемы SQL Server Audit на производительность напрямую зависит от профиля нагрузки экземпляра СУБД, интенсивности выполнения пакетов T-SQL (EPS) и архитектуры приложений. Для обеспечения стабильности промышленной среды необходимо внедрять следующие архитектурные оптимизации.

Предварительное тестирование и оценка объемов

Включение аудита на уровне сервера (BATCH_COMPLETED_GROUP, SCHEMA_OBJECT_ACCESS_GROUP) генерирует избыточный поток данных.

Рекомендация: перед развертыванием на промышленном сервере в обязательном порядке проведите профилирование нагрузки на тестовом или Staging-стенде. Сделайте замер EPS согласно методике в разделе Расчет параметров буфера и интервала опроса для точной оценки скорости заполнения дискового пространства и расчета утилизации CPU.

Вынесение бинарных логов на выделенную дисковую подсистему

По умолчанию инструкция предполагает запись файлов во внутренний каталог системного диска: FILEPATH = N’C:\SQLAudit\'. Для нагруженных систем запись потока аудита на диск C:\ совместно с операционной системой и файлом подкачки недопустима.

Рекомендация: вынесите целевую директорию аудита на отдельный высокоскоростной массив. Рекомендуется использовать выделенные диски SSD/NVMe с низким показателем задержки I/O. Измените значение параметра FILEPATH в скрипте создания аудита на выделенный том.

Примеры продового разделения дисков:

E:\SQLAudit\ — выделенный том для логов безопасности;
F:\MSSQL\Audit\ — изолированный высокоскоростной массив.

Настройка исключений антивирусного ПО и агентов EDR

Активное сканирование каталога с бинарными логами средствами антивирусов или агентами EDR/XDR создает паразитную нагрузку на дисковую подсистему за счет двойного чтения файлов.

Рекомендация: по согласованию с подразделением ИБ добавьте маску пути *.sqlaudit и саму целевую директорию логов в список постоянных исключений (Exclusions) антивирусных сканеров. Это полностью исключит:

блокировки файлов .sqlaudit со стороны AV-движков в момент фиксации событий СУБД;
избыточные операции чтения новых файлов .sqlaudit антивирусом при автоматической ротации.

Настройка задержки буферизации (параметр `QUEUE_DELAY`)

Параметр QUEUE_DELAY определяет максимальное время (в миллисекундах), в течение которого события аудита могут накапливаться в оперативной памяти сервера перед принудительным сбросом (flush) на диск.

Рекомендация: по умолчанию в инструкции установлена задержка QUEUE_DELAY = 1000 (1 секунда). На высоконагруженных серверах (350+ EPS) для снижения частоты дисковых операций записи (IOPS) рекомендуется увеличить этот интервал. Логи будут буферизоваться дольше и сбрасываться на диск более крупными пачками (батчами), что снизит накладные расходы на дисковую подсистему.

Рекомендуемые продовые значения под высокую нагрузку:

QUEUE_DELAY = 5000 — сброс на диск раз в 5 секунд;
QUEUE_DELAY = 10000 — сброс на диск раз в 10 секунд — максимальный уровень оптимизации диска.

Оптимизация пагинации и частоты опроса на стороне SIEM

Параметры вычитки логов коннектором JDBC/ODBC напрямую влияют на утилизацию ресурсов процессора (CPU) СУБД. Регулярные ежесекундные обращения создают паразитную нагрузку на компиляцию планов запросов.

Рекомендация: для снижения накладных расходов на обработку запросов коннектора перейдите от частых мелкопакетных опросов к редким крупноблочным выгрузкам. Увеличьте интервал опроса на уровне параметров Интервал запроса точки входа R-Vision одновременно с увеличением лимита TOP в теле SQL-запроса.

Пример оптимизации параметров пагинации под нагрузку:

По умолчанию (низкая нагрузка): 10 секунд / TOP 2000 строк событий.
Оптимально для Production (высокая нагрузка): 15 секунд / TOP 10000 строк событий.

Тонкая фильтрация паразитных событий на уровне SQL-функции

В базовой конфигурации функции интеграции заложена фильтрация базового системного шума операционной системы и самого коннектора. Для высоконагруженных промышленных СУБД этот список необходимо расширять на основе анализа поступающего в SIEM потока данных.

Рекомендация: расширяйте секцию WHERE внутри функции dbo.GetServerAuditLogs дополнительными предикатами исключения. Отсекайте автоматизированные запросы систем мониторинга, резервного копирования и циклические технологические проверки приложений (Health Checks).

Пример 2. Примеры дополнительных продовых фильтров:

-- Исключение по маске имени приложения
AND application_name NOT LIKE 'SQLAgent%'
AND application_name NOT LIKE 'Monitoring%'
AND application_name NOT LIKE 'Zabbix%'

-- Исключение по хосту источника
AND host_name NOT IN ('monitoring01')

-- Исключение служебных учетных записей инфраструктуры
AND server_principal_name NOT IN ('svc_monitoring', 'svc_zabbix', 'svc_backup')

-- Исключение циклических статических запросов проверки связи
AND statement NOT IN ('SELECT 1', 'SELECT @@SPID', 'SELECT GETDATE()')

-- Исключение регулярных запросов мониторинга производительности
AND statement NOT LIKE '%dm_os_performance_counters%'

Критическое предупреждение ИБ

Разрешается исключать только доверенные технологические запросы, не несущие значимого контекста информационной безопасности. Перед добавлением любого фильтра по полю statement проведите ретроспективный анализ событий в интерфейсе SIEM и убедитесь, что исключаемые текстовые конструкции запросов не используются в действующих правилах корреляции или сценариях реагирования (Use Cases).

Изоляция дисковых потоков ввода-вывода (I/O Bottlenecks)

При отсутствии физического разделения ресурсов конкуренция за дисковое время между логами транзакций, временными таблицами и потоком аудита приводит к деградации производительности СУБД.

Рекомендация: архитектурно разнесите по разным независимым физическим дискам/массивам файлы базы данных (.mdf), журнал транзакций (.ldf), системную базу tempdb и целевой каталог файлов аудита .sqlaudit. Если дисковых ресурсов сервера недостаточно, изолируйте tempdb от каталога аудита, так как оба этих компонента генерируют максимальный поток операций последовательной и случайной записи (IOPS).

Пример 3. Пример деструктивной (неоптимизированной) структуры дисков:

C: (Системный диск)
 └── Windows + SQL Executables + tempdb + Transaction Logs + SQLAudit

Пример эталонного (производительного) распределения дисков на Production:

C: → Операционная система Windows + исполняемые файлы MS SQL Server.
D: → Пользовательские базы данных (Файлы данных .mdf).
E: → Журнал транзакций (Файлы .ldf) — требует последовательной записи.
F: → Системная база данных tempdb — требует высокой скорости случайного доступа.
G: → Каталог хранения файлов аудита SQLAudit — изолированный поток последовательной записи.

Была ли полезна эта страница?

Обратная связь