Александр Боковой:
«То, что раньше считалось корпоративным решением и стоило огромных денег, доступно не просто отдельным энтузиастам, а всему спектру пользователей»

Александр Боковой, ведущий инженер – разработчик программного обеспечения Red Hat

Об автоматизации идентификации пользователей, управлении правами и безопасности, а также развитии Open Source-сообщества рассказывает ведущий инженер – разработчик программного обеспечения Red Hat Александр Боковой

– Вы занимаетесь автоматизацией безопасности, это ваше основное направление. Какие свободные проекты по этим тематикам сейчас наиболее востребованы? И что предлагает компания Red Hat в этой сфере?

– Я занимаюсь вопросами автоматизации, тем, что по-английски называется Identity Management, то есть управление ресурсами пользователей, групп, машин, политиками доступа к этим ресурсам, интеграцией с другими операционными системами.

С точки зрения протокольной части, это такой большой суп из LDAP, Kerberos, SMB-протокола и многого другого. Все это входит в поддержку криптографии на основе публичных ключей и интеграцию между огромным количеством компонентов в операционных системах.

Я работаю над проектом FreeIPA уже больше семи лет и хочу сказать, что делать там еще много чего, есть что улучшить и модернизировать.

Какие проекты можно считать «горячими», то есть популярными, активными, достаточно сложно сказать, потому что в области управления ресурсами сложилась интересная ситуация.

Многие этими проектами пользуются, но немногие о них говорят, потому что, как правило, проекты Identity Management, FreeIPA, масса решений на основе LDAP-сервера фактически используются для того, чтобы создать сердце инфраструктуры организации. И мало кто готов открыто говорить, как устроена инфраструктура их организации. Люди считают, что, рассказывая об этом публично, они фактически дают шанс потенциальному атакующему.

Потому мы имеем такую парадоксальную ситуацию, когда вроде бы то, что мы делаем, востребовано, но – о нем не говорим.

В этом году первый раз мы организовали Developer Group на FOSDEM-конференции по вопросам менеджмента более широким, не только связанным с операционными системами, а и с бизнес-системами, с системами интеграции с веб-приложениями. И нам для работы выделили самую маленькую комнату на 50 человек в Свободном университете Брюсселя.

У нас было 50 человек внутри и 150 человек снаружи, желающих попасть внутрь. Я чувствовал себя неприятно, когда должен был отказывать людям, потому что есть правила пожарной безопасности, и я их не могу нарушить, потому что иначе всю конференцию сорву. Надо сказать, что был огромный интерес со стороны всех пользователей. Доклады записаны, они доступны на сайте FOSDEM, так что рекомендую читателям журнала обратить на них внимание.

Что касается FreeIPA, он возник как проект в 2007 году. Нам уже 11 лет. Мы рискнули попытаться собрать целое из кусочков и перевернуть ситуацию, парадоксальную опять-таки, которая возникла, когда Microsoft использовала технологии, отработанные в UNIX, опять же криптографию на основе публичных ключей и реализовала для себя Active Directory в 1997-1998 годах, то есть фактически построив то, что сейчас доминирует в корпоративных средах с использованием системы Windows на основе технологий, созданных кровью в UNIX-среде.

И долгое время были попытки повторить, что-то похожее сделать, реализовать, что позволяло бы также интегрировать UNIX, в целом системы, используя те же подходы. Но во многом это строилось на «давайте сделаем красивый интерфейс к LDAP, красивый интерфейс к Kerberos», настраивать все эти отдельные приложения было достаточно сложно, было очень много запутанной документации.

Red Hat решил дело упростить. Не только потому, что так хотели пользователи. На самом деле, если пользователь читает документацию и не может поставить приложение, например, на сервер Kerberos, это означает нагрузку на систему поддержки Red Hat. Даже если есть хорошие книги по теме, это не означает, что будут хорошая документация, хорошее понимание утилит и так дальше.

Поэтому Red Hat тогда решил создать проект, который бы автоматизировал большую часть этой работы на серверной стороне, и параллельный проект для автоматизации использования на стороне клиента.

Один из проектов – это FreeIPA, второй проект – SSSD. SSSD – на клиентской стороне, интегрирует все, что требуется от клиента при обращении к серверу, для того, чтобы получать информацию о пользователях, о группах, брать с сервера определенные политики, по которым эти пользователи могут обращаться к определенным ресурсам, имеющимся в машине.

И за 10-11 лет дело развилось в достаточно гибкую систему, которая позволяет для машинной основы Linux и SSSD за минимальный промежуток времени интегрироваться в сложную корпоративную среду. Но не только на стороне клиента, на стороне сервера, скажем, типичная настройка серверов RIP состоит в том, что мы запускаем утилиту установки и через шесть минут имеем настроенный Kerberos, KDC, LDAP-сервер со всеми схемами, пригодными для использования вPOSIX-среде для пользователей, групп, машин и т.д. И система управления: через веб-интерфейс или утилиту командной строки. То есть одна машина – шесть минут.

