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

Что LUKS защищает, а что — нет

LUKS (Linux Unified Key Setup) — стандартная в Linux спецификация формата шифрования блочных устройств, реализуемая через dm-crypt на уровне ядра. Прежде чем настраивать шифрование, важно чётко понимать модель угроз, от которой оно защищает, — LUKS обеспечивает шифрование данных в состоянии покоя (encryption at rest): содержимое диска нечитаемо без знания правильного секрета, если носитель физически изъят, украден или скопирован в выключенном или отсоединённом состоянии.

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

Практический вывод из этого разграничения: LUKS — правильный инструмент против кражи физического носителя (актуально в первую очередь для собственного оборудования и выделенных серверов, а не для VPS, где физический доступ к диску контролируется провайдером) и против сценариев, где выключенная копия диска или его снимок могут попасть в чужие руки (например, при неаккуратной утилизации старого оборудования или неконтролируемом копировании снапшотов виртуальной машины). Он не заменяет обычную защиту работающего сервера — firewall, SSH-безопасность, минимизацию поверхности атаки приложения.

Создание зашифрованного раздела через cryptsetup

Утилита cryptsetup — стандартный инструмент управления томами LUKS в большинстве дистрибутивов Linux. Процесс начинается с инициализации нового зашифрованного тома на выбранном блочном устройстве или разделе — эта операция необратимо уничтожает любые существующие данные на устройстве, поскольку записывает новый заголовок LUKS в его начало.

cryptsetup luksFormat /dev/sdb1
# WARNING!
# ========
# This will overwrite data on /dev/sdb1 irrevocably.
# Are you sure? (Type "yes" in capital letters): YES
# Enter passphrase for /dev/sdb1:

После инициализации том нужно разблокировать (открыть) — эта операция расшифровывает мастер-ключ из заголовка с помощью введённой парольной фразы и создаёт в системе временное отображаемое устройство в каталоге /dev/mapper, с которым дальше можно работать как с обычным блочным устройством: создать на нём файловую систему и смонтировать.

cryptsetup luksOpen /dev/sdb1 data_encrypted
mkfs.ext4 /dev/mapper/data_encrypted
mkdir -p /mnt/data
mount /dev/mapper/data_encrypted /mnt/data

Имя после cryptsetup luksOpen (в примере data_encrypted) — произвольное, выбираемое администратором, и используется только как идентификатор устройства в /dev/mapper на время, пока том разблокирован; после cryptsetup luksClose это отображаемое устройство исчезает, а сами зашифрованные данные остаются на физическом разделе в закрытом состоянии.

Разблокировка при загрузке: парольная фраза или файл-ключ

Для раздела, который должен монтироваться автоматически при каждой загрузке сервера, есть два принципиально разных подхода. Первый — интерактивный запрос парольной фразы в процессе загрузки, что подходит для системного раздела на собственном оборудовании с физическим доступом к консоли, но неудобно и часто вообще невозможно для VPS, где нет интерактивного доступа к процессу загрузки до поднятия сети и SSH.

Второй, практически более распространённый на серверах, — файл-ключ (keyfile): случайно сгенерированный файл, который добавляется в качестве альтернативного секрета для того же тома LUKS и используется автоматически системой инициализации при загрузке без участия администратора.

# генерация случайного файла-ключа
dd if=/dev/urandom of=/etc/luks/data.key bs=1024 count=4
chmod 400 /etc/luks/data.key

# добавление файла-ключа как ещё одного способа разблокировки тома
cryptsetup luksAddKey /dev/sdb1 /etc/luks/data.key

# /etc/crypttab
data_encrypted  /dev/sdb1  /etc/luks/data.key  luks

# /etc/fstab
/dev/mapper/data_encrypted  /mnt/data  ext4  defaults  0  2

Критически важное условие безопасности этой схемы: сам файл-ключ должен находиться на разделе, который либо не зашифрован и физически недоступен без компрометации всей системы целиком (обычный корневой раздел VPS, доступ к которому и так означает полный контроль над сервером), либо на отдельном, ещё более защищённом томе. Права доступа к файлу-ключу должны быть максимально ограничены (chmod 400, только root), поскольку по сути этот файл эквивалентен парольной фразе в открытом виде, лежащей на диске.

Шифрование отдельного диска с данными против полного шифрования диска

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

Полное шифрование диска (Full Disk Encryption, включая системный раздел) даёт более полную защиту — в частности, скрывает от анализа физического носителя даже структуру файловой системы, установленное программное обеспечение и конфигурацию, — но требует отдельного, обычно небольшого незашифрованного раздела /boot для загрузчика (поскольку сам загрузчик на раннем этапе ещё не умеет работать с зашифрованными томами) и решения проблемы ввода парольной фразы при каждой загрузке без интерактивного доступа к серверу.

Для типичного сценария VPS-хостинга — где провайдер физически контролирует дисковую подсистему датацентра, а угроза кражи конкретно этого физического диска маловероятна по сравнению с угрозой компрометации самой работающей операционной системы — шифрование отдельного тома с наиболее чувствительными данными обычно даёт достаточный практический эффект при заметно меньшей операционной сложности, чем полное шифрование всего диска с необходимостью автоматической загрузки без интерактивного ввода пароля.

Резервное копирование и восстановление заголовка LUKS

Заголовок LUKS, расположенный в начале зашифрованного раздела, хранит не сами данные, а несколько key slot — зашифрованных разными секретами копий одного и того же мастер-ключа, которым в действительности зашифровано содержимое раздела. Повреждение заголовка (например, из-за сбойного сектора диска, ошибочной операции разметки или случайной перезаписи начала раздела) делает данные безвозвратно недоступными, даже если верная парольная фраза точно известна, — без заголовка расшифровать мастер-ключ попросту нечем.

cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/luks-header-sdb1.img

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

cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file /root/luks-header-sdb1.img

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

Смена парольной фразы и управление несколькими key slot

LUKS поддерживает до нескольких (обычно до восьми) независимых key slot для одного тома — каждый слот содержит свою, независимо зашифрованную копию одного и того же мастер-ключа, что позволяет иметь несколько разных способов разблокировки одного и того же тома без повторного шифрования данных при добавлении, удалении или замене любого из них.

# просмотр занятых слотов
cryptsetup luksDump /dev/sdb1

# смена существующей парольной фразы
cryptsetup luksChangeKey /dev/sdb1

# удаление конкретного слота (например, скомпрометированной парольной фразы)
cryptsetup luksKillSlot /dev/sdb1 1

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

Производительность и практические накладные расходы

Шифрование и расшифровка данных на лету через dm-crypt требуют вычислительных ресурсов процессора при каждой операции чтения и записи на зашифрованный том. Современные процессоры x86-64 включают аппаратные инструкции AES-NI, ускоряющие именно операции шифрования по алгоритму AES, который используется LUKS по умолчанию, — при их наличии накладные расходы на шифрование для типичной нагрузки веб-приложения или базы данных на VPS в большинстве случаев не становятся узким местом по сравнению с самой скоростью диска или сети.

# проверка поддержки AES-NI процессором
grep -o aes /proc/cpuinfo | head -1

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

Когда LUKS оправдан на VPS, а когда достаточно других мер

Шифрование диска через LUKS даёт наибольшую практическую пользу там, где реально существует риск попадания физического носителя в чужие руки в состоянии покоя: собственное оборудование, colocation, ситуации с обязательными требованиями к шифрованию данных по регуляторным причинам (обработка платёжных данных, персональных данных под определёнными юрисдикциями), или архивные резервные копии, физически переносимые между площадками на съёмных носителях.

На типичном VPS у крупного провайдера, где физический доступ к дисковой инфраструктуре датацентра сам по себе строго ограничен и контролируется провайдером, а реальная угроза для большинства проектов — компрометация именно работающей операционной системы через уязвимости приложения или слабую защиту доступа, шифрование диска не заменяет и не снижает приоритет базовой защиты: правильно настроенный firewall, отключённый вход по паролю в SSH, регулярные обновления и минимально необходимый набор запущенных сервисов.

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

Особый случай: шифрование раздела подкачки

Раздел подкачки (swap) заслуживает отдельного внимания при планировании шифрования, поскольку в него операционная система может выгружать страницы оперативной памяти, включая потенциально чувствительные данные — пароли, ключи сессий, содержимое базы данных, временно оказавшееся в памяти процесса. Незашифрованный swap на диске с шифрованием только раздела данных сводит на нет часть защиты: те же самые чувствительные данные могут осесть на физическом носителе в открытом виде через механизм подкачки, минуя шифрование основного раздела.

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

# /etc/crypttab — шифрование swap случайным ключом при каждой загрузке
swap_encrypted  /dev/sdb2  /dev/urandom  swap,cipher=aes-xts-plain64,size=256

# /etc/fstab
/dev/mapper/swap_encrypted  none  swap  sw  0  0

Такая схема не требует управления парольной фразой или файлом-ключом специально для swap и полностью автоматизируется на уровне загрузки системы — единственное следствие использования случайного ключа при каждой загрузке в том, что содержимое swap с прошлой сессии становится полностью и безвозвратно нечитаемым после перезагрузки, что для назначения этого раздела (временная выгрузка памяти) не является проблемой.

Диагностика типичных проблем при работе с LUKS

Наиболее частая практическая проблема — том с шифрованием не разблокируется автоматически при загрузке, хотя парольная фраза или файл-ключ введены верно. В большинстве случаев причина в опечатке или несоответствии UUID устройства в /etc/crypttab, особенно после замены диска или изменения порядка подключения дисков контроллером, при котором имя устройства вида /dev/sdb может смениться на /dev/sdc — использование UUID вместо прямого имени устройства в crypttab устраняет эту категорию проблем.

# получить UUID зашифрованного раздела
blkid /dev/sdb1
# /dev/sdb1: UUID="a1b2c3d4-..." TYPE="crypto_LUKS"

# использовать UUID вместо имени устройства в crypttab
# data_encrypted  UUID=a1b2c3d4-...  /etc/luks/data.key  luks

Вторая типичная ситуация — ошибка «No key available with this passphrase» при попытке разблокировки: она означает либо действительно неверно введённую парольную фразу, либо (реже, но серьёзнее) повреждение конкретного key slot, в котором эта фраза хранится, при сохранности остальных слотов и самих данных. Проверка состояния заголовка через luksDump помогает отличить одну ситуацию от другой до того, как предпринимать более радикальные шаги вроде восстановления из резервной копии заголовка.

cryptsetup luksDump /dev/sdb1 | grep -A2 "Keyslot"

Третья ситуация — снижение производительности сразу после создания нового зашифрованного тома, объясняемое не самим шифрованием, а фоновым процессом инициализации (в некоторых конфигурациях LUKS2 выполняет дополнительную начальную обработку метаданных) — эта нагрузка временная и проходит после завершения инициализации, что стоит учитывать при бенчмаркинге нового зашифрованного раздела сразу после его создания, чтобы не сделать ошибочный вывод о постоянных накладных расходах шифрования.