С тихой эксфильтрацией данных из баз есть одна неприятная особенность: в большинстве реальных случаев она вообще не выглядит как эксфильтрация. Нет ни дампов, ни пиков трафика, ни экзотических SQL-конструкций. Есть обычные SELECT, знакомые учетные записи и зашифрованный трафик, который снаружи ничем не отличается от легитимного. Именно поэтому такие инциденты часто проходят мимо средств защиты.
Автор: Дмитрий Ларин, руководитель продуктового направления по защите баз данных компании "Гарда"
Откуда берется тихая утечка?
Один из самых распространенных сценариев – компрометация приложения. Веб-приложение взламывают, но дальше злоумышленник не идет напрямую в базу под левым пользователем. Он использует тот же самый пул соединений, который приложение использует годами. Для базы данных это абсолютно легитимный доступ: знакомая учетка, знакомый источник, корректные запросы. Нет никакого вторжения в привычном смысле. Меняется только цель этих запросов, но сама БД этого не знает.
Второй частый вариант – компрометация учетной записи разработчика, администратора или сервисного пользователя. Дальше начинается аккуратная работа с данными – без спешки, без массовых выгрузок, с оглядкой на привычное поведение.
Есть, конечно, сценарии, где участвует внутренний пользователь, но и здесь все не так прямолинейно. Речь не о человеке, который за вечер скачивает дамп и уходит с флешкой. Чаще это постепенная выгрузка – месяцами, небольшими объемами, в неудобное для детекта время. Иногда это делается осознанно, иногда – под видом служебной необходимости или автоматизации.
Наконец, отдельная категория – технические и полуавтоматические сценарии. Скрипты, интеграции, копии для аналитики, временные выгрузки, которые перестали быть временными. Они могут работать годами, постепенно расширяя объем данных, которые оказываются за пределами исходного контура. Формально здесь вообще нет нарушителя – есть плохо контролируемый процесс, который со временем начинает напоминать утечку по всем последствиям.
Одиночные СЗИ не справляются
Проблема тихой эксфильтрации становится особенно заметной, когда смотришь на нее через призму отдельных классов средств защиты. Каждый из них по-своему прав, но видит только часть картины – и именно на этом разрыве атака и держится.
Сетевые средства, включая NDR, хорошо чувствуют инфраструктуру. Они видят маршруты, источники, направления трафика, умеют замечать сканирование, вторжения, нетипичные соединения. Но когда речь заходит о работе приложений с базами данных, этот инструментарий быстро упирается в свой потолок. Трафик зашифрован, узлы легитимны, объемы не выбиваются из привычных коридоров. Даже если данные в итоге уходят наружу, начало этой истории почти всегда происходит внутри доверенного контура, где для сети все выглядит штатно.
Средства защиты баз данных, наоборот, прекрасно понимают, что происходит внутри СУБД. Они видят SQL-операции, знают, какие таблицы читают, кто и с какими правами это делает. Но они не отвечают на ключевой вопрос: что происходит с данными после того, как они покинули базу. Для DBF выгрузка закончилась в момент выполнения запроса.
SIEM в этой схеме часто оказывается не спасением, а даже усилителем проблемы. Отдельные факты – доступ к чувствительной таблице, нетипичный сетевой поток, активность с конкретного IP – по отдельности не выглядят инцидентом. А без заранее выстроенной логики корреляции они и не складываются в историю.
В результате каждый инструмент делает ровно то, для чего он был создан, но эксфильтрация происходит между ними.
Связка технологий NDR и DBF
Идея связать сетевую аналитику и контроль операций в базах данных на первый взгляд кажется неочевидной, но именно она дает возможность увидеть тихую эксфильтрацию.
Самый простой сценарий начинается со стороны сети. NDR фиксирует подозрительную активность в виде списка IP-адресов: источник, который ведет себя нетипично, хост с признаками компрометации, соединения, не укладывающиеся в профиль нормального поведения (baseline). Сам по себе этот сигнал еще не говорит об утечке данных. Но информация о таких источниках передается в систему DBF, и контекст резко меняется. SQL-запросы, которые выглядели вполне легитимными, начинают рассматриваться иначе, потому что они приходят от сетевого источника, уже помеченного c помощью NDR как подозрительный.
Проект с такой интеграцией был успешно реализован на основе решений "Гарда NDR" и "Гарда DBF" в 2025 г.
"Гарда NDR" – решение для защиты от сложных и неизвестных киберугроз на основе анализа сетевого трафика и телеметрии с возможностью активного реагирования на инциденты.
"Гарда DBF" – система комплексной защиты данных в СУБД и бизнес-приложениях. Осуществляет независимый контроль операций и реагирует на угрозы в режиме реального времени. Позволяет контролировать действия привилегированных пользователей, обнаруживать факты сокрытия следов несанкционированной активности.
Ключевой момент не в самом факте интеграции, а в смене логики детектирования. Речь идет о том, чтобы связать неоднозначные сигналы в цепочку. Ни сетевой индикатор, ни отдельный SQL-запрос поодиночке не являются доказательством утечки. Но вместе они начинают складываться в полную картину: откуда пришел запрос, что именно читали, как долго это происходило и куда в итоге ушли данные. Именно в этот момент тихая эксфильтрация превращается в процесс с началом, развитием и последствиями. Появляется не просто алерт, а вектор атаки.
Есть мнение, что тихую эксфильтрацию можно обнаружить только постфактум, когда ущерб уже частично нанесен. На практике это верно лишь в тех случаях, когда система защиты не пытается понять, что для хоста является нормальным. Как только появляется поведенческая модель, временной горизонт существенно сокращается.
Блокировка – тяжелое решение
Возникает вопрос: если мы видим активность с подозрением на эксфильтрацию, почему просто ее не заблокировать? Вроде бы ответ выглядит просто. Но организационно – это один из самых сложных моментов во всей цепочке.
Исторически системы защиты баз данных в большинстве компаний работают в режиме мониторинга. Не потому что они не умеют блокировать, а потому что никто не хочет брать на себя риск. Любая ошибка на этом уровне сразу превращается в инцидент для бизнеса: приложение перестало работать, отчет не сформировался, сервис упал в самый неподходящий момент. И дальше начинается хорошо знакомая многим цепочка взаимных претензий между ИТ, ИБ и владельцами процессов.
Эта осторожность понятна. Поэтому даже при наличии уверенных сигналов компании часто предпочитают сначала посмотреть еще, собрать больше данных, убедиться, что это не ложное срабатывание.
Проблема в том, что тихая эксфильтрация как раз и выигрывает от этой паузы. Пока система наблюдает, данные продолжают уходить. И чем аккуратнее работает злоумышленник, тем сложнее принять решение о жестком действии. Здесь нет яркого триггера, нет характерного события, после которого все становится очевидно.
Блокировка в таких сценариях – вопрос зрелости процессов и доверия к аналитике. Пока у ИБ нет уверенности в том, что система понимает контекст и видит картину целиком, автоматическая реакция будет восприниматься как риск, а не как защита.
Даже если эксфильтрацию не удалось остановить на самой ранней стадии, связка DBF и NDR меняет качество последующего расследования. Вместо попыток восстановить события по логам появляется связная картина – не просто факт утечки, а понятная последовательность действий.
Важный момент здесь в том, что системы начинают работать не как источники логов, а как участники расследования. Решения на уровне DBF и NDR могут принимать локальные решения, фиксировать инцидент, блокировать отдельные действия и уже в таком виде передавать информацию в SIEM. В результате в SIEM попадает не хаотичный поток событий, а практически готовый инцидент с контекстом и временной линией.
С точки зрения доказательной базы появляется возможность аргументированно говорить о злонамеренности, а не просто о подозрительной активности.
От детекта к активному противодействию
Когда базовый детект и расследование начинают работать, довольно быстро возникает следующий вопрос: а что можно сделать дальше, кроме фиксации и блокировки? Связка NDR и DBF здесь открывает пространство для сценариев, которые еще несколько лет назад выглядели скорее экспериментальными, чем практическими.
Самое очевидное направление – ускорение реакции. Сегодня многие интеграции строятся вокруг передачи списков индикаторов и ожидания, пока другая система их обработает. Логика постепенно смещается в сторону более прямого взаимодействия: если одна сторона уверена в компрометации источника или учетной записи, другая может реагировать практически сразу, без промежуточных этапов.
Дальше начинается работа с самим содержимым данных. Если система понимает, что происходит злонамеренная выгрузка, появляется возможность не только остановить процесс, но и повлиять на его дальнейшее развитие. Маркировка данных, добавление скрытых идентификаторов, отслеживание утекших копий – все это позволяет увидеть, где и как информация всплывает после выхода за пределы исходного контура. В таких сценариях эксфильтрация становится источником дополнительной аналитики.
Еще один логичный шаг – более тесная связка с маскированием и технологиями Deception. Если выявлен подозрительный хост, пользователь или приложение, – можно незаметно перенаправить их к обезличенной среде или в ложный слой инфраструктуры. Злоумышленник продолжает действовать, не подозревая, что его поведение уже находится под контролем, а риск утечки реальных данных при этом исключается.
Все эти сценарии не рождаются в лабораториях ради красивых презентаций. Они появляются из практики, когда заказчик сталкивается с конкретной проблемой и ищет способ не просто закрыть инцидент, а понять, как сделать систему устойчивее к подобным атакам в будущем. Тихая эксфильтрация здесь выступает как драйвер развития – заставляя защиту данных двигаться от пассивного наблюдения к управляемому противодействию.
Вместо послесловия
Если свести рассуждения к одной мысли, она будет такой: утечки из баз данных давно перестали быть следствием плохих людей или дырявых систем. Гораздо чаще это результат того, что инфраструктура живет по инерции, а данные в ней воспринимаются как статичный ресурс, а не как процесс с поведением, динамикой и рисками.
Тихая эксфильтрация неудобна именно этим. Она спокойно существует в рамках разрешенного – и потому требует от ИБ не быстрых реакций, а вдумчивого взгляда на то, как устроено доверие внутри системы. Кто, зачем и в каком контексте работает с данными, и что происходит после того, как данные покидают привычные границы.
Связка NDR и DBF в этом смысле – не универсальный ответ и не серебряная пуля. Это пример того, как разные уровни защиты данных и сетевой безопасности начинают дополнять друг друга и закрывать слепые зоны, которые по отдельности они закрыть не могут. И чем раньше такие связи становятся частью архитектуры, а не разовой интеграцией под конкретный кейс, тем меньше шансов у эксфильтрации оставаться тихой.
Реклама: ООО «Гарда Технологии». ИНН 5260443081. Erid: 2SDnjdUDbF7