Привет, Хабр!
Меня зовут Алексей Шмелёв, я руковожу группой аналитики и безопасности данных в «Гарде». Мы занимаемся настройкой «решающих правил» в таких продуктах «Гарды», как DBF и DLP. Наша задача — настроить политики таким образом, чтобы они удовлетворяли требованиям заказчиков и соответствовали нормативно-правовым актам по защите информации. В результате нашей работы решение, установленное в отдельно взятой инфраструктуре или информационной системе, эффективнее детектирует события безопасности.
Прежде всего хочу отметить, что утечки данных у заказчиков встречаются в процессе эксплуатации DBF не так часто, как может показаться. Зачастую утечки становятся результатом некорректных настроек или легаси-процессов. Так, в число «интересных» событий, фиксируемых решением, входят выборка данных из чувствительных таблиц, нарушение принципа наименьших привилегий и порядка доступа к данным, хранимым в БД. Всё это — следствие несоблюдения корпоративных ИБ-политик.
Каждое из этих действий по отдельности легко объясняется срочной задачей, историческим наследием или «временным костылем, который стал постоянным». Однако, когда таких аномалий становится несколько или одна и та же аномалия начинает встречаться чаще, формируется устойчивый фон, который усложняет расследования и размывает ответственность. В таком шуме легко пропустить реальный инцидент.
Ниже — десять паттернов, которые мы встречаем на проектах чаще других. Я расположил их в порядке убывания частоты: от того, что видим почти на каждом внедрении, до редких, но от этого не менее интересных кейсов. Для каждого случая разберу, как аномалия проявляется, почему возникает, чем рискует заказчик и как перевести ситуацию из зоны «серого шума» в управляемый процесс.
Работа админов из-под техучеток
Частота: 🟣🟣🟣🟣⚪ (очень высокая)
Опасность: 🟣🟣🟣⚪⚪ (средняя)
Сервер приложений обращается к базе данных через технологические учетные записи (ТУЗ). Для реализации бизнес-процессов в информационной системе ТУЗ обладают достаточно широким набором привилегий по отношению к хранимым в БД данным: выборка, изменение и удаление.
Согласно требованиям безопасности, например, PCI DSS, интерактивное использование учетных записей приложений ТУЗ запрещено. Их допускается использовать только в исключительных случаях: при наличии производственной необходимости, при обосновании и документальном подтверждении со стороны руководства. Но на практике администраторы часто работают через них. Под одной учеткой выполняются и запросы приложения, и ручные SQL-операции. Мы встречаем такое более чем у половины заказчиков.
Во встроенной в СУБД подсистеме аудита работа из-под ТУЗ выглядит как действия одного субъекта. А на деле это разные типы активности, а самое главное — разные люди, которые выполняют операции из-под одной учетной записи. В итоге невозможно понять, кто именно выполнил действие, и разделить активность приложения и активность привилегированных пользователей, использующих ТУЗ.
Как это видит DBF. DBF строит поведенческий профиль учетной записи: тип запросов, частота, IP и параметры подключения. Комплекс фиксирует отклонение, если вход в БД выполняется не с IP-адресов серверов приложений и при этом используются, скажем, SQL-редакторы или терминальные клиенты СУБД.
Интерактивное использование ТУЗ отличается от активности приложения по структуре и свойствам SQL-запросов, а также параметрам сессии с сервером БД.
Чем опасно. Нельзя определить, кто выполнил действие, так как все операции выполняются из-под одной учетной записи.
Что делать. Разделить учетные записи. Приложение работает через ТУЗ, администраторы — через персональные аккаунты. Запретить интерактивное использование ТУЗ. Настроить в DBF контроль использования ТУЗ и фиксировать отклонения по параметрам сессии с БД.
Дефолтные учетки в проде
Частота: 🟣🟣🟣🟣⚪ (высокая)
Опасность: 🟣🟣🟣🟣🟣 (критическая)
Во всех СУБД есть стандартные учетные записи: postgres в PostgreSQL, sys и system в Oracle, sa в MSSQL, root в MySQL. Формально, согласно PCI DSS и ГОСТ Р 57580, их использование должно быть сведено к минимуму, то есть только по производственной необходимости. А в случае отсутствия таковой эти учетные записи необходимо удалять или блокировать. На практике это правило соблюдается далеко не всегда.
Часто эти учетки продолжают использоваться — где-то их держат для работы серверов приложений, где-то на них завязаны служебные скрипты, а иногда под ними просто привыкли работать админы.
По факту дефолтные учетные записи давно живут как полноценные привилегированные учетки в боевой инфраструктуре. У одного из заказчиков, например, контроль стандартных УЗ показал активное использование учетной записи postgres. Причем не просто для обслуживания. Из-под нее шло управление другими учетками в продакшене.
Как это видит DBF. Комплекс фиксирует все обращения к БД из-под стандартных учетных записей и строит профили их легитимного использования. Если вдруг, к примеру, из-под sa или postgres выполняются операции по управлению учетными записями БД или массовая выборка данных из таблиц, комплекс фиксирует отклонение.
Чем опасно. Дефолтные учетные записи в числе первых становятся объектом атак злоумышленников. Компрометация таких УЗ может привести к серьезным негативным последствиям, так как зачастую они обладают максимальным набором привилегий.
Что делать. Понять, чем вызвано использование учетных записей по умолчанию. Если это не производственная необходимость, то сперва важно создать отдельные сервисные учетки с минимально необходимым набором привилегий. Затем перевести на работу из-под них сервисы и бизнес-процессы.
В случае обоснованной необходимости использование стандартных учеток важно контролировать.
В DBF при этом имеет смысл выделить отдельное правило: любые действия под default-аккаунтами, за исключением регламентных задач, считать критичным событием и сразу отправлять в SOC.
Общие креды у нескольких админов
Частота: 🟣🟣🟣⚪⚪ (средняя)
Опасность: 🟣🟣🟣🟣⚪ (высокая)
В идеале админы для сопровождения серверов БД должны использовать персональные учетки. Но это только в идеале. Случай, когда сервер администрировал один сотрудник, потом уволился, система масштабировалась, администраторов стало несколько, а учетка осталась общей — отнюдь не единичный.
Как это видит DBF. Строя профиль учетной записи, DBF фиксирует количество уникальных IP-адресов и учетных записей операционной системы, с которых выполняется подключение под одним логином. Если в профиле учетной записи несколько IP-адресов и логинов ОС, — это тревожный маркер.
Поведенческая модель фиксирует не только сами запросы, но и способ подключения пользователя к БД — откуда и через какие инструменты он подключился. Например, это может быть SQL-редактор либо командная строка (CLI).
Чем опасно. Безопасникам сложнее расследовать инциденты. Кроме того, неперсонифицированные учетные записи используются админами с целью сокрытия своих нелегитимных действий.
Что делать. Внедрить персонализированный доступ. Для временных задач использовать механизмы JIT-доступа с обязательным аудитом сессий. Фиксировать факты подключения из-под одной учетной записи с разных IP-адресов, а также из-под разных учетных записей ОС.
Ручные изменения данных в продакшене
Частота: 🟣🟣🟣⚪⚪ (средняя)
Опасность: 🟣🟣🟣⚪⚪ (средняя)
Операции INSERT и UPDATE — обычная часть жизни любой СУБД. В продакшене их проходят тысячи в сутки, и сами по себе они не вызывают вопросов. В норме такие изменения идут через сервер приложений и бизнес-логику. Она диктует правила игры: какие данные можно менять и при каких условиях.
Но если те же изменения начинают делать напрямую через SQL-редактор, да еще и в нетипичное время, — это уже повод насторожиться. Так, в одном из кейсов сотруднику техотдела с повышенными правами нужно было срочно внести правки в проде. DBF зафиксировала аномалию, так как данные начали менять в нетипичные для обновления приложения интервалы времени. Формально человек не нарушил регламент, но внимание DBF привлекло именно изменение контекста. С точки зрения системы важен не только сам факт корректировки, но и то, как это происходит.
Как это видит DBF. Система анализирует SQL-запросы и сопоставляет их с источником подключения (именем приложения и IP-адресом). Если команды UPDATE или INSERT приходят из нетипичного источника или выполняются в необычное время, формируется соответствующий алерт.
Чем опасно. Прямые изменения в базе обходят бизнес-логику приложения (слой, который валидирует операции и фиксирует их контекст). Например, администратор подключается к базе через SQL-клиент и вручную выполняет UPDATE, минуя backend.
Изменение данных не через приложение может нарушить логику его работы и привести к недоступности данных.
Что делать. Полностью исключить такие сценарии в продакшене обычно невозможно, поэтому лучше использовать несколько уровней контроля. Где допустимо, ограничить права на DML-операции с помощью ролевой модели доступа, а для экстренных правок ввести отдельный процесс с фиксацией изменений и последующим аудитом. В DBF дополнительно стоит настроить алерты на нетипичные сценарии.
Повышение привилегий в обход политик ИБ
Частота: 🟣🟣⚪⚪⚪ (ниже средней)
Опасность: 🟣🟣🟣🟣⚪ (высокая)
Как правильно выдавать права пользователям? В идеальной картине мира — строго по регламентам информационной безопасности. Нарушение этих правил — как трещина в фундаменте. Сначала она незаметна, но потом приводит к бесконтрольному росту привилегий и, в конечном счете, к утечкам или сбоям.
Но даже там, где всё прописано черным по белому, находится место для «ускоренного пути». В одном из кейсов с помощью DBF мы обнаружили такой инцидент: штатно привилегии выдавались через интерфейс информационной системы. При этом в БД выполнялся вызов процедуры, на вход которой подавались логин, список прав и объекты доступа. В компании обычно всё прозрачно, контролируемо, задокументировано. А тут в логах засветилась — прямая SQL-операция GRANT. Насторожило, что ее выполнили вручную и что привилегии назначались рядовому сотруднику (не из числа привилегированных пользователей). Прямое назначение привилегий через SQL нарушало все внутренние регламенты. Это и стало поводом для расследования.
Как это видит DBF. DBF фиксирует все операции повышения привилегий — через GRANT, при изменении настроек учетной записи через ALTER ROLE/USER, а также через функции и процедуры. Алерт формируется при фиксации способа повышения привилегий, отличного от типичного для данной информационной системы. Причем для DBF «нетипичность» — это не только тип SQL-операции, но и совокупность контекстных признаков. Например, когда, как в нашем случае, админ выполнил операцию GRANT с личного ноута в час ночи через терминал psql.
Чем опасно. Бесконтрольный рост привилегий и повышение риска утечки данных.
Что делать. Операции повышения привилегий должны выполняться только в рамках согласованных сценариев: когда нужно планово или аварийно изменить что-то.
Никакого «я быстро сам через psql выдам, потом оформлю». Такой подход давно пора оставить в прошлом.
Всплески неуспешной аутентификации (брутфорс)
Частота: 🟣🟣⚪⚪⚪ (ниже средней)
Опасность: 🟣🟣🟣🟣⚪ (высокая)
Активность злоумышленников внутри периметра может включать в себя в том числе и различные техники подбора логинов и паролей к БД. При этом всплески ошибок аутентификации не всегда говорят о нелегитимной активности. Сбои и ошибки конфигурации сервисов могут также выдавать похожую картину.
Однако некоторых особо бдительных заказчиков даже такие всплески настораживают. Так, в одном из кейсов подозрения появились по двум причинам. Во-первых, все ошибки были из-под системной учетки sa на сервере MSSQL. Во-вторых, активности из-под данной УЗ до всплеска не наблюдалось в принципе. Всё указывало на нелегитимные действия. Зафиксированные события мы передали профильным подразделениям для проведения дальнейшего расследования.
Как это видит DBF. DBF агрегирует события неуспешной аутентификации за выбранный интервал времени и отслеживает факты превышения порога.
Чем опасно. Как я ранее уже говорил, — системные учетные записи обладают повышенными привилегиями, поэтому в случае их компрометации злоумышленник может получить полный доступ к БД со всеми вытекающими последствиями. Даже если такие события генерирует не злоумышленник, а некий забытый скрипт, оставлять их без внимания не стоит, так как за таким «шумом» можно пропустить реальную атаку.
Что делать. Реагировать не на сами события неуспешной аутентификации, а на превышения порогов. Практика показывает, что количество ошибок аутентификации на прод-системах обычно достаточно большое и далеко не все из них требуют внимания со стороны служб ИБ. В половине случаев оказывается, что какой-то сервис просто долбит в БД старым паролем.
Системные учетки вроде sa — не для продакшена. Их использование допускается только в исключительных случаях, поэтому их следует отключать везде, где это возможно.
Прямой доступ к данным VIP-клиентов на сервере БД
Частота: 🟣🟣⚪⚪⚪ (ниже средней)
Опасность: 🟣🟣🟣🟣🟣 (критическая аномалия для финсектора)
В финансовых организациях за данными счетов VIP-клиентов следят особенно тщательно. И это правильно. Доступ к ним имеют только узкий круг сотрудников, причем все обращения выполняются ими из приложения. Если информацию о VIP запросили напрямую, к примеру, через SQL-редактор, это считается аномалией, требующей немедленной реакции.
Честно, я с подобным отклонением столкнулся впервые. Дело было так. У одного заказчика поставили на контроль доступ к данным «особо важных» клиентов. Результаты мониторинга не заставили себя долго ждать. Буквально через пару недель DBF зафиксировал факты доступа к таким данным со стороны привилегированных пользователей.
Почему такое в принципе могло случиться? В данном случае это было нарушение принципа наименьших привилегий. К слову, компании им довольно часто пренебрегают.
Как это видит DBF. Комплекс проводит классификацию данных по типам и уровням конфиденциальности, либо сведения о «разметке» данных комплекс забирает из внешней системы. Сформированные списки используются далее в качестве критерия политики мониторинга, которая отслеживает все запросы к этим объектам, независимо от того, под какой учеткой они производятся. Далее комплекс фиксирует нетипичные запросы: когда объем выборки превышает порог или запрос приходит не с IP-адреса сервера приложения.
Чем опасно. Высокий риск утечки «чувствительных» данных в результате нелегитимных действий инсайдеров.
Что делать. Провести аудит привилегий доступа пользователей к «чувствительным» данным. Поставить все обращения VIP- и PII-таблицам на контроль комплексом. Особое внимание уделить обращениям к таким таблицам со стороны администраторов БД.
SELECT * без необходимости
Частота: 🟣🟣⚪⚪⚪ (ниже средней)
Опасность: 🟣🟣🟣⚪⚪ (средняя)
Запрос вида SELECT * сам по себе не аномалия. Однако они могут вызывать проблемы с производительностью и безопасностью.
Характерными для приложений являются операции по выборке данных с явным указанием полей таблиц. Поэтому наличие операций SELECT * в обращениях к БД может свидетельствовать о нелегитимной активности. Так, в одной организации спустя неделю после постановки сервера БД на контроль комплексом удалось выявить такие запросы, применив фильтр по содержимому и свойствам SQL-запросов. Ответы на обнаруженные запросы содержали персональные данные клиентов. Правда, утечки как таковой не было, ложная тревога. Оказалось, сотрудники просто решили вручную собрать статистику. Действовали в рамках должностных обязанностей. Но сам факт полной выборки данных из чувствительных таблиц всегда требует внимания. Тут, как говорится, лучше лишний раз перестраховаться.
Как это видит DBF. DBF анализирует SQL-трафик, выявляет запросы вида SELECT* и сопоставляет их со списком таблиц с данными ограниченного доступа. Если выборка затрагивает объекты с метками PII/VIP или таблицы с перс-данными, система дополнительно оценивает количество возвращаемых строк, частоту обращений и отклонение от baseline. Для штатных сервисов SELECT*, особенно на «чувствительных» таблицах, считаются нетипичным паттерном.
Чем опасно. Потенциальная эксфильтрация данных.
Что делать. Ставить на контроль обращения вида SELECT *. При этом особое внимание следует уделять запросам, выполняемым из-под учетных записей привилегированных пользователей. В комбинации со списками таблиц с данными ограниченного доступа политика мониторинга будет выдавать готовый алерт.
Экспорт данных из БД
Частота: 🟣🟣⚪⚪⚪ (ниже средней)
Опасность: 🟣🟣🟣⚪⚪ (средняя)
Операции экспорта позволяют выгружать содержимое таблиц напрямую в файл или терминал. Например, в PostgreSQL за это отвечает команда COPY TO. Ее используют в таких легитимных процессах, как резервное копирование (pg_dump), сбор отчетности, миграции. Если же команда выполняется вне этих процессов, это может указывать на нелегитимную активность.
В одном из проектов с помощью поведенческой аналитики нам удалось выявить подобные факты. Профили поведения строились только в рамках активности по выполнению COPY TO. Зафиксированные аномалии по используемому приложению и логину БД указывали на признаки нелегитимного экспорта данных.
Как это видит DBF. С помощью поведенческой аналитики DBF оценивает контекст и способ выполнения операций экспорта, сопоставляя их с эталонными (легитимными) значениями. Например, выполнение команды COPY TO не через pg_dump свидетельствует либо о запуске нового бизнес-процесса, либо о нелегитимной активности привилегированного пользователя.
Чем опасно. Экспорт данных из БД — первый шаг на пути к эксфильтрации. Данные могут покинуть защищаемый периметр и привести к утечке.
Что делать. Постараться свести операции экспорта данных к регламентированным сценариям и только там, где они действительно нужны. Поставить все операции экспорта данных на контроль комплексом DBF, а также фиксировать отклонения в параметрах выполнения данных операций.
Массовое назначение предопределенных ролей
Частота: 🟣⚪⚪⚪⚪ (редко)
Опасность: 🟣🟣🟣🟣⚪ (высокая)
Предопределенные роли представляют собой предустановленные в СУБД наборы привилегий, предназначенные для удобства управления правами доступа. Некоторые из них содержат потенциально опасный широкий набор привилегий. Например, чтение и запись любых данных, доступ к файловой системе и выполнение программ на сервере БД. Назначение таких ролей пользователям БД должно проводиться только при обоснованной необходимости.
У одного из заказчиков в PostgreSQL мы зафиксировали, не просто единичный случай, а прямо массовое назначение роли pg_read_all_data пользователям структурного подразделения. В этой базе у заказчика хранились в том числе персональные данные. И хотя дальнейшее развитие событий мне неизвестно, но такие инциденты почти всегда говорят о «ленивом» администрировании: «проще выдать всем, чем разбираться».
Как это видит DBF. Контентный анализ запросов к БД в DBF позволяет выявлять признаки назначения предопределенных ролей. Комплекс фиксирует все операции по назначению привилегий пользователям БД, расставляя при этом у событий уровни критичности и повышая таким образом их приоритет.
Чем опасно. Нарушается принцип наименьших привилегий, повышается риск утечки данных.
Что делать. Во-первых, соблюдать принцип наименьших привилегий: назначать пользователям минимально необходимый набор прав доступа к данным. Во-вторых, проводить регулярный аудит прав доступа пользователей к данным в БД. Ну и последнее — настроить алерты в DBF на выполнение операций по назначению «опасных» наборов привилегий пользователям БД.
Почему «всё работает» не значит «всё в порядке»?
Ни одно из этих событий само по себе, конечно, не тянет на громкий инцидент. И всегда найдется чем объяснить походы налево отступления от регламентов: был срочный фикс на проде или просто выгрузили данные вручную «под отчет». Проблем нет, бизнес работает.
Но если посмотреть внимательнее, становится ясно, что аудит превращается в бумаготворчество. В этой «серой зоне» настоящий инцидент спрятать проще всего. Чтобы такого не происходило, и нужен DBF. Он, по сути, работает как своевременный чекап процессов обращения с данными. Если его вовремя не сделать, можно потратить огромные ресурсы на ликвидацию последствий.
