Теневые базы данных: риски, типы и методы защиты
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
Email: petukhov@legascom.ru
Теневые базы данных - часть Shadow IT: они находятся вне контроля служб ИТ и ИБ, но при этом хранят чувствительную информацию и становятся лакомой целью для злоумышленников. Даже если такие БД технически исправны, их отсутствие в инвентаризации и модели угроз делает инфраструктуру уязвимой. Разбираем, какие типы теневых баз встречаются в компаниях, чем они опасны и как их выявлять и нейтрализовать.
Откуда берутся теневые БД: 3 основных типа
Тип 1. Инфраструктура по недосмотру
Это забытые тестовые базы, стенды для отладки, дампы для проверки гипотез, а также БД от уже отключённых систем. Их оставляют «на всякий случай» или просто не удаляют после завершения работ.
Типичные сценарии:
разработчики и DevOps поднимают временные экземпляры БД для тестов, но не выводят их из эксплуатации;
старая CRM или биллинг отключены, а сервер базы данных продолжает работать;
по итогам пентеста Red Team не удаляет тестовые дампы.
В таких базах нередко хранятся данные, близкие к реальным: персональные данные, коммерческая тайна, учётные записи. При этом к ним не применяют актуальные меры защиты, и они становятся удобной точкой входа для атак.
Пример из практики юридической компании ЛЕГАС: старый сервер, формально выведенный из эксплуатации ещё в 2016 году, оставался доступным с инженерными учётными записями. После утечки учётных данных злоумышленник использовал его для разведки и развития атаки во внутреннем сегменте сети.
Тип 2. Легальная БД с теневыми подключениями
Сама СУБД учтена, но к ней подключают сторонние сервисы (BI, отчётность, маркетинг) без согласования с ИТ и ИБ. Часто это делает отдельный сотрудник: настраивает прямое подключение к продуктивной базе для построения отчётов, и данные выгружаются регулярно, иногда в полном объёме.
Такие подключения формально могут быть легитимными, но не отражены в модели угроз и не контролируются.
Что делать: легализовать процесс, включить его в модель угроз, оценить риски и настроить политики контроля. Эффективная мера - динамическое маскирование: BI-система получает не исходные данные, а обезличенные (синтетические), при этом сохраняется формат.
Тип 3. Умышленная теневая инфраструктура
Её создают либо внешние злоумышленники после проникновения, либо внутренние нарушители.
Варианты:
Для координации атаки. Злоумышленник разворачивает временную БД, чтобы хранить результаты разведки: IP-адреса, версии сервисов, учётные данные.
Для эксфильтрации данных. Используются встроенные механизмы СУБД (например, dblink), которые сложно отследить по логам: в них нет названий таблиц и описания контента. Для ИБ-аналитика такие операции выглядят как обычные системные вызовы.
Теневые бизнес-процессы. Инсайдеры разворачивают параллельные системы (например, теневой биллинг) и работают вне официального контура. Такие сервисы могут быть скрыты на нестандартных портах и не обнаруживаются штатным сканированием.
Пример: у оператора связи выявили теневой биллинг: администратор вёл параллельный учёт и продавал услуги вне официального контура. Базу открыли на нестандартном порту, чтобы избежать обнаружения. Выявить её удалось только через анализ сырого сетевого трафика.
Чем опасны теневые БД: реальный кейс
Злоумышленник может использовать забытую учётную запись PostgreSQL и расширение dblink, чтобы подключиться к сторонней СУБД и выполнить удалённый запрос с выгрузкой данных. Встроенные средства мониторинга не фиксируют такие операции.
Однако специализированные решения (например, Database Firewall) способны:
обнаружить вызовы функций dblink_connect и dblink_exec;
выявить признаки сбора данных и эксфильтрации с помощью анализа регулярных выражений;
в режиме активного противодействия - заблокировать подозрительные вызовы.
Как выявлять теневые базы: 3 ключевых инструмента
Сканирование сети на открытые порты СУБД. Запускают по расписанию и по сегментам, чтобы снизить нагрузку и корректно интерпретировать результаты. Помогает найти забытые и неактивные базы.
Ограничение: если сервис работает на нестандартном порту или скрыт иным способом, сканирование его не заметит.
Анализ живого сетевого трафика. Система фиксирует реальные обращения к БД (запросы и ответы, содержимое), выявляя ранее неучтённые базы. По содержимому можно определить, передаются ли персональные данные или иная чувствительная информация.
Ограничение: если к базе нет обращений, она не попадёт в выборку.
Профилирование и поведенческий анализ БД. Формируют модель нормального поведения: какие учётные записи, сегменты и приложения работают с базой. Отклонения (новые подключения, нестандартные запросы, нетипичные источники) сигнализируют о риске. Профили в виде дашбордов передают аналитикам SOC для мониторинга в реальном времени.
Какие решения принимать после обнаружения
По итогам аудита офицеру безопасности нужно выбрать одну из стратегий:
Легализовать базу. Взять её в контур безопасности, применить политики контроля, включить в инвентаризацию и модель угроз.
Запретить использование. Удалить теневые инстансы и заблокировать доступ.
Применить динамическое маскирование. Актуально для теневых подключений к легальной инфраструктуре: сохранить функциональность, но обезличивать ответы на подозрительные запросы (например, от подрядчиков).
Практические рекомендации
Проводите регулярную инвентаризацию. Практика юридической компании ЛЕГАС показывает, что перечень БД по документам почти всегда отличается от фактической картины в инфраструктуре.
Делайте глубокую классификацию с привлечением профильных специалистов. Только владельцы систем могут корректно определить принадлежность базы и её роль в бизнес‑процессах.
Комбинируйте методы обнаружения. Сканирование, анализ трафика и поведенческое профилирование закрывают разные сценарии: забытые базы, скрытые сервисы и внутренние злоупотребления.
Автоматизируйте контроль. Используйте инструменты, которые позволяют фиксировать новые подключения, выявлять аномальные запросы и блокировать рискованные операции (например, вызовы dblink).
Вывод
Теневые СУБД - не гипотетическая угроза, а следствие организационных пробелов и технических упущений. Без регулярной инвентаризации, анализа трафика и поведенческого контроля компания теряет прозрачность и контроль над данными. Комплексный подход позволяет вовремя выявлять неучтённые базы, снижать риски утечек и превращать «слепые зоны» в управляемые элементы инфраструктуры.
