У нас есть небольшая сеть с сервером Ubuntu посередине и ноутбуками Ubuntu. Все ноутбуки используют eCryptfs для шифрования всего домашнего каталога пользователей. Обычно на каждый ноутбук приходится два или более пользователей. Процедура резервного копирования остается внутри сети, поэтому мы можем передавать файлы в незашифрованном виде на сервер. Мы хотели бы пойти с rsync
на основе решения, но также подходят и для других.
Мы столкнулись с трудностями при попытке сделать резервную копию домашних каталогов ноутбуков, что доставляло нам большую головную боль. Все сводится к следующему:
Если пользователь A вошел в систему, домашний каталог расшифровывается, а зашифрованные файлы в /home/.ecryptfs/A
заблокированы от чтения из других процессов (что хорошо)
Если пользователь B не вошел в систему, его домашний каталог не расшифровывается, в нем есть только зашифрованные файлы /home/.ecryptfs/B
.
Нам нужен сценарий резервного копирования, который может запускаться, пока пользователь A вошел в систему (потому что в нашем случае он запускает его вручную), а пользователь B может войти или не войти в систему (обычно нет).
Теперь вопрос: какой мы должны сделать резервную копию? Если мы перейдем к зашифрованным данным, данные пользователя A не могут быть скопированы. С другой стороны, расшифрованные данные означают, что пользователь B должен тоже войти в систему. И когда дело доходит до восстановления чего-либо, смешивание обоих приводит к веселому времяпрепровождению.
Возможно, есть другие решения этой проблемы, которые мы упустили?
Ты уверен что /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, событие действия ...) копировать незашифрованные файлы в общий ресурс (который может быть или не может быть зашифрован), а затем снова зашифрует свою собственную FS перед регистрацией вне.
Я вижу, что это не окончательное решение, но это означает, что у пользователя всегда будет актуальная резервная копия, поскольку его файлы синхронизируются на сервере. И если пользователь B не входил в систему какое-то время, то нет ничего плохого в том, чтобы не создать его резервную копию, потому что его файлы изначально не изменились.
Это что-то вроде того, что вы ищете, или вы стремитесь к более ... упрощенному, все в одном решении?
Хотя в идеале было бы лучше отказаться от зашифрованной передачи для резервного копирования, так как прямо сейчас вы оставляете свои ценные данные открытыми для человека в середине и / или попытках сниффинга.