Привет, Хабр! Меня зовут Александр Копылов. Я руководитель направления аутентификации bigdata, участник профсообщества Сбера DWH/BigData.
Сегодня предлагаю обсудить интересное решение из сферы инфобеза для высоконагруженных проектов. Огромное их количество, помимо технических возможностей и разнообразных фич, требует правильного подхода к безопасности. Одно из оптимальных решений ― FreeIPA, о нём и поговорим под катом.
В чём вообще проблема?
На данный момент существует очень ограниченное количество полноценных решений для обеспечения полного комплекса задач безопасности, необходимого крупным компаниям. Сложность в том, что большинство таких решений выполняет только часть нужных функций, при этом у них множество ограничений. Ещё одна проблема ― неполная совместимость с различными разработками, актуальными для энтерпрайза. Кроме того, поддержка таких решений зачастую стоит неоправданно дорого.
Наиболее популярным является ряд проприетарных решений, содержащих множество различных компонентов. Их проблема в том, что они «заточены» под собственную экосистему продуктов компании-разработчика. Крайне редко какое-то из таких решений полностью совместимо с продуктами других вендоров.
Мировая практика показывает, что в сфере высоконагруженных сервисов основной операционной системой является Linux/Unix. Интеграция в подобные ОС имеет ряд сложностей из-за отличий архитектуры по сравнению с наиболее популярной проприетарной ОС. Некоторые вещи через неё невозможно настроить, например политики доступа SUDO и HBAC правила. Возможно, разработчик ОС просто не заинтересован в развитии этого направления из-за сложности разработки.
Перед командой Сбера относительно недавно была поставлена задача найти оптимальное решение среди существующих. Это решение должно было соответствовать таким критериям:
Open-source как гарант отсутствия скрытых элементов.
Возможность разработки собственного форка.
Управление Linux ОС и полная интеграция с Linux.
Компактный, отказоустойчивый и функциональный дистрибутив.
Обилие различных компонентов безопасности.
Поддержка всех возможных протоколов.
Аналог проприетарного решения и поддержка RPC.
Наличие как интерфейса управления, так и консольной реализации.
А вот и решение
По совокупности показателей выбор пал на FreeIPA ― это open-source-проект, который является полным аналогом RH IDM, выполняет те же самые задачи и может работать на небольшом аппаратном ресурсе с огромным количеством транзакций.
Плюс FreeIPA в том, что с его помощью мы получаем возможность управления политиками, доступами к Linux-серверам, возможность ведения собственного LDAP-каталога учётных записей для аутентификации по протоколу Kerberos (на данный момент он один из самых защищённых), собственный DNS-сервер и удостоверяющий сервер для подписи сертификатов. Также инструмент позволяет создавать защищённые доверенные соединения с доменами наиболее популярных проприетарных ОС для объединения гетерогенных систем в большое множество.
Ниже расскажем о существенном объёме работ по «допиливанию» продукта под нужды такой крупной компании, как Сбер, то есть по обеспечению использования FreeIPA в Enterprise-инфраструктуре со всеми критично важными компонентами: мониторинг, нагрузочное тестирование и вспомогательные средства отслеживания аномальной активности.
FreeIPA ― что за зверь?
FreeIPA или IPA ― open-source-набор компонентов для централизованного управления пользователями, их группами, хостами ― (389 LDAP), аутентификацией ― (MIT KDC) и авторизацией в Linux-системах (SSSD). Плюс это ещё и собственный сервер доменных имён (BIND), а также удостоверяющий центр (DOGTAG).
Он разработан для ОС Linux/Unix и сейчас успешно развивается.
FreeIPA ― upstream, который представляет собой community-версию в основном для тестирования и отладки. Тем не менее он способен работать на проектах без требований High Availability и SLA. Серверная реализация может разворачиваться на CentOS, Debian/Ubuntu и некоторых других Linux-дистрибутивах, на которые портирован продукт.
IPA ― клиент-серверное решение, требующее наличия выделенных Linux-серверов с развёрнутым ПО для работы с субъектами безопасности, которые хранятся в реплицируемом службе каталогов LDAP.
Соответственно, любые потребители на любой операционной системе (которые называются IPA-клиентами) могут беспрепятственно взаимодействовать с серверами, получая данные о пользователях, политиках доступа, а также любую другую необходимую информацию для обеспечения безопасной работы.
Полная поддержка разных функциональных модулей безопасности присутствует только в CentOS. В частности, управление доступами к службам внутри Linux или Host-Based Access Control, подсистема OTP, sudo-привилегии.
FreeIPA можно назвать главным аналогом проприетарного решения RH IDM. Несмотря на наличие технической возможности интеграции с Linux-клиентами, обеспечение политик доступа из-за отличий ОС невозможно и сводится к проприетарному стороннему ПО, представляющему скорее небольшую надстройку, чем родственный Linux интерфейс.
IPA разработана исключительно под Linux-системы и поддерживает полностью все необходимые ОС возможности. В то же время, как было сказано выше, можно подключать и клиентов других систем, но с ограничениями.
Благодаря гибкости, универсальности, функциональности и эксклюзивности для Linux данный инструмент был включён в дистрибутив ОС Astra Linux. Дополнив внутренние технологии переработанным сервером FreeIPA, компании удалось получить надёжное и безопасное решение отечественной операционной системы.
Это говорит о широком спектре внедрения, так как проприетарные решения не всегда подходят для задач бизнеса. Управление такими каталогами требует специально обученных инженеров, контракта с вендором и большой бюрократической работы.
Выбор FreeIPA с точки зрения коммерческой нагрузки является наиболее оптимальным и подходящим большинству энтерпрайз-инфраструктур.
Стоит отметить, что далеко не всегда потребители используют все возможности FreeIPA. Чаще всего работают с такими возможностями: аутентификация пользователей и служб, подпись сертификатов для серверов и авторизация (PAM, LDAP и т. п.)
В связи с развитием отрасли больших данных и сопутствующих технологий неоднократно поднимался вопрос о безопасности работы с Big Data. Сообщество разработчиков, которое подарило миру Hadoop-экосистему, остановилось на наиболее надёжном с точки зрения защиты протоколе ― Kerberos. Таким образом определена поддержка проприетарного решения и FreeIPA.
Почему Kerberos?
Это действительно очень надёжное, испытанное десятками лет решение, которое просто работает.
Версии протокола постоянно модернизируются, вносятся новые криптографические алгоритмы и тестируются все кейсы, которые появляются у желающих скомпрометировать хранилища.
Kerberos ― не самое простое в имплементации решение. Но оно является гибким и оптимизированным под высоконагруженные системы, что при наличии других инструментов делает кластеры практически неуязвимыми.
Kerberos поддерживается в проприетарных решениях.
Для обеспечения массовости внедрения для любого языка программирования и в любой open-source- или коммерческий продукт у Kerberos существует общепринятый интерфейс ― GSSAPI.
Помимо Kerberos-аутентификации, IPA-серверы могут управлять жизненным циклом сертификатов: выпускать их автоматизированным и прозрачным для серверов-потребителей способом, но при этом максимально безопасно. Многофункциональность IPA позволила быстро занять нишу популярных BigData-решений.
Но есть и определённый нюанс: из-за особенности работы встроенного модуля аутентификации Java, который первоначально разрабатывался для экосистемы вендорских продуктов и не мог учитывать изменения RFC, он не совместим с MIT Kerberos для большинства задач. А разработчики средних и крупных корпораций в силу незнания и/или непонимания всех стандартов оставляют «коробочный» код, не заменяя на GSSAPI-модуль. К сожалению, это коснулось и ряда крупных продуктов BigData.
К слову, приложения, написанные на языках C++, Python, Go, используют «под капотом» родную библиотеку MIT, поэтому указанная проблема для них неактуальна.
Наша реализация
В Сбере пошли чуть дальше и разработали свой дистрибутив Hadoop, который поддерживает все стандарты и обеспечивает отказоустойчивую и быструю работу с большими данными. Производительность всей системы выросла в 4 раза.
Удалось полноценно интегрировать SDP и с плагинами IPA, многократно упростив процесс разворачивания огромных кластеров для аналитиков и разработчиков.
Изменения полностью легитимные и достаточно подробно описаны. Всё это позволило оптимизировать и сторонние системы, написанные на Java, так как проблема общая.
Кластеры растут с каждым днём, следовательно, появляется вопрос о масштабировании. Возможность горизонтального роста с двусторонней репликацией позволяет беспрепятственно наращивать топологию аналогично самым популярным проприетарным решениям.
Тем не менее в промышленной эксплуатации даже в идеальной среде могут существовать нарушители требований производительности и оптимизации, с которыми необходимо бороться.
Для анализа нарушителей мы разработали отдельный инструмент поиска аномалий и сервис статистики запросов, по которым видна общая карта движения принципалов ― субъектов Kerberos, а также частота их взаимодействия.
Фактически жизнь внутри единого кластера безопасности несёт в себе определённые риски и разногласия между критическими бизнес-задачами и задачами с меньшим приоритетом.
Увеличение количества IPA-серверов в таком случае является неэффективным, так как это попытка устранить симптомы, а не причину. И вовсе не решает проблему влияния со стороны нарушителей.
Использование двух подходов поможет разделить критичность задач:
Приведение к требованиям всех автоматизированных систем без исключения и предоставление экспертизы.
Обеспечение бизнес-кластеров собственными керберизованными структурами.
Первый пункт удалось решить Java-методом с полной поддержкой стандарта протокола Kerberos.
Второй пункт базируется на экспериментальных доверительных отношениях между разными областями Kerberos (лесами ― в терминологии Directory Server). Каждый блок по приоритету живёт в собственном ограниченном пространстве, но при этом имеет возможность обмениваться информацией по безопасному каналу с соседями, если данная необходимость присутствует.
Нагрузочное тестирование + мониторинг Prometheus + модель аномалий
Стоит отметить, что в рамках Enterprise-решения FreeIPA и в community не проводилось нагрузочное тестирование кластера в условиях горизонтального и вертикального масштабирования.
В связи с постоянным ростом количества клиентов и использования ими различного прикладного программного обеспечения была поставлена цель по определению пороговых значений по нагрузке на каждый инстанс FreeIPA в кластере.
В первую очередь необходимо было определить, какую нагрузку эмулировать для максимальной эмуляции реальных условий. Как основное приложение для генерации нагрузки был выбран Jmeter. Дополнительно был проведён анализ необходимых действий и служб, которые будут максимально нагружаться. Сложность заключалась в том, что у IPA 3 наиболее активных сервиса, которые находятся под постоянной нагрузкой ― KDC, LDAP и HTTPD. Получить пороговые значения требуется как под точечной нагрузкой на сервис, так и при фоновой инфраструктурной и прикладной нагрузках. Тем самым был создан план нагрузки, где идут постоянные обращения к HTTPD, эмулирующие работу с web-администратора, чтение LDAP со случайным фильтром, эмулирующие запросы на поиск объекта LDAP при аутентификации, и стандартные запросы Kerberos. Важно было также учесть влияние операций модификации и удаления сущностей LDAP на весь кластер.
Впоследствии были определены 3 основных сценария тестирования:
Операции активного чтения с предварительной аутентификацией.
Операции активной записи/модификации с предварительной аутентификацией.
Операции удаления с предварительной аутентификацией.
Для первичного тестирования был выбран кластер FreeIPA в составе 3 инстансов, при вертикальном масштабировании ресурсы были увеличены вдвое, а для горизонтального был собран кластер из 6 инстансов. Самым сложным оказалось обеспечить активный мониторинг FreeIPA так, чтобы он мог забирать данные и агрегировать их быстрее, чем Zabbix.
Проанализировав несколько систем и способов мониторинга, мы выбрали стек Prometheus+Grafana. Здесь для мониторинга системы используется расширенный набор метрик с помощью node exporter и самописный LDAP exporter для мониторинга LDAP и активности прикладного программного обеспечения. Дополнительно были отрисованы 9 дашбордов в графане для проведения дополнительного анализа результатов в процессе выполнения нагрузочного тестирования.
По результатам тестирования было выявлено, что наиболее успешный способ масштабирования кластера FreeIPA ― вертикальный. Дело в том, что из-за расширения количества инстансов в кластере в случае изменений в структуре LDAP репликация проходит крайне долго, и горизонтальное масштабирование становится неэффективным. Дополнительно к этому на каждую структуру и топологию были рассчитаны пороговые значения по запросам аутентификации и взаимодействию с LDAP и HTTPD.
В процессе развития нагрузочного тестирования и систем мониторинга на базе prometheus был доработан экспортёр и дополнительные дашборды мониторинга для оперативного обнаружения дефектов, связанных с повышением нагрузки на серверы IDM. Дашборды и экспортёр после активных тестов во всех средах были выведены в промышленную эксплуатацию и переданы на сопровождение. Такой механизм мониторинга показал себя как более быстрый и детализированный по сравнению с Zabbix.
Дополнительно к средствам мониторинга мы разработали модель аномалий событий FreeIPA для отслеживания тех событий, которые не может отследить ни одна система мониторинга. На основе данных логов Kerberos и Access модель отслеживает все аномальные проявления, вызванные нагрузкой компоненты FreeIPA. Модель читает весь набор логов за период 15 минут и предоставляет ответ в формате json с результатами всех действий внутри логов Kerberos и Access за этот период.
В результатах на основе Kerberos-логов учитывается количество запросов к kdc, с указанием upn/spn. Так, указывается, кто их вызывает и какое влияние они имеют на каждый сервер FreeIPA, какой динамический и общий рост обнаружен.
В результатах на основе Access-логов учитывается весь объём операций за указанный период с LDAP, их тип, количество и влияние на каталог, среднее время выполнения запроса к LDAP, мера аномальности, которая высчитывается по совокупности всех этих данных.
В конечном счёте FreeIPA стала полноценным Enterprise-решением для Сбера с огромным каталогом пользовательских, хостовых и сервисных клиентов. С имеющимися в составе полноценной обвязкой мониторинга и наборами специнструментов обслуживания и сопровождения. Отметим также, что, как и у любого другого продукта, у FreeIPA есть «точки роста», но о них мы расскажем в следующих статьях.
На этом всё. Традиционно ― если у вас есть вопросы, добавляйте их в комментарии, а мы ответим. Если в вашей компании есть собственные кейсы, связанные с описанным в статье решением, расскажите о них, пожалуйста.
Комментарии (4)
AlexGluck
20.07.2022 19:01-2Заббикс имеет пуш модель и высокочастотный мониторинг с частотой опроса 1 секунда (меньше не помню), активный агент. Прометей работает через пул модель и запросы с частотой 1 секунда на все метрики потребуют больше вычислительных ресурсов. Может кто нибудь из технических специалистов, квалифицированных, раскрыть тему мониторинга из того бреда, что написано в статье?
DenShark
> Open-source как гарант отсутствия скрытых элементов.
Это не гарантия закладок и скрытых, или не очень скрытых элементов по результату начала СВО