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

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

Чтобы сделать наши курсы по 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
Поиск по сайту