Безопасность баз данных: как извлечь максимум из технологий DAM

Habr

9 min

Привет, Хабр, меня зовут Дмитрий Горлянский, я руководитель технического сопровождения продаж группы компаний «Гарда». Уже больше десяти лет обеспечиваю реализацию проектов внедрения ИБ-систем, но наибольший интерес для меня представляет защита данных.

За годы работы я не раз сталкивался с ситуацией, когда компании внедряют системы защиты, но используют их далеко не в полной мере. Технология DAM (Database Activity Monitoring) существует уже более десяти лет, однако на практике все еще встречаются примеры ее неэффективного использования. Это как правило обусловлено двумя факторами:

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

По итогам 2024 года Роскомнадзор сообщил о 135 случаях утечек баз данных. В результате в открытом доступе оказалось рекордное количество ‒ более 710 млн записей персональных данных российских граждан. В зависимости от источника утечки, записи включают ФИО, даты рождения, номера телефонов, адреса электронной почты и физические адреса, паспортные данные, номера банковских карт, детали заказов, хэш-суммы паролей, и другую конфиденциальную информацию.

В этой статье рассматривается технология DAM (Database Activity Monitoring) ‒ инструмент мониторинга активности пользователей в базах данных, позволяющий выявлять аномалии, контролировать доступ и предотвращать утечки данных. Мы разберем, какие угрозы характерны для работы с базами, функциональные возможности DAM, типовые задачи защиты данных, решаемые с помощью DAM, как DAM для противодействия угрозам, дадим рекомендации по настройкам.

Классификация киберугроз для баз данных

Список специфичных для баз данных угроз:

1. Кража данных БД внешними злоумышленниками,

2. Утечка, осуществляемая внутренним пользователем,

3. Мошеннические действия с использованием легитимного доступа к информации или прямого доступа к данным,

4. Вывод из строя системы управления базой данных (СУБД),

5. Порча или подмена данных.

Кроме того, угрозы можно разделить на общие и специфичные для отрасли: общие угрозы включают утечки персональных данных, а также нелегитимный доступ к информации, а отраслевые угрозы варьируются в зависимости от бизнеса. Например, в ритейле ‒ это кража данных о скидках и акциях, в телекоммуникациях ‒ сбор информации о человеке по номеру телефона. Важно учитывать легитимный доступ к инсайдерской информации. Например, сотрудники колл-центра могут использовать свои полномочия для получения и передачи данных, что требует особого внимания.

При атаках на базы данных чаще всего целью становятся:

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

Злоумышленники могут использовать персональные данные для подбора паролей. Как показывает практика, примерно 30% сотрудников в компаниях ставят даты рождения в паролях, а значит получив базу таких данных можно настроить словарь для брутфорса других систем. Финансовая информация может пригодиться преступникам для мошеннических операций, а корпоративные данные интересны конкурентам для получения преимуществ.

К последствиям несанкционированного доступа к БД относятся:

кража информации, утечки данных,
потеря доходов,
штрафы от контролирующих органов,
расходы на устранение последствий взлома, восстановление данных и систем,
ущерб репутации и отток клиентов.

DAM и его функциональные возможности

DAM ‒ это инструменты продвинутого мониторинга и анализа пользовательских обращений к базам данных. Аналитическая компания Gartner определяет DAM следующим образом:

Database Activity Monitoring ‒ это набор инструментов, которые помогают идентифицировать и оповещать о мошенническом, нелегальном и нежелательном поведении с минимальным влиянием на операции и производительность пользователей баз данных. Эти инструменты эволюционировали из базового анализа активности в реляционных системах управления базами данных (RDBMS) до более широкого набора возможностей, таких как обнаружение и классификация, управление уязвимостями, анализ на уровне приложений, предотвращение вторжений, поддержка безопасности неструктурированных данных, интеграция с системами управления учетными данными, а также поддержка систем управления рисками.

Ключевое отличие от стандартного логирования в том, что DAM не только фиксирует, какие запросы делают пользователи, но и анализирует, какие данные возвращаются в ответ.

Система Database Activity Monitoring позволяет:

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

Типовые задачи защиты данных, решаемые с помощью DAM

1. Контроль массовой выгрузки данных. DAM выявляет аномалии в активности учетных записей, что позволяет детектировать случаи выгрузки превышающих стандартные объемы данных.

