Стратегия резервного копирования для eCryptfs
У нас есть небольшая сеть с сервером Ubuntu посередине и ноутбуками Ubuntu вокруг. Все ноутбуки используют eCryptfs для шифрования всего домашнего каталога пользователей. Обычно в ноутбуке два или более пользователей. Процедура резервного копирования остается внутри сети, поэтому мы можем передавать незашифрованные файлы на сервер. Мы хотели бы пойти с rsync решение, но с другими тоже.
Мы столкнулись с трудностями при попытке сделать резервную копию домашних каталогов ноутбуков, что принесло нам большие головные боли. Это сводится к этому:
Если пользователь A вошел в систему, домашний каталог расшифровывается, а зашифрованные файлы в
/home/.ecryptfs/Aзаблокированы от чтения из других процессов (что хорошо)Если пользователь B не вошел в систему, его домашний каталог не расшифровывается, в нем находятся только зашифрованные файлы.
/home/.ecryptfs/B,Нам нужен сценарий резервного копирования, который может быть запущен, когда пользователь A вошел в систему (потому что она запускает его вручную в нашем случае), а пользователь B может или не может войти (обычно нет).
Теперь вопрос: что мы должны сделать резервную копию? Если мы пойдем за зашифрованными данными, материал пользователя А не может быть сохранен. С другой стороны, расшифрованные данные означают, что пользователь B также должен войти в систему. И смешивание обоих приводит к забавному времени, когда дело доходит до восстановления чего-либо.
Возможно, есть другие решения этой проблемы, которые мы пропустили?
3 ответа
Вы уверены, что /home/.ecryptfs/A заблокирован для чтения? Я использую ecryptfs, и в то время как я вошел в систему и могу просматривать и читать файлы в /home/.ecryptfs/myusername/.Private, Я просто попытался зайти в этот каталог (и подкаталоги) и открыть файлы (используя vim -b) и я мог читать их хорошо. Я бы, конечно, хотел, чтобы их заблокировали для записи, но я не понимаю, почему они будут заблокированы для чтения. Какую версию ОС вы используете? (Я на Ubuntu Lucid 10.04). Может быть, задать отдельный вопрос об ошибках, которые вы получаете, потому что, возможно, что-то еще вызывает проблему.
Чтобы прямо ответить на ваш вопрос - сделайте резервную копию содержимого /home/.ecryptfs/, Это создаст резервные копии (зашифрованные копии) всех файлов для всех пользователей.
Кроме того, вы должны иметь возможность расшифровать файлы, если это необходимо. Таким образом, вы должны хранить распакованную парольную фразу где-нибудь в безопасности, на случай, если пользователь забудет свой пароль, уйдет... Чтобы получить его, попросите пользователя запустить
ecryptfs-unwrap-passphrase
в то время как вошли в систему, и сохраните результат где-нибудь. Он достаточно мал, чтобы вы могли его записать (дважды проверить трижды) и сохранить в сейфе, или попросить двух человек хранить половину каждого или несколько таких в зависимости от того, какой уровень безопасности вам необходим.
В противном случае вам нужно /home/.ecryptfs/*/.ecryptfs/wrapped-passphrase и пароли пользователей.
Также следует помнить, что rsync не сможет ускорить передачу файлов при синхронизации зашифрованных данных. Любое изменение в незашифрованном файле полностью изменит зашифрованный файл. И сжатие не будет работать с зашифрованными данными. Это не должно быть большой проблемой для вашего случая, когда синхронизация происходит по локальной сети, но может быть важно для других людей, читающих этот вопрос. Хотя rsync по-прежнему может проверять, является ли зашифрованный файл неизменным, ему не придется повторно передавать неизмененные файлы.
Читатели этого вопроса также могут быть заинтересованы в этом руководстве по резервному копированию со стороны сопровождающего ecryptfs.
Предположительно, для расшифровки абсолютно необходима пароль пользователя, которого нет. Следовательно, ваш единственный вариант - найти решение, которое создает резервные копии зашифрованных файлов, и использовать его для обоих пользователей. Преимущество этого заключается в том, что, по-видимому, конфиденциальная информация также зашифрована на носителе резервного копирования, что может быть важно, если вы перемещаете ее по всему месту (для удаленного доступа).
Я не знаком с ecryptfs, но кажется, что файлы являются стандартными файлами при просмотре базовой файловой системой (предположительно ext3).
Итак, 1) Является ли "исходный" каталог, который содержит зашифрованные данные на самом деле где-то еще, а затем смонтирован так, что незашифрованная версия появляется в указанном вами месте - в этом случае вы можете просто получить зашифрованные данные из исходного местоположения, Некоторые из документации по Ubuntu предполагают, что незашифрованные личные файлы - это то, что вы видите в /home/.ecryptfs/A/Private, а их зашифрованные аналоги фактически присутствуют в /home/.ecryptfs/A/.Private. Если это так, и вы используете rsync, у вас в любом случае будет зашифрованный каталог.Private для обоих пользователей, и для ясности вы можете использовать параметры исключения rsync, чтобы предотвратить резервное копирование незашифрованного частного каталога.
2) В качестве альтернативы ваш вопрос читается немного, как будто вся папка A (или B) зашифрована, и, возможно, незашифрованные и зашифрованные версии смонтированы в одном месте. Если это так, не могли бы вы попробовать что-то вроде mount -o ro --bind /home/.ecryptfs/A /mnt/encryptedA, который предоставил бы другую точку доступа к каталогу A через /mnt/encryptedA. Если это было сделано до входа пользователя в систему, возможно, вы бы сохранили доступ к зашифрованной версии через / mnt / encryptedA, даже если /home/.ecryptda/A предоставляет доступ к незашифрованной версии. Я не знаю, сработает ли это - вам просто нужно попробовать и посмотреть.
Почему бы не "просто" синхронизировать свои файлы при выходе из общего ресурса. таким образом, вместо того, чтобы вручную запускать свою работу, он будет "автоматически запускаться" (cron, action action...) копировать незашифрованные файлы в общий ресурс (который может или не может быть зашифрован), а затем снова шифровать свою собственную FS перед регистрацией из.
Я вижу, что это не окончательное решение, но это означает, что у пользователя всегда будет актуальная резервная копия, поскольку его файлы синхронизируются на сервере. И если пользователь B не вошел в систему в течение некоторого времени, то нет ничего плохого в том, чтобы не создавать резервную копию его, потому что его файлы не изменились с самого начала.
Это что-то вроде того, что вы ищете, или вы стремитесь к более... оптимизированному, все в одном решении?
В идеале, хотя бы лучше пересчитать лот за зашифрованный перевод для резервного копирования, так как прямо сейчас вы оставляете свои ценные данные открытыми для человека в середине и / или пытаетесь понюхать.