SecRadar / Защита баз данных / Как выбрать

DBF/DAM · Гайд по выбору

Как выбрать защиту баз данных (DBF/DAM): критерии выбора

Проверено экспертной редакцией SecRadar · по первоисточникам ФСТЭК / ФСБ / Банка России

Выбор системы защиты баз данных — это не выбор между известными названиями, а сведение конкретных условий (какие СУБД защищаем, нужна блокировка или аудит, кто и как получает доступ) с тем, что продукт умеет делать без доработок. Ниже — критерии, а не список вендоров: сравнение конкретных российских DBF/DAM-решений смотрите на странице класса и на радаре DBF.

Экспертная редакция SecRadar · как мы проверяем факты → Обновлено 10 июля 2026 · ~9 мин чтения ✓ критерии сверены с требованиями ФСТЭК и практикой внедрения систем защиты баз данных в РФ

Кратко

Главный критерий: Соответствие профилю риска и топологии — блокировка в реальном времени нужна не всем, части сценариев хватает пассивного аудита.
Проверить в первую очередь: Точный список поддерживаемых СУБД и версий — PostgreSQL, Oracle, MS SQL, платформа 1С.
Для ИСПДн и КИИ: Требование сертификата ФСТЭК зависит от статуса системы, форму оценки соответствия для значимых объектов КИИ определяет приказ №239.
Производительность: Тестировать задержку и нагрузку на своём профиле трафика, а не на демо-стенде вендора.
DBF/DAM не заменяет: DLP (контроль исходящих каналов) и шифрование данных СКЗИ — это разные классы защиты.
Где сравнить вендоров: Каталог DBF и радар DBF на SecRadar.

Как выбрать защиту баз данных за 5 шагов

Короткий ответ: начните с того, какие СУБД вы защищаете — PostgreSQL, Oracle, MS SQL или встроенная платформа 1С — и сверьте точный список поддерживаемых версий у каждого кандидата: общая формулировка «поддерживает основные СУБД» на практике часто не покрывает вашу редакцию или отраслевую сборку. Дальше определите режим работы — нужна ли блокировка подозрительных запросов в реальном времени (DBF) или достаточно пассивного аудита действий администраторов и приложений (DAM).

Проверьте, как система перехватывает трафик — агентом на сервере БД или без него, через зеркалирование сетевого трафика, — и как это скажется на нагрузке и доступности базы. Оцените маскирование данных для тестовых сред, детект аномального доступа, блокировку SQL-инъекций и интеграцию с SIEM. И только в конце сравнивайте лицензирование и сертификат ФСТЭК, если он обязателен для вашего статуса — ИСПДн или значимый объект КИИ.

1. СУБД

Точный список версий — PostgreSQL/Oracle/MS SQL/1С, а не общая формулировка вендора

2. Режим

Inline-блокировка или пассивный аудит — защита в реальном времени против фиксации постфактум

3. Перехват

С агентом на сервере БД или без него — полнота видимости против нагрузки на сервер

4. Детект

Аномалии доступа и SQL-инъекции — не только сбор и хранение логов

5. TCO и ФСТЭК

Лицензия + внедрение + сертификат, если требуется, на весь срок эксплуатации

Что такое DBF и DAM и чем они отличаются

DBF (Database Firewall) и DAM (Database Activity Monitoring) — два подхода к одной задаче: защите баз данных от несанкционированного доступа и аномальной активности на уровне протокола самой СУБД, а не на уровне сети или конечной точки. На рынке эти термины часто используют как синонимы одного класса, потому что большинство современных продуктов совмещают оба режима в одной системе.

DBF активный, inline

Работает как прокси между приложением и СУБД: разбирает каждый SQL-запрос на лету и может заблокировать его до выполнения — например, остановить массовую выгрузку таблицы с данными клиентов или отсечь запрос с признаками SQL-инъекции. Это защита в реальном времени, похожая по логике на WAF, но на уровне протокола базы данных, а не HTTP.

DAM пассивный, постфактум

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

Граница между ними на практике размыта: зрелые продукты сочетают inline-блокировку для узкого набора критичных правил (массовая выгрузка, DDL-команды вроде DROP или TRUNCATE, сигнатуры инъекций) с пассивным аудитом для всего остального трафика — так проще не задеть доступность приложения ложным срабатыванием. При выборе стоит проверять не название продукта, а какой режим доступен для каждого правила и что происходит с запросом при отказе системы: fail-open пропускает трафик без проверки, fail-closed блокирует всё, включая легитимные запросы.

