Шифрование дисков с ГОСТ в НАЙС.ОС

НАЙС.ОС CLOUD позволяет шифровать дисковые разделы, дополнительные накопители и файловые контейнеры алгоритмом «Кузнечик» (ГОСТ Р 34.12-2015). Шифрование осуществляется в ядре Linux через Kernel Crypto API и dm-crypt, а создание, открытие и обслуживание защищённых томов выполняет cryptsetup. Для хранения метаданных, управления паролями и ключевыми слотами используется LUKS2.

Это руководство охватывает полный путь: проверку встроенного ГОСТ в ядре, создание учебного контейнера, работу с данными, подключение дополнительного физического диска, автоматическое открытие томов, подготовку ранней загрузки через dracut и восстановление доступа. Разделы по корневому разделу и initramfs, реальным дискам, восстановлению и диагностике дополняют основную статью, не повторяя её команд.

Не форматируйте системный диск по образцу учебной лаборатории

cryptsetup luksFormat, mkfs.ext4, создание новой таблицы разделов и операции записи по блочному устройству могут безвозвратно уничтожить данные. На работающем сервере сначала используйте файл-образ, затем отдельный пустой диск. Перевод уже работающего корневого раздела на шифрование — самостоятельная процедура миграции с резервным копированием и восстановлением из внешней среды; это не операция «на месте» по одной команде.

Какие задачи решает дисковое шифрование

Дисковое шифрование прежде всего защищает данные на выключенном или отключённом носителе: при краже накопителя, утилизации, выносе диска из сервера или доступе к сырому образу тома без ключа. После открытия LUKS и монтирования файловой системы авторизованные процессы видят обычные файлы — тогда доступ дополнительно регулируют права UNIX, SELinux, учётные записи и политика резервного копирования.

Шифрование диска не заменяет контроль целостности, защиту от вредоносного ПО, шифрование сетевого соединения и безопасность работающей виртуальной машины. Администратор гипервизора с доступом к памяти запущенной ВМ может обладать возможностями, недоступными человеку с одним лишь образом выключенного диска.

Где находится «Кузнечик»

Приложение / база данных / файловая система
                    │ чтение и запись
                    ▼
                ext4 / XFS
                    │
                    ▼
        /dev/mapper/<имя-тома>
                    │
                    ▼
             dm-crypt / LUKS2
                    │
                    ▼
            Linux Kernel Crypto API
                    │
                    ▼
        встроенный xts(kuznyechik) НАЙС.ОС
                    │
                    ▼
          Физический диск / раздел / файл-образ

cryptsetup при открытии контейнера формирует отображение device-mapper и передаёт ядру параметры шифрования. Чтение и запись секторов шифруются в ядре, поэтому загружать openssl-gost-engine ради уже работающего dm-crypt не требуется. OpenSSL и криптографический Provider применяются в других компонентах системы, а здесь работающий алгоритм подтверждается cryptsetup status, /proc/crypto и практическим чтением данных.

Из чего состоит защищённый том

Уровень	Назначение в НАЙС.ОС
«Кузнечик»	Блочный шифр с блоком 128 бит и ключом 256 бит
XTS	Режим шифрования секторов; применяет два независимых ключа «Кузнечика»
plain64	Формирует значение для привязки шифрования к номеру сектора
dm-crypt	Прозрачное шифрование чтения и записи блочных устройств
LUKS2	Заголовок, параметры алгоритма, ключевые слоты и управление доступом
cryptsetup	Создание, открытие, изменение паролей, закрытие и аудит LUKS
dracut/initramfs	Разблокирование тома до монтирования корневой файловой системы

Рекомендуемый и подтверждённый на НАЙС.ОС профиль шифрования полезных данных:

cipher:   kuznyechik-xts-plain64
keysize:  512 бит суммарно для XTS
format:   LUKS2

512 бит — длина всего материала двух ключей XTS (по 256 бит), а не утверждение о 512-битной стойкости. Для дисковых секторов XTS подходит по назначению лучше, чем прямой ECB или обычный CBC. XTS обеспечивает конфиденциальность, но не аутентифицирует содержимое секторов и не защищает сам по себе от злонамеренной подмены зашифрованных блоков.

