Astra Linux SE на рабочих местах с гостайной: мандатный контроль и SSSD в деле

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

На практике «просто» оказалось ёмким словом.

Мандатный контроль доступа: не то же самое, что права Unix

Первый разговор с командой клиента занял час - только чтобы объяснить, чем мандатный контроль отличается от дискреционного. В обычном Linux файл принадлежит пользователю, пользователь решает, кто ещё может его читать. В Astra Linux SE поверх этого работает мандатная модель: каждый субъект (процесс, пользователь) и каждый объект (файл, директория, устройство) имеет метку безопасности с уровнем и категориями. Ядро проверяет обе стороны при каждом обращении - и если уровень субъекта ниже уровня объекта, доступа нет, вне зависимости от дискреционных прав.

На практике это означает, что пользователь с уровнем «секретно» не может даже увидеть файл с меткой «совершенно секретно» - не то что прочитать. Это не баг и не ограничение, это и есть суть модели.

Метки настраиваются через pdp-ls и pdp-chattr. Посмотреть текущую метку файла:

pdp-ls -M /home/user/document.docx

Выставить метку пользователю при создании сессии можно через PAM-модуль pam_mktemp и настройки в /etc/parsec/. Ключевой конфиг - /etc/parsec/macros, где описываются категории и уровни для конкретной инсталляции.

Главная операционная проблема, которую мы сразу обозначили: метки нужно проставлять осознанно при создании каждого файла или директории. Если пользователь работает на уровне «секретно» и создаёт файл, он автоматически получает метку текущего сеанса. Но перенести файл между уровнями без специальных процедур - нельзя. Для организации это означало необходимость пересмотра рабочих процессов с документами.

SSSD и Active Directory: подключение есть, нюансы тоже

Убирать Active Directory никто не собирался - там авторизация, групповые политики, управление учётными записями для всего остального зоопарка Windows-машин. Задача стояла: аутентифицировать пользователей на Astra Linux SE через существующий AD.

Технически это решается через SSSD (System Security Services Daemon) - демон, который умеет работать с AD через Kerberos и LDAP. В Astra Linux SE SSSD есть и в целом работает. Несколько вещей при этом потребовали отдельного внимания.

Конфиг /etc/sssd/sssd.conf в базовом виде выглядит ожидаемо:

[sssd]
services = nss, pam
domains = corp.example.ru

[domain/corp.example.ru]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_domain = corp.example.ru
ad_server = dc01.corp.example.ru
krb5_realm = CORP.EXAMPLE.RU
cache_credentials = true
enumerate = false

Соединение поднялось, пользователи из AD логинятся. Но здесь начинается интересное.

Первое - мандатные метки и AD-пользователи не связаны автоматически. AD ничего не знает про метки Astra Linux SE, и метки не синхронизируются из атрибутов пользователя в AD. Уровень доступа для каждого AD-пользователя нужно прописывать локально на машине - в /etc/parsec/ или через консоль управления безопасностью. Это означает дополнительную операционную процедуру при каждом появлении нового пользователя, которому нужен доступ к защищённым машинам.

Второе - групповые политики AD работают частично. Стандартные политики, управляющие параметрами Windows - не применяются, это ожидаемо. Но и те GPO, которые теоретически могли бы управлять UNIX-атрибутами через RFC 2307, работают не так гладко. Для управления конфигурацией Linux-машин через AD нужно либо использовать сторонние инструменты (Ansible, puppet), либо мириться с ручным управлением.

Третье - Kerberos и времена синхронизации. Kerberos чувствителен к расхождению времени. На стенде один раз получили классическую ситуацию: NTP не успел синхронизироваться после перезагрузки, аутентификация через Kerberos начала отваливаться с невнятными ошибками в логах. Решение тривиальное - chrony или ntpd в автозапуске и проверка синхронизации как часть процедуры ввода машины в эксплуатацию.

Что получилось и что осталось

Пилот прошёл на нескольких рабочих местах. Пользователи логинятся через AD, файлы получают мандатные метки, разграничение доступа по уровням работает. Это главное.

Операционные выводы, которые мы зафиксировали для клиента:

• Обучение персонала - обязательный этап, не опциональный. Концепция меток нетривиальна для людей, привыкших к Windows. Несколько раз на пилоте получали вопросы «почему я не вижу свой же файл» - потому что файл создан в сеансе с другой меткой.
• Процедура маркирования документов - нужно написать и согласовать до того, как система пойдёт в production. Иначе разметка будет хаотичной.
• Управление конфигурацией - без централизованного инструмента (Ansible или аналог) операционная нагрузка на администратора растёт линейно с количеством машин. Каждая машина - это ручная настройка меток для локальных пользователей.
• Совместимость ПО - часть прикладного ПО, которое клиент хотел запускать, ставится из пакетов без подписи или требует библиотек, которых нет в репозиториях Astra Linux SE. Это отдельная история для следующего раунда.

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

Пилот не закончен - дальше смотрим на совместимость прикладного стека и выстраиваем процедуры управления метками в масштабе. Результаты будут.