Теневые базы данных – это часть инфраструктуры Shadow IT, которая находится вне формального учета и контроля служб ИБ и ИТ. Среди всех видов теневых ИТ-активов ИИ-помощники и базы данных остаются наиболее уязвимыми и желанными для злоумышленников. Теневые базы данных могут быть полностью рабочими, но при этом отсутствовать в актуальной инвентаризации, модели угроз и регламенте контроля. Разберемся, как такие базы данных появляются в ИТ-инфраструктуре компании и какие риски кибербезопасности с ними связаны.
Автор: Дмитрий Горлянский, эксперт по технологиям защиты СУБД компании "Гарда"
Теневая инфраструктура баз данных возникает по разным причинам, но последствия схожи: компания теряет контроль над данными и рискует их безопасностью. На практике такие БД делятся на три типа: они отличаются не только происхождением, но и характером угроз.
Первый тип – инфраструктура по недосмотру
К нему относятся тестовые базы, временные сервисы, стенды для проверки гипотез, которые не вывели из эксплуатации. Подразделения внутренней разработки (программисты, тестировщики, DevOps-инженеры и т. д.) регулярно поднимают новые экземпляры БД для проверки работы обновлений, совместимости и отладки, но после завершения работ часть баз остается в сети. Со временем на серверах накапливаются дампы данных близкие к реальным. В них могут содержаться персональные данные, коммерческая тайна и другая конфиденциальная информация. При этом должные меры защиты к таким базам не применяются.
К этой же категории можно отнести базы данных информационных систем, которые были выведены из эксплуатации, но не отключены. Компания переходит на новую CRM или биллинг, отключает приложение, но сервер базы данных продолжает работать. Так, в одном из проектов крупной компании старый сервер, формально выведенный из эксплуатации еще в 2016 г., оставался доступным с инженерными учетными записями. После утечки учетных данных злоумышленник получил через него доступ во внутренний сегмент сети и использовал базу для разведки и развития атаки.
Возможны и ситуации, когда в ходе пентестов команда Red Team разворачивает дампы баз данных, а после завершения работ не удаляет их из инфраструктуры компании.
Второй тип – легальная база данных с теневыми подключениями
Сама СУБД учтена, но к ней подключают сторонние инструменты без уведомления ИТ и ИБ. Чаще всего это системы бизнес-аналитики, отчетности, маркетинга и другие сервисы. Руководитель подразделения или аналитик настраивает прямое подключение к продуктивной базе для построения отчетов. Данные выгружаются напрямую, иногда регулярно и в полном объеме. При этом такой сценарий не всегда включают в модель угроз.
На одном из проектов подобную схему подобную схему удалось обнаружить при аудите обращений к клиентской базе. Часть запросов выполнялась под личной учетной записью сотрудника. Анализ показал регулярную выгрузку конфиденциальных данных в стороннюю BI-систему. Формально доступ был легитимным, но процесс не проходил согласование и создавал дополнительные риски.
Если на проекте встречаются такие случаи, то рекомендуется учесть этот бизнес-процесс в модели угроз, легализовать базу и подключения к ней сторонних сервисов, оценить риски и настроить политики контроля. Дополнительной эффективной мерой защиты становится применение технологии маскирования, когда БД отдает BI-системе данные не в исходном виде, а в обезличенном – заменяет на синтетические, сохраняя формат.
Третий тип – умышленная теневая инфраструктура
Ее создают либо внешние злоумышленники после проникновения в сеть, либо внутренние нарушители.
В случае взлома извне после проникновения в сеть атакующий разворачивает временную БД для сбора данных и координации атаки. В нее складываются результаты разведки: IP-адреса, версии сервисов, операционных систем, данные учетных записей. Такая база помогает злоумышленникам координировать дальнейшие действия и развивать атаку. Другой вариант – использования теневой БД для выгрузки информации из боевых баз данных через встроенные механизмы самой СУБД, например через dblnk. Найти эти события в логах СУБД крайне проблематично, потому что в них нет ни названия таблиц, из которых выгружается информация, ни описания, ни типа контента. ИБ-аналитики такие операции видят как обычные системные вызовы, поэтому без анализа трафика и контента обнаружить выгрузку проблематично.
Наиболее радикальные случаи развертывания теневой инфраструктуры – ее использование для формирования теневых бизнес-процессов. Инсайдеры создают копии информационных систем, бизнес-приложений, копии баз данных, и работают уже с ними, запуская свои параллельные теневые сервисы. Так, в одном проекте у оператора связи выявили теневой биллинг: администратор развернул параллельную систему учета и продавал услуги связи вне официального контура. База была открыта на нестандартном порту, что позволяло скрыть ее от штатного сканирования. Сложность этого вида мошенничества – его невидимость для встроенных инструментов защиты СУБД. В этом случае его удалось обнаружить с помощью сканирования и анализа сырого трафика сети, благодаря чему были выявлены обращения к неучтенной базе данных.
Какие последствия возможны, если теневая база данных не будет обнаружена? Рассмотрим на примере одного проекта из нашей практики проектов. Злоумышленник использовал забытую учетную запись PostgreSQL и расширение dblink. С помощью функций dblink_connect и dblink_exec он потенциально мог подключиться к сторонней СУБД и выполнить к ней удаленный запрос с эксфильтрацией данных. Причем никакие встроенные средства мониторинга не позволили бы обнаружить такую утечку. Однако технологии Database Firewall смогли не только зафиксировать факт вызова этих функций, но и обнаружить признаки сбора данных и последующую эксфильтрацию, благодаря технологии анализа регулярных выражений. При использовании режима активного противодействия угрозам попытки вызова функции можно и вовсе заблокировать.
Меры обнаружения и защиты
Обнаружение теневых баз данных требует сочетания нескольких механизмов. Первый инструмент – регулярное сканирование сети на предмет открытых портов СУБД. Его запускают по расписанию и по сегментам, чтобы не перегружать инфраструктуру и корректно интерпретировать результаты. Такой подход помогает выявить забытые и неактивные базы. Ограничение метода очевидно: если сервис работает на нестандартном порту или скрыт иным способом, сканирование его не заметит.
Второй инструмент – анализ живого сетевого трафика. Система фиксирует реальные обращения к базам данных (запросы и ответы, а также их содержимое) и выявляет те, которые ранее не учитывались. По содержимому запросов и ответов можно определить, передаются ли персональные данные или иная чувствительная информация. Механизм анализа обращений обнаружит базу данных, даже если она работает на нестандартном порту и пытается себя скрыть. Недостаток этого механизма в зависимости от активности: если к базе не обращаются, то сканирование по трафику ее не обнаружит.
Третий инструмент – профилирование и поведенческий анализ баз данных. Профилирование определяет, какие учетные записи работают с базой, из каких сегментов и через какие приложения. На основе данных формируется модель обращений и профиль нормального поведения. Профили баз данных в виде дашбордов можно напрямую передавать аналитикам SOC для отслеживания подключений в реальном времени. Появление новых подключений, нестандартных запросов или нетипичных источников сигнализирует о риске. Такой подход особенно эффективен для выявления несанкционированных подключений и внутренних злоупотреблений с использованием легальной инфраструктуры.
По итогам сканирования и поведенческого анализа офицеру безопасности предстоит принять несколько управленческих решений: легализовать выявленные базы данных (взять их в контур безопасности и накатить на них политики контроля), запретить их использование (удалить все теневые инстансы) либо применять динамическое маскирование. Последний вариант актуален, когда обнаруживаются теневые подключения к легальной инфраструктуре. Применение динамического маскирования позволяет сохранить использование баз данных, но обезличивать ответы на запросы, которые кажутся офицеру безопасности нелегитимными или исходят от внешних пользователей (например, подрядчиков).
Практика показывает, что перечень баз данных, сформированный в рамках внутренней инвентаризации, часто не совпадает с фактической картиной в инфраструктуре. Уже на этапе первичного аудита выявляются дополнительные экземпляры баз данных, которые не отражены в актуальной документации и бизнес-процессах компании. Поэтому после проведения первичной инвентаризации рекомендуется делать более глубокую классификацию с привлечением профильных специалистов организации, поскольку именно они могут корректно определить принадлежность обнаруженной базы к конкретной системе и ее роль в бизнес-процессах.
В заключение
Теневые СУБД – не абстрактная угроза, а следствие организационных пробелов, технических упущений и активности атакующих. Без регулярной инвентаризации, анализа трафика, профилирования и поведенческого анализа компания теряет контроль и прозрачность процессов. В результате даже легальная инфраструктура постепенно превращается в набор неучтенных точек входа для злоумышленников и повышает риски утечки данных.