Недавнийдемонтаж кодовых пространствзаставили меня задуматься о процессах резервного копирования вне офиса (которые я сейчас выполняю вручную с вводом пароля). Я читалобучающие материалыпоказывая, как автоматизировать резервное копирование с помощью duplicity. Они, как правило, вращаются вокруг использования ключа SSH для автоматизации процесса аутентификации на сервере резервного копирования.
Однако мне кажется, что здесь полно дыр. Если сервер, на котором выполняется резервное копирование, скомпрометирован до такой степени, что злоумышленник получил доступ, то он может автоматически войти на сервер резервного копирования и удалить резервные копии. Если предположить, что администратор использовал /usr/bin/nologinфайл /etc/passwdдля пользователя резервного копирования (я понятия не имею, насколько на это можно положиться или помешает ли это удаленной работе duplicity), то злоумышленник все равно может заставить duplicity стереть резервные копии, используя команду duplicity remove-older-than [time now].
Является ли единственным безопасным решением отправлять файлы на сервер резервного копирования с помощью rsync через ssh и иметь "главного пользователя" на сервере резервного копирования, который будет выполнять локальные итеративные резервные копии всех учетных записей пользователей в свою собственную область хранения (например, только у него есть разрешения на свои собственные файлы, но у него есть разрешение на чтение файлов всех других учетных записей)? Или есть способ предотвратить дублирование при удалении резервных копий и предотвратить удаленный вход?
решение1
AFAIK duplicity не может сделать резервную копию удаленного каталога в локальный каталог. Я решаю проблему в два шага. На сервере резервного копирования сделайте:
Запустите rsync через ssh, используя ключи ssh, чтобы синхронизировать удаленный каталог с локальным каталогом.
rsync -avz -e ssh пользователь@удалённый:/удалённый/каталог локальный_каталог
Запустите duplicity из одного каталога в другой. Используйте асимметричные ключи GnuPG, чтобы вам не понадобились парольные фразы во время шифрования.
duplicity --encrypt-key=YOUR_KEYID локальный_каталог file://backup_directory
или без шифрования резервной копии:
duplicity --no-encryption local_directory file://backup_directory
решение2
После загрузки резервной копии вы можете использовать ее, chattr +iчтобы сделать их неизменяемыми, чтобы их нельзя было изменить или удалить. Только root может установить или снять этот флаг.
В качестве альтернативы вы можете передать chownфайлы другому пользователю после загрузки, чтобы резервная учетная запись больше не имела к ним доступа.