Привет Хабр! Меня зовут Дмитрий Ларин, я руководитель продуктового направления по защите баз данных группы компаний «Гарда», отвечаю за наш продукт «Гарда DBF». Это система класса DAM/DBF (Database Activity Monitoring/Database Firewall), она предназначена для защиты данных, хранящихся в СУБД. Но в контексте этой статьи важно то, что продукт позволяет перехватывать трафик обращений не только к базам данных, но и к брокерам сообщений. Сегодня разберем метод обеспечения безопасной работы брокеров сообщений на примере «Гарда DBF» и Apache Kafka. Раскрою:
Растущая сложность ИТ-решений и переход на распределенную архитектуру приводит к усложнению обмена информацией между системами и их компонентами. Упорядочить и упростить взаимодействие всех систем помогают брокеры сообщений, такие как Apache Kafka, RabbitMQ и другие. Они выполняют роль посредников в обмене данными между различными компонентами системы, что делает ИТ-инфраструктуру более гибкой, масштабируемой и надежной.
Брокер Apache Kafka является ключевым компонентом в инфраструктуре многих компаний и обеспечивает передачу большого объема информации в реальном времени, в том числе конфиденциальной. Однако, при его работе встают вопросы защиты от уязвимостей, противодействия утечкам данных и несанкционированному доступу к информации. В статье разберем принцип работы и проблемы безопасности Kafka, способы применения продукта для защиты БД и для брокеров сообщений, и возможности «Гарда DBF» по защите данных, передаваемых через брокер.
Материал будет полезен как техническим специалистам, работающим непосредственно с Apache Kafka и системами безопасности, так и руководителям, заинтересованным в эффективном и безопасном управлении потоками данных. В частности, системным администраторам и DevOps инженерам, разработчикам, интегрирующим Kafka приложения, тем, кто отвечает за настройку, развертывание и поддержку инфраструктуры на базе брокера, а также ИБ-специалистам.
Принцип работы Apache Kafka и проблемы безопасности
Apache Kafka – один из самых популярных брокеров сообщений. Высокая масштабируемость, устойчивость, производительность и гибкость делают Kafka привлекательным решением для компаний в различных сферах. В отличии от обычных СУБД, которые предназначены для хранения и управления статичными данными, Kafka – это система обработки потоков данных, которая позволяет передавать, хранить и обрабатывать их в реальном времени.
Kafka разделяет данные на топики и партиции, в которых сообщения записываются и читаются продьюсерами и консьюмерами:
продьюсер – это компонент или приложение, которое отправляет (публикует) сообщения в одну или несколько тем (топиков) Kafka;
консьюмер – это компонент или приложение, которое читает (потребляет) сообщения из тем (топиков) Kafka.
Упрощенно процесс обработки сообщений выглядит следующим образом:
1. Продьюсер отправляет сообщение в Топик. Сообщение содержит значение и ключ, который определяет, в какую партицию попадет сообщение.
2. Консьюмер пытается забрать сообщение. Если консьюмер не сможет прочитать сообщение из Kafka, а это может произойти по нескольким причинам, то и последствия будут зависеть от характера проблемы.
3. Консьюмер обрабатывает сообщение и сообщает брокеру о результате.
4. В случае ошибки сообщение не удаляется из партиции и доступно для повторного чтения консьюмерами.
Выступая в роли посредника и агрегатора информации, в том числе конфиденциальной, Kafka становится узким местом в обеспечении безопасности данных. Конечно, в брокере предусмотрены встроенные инструменты для повышения уровня защищенности (аутентификация подключений, шифрование данных, авторизация операций), но они не покрывают всех уязвимостей. Например, случаи превышения своих полномочий администраторами систем. Для дополнительного обеспечения безопасности данных применяются системы класса DAM/DBF.
Как продукт для защиты БД можно применять и для брокеров сообщений
Программный комплекс «Гарда DBF» относится к системам класса DAM/DBF и позволяет перехватывать трафик обращений не только к базам данных, но и к брокерам сообщений. Комплекс обеспечивает безопасность, мониторинг и независимый аудит операций с базами данных и бизнес-приложениями. Использование систем класса DAM/DBF может быть полезным в связке Kafka, например, для:
аудита доступа к данным – «Гарда DBF» может помочь в выявлении несанкционированных попыток доступа и обеспечении соответствия требованиям безопасности;
аудита действий пользователей – «Гарда DBF» позволяет вести детализированный аудит операций, связанных с Kafka, что может быть важно для понимания, кто и как использует данные.
Для контроля действий пользователей и выявления подозрительных операций в «Гарда DBF» используются специальные правила – политики. Контроль за обращениями к Kafka можно настроить несколькими способами:
1. При помощи политики мониторинга. Действия пользователей перехватываются в соответствии с заданными критериями.
2. При помощи политики профилирования. Комплекс выявляет отклонения от моделей нормального поведения пользователей.
Контроль с политикой мониторинга
При использовании политики мониторинга необходимо настроить критерии, по которым будут перехватываться действия пользователей. В разделе Политики создадим новую политику мониторинга и выберем сервер с Kafka в поле Базы данных. Далее настроим Критерии для обработки нескольких возможных уязвимостей:
Перехват данных неизвестными консьюмерами:
По критерию IP адрес:порт. Добавим известный адрес консьюмера (например, 192.168.37.77:9092) в Исключения. Политика сработает для любого IP-адреса, который будет отличаться от разрешенного;
По критерию Логин БД. В этом случае в исключения добавлена известная нам учетная запись – rdkafka. Политика будет фиксировать доступ с использованием любых других учетных записей;
Передача данных, содержащих конфиденциальную информацию. Например, при помощи критерия Ключевое слово и регулярного выражения содержимое запросов и ответов будет проверяться на наличие данных банковских карт;
Контроль с политикой профилирования
Профилирование использует эталонные и статистические значения для выявления отклонений и аномалий на основе существующих профилей. Это значит, что при правильной настройке защитный комплекс с легкостью обнаружит нестандартное поведение как продьюсера, так и консьюмера Kafka.
профиль – набор параметров, описывающих нормальное поведение пользователя с конкретным объектом. На основе профилей выявляются отклонения и аномалии;
отклонения – это нехарактерное действие пользователя в базе данных. Например, подключение с IP-адреса, который отсутствует в Профиле;
аномалия – это несоответствие статистики поведения пользователей по отношению к настроенной норме. Аномалии выявляются на основе статистических данных. Для их выявления важно ответить на вопрос, сколько или какое количество событий считается аномальным.
Построить профили можно с использованием вкладки Аналитика в политике мониторинга или в разделе Профилирование → Обучение. При настройке можно задать:
идентификатор, который однозначно определяет пользователя;
контролируемые параметры, например, IP-адрес и используемое приложение;
глубину подсчета средних значений;
автоматическую заморозку профиля после обучения;
выявление отклонений, аномалий за интервал и статистических аномалий;
отправку уведомлений в SIEM и на email.
Построение профилей занимает время, но позволяет выявлять аномальное поведение, например, резкий рост количества или объема запросов и ответов, частые попытки авторизации с разных IP-адресов. Создание эталонного профиля помогает ускорить настройку других профилей.
Практика применения «Гарда DBF»
Проиллюстрирую реальным случаем выявления утечки данных клиентов в одном из банков.
Несмотря на контроль со стороны службы ИБ, персональные данные клиентов все равно попадали в руки злоумышленников. Благодаря внедрению «Гарда DBF» и настройке политик профилирования были выявлены обращения к Apache Kafka от неизвестного ПО.
В соответствии с настройками, защитный комплекс направил на электронную почту сотрудника ИБ оповещение о попытках несанкционированного доступа к чувствительным данным с указанием IP-адреса, откуда отправлялись обращения, и сохранил доказательства для ретроспективного анализа. Это помогло прекратить утечку и перепродажу персональных данных клиентов третьим лицам.
Другие возможности Гарда DBF
Возможности «Гарда DBF» не ограничиваются работой с брокерами сообщений, продукт предназначен для защиты баз данных. Например, он может:
проводить независимый аудит операций в режиме реального времени;
блокировать нелегитимные локальные и сетевые запросы к серверам БД. Для этого используется специальное ПО − агент контроля подключений;
автоматически выявлять новые базы данных, а также реагировать на изменения настроек имеющихся баз;
сканировать БД на уязвимости (неустановленные патчи, учетные записи с простыми паролями и т.д.);
хранить информацию для проведения ретроспективного анализа;
контролировать запросы к бизнес-приложениям (таким как ERP, CRM, и так далее);
формировать отчеты по всем событиям безопасности и операциям пользователей СУБД;
уведомлять о событиях информационной безопасности через отправку данных в SIEM или на email.
Заключение
Программный комплекс «Гарда DBF» решает проблему защиты данных в системах, которые используют Apache Kafka для обмена сообщениями:
позволяет обнаруживать и блокировать несанкционированные попытки доступа к сообщениям Kafka, включая действия неизвестных консьюмеров или использование неизвестных учетных записей. Это помогает предотвратить утечку конфиденциальной информации, например, данных клиентов;
отслеживает действия продьюсеров и консьюмеров в Kafka, фиксирует все операции и сохраняет данные для ретроспективного анализа. Это позволяет точно определить источник утечки или злоупотреблений, а также собрать доказательства для дальнейшего расследования;
автоматически отправляет уведомления о нарушениях в SIEM-системы или по электронной почте, позволяя службам информационной безопасности оперативно реагировать на угрозы.
Таким образом, «Гарда DBF» обеспечивает дополнительный уровень защиты для Apache Kafka, минимизируя риски утечек данных, повышая прозрачность операций и предоставляя инструменты для проактивного контроля и предотвращения угроз.