Как управлять резервным копированием зашифрованных разделов

283
Zumado

У меня есть следующий материал с моим ноутбуком:

  • 20 ГБ SSD
  • 500 ГБ HDD (диск A)
  • Внешний жесткий диск (диск B)

Что я хочу :

  • Мой Linux (Debian 9) зашифрован на уровне раздела (которым я управляю) с классическим разделением (root-var-home-tmp-boot) на SSD.
  • Резервное копирование этого. Я не очень уверен в том, как я этого хочу, в идеале с некоторым версионированием, но с зашифрованным разделом, который будет означать синхронизацию на уровне файловой системы, а затем зашифровать резервную копию.

На данный момент лучшими решениями, которые я видел, была реализация RAID 1 ( mdadm --> LUKS --> LVM --> ext4) или использование rsyncили dd.

Похоже, что mdadmэто лучший способ добиться того, чего я хочу, из-за шифрования, и что использование ddв реальном разделе может вызвать проблемы. Но это означает, что я должен постоянно использовать диск A объемом 120 ГБ, а диск B в качестве дополнительного диска является моей реальной резервной копией.

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

Любые предложения приветствуются.
Спасибо!

1

1 ответ на вопрос

0
davidgo

При условии, что вы используете шифрование AES и ваш ноутбук поддерживает aes-ni (почти все современные процессоры x86), шифрование и дешифрование обходятся недорого. Лучше всего было бы использовать rsnapshot для зашифрованного диска. Rsnapshot использует rsync и символические ссылки, чтобы обеспечить простое в использовании управление версиями, в то время как только дублирование файлов, которые были изменены, и даже может быть выполнено удаленно через ssh (это означает, что это может быть автоматизировано и пропускная способность ограничена, чтобы минимизировать влияние на производительность). Если вы используете локальный съемный диск, вы можете сохранить файл ключа для зашифрованного съемного диска в основной системе (то есть, чтобы он был доступен только после расшифровки основного диска), и сделать так, чтобы он казался меньше - просто убедитесь, что у вас есть резервная копия ключ и / или второй альтернативный пароль.

Спасибо, я сейчас настраиваю это решение. Я посмотрю, сколько времени потребуется, чтобы сделать снимки (как только первый будет сделан). Что касается ssh, если вы не имеете в виду, что я могу управлять им удаленно или добавить слой шифрования, я бы не передавал данные через него - он не обеспечивает такую ​​же безопасность, как полностью зашифрованный диск. Zumado 6 лет назад 0
Вы путаете 2 вещи здесь - ssh шифрует данные в полете / по проводам - ​​и предотвращает их перехват - и это вездесуще так легко добавить. Это полностью отличается от шифрования в состоянии покоя - именно так данные хранятся на диске. Поскольку шифрование всегда имеет определенную стоимость, которая, как вы считали, стоит того, если вы не выполняете резервное копирование на физически подключенный диск, вам действительно нужны оба варианта - издержки ssh тривиальны по сравнению со стоимостью дискового ввода-вывода. davidgo 6 лет назад 0
«предотвращает перехват этого»: нет, это то, что я имел в виду, это не так. Может быть, я слишком параноик, но с момента, когда выясняется, что кто-то может его сломать, я не считаю это безопасным. См. Https://en.wikipedia.org/wiki/Secure_Shell#US_government_hack_of_SSH_protocols_confirmed Zumado 6 лет назад 0
А? AFAIK, SSH, как известно, небезопасен (за исключением конкретной реализации, которая была исправлена ​​много лет назад). Посоветуйте пожалуйста как это можно сломать? davidgo 6 лет назад 0
Ну, я дал вам ссылку. Это не сломано само по себе, реализации клиентов, и в течение многих лет (инструмент CIA Gyrfalcon для OpenSSH на Linux). Во всяком случае, я просто придерживаюсь общего правила, если только мне не нужно, я стараюсь не передавать конфиденциальные данные через Интернет (даже зашифрованные). Zumado 6 лет назад 0
Вы понимаете, что Gyrfalcon требует, чтобы система уже была полностью скомпрометирована - то есть, человеку, устанавливающему ее, уже нужен root? (https://www.ssh.com/ssh/cia-bothanspy-gyrfalcon) В этот момент они могли также легко заменить открываемый двоичный файл на вредоносный. Конечно, у вас также будет доступ к закрытым ключам и смонтированным + то есть незашифрованным) данным. davidgo 6 лет назад 0

Похожие вопросы