Кейс: в компании действовал запрет на массовую выгрузку данных, стояло ограничение не более 1 000 строк одним запросом. Однако администратор написал скрипт, с помощью которого в течение двух недель небольшими порциями выгружал данные из БД, маскируясь под штатную активность. Таким образом он избегал аномально большой активности, и смог скачать всю базу данных.

DAM позволяет бороться с подобными случаями средствами профилирования. Даже при попытке скрыть активность путем небольших порционных запросов, система определяет совокупный объем выгруженной информации с учетной записи, выявляет превышения и аномалии, и позволяет блокировать их.

2. Выявление фактов внутреннего мошенничества с использованием доступа к конфиденциальной информации.

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

DAM позволяет анализировать обращения к БД, соответствующие конкретному действию пользователя в бизнес-приложении, в данном случае – выполнение поиска событий по параметру «сумма страховой премии», а также выполнять статистический анализ таких действий и сигнализировать о фактах аномальной активности пользователя по данному бизнес-процессу

3. Контроль за техническими учетными записями в трехзвенных архитектурах информационных систем.

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

1. Контроль обращений пользователей к приложению, а не к самой БД с разбором HTTP- или HTTPS-протоколов. Этот вариант удобен для решения задач выявлений внутренних мошенничеств, а также выявления неправомерного доступа к критической информации. Например – контроль обращений сотрудников call-центров к персональным данным клиентов не своего региона или другой зоны ответственности.

2. Использование механизмов user-tracking, либо встроенных в приложение, либо доработка приложения для передачи идентификатора пользователя в SQL-сессиях.

3. Контроль технологических учетных записей, под которыми работает приложение. Особенно это актуально для веб-приложений, опубликованных в интернете. Злоумышленники могут получить доступ к технической учетной записи через уязвимости веб-приложения (например, с помощью SQL-инъекции). Поэтому важно выявлять аномалии в поведении, анализировать и формировать профиль активности учетной записи. Например, веб-сервер, взаимодействующий с личным кабинетом, обращается к базе данных. В случае компрометации учетной записи можно обнаружить попытки доступа к данным из таблиц, с которыми ранее не было взаимодействия, даже если доступ к этим таблицам отсутствует. Сам факт попытки указывает на высокую вероятность компрометации учетной записи. Также индикатором атаки будут попытки выполнения нестандартных запросов (заведение пользователей, попытки смены роли), попытки обращений к системным таблицам (списки пользователей и ролей, таблицы с настройками безопасности, небезопасные хранимы процедуры).

4. Контроль изменений в базе данных.

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

Кейс: администратор вручную вмешивался в процесс обработки денежных переводов, находил транзакцию своего сообщника по реквизитам, изменял данные и корректировал суммы. Вместо предусмотренных 10 000 рублей сообщник получал 50 000.

Поэтому важно выявлять, какие именно записи в БД используются в уязвимых к изменениям процессах, определять легитимные источники внесения этих данных и выявлять несанкционированное их изменение.

5. Детектирование потенциально опасных событий.

Речь идет о сопутствующих проведению кибератаки действиях, которые не обязательно связаны с попытками организовать утечку информации, и поэтому часто остаются без должного внимания со стороны ИБ. К таким событиям можно отнести:

попытки подключения к базе данных под ранее заблокированными учетными записями (например, ранее уволившихся сотрудников, особенно администраторов), или же техническими учетными записями подрядчиков, ранее работавших с БД;
аномально большое количество запросов, возвращающих ошибку. Это может говорить о том, что скомпрометировано или выведено из строя приложение, работающее с базой данных;
массовое создание новых пользователей или объектов в базе данных;
попытки просмотра данных системных таблиц – списка учетных записей, хэшей паролей, настроек безопасности и другое.

При наступлении подобных событий рекомендуется отправлять соответствующие уведомления в SIEM-системы для оперативного мониторинга и корреляции с событиями других систем мониторинга.

Мониторинг и противодействие

DAM-системы развиваются как комплексные решения и могут использоваться не только как средства мониторинга, но и в режиме блокировки нелегитимных SQL-запросов. Примеры типичных правил блокировки:

доступ технической учетной записи на сервер приложений со сторонних IP-адресов;
не локальные подключения встроенных технических учетных записей;
SELECT-запросы к таблицам с персональными данными, которые выполняются учетной записью подрядчика (администратора) и возвращают более 1 строки данных;
выполнение запросов типа INSERT, UPDATE в таблицы от учетных записей, не входящих в список разрешенных для этих действий;
подключение учетных записей администраторов с чужим доменным именем.

Шукати в цьому блозі

OSINT | OOSI | JJIT | CASBT