Astra Linux SE 1.7.3 на рабочих станциях КИИ: мандатный доступ, 1С и корпоративные приложения

Astra Linux Special Edition 1.7.3 вышла с обновлением механизмов мандатного доступа - и у нас как раз был повод её проверить: несколько рабочих станций на объекте КИИ второй категории надо было перевести на сертифицированную ОС под требования ФСТЭК. Записали наблюдения из процесса - потому что документация у Astra, мягко говоря, не избыточна, а интернет про 1.7.x знает меньше, чем хотелось бы.

Что изменилось в 1.7.3

Ключевое в обновлении - расширение мандатных меток и доработка механизма PARSEC (Parallel Access Rights Security Control). В 1.7.2 были известные ограничения при работе с сетевыми ресурсами в мандатном контексте: часть приложений некорректно наследовала метки при запуске через sudo или смене пользовательского контекста. В 1.7.3 это частично починили - мы проверяли на нескольких сценариях запуска терминального клиента 1С через PDC-домен, и поведение стало предсказуемее.

Сертификат ФСТЭК на 1.7.3 покрывает 1Б и 1В уровни защищённости для ГИС, что для большинства объектов КИИ второй и третьей категорий достаточно. Для первой - разговор отдельный.

Мандатное управление: где больно

Концепция мандатного доступа PARSEC - это уровни секретности от 0 до 63 и категории. Каждый процесс и каждый файл получают метку. Процесс с низкой меткой не может читать объекты с высокой - всё честно, как в учебнике. На практике - несколько точек боли, которые съели большую часть времени.

Первое - наследование меток при автозапуске. Сервисы в systemd стартуют с меткой 0:0 по умолчанию. Если приложение должно работать с файлами с меткой 1:0 - нужно явно прописывать pdpl-service с нужным контекстом или настраивать запуск через fly-admin-smc. Документация про это есть, но найти нужный раздел - отдельный квест.

Второе - СУБД и мандатные метки. На этом объекте PostgreSQL с базой 1С. По умолчанию postgres-процесс работает в контексте 0:0, а рабочие файлы базы размечены уровнем выше. Решение - запуск через pdpl-su с нужным уровнем и явное выставление меток на директории данных через pdpl-file. Важный нюанс: после обновления пакета postgresql меткам на /var/lib/postgresql/data ничего не случается, но если пакет переустановить с нуля - метки слетают, и база не стартует без диагностики в логах. Добавили в runbook.

Третье - сетевой трафик и мандатные метки. PARSEC умеет маркировать сетевые пакеты, и если это включено, а клиент и сервер на разных уровнях - соединение режется на iptables. У нас это проявилось при подключении к контроллеру домена Samba: клиент с меткой 1:0 не мог подключиться к DC, у которого маркировка трафика была настроена на 0:0. Лечится согласованием уровней или явным разрешением в правилах мандатного firewall.

Совместимость с 1С

Терминальный клиент 1С (тонкий, через веб-браузер Chromium) в целом работает. Нюансы:

• Chromium нужен из репозитория Astra, не тот что в snap или Flatpak. Версия старше, чем хотелось бы, но с сертифицированной ОС так и должно быть.
• Принтеры - CUPS с нужными драйверами подключаются штатно, но мандатный контекст процесса печати надо согласовывать с меткой очереди. Пользователи жаловались, что «принтер не работает» - оказалось, у cupsd метка 0:0, у документов пользователя 1:0, запись в очередь блокировалась PARSEC.
• Файловый обмен с 1С через сетевую папку SMB - работает, но требует аккуратной настройки меток на точке монтирования. mount.cifs по умолчанию монтирует с меткой 0:0, и файлы, скачанные туда пользователем с уровнем 1:0, оказываются недоступны для дальнейшей загрузки в 1С - потому что уже размечены клиентской меткой, а SMB-сессия идёт в контексте 0:0.

Hardening под ФСТЭК: базовый чеклист

Сертификация ОС - это не финал, а точка отсчёта. ФСТЭК в методических документах по КИИ ожидает ряд дополнительных мер поверх базовой конфигурации:

• Аудит событий - auditd настроен и пишет в защищённое хранилище. Astra поставляется с преднастроенным профилем, но он минимальный: добавляем правила на доступ к критичным файлам конфигурации, изменение мандатных меток, смену пользовательского контекста.
• Контроль целостности - acheck (встроенный инструмент Astra) для проверки эталонных контрольных сумм системных файлов. Настраиваем на запуск при старте и ежедневно по cron, результат в лог с тамперингом.
• Управление учётными записями - отключение неиспользуемых системных пользователей, блокировка root для интерактивного входа, настройка PAM с ограничениями по числу сессий и таймаутом.
• Сетевой стек - fly-admin-smc для управления правилами мандатного брандмауэра, отключение неиспользуемых сервисов через systemctl.

Отдельно - политика обновлений. Сертифицированная ОС с обновлениями из репозиториев Astra обновляется медленнее, чем upstream Debian. Некоторые CVE, которые в Debian уже закрыты, в Astra на момент развёртывания могут быть открыты - это особенность цикла сертификации. Фиксируем в модели угроз.

Где стоим

Первая партия рабочих станций развёрнута и передана пользователям. Основная жалоба - скорость работы браузера и привычка к другому интерфейсу. Технических блокеров по работе с 1С и корпоративной почтой (Evolution через Exchange EWS) не осталось. Следующий этап - серверная часть на том же объекте, там своя история с мандатными метками на уровне гипервизора.

В рамках managed-сопровождения мы готовим шаблонную конфигурацию для типового рабочего места на Astra Linux SE: набор преднастроенных политик, runbook по интеграции с 1С и Samba-доменом, чеклист первичного hardening. Пока это внутренний артефакт, но по запросу делимся.