Когда в начале года иностранные производители средств защиты покинули отечественный рынок и Россия оказалась тем самым одиноким китом в океане кибербезопасности, на нашу команду буквально обрушился шквал входящих запросов от компаний на подбор отечественных решений на замену импортным. Тестирование решений мы обычно проводим на стенде, и с марта их количество и качество сильно увеличились. Не обошла эта ситуация и системы защиты баз данных, также известные как продукты класса Database Activity Monitoring, или DAM.

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

В качестве вступления

В прошлом году мы уже тестировали «Гарда БД» версии 4.17.1 с версией агента 2.7 и системой управления базами данных (СУБД) MS SQL. Тогда обнаружили несколько проблем: например, при прямом подключении к СУБД с установленным на сервере агентом в журнале событий продукта не отражался логин локальной учетной записи операционной системы и СУБД, а также не работала блокировка доступа к БД MS SQL с использованием агента.

В этом году для проведения испытаний на стенде мы использовали версию продукта 4.21.0 и агента 2.11. Тестирования чаще всего проводили на трех СУБД: Oracle, MS SQL Server и PostgreSQL. В статье сосредоточимся на последней, так как с ней была связана большая часть запросов. Детали подготовки стенда к тестированию опустим, отметим только, что стенд состоял из сервера управления и двух анализаторов.

Проверка №1. Контроль БД в режиме реального времени

«Гарда БД» перехватывает трафик со SPAN-порта и получает данные с установленного на сервере СУБД агента. Есть предустановленные политики мониторинга, ниже перечислены некоторые из них:

Всего в системе после развертывания доступно 35 политик, предназначенных для перехвата различных событий, но не все предустановленные политики можно использовать сразу «из коробки». Часть приходится дорабатывать. Для проведения дальнейших тестов мы подготовили политики для перехвата следующих нетиповых событий:

1. Доступ под заблокированной УЗ.

2. Доступ под несуществующей УЗ.

3. Попытки перебора паролей от УЗ администратора (ошибки аутентификации).

4. Попытки доступа к системным таблицам и представлениям.

5. Смена паролей для УЗ пользователей.

6. Повышение/изменение привилегий пользователей БД.

7. Разблокировка учетных записей.

8. Создание дампов БД.

9. Выгрузка большого объема данных из БД.

Все отправленные к СУБД запросы и полученные ответы были зафиксированы в журнале событий, часть из них на скриншотах ниже:

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

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

Ниже результат запроса в виде готового списка.

Это дает нам возможность видеть сразу все интересующие нас УЗ, имеющие доступ к БД. В зависимости от задачи запрос можно менять и формировать список по тем критериям, которые вам нужны, например по назначенным ролям.

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

Кстати, в прошлогоднем тестировании с СУБД MS SQL мы обнаружили проблему с фиксацией УЗ ОС и УЗ СУБД. Оказалось, что проблема крылась в декодировании аутентификационной информации при перехвате запросов к MS SQL. Эта информация передается в протоколе в зашифрованном виде. Теперь в продукте есть возможность импорта ключа шифрования с сервера MS SQL. Учитывая постоянную смену ключа, нужно регулярно повторять процедуру его экспорта с сервера MS SQL с импортом в «Гарда БД». В агенте продукта для этого предусмотрена функция автоматического импорта.

Проверка № 2. Блокировка несанкционированного доступа

Блокировки проверяли на агентах и в сценарии, когда доступ к БД осуществляется под привилегированными стандартными УЗ (как ОС, так и БД) или когда доступ к БД под привилегированными УЗ возможен только с определенных IP-адресов или сетей. Правила получились такими:

Все успешные попытки подключений к БД, не попадающие под правила блокировок, мы видим в журнале событий:

Еще в системе есть журнал по блокировкам на агенте, в котором можно увидеть, по какому правилу происходили блокировки:

Со стороны пользователя блокировки выглядят вот так:

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

Проверка № 3. Обнаружение БД в сети

При обработке SPAN-трафика, трафика от агентов и при сканировании сети «Гарда БД» автоматически обнаружила базы данных и отразила их в соответствующем разделе. По обнаруженной БД доступна следующая информация: IP-адрес, порт, протокол (он же тип СУБД), используемый анализатор и наличие агента. Через несколько часов БД автоматически добавилась в настроенные ранее политики согласно правилам автодобавления БД на контроль.

В каждой политике есть возможность добавить не все найденные БД, а только соответствующие определенному шаблону: подсеть, порты и тип СУБД.

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

Проверка № 4. Сканирование на уязвимости

Сканирование проводили по предустановленным политикам поиска уязвимостей, в результате уязвимости были обнаружены.

Есть механизм для выявления уязвимостей, связанных с некорректными/небезопасными настройками: наличие избыточных прав доступа к небезопасным процедурам, настройки аудита, настройки аутентификации и другие. Чтобы провести проверку, мы отправляли тестовый SQL-запрос и анализировали ответ. При этом указывали критерий успешности – наличие определенного значения в каком-либо поле ответа, количество строк в ответе (больше/меньше/равно/не равно) и др.

Этот механизм пригодится для выполнения кастомных проверок. Например, если мы считаем недопустимым нарушением факт наличия заблокированных (деактивированных) учетных записей, то можем задать такую пользовательскую проверку:

select r.rolname, r.rolcanlogin from pg_catalog.pg_roles r where r.rolname !~ '^pg_' and r.rolcanlogin = 'f' order by 1;

Критерий успешности – количество строк в ответе = 0

Если запрос вернет «Гарда БД» хотя бы одну учетную запись, будет зафиксировано, что проверка не пройдена.

Проверка № 5. Анализ событий

В «Гарда БД» предустановлен набор отчетов с информацией по количеству запросов и объему ответов, неудачным авторизациям, ошибкам в запросах и т. д. Графические отчеты интуитивно понятные. Собственноручная настройка отчетов с графическим представлением не вызвала у нас каких-либо сложностей.

Отчеты позволили провести быстрый анализ событий на предмет поиска логинов с неуспешными попытками аутентификации:

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

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

Порадовало, что в продукте виден полный синтаксис отправленного к БД запроса и возвращаемые ответы:

Проверка № 6. Поведенческий анализ

С помощью написанных SQL-скриптов и созданных задач в течение семи дней мы сформировали типовой профиль УЗ по запросам к БД. После заморозки обучения сделали нетиповые запросы. «Гарда БД» выявила все отклонения и аномалии в статистической картине доступа к БД и отразила их в специальном разделе.

Проверка № 7. Управление правами доступа

В разделе «Настройки — Пользователи и роли» мы создали учетные записи, настроили роли, задали права доступа к разделам интерфейса (Главное, Политики, Данные, Сканирование, Профилирование, Агенты, Отчеты, Архивы, Журналы, Настройки).

Все работает — все разрешения и ограничения учетных записей были проверены.

Проверка № 8. Система оповещения

Оповещения мы настроили через специальный шаблон. На указанную почту, в MaxPatrol SIEM, QRadar и Splunk пришли оповещения о событиях работы «Гарда БД» и событиях безопасности по настроенным ранее политикам.

Сводная таблица с результатами тестирования основной функциональности решения «Гарда БД»

Выводы

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

Авторы:

Михаил Топкасов, руководитель направления комплексной безопасности центра «Solar Интеграция» компании «РТК-Солар»

Никита Игонькин, руководитель направления по сервисному партнерству центра «Solar Интеграция» компании «РТК-Солар»