Astra Linux SE 1.6 у госзаказчика: SSSD работает, прикладное ПО - вопрос

Импортозамещение в 2019 году уже не абстракция в методичке - это конкретные требования в конкурсной документации. У госзаказчиков с требованиями по сертификации ФСТЭК выбор дистрибутива Linux сводится к очень короткому списку, и Astra Linux Special Edition в нём стоит почти на первом месте. Реестр отечественного ПО пополняется, но список сертифицированных дистрибутивов, которые реально используют живые люди в рабочем режиме, остаётся узким.

Мы сейчас ведём пилот у одного государственного заказчика - административная структура, часть рабочих мест переводится на Astra Linux SE 1.6 как требование по импортозамещению. Клиент пришёл с понятным запросом: нужно понять, что работает, что не работает, и сколько времени займёт полноценный перевод. Вот что мы видим на середине пилота.

Что с Active Directory

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

Astra Linux SE 1.6 интегрируется с Active Directory через SSSD - System Security Services Daemon. Мы настраивали это сочетание с некоторой осторожностью: опыт с другими дистрибутивами на SSSD бывал нестабильным, особенно при перебоях сети или при сложных деревьях доверий.

Здесь сработало. SSSD держит связь с контроллерами домена нормально, авторизация пользователей работает, групповые политики в части ограничений на рабочих станциях применяются. Мандатный контроль доступа - фишка Astra Linux SE - с доменными учётными записями совместим: уровни безопасности назначаются через атрибуты в AD, и это настраивается. Нетривиально, но документация есть.

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

Где больно - прикладное ПО

Вот тут начинается настоящая история. Интеграция с AD - это инфраструктурный вопрос, он решаемый. Прикладное ПО - это про то, как люди работают каждый день.

• Браузер. Из коробки идёт Chromium, что в целом нормально. Основная проблема - корпоративные веб-приложения заказчика, часть из которых написана с расчётом на IE/Edge и использует ActiveX или специфичные JS-библиотеки. Несколько порталов работают некорректно. Отдельная головная боль - порталы с КриптоПро плагином: нужна версия КриптоПро для Linux, и она есть, но требует отдельной установки и настройки.

• Офисный пакет. Заказчик частично перешёл на LibreOffice, частично использует My Office - оба в реестре отечественного ПО. LibreOffice с документами в формате .docx справляется в большинстве случаев, но сложная вёрстка с таблицами, колонтитулами и встроенными объектами ломается. Люди, которые работают с шаблонами - формами, договорами, отчётами - это чувствуют сразу.

• Специализированные системы. Это самый болезненный узел. У заказчика есть несколько внутренних информационных систем, написанных под Windows - часть на .NET, часть вообще с клиентом под IE. Часть из них работает в web-версии и открывается в Chromium с переменным успехом. Остальные - нет. Перепиливать их никто не будет быстро.

Как мы с этим работаем

Стратегия пилота не «заменить всё разом», а найти, где переход реально возможен без потери производительности. Мы сейчас составляем карту: какое ПО у каких групп пользователей, что совместимо, что требует адаптации, что вообще не совместимо.

Параллельно тестируем WINE для нескольких Windows-приложений, которые не имеют Linux-версии. Это не идеальный путь, но для переходного периода вполне рабочий для ряда простых утилит. Для .NET-приложений смотрим на возможность терминального доступа к Windows-серверу - часть людей можно оставить в Astra Linux для большинства задач, а к legacy-системам пускать через RDP или RemoteApp.

Мандатный контроль доступа в Astra Linux SE - отдельная тема. Клиент хочет его использовать, потому что именно за него платит лицензию. Но включить МАС на уровне всех рабочих мест сразу - значит получить волну обращений в поддержку. Планируем поднимать постепенно, начиная с тех, кто работает с документами с грифом.

Что думаем сейчас

Главный вывод из середины пилота: техническая часть перехода на Astra Linux SE решаема, и SSSD + AD - не та проблема, которую стоит бояться. Реальная работа - это инвентаризация прикладного ПО и переговоры с разработчиками внутренних систем.

Полный перевод заказчика на Astra Linux по плану займёт дольше, чем изначально предполагалось. Не потому что дистрибутив плохой - а потому что задача «совместимость прикладного ПО» не закрывается тем, что ОС в реестре отечественного ПО.

Сопровождение серверной и рабочей инфраструктуры в процессе таких переходов - именно это мы сейчас и делаем.