Полнодисковое шифрование VPS

Полнодисковое шифрование отвечает ровно на один вопрос: что получит противник, если завладеет вашим накопителем при выключенной машине? На все остальные вопросы — что видит хостинг-провайдер, что происходит при захвате работающего сервера, в безопасности ли резервные копии — ответ другой, и попытка свести их все к одному — верный способ получить шифрование, которое не защищает ровно ничего.

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

От чего шифрование в состоянии покоя действительно защищает

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

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

Почему VPS — не ноутбук

На ноутбуке логика очевидна сама по себе. Вы вводите парольную фразу при загрузке, ключ существует только в RAM, пока машина включена, а выключение ставит точку в этой истории. У сервера никого нет за консолью. Ключ должен подавать что-то на каждой загрузке, и каждый кандидат на роль этого «что-то» меняет доступность на защищённость:

• Ключ вводит человек. Самая надёжная схема, поскольку ключ никогда не хранится на машине, — но сервер не сможет вернуться из перезагрузки без вас, и вам нужен способ попасть внутрь ещё до существования операционной системы.
• Ключ хранит сама машина. Удобно, и в большинстве самодельных конфигураций контрпродуктивно: файл ключа на том же виртуальном диске означает, что ключом владеет тот, кто владеет диском.
• Ключ передаёт другая машина. Разблокировка, привязанная к сети, — как правило, Clevis совместно с сервером Tang. Сервер разблокируется сам, только пока способен дотянуться до контролируемого вами хоста, и это действительно полезное свойство — перенос доверия, а не его устранение.

Есть и второе отличие, которое обходит стороной большинство гайдов. На VPS /boot и initramfs хранятся в открытом виде, они находятся на носителе, который в конечном счёте контролирует провайдер, и никакую цепочку загрузки проверить нельзя — нет собственного TPM, нет measured boot, нечего аттестовать. Хост, которому нужна ваша парольная фраза, мог бы изменить initramfs и получить её при следующей разблокировке. Это не описание того, что делаем мы; это описание того, что допускает архитектура, — а это единственный честный способ рассуждать о компьютере, который вы арендуете. Наше сравнение VPS и выделенных серверов разбирает ту же границу доверия со стороны железа, а наш честный ответ об офшорной анонимности применяет ту же дисциплину к маркетингу вокруг неё.

Три схемы развёртывания, которые того стоят

Единственно правильной настройки не существует — есть та, чей сценарий отказа вам по силам пережить. Эти три схемы охватывают практически все реальные случаи.

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

Шифрование тома с данными на работающем VPS

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

• Установите инструментарий. apt install cryptsetup. Если по вашему тарифу выдан второй блочный диск, используйте его напрямую и пропустите следующий шаг.
• Создайте контейнер. На VPS с одним диском практичный путь — обычный файл: fallocate -l 40G /var/lib/vault.img. Он ведёт себя как диск, и его можно позже увеличить.
• Отформатируйте его как LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Оставьте значения шифра по умолчанию; ниже разобран единственный параметр, который стоит трогать на небольшом сервере.
• Откройте его и разместите файловую систему. cryptsetup open /var/lib/vault.img vault даёт вам /dev/mapper/vault; затем mkfs.ext4 /dev/mapper/vault и mount /dev/mapper/vault /srv/vault.
• Перенесите важные данные, затем перенаправьте на них сервисы. Bind-монтирование или rsync при остановленном сервисе обычно чище символических ссылок — базы данных особенно не любят, когда за ними «бегают».
• Сделайте резервную копию заголовка LUKS. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, затем перенесите этот файл с сервера. Несколько повреждённых килобайт в начале контейнера безвозвратно уничтожают все байты за ними, и это единственная существующая страховка.
• Закройте его и убедитесь, что сможете войти снова. umount /srv/vault && cryptsetup close vault, затем откройте его заново по своим записям, а не по памяти. Сделайте это до того, как внутри появится что-то ценное.

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

Полное шифрование корня с удалённой разблокировкой по SSH

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