– Это – идеальный результат…

– Все это построено на основе LDAP-сервера 389-DS. В свое время Red Hat купил его у IPlanet, а IPlanet купила еще у кого-то; тот самый первоначальный, ни с кем не делимый, сервер был серверной стороной большого проекта, клиентской стороной которого был браузер Mozilla, Netscape-навигатор тогдашний, который потом стал браузером, а в 2003-2004-м – Firefox. То есть на самом деле все эти технологии связаны.

Часть ребят, которые работают над проектом FreeIPA, различными его компонентами, работали в Netscape в 1997-1998 годах и до сих пор работают в Red Hat над теми же самыми компонентами. Это ответ на не заданный вопрос о том, а интересно ли этим заниматься десятилетиями.

Сервер LDAP 389-DS – под свободной лицензией, он позволяет реплицироваться многократно, и все эти серверы между собой обмениваются данными. Поэтому решается вопрос дублирования и горячей замены, поскольку все они работают в стиле Active-Active. Не нужно поднимать, когда кто-то упал, потому что его и так поднимут.

А переключения между серверами реализованы на стороне клиента. То есть когда клиент SSSD видит, что какой-то из серверов, с которым он работает, упал, он просто использует механизмы обнаружения активных серверов и переключается на них.

Система внутри достаточно сложна, но снаружи мы пытаемся сделать ее выглядящей попроще, чтобы типовые операции выполнялись одной-двумя командами. Заказчики Red Hat это увидели и используют.

Ситуация была довольно интересной. Вначале Red Hat считал, что разработку можно продавать как отдельный продукт, но потом оказалось, что заказчики не очень понимали, за что они платят. И корпоративное поддерживание Red Hat, и реализация FreeIPA, которая называется «Red Hat enterprise identity management», просто являются частью подписки на Red Hat Enterprise Linux. То есть никаких дополнительных средств не нужно использовать. Поэтому пользователи это оценили. Настолько, что мы сейчас даже видим ситуацию, когда большие корпорации разворачиваются вначале в тестовых режимах, а потом полноценно на Red Hat Enterprise Linux identity management.

Надо сказать, что у нас достаточно активное, живое комьюнити пользователей, немного менее активное внешнее комьюнити разработчиков, но в последний год появились разработчики из России, которые активно пытаются добавлять функционал, который им интересен, скажем, более полноценную локализацию на русский язык.

– Чем вызван всплеск интереса к данной теме у российских разработчиков?

– Свободных решений Identity Management не так и много. Люди либо вынуждены писать свое ПО и дальше его поддерживать, либо вливаться в существующие проекты. Один из способов – это вливание в разработку FreeIPA.

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

Я один из разработчиков Samba. С 2003 года я в Samba Team. Я вижу то же самое, происходящее с Samba AD. Но там другая страна, там Франция, не Россия. Очень активно действуют государственные органы. Они претворяют в жизнь простую политику: нанимают и французских разработчиков и других, которые уже активно участвуют в работе в апстрим и комьюнити для реализации конкретных проектов. Об этом довольно много было сказано на конференциях с той же AXP, Linux Conf.

В этом году один из наших коллег Эндрю Бартлет (Andrew Bartlett) взбудоражил публику, сообщив о том, что часть французских министерств переходит на Samba AD. Неожиданна сама публичность для министерств.

Мы в Red Hat работаем над Samba. Может быть, не так активно, как над FreeIPA.

Часть FreeIPA – в реализации связи с Active Directory. И многие заказчики как раз используют FreeIPA в корпоративном процессе для управления машинами Linux и фактически представляют у себя системы, в которых есть и Linux-системы, и Windows-системы, и MAC, и другие серверные платформы.

Давно уже нет вопроса о какой-то эксклюзивности какой-то одной операционной системы. То есть реальность такова, что наверху стоит Microsoft, которая раздает приглашения на семинар по запуску Red Hat Open Shift на своей облачной платформе.

Это интересное развитие ситуации. В Microsoft, к примеру, работают несколько разработчиков из Samba Team. А это нельзя было ранее представить. Но мы сотрудничаем в Samba Team с Microsoft уже довольно давно. Каждый год Microsoft привозит архитекторов файловых систем, всех интерфейсов, на конференции Samba XP, проводимые Samba Team.

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

– Давайте поговорим еще о безопасности. Идет эволюция в безопасности. И мы приходим к политикам. Не могли бы вы поподробнее рассказать, как этот переход осуществляется – от второго звена к третьему?

