Astra Linux Special Edition 2026: тонкая настройка и безопасность для защищённых контуров

Краткое содержание

• Введение и подготовка среды Astra Linux SE 2026
• Настройка мандатного контроля доступа (МКД) для защищённого контура
• Интеграция КриптоПРО CSP: криптографическая защита и аппаратные токены
• Аудит безопасности: мониторинг событий МКД и криптоопераций
• Практические сценарии развертывания в защищённых контурах
• Шпаргалка команд и скриптов для администратора

Что получится в итоге

После выполнения основных шагов вы получите базовый контур Astra Linux SE 2026 с понятными критериями проверки на каждом этапе:

• Подтвердите версию ОС VERSION="2026", обновите пакеты и подготовите резервные копии конфигураций.
• Настроите профиль МКД, назначите метки процессам и файлам, а также проверите запрет доступа между уровнями.
• Подключите Рутокен или JaCarta, проверите видимость устройства и работу КриптоПРО CSP.
• Подготовите конфигурацию Nginx для TLS и проверите её командой nginx -t, учитывая поддержку ssl_provider в конкретной сборке.
• Активируете auditd, настроите правила для МКД и криптографических операций, а затем найдёте события в /var/log/audit/audit.log.

Инструкции подходят для стенда или сервера, где Astra Linux Special Edition 2026 уже установлена, у администратора есть права sudo, а пакеты КриптоПРО CSP доступны из согласованного репозитория или в виде локальных .deb-пакетов. В защищённом контуре отдельно проверьте имена сетевых интерфейсов, внутренние DNS-серверы, профили МКД, пути к сертификатам и поддержку криптографического провайдера в сборке Nginx.

Готовые политики МКД, конфиги Nginx и auditd для Astra Linux SE 2026

Это практическое руководство для системных администраторов и DevOps-инженеров, которым нужно внедрить Astra Linux SE 2026 в высокозащищённом контуре. В материале собраны политики мандатного контроля доступа (МКД), конфигурации Nginx с интеграцией КриптоПРО CSP, команды для работы с аппаратными токенами и скрипты аудита безопасности.

• Сэкономите 2-3 дня на настройке благодаря готовым конфигурациям и шаблонам политик безопасности.
• Снизите риск ошибок при интеграции с КриптоПРО за счёт последовательной проверки устройства, криптопровайдера и конфигурации Nginx.
• Получите готовые скрипты для аудита СЗИ и критерии, по которым можно проверить результат до переноса изменений в рабочую среду.

Быстрый старт

• Проверить версию ОС и подготовить среду перед изменением политик.
• Настроить политики МКД и проверить метки процессов и файлов.
• Подключить Рутокен или JaCarta и подготовить конфиг Nginx для КриптоПРО CSP.
• Проверить auditd, правила аудита и записи в логах.
• Открыть шпаргалку команд и скриптов для повторного запуска процедур.

Оглавление

• Введение и подготовка среды Astra Linux SE 2026
• Настройка и управление мандатным контролем доступа (МКД)
• Криптографическая защита и интеграция с отечественным ПО
• Аудит событий и мониторинг безопасности
• Практические сценарии развертывания в защищённых контурах
• Шпаргалка команд и скриптов для администратора

Введение и подготовка среды Astra Linux SE 2026

Это руководство предназначено для системных администраторов и DevOps-инженеров, которым требуется развернуть и настроить Astra Linux Special Edition 2026 в высокозащищённом контуре. Основной фокус — мандатный контроль доступа, криптографическая защита КриптоПРО CSP, интеграция с Nginx и аудит событий через auditd. Для каждого этапа приведены команды, примеры конфигураций и признаки успешной проверки.

Инструкции рассчитаны на базовую установку Astra Linux SE 2026. Их нельзя переносить в рабочий контур без предварительной проверки профиля безопасности, состава пакетов и требований конкретной СЗИ. Перед изменением конфигураций сохраните резервные копии и подготовьте процедуру отката.

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

Проверка версии и базовой конфигурации

Для проверки точной версии используйте команду:

cat /etc/os-release

В ответе должна присутствовать строка VERSION="2026". Убедитесь, что установлены последние обновления безопасности:

sudo apt update && sudo apt upgrade -y

Для базовой настройки сети и имени хоста используйте инструмент hostnamectl:

sudo hostnamectl set-hostname server-al-se-01

