FreeIPA as an Enterprise solution

https://habr.com/ru/companies/sberbank/articles/677900/

Привет, Хабр! Меня зовут Александр Копылов. Я руководитель направления аутентификации 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?

1. Это действительно очень надёжное, испытанное десятками лет решение, которое просто работает.

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

3. Kerberos ― не самое простое в имплементации решение. Но оно является гибким и оптимизированным под высоконагруженные системы, что при наличии других инструментов делает кластеры практически неуязвимыми.

4. Kerberos поддерживается в проприетарных решениях.

5. Для обеспечения массовости внедрения для любого языка программирования и в любой 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-серверов в таком случае является неэффективным, так как это попытка устранить симптомы, а не причину. И вовсе не решает проблему влияния со стороны нарушителей.

Использование двух подходов поможет разделить критичность задач:

1. Приведение к требованиям всех автоматизированных систем без исключения и предоставление экспертизы.

2. Обеспечение бизнес-кластеров собственными керберизованными структурами.

Первый пункт удалось решить Java-методом с полной поддержкой стандарта протокола Kerberos.

Второй пункт базируется на экспериментальных доверительных отношениях между разными областями Kerberos (лесами ― в терминологии Directory Server). Каждый блок по приоритету живёт в собственном ограниченном пространстве, но при этом имеет возможность обмениваться информацией по безопасному каналу с соседями, если данная необходимость присутствует.

Нагрузочное тестирование + мониторинг Prometheus + модель аномалий

Стоит отметить, что в рамках Enterprise-решения FreeIPA и в community не проводилось нагрузочное тестирование кластера в условиях горизонтального и вертикального масштабирования.

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

В первую очередь необходимо было определить, какую нагрузку эмулировать для максимальной эмуляции реальных условий. Как основное приложение для генерации нагрузки был выбран Jmeter. Дополнительно был проведён анализ необходимых действий и служб, которые будут максимально нагружаться. Сложность заключалась в том, что у IPA 3 наиболее активных сервиса, которые находятся под постоянной нагрузкой ― KDC, LDAP и HTTPD. Получить пороговые значения требуется как под точечной нагрузкой на сервис, так и при фоновой инфраструктурной и прикладной нагрузках. Тем самым был создан план нагрузки, где идут постоянные обращения к HTTPD, эмулирующие работу с web-администратора, чтение LDAP со случайным фильтром, эмулирующие запросы на поиск объекта LDAP при аутентификации, и стандартные запросы Kerberos. Важно было также учесть влияние операций модификации и удаления сущностей LDAP на весь кластер.

Впоследствии были определены 3 основных сценария тестирования:

1. Операции активного чтения с предварительной аутентификацией.

2. Операции активной записи/модификации с предварительной аутентификацией.

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 есть «точки роста», но о них мы расскажем в следующих статьях.

На этом всё. Традиционно ― если у вас есть вопросы, добавляйте их в комментарии, а мы ответим. Если в вашей компании есть собственные кейсы, связанные с описанным в статье решением, расскажите о них, пожалуйста.