Почему в luksDump рядом с «Кузнечиком» виден AES

В LUKS2 различаются ключ шифрования полезных данных и средства защиты ключевых слотов. В рабочем испытании НАЙС.ОС получена следующая комбинация:

Data segments:
    cipher: kuznyechik-xts-plain64
Keyslots:
    Cipher: aes-xts-plain64
    PBKDF: argon2id
Digests:
    Hash: sha256

Это не ошибка и не означает, что файловая система зашифрована AES. «Кузнечик» используется для секторов с данными, а AES защищает материал ключевого слота в заголовке. Argon2id преобразует пароль в материал для открывания ключевого слота; SHA-256 участвует в соответствующих операциях метаданных. Поэтому в этой конфигурации корректно говорить «ГОСТ-шифрование данных в LUKS2», а не «абсолютно все криптографические операции LUKS выполняются по ГОСТ».

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

1. Подготовка и безопасная диагностика

Перед использованием физического диска изучите правила выбора устройства. Для учебной лаборатории нужны только Python, доступ к AF_ALG, ядро со встроенными ГОСТ-алгоритмами, cryptsetup, losetup и mkfs.ext4.

Проверяем работающее ядро НАЙС.ОС и параметры встроенной криптографии:

uname -r
grep '^CONFIG_CRYPTO_NICEOS_GOST_KUZNYECHIK=y' "/boot/config-$(uname -r)"
less "/boot/KERNEL_GOST_README-$(uname -r).txt"
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS

Для встроенного ГОСТ проверяются параметры CONFIG_*=y именно запущенного ядра. Поскольку «Кузнечик» является частью образа ядра, нет отдельного устанавливаемого криптомодуля. Проверку доступности дискового режима выполняют через xts(kuznyechik) в Linux Crypto API и сквозной тест LUKS2.

Проверяем регистрацию нужного алгоритма через AF_ALG — без создания томов и изменения файлов:

python3 - <<'PY'
import socket
for cipher in ('cbc(kuznyechik)', 'xts(kuznyechik)'):
    try:
        with socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0) as s:
            s.bind(('skcipher', cipher))
        print(cipher, '— доступен')
    except OSError as error:
        print(cipher, '— ошибка:', error)
PY

Обе строки «доступен» подтверждают регистрацию Crypto API, но сами по себе ещё не проверяют правильность преобразования данных. Для проверки реального шифрования и обратного преобразования воспользуйтесь практическими тестами ядра и затем учебным томом ниже.

Если cryptsetup не установлен, установите его из репозитория НАЙС.ОС:

sudo tdnf install cryptsetup
cryptsetup --version

Вместо tdnf допустим dnf, если он установлен и используется на данном сервере. Для предоставленного стенда были доступны функции cryptsetup UDEV, BLKID, KEYRING, KERNEL_CAPI, PWQUALITY, HW_OPAL.

2. Полная лаборатория: контейнер LUKS2 в файле

Этот сценарий проверен на НАЙС.ОС CLOUD. Он не затрагивает /dev/vda или другие реальные диски и является отправной точкой для остальных руководств.

Создаём чистый файл-образ

Выделяем 128 МиБ и убеждаемся, что имя файла указано правильно:

mkdir -p "$HOME/gost-storage-lab"
IMG="$HOME/gost-storage-lab/scratch.img"
truncate -s 128M "$IMG"
ls -lh "$IMG"

truncate создаёт файл заданной длины; выделение реальных блоков на хостовой файловой системе может быть отложенным. Учебный образ предназначен только для лаборатории. Не храните в нём единственную копию важных данных.

Создаём loop-устройство

IMG="$HOME/gost-storage-lab/scratch.img"
losetup -j "$IMG"
LOOP_DEV=$(losetup --find --show "$IMG")
printf 'Тестовое устройство: %s\n' "$LOOP_DEV"
losetup -j "$IMG"

