Шифрование данных на дисках и в файловых системах: практическое руководство по LUKS, BitLocker и ZFS

LUKS шифрует блочное устройство в Linux через dm-crypt, BitLocker шифрует том Windows, ZFS native encryption шифрует отдельный датасет внутри пула. Три инструмента закрывают три разные задачи, и выбор диктует операционная система, а не личные предпочтения: для сервера на Linux берут LUKS, для парка ноутбуков на Windows берут BitLocker, для NAS и файловых хранилищ на OpenZFS или TrueNAS берут шифрование датасетов.

Разница видна на первом уровне. LUKS и BitLocker скрывают всё содержимое раздела, включая файловую систему, таблицы размещения файлов и остатки удалённых данных. ZFS шифрует данные и метаданные датасета, оставляя видимой структуру пула, имена датасетов, их размеры и свойства. Ключ нигде не лежит рядом с данными: он выводится из пароля через Argon2id или хранится в защищённом файле, и без него массив байт превращается в случайный шум.

Потеря ключа означает безвозвратную потерю данных. AES-256 не подбирается перебором ни на CPU, ни на GPU, восстановление через сервисный центр или лабораторию невозможно, поэтому резервный ключ, копия заголовка LUKS и recovery key BitLocker готовятся до того, как на диск попадёт первая полезная запись.

Зачем шифровать данные на уровне устройства и какой инструмент выбрать

Full-disk encryption (FDE) защищает сценарий, который не закрывают ни права доступа, ни сетевые экраны: физический доступ к носителю. Украденный ноутбук, изъятый из стойки диск, подобранный внешний SSD, проданный по ошибке сервер с массивами. Если данные лежат в открытом виде, злоумышленнику достаточно подключить диск к своей системе.

Чем FDE отличается от шифрования отдельных файлов

Шифрование на уровне файлов работает с выборкой: Cryptomator, gocryptfs, eCryptfs, EFS в Windows. Оно удобно для облачных хранилищ и общих каталогов, но оставляет в открытом виде много сопутствующих данных. Метаданные, имена файлов (в разных схемах), временные копии офисных приложений, кэш браузера, файл подкачки, журналы, теневые копии, свободные секторы после удаления файлов. Подробнее о компромиссах между клиентским и серверным подходом рассказано в разборе клиентского, серверного и гибридного шифрования.

FDE шифрует весь блочный носитель целиком. Файл подкачки, гибернация, журналы СУБД, удалённые файлы, неразмеченные секторы, остатки от предыдущих разделов. Сценарий с кражей ноутбука закрывается именно так: восстановить содержимое из неиспользуемых секторов не получится, потому что неиспользуемых секторов в зашифрованном виде не существует.

Границы защиты тоже нужно понимать. Пока система работает, данные расшифрованы в оперативной памяти, и атаки класса cold boot, а также прямой доступ по DMA через Thunderbolt и PCIe обходят шифрование. Hibernation-файл на зашифрованном диске защищён, но дампы памяти в незашифрованном swap - уже нет. FDE не спасает от ransomware, от администратора с root, от вредоносного кода внутри работающей ОС.

Критерии выбора: ОС, уровень шифрования, управление ключами

Три критерия определяют выбор за минуту: операционная система, уровень шифрования и способ управления ключами.

Критерий	LUKS	BitLocker	ZFS native encryption
Операционная система	Linux, dm-crypt	Windows 10/11 Pro и Enterprise, Windows Server	OpenZFS 0.8+, TrueNAS, illumos
Уровень шифрования	Блочное устройство или раздел	Том Windows	Датасет или zvol
Алгоритмы	aes-xts-plain64 (512 бит), serpent, twofish; вывод ключа Argon2id	XTS-AES 128/256, AES-CBC	aes-256-gcm по умолчанию, aes-256-ccm, aes-128-gcm
Управление ключами	До 32 key slots, пароль, keyfile, TPM2 через systemd-cryptenroll	TPM, PIN, USB startup key, recovery key, escrow в AD DS или Entra ID	keyformat=passphrase или raw, keylocation=prompt или file://
Разблокирование	cryptsetup luksOpen, /etc/crypttab	Автоматически через TPM, вручную recovery key	zfs load-key, zfs mount
Совместимость с RAID	Работает поверх mdadm и LVM, а также под ними	Storage Spaces, ограниченно	RAIDZ, зеркала, dRAID внутри пула

