Первый пилот Astra Linux SE на рабочей станции госклиента: грабли по списку
Разворачиваем Astra Linux SE у госклиента после приказа о реестре отечественного ПО. Active Directory, 1С и корпоративный браузер - документируем каждую грабли.
Приказ Минкомсвязи о реестре отечественного ПО: госорганы обязаны обосновывать отказ от российских продуктов
В январе Минкомсвязи подписало приказ о реестре отечественного программного обеспечения. Механика простая: есть реестр, при закупке государственный орган обязан обосновать, почему он берёт зарубежный продукт, если в реестре отечественного программного обеспечения есть российский аналог. Не запрет, но документальная нагрузка на отказ от российского - появилась.
Для нас это материализовалось в конкретный запрос: клиент из госсектора хочет пилот Astra Linux Special Edition на рабочих станциях. Не «хочет», если честно - скорее «регулятор требует попробовать». Разница принципиальная, потому что мотивация определяет, насколько люди готовы терпеть неудобства в процессе.
Пилот идёт прямо сейчас. Ниже - что мы уже прошли, без купюр.
Почему именно Astra Linux SE
Astra Linux Special Edition сертифицирована ФСТЭК и ФСБ, то есть для госорганов с требованиями по информационной безопасности это фактически первый кандидат в реестре. Есть и обычный Astra Linux Common Edition, но для регуляторного обоснования нужна именно SE.
Технически это Debian-производное с собственными патчами в ядро и систему мандатного управления доступом (MAC). Звучит знакомо для тех, кто работал с SELinux или AppArmor, но реализация своя - это важно помнить при отладке.
Грабля первая: Active Directory и Kerberos
Клиент уже работает в домене Windows Active Directory. Само по себе Linux в AD - не новость, winbind или sssd с krb5 решают задачу. Проблема оказалась в другом.
Astra Linux SE имеет собственную реализацию клиента мандатной аутентификации, которая при включённом MAC ведёт себя не так, как стандартный sssd. На практике это выглядело так: пользователь доменный аутентифицируется, заходит в систему - и дальше часть политик группы не применяется, потому что MAC-контекст сессии не соответствует ожидаемому.
Решение нашли в документации ФКН (формуляр Astra Linux SE, пункт про интеграцию с AD), но документация написана так, что первые два прочтения ничего не дают - надо читать буквально каждое слово и понимать, как MAC-уровни соотносятся с правами доменного пользователя.
Итог по AD: работает, но настройка занимает примерно вдвое дольше, чем на стандартном Ubuntu или CentOS. Для интеграционных проектов это важно закладывать в оценку.
Грабля вторая: 1С
1С:Предприятие 8.x под Linux - официально поддерживаемый сценарий с тонким клиентом. Клиент ставится, запускается. Здесь мы были оптимистичны - и зря.
Первая неожиданность: тонкий клиент 1С использует свою систему рендеринга, которая взаимодействует с X11 специфическим образом. На Astra Linux SE с включённым мандатным управлением часть операций с буфером обмена работала непредсказуемо - копирование из 1С в другое приложение либо срабатывало, либо нет, и воспроизвести это детерминированно не получалось сразу.
Оказалось, что буфер обмена в X11 и мандатные метки - тема отдельная. MAC-система Astra Linux SE контролирует доступ к буферу обмена между приложениями разных уровней. Тонкий клиент 1С запускается с одним MAC-уровнем, текстовый редактор - с другим, и копирование между ними блокируется политикой по умолчанию.
Решение: перевести оба приложения на один MAC-уровень для этого пользователя, либо скорректировать политику через pdp-config. Второй вариант требует понимания модели безопасности Astra, иначе можно случайно сделать дыру в том самом MAC, ради которого брали SE.
Вторая неожиданность: обновление базы данных 1С через тонкий клиент требует прав администратора приложения. В AD-домене эти права назначаются через группы, но когда MAC вступает в игру - проверять надо комбинацию «домен + MAC-уровень», а не только домен. Документация 1С про Linux об этом не говорит ни слова, документация Astra про 1С - тоже. Выяснили экспериментально.
Грабля третья: корпоративный браузер
У клиента внутренний портал работает с ГОСТ-сертификатами. Это отдельная история: российские удостоверяющие центры выдают сертификаты на алгоритмах ГОСТ Р 34.10-2001/2012, которые не входят в стандартные браузеры. Для Windows это решается КриптоПро CSP + специальным плагином для браузера.
На Astra Linux SE ситуация такая: КриптоПро для Linux существует, ставится. Браузер в виде специально собранного Chromium с поддержкой ГОСТ - тоже есть, его поставляет КРИПТО-ПРО. Но при интеграции с MAC-подсистемой Astra оказалось, что сборка Chromium, которую предоставляет КриптоПро, не подписана с учётом мандатных политик Astra.
Итог: браузер запускается только при частичном отключении MAC для конкретного приложения. Формально с точки зрения регулятора это «допустимо если оформлено», но с точки зрения здравого смысла - мы берём сертифицированную ОС и тут же отключаем её главную фичу для ключевого приложения. Оставили это в пилоте как открытый вопрос к вендору.
Где мы сейчас
Пилот продолжается. Несколько рабочих мест работают в боевом режиме: AD-аутентификация работает, 1С работает с оговорками по MAC-уровням, браузер - с костылём. Пользователи терпят, но без энтузиазма.
Главное наблюдение пока: Astra Linux SE - это не просто «Debian с другим лого». MAC-подсистема реально влияет на поведение всего, что с ней взаимодействует, и каждое стороннее приложение требует проверки в связке именно с MAC. Документация существует, но написана для людей, которые уже знают предметную область. Если знаешь - помогает. Если не знаешь - придётся учиться параллельно с внедрением.
По интеграции такого рода имеет смысл закладывать запас времени на каждый корпоративный компонент - примерно двойной по сравнению с обычным Linux. Не потому что Astra плохая, а потому что каждое приложение надо проверять в связке с MAC отдельно, и этот опыт пока мало где описан.
Про результаты пилота в целом напишем отдельно, когда будет больше данных.