– Мы ставим вопрос о том, что нужно, с одной стороны, автоматизировать сложные процессы, скажем, разворачивание инфраструктуры требует такой же автоматизации, как и процессы автоматизации конечных приложений, когда они разворачиваются на огромное количество филиалов. Если мы просто напишем механизмы, которые что-то автоматизируют, этого недостаточно, то есть мы решили проблему дублицирования.

Но мы таким образом не решаем проблему вариативности на местах. Для того чтобы такую вариативность создать, нам нужно иметь механизмы, позволяющие, собственно, где-то допускать принятие решений на месте. Тот проект, о котором я рассказывал на конференции, то, что в Red Hat Enterprise Linux называется Network-Bound Disk Encryption, содержит как один из компонентов проект Clevis, который на стороне клиента реализует как раз работу с политиками, построенную на криптографически выверенном механизме порогового разделения секретов на шаги.

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

То есть мы имеем некий замок довольно сложного свойства. Для того чтобы его открыть, нам нужно собрать несколько компонентов вместе. Такая модель, конечно, не описывает все возможные политики. Но как раз для расшифровывания дисков, привязки их к определенным физическим местам она идеально подходит. Со стороны FreeIPA мы имеем поддержку политик доступа к приложениям, запущенным на отдельных машинах. Это более традиционная схема, в которой централизованно задаются некоторые наборы параметров, говорящие, что, например, пользователь из такой-то группы имеет право через определенную группу машин обращаться к тем или иным приложениям. Приложения – имеется ввиду доступ к ним через PAMM-интерфейс. На стороне клиента SSSD как раз приводит в действие эту политику.

Еще один проект, который вместе делаем с ребятами из GNOME. Он называется Fleet Commander. Его задача – реализовать приведение политик администрирования на клиентские места. То есть администратор создает, скажем, внешний вид рабочего стола, какие там иконки должны быть, какие приложения, какие ссылки, какие ресурсы должны присутствовать.

И когда пользователь первый раз логинится на машину, SSSD вместе с Fleet Commander вытягивает из FreeIPA эти настройки и единовременно настраивает рабочий стол. Причем в политиках может быть описано, что этот рабочий стол заблокирован, пользователь не может изменить какие-то части его, а какие-то – может. То есть у нас, получается, есть политики, которые описывают совершенно разные способы применения и области использования, но все они направлены на одно.

Они централизованы, за исключением, может быть, Clevis, где как раз мы должны описывать что-то локально. Они описывают поведение системы при изменении условий. Например, пользователь под таким-то именем логинится в систему, он присутствует в группах, имеет определенное членство. Соответственно, это влияет на то, какие операции ему позволены: операции с УДО, операции запуска приложений, авторизации через PAMM и т.д., и вплоть до конечного момента, где пользователь, который никакого отношения к ИТ-инфраструктуре не имеет, получает преднастроенный десктоп, у которого определены те приложения, которые ему нужны.

У нас есть и заказчики, которым это интересно, и есть комьюнити, которым это интересно. Потому что многие из этих компонент FreeIPA благодаря тому, что они стали несложными в настройке – одна команда, шесть минут – и у нас все есть, люди ставят на маленькие серверы или дома. Таким образом, получают инфраструктуру, которая выглядит как корпоративная инфраструктура, с надежностями соответствующего уровня у себя дома. А также в своих общественных организациях, тем самым снижая общий расход на поддержание таких систем. Интегрируя это со средствами автоматизации, вроде Ansible, получаем систему, которая гарантированно умеет разворачиваться в тот результат, который мы ожидаем.

– Это очень востребованная вещь, особенно в плане автоматизации; сколько всего было придумано, но всегда с какими-то костылями.

– Понятное дело, что существуют определенные ограничения. То есть мы должны ограничить себя в вариативности по задачам, скажем. Для того чтобы предоставлять пользователям в POSIX-среде гибкость, мы делаем определенные предположения по тому, что и как хранится, какова схема, каковы подходы. Это, может быть, не всегда решает те задачи, которые рассматривают люди, использующие LDAP для более широкого применения. Для них это выглядит немного искусственно и сжато. Некоторые из наших решений построены на реальности, на поддержке этого в долгосрочной перспективе. Red Hat Enterprise потребовалось 10 лет, в определенных редакциях, и больше 10 лет… и вопрос «сокращение обращений в поддержку пользователей» до сих пор вполне актуален.

– А как у вас построена работа в сообществе? Сами придумываете, что еще нужно изменить? Вы получаете фидбек от пользователей? Как здесь процесс построен?