Общее правило одно для всех трёх: шифрование защищает конфиденциальность при потере носителя и не заменяет резервное копирование. Отказ диска, ошибка администратора и шифровальщик действуют одинаково успешно и на зашифрованных данных.

LUKS: шифрование диска в Linux

LUKS2 - формат по умолчанию в актуальных дистрибутивах: Debian, Ubuntu, RHEL, AlmaLinux, Rocky. Он хранит заголовок размером около 16 МиБ в начале устройства, поддерживает до 32 слотов для ключей и вывод ключа через Argon2id, что делает перебор пароля дорогим по памяти.

Создание зашифрованного тома LUKS: пошагово

Установите пакет: apt install cryptsetup на Debian и Ubuntu, dnf install cryptsetup на RHEL-семействе. Проверьте, что целевое устройство не содержит нужных данных: lsblk -f и blkid покажут текущие файловые системы, а wipefs -a /dev/sdb снимет старые сигнатуры.

Создание тома: cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --hash sha256 --pbkdf argon2id /dev/sdb. Команда запросит подтверждение вводом YES, а затем пароль. Ключ длиной 512 бит в режиме XTS означает два независимых 256-битных ключа, отдельно на шифрование и на твики.

Открытие тома и создание файловой системы:

cryptsetup luksOpen /dev/sdb cryptvol
mkfs.ext4 -L secure /dev/mapper/cryptvol
mount /dev/mapper/cryptvol /mnt/secure

Для XFS замените mkfs.ext4 на mkfs.xfs. Проверить состояние тома можно через cryptsetup luksDump /dev/sdb: вывод покажет версию формата, шифр, функцию вывода ключа и занятые слоты. Закрытие тома выполняется командой cryptsetup close cryptvol после umount.

Типичная ошибка на этом шаге - выбор не того устройства. Перед luksFormat сверяйте серийный номер через lsblk -o NAME,SIZE,SERIAL,MODEL и подключайте диски по стабильным путям /dev/disk/by-id/ вместо /dev/sdb.

Управление ключами LUKS: слоты, добавление и удаление

Каждый пароль или keyfile занимает отдельный слот. Добавление резервного ключа: cryptsetup luksAddKey /dev/sdb (сначала запрашивается существующий пароль, затем новый). Добавление файла-ключа: cryptsetup luksAddKey /dev/sdb /root/luks-sdb.key. Удаление конкретного ключа: cryptsetup luksRemoveKey /dev/sdb, удаление по номеру слота: cryptsetup luksKillSlot /dev/sdb 3. Смена пароля в слоте: cryptsetup luksChangeKey /dev/sdb -S 0.

Практическая схема: пользовательский пароль в слоте 0, keyfile для автоматического монтирования в слоте 1, recovery-пароль на бумаге в сейфе в слоте 2. Удаление последнего ключа делает том нечитаемым навсегда, поэтому перед чисткой слотов проверяйте luksDump и держите рабочий ключ под рукой.

Автоматизация в /etc/crypttab: строка вида cryptvol UUID=ваш-uuid /root/luks-sdb.key luks,discard. Файл-ключ создаётся через dd if=/dev/urandom of=/root/luks-sdb.key bs=512 count=8 и правами chmod 600. Опция discard включает TRIM и раскрывает примерный объём занятых блоков на SSD, что для части угроз неприемлемо: тогда TRIM отключают и закладывают запас по производительности. Keyfile на незашифрованном корне ослабляет всю схему, поэтому для серверов без физической охраны используют привязку к TPM2 (systemd-cryptenroll --tpm2-device=auto с дополнительным PIN) или сетевую разблокировку через dropbear в initramfs.

Восстановление доступа к LUKS: заголовок и резервные ключи

Заголовок содержит сами ключевые слоты. Если он повреждён, том не открывается ни одним паролем. Копия делается один раз после создания: cryptsetup luksHeaderBackup /dev/sdb --header-backup-file /root/luks-sdb-header.img. Обратное восстановление: cryptsetup luksHeaderRestore /dev/sdb --header-backup-file /root/luks-sdb-header.img. Файл заголовка позволяет открыть том, поэтому храните его на отдельном носителе вне сервера, а не на самом шифруемом диске и не в том же корне, который он защищает.