Настройка статического IP-адреса выполняется через редактирование файла /etc/netplan/01-netcfg.yaml. Пример конфигурации:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

Адреса 8.8.8.8 и 8.8.4.4 приведены только как пример. В защищённом контуре используйте согласованные внутренние DNS-серверы. Если сетевой интерфейс называется не eth0, замените имя в конфигурации до применения изменений.

Применяйте изменения командой sudo netplan apply.

Проверка результата: команда cat /etc/os-release показывает VERSION="2026", имя хоста соответствует заданному значению, а интерфейс eth0 получает адрес из файла /etc/netplan/01-netcfg.yaml. Если после netplan apply пропала связь, вернитесь к резервной копии и проверьте имя интерфейса, шлюз и DNS.

Подготовка к работе с мандатным контролем и криптографией

Перед началом сложных настроек необходимо создать предварительные условия. Установите базовые пакеты для мандатного контроля и криптографии:

sudo apt install astra-mmc astra-secure-utils cryptcp -y

Команда подходит, если пакеты доступны в подключённом репозитории. При использовании локальных пакетов проверьте их совместимость с Astra Linux SE 2026 и не смешивайте версии из разных комплектов без проверки зависимостей.

Если планируется использование аппаратных токенов (Рутокен, JaCarta), проверьте их наличие и доступность через USB-порты. Для этого можно использовать команду lsusb.

Важно: Критически важно создать резервные копии ключевых конфигурационных файлов перед любыми изменениями.

sudo cp /etc/astra-mmc/policy.conf /etc/astra-mmc/policy.conf.backup
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

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

Настройка и управление мандатным контролем доступа (МКД)

Мандатный контроль доступа в Astra Linux SE 2026 реализуется через механизм меток, присваиваемых субъектам (процессы) и объектам (файлы, каталоги). Это ключевой инструмент для разграничения доступа в защищённом контуре и основа для настройки политик МКД.

Как настроить МКД для изолированного рабочего места?

Для первичной настройки системы МКД используйте команду:

sudo dpkg-reconfigure astra-mmc

Интерфейс предложит выбрать базовый профиль безопасности, например «Высокий» для защищённых контуров. Выбор профиля должен соответствовать регламенту организации: повышение уровня без проверки совместимости приложений может привести к отказам доступа. После этого основные операции выполняются через утилиту setmmc.

Базовые операции с метками

Просмотр текущей метки процесса:

setmmc -p

Просмотр метки файла:

setmmc -f /path/to/file

Назначение высокой метки файлу:

setmmc -f /path/to/secret_data.txt -l HIGH

Изменение метки запущенного процесса, например веб-сервера:

setmmc -p $(pidof nginx) -l MEDIUM

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

Проверка результата: setmmc -p и setmmc -f /path/to/file возвращают метки без ошибок. Для проверки разграничения создайте тестовый файл с меткой HIGH и попробуйте прочитать его из сессии с меткой LOW. В рабочей конфигурации доступ должен быть запрещён политикой МКД. Если метки не выводятся или чтение разрешено, остановите дальнейшую настройку и проверьте выбранный профиль и действующие политики.

Конфигурация изолированных рабочих мест и сессий

Для создания полностью изолированной среды для обработки критичных данных можно запустить отдельную сессию с уникальной меткой. В графическом режиме это делается через меню «Система» → «Запустить изолированную сессию».

В консольном режиме используйте команду:

sudo astra-session --label TOP_SECRET --isolate

Эта команда создает новую сессию с меткой TOP_SECRET, где все запущенные процессы и созданные файлы будут автоматически получать эту метку. Политики доступа между этой сессией и основной системой с меткой LOW будут запрещены по умолчанию, обеспечивая изоляцию.

Для управления политиками между сессиями редактируйте файл /etc/astra-mmc/policy.conf. Пример правила, разрешающего передачу данных из сессии с меткой HIGH в сессию MEDIUM только через специальный каталог:

allow HIGH -> MEDIUM /var/transfer/;

Проверка результата: запущенная изолированная сессия получает метку TOP_SECRET, а попытка обратиться к объекту другого уровня без разрешающего правила завершается отказом. Проверяйте не только запуск сессии, но и фактический доступ к тестовым файлам.

Разработка и применение политик безопасности

Переход от базовых команд к стратегическому управлению осуществляется через файлы политик. Создайте файл политики для роли «Оператор» по пути:

/etc/astra-mmc/policies/operator.policy

Содержимое файла может выглядеть так:

# Политика для оператора
subject_label OPERATOR
allow OPERATOR -> LOW /home/operator/;
allow OPERATOR -> MEDIUM /var/log/;
deny OPERATOR -> HIGH *;

Это правило разрешает оператору работать в своем домашнем каталоге (метка LOW) и читать логи (метка MEDIUM), но полностью запрещает доступ к данным с высокой меткой HIGH.

Для применения политики используйте:

sudo mmc-load-policy /etc/astra-mmc/policies/operator.policy

Автоматическое применение политик при запуске системы можно настроить через добавление команды загрузки в /etc/rc.local или создание системной службы. Сначала добейтесь корректной загрузки политики вручную, затем автоматизируйте этот шаг.

Проверка результата: команда mmc-load-policy не возвращает ошибок, а тестовый процесс с меткой OPERATOR получает доступ только к разрешённым путям. Если политики МКД не применяются, проверьте точное имя файла, синтаксис правил, выбранный профиль безопасности и повторно выполните загрузку вручную.

Тестирование политик проводится путем запуска процессов с нужными метками и проверки доступа к файлам с помощью setmmc -f и стандартных команд чтения (cat, ls).

Резюме раздела: Вы настроили базовый профиль МКД, научились управлять метками процессов и файлов, создали изолированную сессию и разработали собственную политику для роли «Оператор». Теперь система готова к интеграции криптографической защиты.

Криптографическая защита и интеграция с отечественным ПО

Интеграция с отечественным криптографическим ПО, таким как КриптоПРО CSP, является обязательным требованием для многих защищённых контуров. На этом этапе важно разделять проверку самого криптопровайдера, аппаратного токена и интеграции с приложением или Nginx.

Как подключить Рутокен к Astra Linux?

Инсталляция и базовая настройка КриптоПРО CSP выполняется из официальных репозиториев или с локального пакета. Предполагается, что пакет cprocsp-*.deb уже скачан.

sudo dpkg -i cprocsp-pki-*.deb cprocsp-ca-*.deb
sudo apt --fix-broken install

После установки необходимо настроить лицензию и проверить работу. Сначала убедитесь, что устройство определяется на уровне USB:

lsusb

Проверка установки криптопровайдера:

/opt/cprocsp/bin/amd64/csptest -keyset -verify

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

sudo apt install libssl3 libc6 -y

Проверка результата: Рутокен или JaCarta отображается в выводе lsusb, а csptest -keyset -verify видит доступное криптографическое устройство. Если USB-устройство не определяется, сначала проверьте порт, кабель и права доступа. Переустановка КриптоПРО CSP не исправит проблему физического подключения.

Настройка TLS и работа с аппаратными токенами

Для генерации ключа и сертификата с использованием токена Рутокен используйте команды КриптоПРО:

/opt/cprocsp/bin/amd64/certmgr -create -rd -cont "рутокен"

Конфигурация веб-сервера Nginx для использования отечественного криптопровайдера требует указания специальных параметров SSL. Пример секции в nginx.conf:

server {
    listen 443 ssl;
    ssl_certificate /opt/cprocsp/keys/cert.pem;
    ssl_certificate_key /opt/cprocsp/keys/key.pem;
    ssl_provider "cprocsp";
    ...
}

Директива ssl_provider "cprocsp" не относится к универсальному синтаксису стандартной сборки Nginx. Используйте её только в сборке или модуле с поддержкой интеграции КриптоПРО CSP.

Перед перезапуском Nginx проверьте конфигурацию:

sudo nginx -t

Если команда возвращает ошибку unknown directive "ssl_provider", текущая сборка Nginx не поддерживает этот параметр. В этом случае проверьте пакет или модуль интеграции КриптоПРО CSP, а не добавляйте директиву в стандартную сборку без подтверждения совместимости.

Настройка аутентификации по токену для пользователей системы выполняется через PAM-модуль. Установите модуль и добавьте в файл /etc/pam.d/common-auth строку:

auth sufficient pam_pkcs11.so

После изменения PAM обязательно оставьте активную административную сессию для отката и проверьте вход на отдельной тестовой учетной записи. Ошибка в common-auth может заблокировать обычную аутентификацию.

VPN-шлюзы и криптографическая защита трафика

