Привет, Хабр!

Сегодня с вами Дмитрий Ларин, руководитель продуктового направления по защите баз данных и Александр Хребтов, аналитик группы компаний «Гарда», и мы поговорим о способах защиты баз данных. После 2022 года многие российские компании оказались в ситуации, когда привычные инструменты управления базами данных стали недоступны. Миграция на отечественные СУБД обострила вопрос: как защитить критические данные в условиях, когда стандартные средства больше не работают?

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

Проблематика

Современные ИТ-системы обрабатывают критические данные — от персональных и финансовых сведений до информации о технологических процессах. Реляционные СУБД (системы управления базами данных) остаются основным механизмом хранения и обработки этих данных, и потому они представляют собой первоочередную цель как внешних атакующих, так и внутренних нарушителей.

Традиционные средства защиты (межсетевые экраны, IDS/IPS, антивирусы) работают на сетевом или файловом уровнях и не видят специфики SQL-протоколов и действий в СУБД. Кроме того, встроенные механизмы журналирования в СУБД могут быть отключены или модифицированы самими администраторами. Это создает необходимость в специализированных средствах защиты на уровне логики работы БД — Database Firewall (DBF).

Переход на отечественные СУБД

Прекращение поставок и поддержки западных СУБД (Oracle, MS SQL, SAP HANA и других), которое началось в 2022 году и продолжается до сих пор, имеет следующие последствия:

• отсутствие обновлений безопасности;

• невозможность легального сопровождения;

• отсутствие соответствия законодательству и требованиям российских регуляторов (ФЗ-152, ФЗ-187, требования по импортозамещению, требования ФСТЭК России и др.).

По Постановлению №1236, госсектор и значительная часть коммерческих компаний обязаны переходить на ПО из реестра отечественного ПО. Для СУБД это означает переход на решения вроде PostgreSQL, «ЛиберБД», «Релест» и других.

Однако миграция на отечественные СУБД сопровождается:

• несовместимостью с используемыми SQL-диалектами и хранимыми процедурами;

• отсутствием зрелых механизмов репликации, кластеризации, резервного копирования;

• необходимостью адаптации или разработки веб-приложений;

• необходимостью переобучения персонала;

• ограниченной экосистемой мониторинга и администрирования.

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

Почему сертификация СУБД не спасает от инсайдеров?

Сертификация СУБД не означает их безопасность по факту. Наличие сертификата не гарантирует безопасность работы с данными (которые загружаются, изменяются и выгружаются из БД) и никак не гарантирует безопасность бизнес-процессов компании:

• сертификация не покрывает весь стек ИБ, особенно в разрезе злоупотреблений со стороны легитимных пользователей;

• большинство СУБД не отслеживают теневые выгрузки данных, работу через технологические учетные записи, а также действия superuser'ов – пользователей с повышенными правами доступа;

• стандартные механизмы логирования легко отключаются или подменяются теми же администраторами.

DBF внедряется в инфраструктуру как независимый перехватчик трафика и регистрирует каждый SQL-запрос, включая обращения из бизнес-приложений и сторонних API, обеспечивая:

• контроль привилегированных пользователей;

• поведенческий анализ и профилирование активностей;

• контекстную фильтрацию запросов и данных;

• независимое журналирование и аудит инцидентов;

• реакцию на события в режиме real-time.

Виды атак на базы данных и техники противодействия

Рассмотрим практические кейсы атак на базы данных и типовые сценарии компрометации и злоупотреблений при работе с БД на примере использования решения «Гарда DBF».

Для удобства мы добавили привязку к классификатору УБИ (угрозы безопасности информации)  – кодам, присвоенным определенным видам угроз в официальном классификаторе, который разрабатывает и ведет ФСТЭК России. Каждый код (например, УБИ.057 или УБИ.067) соответствует конкретному сценарию угрозы или типу уязвимости, описанному в нормативных и методических документах. Проще говоря, набор кодов указывает, что угроза в каждом кейсе совпадает или пересекается по характеристикам с этими кодами угроз в классификаторе. Это помогает специалистам по информационной безопасности быстро ориентироваться в типовых сценариях атак и соблюдении требований регуляторов.

Несанкционированная выгрузка данных через легитимные запросы

Сценарий: пользователь с легальными правами (аналитик, администратор БД) выгружает данные по частям — скриптами, из OLAP‑запросов, через BI‑инструменты.

Проблема: SQL‑выгрузка по расписанию с фильтрацией по ключевым столбцам, недоступная для отслеживания через стандартные DLP или SIEM‑системы.

Противодействие: DBF отслеживает SQL‑выборки с избыточным объемом, нетипичные фильтры и выгрузки, частоту обращения к данным и аномальное поведение пользователей. Также блокирует обращения к чувствительным данным вне согласованных сценариев.