Если пароль забыт, но резервный keyfile сохранён, доступ возвращается через cryptsetup luksOpen /dev/sdb cryptvol --key-file /root/luks-sdb.key, после чего в свободный слот добавляется новый пароль. Если утеряны и пароль, и все ключи, и копия заголовка, данные восстановить нельзя: в заголовке нет мастер-ключа, а в блоках данных нет ничего, кроме шума.

BitLocker: шифрование диска в Windows

BitLocker встроен в Windows 10 и 11 Pro и Enterprise, а также в Windows Server. Он шифрует том целиком, опирается на TPM для автоматической разблокировки при загрузке и на recovery key для аварийного доступа.

Как настроить BitLocker: GUI и PowerShell

Через интерфейс: Панель управления, раздел BitLocker, кнопка «Включить BitLocker», затем выбор способа хранения ключа восстановления и режима шифрования. Для новых установок Windows 10 и 11 по умолчанию применяется программное шифрование XTS-AES, а аппаратное шифрование самих SSD отключено из-за известных проблем с его реализацией в прошивках.

Через PowerShell то же самое делается скриптом: Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector. Параметр -UsedSpaceOnly ускоряет первый проход на дисках с данными, но свободное место остаётся нерасшифрованным до момента записи. Проверка состояния: manage-bde -status C:.

Усиление защиты добавляется PIN или USB-ключом: Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmAndPinProtector -Pin (Read-Host -AsSecureString) или -TpmAndStartupKeyProtector -StartupKeyPath "E:". Для доменных машин с проводной сетью работает BitLocker Network Unlock: система получает ключ от WDS-сервера при загрузке, и администратору не нужно вводить PIN на каждой перезагрузке.

Требования к железу: TPM версии 1.2 и выше, для связки с PIN и новыми сценариями нужен TPM 2.0. Групповые политики задают метод шифрования («Choose drive encryption method and cipher strength») и запрет аппаратного шифрования («Configure use of hardware-based encryption for fixed data drives»).

Управление ключами BitLocker: recovery key, TPM, AD DS

Просмотр защитников тома: manage-bde -protectors -get C:. Вывод покажет числовой пароль восстановления (48 цифр), идентификаторы и типы протекторов. Резервное копирование в Active Directory: manage-bde -protectors -adbackup C: -id {GUID-протектора}. В доменной среде escrow настраивается политикой «Store BitLocker recovery information in Active Directory Domain Services» с обязательной выгрузкой пароля восстановления и информации о TPM.

Для гибридных и облачных схем ключ сохраняется в Entra ID (бывший Azure AD) через Intune, тогда сотрудник видит свой recovery key в личном кабинете. Правило одно: recovery key не хранится на самом ноутбуке, не печатается на наклейке под клавиатурой и не лежит в общедоступной папке. Отдельно настраивается авторазблокировка съёмных и дополнительных томов: manage-bde -autounlock -enable D:.

Ротация ключей выполняется регулярно и обязательно после увольнения сотрудника, у которого был доступ к паролю восстановления: manage-bde -protectors -delete C: -type RecoveryPassword и повторное создание через manage-bde -protectors -add C: -RecoveryPassword.

Восстановление доступа к BitLocker: recovery key и сброс TPM

Частые причины запроса ключа: обновление прошивки, замена материнской платы, изменение порядка загрузки, обновление BIOS, сброс TPM. Система показывает экран восстановления и просит 48-значный пароль. Разблокировка в командной строке среды восстановления: manage-bde -unlock C: -RecoveryKey путь-к-файлу-с-ключом.

Если защитник TPM сломан, его удаляют и создают заново: manage-bde -protectors -delete C: -type Tpm, затем manage-bde -protectors -add C: -Tpm. Сброс TPM через tpm.msc без recovery key означает потерю доступа ко всем зашифрованным томам, привязанным к этому чипу. Перед очисткой TPM убедитесь, что пароль восстановления сохранён в AD DS или в защищённом хранилище.

Атака на режим TPM-only известна давно: без PIN злоумышленник с физическим доступом может извлечь ключ через DMA или холодную перезагрузку, поэтому для ноутбуков, выезжающих за пределы офиса, разумно включать TPM и PIN либо требовать дополнительный startup key.