Важно: эту команду losetup --find --show выполняют один раз. При повторном запуске для того же файла появится ещё одно loop-устройство (/dev/loop1, /dev/loop2 и т. д.). Для повторных проверок сначала ищите уже существующее отображение через losetup -j "$IMG", а не создавайте новое. Число после /dev/loop ничего не говорит о содержимом устройства.

Перед форматированием подтвердите, что loop указывает именно на лабораторный файл:

losetup -l "$LOOP_DEV"
lsblk -f "$LOOP_DEV"

Создаём LUKS2 с «Кузнечиком»

Форматирование уничтожает предыдущий заголовок и структуру тома

Следующий вызов выполняется только для учебного scratch.img, отображённого в LOOP_DEV. При повторном формате уничтожатся и прежний ключ, и файловая система.

cryptsetup luksFormat \
  --type luks2 \
  --cipher kuznyechik-xts-plain64 \
  --key-size 512 \
  --verify-passphrase \
  "$LOOP_DEV"

На запрос подтверждения введите YES, а затем дважды — длинную уникальную парольную фразу. Проверка PWQUALITY может отклонять короткие и словарные пароли. Ошибка качества пароля не означает, что алгоритм «Кузнечик» не поддерживается.

После успешного завершения:

cryptsetup isLuks "$LOOP_DEV" && echo 'Заголовок LUKS найден'
cryptsetup luksUUID "$LOOP_DEV"
cryptsetup luksDump "$LOOP_DEV"

luksDump выводит метаданные, но не содержимое секретного ключа. Тем не менее не публикуйте полный отчёт из рабочего хранилища без проверки на служебные идентификаторы и детали инфраструктуры.

Открываем контейнер

cryptsetup open "$LOOP_DEV" niceos_gost_lab
cryptsetup status niceos_gost_lab

В выводе должна присутствовать строка cipher: kuznyechik-xts-plain64. Команда открывает отображение /dev/mapper/niceos_gost_lab; до открытия этого отображения не существует. Именно поэтому mkfs.ext4 или mount завершатся ошибкой, если выполнить их раньше cryptsetup open.

Создаём файловую систему внутри шифрованного тома

Форматируйте только /dev/mapper/niceos_gost_lab

Никогда не подставляйте вместо него /dev/vda, /dev/vda3, каталог /dev или устройство, на котором находится /. Для рабочего диска файл-образ и имя отображения будут другими — см. отдельную инструкцию.

mkfs.ext4 /dev/mapper/niceos_gost_lab
mkdir -p "$HOME/gost-storage-lab/mnt"
mount /dev/mapper/niceos_gost_lab "$HOME/gost-storage-lab/mnt"
findmnt "$HOME/gost-storage-lab/mnt"

Создаём файл, читаем его и сохраняем контрольную сумму:

MNT="$HOME/gost-storage-lab/mnt"
printf '%s\n' 'НАЙС.ОС: тест ГОСТ Кузнечик' > "$MNT/test.txt"
sync
cat "$MNT/test.txt"
sha256sum "$MNT/test.txt"
cryptsetup status niceos_gost_lab

Чтение и запись проходят через /dev/mapper/... и dm-crypt; ядро шифрует данные для хранения в scratch.img. Открытие файла через смонтированную файловую систему возвращает прозрачный для приложения текст.

Закрываем том правильно

umount "$HOME/gost-storage-lab/mnt"
cryptsetup close niceos_gost_lab
losetup -d "$LOOP_DEV"

Не удаляйте loop-устройство и не закрывайте dm-crypt, пока файловая система смонтирована или используется процессом. Если umount сообщает busy, выясните, кто удерживает каталог, через findmnt и fuser -vm, завершите обращения и повторите размонтирование.

Повторно открываем существующий том

Теперь ничего не форматируем. Проверяем сохранность того же файла на новом подключении:

IMG="$HOME/gost-storage-lab/scratch.img"
MNT="$HOME/gost-storage-lab/mnt"
LOOP_DEV=$(losetup -j "$IMG" | head -n 1 | cut -d: -f1)
if [ -z "$LOOP_DEV" ]; then
    LOOP_DEV=$(losetup --find --show "$IMG")
