Аргумент в пользу шифрования арендованного сервера уже, чем предполагает маркетинг, но куда весомее в этих узких рамках. NVMe-накопители выходят из строя и возвращаются поставщику с вашими данными всё ещё на борту. Ноды выводят из эксплуатации, а хранилища перепродают. Оборудование снимают образом или выносят из стойки. В каждом из этих случаев LUKS — это разница между читаемой файловой системой — вашими ключами, вашей базой данных, вашим почтовым хранилищем — и блоком шума, с которым никто ничего не сделает.
Чего он не даёт — так это защиты от машины, на которой вы работаете. Это разграничение — суть всего руководства, поэтому оно идёт первым, ещё до единой команды. Дальше — сама работа: правильно созданный том LUKS2, резервная копия заголовка, зашифрованный swap, удалённая разблокировка по SSH и план восстановления на случай перезагрузки, после которой сервер не поднимается. Сервер под всем этим можно арендовать без ID и оплатить в Monero; шифрование — это слой, который вы добавляете поверх, а не замена ему.
Что на самом деле защищает шифрование данных в состоянии покоя
Полное шифрование диска отвечает на один вопрос и отвечает исчерпывающе: что произойдёт, если диск окажется в чужих руках, пока он выключен? На арендованной инфраструктуре это не гипотеза. Диски выходят из строя и возвращаются поставщику. Ноды выводят из эксплуатации, а их хранилища перепродают. С томов снимают образы в ходе расследования, или они покидают здание в ящике.
- В зоне защиты. Выключенный диск, офлайн-образ вашего тома, диск, возвращённый по гарантии, выведенная из эксплуатации нода, скопированный файл снапшота. В каждом из этих случаев атакующему достаются шифротекст и заголовок — без парольной фразы на этом история заканчивается.
- Вне зоны защиты: работающая машина. Как только том открыт, ключ оказывается в памяти ядра, и файловая система видна всему, что обладает правами root.
- Вне зоны защиты: ваш трафик. Байты в канале — забота TLS и WireGuard. LUKS их вообще не видит.
- Вне зоны защиты: скомпрометированная учётная запись root. Злоумышленник, уже проникший внутрь, читает ваши файлы через ту же точку монтирования, что и вы. Для этого нужна защита сервера, и эти два средства защиты не взаимозаменяемы.
Список короткий намеренно. Шифрование данных в состоянии покоя — это дешёвое и очень ценное средство защиты со строго ограниченной областью действия, и почти всё разочарование, о котором сообщают люди, происходит от того, что они молча ожидали, что оно прикроет и три остальных пункта тоже.
Оговорка про арендованное железо, сказанная прямо
Когда ваш зашифрованный том открыт, ключ находится в оперативной памяти гостевой системы — а на любом VPS, где бы он ни находился, эта память живёт на машине, которую физически контролирует оператор. Гипервизор может читать память гостя. Это не изъян LUKS, не изъян KVM и не изъян конкретно этого хостинга; это то, что означает аренда компьютера, и любой провайдер, утверждающий обратное, описывает продукт, которого не существует.
Поэтому расчёт прямолинеен: шифрование данных в состоянии покоя делает офлайн-атаку невозможной и оставляет онлайн-атаку ровно там же, где она была. Диск, покинувший стойку, становится бесполезным. Работающий сервер настолько же уязвим, насколько был вчера. Обе половины этого утверждения верны одновременно, и руководство, рассказывающее только о первой половине, оказывает вам плохую услугу.
Что действительно сдвигает вторую стрелку — это другой набор мер, и они складываются с шифрованием, а не заменяют его. Здесь нечего раскрывать по документам, потому что регистрация — без KYC — только email для доставки учётных данных и ничего больше. Оплата проходит в блокчейне, а не через банк. А юрисдикция, в которой находится сервер, решает, какие требования вообще имеют силу. Наш честный разбор того, что скрывает, а чего не скрывает VPS с оплатой в криптовалюте, разбирает остальное, а статья про Четырнадцать глаз раскрывает сторону обмена разведданными. Если воспринимать LUKS как один слой защиты среди нескольких — это отличное вложение. Если воспринимать его как щит от собственного хостинга — это заблуждение.
Том данных или корневая файловая система: решите, прежде чем печатать
Это может принимать одну из двух форм, и выбор здесь о риске, а не о надёжности.
- Зашифрованный том данных. Контейнер LUKS рядом с операционной системой. Всё важное — базы данных, почта, ключи, загрузки, резервные копии — живёт внутри него; сама ОС остаётся в открытом виде. Десять минут работы, никакого риска для загрузки и полная обратимость в любой момент. Именно это стоит собирать большинству читателей, и именно это делают шаги ниже.
- Зашифрованная корневая файловая система. Внутри всё, включая логи, списки пакетов и историю шелла, о которой вы забыли. Строго надёжнее, и по-настоящему сложнее применить к машине, которая уже работает.
О причине этой сложности стоит сказать прямо, потому что ни один туториал этого не делает: нельзя зашифровать файловую систему, которая прямо сейчас смонтирована на чтение-запись и обслуживает вашу SSH-сессию. Оба реальных метода — сжатие с копированием или cryptsetup reencrypt на месте — требуют, чтобы корень был отключён. На машине с внеполосной консолью вы просто загружаете установщик, и это рутинная операция. На безголовом VPS вам приходится сначала переводить работающую систему в RAM-диск, и если что-то в этом процессе пойдёт не так, сервер не поднимется, а путь восстановления — это переустановка, которая стирает диск.
Поэтому: соберите том данных сегодня, перенесите на него всё сколько-нибудь важное, а зашифрованный корень воспринимайте как решение, которое принимают в момент развёртывания, на машине, которой ещё нечего терять. Последний раздел разбирает именно этот путь, включая dropbear-initramfs для ввода парольной фразы по SSH при загрузке.
Что нужно, прежде чем начать
Не так уж много, и отчасти поэтому этим стоит заняться.
- Тариф. Шифрование не добавляет требований к RAM и почти не нагружает CPU. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) достаточно; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) — комфортный размер, если сервер к тому же выполняет реальный рабочий сервис. Единственная цифра, которая важна, — это диск, потому что зашифрованный том выделяется именно из него.
- Debian 12 или 13 из библиотеки шаблонов, либо Ubuntu LTS — команды ниже написаны под Debian, и в других системах названия пакетов отличаются. Развёртывание занимает около минуты, а полноценная виртуализация KVM означает настоящее ядро с модулями
dm-crypt, а не контейнер, одалживающий чужое. - Десять минут базовой защиты для начала. Шифрование на сервере, который всё ещё принимает вход по паролю, — это замок на двери без косяка.
- Парольная фраза, которую вы больше нигде не использовали, сгенерированная, а не придуманная, и сохранённая там, где она переживёт потерю этой машины. Восстановления не существует, сброса не существует, и никакой тикет в поддержку не поможет.
- Место за пределами сервера для хранения резервной копии заголовка. Еженедельные снапшоты включены в каждый тариф, но снапшот зашифрованного тома остаётся зашифрованным — полезен для отката, бесполезен, если парольная фраза утеряна.
Локация не имеет значения ни для чего из этого, так что выбирайте по цене или юрисдикции: Amsterdam, Paris, Bucharest и Sofia идут по базовой цене, тогда как Zurich, Reykjavik, Stockholm и Kuala Lumpur — с надбавкой.
Пошаговая инструкция
- Разверните сервер, защитите его и убедитесь, что у CPU есть AES-NI
Разверните Debian 13 из библиотеки шаблонов и для начала потратьте десять минут на базовые меры: только SSH-ключи, отключённый вход по паролю root, nftables default-deny, автоматические обновления безопасности. Затем убедитесь, что железо не заставит вас платить за это:
grep -o -m1 ' aes ' /proc/cpuinfo apt update && apt install -y cryptsetup cryptsetup benchmarkВам нужны показатели
aes-xtsв гигабайтах в секунду. У любого серверного x86-64 CPU последнего десятилетия есть AES-NI, так что узким местом будет не шифрование — а NVMe под ним, точно так же, как и раньше. - Выделите место под том
Если на диске вашего тарифа есть неразмеченное пространство, используйте его — настоящий раздел проще всего шифровать:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT sgdisk -n 0:0:0 -c 0:secure /dev/vda partprobe /dev/vdaЕсли шаблон занял весь диск, не боритесь с этим. Контейнер на основе файла здесь полноправный вариант, ничего не стоит по пропускной способности на NVMe и может быть расширен позже:
fallocate -l 20G /var/lib/secure.img chmod 600 /var/lib/secure.img losetup --find --show /var/lib/secure.imgЗапомните loop-устройство, которое он выведет — обычно
/dev/loop0. Везде ниже используется/dev/disk/by-partlabel/secure; подставьте своё loop-устройство, если вы выбрали путь с контейнером. - Отформатируйте его как LUKS2 — и ограничьте затраты памяти
Это команда, которая решает всё, поэтому её стоит прочитать, а не просто вставить:
cryptsetup luksFormat --type luks2 \ --cipher aes-xts-plain64 --key-size 512 \ --pbkdf argon2id --pbkdf-memory 262144 --iter-time 5000 \ /dev/disk/by-partlabel/secure--key-size 512— это AES-256 в режиме XTS, который делит ключ пополам — это не AES-512, которого не существует.--pbkdf argon2id— это устойчивая к памяти функция деривации ключа, которая делает подбор вашей парольной фразы дорогим как по RAM, так и по CPU.--pbkdf-memory 262144ограничивает это значение 256 MB, и это та строка, которую люди пропускают, а потом жалеют. Если её не задать,cryptsetupсам подгоняет затраты памяти под объём RAM, доступный в момент форматирования. Разблокируйте тот же заголовок позже там, где памяти меньше — тариф на 1 GB, спасательное окружение, initramfs — и разблокировка может провалиться напрочь. Ограничивайте это осознанно. - Откройте том, создайте файловую систему и смонтируйте
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \ --allow-discards open /dev/disk/by-partlabel/secure secure mkfs.ext4 -L secure /dev/mapper/secure mkdir -p /srv/secure mount -o noatime /dev/mapper/secure /srv/secure df -h /srv/secureДва флага workqueue имеют значение только на NVMe и больше нигде;
--allow-discardsсохраняет работу TRIM ценой раскрытия того, какие блоки заняты, всем, кто держит выключенный диск в руках. Оба обсуждаются ниже — варианты по умолчанию выше правильны для сервера общего назначения. - Сделайте резервную копию заголовка LUKS за пределами сервера
Сделайте это сейчас, пока на томе ещё нет ничего, что жалко потерять. Заголовок — это примерно 16 MB метаданных, хранящих слоты ключей, и повреждённый заголовок означает, что шифротекст невосстановим, как бы хорошо вы ни помнили парольную фразу:
cryptsetup luksHeaderBackup /dev/disk/by-partlabel/secure \ --header-backup-file /root/secure-header.img sha256sum /root/secure-header.imgСкопируйте его куда-нибудь ещё — заберите через
scp, положите в менеджер паролей, распечатайте хэш — а затем удалите локальную копию. Относитесь к этому файлу как к эквиваленту парольной фразы, потому что в сочетании с любой парольной фразой, которую он когда-либо хранил, он им и является. - Перенесите на том то, что действительно важно
Зашифрованный том, в который ничего не пишет, не защищает ничего. Сначала остановите сервис, перенесите его состояние, затем сделайте bind-mount старого пути, чтобы больше ничего не пришлось перенастраивать:
systemctl stop postgresql rsync -aHAX --info=progress2 /var/lib/postgresql/ /srv/secure/postgresql/ mv /var/lib/postgresql /var/lib/postgresql.old mkdir /var/lib/postgresql echo '/srv/secure/postgresql /var/lib/postgresql none bind 0 0' >> /etc/fstab mount /var/lib/postgresql systemctl start postgresqlУбедитесь, что сервис в порядке, прежде чем стирать через
shredили удалять каталог.old— и помните, что в файловой системе с copy-on-write или на NVMe с выравниванием износа удаление открытого текста — не то же самое, что его уничтожение. Чистая версия этой истории — создавать зашифрованный том ещё до появления сервиса. - Решите, как том будет разблокироваться, и будьте с собой честны
Вот развилка, на которую натыкается каждый. Добавьте том в
/etc/crypttabсnoauto, чтобы ничто не блокировало загрузку, и разблокируйте его вручную по SSH, когда он вам нужен:echo 'secure /dev/disk/by-partlabel/secure none \ luks,noauto,discard,no-read-workqueue,no-write-workqueue' >> /etc/crypttab cryptdisks_start secureЭто честная конфигурация: ключ существует только пока вы рядом, а после перезагрузки том остаётся закрытым, пока вы не скажете иначе. Цена в том, что после самопроизвольной перезагрузки сервис возвращается в выключенном состоянии.
Альтернатива — keyfile в
/etc/crypttab, чтобы том открывался автоматически. Если этот keyfile лежит на том же диске, вы не зашифровали вообще ничего — тот, кто держит выключенный диск, держит ключ рядом с замком. Это имеет смысл только тогда, когда ключ приходит оттуда, где диска нет: получен через туннель WireGuard при загрузке, либо введён в initramfs по SSH, как в последнем разделе. Выбирайте осознанно; вариант по умолчанию с ручной разблокировкой — единственный, который означает именно то, что говорит. - Зашифруйте swap и проверьте всё целиком
Swap — это место, куда память попадает, чтобы стать артефактом на диске, поэтому зашифрованный том рядом с открытым swap сливает ровно те секреты, которые вы пытались защитить. Случайный ключ на каждую загрузку — правильный ответ: нечем управлять, нечего терять. Сначала проверьте
swapon --showи подставьте своё устройство; если шаблон выдал вам swap-файл, а не раздел, удалите его и используйте вместо этого небольшой раздел, потому что устройству со случайным ключом нужно блочное устройство:swapoff -a sed -i '/swap/s/^/#/' /etc/fstab echo 'swap /dev/vda3 /dev/urandom \ swap,cipher=aes-xts-plain64,size=512' >> /etc/crypttab echo '/dev/mapper/swap none swap sw 0 0' >> /etc/fstabЗатем перезагрузитесь — пока ошибиться всё ещё дёшево — и честно проверьте результат:
lsblk -o NAME,FSTYPE,MOUNTPOINT cryptsetup status secure blkid /dev/disk/by-partlabel/secure # should say crypto_LUKS swapon --show # should show /dev/mapper/swapТест, который действительно что-то показывает: при закрытом томе убедитесь, что
/srv/secureпуст, а зависящий от него сервис отказывается запускаться. Если верно и то, и другое, шифрование настоящее, а не декоративное.
Слоты ключей, заголовки и смена парольной фразы
LUKS2 хранит до 32 слотов ключей. Каждый содержит копию одного и того же мастер-ключа, обёрнутую отдельной парольной фразой, поэтому вы можете добавить вторую парольную фразу, ничего не перешифровывая:
cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1Две парольные фразы с самого начала — правильное решение по умолчанию: одна для использования, вторая — записанная и хранящаяся отдельно. Потеря единственного доступа к тому из-за опечатки в менеджере паролей — самый распространённый способ потерять данные LUKS, с большим отрывом опережающий всё, что может сделать злоумышленник.
Теперь — ловушка. Резервная копия заголовка, снятая до смены парольной фразы, всё ещё открывает том старой парольной фразой. Слоты ключей живут в заголовке, поэтому старая копия заголовка — это и старая копия слотов ключей — сам мастер-ключ под ними никогда не менялся. Если вы меняете фразу потому, что она могла утечь, необходимо уничтожить все резервные копии заголовка, снятые до смены, и сделать новую. Иначе смена не даёт ничего, кроме иллюзии спокойствия.
Тот же факт делает резервные копии заголовка чувствительными сами по себе: этот файл на 16 MB вместе с любой парольной фразой, которую он когда-либо знал, достаточен для расшифровки тома. Храните его там же, где хранили бы парольную фразу, а не там, где храните снапшоты.
Производительность: AES-NI, NVMe и два флага, которые стоит знать
cryptsetup benchmark за примерно пятнадцать секунд говорит правду именно для вашего vCPU. На любом CPU с AES-NI — а это любой серверный x86-64 процессор последнего десятилетия — стоит ожидать несколько гигабайт в секунду для aes-xts, с комфортным запасом быстрее, чем NVMe под ним. Практические накладные расходы на реальной нагрузке — это низкие единицы процентов, и упираются они в CPU, а не в задержку.
На быстром хранилище имеют значение две опции cryptsetup, и только на быстром хранилище:
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
--allow-discards open /dev/disk/by-partlabel/secure secureФлаги workqueue обходят внутренние очереди dm-crypt и передают ввод-вывод напрямую устройству. На вращающемся диске они ничего не меняют; на NVMe RAID10 они убирают реальное узкое место при высокой глубине очереди. Добавьте их в строку опций crypttab как no-read-workqueue,no-write-workqueue, чтобы сделать постоянными.
--allow-discards — вариант с компромиссом. Он пропускает TRIM к NVMe, что со временем поддерживает производительность записи — а заодно раскрывает всем, кто держит в руках выключенный диск, какие блоки заняты, а какие свободны. Это настоящая, пусть и скромная, утечка информации: она показывает примерно то, насколько заполнен том, и может намекнуть на структуру файловой системы. На сервере общего назначения выбирайте производительность. Если содержимое тома — из тех вещей, где чувствителен сам размер, оставьте discard выключенным.
Путь через корневую файловую систему и удалённая разблокировка по SSH
Если вы хотите зашифровать всё целиком, делайте это на машине, на которой ещё ничего нет — сначала разверните, потом конвертируйте, потом стройте. Сама конвертация стандартна: сжать корневую файловую систему, пока она отключена, создать контейнер LUKS2 в освободившемся пространстве, скопировать систему через rsync -aHAX, указать /etc/fstab и /etc/crypttab на mapper-устройство, затем выполнить update-initramfs -u -k all и переустановить GRUB. Проблемой для безголового VPS это делают именно слова пока она отключена: добраться до этого состояния без консоли означает сначала перевести работающую систему в RAM-корень, а это тот самый шаг, который заканчивается переустановкой, если что-то идёт не так.
То, что вообще делает зашифрованный корень пригодным для использования на удалённой машине, — это dropbear-initramfs — SSH-сервер размером примерно 200 KB, встроенный в загрузочный образ и слушающий, пока ядро ждёт парольную фразу:
apt install dropbear-initramfs cryptsetup-initramfs
# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys
echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
>> /etc/dropbear/initramfs/dropbear.conf
echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k allЗатем во время загрузки вы выполняете ssh -p 2222 root@your-ip, и принудительная команда cryptroot-unlock запрашивает парольную фразу. Прежде чем полагаться на это, стоит знать три вещи. У initramfs есть собственный host key, поэтому ваш клиент предупредит о несовпадении на порту 2222 — это ожидаемо и как раз причина выделить для этого отдельный порт. Этот host key и ваш authorized_keys лежат на незашифрованном загрузочном разделе, доступном для чтения всем, кто держит диск в руках, поэтому используйте ключ разблокировки, который не делает больше ничего. А -s отключает вход по паролю в initramfs, и это не опция, а обязательное условие.
Ещё одна деталь, которая кусается на маленьких тарифах, — та же, что и в шаге третьем, и здесь она кусается больнее всего. initramfs запускается раньше, чем большая часть вашей RAM становится доступна хоть для чего-то комфортного, поэтому заголовок, отформатированный с большим объёмом памяти Argon2id, может не разблокироваться на той же самой машине, где был создан. Форматируйте с ограниченным --pbkdf-memory и тестируйте перезагрузку, пока терять ещё нечего.
День второй: что меняется, а что нет
Совсем немногое, в этом и суть. Открытый том LUKS — обычное блочное устройство; fsck, rsync, df и ваш инструмент резервного копирования ведут себя точно так же, как раньше. Обновления ядра не затрагиваются, потому что dm-crypt встроен в дерево ядра. Расширение тома после апгрейда тарифа — это две команды — cryptsetup resize, а затем собственное расширение файловой системы — и не требует повторного шифрования.
Стоит выработать три привычки. Репетируйте перезагрузку по расписанию, а не узнавайте в три часа ночи, что парольная фраза, которую вы нигде не записали, существует в единственном экземпляре. Храните резервные копии зашифрованными отдельно — restic или borg на внешний сервер, что является отдельным средством защиты, не связанным с томом, и переживёт полную потерю сервера; дополнение с ежедневным резервным копированием во внешнее хранилище стоит $2.00/mo, если вы не хотите настраивать это сами. И закрывайте том прежде, чем перестанете заботиться о сервере: cryptsetup close secure перед плановым выключением, миграцией или переустановкой означает, что ключ покидает память прежде, чем диск перестаёт быть вашим.
В плане политики торговаться не о чем. Вы получаете полный root на госте KVM, и что вы делаете с блочным уровнем — исключительно ваше дело; шифрование собственного тома — обычное системное администрирование, а не особый случай. Политика допустимого использования касается поведения — жёсткий предел там: никакого CSAM и никакого терроризма — и ничего не говорит про dm-crypt. Шифрование меняет форму гипотетического плохого дня: выключенный том, покидающий это здание, превращается в шум, и это стоит десяти минут вашего времени.
Часто задаваемые вопросы
Останавливает ли полное шифрование диска хостинг-провайдера от чтения моих данных?
Нет, пока сервер работает. Как только том разблокирован, ключ находится в оперативной памяти гостевой системы, а на любом VPS эта память находится на железе, которое контролирует оператор — гипервизор может её прочитать. Что LUKS делает полностью — это превращает выключенный диск в бесполезный: диск, возвращённый поставщику, выведенная из эксплуатации нода, офлайн-образ. Любой, кто продаёт шифрование диска как защиту от собственного хостинга, описывает то, чего не существует.
Можно ли зашифровать VPS, у которого нет консоли или доступа KVM-over-IP?
Зашифрованный том данных — да, полностью по SSH, без риска для загрузки, минут за десять. Зашифрованная корневая файловая система — другое дело: любому методу нужен отключённый корень, а на безголовой машине это означает сначала перевести работающую систему в RAM-диск. Это работает, и именно так люди теряют серверы. Конвертируйте в момент развёртывания, пока на сервере ничего нет, и используйте dropbear-initramfs, чтобы вводить парольную фразу по SSH при загрузке.
Сколько производительности реально стоит LUKS?
Низкие единицы процентов на любом CPU с AES-NI, а это значит — на любом современном x86-64 vCPU. Запустите cryptsetup benchmark, и вы увидите aes-xts на уровне гигабайт в секунду — быстрее, чем NVMe под ним, так что узким местом остаётся хранилище. На быстрых дисках --perf-no_read_workqueue и --perf-no_write_workqueue возвращают большую часть оставшегося при высокой глубине очереди.
Что произойдёт, если я потеряю парольную фразу?
Данные потеряны. Нет ни механизма восстановления, ни мастер-ключа, который хранил бы кто-то ещё, ни тикета в поддержку, который бы помог — это и есть то свойство, за которое вы платили. Смягчите это заранее: добавьте вторую парольную фразу в отдельный слот ключа через cryptsetup luksAddKey и храните резервную копию заголовка за пределами сервера. Учтите, что резервная копия заголовка, снятая до смены парольной фразы, всё ещё открывает том старой фразой, поэтому уничтожайте устаревшие копии при смене.
Какой тариф VPS нужен, чтобы запустить зашифрованный том?
Шифрование не добавляет требований к RAM и почти не нагружает CPU, поэтому тариф определяется вашей нагрузкой, а не LUKS. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) обслуживает зашифрованный том, даже не замечая этого; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) — комфортный размер, если на сервере ещё крутится база данных или почтовый сервер. Единственное реальное ограничение — диск, поскольку том выделяется именно из него.
Разрешено ли шифровать сервер на ваших тарифах?
Да — это обычное системное администрирование. Вы получаете полный root на госте KVM с настоящим ядром, так что dm-crypt, кастомное разбиение на разделы и всё остальное на уровне блочного устройства — целиком в вашем распоряжении. Политика допустимого использования регулирует поведение, а не конфигурацию, и жёсткий предел там — никакого CSAM и никакого терроризма.
Нужно ли шифровать swap тоже?
Да, и это тот шаг, который пропускает большинство руководств. Swap — это место, куда память ядра — включая ключи и расшифрованные буферы — попадает в виде артефакта на диске, поэтому открытый swap рядом с зашифрованным томом сливает как раз то, что вы пытались защитить. Используйте случайный ключ на каждую загрузку через /etc/crypttab: нечем управлять и нечего терять. В результате гибернация становится невозможной, что на VPS не стоит вам ничего.