ZFS: нативное шифрование в файловой системе

Native encryption появилось в OpenZFS 0.8 и работает в TrueNAS, Proxmox, Ubuntu, Debian, FreeBSD. Шифрование задаётся на датасете, наследуется дочерними датасетами и применяется к zvol, что позволяет закрыть отдельные виртуальные диски и каталоги, не трогая весь пул.

Создание зашифрованного датасета ZFS: пошагово

Создание с парольной фразой: zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/secure. После создания изменить параметр encryption нельзя: включить шифрование на существующем датасете невозможно, данные пересоздаются через zfs send и zfs receive в новый зашифрованный датасет.

Вариант с keyfile: zfs create -o encryption=on -o keyformat=raw -o keylocation=file:///etc/zfs/keys/tank-secure.key tank/secure. Для raw-ключа заранее создаётся файл ровно 32 байта: dd if=/dev/urandom of=/etc/zfs/keys/tank-secure.key bs=32 count=1, права chmod 600, владелец root. Алгоритм по умолчанию aes-256-gcm, при необходимости указывается aes-256-ccm или aes-128-gcm параметром -o encryption=aes-256-ccm.

Наследование: датасет tank/secure/data с параметром encryption=inherit открывается тем же ключом, что и родитель, и управляется одной командой zfs load-key -r tank/secure. Это удобно для разделения баз данных, домашних каталогов и резервных копий внутри одного пула.

Управление ключами ZFS: keyformat, keylocation, смена ключа

Проверка состояния: zfs get encryption,keystatus,keyformat,keylocation tank/secure. Значение keystatus=unavailable означает, что ключ не загружен и данные недоступны. Загрузка ключа: zfs load-key tank/secure или zfs load-key -a для всех датасетов. В TrueNAS те же действия выполняются через GUI: ключ шифрования привязан к датасету, его можно скачать файлом и загрузить обратно.

Смена ключа без перезаписи данных: zfs change-key -o keyformat=raw -o keylocation=file:///etc/zfs/keys/new.key tank/secure. Смена пароля выполняется тем же способом с keyformat=passphrase. Ключ стоит держать вне пула: файл на другом сервере, в менеджере секретов или на зашифрованном системном диске. Если ключ лежит в том же пуле и пул выходит из строя, вы теряете и данные, и ключ.

При keylocation=prompt ключ вводится при загрузке вручную, автоматическое монтирование требует keylocation=file:// и доступного файла. Смежные темы сжатия, дедупликации и шифрования внутри пула разобраны в материале про обработку данных в системах хранения.

Восстановление доступа к ZFS: загрузка ключа и монтирование

После перезагрузки доступ возвращается двумя командами: zfs load-key tank/secure и zfs mount tank/secure. Массовая загрузка: zfs load-key -a && zfs mount -a. Если ключ хранится в файле, проверьте, что он доступен до попытки монтирования: путь /etc/zfs/keys должен существовать, права 600, владелец root.

Потеря ключа для ZFS означает то же, что потеря пароля LUKS: данные не расшифровываются, поддержка не помогает, брутфорс aes-256-gcm бесполезен. Резервная копия ключа и текста парольной фразы хранится отдельно от пула. Для резервных копий на другой сервер используется zfs send с уже расшифрованного датасета, причём поток шифруется повторно при передаче через ssh или через параметр -w при отправке в зашифрованный приёмник.

Производительность шифрования: что важно знать

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

Влияние AES-NI на скорость шифрования

AES-NI, набор инструкций Intel и AMD, ускоряет AES в 5-10 раз относительно программной реализации. На процессоре с поддержкой AES-NI том LUKS с aes-xts-plain64 выдаёт порядка 1.5-3 ГБ/с на одном ядре, а приложения теряют 1-5% производительности относительно незашифрованного тома. Без AES-NI потолок падает до 100-200 МБ/с, и падение скорости в некоторых сценариях достигает 50%.

Все серверные процессоры последних поколений поддерживают AES-NI. Проверить наличие инструкции в Linux можно через grep -o aes /proc/cpuinfo: пустой вывод означает отсутствие поддержки, и тогда шифрование стоит планировать с запасом по CPU или использовать отдельный контроллер с криптоускорителем.

