Database Activity Monitoring: как устроен аудит запросов к СУБД
Database Activity Monitoring (DAM) — это класс систем, которые видят и записывают, кто, когда и какими SQL-запросами обращается к базам данных, разбирают эти запросы и применяют к ним политики: что разрешено, что подозрительно, а что нужно немедленно заблокировать или проэскалировать. По сути DAM отвечает на вопрос «что на самом деле происходит внутри СУБД» независимо от встроенного аудита самой базы и в обход прав администратора. **Если коротко:** ключевое отличие DAM-решений — не в красивых дашбордах, а в способе съёма активности (агент на сервере СУБД, сетевой прокси, зеркалирование трафика или встроенный аудит), потому что именно он определяет полноту перехвата, влияние на производительность и слепые зоны. Ниже разбираем, как DAM перехватывает и разбирает SQL, как работают политики и алертинг, чем платят за мониторинг в нагрузке, и даём чек-лист внедрения. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге защиты баз данных и DAM](/rating/database-security-db-activity-monitoring).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Что такое DAM и какую задачу он решает
Database Activity Monitoring — это независимый контур наблюдения за обращениями к СУБД. В отличие от штатного аудита базы, DAM выносит сбор и анализ событий за пределы самого сервера данных, поэтому его сложнее «обойти» или отключить тому, у кого есть права администратора БД. Это и есть главная ценность для безопасности и комплаенса: контроль привилегированных пользователей и фиксация доступа к чувствительным данным.
DAM закрывает три типовые задачи. Первая — безопасность: выявить аномальный или вредоносный доступ (массовая выгрузка таблиц, обращение к данным в нерабочее время, SQL-инъекции, доступ DBA к платёжным данным). Вторая — комплаенс: вести неизменяемый журнал доступа к персональным данным и подтверждать выполнение требований регуляторов и внутренних политик. Третья — расследования: дать аналитику восстановить полную картину «кто что делал» при разборе инцидента.
DAM в цифрах: что важно понимать сразу
Агент, сетевой прокси, зеркалирование трафика, встроенный аудит
Парсинг до уровня объекта, операции и условий
Чем глубже перехват, тем выше влияние на СУБД
Замер полноты перехвата и просадки производительности
Как DAM перехватывает запросы: четыре способа съёма
Способ съёма активности — фундаментальная развилка архитектуры DAM. От него зависит, что именно увидит система: только сетевой трафик или ещё и локальные подключения, весь SQL или его часть, и какой ценой по производительности. На практике способы комбинируют, чтобы закрыть слепые зоны.
- **Локальный агент (sensor) на сервере СУБД.** Перехватывает обращения на уровне межпроцессного взаимодействия, разделяемой памяти или системных вызовов. Видит и сетевые, и локальные подключения (включая консольный доступ DBA), но требует установки ПО на сервер базы и потребляет его ресурсы. - **Сетевой прокси (inline).** Весь трафик к СУБД идёт через DAM как через шлюз. Позволяет не только наблюдать, но и блокировать запрос «на лету», однако становится точкой в разрыве канала: добавляет задержку и требует отказоустойчивости. - **Зеркалирование трафика (SPAN/TAP, out-of-band).** Коммутатор зеркалирует копию трафика на DAM. Нулевое влияние на путь запроса и на производительность СУБД, но не видит локальных подключений и шифрованных сессий без расшифровки, и не умеет блокировать. - **Встроенный аудит СУБД (native audit / триггеры).** DAM забирает события из штатных механизмов аудита базы. Простое подключение без агентов, но нагружает саму СУБД и зависит от того, что администратор базы не отключил аудит.
Способы съёма активности: плюсы и минусы
| Способ съёма | Плюсы | Минусы |
|---|---|---|
| Локальный агент на сервере СУБД | Видит локальные и сетевые подключения, включая консоль DBA; полный перехват | Установка на сервер БД; потребление CPU/RAM; совместимость с версиями ОС/СУБД |
| Сетевой прокси (inline) | Может блокировать запрос в реальном времени; контроль до выполнения | В разрыве канала: задержка и риск точки отказа; нужна отказоустойчивость |
| Зеркалирование трафика (SPAN/TAP) | Нулевое влияние на СУБД и на путь запроса; легко масштабировать | Не видит локальных сессий; проблемы с TLS; блокировка невозможна |
| Встроенный аудит СУБД | Без агентов, быстрый старт; видит локальную активность | Нагрузка на саму СУБД; зависит от настроек; DBA может отключить |
Разбор SQL, политики и алертинг
Перехватить запрос — половина дела. Дальше DAM должен понять, что именно произошло, и решить, как реагировать. Поток обработки укрупнённо проходит несколько стадий: захват запроса, его нормализация и разбор, применение политик, генерация алерта и сохранение в неизменяемый журнал.
- **Разбор (parsing) SQL.** Запрос раскладывается на составляющие: тип операции (SELECT/INSERT/UPDATE/DELETE/DDL), затронутые объекты (таблицы, представления, столбцы), условия и предполагаемый объём выборки, учётная запись, источник подключения и приложение. Это превращает «строку SQL» в структурированное событие, к которому можно применить правила. - **Политики.** На разобранные события навешиваются правила: белые и чёрные списки объектов и операций, доступ к чувствительным таблицам, ограничения по ролям, времени и адресам, пороги на объём выгрузки, сигнатуры SQL-инъекций и поведенческие аномалии. - **Алертинг и реакция.** При срабатывании политики DAM фиксирует событие, поднимает алерт (в консоль, SIEM, по почте), а в inline-режиме может заблокировать или прервать сессию. Всё это пишется в защищённый от изменения журнал для комплаенса и расследований.
Важная развилка — мониторинг против блокировки. Большинство внедрений начинают в режиме наблюдения (out-of-band), накапливают базовую линию нормального поведения и только потом точечно включают блокировку на критичных политиках, чтобы не остановить легитимные бизнес-операции ложным срабатыванием.
DAM: зрелость функций по классу решений
Усреднённая редакционная оценка готовности класса DAM-решений по открытым данным. Это не вендорский бенчмарк и не заменяет пилот на вашей СУБД.
Влияние на производительность: чем платят за мониторинг
Влияние на производительность — главный практический вопрос при внедрении DAM, особенно для нагруженных OLTP-баз и систем дистанционного банковского обслуживания. Цена мониторинга напрямую зависит от выбранного способа съёма.
- **Зеркалирование (out-of-band)** практически не влияет на СУБД: копия трафика обрабатывается на стороне DAM, путь запроса не меняется. - **Локальный агент** потребляет CPU и память на сервере базы; грамотная реализация держит накладные расходы умеренными, но их обязательно нужно замерять под боевым профилем. - **Сетевой прокси (inline)** добавляет задержку в каждый запрос и становится узлом, чьё падение влияет на доступность БД, — поэтому требует кластеризации и отказоустойчивости. - **Встроенный аудит** перекладывает нагрузку на саму СУБД: расширенный аудит способен ощутимо просаживать производительность базы, и это нужно тестировать.
Вывод простой: универсального ответа нет, поэтому полноту перехвата и просадку производительности измеряют на пилоте под реальным трафиком, а не по паспортным цифрам.
Чек-лист внедрения DAM
Как внедрить DAM: 6 шагов
-
01
Инвентаризация и приоритизация
Определите критичные базы и таблицы с чувствительными данными — с них начинается покрытие.
-
02
Пилот способа съёма
Разверните DAM на копии трафика или тестовой БД, проверьте полноту перехвата и замерьте влияние на производительность.
-
03
Подключение источников
Заведите агенты, зеркала или аудит по выбранной схеме, закройте слепые зоны локального доступа.
-
04
Настройка политик в режиме наблюдения
Соберите базовую линию нормального поведения, отстройте ложные срабатывания.
-
05
Включение реакции
Точечно активируйте алерты и блокировку на критичных политиках, интегрируйте с SIEM и процессами реагирования.
-
06
Эксплуатация и аудит
Настройте отчётность под комплаенс, регулярно ревизуйте политики и расширяйте покрытие на остальные базы.
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики DAM сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом защиты баз данных и DAM](/rating/database-security-db-activity-monitoring): здесь — как устроена технология и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались, как устроен DAM, — переходите к сравнению поставщиков: **[рейтинг защиты баз данных и DAM →](/rating/database-security-db-activity-monitoring)**. Полезно прочитать рядом: [рейтинг российских DAM-систем](/research/reyting-dam-sistem-rossiya), [чем заменить Imperva и IBM Guardium](/research/zamena-imperva-guardium-dam) и [защита баз данных в банке](/research/zashchita-baz-dannyh-bank).
Частые вопросы
Чем DAM отличается от встроенного аудита самой СУБД?
Встроенный аудит работает внутри базы, нагружает её и управляется тем же администратором, действия которого как раз нужно контролировать, — его можно отключить или подчистить. DAM выносит сбор и анализ за пределы СУБД, ведёт независимый неизменяемый журнал и видит активность даже привилегированных пользователей. На практике их часто комбинируют.
Сильно ли DAM замедляет базу данных?
Зависит от способа съёма. Зеркалирование трафика практически не влияет на СУБД; локальный агент потребляет ресурсы сервера базы; inline-прокси добавляет задержку в каждый запрос; встроенный аудит нагружает саму базу. Конкретную просадку обязательно измеряют на пилоте под реальным профилем нагрузки.
Может ли DAM блокировать вредоносные запросы, а не только фиксировать их?
Да, но только в inline-режиме (сетевой прокси), когда трафик идёт через DAM. В режиме зеркалирования система видит и сигнализирует, но не вмешивается в путь запроса. Обычно блокировку включают точечно и после накопления базовой линии, чтобы не оборвать легитимные операции.
Видит ли DAM локальные подключения администратора, а не только сетевые?
Только при наличии локального агента на сервере СУБД или через встроенный аудит. Зеркалирование и сетевой прокси перехватывают лишь сетевой трафик и не покрывают консольный и локальный доступ DBA — это типичная слепая зона, которую закрывают агентом.
Что важнее при выборе DAM — функции или способ съёма?
Способ съёма первичен: он определяет полноту перехвата, слепые зоны и влияние на производительность. Богатый функционал политик бесполезен, если система не видит часть активности. Поэтому сначала проверяют покрытие и нагрузку на пилоте, а уже потом сравнивают аналитику и отчётность.
Где сравнить конкретных вендоров DAM между собой?
В рейтинге защиты баз данных и DAM — там компании ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
Database Activity Monitoring (DAM) — это класс систем, которые видят и записывают, кто, когда и какими SQL-запросами обращается к базам данных, разбирают эти запросы и применяют к ним политики: что разрешено, что подозрительно, а что нужно немедленно заблокировать или проэскалировать. По сути DAM отвечает на вопрос «что на самом деле происходит внутри СУБД» независимо от встроенного аудита самой базы и в обход прав администратора. **Если коротко:** ключевое отличие DAM-решений — не в красивых дашбордах, а в способе съёма активности (агент на сервере СУБД, сетевой прокси, зеркалирование трафика или встроенный аудит), потому что именно он определяет полноту перехвата, влияние на производительность и слепые зоны. Ниже разбираем, как DAM перехватывает и разбирает SQL, как работают политики и алертинг, чем платят за мониторинг в нагрузке, и даём чек-лист внедрения. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге защиты баз данных и DAM](/rating/database-security-db-activity-monitoring).