Привет, Хабр! Импортозамещение инфраструктурного стека Microsoft — задача, с которой периодически сталкиваются большие российские компании и субъекты критической инфраструктуры (КИИ). Служба каталога, менеджер конфигураций, корпоративный центр сертификации — всё это годами держалось на решениях одного вендора. Но все знают, что за последние 5 лет всё кардинально поменялось, и нужны решения, способные реально заменить существующий 30 лет стек.
На Хабре уже выходили материалы про аналоги Active Directory. Настал черед поговорить про коробочные решения, уже заменяющие стек Windows + AD + SCCM + CA. Речь идёт об Astra Server Core, совместной платформе «Группы Астра» и компании «Аладдин». Решение представляет собой Astra Linux Server с корпоративным центром сертификации Aladdin Enterprise CA (eCA), службой каталога ALD Pro и менеджером конфигураций ACM.
Я поговорил об этом стеке с директором серверного ПО «Группы Астра» Алексеем Фоменко и генеральным директором компании «Аладдин» Сергеем Груздевым. Мы обсудили, из чего состоит платформа, как организована миграция с Windows-инфраструктуры без остановки сервисов, какие специалисты нужны для внедрения и как обстоит дело с совместимостью с другими российскими ОС.
Приятного чтения!
Оглавление
Расскажите подробнее о том, что представляет собой Astra Server Core?
Алексей Фоменко: Это продукт нового уровня относительно большинства вендорских Linux-решений, присутствующих на рынке. Мы инвестировали значительное время в развитие инфраструктурных продуктов. Совместно с компанией «Аладдин» — а встречаемся мы именно на промышленных внедрениях — проанализировали, как эти решения функционируют в реальной боевой инфраструктуре заказчиков. В результате пришли к выводу, что продукты достигли зрелости, достаточной для объединения в единый программный комплекс — платформу Astra Server Core.
Платформа включает следующие компоненты: серверная операционная система Astra Linux, служба каталога ALD Pro, менеджер конфигураций ACM и корпоративный центр сертификации Aladdin Enterprise CA (eCA). Совокупно эти компоненты образуют полноценную замену стека Microsoft. Крупные корпоративные заказчики получают возможность перейти на Astra Server Core, сохраняя привычные сценарии работы. Помимо этого, каждый компонент платформы поддерживает эксплуатацию в гетерогенной среде — настолько долго, насколько это необходимо заказчику, — то есть одновременную работу как в унаследованной западной инфраструктуре, так и в новой среде на отечественных технологиях.
Как будет организован переход на Astra Server Core? Заказчику придётся строить параллельную инфраструктуру, или возможна миграция сертификатов в рамках существующей среды?
Алексей Фоменко: Относительно общего подхода — мы рекомендуем строить отдельную инфраструктуру. Встраивание даже защищённых продуктов в уже скомпрометированную или необслуживаемую среду увеличивает сложность эксплуатации и создаёт дополнительные точки отказа. У нас есть подтверждённые примеры того, как подобный подход компрометировал сторонние решения. В частности, если служба каталога на базе Samba (open source или коммерческая) интегрирована в доменную инфраструктуру Microsoft, то при компрометации домена Microsoft компрометируется и решение на Samba. Такой подход не отвечает требованиям заказчиков к безопасности и надёжности.
Рекомендуемый сценарий: строить новую инфраструктуру отдельно, при этом плавно переводить пользователей, поскольку они могут работать в двух средах одновременно. По вопросу миграции сертификатов — Сергей Груздев поясняет подробнее.
Сергей Груздев: Инфраструктуру с нуля практически никто не строит — как правило, она уже существует на базе Microsoft. Наша задача — не нарушить работу действующих сервисов. Схема следующая: корпоративный центр сертификации Aladdin eCA разворачивается параллельно Microsoft CA, после чего настраивается политика переключения входящих запросов на выпуск и обновление сертификатов на новый сервер. Поскольку типичный срок действия сертификата составляет один год, сценариев перехода два.
-
Первый — эволюционный: новый сервер обрабатывает все поступающие запросы в режиме bypass. В начале миграции 100% выпущенных сертификатов находятся на стороне Microsoft, однако в течение года их доля сокращается, а доля сертификатов на платформе «Аладдин» возрастает. Таким образом, полная ротация происходит без остановки сервисов.
-
Второй — ускоренный: система импортирует шаблоны сертификатов, выпущенных в инфраструктуре Windows, и принудительно перевыпускает их по сегментам в полуавтоматическом режиме.
Оба сценария охватывают два класса объектов: доменные (машины, пользователи и оборудование, состоящие в домене) и недоменные. Для доменных устройств раскатка сертификатов выполняется штатными средствами операционной системы. Для недоменных — задействуется отдельное решение, обеспечивающее распространение сертификатов на оборудование, сервисы и пользователей за пределами домена. Таким образом, оба случая закрыты, и миграция проходит без сервисных шоков.
Какие компетенции необходимы для внедрения Astra Server Core? Достаточно ли квалификации системного администратора, или требуется специализированная экспертиза?
Алексей Фоменко: Продукты достаточно зрелые. Для службы каталога ALD Pro разработан курс ALD Pro Professional, в котором две трети учебного времени посвящены администрированию Linux — архитектуре протоколов, работе служб и прочим основам, — а оставшаяся треть — развёртыванию ALD Pro. Аналогичный подход реализован для менеджера конфигураций ACM. Компания «Аладдин» также предоставляет учебные курсы по своему решению. Цель — обеспечить возможность самостоятельного развёртывания после базового прохождения курсов.
Сложности, как правило, возникают на этапе проектирования: как правильно встроить решения в существующую инфраструктуру и выстроить архитектуру. Здесь необходим консалтинг, который мы готовы предоставлять совместно — особенно в корпоративном сегменте, где любое внедрение предваряется проектированием. Техническая поддержка также доступна после развёртывания. Качество взаимодействия с поддержкой зависит от уровня администратора: часть специалистов задаёт предметные вопросы, другие обращаются с запросом «не работает», — в таких случаях анализ логов в рамках диалога с администратором позволяет идентифицировать проблему и скорректировать конфигурацию.
Сергей Груздев: Я бы разделил этот вопрос на два блока. Первый — как мигрировать и внедрить продукт. Процедура пошагово задокументирована. Однако реальная проблема в другом: у заказчиков сложные, нестандартные инфраструктуры. При этом целое поколение ИТ-специалистов сформировалось в экосистеме Microsoft, которая намеренно скрывала архитектурные детали и прятала PKI-концепции под слоем мастеров установки. Такой подход создал слой «операторов», не имеющих глубокого понимания того, что происходит под капотом.
Сейчас отрасль столкнулась с задачей качественно иного уровня: переход из одной технологической экосистемы в другую с сохранением гетерогенности. Компетенций в проектировании таких сред катастрофически не хватает, и материалов по этой теме крайне мало. В связи с этим я работаю над учебным пособием — книгой «Основы PKI. Теория и практика», посвящённой именно архитектурным аспектам корректного проектирования инфраструктуры открытых ключей.
Второй блок — формирование центров компетенции на базе партнёров-интеграторов. Ключевой принцип: сначала внедри решение у себя. Специалист, не эксплуатирующий продукт самостоятельно, не может знать его достаточно хорошо. Помимо этого, мы практикуем вендорский надзор: когда интегратор готовит проект для заказчика, наши эксперты проводят архитектурный аудит ещё на стадии предпроекта. Это устраняет 60–80% потенциальных проблем до начала внедрения. Следующий шаг — переход от уровня тренингов к уровню архитектурного проектирования, с глубоким погружением в то, как правильно выстраивать инфраструктуру, а не просто как её воспроизвести.
Получается, совместная разработка продукта предполагает и совместную эксплуатацию. Квалификации системного администратора недостаточно — нужен DevOps-инженер?
Сергей Груздев: Именно. Продукт — это лишь вершина айсберга. Подводная часть — методология внедрения, сопровождение, развитие и устранение инцидентов. Эти знания необходимо транслировать в партнёрскую сеть. Оба вендора накопили компетенции по отдельности; теперь задача — объединить их и передать партнёрам. Мы вендоры и не работаем с заказчиками напрямую, поэтому наша миссия — научить партнёрскую сеть делать это правильно.
Алексей Фоменко: Добавлю важный нюанс. Для заказчика с 50 пользователями требования минимальны: типовые настройки, коробочное решение. То, о чём говорит Сергей Груздев, актуально прежде всего для корпоративного сегмента — там, где сотни и тысячи пользователей. В таких проектах действительно необходимы DevOps-инженер и серьёзное погружение в продукт.
Сергей Груздев: И security-архитектор. Нужно заходить с двух сторон.
На кого ориентирована Astra Server Core — на государственные организации, субъекты КИИ или на крупный частный бизнес?
Алексей Фоменко: И на тех, и на других. Исторически обе компании хорошо представлены в госсекторе и КИИ, и мы рассчитываем, что платформа органично впишется в инфраструктуру текущих клиентов — с возможностью апгрейда на новый стек. Синергия очевидна: заказчику проще работать с единой платформой и дешевле её купить, нам — проще обновлять её целиком, а не провязывать отдельные решения друг с другом. Тем не менее платформа применима в любом сегменте: стек Microsoft со службой каталога, SCCM и удостоверяющим центром используется в самых разных организациях. Применимость определяется ИТ-зрелостью и принятыми практиками системного администрирования.
Сергей Груздев: Важно добавить: декларации о безопасности должны быть подтверждены независимой экспертизой. Для этого существует система сертификации. Наши продукты уже прошли сертификацию, и в настоящее время мы готовимся к сертификации для эксплуатации в системах с обработкой сведений, составляющих государственную тайну, до степени «совершенно секретно». Это высокий уровень проверки, подтверждающий реальную, а не декларативную безопасность.
Как изменятся затраты заказчика через год после перехода на платформу?
Алексей Фоменко: Точные цифры привести затруднительно. Однако я вижу следующее: сегодня заказчики расходуют значительную часть ресурсов на закрытие операционных проблем — разбор инцидентов в разрозненных решениях, тестирование после обновлений, пересборку конфигураций. Переход на единую платформу устраняет эту суету. Высвободившееся время и ресурсы заказчик сможет направить на развитие инфраструктуры, а не на её обслуживание.
Сергей Груздев: Добавлю: ускорение внедрения тоже важно. Платформа устраняет весь цикл выбора — сборка стенда, тестирование совместимости, раздельные конкурсные процедуры, риск несостоявшегося тендера. Всё это время, нервы, деньги и ресурсы. Типовые кейсы и сценарии уже отработаны и доступны «из коробки». Что принципиально: компоненты платформы обновляются в едином синхронизированном цикле. Обновление одного компонента не нарушает работу остальных — а это важнее, чем кажется на этапе внедрения.
Насколько актуальна проблема вендорлока? Может ли Astra Server Core работать с другими российскими операционными системами?
Алексей Фоменко: Платформенные решения — это набор взаимоувязанных компонентов, каждый из которых обеспечивает работу в гетерогенной среде. Фундамент платформы — серверная ОС Astra Linux, обладающая наиболее широкой базой совместимости в России. Сервис Ready for Astra занимается тестированием и подтверждением совместимости сторонних решений. Служба каталога ALD Pro имеет более 150 интеграций с различными технологическими решениями — причём это не формальные интеграции «для галочки», а полноценные, с задокументированными сценариями и инструкциями по конфигурации обоих компонентов. Мы изначально исходим из того, что технологический ландшафт заказчика остаётся разнородным — и, возможно, таким останется навсегда. Платформа проектируется для встраивания в этот ландшафт, а не для его вытеснения.
Сергей Груздев: Принцип гетерогенности должен быть заложен в архитектуру с самого начала. Часть решений, сервисов и данных останется в Windows — либо потому, что их перенос экономически нецелесообразен, либо технически невозможен. Поэтому архитектура должна предусматривать устойчивую совместную работу двух сред. Это усложняет задачу, но мы этот путь прошли.
Что касается независимости: «Аладдин» — самостоятельный вендор. Для включения в реестр отечественного ПО мы обязаны и фактически поддерживаем как минимум «большую тройку» российских дистрибутивов Linux, а в совокупности — около десяти операционных систем.
Стратегическое партнерство с «Астрой» не означает эксклюзивности: рынок устроен так, что многие заказчики одновременно используют несколько операционных систем, и мы обязаны их все поддерживать. Ценность партнёрства — в другом: компоненты синхронизированы на уровне платформы, поставляются из единого источника и, по оценке, на 40% дешевле, чем при раздельной закупке. Фактически «Аладдин» выступает как OEM-компонент в составе Astra Server Core: «Астра» рассматривает его как собственный продукт, при этом на сложных кейсах подключается экспертиза «Аладдин». Заказчик получает единое окно поддержки — без перекладывания ответственности между вендорами. Это экономит время и ресурсы и у заказчика, и у нас: высвобождённые мощности мы направляем на развитие платформы, обучение и трансфер компетенций партнёрам.
Заключение
Вот такое вышло интервью. Интересно будет понаблюдать за развитием российских вендоров, разными коллаборациями, а также какой будет Astra Server Core через 5 лет.
Другой вопрос, что для создания своего стека Microsoft потратила намного больше финансов и человеко-часов, да и сам стек сформировал рынок. Как будет с решением от «Группы Астра» и компании «Алладин», покажет время. Тем более, что некоторым IT-специалистам ещё предстоит тестировать Astra Server Core для перехода с инфраструктурного стека Microsoft, а значит, будет больше экспертизы.
Спасибо за прочтение!
ссылка на оригинал статьи https://habr.com/ru/articles/1048304/