fi
cryptsetup isLuks "$LOOP_DEV" || { echo 'Это не LUKS'; exit 1; }
cryptsetup open "$LOOP_DEV" niceos_gost_lab
mount /dev/mapper/niceos_gost_lab "$MNT"
cat "$MNT/test.txt"
grep -Fx 'НАЙС.ОС: тест ГОСТ Кузнечик' "$MNT/test.txt"
sha256sum "$MNT/test.txt"
cryptsetup status niceos_gost_lab

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

Как интерпретировать результат стенда НАЙС.ОС

В эксплуатационной проверке получен результат:

/dev/mapper/niceos_gost_lab is active and is in use.
  type:    LUKS2
  cipher:  kuznyechik-xts-plain64
  keysize: 512 [bits]
  key location: keyring
  loop:    /root/gost-storage-lab/scratch.img
  sector size: 512 [bytes]
  mode:    read/write

Контрольная сумма тестового файла после закрытия и повторного открытия:

29b35eaf576cf79c37ca772ecf807de5bff93344fb8a0db65c361ca31fc53f49

В лабораторной проверке были успешно выполнены шифрование/расшифрование в режимах CBC и XTS через AF_ALG, инициализация LUKS2, создание ext4, запись данных, закрытие контейнера и его повторное открытие. Это практическое подтверждение работы связки НАЙС.ОС, а не только обнаружение имени шифра.

3. Что меняется при переходе от файла к настоящему диску

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

Рекомендуемый путь для нового пустого накопителя:

1. Определить диск командой lsblk, убедиться, что он не является системным и не содержит нужных данных.
2. Использовать постоянный путь /dev/disk/by-id/..., а не полагаться на изменяющийся номер /dev/sdb.
3. Создать раздел нужного размера вне рамок текущих рабочих томов.
4. Выполнить luksFormat для этого раздела, открыть его под осмысленным именем (niceos_secure).
5. Создать файловую систему внутри /dev/mapper/niceos_secure.
6. Настроить /etc/crypttab и /etc/fstab; проверить ручное открытие до первой перезагрузки.
7. Создать резервную копию LUKS-заголовка и записать сведения о восстановлении.

Полная инструкция и готовый проверочный чек-лист: шифрование физического диска.

Если на диске уже находятся данные, новый LUKS-том создают на другом носителе или после полной резервной копии, затем данные копируют, сверяют и только после этого выводят старый том из эксплуатации. Безопасная миграция корня / дополнительно описана в главе об initramfs.

4. Управление паролями и ключевыми слотами

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

Смотрим занятые слоты:

cryptsetup luksDump "$HOME/gost-storage-lab/scratch.img"

Добавляем новую парольную фразу к существующему тому (после проверки успешного доступа по старому паролю):

cryptsetup luksAddKey "$HOME/gost-storage-lab/scratch.img"

Программа запросит действующий пароль, затем новый. Перед удалением старой парольной фразы обязательно выполните отдельную проверку, что новый пароль открывает том. Для удаления применяется cryptsetup luksRemoveKey, но выполнять её нужно только после проверки второго способа восстановления и создания резервной копии заголовка: удаление последнего действующего ключа делает том недоступным.

Никогда не передавайте пароли прямо в аргументах команд или истории оболочки, например как --key-file с файлом в общедоступном каталоге. Для автоматического открытия корпоративных дисков требуется отдельная политика безопасного хранения секрета.

5. Принцип резервирования

При LUKS2 критичны и данные на носителе, и заголовок LUKS. Если повреждены ключевые слоты или служебные метаданные, пароль может перестать открывать полностью сохранившиеся зашифрованные данные.

Для учебного образа можно сохранить отдельную копию заголовка:

umask 077
IMG="$HOME/gost-storage-lab/scratch.img"
cryptsetup luksHeaderBackup "$IMG" \
  --header-backup-file "$HOME/gost-storage-lab/scratch-header.backup"
chmod 600 "$HOME/gost-storage-lab/scratch-header.backup"

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

