Шифрование дисков на сервере: что защищает, а что нет

MAATRIX

Рано или поздно в требованиях к серверу появляется пункт «диски должны быть зашифрованы» — из регламента, от аудитора, от заказчика, а иногда просто из общего ощущения, что так безопаснее. Настроить LUKS несложно, но дальше обычно возникает вопрос, который никто не проговаривает вслух: а от чего это реально защищает? Ответ короче, чем кажется, и именно поэтому его стоит проговорить честно, до того как шифрование диска запишут в план как замену остальным мерам безопасности.

Что вообще происходит при шифровании диска

Шифрование на уровне блочного устройства (LUKS в связке с dm-crypt — стандарт для Linux) работает ниже файловой системы. Есть диск или раздел, есть ключ, и всё, что попадает на диск в виде блоков, шифруется этим ключом перед записью и расшифровывается при чтении. Файловая система (ext4, XFS, что угодно) монтируется поверх уже расшифрованного слоя и ничего не знает о шифровании — для неё это обычный блочный носитель.

Ключевой момент для понимания всей темы: пока раздел не разблокирован, содержимое диска — это неотличимый от случайного набор байт. Разблокировать раздел можно только зная ключ (или парольную фразу, из которой ключ выводится через KDF). Без ключа перебор бессмысленен — современные параметры LUKS2 (Argon2id по умолчанию) делают брутфорс парольной фразы вычислительно неподъёмным при разумной длине пароля.

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

Базовая настройка на новом сервере (LUKS для раздела с данными, если он не нужен сразу при загрузке):

# создать зашифрованный раздел
cryptsetup luksFormat /dev/sdb1

# открыть (запросит парольную фразу)
cryptsetup luksOpen /dev/sdb1 data

# создать файловую систему поверх открытого устройства
mkfs.ext4 /dev/mapper/data

# смонтировать
mount /dev/mapper/data /mnt/data

Это и есть тот самый момент «до» и «после»: до luksOpen содержимое /dev/sdb1 бессмысленно для любого, кто его читает напрямую. После — оно смонтировано в /mnt/data и живёт обычной жизнью файловой системы.

Сценарий, где шифрование диска реально работает

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

• диск физически украли — вынули из сервера в дата-центре, изъяли при обыске, украли сам сервер целиком;
• сервер (или диск) списали и утилизировали, не уничтожив данные;
• диск отправили в ремонт или на замену по гарантии, и он попал в руки третьей стороны;
• резервную копию на внешнем носителе (не в облаке, а физическом HDD/SSD) потеряли или её украли.

Во всех этих случаях диск выключен, раздел не разблокирован, файловая система не смонтирована. Тот, кто получил физический доступ, видит только блочное устройство с шифротекстом. Без ключа он не может подключить диск к другой машине и прочитать файлы, восстановить удалённые данные через forensic-инструменты, вытащить конфиги с паролями и приватными ключами. Это ровно то, ради чего шифрование диска существует, и здесь оно работает так, как заявлено.

Именно этот сценарий стоит за большинством регуляторных требований к шифрованию — GDPR, PCI DSS, отраслевые стандарты обычно формулируют требование именно как «защита от несанкционированного доступа при утере или краже носителя», а не как общую защиту от взлома. Если у вас есть такое требование — LUKS на сервере (или BitLocker/аналоги, если это Windows) действительно закрывает именно этот пункт.

Сценарий 1, где шифрование не защищает: взлом работающего сервера

Вот здесь начинаются завышенные ожидания. Представьте: сервер включён, диск разблокирован, файловая система смонтирована — то есть сервер находится в нормальном рабочем состоянии, как 99.9% времени своей жизни. Злоумышленник эксплуатирует уязвимость в приложении — SQL-инъекцию, RCE в веб-фреймворке, уязвимую библиотеку, слабый пароль в админке — и получает доступ через сеть.

С точки зрения этого злоумышленника диск зашифрован или нет — абсолютно не важно. Он не читает блочное устройство напрямую, он работает через уже запущенные процессы и смонтированную файловую систему. Для процесса, который читает /var/www/app/config.php или дампит таблицу пользователей из PostgreSQL, шифрование диска ниже файловой системы полностью прозрачно — оно расшифровало данные ещё на этапе монтирования, задолго до того, как в систему вообще кто-то попал.

Иначе говоря: шифрование диска защищает данные *в состоянии покоя* (data at rest). Атака через уязвимость приложения происходит на данные *в работе* (data in use) — и это принципиально другая модель угроз, для которой нужны принципиально другие меры: обновления, ограничение прав, сегментация сети, WAF, аудит кода. LUKS тут ни при чём не потому, что он плохо настроен, а потому что он не создан для этой задачи.

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

Сценарий 2, где шифрование не защищает: администратор гипервизора и снапшот памяти

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

• хранится в файле на том же хосте (initramfs с keyfile, автоматическая разблокировка при загрузке);
• прокидывается через vTPM или аналогичный механизм, физически привязанный к той же машине;
• вводится автоматически неким скриптом на стороне хостинг-провайдера.

Как только это происходит — модель угроз меняется. Ключ шифрования становится доступен на том же физическом хосте, где крутится ваша VM, а значит доступен и стеку виртуализации, который этой VM управляет. Администратор хостинг-провайдера с доступом к гипервизору технически может снять снапшот памяти работающей виртуальной машины (в KVM/QEMU это штатная операция, virsh dump или снапшот с сохранением состояния) и получить оттуда расшифрованные данные, ключи шифрования из оперативной памяти, содержимое открытых файлов — всё то, что в момент снятия снапшота находится в RAM в открытом виде.

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

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

Сценарий 3, где шифрование не защищает: вредоносное ПО внутри системы

Третий случай проще всего сформулировать, но его тоже часто упускают: шифровальщик (ransomware) или любое другое вредоносное ПО, которое запустилось внутри уже загруженной и расшифрованной системы, работает с файлами так же, как любой легитимный процесс — через смонтированную файловую систему. Для него, как и для взломщика из первого сценария, шифрование диска ниже файловой системы совершенно не существует как барьер.

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

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

Таблица: сценарий → защищает ли шифрование диска

Последняя строка отдельно важна: шифрование диска сервера и шифрование бэкапов — это две разные настройки, и одна не покрывает другую. Бэкап, который физически лежит на другом носителе (внешний диск, объектное хранилище, другой дата-центр), нуждается в собственном шифровании независимо от того, зашифрован ли исходный сервер. Это отдельно разобрано в статье про частые ошибки в шифровании бэкапов на сервере — там речь именно про то, что шифрование бэкапа нужно настраивать явно, а не предполагать, что оно «наследуется» от диска.

Практический вывод: где шифрование диска уместно, а где — театр безопасности

Шифрование диска стоит настраивать, если у вас есть один из этих случаев:

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

Оно НЕ заменяет и не является приоритетом, если основная угроза — это:

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

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

Частые вопросы