Настройка VPN-клиента OpenVPN с использованием криптографии КриптоПРО требует предварительной генерации ключей через криптопровайдер и указания в конфиге OpenVPN параметров:

cryptoapicert "SELECT\Certificate\from\CryptoAPI"
engine "cprocsp"

Для маршрутизации трафика конкретного приложения через VPN можно использовать механизм маркировки пакетов (netfilter) в сочетании с мандатными метками. Создайте правило, которое маркирует все пакеты, исходящие от процесса с меткой SECRET_VPN:

sudo nft add rule ip mangle output meta sksecmark eq SECRET_VPN mark set 10

Затем настройте политику маршрутизации для пакетов с маркой 10 через VPN-интерфейс. После изменения проверьте таблицу маршрутизации и тестовый трафик приложения: правило маркировки само по себе не создаёт маршрут через tun0.

Резюме раздела: Вы установили КриптоПРО CSP, настроили Nginx для работы с отечественными сертификатами, подключили аутентификацию через токены и сконфигурировали VPN с маршрутизацией на основе мандатных меток. Для более глубокого изучения безопасности веб-сервера рекомендуем руководство по продвинутой безопасности Nginx.

Аудит событий и мониторинг безопасности через auditd

Подсистема аудита (auditd) в Astra Linux SE 2026 позволяет отслеживать и анализировать события, связанные с безопасностью, включая операции МКД, запуск криптографических утилит и доступ к конфигурационным файлам.

Как аудировать работу КриптоПРО?

Настройка auditd и правила для контроля МКД начинается с проверки службы:

sudo systemctl enable auditd && sudo systemctl start auditd

Проверьте состояние:

sudo systemctl is-active auditd

Важно: параметр -S в auditctl принимает имя системного вызова, а не имя команды setmmc. Для аудита запуска утилиты определите путь к бинарному файлу и установите правило наблюдения:

SETMMC_PATH=$(command -v setmmc)
sudo auditctl -w "$SETMMC_PATH" -p x -k setmmc_exec

Для аудита доступа к файлам с высокой меткой HIGH используйте:

sudo auditctl -w /path/to/high_label_file -p rwa -k high_label_access

Просмотр и фильтрация логов аудита выполняется командой ausearch:

sudo ausearch -k high_label_access -ts today

Проверка результата: команда sudo systemctl is-active auditd возвращает active, правило отображается в выводе sudo auditctl -l, а тестовый доступ к контролируемому файлу появляется в результатах ausearch. Правила, добавленные через auditctl, могут потребовать отдельной настройки постоянной загрузки после перезагрузки.

Аудит криптографических операций и доступа

Для отслеживания использования токенов добавьте правило, отслеживающее доступ к устройству токена:

sudo auditctl -w /dev/bus/usb -p r -k token_access

Аудит генерации ключей через КриптоПРО можно настроить путем отслеживания запуска процесса certmgr:

sudo auditctl -w /opt/cprocsp/bin/amd64/certmgr -p x -k certmgr_exec

Не забудьте также настроить аудит доступа к конфигурационным файлам криптографических систем, например, /opt/cprocsp/keys/:

sudo auditctl -w /opt/cprocsp/keys/ -p rwa -k crypto_keys_access

Проверяйте правила командой sudo auditctl -l, а события — через sudo ausearch -k certmgr_exec -ts today или соответствующий ключ правила.

Централизованный сбор логов и реагирование

Для отправки логов auditd на центральный сервер через rsyslog настройте в файле /etc/rsyslog.conf:

module(load="imfile")
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="audit"
      Severity="info")

*.* @central-log-server:514

Проверьте, что файл /var/log/audit/audit.log существует, rsyslog имеет доступ к его чтению, а центральный сервер принимает сообщения на указанном порту. Перед передачей событий убедитесь, что такой способ централизованного сбора разрешён политикой защищённого контура.

Пример простого скрипта для автоматического анализа логов и алертинга на события по ключу high_label_access:

#!/bin/bash
LOG_EVENT=$(sudo ausearch -k high_label_access -ts today 2>/dev/null)
if [ -n "$LOG_EVENT" ]; then
    echo "КРИТИЧЕСКОЕ СОБЫТИЕ: нарушение политики МКД" | mail -s "Alert Astra Linux" admin@example.com
fi

Этот скрипт можно запускать по cron каждые 10 минут. Для отправки уведомлений должен быть настроен почтовый транспорт, а ключ high_label_access должен соответствовать реально загруженному правилу auditd.