Восстановление заголовка — опасная операция: оно может отменить последующие изменения ключевых слотов. Её нельзя выполнять на рабочем диске без проверенного плана. См. резервирование и восстановление.

6. Почему initramfs принципиален для корневого диска

Дополнительный том, открываемый после входа в систему, использует встроенный ГОСТ в ядре и установленный cryptsetup. Зашифрованный корень / должен быть открыт до того, как система сможет прочитать эти компоненты с корневого диска.

В раннем загрузочном окружении, созданном dracut, должны находиться:

• Механизм device-mapper и dm-crypt (как встроенные возможности ядра или доступные модули).
• Встроенный «Кузнечик» и доступный шаблон XTS в загруженном ядре; копирование ГОСТ-алгоритмов в initramfs не требуется. Возможности XTS проверяются через Crypto API и конфигурацию ядра.
• Драйверы контроллера хранения и файловой системы корневого тома.
• Пользовательские компоненты для разблокирования LUKS, включая systemd-cryptsetup или соответствующее средство dracut.
• Корректные идентификаторы LUKS и параметры корневого устройства.
• Механизм безопасного ввода парольной фразы или доступа к ключу на раннем этапе.

Встроенный «Кузнечик» не нуждается в .ko внутри initramfs. Для открытия зашифрованного корня требуются средства LUKS2, поддержка пароля и необходимые драйверы накопителя.

Подробная процедура: ГОСТ в dracut/initramfs и шифрование корня. Там же описано, как подготовить отдельный проверочный initramfs, не заменяя текущий загрузочный образ и без перезагрузки сервера.

7. Обслуживание тома

Для повседневной эксплуатации используйте cryptsetup status, lsblk, findmnt и journalctl. Состояние отображения active ещё не означает, что нужная файловая система смонтирована; различайте уровень LUKS и уровень файловой системы.

cryptsetup status niceos_secure
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
findmnt -t ext4,xfs,btrfs
journalctl -k -n 100 --no-pager

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

После обновления ядра убедитесь, что в образ нового ядра встроен «Кузнечик», а при зашифрованном / новый initramfs содержит все средства открытия LUKS2 и драйверы накопителя. Для сервера с удалённым доступом обновление проводят при наличии консоли гипервизора и проверенного пути отката.

8. Где заканчивается защита XTS

XTS не гарантирует аутентичность данных; злоумышленник, получивший запись на заблокированный носитель, может изменить зашифрованные блоки. Механизмы контроля целостности (например, соответствующим образом спроектированная защита метаданных или dm-integrity) оцениваются отдельно — они не включаются автоматически при выборе «Кузнечика».

ГОСТ-алгоритм сам по себе также не означает сертификацию всего программно-аппаратного комплекса в качестве СКЗИ. При необходимости выполнения регуляторных требований учитываются используемые средства защиты, условия их применения и соответствующая документация.

Следующие руководства

• Реальный накопитель: подготовка, LUKS, автоподключение.
• ГОСТ и ранняя загрузка: dracut/initramfs.
• Резервное копирование, ключи и восстановление.
• Диагностика неисправностей.
• Базовая архитектура dm-crypt в Kernel Crypto API.

Официальные справочные материалы

• cryptsetup — руководство и возможности LUKS.
• cryptsetup FAQ — устройство LUKS, XTS и модель угроз.
• dracut — параметры конфигурации.
• systemd crypttab — автоматическое открытие томов.

Встроенная криптография и существующие диски

При переходе НАЙС.ОС на встроенный ГОСТ алгоритм xts(kuznyechik) остаётся доступным через тот же Kernel Crypto API. Поэтому существующие LUKS2-контейнеры не требуют повторного luksFormat: шифротекст, пароли и заголовок остаются на носителе. После загрузки нового ядра выполните сквозной тест на резервной копии и убедитесь, что данные успешно открываются и закрываются. Подробный порядок миграции сохранён отдельно.

Для шифрованного корневого раздела новый механизм упрощает раннюю загрузку, но сам по себе не гарантирует её: драйверы, dracut, LUKS2, пароль и параметры GRUB2 остаются необходимыми. См. полное руководство по ранней загрузке.