Шифрование диска на сервере, которым вы не владеете

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

Три состояния данных — и то, которое никто не шифрует

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

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

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

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

Где живёт ключ, пока машина работает

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

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

• Живая миграция. Перенос работающей виртуальной машины между физическими хостами копирует её память прямо на ходу. Это штатная функция — именно так хост обслуживают, не перезагружая вас, — и ваш мастер-ключ находится среди копируемых страниц памяти.
• Снимок, включающий память. Снимок только диска для тома, который вы зашифровали сами, содержит шифротекст и ничего больше. А снимок, позволяющий машине продолжить работу ровно с того же места, содержит и ключ — потому что ключ как раз и есть часть того, из чего состоит это «ровно то же место».
• Дамп памяти. Память вашей гостевой системы находится внутри адресного пространства процесса на хосте. Чтение памяти этого процесса — рутинная отладочная операция, а нужные для этого инструменты идут в комплекте со стеком виртуализации, их не нужно проносить тайком.

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

Проблема перезагрузки и лазейка, которая её обнуляет

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

Четыре способа разблокировать зашифрованный корневой том на удалённой машине

Метод	Автоматическая перезагрузка	Защита при краже диска	Чего это стоит
Подключение по SSH к загрузочному образу	Нет	Да	Минимальный SSH-сервер внутри initramfs позволяет подключиться и ввести парольную фразу. Машина остаётся выключенной, пока не найдётся человек, который не спит и доступен. Это честный вариант, и цена у него настоящая: перезагрузка в четыре утра оборачивается простоем до тех пор, пока кто-то это не заметит.
Ключ, привязанный к сети	Да	Частично	При загрузке машина запрашивает ключ разблокировки у сервера, который вы держите отдельно, и вы можете отказать в выдаче ключа машине, которая переместилась или которую вы не перезагружали сами. Сервер ключей обязан оставаться в сети, и он должен находиться там, куда не дотянется то же самое постановление, — иначе вы просто разделили один ключ между двумя дверьми с одним и тем же замком.
Файл ключа в загрузочном образе	Да	Нет	Ключ лежит в initramfs, initramfs — на незашифрованном загрузочном разделе, а загрузочный раздел — на том самом диске, который вы пытались защитить. Тот, кто забирает диск, забирает вместе с ним и ключ. Такая конфигурация встречается часто, загружается она безупречно и не защищает вообще ни от чего.
Ключ, запечатанный в TPM	Да	Частично	На собственном железе настоящий защитный чип отдаёт ключ только той цепочке загрузки, которая не была изменена. На виртуальном сервере этот чип эмулирует сам хост, а значит, запечатывая ключ в нём, вы вручаете его именно той стороне, от которой пытались его спрятать.

Третья строка заслуживает отдельного внимания. Именно к ней приходят, когда требование сформулировали как диски должны быть зашифрованы — и никто не спросил, зачем. Аудит проходит успешно. Блочное устройство действительно зашифровано. А ключ едет на том же самом куске железа, в файле, который восстановительная оболочка прочитает секунд за четыре.

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

Что на самом деле даёт полное шифрование диска

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

Восемь сценариев и то, меняет ли полное шифрование диска исход