• Устанавливайте сразу зашифрованным. Загрузите установщик дистрибутива через загрузку собственного ISO и выберите управляемое разбиение диска с зашифрованным LVM. Преобразовать уже работающую корневую файловую систему на месте технически возможно, но риск того не стоит.
• Добавьте SSH-сервер, работающий до загрузки. apt install dropbear-initramfs, затем поместите свой публичный ключ в /etc/dropbear/initramfs/authorized_keys. Это отдельный набор ключей, не связанный с обычным SSH, — используйте выделенный ключ.
• Заприте его. В /etc/dropbear/initramfs/dropbear.conf задайте DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": без входа по паролю, без переадресации портов, собственный порт и тайм-аут простоя, чтобы зависшая сессия не держала загрузку открытой.
• Дайте initramfs сеть. Добавьте статический параметр ip= в GRUB_CMDLINE_LINUX в файле /etc/default/grub — формат такой: ip=address::gateway:netmask::interface:off. Расчёт на DHCP на этом этапе — типичный способ остаться без доступа.
• Пересоберите и перезагрузитесь. update-initramfs -u && update-grub, затем перезагрузитесь и подключитесь командой ssh -p 2222 root@your-server, после чего выполните cryptroot-unlock. Клиент предупредит о неизвестном ключе хоста: у initramfs свой собственный ключ, это ожидаемо, и его стоит закрепить отдельной записью в known_hosts.
• Проверьте путь отказа заранее, до того как на него придётся положиться. Установите обновление ядра, перезагрузитесь, разблокируйте снова. Обновления ядра пересобирают initramfs, и именно тогда всплывает ошибка конфигурации.

Два параметра, которые важны, и ловушка небольшого VPS

LUKS2 по умолчанию использует AES-XTS с 512-битным ключом и вывод ключа через Argon2id. Оба выбора верны. Ручная настройка шифра — способ одновременно замедлить и ослабить систему, а интернет полон скопированных командных строк, которые делают именно это. Однако две вещи заслуживают внимания.

Производительность — не проблема, пока не становится ею

Проверьте аппаратное ускорение командой grep -m1 -o aes /proc/cpuinfo и измерьте его командой cryptsetup benchmark. На любом CPU с AES-NI — а таковы все узлы, на которых мы работаем, — AES-XTS обрабатывает несколько гигабайт в секунду на ядро, что с запасом превышает то, что способен отдать один виртуальный диск, поэтому заметная цена — несколько процентов CPU при интенсивном I/O и небольшой рост задержки. Без AES-NI картина переворачивается, и шифрование становится узким местом; это тот единственный случай, когда альтернативный шифр — реальное решение, а не карго-культ.

Именно память Argon2id создаёт проблему

Argon2id намеренно требователен к памяти, и cryptsetup калибрует его во время форматирования по объёму RAM той машины, на которой идёт форматирование. Отформатируйте том на рабочей станции с 32 ГБ RAM, перенесите его на VPS с 1 ГБ RAM — и разблокировка может провалиться напрямую, потому что памяти, которую требует вывод ключа, попросту нет, а внутри initramfs всё ещё хуже, поскольку доступно значительно меньше памяти, чем в работающей системе. На небольших инстансах зафиксируйте значение: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb ограничивает его 256 МБ. Меньшее значение — это реальное снижение стойкости к офлайн-перебору, поэтому компенсируйте его более длинной парольной фразой.

Один необязательный флаг заслуживает осознанного решения, а не бездумного копирования: --allow-discards пропускает TRIM к нижележащему устройству, что полезно для износа SSD и стабильной производительности, но заодно раскрывает, какая часть тома используется и примерно где. По умолчанию он выключен. Включайте его, понимая, что именно он раскрывает.

Swap, журналы, снапшоты — то, что забывают

Зашифрованное хранилище, вокруг которого протекает открытый текст, — самый распространённый из всех сбоев, и он остаётся незаметным, пока кто-то не присмотрится.