Зачем отдельная защита БД, если есть DLP и сетевой МЭ

DLP контролирует каналы, которыми данные покидают периметр организации, — почту, веб, USB, печать. Он не разбирает трафик внутри дата-центра: когда администратор или скомпрометированная учётная запись выполняет прямой SQL-запрос к базе, для DLP это обычное сетевое соединение, а не факт утечки. Сетевой межсетевой экран работает на уровне IP-адреса и порта — он пропустит любой корректно оформленный пакет к порту СУБД, не разбирая содержимое SQL-запроса, и тем более не отличит легитимный запрос от инъекции, замаскированной под обычный трафик.

Отдельная проблема — привилегированные пользователи: администраторы БД, разработчики и подрядчики с легитимным доступом к самой базе. Администрирование и защита баз данных на уровне СУБД — права, патчи, резервное копирование — задача DBA. Но контроль того, что происходит внутри этих прав — не выгружает ли администратор данные пачками ночью, не читает ли подрядчик лишние таблицы, — видит только DBF/DAM, а не периметровые средства защиты.

Отдельно от DBF/DAM стоит криптографическая защита БД — шифрование на уровне столбцов, таблиц или всего диска (TDE), которое закрывает данные при физическом хищении носителя или резервной копии. Это задача класса СКЗИ (см. СКЗИ на SecRadar): шифрование не отличает легитимный запрос авторизованного пользователя от аномального — расшифрованные данные видны любому, кто прошёл штатную аутентификацию в СУБД. DBF/DAM и шифрование решают разные задачи и обычно используются вместе.

Ключевые критерии выбора защиты баз данных

Ниже — критерии, которые стоит проверять у любого кандидата, вне зависимости от того, как вендор называет свой продукт — DBF, DAM или просто системой защиты баз данных.

Поддержка СУБД: PostgreSQL, Oracle, MS SQL, 1С проверять версии

Каждая СУБД — свой протокол и диалект SQL. Продукт может формально «поддерживать PostgreSQL» и не работать с нужной мажорной версией или отечественным форком. Отдельная сложность — платформа 1С: поверх MS SQL, PostgreSQL или файлового хранилища у неё собственный слой запросов, и универсальные решения не всегда видят его корректно. Просите у вендора точный список поддерживаемых версий и редакций.

Режим inline/proxy или пассивный аудит критично для прод-систем

Inline-режим блокирует запрос до его выполнения, но добавляет системе защиты роль точки в цепочке «приложение → СУБД»: при сбое компонента запрос либо пройдёт без проверки (fail-open), либо остановится вместе со всем трафиком к базе (fail-closed). Пассивный аудит не блокирует ничего, зато не уронит прод при отказе. Для критичных систем важно знать поведение конкретного продукта при отказе.

Перехват без агента на СУБД или с агентом видимость vs нагрузка

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

Маскирование и обезличивание данных для тестовых сред и ПДн

Динамическая маскировка подменяет значения в результате запроса на лету: разработчик в тестовой среде видит вместо реальных ФИО и номеров карт клиентов маскированные значения, а структура данных для приложения сохраняется. Это не то же самое, что статическая выгрузка обезличенной копии базы, но обе техники снижают риск утечки персональных данных при разработке.

Обнаружение аномалий доступа поведенческая аналитика

Система строит профиль обычного поведения учётной записи — объём и время выгрузок, типовые таблицы, источник подключения — и сигнализирует при отклонении: ночная массовая выгрузка с учётки, которая обычно делает единичные запросы днём, или резкий рост числа запросов без нагрузки в приложении. Это способ поймать скомпрометированную или инсайдерскую учётку, действующую легитимными правами.

Блокировка SQL-инъекций если приложение обращается к БД напрямую

Сигнатурный и эвристический анализ SQL-запроса на признаки инъекции — UNION-based, blind, time-based — актуален там, где приложение формирует запросы к БД динамически или использует уязвимый ORM. Если доступ к базе идёт через строго параметризованные запросы бэкенда, риск ниже, но защита от инъекций на уровне DBF работает как дополнительный слой, а не замена безопасной разработки.

Интеграция с SIEM не остров

Без передачи событий во внешний SIEM DBF/DAM превращается в отдельную систему, за которой на практике часто не следит никто, кроме периода после инцидента. Проверяйте не факт наличия интеграции, а что именно передаётся: только алерты о срабатывании правил или весь поток запросов для корреляции.

Влияние на производительность СУБД тестировать на реальной нагрузке

