Astra Linux SE 2.8: разворачиваем на рабочих станциях с допуском к гостайне

В конце июля «Русбитех-Астра» закрыла тему, которая у нескольких наших клиентов висела как открытый вопрос с начала года: Astra Linux Special Edition 2.8 получила сертификат ФСТЭК России по профилю МО5. Это высший уровень защищённости в линейке сертификатов ФСТЭК - выше только ФСБ со своими гостайновыми требованиями, которые обсуждаются совсем в других кабинетах. Для нас это означало, что можно переходить от разговоров к инсталляциям.

У одного из клиентов - организации с лицензиями на работу со сведениями, составляющими государственную тайну, - стояла задача переоснастить парк рабочих станций под требования аттестации автоматизированных систем по классу 1Б. До этого часть машин работала на Astra Linux 2.7 с сертификатом МО4, часть - на Windows с набором СЗИ поверх. Последнее - классическая история про «мы потом разберёмся с совместимостью», которая превратилась в гору документации и ежегодный головняк при проверках.

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

Первый вопрос, который задают: зачем переходить, если 2.7 работает? На практике разница не только в строчке сертификата:

• Мандатный контроль целостности (МКЦ) стал плотнее интегрирован в политику по умолчанию. В 2.7 при стандартной установке МКЦ нужно было донастраивать вручную под конкретные профили меток. В 2.8 базовая политика стартует с уже расставленными уровнями для системных каталогов, и это экономит примерно треть времени на первичной конфигурации.
• Astra Hardened Kernel в 2.8 основан на ядре 5.15 LTS с патчами Grsecurity-подобного класса. Не то чтобы 2.7 был беззащитен, но ABI-совместимость с современными драйверами у 2.8 существенно лучше - это важно для рабочих станций с относительно свежим железом.
• Маркированные пакеты - в 2.8 появился реестр компонентов с отметками о прохождении сертификационных испытаний. Это не просто удобство: при аттестации проверяющие спрашивают, из каких источников установлено ПО и есть ли сертификационный паспорт на конкретную версию пакета. В 2.7 эту документацию нужно было собирать отдельно.

Как выглядит процедура аттестации на практике

Аттестация АС по классу 1Б - это не «поставил ОС, закрыл задачу». Это работа с аттестационной лабораторией, которая занимает несколько недель и требует подготовки на нескольких уровнях сразу.

Мы делали это параллельно с развёртыванием - команда managed разворачивала рабочие станции, пока юридическая и безопасная стороны клиента готовили пакет документов для лаборатории.

Этап 1 - подготовка эталонного образца. Одна машина конфигурируется полностью: ОС, политики SELinux/МКЦ, список разрешённого ПО, отключение неиспользуемых сервисов (у нас это 17 позиций в systemd, которые по умолчанию включены, но в закрытом контуре не нужны). С этого образца снимаются хеши ключевых файлов и конфигураций - это будущая доказательная база.

Этап 2 - проверка лаборатории. Аттестационная лаборатория проводит испытания по программе, согласованной с ФСТЭК. Проверяют механизм мандатного управления доступом, аутентификацию, аудит событий, защиту от НСД на уровне загрузчика. Конкретный состав испытаний зависит от класса системы, но МО5 с сертификатом 2.8 в этом смысле даёт лаборатории стандартную точку опоры - часть проверок закрывается ссылкой на сертификационные испытания ОС.

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

Что нас удивило (не в хорошем смысле)

Совместимость принтеров и периферии - это отдельная поэма. На рабочих станциях стояли МФУ от нескольких вендоров, и картина оказалась пёстрой: часть работала через CUPS без проблем, часть требовала драйверов, которые поставщик поставляет только под Windows, один аппарат вообще не поддерживал ничего кроме проприетарного клиента под x86/Win32. В закрытом контуре с требованиями гостайны завести эти МФУ через виртуализацию или эмуляцию - вопрос не только технический, но и аттестационный. В итоге часть парка периферии пришлось заменить. Это не проблема Astra Linux 2.8 конкретно, но это реальность, о которой стоит знать до начала проекта, а не в процессе.

Второй момент - прикладное ПО. Часть специализированных программ под задачи клиента существует только в Windows-версии. Для некоторых нашли отечественные аналоги в реестре Минцифры, для некоторых - нет. Дедлайн по КИИ это давление не снимает, а скорее добавляет: там, где нет замены, нужно либо обосновывать исключение, либо искать решение через эмуляцию, что при высших классах защищённости само по себе предмет для отдельного разговора с регулятором.

Где сейчас

Первая очередь рабочих станций аттестована и введена в эксплуатацию. Вторая очередь - в работе, там сложнее с прикладным ПО. Предварительный вывод: сертификат МО5 на 2.8 реально упрощает аттестационную процедуру - документационная нагрузка снижается, потому что часть доказательной базы уже закрыта испытаниями производителя. Но технический долг по периферии и прикладному ПО никуда не девается - его нужно выявлять на этапе обследования, а не после начала развёртывания.