Сценарий	Шифрование помогает	Что на самом деле решает исход
Диск списывают, перепродают или возвращают по гарантии	Да	Больше от этого не защищает ничто. Диски покидают дата-центры постоянно, очистка данных — это процесс, а процессы дают сбои тихо. Это ровно тот сценарий, для которого полное шифрование диска и придумали, и здесь оно работает именно так, как обещано.
Машину выключают и извлекают диск	Да	Та же защита с той же границей, и эта граница — слово выключена. Машина, изъятая во время работы, — это машина, изъятая разблокированной: с открытыми томами и ключом, который никуда не делся из памяти.
Резервная копия хранится в другом месте	Частично	Шифрование исходного тома никак не влияет на копию данных. Решает то, была ли резервная копия зашифрована до того, как покинула машину, ключом, который не хранится на той же машине, которую копируют.
Платформа делает снимок	Частично	Снимок только диска для тома, который вы зашифровали сами, — это шифротекст, бесполезный для любого, у кого нет вашей парольной фразы. А снимок, захватывающий состояние памяти, захватывает вместе с ним и ключ. И то и другое называют одним и тем же словом — «снимок».
Кто-то получает shell на работающей машине	Нет	Том уже открыт, и злоумышленник читает файлы, а не блоки диска. Здесь решают патчи, минимально необходимые привилегии и учётные данные, не переиспользуемые между сервисами, — шифрование в этой строке не даёт ничего.
Оператор хоста или любой, кто владеет его доступом	Нет	Помогает только шифрование, ключ от которого вообще никогда не попадает на машину. Единственное исключение — аппаратное шифрование памяти, и оно везде отключено по умолчанию; об этом — в следующем разделе.
Провайдеру вручают постановление	Частично	Юрисдикция решает, кто вправе спрашивать и на каком основании; шифрование решает, что может содержаться в ответе. Наша собственная опубликованная правовая позиция — это два отдельных предложения, и важны оба: мы не храним ключи клиентов и не можем их предоставить, а незашифрованный том на виртуальном сервере всё равно требует постановления, адресованного именно этой услуге.
Вам нужно раскрыть факт утечки	Частично	Если ваши пользователи находятся в ЕС, статья 32 GDPR прямо называет шифрование среди ожидаемых от вас мер, а статья 34 снимает обязанность уведомлять физических лиц — но никогда регулятора — если данные были сделаны нечитаемыми. Применимо ли это, целиком зависит от того, где находился ключ в момент, когда данные покинули машину.

Выше диска: что уцелеет при враждебном хосте

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

Шифруйте выше приложения, а не под ним

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

Резервные копии — отдельное решение, а не следствие

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

Шифрование памяти, и почему у вас его, скорее всего, нет

У состояния, которое никто не шифрует, всё же есть аппаратный ответ. Расширения конфиденциальных вычислений — AMD SEV-SNP, Intel TDX — шифруют память и состояние регистров гостевой системы ключом, которым владеет отдельный защищённый процессор, а не гипервизор, так что хост, снимающий дамп памяти, получает обратно только шифротекст. Это реальная и уже поставляемая технология. Но и весьма узкая: SEV-SNP требует кремния EPYC третьего поколения или новее, хост должен быть намеренно настроен для этого, а гостевая система обязана подтвердить, что действительно его получила. Почти ни один универсальный виртуальный сервер этого не предлагает, и ни один не предлагает это молча. Считайте, что у вас этого нет, пока провайдер не подтвердит обратное письменно и не объяснит, как самостоятельно проверить аттестацию.

Настройка, честная в отношении своих пределов

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

1. Запишите тот единственный сценарий, от которого вы защищаетесь (5 мин). Списанный диск, изъятая во время работы машина, враждебный хост, судебное постановление, утечка, о которой нужно уведомить. У каждого из них свой ответ, а конфигурация, нацеленная сразу на все пять, гарантированно не решает ни одного.
2. Размещайте шифрование там же, где держите ключ (решение). Если ключ держит провайдер, вы купили защиту от диска, покидающего здание, — и ничего сверх того. Если нужно больше, том придётся разблокировать изнутри гостевой системы, вам самим, чем-то, чего платформа никогда не увидит.
3. Шифруйте том с данными, а не корневой том (настройка). Зашифрованный корень означает, что каждая перезагрузка будет ждать вас. Отдельный зашифрованный том с каталогом базы данных, загрузками и секретами позволяет машине подниматься самостоятельно, пока чувствительная часть остаётся закрытой до тех пор, пока вы её не откроете. Это тот компромисс, к которому стоит приходить большинству небольших платформ, и почти никто его не формулирует вслух.
4. Никогда не оставляйте файл ключа на незашифрованном загрузочном разделе (правило). Если машина загружается без участия человека, без сервера ключей и без консоли, ключ лежит на диске — третьего не дано. Это разумный компромисс, если похищенный диск и есть вся ваша модель угроз, и самообман — во всех остальных случаях.
5. Шифруйте резервные копии в момент записи, ключом, который хранится отдельно (настройка). А затем разверните одну копию на другой машине — в день, когда ничего не горит.
6. Сформулируйте одним предложением, что именно вы закрыли (5 мин). Что-то вроде: злоумышленник, вытащивший этот диск из стойки, не получает ничего, а любой, у кого есть root на работающей машине или на её хосте, получает всё. Если это предложение неприятно записывать, то именно потому, что оно правдиво.

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

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

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