В настоящее время я занимаюсь «проектированием» своей личной (на базе Linux) ИТ, в частности, резервных копий.
У меня есть несколько серверов, которые генерируют данные, заслуживающие резервного копирования (базы данных, файлы и т. Д.), И я хотел бы разместить их в центральном хранилище резервных копий (которое снова создается в другом месте).
В настоящее время у меня возникают мысли о безопасности: что произойдет, если машина перейдет в собственность?
Первоначально я планировал, что все системы будут использовать одного и того же пользователя резервного копирования, но это оказалось проблемой: если один из клиентов становится владельцем, он может изменять произвольные другие данные резервного копирования.
Я рассматриваю возможность создания одного пользователя резервного копирования для каждого источника данных, который у меня есть. Поскольку количество имеющихся у меня источников данных довольно постоянно, для меня это не проблема. Однако я чувствую, что нарушаю принцип DRY: наверняка кто-то где-то уже думал об этой проблеме, есть ли какие-либо корпоративные / известные инструменты, которые я наблюдал? Или есть совершенно другой способ реализовать это?
Я работал в месте, которое было похоже на то, на что вы смотрите.
У нас было множество серверов, в основном Linux, и все они выполняли резервное копирование на центральный сервер, в основном с использованием NFS. Наша CRM-система была разработана собственными силами, поэтому ее можно было перестроить в случае необходимости, и она могла останавливаться каждый час и создавать резервные копии своих баз данных. Главный файловый сервер каждую ночь делал резервную копию, полную или инкрементную.
На центральном сервере резервного копирования на постоянной основе выполнялся Crashplan для внешнего резервного копирования, и мы архивировали примерно одну полную резервную копию в год на другой диск.
Любой взломанный сервер может повлиять только на резервные копии этого сервера, но не на архивы или удаленный сайт. Если сервер резервного копирования был скомпрометирован, это могло повлиять на все «активные» резервные копии, но не на архивы и не на внешние копии. Нас не волновало, что сервер будет скомпрометирован, но если что-то случится с дисками, на которых мы храним резервные копии, мы посчитали, что этого достаточно, чтобы можно было перейти к удаленной копии.
Резервное копирование Borg предоставляет клиентские репозитории с использованием одного пользователя в центральном репо.
Вам следует зашифровать все резервные копии в состоянии покоя, на уровне ОС / оборудования и / или на уровне репозитория.
https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html#restrictions
Решите каждую из реальных угроз с помощью инструмента, который хорош в одном деле.
Собственная цель резервного копирования компрометирует все исходные резервные копии
Кто владеет одним источником, может захотеть скомпрометировать резервные копии других источников.
chroot пользователь на источник)Используя учетные данные для загрузки резервных копий, злоумышленник компрометирует старые резервные копии.
Взломанный источник пытается отказать в обслуживании, предотвращая резервное копирование из других источников
ForceCommand internal-sftp)Взломанный источник пытается вызвать ошибку администратора во время восстановления или резервного копирования
Резервные копии могут быть скомпрометированы между источником и исходной целью резервного копирования