Резюме раздела: Вы активировали auditd, создали правила для отслеживания запуска setmmc, доступа к файлам и криптоопераций, настроили централизованный сбор логов и базовый алертинг. Для комплексного подхода к аудиту инфраструктуры изучите руководство по аудиту безопасности DevOps-цепочек.

Практические сценарии развертывания в защищённых контурах

Следующие сценарии демонстрируют, как объединить все рассмотренные инструменты для решения реальных задач в корпоративной среде. Перед применением замените тестовые метки, пути и адреса на значения из вашего регламента.

Сценарий: Изолированное рабочее место для обработки секретных данных

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

1. Создайте отдельную сессию с меткой TOP_SECRET: sudo astra-session --label TOP_SECRET --isolate.
2. Назначьте существующим файлам с секретными данными эту же метку: setmmc -f /secret/data/* -l TOP_SECRET.
3. В политиках (/etc/astra-mmc/policy.conf) разрешите передачу данных из TOP_SECRET в метку MEDIUM только через специальный каталог с криптографической подписью: allow TOP_SECRET -> MEDIUM /var/approved_transfer/;.
4. Настройте аутентификацию в сессии через аппаратный токен, добавив PAM-модуль.
5. Включите детальный аудит всех действий, попадающих под заданные правила: sudo auditctl -w /secret/data/ -p rwa -k top_secret_audit и SETMMC_PATH=$(command -v setmmc); sudo auditctl -w "$SETMMC_PATH" -p x -k label_change.

Проверка сценария выполняется по трём признакам: сессия запускается с меткой TOP_SECRET, доступ к данным из неподходящего уровня запрещается, а разрешённые действия появляются в результатах ausearch -k top_secret_audit -ts today. Такой подход обеспечивает изоляцию, контролируемый выход данных и трассировку действий, попавших под заданные правила.

Сценарий: Сервер веб-приложения с криптографической защитой

Цель: развернуть веб-сервер Nginx, обслуживающий приложение, с использованием отечественного TLS и под контролем мандатных меток.

1. Установите КриптоПРО CSP и подготовьте сертификат для домена, как описано выше.
2. Настройте Nginx для использования этого сертификата и провайдера «cprocsp» только при наличии поддержки такой интеграции в сборке.
3. Присвойте процессу Nginx и файлам его конфигурации специальную метку WEB_SERVER: setmmc -p $(pidof nginx) -l WEB_SERVER и setmmc -f /etc/nginx/nginx.conf -l WEB_SERVER.
4. В политиках разрешите процессу с меткой WEB_SERVER читать статические файлы приложения (метка APP_DATA) и записывать логи (метка LOGS): allow WEB_SERVER -> APP_DATA /var/www/app/; и allow WEB_SERVER -> LOGS /var/log/nginx/;.
5. Настройте аудит изменений конфигурации и попыток доступа к файлам Nginx: sudo auditctl -w /etc/nginx/ -p rwa -k nginx_config_access.

Перед запуском проверьте конфигурацию командой sudo nginx -t, затем выполните тестовый TLS-запрос и проверьте события командой sudo ausearch -k nginx_config_access -ts today. Такой подход обеспечивает криптографическую защиту трафика, разграничение доступа на уровне файлов и детальный аудит изменений.

Шпаргалка команд и скриптов для администратора

Готовый чек-лист основных команд для быстрого повторения:

Пример скрипта для автоматического применения политик после обновления системы:

#!/bin/bash
# Скрипт восстановления политик МКД после apt upgrade
POLICY_DIR=/etc/astra-mmc/policies
for policy in "$POLICY_DIR"/*.policy; do
    [ -f "$policy" ] || continue
    sudo mmc-load-policy "$policy" || exit 1
    echo "Загружена политика: $policy"
done

Пример скрипта для проверки состояния службы аудита и её логов:

#!/bin/bash
if systemctl is-active --quiet auditd; then
    echo "Служба auditd активна."
    START_TIME=$(date -d '24 hours ago' '+%m/%d/%Y %H:%M:%S')
    LOG_COUNT=$(sudo ausearch -ts "$START_TIME" 2>/dev/null | grep -c '^type=')
    echo "За последние 24 часа записано $LOG_COUNT событий."
else
    echo "ВНИМАНИЕ: служба auditd не активна!"
    sudo systemctl start auditd
fi

Перед переносом скриптов в рабочую среду проверьте права на запуск, пути к файлам, наличие почтового транспорта и сохранность правил после перезагрузки. Для решения других задач автоматизации, таких как массовое назначение меток файлам или централизованный сбор логов, обратитесь к нашему практическому гайду по автоматизации инфраструктуры. Также, для обеспечения безопасности других компонентов инфраструктуры, например, баз данных, полезным будет полное руководство по безопасности MySQL.

FAQ: Часто задаваемые вопросы по Astra Linux SE 2026

Как быстро проверить, что МКД работает в Astra Linux SE 2026?

Выполните setmmc -p для просмотра метки текущего процесса и setmmc -f /path/to/file для проверки метки файла. Это подтверждает доступность операций с метками, но не заменяет функциональную проверку. Создайте тестовый файл с меткой HIGH и попробуйте прочитать его из сессии с меткой LOW — доступ должен быть запрещён действующей политикой МКД.

Что делать, если КриптоПРО CSP не видит Рутокен?

Сначала проверьте физическое подключение токена через lsusb. Затем выполните /opt/cprocsp/bin/amd64/csptest -keyset -verify и убедитесь, что установлены необходимые библиотеки: sudo apt install libssl3 libc6 -y. Если USB-устройство видно, но КриптоПРО CSP его не видит, проверьте права доступа к устройству, совместимость пакетов и наличие лицензии. Те же шаги применимы для первичной проверки JaCarta. Переустановку пакетов cprocsp-pki-*.deb и cprocsp-ca-*.deb выполняйте только после проверки этих условий.

Почему не применяются политики МКД?

Проверьте выбранный профиль через sudo dpkg-reconfigure astra-mmc, точный путь к файлу политики и результат команды sudo mmc-load-policy /etc/astra-mmc/policies/operator.policy. Затем проверьте метки процесса и файла командами setmmc -p и setmmc -f /path/to/file. Частые причины проблемы — ошибка в синтаксисе правила, несовпадение метки субъекта или объекта и попытка проверить политику до её фактической загрузки.

Как настроить автоматическое применение политик МКД после перезагрузки?

Добавьте команду sudo mmc-load-policy /etc/astra-mmc/policies/operator.policy в файл /etc/rc.local перед строкой exit 0 или создайте systemd-юнит. Готовый скрипт для массовой загрузки политик приведён в разделе «Шпаргалка команд и скриптов для администратора». Сначала проверьте ручную загрузку политики, а затем убедитесь, что автоматический механизм запускается с нужными правами.

Можно ли использовать КриптоПРО CSP с Nginx для TLS-соединений?

Да, если используемая сборка Nginx и подключённый модуль поддерживают интеграцию с КриптоПРО CSP. В конфигурации указываются параметры ssl_certificate, ssl_certificate_key и, при наличии поддержки, ssl_provider "cprocsp". Перед перезапуском выполните sudo nginx -t. Ошибка unknown directive "ssl_provider" означает, что текущая сборка не знает эту директиву.

Что делать, если Nginx возвращает ошибку при интеграции с КриптоПРО?

Сначала выполните sudo nginx -t и определите тип ошибки. При сообщении об неизвестной директиве проверьте сборку или модуль интеграции КриптоПРО CSP. При ошибке доступа к сертификату или ключу проверьте существование файлов, права чтения для процесса Nginx и метки МКД. Не заменяйте конфигурацию на произвольные параметры SSL без проверки того, какой криптографический провайдер фактически поддерживает ваша сборка.

Что делать, если auditd не пишет события?

Проверьте службу командой sudo systemctl is-active auditd, список правил — командой sudo auditctl -l, а наличие записей — через sudo ausearch -ts today. Убедитесь, что правило действительно загружено и использует корректный ключ. Для контроля запуска setmmc не указывайте имя команды в параметре -S: используйте путь к исполняемому файлу с правилом -w, как в разделе аудита. Также проверьте доступность файла /var/log/audit/audit.log и настройки постоянной загрузки правил.

Как настроить алертинг при нарушении политики МКД?

Используйте auditd для записи событий по ключу правила, затем передайте результаты ausearch в скрипт уведомлений. В примере из статьи используется ключ high_label_access и команда mail. Перед эксплуатацией проверьте, что ключ соответствует нужному правилу, а почтовый транспорт действительно доставляет сообщения администратору.