Inline-режим добавляет задержку на каждый запрос, агентный сбор аудита — накладные расходы на CPU и I/O сервера БД. Для высоконагруженных транзакционных систем — процессинга, ДБО, биллинга — разница в десятки миллисекунд на запрос при большом потоке транзакций складывается в заметное замедление сервиса. Требуйте нагрузочный тест на своём профиле трафика, а не верьте цифрам с демо-стенда вендора.

Сертификат ФСТЭК для ИСПДн и КИИ как и для других СЗИ

Требование к сертифицированному средству защиты зависит от статуса системы — уровня защищённости информационной системы персональных данных, категории значимости объекта КИИ или класса защищённости ГИС, а не действует автоматически для любой базы данных. Для значимых объектов КИИ форму оценки соответствия — сертификацию, испытания или приёмку — определяет приказ ФСТЭК №239, п.

28. У класса DBF/DAM нет отдельного кода в Реестре российского ПО: продукты регистрируются под кодом 03.09 или 03.03 в зависимости от заявленной вендором основной функции — это стоит учитывать при сверке записи в реестре конкретного продукта.

Модель лицензирования и TCO три года, не один

Лицензируют такие системы обычно по числу защищаемых инстансов СУБД, по количеству процессорных ядер сервера базы данных или по объёму обрабатываемых данных — модели по-разному ведут себя при росте инфраструктуры. В TCO стоит закладывать не только лицензию, но и внедрение, обучение DBA и аналитиков ИБ, продление сертификата ФСТЭК, если он требуется.

реестр у класса DBF/DAM нет отдельного кода в Реестре российского ПО — продукты числятся под кодами 03.09 или 03.03 (сверено по classes.json/reestr.digital.gov.ru) оценка связка «статус системы → нужен ли сертификат» упрощена; для конкретного проекта сверяйте с моделью угроз и приказом ФСТЭК №239

Частые ошибки при выборе защиты баз данных

Верить общей формулировке «поддерживает все основные СУБД» без проверки версии. 1С и отечественные форки СУБД чаще всего выпадают из типового списка коннекторов.
Включать inline-блокировку сразу в продакшене без периода мониторинга. Ложные срабатывания на легитимных бизнес-запросах останавливают транзакции, а не только атаки.
Не тестировать производительность под реальной пиковой нагрузкой. Демо-стенд вендора почти никогда не воспроизводит боевой профиль трафика транзакционной системы.
Путать DBF/DAM с шифрованием данных. Рассчитывать, что криптографическая защита БД (СКЗИ) закроет задачу контроля доступа, хотя это разные классы защиты с разными задачами.
Не закладывать интеграцию с SIEM в архитектуру заранее. Подключать её постфактум сложнее и дороже, чем на этапе внедрения.
Не сверять требование сертификата ФСТЭК для конкретного статуса системы на старте проекта. При значимом объекте КИИ или высоком уровне защищённости ИСПДн отсутствие сертификата у выбранного продукта означает повторный тендер.

Чек-лист выбора защиты баз данных

Составьте список СУБД и точных версий, которые нужно защитить, — включая платформу 1С и нетиповые сборки.
Определите, нужна ли блокировка запросов в реальном времени (DBF) или достаточно пассивного аудита (DAM) для вашего профиля риска.
Уточните способ перехвата трафика — с агентом на сервере БД или без него — и оцените нагрузку на сервер в каждом варианте.
Проверьте поведение системы при отказе — fail-open или fail-closed — для критичных транзакционных сервисов.
Оцените наличие динамического маскирования данных для тестовых и отладочных сред.
Проверьте, строит ли система поведенческий профиль учётных записей и как настраивается порог аномалии.
Уточните покрытие сигнатур SQL-инъекций и частоту обновления базы правил.
Проверьте готовую интеграцию с вашим SIEM и что именно передаётся — алерты или полный поток запросов.
Запросите нагрузочный тест на своём профиле трафика, а не на демо-данных вендора.
Определите, обязателен ли сертификат ФСТЭК для вашего статуса — ИСПДн, ГИС или значимый объект КИИ — и сверьте срок его действия в госреестре СЗИ ФСТЭК.
Посчитайте TCO на 3 года: лицензия по инстансам или ядрам, внедрение, обучение DBA и аналитиков, продление сертификата.
Запросите пилот на копии реальной боевой базы, а не на синтетическом наборе данных.

Где сравнить российские решения для защиты баз данных

