Как построить свой OAuth с аутентификацией и авторизацией для Kafka: кейс BlackRock

Автор Категория , ,
Как построить свой OAuth с аутентификацией и авторизацией для Kafka: кейс BlackRock

Чтобы сделать наши курсы по Apache Kafka еще более полезными, сегодня мы поговорим про базовые и расширенные возможности обеспечения информационной безопасности этой Big Data платформы. А в качестве практического примера разберем кейс международной финтех-компании BlackRock, которая разработала собственное security-решение для Kafka на базе протокола OAuth и серверов единого доступа KeyCloak.

 

Еще раз о безопасности Apache Kafka: 3 базовых возможности

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

Основными функциями, которые отвечают за безопасность Kafka, являются следующие [1]:

  • SSL/TLS-шифрование данных на лету, позволяющий шифровать данные между отправителями (producer) и потребителями (consumer) Kafka. Это шифрование решает проблему атаки «человек посередине», защищая данные по умолчанию в PLAINTEXT от прочтения маршрутизаторами по пути передачи данных в сети интернет. При использовании SSL только первая и последняя машина могут расшифровать отправляемый пакет. Побочным эффектом этой безопасности является незначительное снижение производительности, т.к. теперь ЦП клиентов и брокеров Kafka теперь также используется для шифрования и дешифрования пакетов. Примечательно, что применение более поздних версий Java и самой Apache Kafka существенно снижают эти накладные расходы.
  • SSL/SASL-аутентификация, которая обеспечивает проверку продюсеров и потребителей в Kafka-кластере, что необходимо для предоставления им соответствующих прав (авторизаций) для доступа к данным. Суть двухсторонней SSL-аутентификацией в том, что брокеры Kafka проверяют подлинность клиентов по наличию сертификатов, подписанных центром сертификации. SASL (Simple Authorization Service Layer) механизм аутентификации отделен от протокола Kafka и поддерживает несколько вариантов (PLAINTEXT, SCRAM, GSSAPI на базе Kerberos, SASL-расширение с конфигурацией обратных вызовов, OAUTHBEARER). О особенностях SSL/SASL-аутентификация в Apache Kafka мы писали здесь на примере кейса тревел-площадки Booking.com.
  • ACL-авторизация, когда после проверки подлинности клиентов брокеры Kafka обращаются к спискам управления доступом (ACL, Access Control Lists), чтобы определить, допущен (авторизован) ли конкретный клиент на запись или чтение в какой-либо топик. Подробнее о том, как работает ACL-авторизация в Apache Kafka мы рассказывали здесь и здесь.

Итак, по умолчанию служба безопасности Kafka использует цифровые сертификаты аутентификации и проприетарные ACL-списки для авторизации. Но эти базовые возможности не покрывают всех потребностей современного бизнеса и не соответствуют последним стандартам корпоративной безопасности. Поэтому инженеры данных и администраторы Big Data кластеров международной финтех-компании BlackRock разработали собственное комплексное и масштабируемое решение для обеспечения безопасности Apache Kafka с минимальной нагрузкой на разработчиков. О том, что именно оно собой представляет, мы поговорим далее.

Комбо аутентификации и авторизации на корпоративном уровне: security-библиотека OAuth

Изначально потребность в расширенных настройках безопасности Apache Kafka у BlackRock возникла в рамках проекта Cachematrix – веб-платформы управления ликвидностью, одобренной 25 крупными глобальными банками и компаниями по управлению активами. Проект имеет многопользовательскую архитектуру, которая требует строгой изоляции обработки данных и контроля доступа к функциям и ресурсам со стороны клиента. Для этого необходимо комплексное и масштабируемое решение с минимальной нагрузкой на разработчиков, включая следующие возможности [2]:

  • детальный контроль безопасности для всех ресурсов системы и приложений в Kafka;
  • прозрачность элементов управления для разработчиков;
  • централизованное управление элементами во время развертывания или в процессе эксплуатации реальной системы (production) с разделением обязанностей;
  • поддержка срока действия и обновления учетных данных для длительных процессов без простоев.

Для реализации этих требований специалисты BlackRock разработалии собственную библиотеку на базе стандартной структуры безопасности OAuth, которое обладает следующими функциями и характеристиками:

  • поддержка детальной авторизации и аутентификации для ресурсов Kafka в многопользовательской или однопользовательской среде;
  • изоляция обработки данных разных клиентов в мультитенантном приложении или отделение одного приложения от другого в общем экземпляре;
  • прозрачность для кода приложения с возможностью добавления к существующему коду при минимальной конфигурации;
  • возможность повторного использования в различных Kafka-приложениях.

Основой OAuth-библиотеки BlackRock является SASL-платформа самой Кафка и технология единого входа в open-source сервере KeyCloak, который обеспечивает регистрацию пользователей, авторизацию через соцсети, выдачу JSON веб-токенов подлинности аккаунтам, двухфакторная аутентификацию, интеграцию со службами каталогов (LDAP-сервером), брокер Kerberos и другие функции безопасного управления доступом [3].

Apache Kafka предоставляет платформу на основе SASL OAUTHBEARER, который входит в Kafka для реализации пользовательской аутентификации и позволяет разработчикам подключать более сложные службы безопасности корпоративного уровня. OAuth – это общепринятый протоколом безопасности, позволяя сторонним приложениям получать токен для доступа к службе ресурсов. Срок действия токена истекает в течение определенного срока. Когда токен истекает, приложение должно запросить новый токен, чтобы оставаться аутентифицированным. Таким образом, OAuth соответствует требованиям BlackRock для аутентификации и авторизации на корпоративном уровне.

Серверы OAuth позволяют использовать несколько типов учетных данных для защиты приложения. В решении BlackRock используется тип предоставления учетных данных клиента, который обрабатывает взаимодействие между сервисами. Клиент OAuth – это приложение, зарегистрированное на сервере OAuth, например, приложение Kafka с запущенным продюсером, который отправляет данные в топик. В этом случае санкционированный доступ предоставляется следующим образом [2]:

  • идентификатор и секрет клиента позволяют получить ему токен с сервера OAuth;
  • клиент делает запрос к ресурсу и передает этот токен вместе с запросом;
  • ресурс аутентифицирует запрос, проверяя токен на сервере OAuth;
  • после аутентификации ресурс определяет разрешения на доступ в токене для авторизации, отправляя токен авторизатору для проверки разрешений;
  • для авторизации библиотека переопределяет Authorizer для использования разрешений на доступ OAuth;
  • гибкая авторизация выполняется с использованием механизма ACL-списков и возможностей KeyCloak.

Таким образом, решение BlackRock объединяет аутентификацию и ACL-авторизацию в едином рабочем процессе на централизованном сервере OAuth. Исходный код этой security-библиотеки доступен для всеобщего использования на Github [4].

Apache Kafka Security, SASL Kafka, Autentification and Authorization Apache Kafka
Аутентификация и авторизация в Apache Kafka и их расширение с библиотекой BlackRock

Завтра мы продолжим разбирать опыт BlackRock и рассмотрим на примере их финтех-платформы, почему в микросервисной архитектуре особенно важна конечная согласованность и как ее достичь с помощью Apache Kafka Streams.

Больше подробностей по обеспечению безопасности, разработки распределенных приложений потоковой аналитики больших данных и администрирования кластеров Apache Kafka вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://medium.com/@stephane.maarek/introduction-to-apache-kafka-security-c8951d410adf
  2. https://medium.com/blackrock-engineering/utilizing-oauth-for-kafka-security-5c1da9f3d3d
  3. https://ru.wikipedia.org/wiki/Keycloak
  4. https://github.com/kafka-security/oauth