Зашифрованный диск в Linux хранит ключ к своим данным в служебной области, называемой заголовком. Этот заголовок располагается в начале раздела и содержит всё необходимое для расшифровки: параметры шифра, случайную соль и зашифрованные паролями копии главного ключа тома. Звучит надёжно, пока не осознаёшь хрупкость этой конструкции. Стоит заголовку повредиться, и весь зашифрованный диск превращается в нечитаемый массив, даже если сами данные физически целы, а пароль известен. Без заголовка отпирать нечего.
Опасность не теоретическая. Заголовок повреждается при сбое во время операций с разделом, при случайной записи поверх начала диска, при ошибке разметки или просто при деградации первых секторов накопителя. Любая из этих бед в одно мгновение делает терабайты зашифрованных данных недоступными навсегда. Единственная настоящая защита от такого исхода это заранее сделанная резервная копия заголовка, хранящаяся отдельно от диска. Разобраться, как её создать, как восстановить и какие тонкости при этом учесть, стоит каждому, кто доверяет шифрованию что-то ценное.
Почему заголовок это самое уязвимое место зашифрованного диска
Чтобы оценить важность резервной копии, нужно понять, что именно хранит заголовок и почему его потеря фатальна. Данные на диске зашифрованы главным ключом тома, а этот ключ не вводится с клавиатуры и не запоминается человеком. Он генерируется случайно при создании тома и хранится в заголовке в нескольких зашифрованных копиях, разложенных по слотам. Пароль пользователя лишь отпирает одну из этих копий в своём слоте, после чего извлечённый главный ключ и расшифровывает данные.
Из этой схемы вытекает уязвимость. Пароль сам по себе не расшифровывает данные напрямую, он только открывает доступ к хранящемуся в заголовке главному ключу. Если заголовок повреждён или стёрт, копий главного ключа больше нет, и любой пароль становится бесполезным, потому что отпирать им нечего. Данные остаются на диске в целости, но прочитать их невозможно, ведь ключ к ним исчез вместе с заголовком.
Заголовок к тому же расположен в самом начале раздела, а это статистически уязвимое место. Именно по началу диска чаще всего бьют ошибочные команды разметки, неудачные установки загрузчиков и случайные операции записи. Несколько затёртых килобайт в начале раздела губят доступ ко всему тому. Поэтому резервная копия заголовка это не паранойя, а базовая мера предосторожности перед любой операцией, способной задеть начало диска.
Как создать резервную копию заголовка
Утилита управления шифрованием умеет выгружать заголовок в отдельный файл одной командой. Она снимает двоичную копию всей служебной области, включая слоты с зашифрованными ключами, и сохраняет её туда, куда укажут.
sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /mnt/safe/sdb1-header.imgЗдесь утилита читает заголовок указанного раздела и складывает его в файл на отдельном носителе. Операция безопасна для данных, потому что она лишь читает, ничего не меняя на самом диске. Получившийся файл небольшой, но содержит всё необходимое для последующего восстановления доступа к тому.
Полезно сразу убедиться, что копия снялась корректно и содержит осмысленный заголовок. Та же утилита умеет показывать содержимое файла заголовка так же, как она показывает заголовок живого тома.
sudo cryptsetup luksDump /mnt/safe/sdb1-header.imgЭта команда выводит параметры шифра, уникальный идентификатор тома и список занятых слотов с ключами. Если вывод выглядит осмысленно и совпадает с параметрами исходного тома, копия снята верно. Делать такую копию рекомендуется сразу после создания зашифрованного тома и затем перед каждой рискованной операцией с диском.
Как восстановить заголовок из резервной копии
Когда беда уже случилась и доступ к тому потерян, резервная копия возвращает его к жизни. Восстановление выполняется парной командой, которая записывает сохранённый заголовок обратно на раздел поверх повреждённого.
sudo cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file /mnt/safe/sdb1-header.imgУтилита перед записью предупредит, что раздел уже содержит заголовок и его замена уничтожит текущие слоты, и потребует явного подтверждения заглавными буквами. Это защита от случайного запуска, ведь восстановление перезаписывает служебную область целиком. После подтверждения сохранённый заголовок ляжет на место повреждённого, и том снова станет открываемым своим паролем.
Завершив восстановление, том открывают обычным образом, и если копия была актуальной, доступ к данным возвращается полностью.
sudo cryptsetup luksOpen /dev/sdb1 restoredЭта команда отпирает том восстановленным заголовком и создаёт расшифрованное отображение, к которому уже можно обращаться как к обычному устройству и монтировать файловую систему. Данные, которые казались потерянными навсегда, снова доступны, потому что главный ключ вернулся вместе с заголовком.
Тонкость с паролями при восстановлении
Здесь кроется неочевидный нюанс, способный преподнести неприятный сюрприз с точки зрения безопасности. Восстановление заголовка возвращает том ровно в то состояние, в каком он был на момент создания копии, включая все пароли в слотах, что существовали тогда. Это значит, что после восстановления работают именно те пароли, что были актуальны при резервировании, а не текущие.
Последствие тонкое, но важное. Допустим, после создания копии заголовка владелец сменил пароль ради безопасности, заподозрив, что старый скомпрометирован. Восстановив заголовок из давней копии, он откатит том к старым слотам, и скомпрометированный пароль снова заработает, а новый перестанет действовать. Получается, что резервная копия заголовка хранит в себе и все пароли на момент её создания, и это нужно держать в уме при управлении такими копиями.
Отсюда вытекает и другое следствие, касающееся надёжного уничтожения данных. Раз копия заголовка позволяет расшифровать том даже после смены или удаления пароля на самом диске, простое затирание заголовка на диске больше не гарантирует уничтожения доступа. Чтобы надёжно закрыть доступ к зашифрованным данным, нужно либо уничтожить все резервные копии заголовка, либо затереть саму зашифрованную область, а не только заголовок на диске.
Где и как хранить резервную копию
Ценность резервной копии полностью зависит от того, где она лежит. Главное правило очевидно, но его часто нарушают: копию заголовка нельзя хранить на самом зашифрованном диске. Если заголовок повредится вместе с диском, погибнет и копия, и вся затея окажется бессмысленной. Копию держат на отдельном физическом носителе, в идеале в нескольких местах сразу.
При этом сам файл заголовка несёт в себе зашифрованные ключи и пароли на момент создания, а значит, попади он к злоумышленнику вместе с доступом к диску, защита рухнет. Поэтому копию заголовка разумно дополнительно зашифровать перед хранением, например, защитив её отдельным инструментом шифрования файлов. Тогда даже найденная копия останется бесполезной без второго пароля.
Чтобы не запутаться в требованиях к хранению, удобно держать перед глазами короткий перечень правил:
- Хранить копию строго отдельно от зашифрованного диска, иначе она погибнет вместе с ним;
- Держать несколько копий в разных местах, чтобы утрата одной не стала катастрофой;
- Дополнительно зашифровать сам файл копии, ведь он содержит ключи и старые пароли;
- Обновлять копию после смены паролей, иначе восстановление откатит их к старым;
- Проверять копию командой просмотра содержимого, убеждаясь, что она читается и не повреждена.
Особого внимания заслуживает безопасное снятие копии на машинах, где есть подкачка. Промежуточный файл заголовка во время работы может попасть в область подкачки на диск и остаться там в открытом виде. Чтобы этого избежать, копию снимают во временную файловую систему в памяти, шифруют её там и лишь потом переносят в постоянное хранилище, не давая чувствительным данным просочиться на диск.
Чем различаются версии формата при резервировании
Стоит учитывать, что зашифрованные тома бывают двух поколений формата, и обращение с их заголовками немного различается. Старое поколение хранит компактный заголовок фиксированного небольшого размера в самом начале раздела. Новое поколение использует заметно более крупную служебную область и держит две копии метаданных для защиты от повреждения, что само по себе повышает устойчивость, но не отменяет нужды в резервной копии.
Команда выгрузки заголовка работает с обоими поколениями одинаково с точки зрения пользователя, но размер получаемого файла будет разным: для нового формата он крупнее, поскольку служебная область объёмнее. При восстановлении утилита требует, чтобы размер ключа и смещение данных в копии совпадали с тем, что ожидается на разделе, иначе она откажется записывать заголовок. Это защита от попытки восстановить копию на несовместимый том.
Узнать, какого поколения том, помогает та же команда просмотра содержимого, которая в самом начале вывода указывает версию формата. Зная версию, проще понимать, чего ожидать от размера копии и как поведёт себя восстановление. При конвертации тома из старого формата в новый служебная область переписывается полностью, и это ровно тот случай, когда свежая резервная копия заголовка перед операцией особенно уместна.
Как встроить резервирование в регулярную практику
Разовая копия хороша, но настоящую надёжность даёт привычка обновлять её при изменениях. Поскольку заголовок меняется только при операциях со слотами, добавлении или удалении паролей, обновлять копию нужно именно после таких действий, а не по расписанию. Между изменениями слотов заголовок неизменен, и старая копия остаётся актуальной сколь угодно долго.
Удобно завести правило: любое изменение паролей или ключей тома сопровождать немедленным обновлением резервной копии и заменой старой во всех местах хранения. Тогда копия всегда отражает текущее состояние, и восстановление не преподнесёт сюрприза с откатом паролей. Старые копии при этом разумно надёжно уничтожать, ведь каждая из них хранит пароли на момент своего создания и остаётся работающим входом в данные.
Полезно также документировать для себя, какой файл копии к какому тому относится, потому что внешне эти двоичные файлы неразличимы. Перепутать копии от разных дисков легко, а восстановление чужой копии на том просто не пройдёт проверку совместимости, в лучшем случае, или создаст путаницу. Понятные имена файлов с указанием тома и даты снятия избавляют от этой головной боли.
Когда обязательно делать копию
Резервную копию заголовка стоит сделать в нескольких ключевых случаях, и пренебрегать ими опасно. Сразу после создания зашифрованного тома это первый и самый важный момент, ведь именно тогда фиксируется исходное состояние. Перед любой операцией с разметкой диска, изменением размера разделов или установкой загрузчика, поскольку все они способны задеть начало раздела с заголовком. Перед обновлением системы шифрования или конвертацией тома между версиями формата, так как такие операции переписывают служебную область.
Привычка снимать копию перед рискованными действиями превращает потенциальную катастрофу в мелкую неприятность. Вместо безвозвратной потери данных худшим исходом становится откат к сохранённому заголовку с восстановлением полного доступа. Несколько секунд на создание копии окупаются спокойствием при любой операции с зашифрованным диском.
Что в итоге запомнить
Заголовок зашифрованного тома это единственный вход к данным, потому что в нём хранятся зашифрованные копии главного ключа, без которых пароль бесполезен. Расположенный в уязвимом начале раздела, заголовок легко повредить ошибочной командой или сбоем, и его утрата делает целые данные нечитаемыми навсегда. Резервная копия, снятая штатной командой выгрузки заголовка в файл, это единственная настоящая страховка от такого исхода.
Восстановление из копии возвращает доступ к тому, но возвращает и пароли на момент её создания, что важно помнить при смене паролей и при надёжном уничтожении данных. Хранить копию нужно отдельно от диска, в нескольких местах и желательно в дополнительно зашифрованном виде, ведь она содержит ключи к данным. Снимая копию сразу после создания тома и перед каждой рискованной операцией, человек избавляет себя от риска потерять всё из-за нескольких повреждённых килобайт в начале диска.
Канал сайта в Telegram
Канал сайта на YouTube