Как измерить накладные расходы шифрования

Первичная оценка: cryptsetup benchmark покажет скорость шифров и хешей, строка aes-xts 512b на современном CPU обычно даёт несколько ГБ/с. Реальное тестирование выполняется на живом томе: fio --name=seqread --rw=read --bs=1M --size=1G --direct=1 --filename=/dev/mapper/cryptvol и аналогичный запуск на незашифрованном разделе того же класса. Разница в IOPS и в задержке на 4K-блоках говорит больше, чем последовательные гигабайты.

Для ZFS проверьте zfs get encryption,compression на датасете и сравните fio на зашифрованном и незашифрованном датасете одного пула. Накладные расходы шифрования в ZFS на чтении и записи укладываются в единицы процентов при включённом AES-NI. Если упор идёт в случайные операции, помогает кэширование: практические конфигурации SLOG и L2ARC разобраны в руководстве по кэшированию в системах хранения.

Отдельная зона риска - аппаратное шифрование дисков и BitLocker: в 2018 году исследователи показали обход шифрования в ряде SSD и HDD с самостоятельным шифрованием, после чего Microsoft перевела новые установки Windows на программное шифрование. Если парк использует SSD с аппаратным шифрованием, политикой запретите его применение и зафиксируйте XTS-AES 256 в программной реализации.

Риски и типичные ошибки при шифровании дисков

Основной риск один: необратимая потеря доступа. Все остальные ошибки исправимы, эта - нет.

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

В LUKS мастер-ключ зашифрован ключом, который выводится из пароля через Argon2id, и лежит в заголовке. Нет ни пароля, ни копии заголовка - нет доступа. В BitLocker recovery key выводится из аппаратных компонентов и хранится в TPM, а сброс TPM без копии ключа закрывает том. В ZFS мастер-ключ зашифрован ключом датасета, и без keyfile или парольной фразы данные выглядят как случайные блоки.

Брутфорс не работает: 256-битный ключ невозможно перебрать ни на CPU, ни на кластере GPU. Реальный сценарий провала выглядит буднично: диск перенесли в новый сервер, заголовок LUKS остался на старом, а резервной копии никто не делал.

Чек-лист перед включением шифрования

Резервная копия данных на отдельном носителе, проверенная восстановлением, а не фактом создания.
Копия заголовка LUKS: cryptsetup luksHeaderBackup на внешний носитель.
Recovery key BitLocker выгружен в AD DS или Entra ID, а не оставлен только в файле на самом ноутбуке.
Ключ ZFS хранится вне пула, доступен при загрузке, права 600 на файл.
Тестовое восстановление: открыть том другим ключом, загрузить датасет, смонтировать, прочитать файл.
Документированная процедура на случай ухода администратора: где лежат ключи и кто имеет к ним доступ.
Отдельный контроль за swap, файлом гибернации и временными каталогами на незашифрованных разделах.

Требования регуляторов закрываются тем же набором мер. GDPR, PCI DSS, HIPAA и ФЗ-152 ожидают шифрование данных на носителях и управляемый жизненный цикл ключей: практические схемы с аудитом доступа и разбором типовых ошибок собраны в руководстве по защите документов при хранении.

Сравнение LUKS, BitLocker и ZFS: что выбрать

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

LUKS vs BitLocker vs ZFS: таблица сравнения

Параметр	LUKS	BitLocker	ZFS native encryption
Платформа	Linux, dm-crypt	Windows, Windows Server	OpenZFS 0.8+, TrueNAS, Linux, FreeBSD
Гранулярность	Раздел или устройство	Том	Датасет или zvol, включая отдельные каталоги
Управление ключами	32 слота, пароль, keyfile, TPM2	TPM, PIN, USB, recovery key, AD DS, Entra ID	passphrase или raw key, keyfile вне пула
Производительность с AES-NI	Накладные расходы 1-5%	Сопоставимо	Единицы процентов на чтении и записи
Восстановление	Резервный ключ или копия заголовка	Recovery key, AD DS, Entra ID	keyfile или парольная фраза
Интеграция с RAID	mdadm, LVM, аппаратные контроллеры	Storage Spaces, ограниченно	RAIDZ, зеркала, dRAID внутри пула