Критерии выше сужают список кандидатов, финальный выбор — сравнение конкретных продуктов по вендору, реестру, поддерживаемым СУБД и сертификату ФСТЭК. На SecRadar для этого два инструмента: каталог — таблица характеристик, радар — визуальная карта по возможностям и комплаенсу.

Каталог

Защита баз данных — таблица сравнения

Вендор, реестр, статус сертификата ФСТЭК, поддерживаемые СУБД и режим работы — на проверяемых данных. Открыть каталог DBF →

Радар

DBF/DAM — визуальная карта рынка

Позиции вендоров по возможностям, присутствию и комплаенсу на одной карте. Открыть радар DBF →

Смежные классы, которые часто рассматривают вместе с защитой баз данных: DLP — контроль каналов, которыми данные покидают периметр, а не того, что происходит внутри самой базы; DCAP/DAG — аудит прав доступа к файлам и неструктурированным хранилищам, смежная, но отдельная задача от структурированных данных в СУБД. Для организаций, где в базе хранятся персональные данные, требования разобраны в разделе «Персональные данные» на SecRadar.

Частые вопросы

Чем отличаются DBF и DAM?

DBF (Database Firewall) работает как прокси между приложением и СУБД и может блокировать подозрительный SQL-запрос до его выполнения — это защита в реальном времени. DAM (Database Activity Monitoring) перехватывает копию трафика и фиксирует действия постфактум, не блокируя запрос в момент выполнения, — это в первую очередь инструмент аудита и расследования. На практике большинство продуктов совмещают оба режима: inline-блокировку для узкого набора критичных правил и пассивный мониторинг для остального трафика. Метка: оценка — рыночное разграничение, конкретная реализация зависит от продукта.

Нужна ли отдельная защита БД, если уже есть DLP и межсетевой экран?

Да, если в базе есть чувствительные или критичные данные. DLP контролирует каналы, которыми данные покидают периметр организации, а не запросы внутри дата-центра — легитимный SQL-запрос администратора или скомпрометированной учётной записи для DLP выглядит как обычный трафик. Сетевой межсетевой экран работает на уровне IP и порта и не разбирает содержимое SQL-запроса. DBF/DAM закрывает именно это — уровень протокола СУБД и привилегированный доступ, который не видят периметровые средства защиты. Метка: оценка — экспертное сопоставление классов.

Нужен ли сертификат ФСТЭК для защиты баз данных?

Зависит от статуса системы, а не действует автоматически для любой базы данных: требование определяется уровнем защищённости ИСПДн, классом ГИС или категорией значимости объекта КИИ. Для значимых объектов КИИ форму оценки соответствия — сертификацию, испытания или приёмку — определяет приказ ФСТЭК №239, п. 28. Отдельного кода класса DBF/DAM в Реестре российского ПО нет: продукты регистрируются под кодом 03.09 или 03.03 в зависимости от заявленной основной функции — это стоит проверять по конкретной записи продукта в Реестре российского ПО и статусу сертификата в госреестре СЗИ ФСТЭК. Метка: реестр — по данным classes.json и reestr.digital.gov.ru на дату проверки.

DBF/DAM или DCAP — что выбрать?

Это разные объекты защиты, а не конкурирующие классы. DBF/DAM контролирует запросы и доступ к структурированным данным внутри СУБД — таблицам, строкам, конкретным запросам. DCAP (Data-Centric Audit and Protection) наводит порядок в правах доступа к файлам и неструктурированным хранилищам — файловым шарам, документам. Организации с базами данных и файловыми хранилищами обычно используют оба класса — они закрывают разные типы данных, а не один и тот же периметр. Подробнее — на странице DCAP. Метка: оценка — экспертное сопоставление классов.

Замедляет ли DBF работу СУБД?

Может — inline-режим добавляет задержку на каждый запрос, а агентный сбор аудита создаёт дополнительную нагрузку на CPU и I/O сервера базы данных. Величина замедления зависит от продукта, режима работы и профиля нагрузки — единой цифры нет. Для транзакционных систем с высокой нагрузкой (процессинг, ДБО) стоит требовать у вендора нагрузочный тест на собственном профиле трафика, а не полагаться на цифры с демо-стенда. Метка: оценка — практический ориентир, а не нормативная величина.

Сравнить российские решения для защиты баз данных

Каталог и радар SecRadar — вендор, реестр, статус сертификата ФСТЭК и поддерживаемые СУБД на проверяемых данных, без пользовательских отзывов.

Каталог DBF → Радар DBF →