УБИ: 057, 067, 088, 097, 127, 128.

Компрометация журналов безопасности СУБД

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

Проблема: встроенные аудиторские функции уязвимы для модификаций изнутри.

Противодействие: DBF ведет независимое журналирование событий и контролирует любые учетные записи, включая «суперпользователей», а также блокирует попытки повышения привилегий и изменения настроек безопасности.

УБИ: 023, 028, 057, 060, 067, 088, 091, 097, 122, 124, 127, 128, 179, 185, 192

Создание теневых копий баз данных

Сценарий: создание резервной копии вне регламентов, экспорт дампа схемы или таблиц на внешние носители.

Проблема: утечка данных через mysqldump, expdp, pg_dump без оповещения ИБ-отдела.

Противодействие: DBF выявляет новые БД, появившиеся в сети компании, резкие скачки объема переданных данных, а также специфические системные команды, характерные для копирования. Таким образом продукт мониторит создание копий, применяет политики безопасности и оперативно уведомляет об их появлении.

Злоупотребление правами доступа

Сценарий: сотрудник с максимальными правами (суперпользователь, администратор СУБД) имеет root-доступ. Он отключает аудит, меняет права другим пользователям и подчищает за собой следы. Такие пользователи также могут менять настройки безопасности и обходить встроенные механизмы защиты в СУБД.

Проблема: невозможно отследить действия в режиме «от имени сервиса».

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

Отказ от действий: архитектура «все от имени сервиса»

Сценарий: в трехуровневой архитектуре (frontend–middleware–DB) все SQL-запросы идут от технологических учетных записей.

Проблема: невозможно определить конечного инициатора действия без межуровневого анализа.

Противодействие: DBF может определять конкретного пользователя (в случае наличия в SQL-запросе таких данных) и связать с логином ОС или логином БД.

Подмена данных

Сценарий: сотрудники изменяют данные в СУБД для собственной выгоды, нанося ущерб компании или влияя на принятие управленческих решений. Например, поднимают свои KPI, подменяют сведения о ключевых показателях проекта, о состоянии и (или) параметрах технологического объекта.

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

Противодействие: Поиск «аномальной модификации» — когда один пользователь меняет записи, не связанные с его рабочими правами. DBF определяет это через контекстный анализ: что, кем, когда и как было изменено, и с какой целью, выявляет подозрительные запросы и блокирует попытки несанкционированного доступа и утечки информации

УБИ: 023, 028, 057, 060, 067, 088, 091, 097, 122, 124, 127, 128, 147, 179, 185, 192, 215.

Задержка реакции на инцидент

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

Проблема: в механизмы защиты СУБД нотификация о событиях безопасности либо не встроена, либо не имеет соответствующих инструментов, и такое скачивание не распознается как событие ИБ (это касается и сертифицированных ФСТЭК России систем на соответствие «Требованиям по безопасности информации к системам управления базами данных»). При отсутствии SIEM мониторинг событий безопасности приходится делать вручную. А в SIEM часто попадают неструктурированные или избыточные данные.

Противодействие: DBF имеет встроенные механизмы автоматических уведомлений о событиях, систему анализа инцидентов и поведенческий анализ. В системе можно тонко настроить реакции: блокировку, алерты, записи в журнал, корреляцию с другими событиями.

Выгрузка баз данных через уязвимости (zero-day или известные проблемы в сертифицированных СУБД)

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

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

Противодействие: DBF обнаружит эксфильтрацию за счет анализа объема и частоты SQL-запросов (например, если ранее пользователь выполнял 10 SELECT-запросов в час, а теперь — сотни в минуту), корреляции с типами возвращаемых данных (адреса, телефоны, паспортные данные, email, финансовые реквизиты), детектирования обходных паттернов (например, использование временных таблиц, слияние данных, сериализация в base64), сравнения действий с поведенческим профилем (если DBA обращается к данным, с которыми ранее не работал), а также за счет идентификации фрагментированных выгрузок ‒ например, через LIMIT + OFFSET или постраничные выборки, охватывающие весь массив.

Вывод

С переходом на отечественные СУБД задача защиты баз данных усложняется – как из-за технологических особенностей новых решений, так и из-за необходимости контролировать гибридную ИТ-инфраструктуру. Специализированные решения класса Database Firewall/DAM обеспечивают необходимый уровень изоляции, мониторинга и реагирования, в том числе при недоверенной среде администрирования.

Такие решения закрывают пробелы встроенных механизмов, обеспечивают выполнение требований законодательства и создают дополнительный уровень контроля, необходимый для эксплуатации критически важных ИС, в том числе в сложнейший переходный период.

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

Еще больше практических вопросов защиты данных приглашаем обсудить на конференции «Сохранить всё: безопасность информации», которая пройдет совсем скоро — 16 октября в Москве, в конгресс-центре Soluxe.