• Swap. Всё, что находится в памяти, может быть выгружено на диск — включая материалы, которые вы аккуратно поместили в хранилище. Либо отключите swap, либо выдавайте ему случайный ключ на каждой загрузке строкой /etc/crypttab вида swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Всё, что пишет туда, куда вы не смотрели. /var/log, /tmp, каталог данных базы, /var/lib/docker, история команд оболочки, журналы systemd. Шифрование /srv/vault при том, что PostgreSQL пишет в /var/lib/postgresql, не даёт ровным счётом ничего. Составьте полный список, прежде чем шифровать.
• Снапшоты. Блочный снапшот зашифрованного тома — это шифротекст, и потому с ним всё в порядке. Снапшот, фиксирующий состояние памяти, — совершенно другой объект и может содержать ключ. Прежде чем использовать панель провайдера, выясните, какой именно снапшот она делает.
• Резервные копии. Решать эту задачу на стороне назначения — неправильный подход. Такие инструменты, как restic и BorgBackup, шифруют на стороне источника ключом, который получатель никогда не видит, поэтому сервер резервного копирования может быть обычной машиной в другой юрисдикции, а не доверенной.
• Открытый текст, который вы уже куда-то отправили. Шифрование в состоянии покоя не действует задним числом. Всё, что уже скопировано, отправлено по почте или синхронизировано в другое место, остаётся за пределами границы, которую вы проводите только сейчас.

Где живёт ключ — в этом вся конструкция

Каждая из перечисленных выше схем — это, по сути, утверждение о хранении ключа. Существует четыре варианта, и они не равноценны:

• В голове, вводится при каждой загрузке. Максимальная защита, максимальное эксплуатационное неудобство. Машину действительно нельзя прочитать без вас.
• В файле на зашифрованной машине. Защищает от наивной перепродажи диска и больше ни от чего. Если этот файл лежит на открытом /boot, он не защищает вообще ни от чего — самая распространённая ошибка в самостоятельно настроенном шифровании.
• На контролируемой вами машине, получается по сети. Clevis, привязанный к серверу Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Сервер загружается без участия человека, пока может дотянуться до «дома», и отказывается разблокироваться где-либо ещё. Отлично подходит для безголовых парков серверов и делает хост Tang тем объектом, который необходимо защищать.
• В TPM. Имеет смысл на оборудовании, которым вы владеете. На VPS виртуальный TPM предоставляет тот же гипервизор, который вы пытаетесь исключить из доверия, так что он решает вопрос удобства, а не доверия.

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

Что видит ваш хостер и где начинается юрисдикция

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

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

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

Девять ошибок, превращающих шифрование в декорацию

• Автоматическая разблокировка из файла ключа на том же диске. Так устроено большинство «зашифрованных» серверов — это равносильно тому, чтобы оставить ключ в замке.
• Шифрование тома, до которого чувствительные данные никогда не доходят. Хранилище пустует, а база данных находится не в нём.
• Отсутствие резервной копии заголовка LUKS. Один повреждённый сектор в начале контейнера — и все байты за ним потеряны навсегда.
• Отсутствие проверки пути разблокировки. Затем обновление ядра пересобирает initramfs, и следующая перезагрузка превращается в спасательную операцию.
• Форматирование на большой машине и разблокировка на маленькой. Argon2id требует память, которую VPS предоставить не может, и том не откроется.
• Выбор парольной фразы как обычного пароля для входа. Ничто не ограничивает скорость офлайн-атаки, кроме функции вывода ключа. Именно длина покупает время.
• Миграция открытых данных в шифрование в предположении, что оригинал исчез. На виртуализированном хранилище перезапись не гарантирует стирание.
• Отправка парольной фразы по тому же каналу, что используется для администрирования машины. OpSec сервера разбирает проблему корреляции, которую это создаёт.
• Путаница между шифрованием провайдера и собственным. «Вся инфраструктура зашифрована в состоянии покоя» — включая нашу — защищает инфраструктуру. От самой инфраструктуры защищает только ключ, которым владеете вы.

Так стоит ли делать это на VPS?

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

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