Встроенные механизмы защиты современных СУБД не гарантируют полной безопасности: утечки и мошенничество через легальный доступ продолжаются. Разбираемся, почему так происходит, как снизить риски и выстроить надёжную защиту баз данных.
Введение
Системы управления базами данных (СУБД) обладают широкой функциональностью для решения задач в составе ИТ-контура. Встроенные механизмы позволяют управлять доступом, фиксировать действия пользователей, что формирует базовый уровень защищённости и соответствует эксплуатационным задачам. Однако сами СУБД не предназначены для решения задач информационной безопасности (ИБ) и не рассматриваются как средства противодействия атакам и действиям инсайдеров.
Если проанализировать успешные угрозы для баз данных, становится очевидно, что большая их часть реализуется через компрометацию штатных возможностей СУБД и использование легитимных учётных записей. Внешние злоумышленники и привилегированные пользователи действуют в рамках разрешённых привилегий, что делает такие сценарии атак малозаметными для встроенных механизмов контроля.
В 2024 году Россия заняла второе место по числу компрометаций данных: на долю отечественных организаций пришлось 8,5 % таких инцидентов. Объём похищенных данных в 2025 году вырос до 687 ТБ при 406 утечках. СУБД в сложившихся условиях оказываются в зоне повышенного риска, поскольку они хранят и обрабатывают критичные данные и напрямую влияют на устойчивость бизнес-приложений: более 70 % компаний рискуют лишиться данных СУБД, при этом 74 % организаций относят базы данных к очень критичным с точки зрения ИБ активам.
Рисунок 1. Векторы атак на базы данных
Попытки реализовать защиту внутри самой СУБД, в том числе за счёт специализированных агентов или модулей, приводят к появлению узконаправленных решений, применимых только к конкретной платформе. В гетерогенной инфраструктуре, где одновременно используются несколько СУБД, такой подход неизбежно приводит к росту числа разрозненных средств защиты и усложняет их сопровождение и контроль.
При этом задача независимого контроля и аудита СУБД по-прежнему актуальна и требует применения специализированных средств защиты, к которым относится, например, «Гарда DBF». Рассматривать возможности решений класса DBF (Database Firewall, межсетевой экран для баз данных) изолированно недостаточно, поскольку в этом случае теряется понимание сценариев и границ их применения. Поэтому посмотрим на них через призму сравнения с функциями встроенных механизмов защиты СУБД.
Эффективность применения решений класса DBF на примере «Гарды DBF»
«Гарда DBF» — система класса DAM / DBF для защиты СУБД и независимого аудита операций с базами данных и бизнес-приложениями. Она функционирует вне самой СУБД и обеспечивает централизованный контроль безопасности, включая среды с различными СУБД разных производителей. Может применяться в инфраструктурах с иностранными, open source- и сертифицированными СУБД.
Аудит и инвентаризация баз данных
В корпоративных СУБД нередко складывается ситуация значительной фрагментации и разнородности: десятки и сотни экземпляров баз данных работают на разных серверах и операционных системах (ОС), используют различные версии, индивидуальные конфигурации. Эта разрозненность усиливается наличием:
- теневых копий баз данных;
- баз данных, которые вывели из эксплуатации, но не отключили;
- тестовых сред;
- отдельных резервных хранилищ;
- нерегламентированных подключений пользователей и администраторов;
- автономных скриптов и сервисов и др.
Такая ситуация создаёт дополнительные риски безопасности, поскольку:
- неучтённые и теневые копии баз данных могут содержать конфиденциальные данные и обрабатывать реальные бизнес-процессы;
- они не учтены в модели угроз и регламенте контроля ИТ- и ИБ-служб;
- наличие в них забытых учётных записей и открытых портов делает инфраструктуру компании уязвимой;
- создаёт риск утечки данных и нарушает требования регуляторов.
Чтобы устранить эти риски и обеспечить прозрачность операций, необходимо регулярно проводить инвентаризацию инфраструктуры. Если это делать встроенными средствами СУБД, то потребуется установка дополнительного программного обеспечения (ПО). Его работа будет ориентирована на конкретную СУБД, с поддержкой ограниченного набора ОС. При этом глубоко интегрированное в архитектуру СУБД ПО зачастую не отслеживает локальные подключения администраторов на уровне сетевого трафика, оставляя часть операций вне контроля и ограничивая полноту мониторинга всей инфраструктуры.
Установка специализированного ПО становится единственным способом сбора событий и мониторинга активности в рамках встроенного аудита СУБД. Однако остаётся нерешённым вопрос анализа ответов СУБД, что ограничивает полноту оценки и оставляет вне зоны контроля многие аспекты работы системы.
В отличие от описанного способа проведения аудита «Гарда DBF» централизованно собирает и консолидирует данные обо всех инстансах (экземплярах) баз данных в инфраструктуре компании, используя несколько механизмов их обнаружения, выявляет уязвимости в настройках СУБД, контролирует их конфигурации и классифицирует данные.
Перехват и анализ событий
Встроенные механизмы заточены, как правило, на работу с конкретной СУБД, соответственно ограничены перечнем событий, которые она генерирует.
При использовании агентской схемы перехват локальных подключений возможен, включая и администраторов. Однако если на одном хосте размещено несколько СУБД, встроенные средства защиты предполагают работу с событиями в разных интерфейсах. То есть нет единого окна контроля всех операций с данными.
В «Гарда DBF» реализовано централизованное управление событиями информационной безопасности через единый веб-интерфейс для СУБД различных типов. Ролевая модель обеспечивает необходимый доступ к различным политикам и данным аудита. При необходимости выгрузки сработок по политикам в стороннюю систему предусмотрена интеграция с SIEM, SOAR. Также есть возможность интеграции с дата-каталогами для обогащения информации в компаниях с датацентричным подходом.
Обычно штатные средства СУБД не позволяют проводить классификацию хранящихся в ней данных. Более того, использование средств машинного обучения для классификации неструктурированных данных внутри встроенных средств защиты крайне ограничено из-за возрастающей сложности итоговой системы. Таким образом, встроенные средства защиты с полной функциональностью аудита на борту будут приравниваться к стороннему ПО.
Приведём пример. Для полноценного расследования инцидента ИБ при утечке персональных данных (ПДн) нам, как правило, необходимо следующее:
- событие самого факта утечки (выгрузка ПДн);
- логин ОС либо IP-адрес злоумышленника;
- контекст происходящего.
Соответственно, перехват запроса на выгрузку ПДн может быть выполнен в рамках конкретной политики (реализуемой средствами штатной защиты либо стороннего ПО, например «Гарда DBF»). Далее необходимо понять, кто именно выполнил этот запрос. Если запрос выполнялся локально, тогда при использовании агентской схемы проблем с получением этой информации нет.
На практике злоумышленники редко используют локальные подключения. Скорее всего, запрос будет выполнен через скомпрометированную учётную запись (УЗ) через сервер приложений в рамках трёхзвенной архитектуры. В этом случае штатные средства защиты расценят такой запрос как легитимный.
Однако стороннее ПО с функциями поведенческой аналитики, помимо мониторинга запросов, способны выявлять аномалии в действиях скомпрометированного пользователя на основе контекста. А возможность идентификации пользователей в трёхзвенных архитектурах позволяет не только подсветить аномалию, но и идентифицировать конкретного злоумышленника или УЗ.
Поведенческий анализ (UEBA для баз данных)
Сложнее всего выявлять инциденты, совершаемые сотрудниками с легитимным доступом к конфиденциальным данным. В этом случае сложно отличить зловредные действия такого сотрудника от обычной работы. Штатными средствами СУБД это сделать невозможно, а системы класса DBF содержат UEBA-механизмы (User and Entity Behavior Analytics, аналитика поведения пользователей и сущностей) для выявления отклонений от типового поведения и аномальных запросов.
В «Гарда DBF» реализованы технологии поведенческого анализа, которые профилируют работу с данными пользователей СУБД:
- изучают характер и параметры обращений пользователей к СУБД (профилирование);
- осуществляют поведенческий анализ и по выявленным отклонениям детектируют аномальное поведение. При установке системы в режиме блокировки она может блокировать доступ к базе данных в реальном времени.
Профилирование в «Гарда DBF» — это постоянный процесс: профили поведения учётных записей баз данных регулярно пополняются новыми параметрами с учётом изменений в работе учётных записей и бизнес-процессах. Кроме того, профили можно пополнять вручную.
В качестве примера рассмотрим ситуацию, когда пользователь с легальными правами (аналитик) выгружает данные из базы по частям: скриптами, из OLAP-запросов (Online Analytical Processing, онлайн-аналитическая обработка данных). Для штатных средств контроля это выглядит как обычная SQL-выгрузка по расписанию и с фильтрами по столбцам, а «Гарда DBF» смотрит на это по-другому. Она видит SQL-выборки с избыточным объёмом, нетипичные фильтры и выгрузки, а также необычную частоту обращения к данным. Смотря на эти действия в комплексе, «Гарда DBF» может заблокировать операцию или оповестить об аномальном поведении.
Более сложный случай — когда подобная активность выполняется от имени технической учётной записи, используемой в трёхзвенных архитектурах. При такой архитектуре работа пользователей осуществляется через сервер приложений, который уже, в свою очередь, подключается к базе данных под технической учётной записью. Таким образом, все запросы в БД от пользователей в логах выглядят как запросы от одной учётной записи. Здесь возможны следующие векторы атак:
- Использование технической учётной записи администратором БД или пользователем с соответствующим доступом для совершения нелегитимных запросов.
- Компрометация технической учётной записи (ТУЗ) при взломе сервера приложений (через SQL-инъекции или эксплуатацию уязвимостей веб-приложения) с последующим использованием злоумышленником .
Такие инциденты сложно отследить на уровне сырых логов СУБД, так как события, свидетельствующие о подобном атипичном поведении ТУЗ, теряются в тысячах строк лога. Наиболее эффективным средством обнаружения такой активности является профилирование технических учётных записей и настройка политик выявления отклонений от профиля, к примеру, с помощью «Гарда DBF».
Если «Гарда DBF» зафиксирует, например, попытку обращения ТУЗ к неиспользуемым ею ранее таблицам (первое, что делает злоумышленник — запрашивает перечень учётных записей в БД), то сразу отметит это как нетипичное поведение и проинформирует офицера безопасности. Для контроля ТУЗ также применим сценарий с растянутой во времени выгрузкой критичной информации.
Возможен и другой сценарий: администратор БД, планируя использовать ТУЗ для «слива» данных, предварительно подготавливает систему. Он назначает необходимые права, изменяет настройки безопасности и уровни логирования, включает небезопасные методы аутентификации, а затем удаляет записи о выполненных действиях. Своевременная настройка политик на выявление подобных действий позволит обнаружить инцидент до того, как будет осуществлена кража данных.
Аналитические возможности
Встроенные механизмы баз данных не предоставляют полноценного инструментария для формирования отчётности. Дашборды и возможности ретроспективного поиска информации отсутствуют. Создание отчётов требует ручной работы и, зачастую, участия администратора баз данных.
«Гарда DBF» собирает события из всех СУБД, формирует дашборды и отчёты, которые можно передавать в SOC-центр в режиме реального времени. Система не только фиксирует подозрительные операции, но и сохраняет всю информацию для последующего разбора.
В системе предустановлен широкий набор готовых отчётов, при этом пользователь может настроить собственные и создавать дашборды для оперативного мониторинга под свои потребности. Доступен экспорт отчётов в формате CSV, PDF, а также их отправка на email.
Выводы
Проведённый анализ показывает, что встроенные механизмы защиты СУБД не выходят за рамки базового уровня обеспечения безопасности и администрирования. Попытки расширить эти возможности за счёт собственных инструментов аудита и защиты приводят к необходимости создания отдельного внешнего сервиса.
Такой подход фактически выводит контроль за пределы ядра СУБД и требует дополнительных вычислительных ресурсов. Для заказчика это означает отдельные затраты и усложнение архитектуры. Подобные решения жёстко привязаны к конкретной СУБД и не масштабируются на другие платформы, используемые в организации. В результате возникает выбор между точечным усилением защиты одной системы и внедрением специализированного решения, охватывающего весь парк баз данных.
На этом фоне наложенные средства защиты, такие как «Гарда DBF», выглядят более зрело и целесообразно с точки зрения обеспечения безопасности различных СУБД и веб-приложений из единого интерфейса, что особенно важно для инфраструктур с разнородным парком. Сквозные политики безопасности применяются ко всем системам, включая контроль доступа, парольные требования и маскирование данных. Это снижает риски, связанные с разрозненной настройкой.
Для обнаружения поведенческих аномалий в «Гарда DBF» реализованы встроенные механизмы UEBA. Независимый аудит, включая контроль сессий и анализ действий в реальном времени, обеспечивает дополнительный уровень доверия по сравнению со штатными средствами контроля.
Реклама, 18+. ООО «Гарда Технологии». ИНН 5260443081
ERID: 2VfnxwZU79c