– Двойственно. С одной стороны, всегда есть пользователи, которые знают, чего они хотят. Вплоть до того, что они знают, как это должно быть реализовано. Очень часто сообщения об ошибках или запросы о новой функциональности содержат намек на то, как они хотели бы, чтобы это было реализовано, т.е. в архитектурном плане. Не всегда это возможно. Иногда мы спорим. Особенно часто спорим с людьми, которые имеют большой опыт работы со старыми UNIX-системами, потому что у них свой взгляд на вещи, они не хотят воспринимать новое, они не хотят подстраиваться под ситуации, которые меняются, реальность меняется в целом. То есть не всегда мы видим запросы от сообщества пользователей, которые мы можем реализовать.

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

Выбор ключей, методов шифрования и алгоритмов по умолчанию – это то, чего от нас ожидают многие заказчики. Многим это не нравится. Они хотят, чтобы мы переключались на использование эллиптических кривых, т.е. базовых. На самом деле, оказывается, на сегодняшний момент во многих из спецификаций и рекомендаций НИСТ упоминается, что лучше не использовать эллиптическую криптографию. Потому что есть уже алгоритмы, которые позволят ключи на эллиптических кривых сломать быстрее.

С другой стороны, зная то, как продукт используется, изучая проблемы, о которых нам сообщают заказчики в службу поддержки, можно видеть, на каких путях трансформации находятся те или иные организации. Мы фактически создаем удивительную ситуацию, когда то, что раньше считалось корпоративным решением и стоило огромных денег, доступно не просто энтузиастам, а всему спектру пользователей – от дома, где все машины могут быть введены в домен и полностью поддерживаются в достаточно защищенном режиме, до неправительственных организаций, у которых с ресурсами традиционно не очень и которые традиционно страдают в вопросах безопасности, потому что у них специалистов нет. А также до малого бизнеса, которому тоже тяжело находить средства на серьезные крупные решения, крупные внедрения, до среднего и крупного бизнеса, у которых такие средства могут быть, но опять-таки специалистов нужно искать на стороне.

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

Решения, которые они принимают, или действия, которые они совершают при требовании разворачивания своих серверов, должны быть не в противоречии с настройками дистрибутивов, потому что настройки дистрибутивов, скажем, в американских государственных структурах четко управляются требованиями, прописанными определенными спецификациями. Для чтения этих спецификаций, для проверки на соответствие им есть определенные стандарты, есть программное обеспечение. В Rail это OpenScape, который позволяет считывать описание такого стандарта через профиль.

Берется этот профиль, берется система и верифицируется, соответствует она ему или нет. Если профиль описан достаточно хорошо, то система может сгенерировать скрипты или сценарии, которые позволяют исправить несоответствия. Теперь представьте: у нас есть, с одной стороны, верифицируемое описание, соответствие которому будет требовать аудит, а с другой – у нас есть поставщик приложения, который на все это не особенно обращал внимание. Профиль требует закручивания гаек, приложение не работает. У бизнеса проблемы с тем, что приложение не выполняет свои функции.

– Какой вектор развития вы видите? Что нас ждет дальше в этом направлении?

– Первое: увеличение количества атак, построенных на эксплуатации ошибок в самом железе. Например, те, которые мы наблюдаем последние полтора года… Поэтому крайне важно обновление систем до последних исправлений, которые есть, с определенной проверкой по всей цепочке. Автоматизация здесь играет чрезвычайно важную роль.

А вторая сторона вопроса состоит в том, что последние 5-10 лет шло бурное развитие всей инфраструктуры на основе веб-сервиса, микросервиса, который породил целый ряд изменений. Отслеживание изменений по всей цепочке, что произошло от момента написания приложения до момента его внедрения, и отслеживание распространения проблем, если они обнаружены в конечном приложении, где оно развернуто, куда оно ушло, где эти контейнеры, которые не обновлялись несколько месяцев или несколько лет и работают ли, поиск этих очагов заражения – это один из важных моментов.

Это не только наличие средств сканирования изначального программного кода статическими или динамическими сканерами, это нахождение проблем в уже развернутых системах: машины, виртуальные машины или контейнеры, и трекинг всего процесса.

Red Hat очень активно работает над всей цепочкой, над тем, чтобы была возможность отследить, что, где, куда ушло, и четко оценивать влияние этого на бизнес, потому что фактически, если мы можем сказать, что у нас вышла, став публичной, какая-то проблема, которая эксплуатируется удаленным образом, хорошо было бы знать, в каком из нескольких десятков тысяч контейнеров в наших системах это присутствует, причем не на глазок, а вполне с конкретными вычислительными метриками. Чтобы понять, сколько мы должны на это потратить времени, во что выльется проблема. Вся инфраструктурная сторона движется к предоставлению более предсказуемых результатов для бизнеса, для принятия решений.

Беседовал Владимир Лукин

Комментарии могут оставлять только зарегистрированные пользователи