# FreeIPA as an Enterprise solution

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

![](/files/gIEhcSp85zHIFXX16xgT)

Привет, Хабр! Меня зовут Александр Копылов. Я руководитель направления аутентификации bigdata, участник профсообщества Сбера DWH/BigData.

Сегодня предлагаю обсудить интересное решение из сферы инфобеза для высоконагруженных проектов. Огромное их количество, помимо технических возможностей и разнообразных фич, требует правильного подхода к безопасности. Одно из оптимальных решений ― FreeIPA, о нём и поговорим под катом.

![](/files/arMVvUBbmBIclNU60HRK)

## В чём вообще проблема?

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

Наиболее популярным является ряд проприетарных решений, содержащих множество различных компонентов. Их проблема в том, что они «заточены» под собственную экосистему продуктов компании-разработчика. Крайне редко какое-то из таких решений полностью совместимо с продуктами других вендоров.

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

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://book.konstantinsecurity.com/readme/architect/identity-and-access-management-idm/freeipa-as-an-enterprise-solution.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
