Резервные копии «только push»?

Людей явно волнует эта проблема, поэтому сервисы вроде тарзнак существует. При этом используются отдельные ключи чтения и записи.

Для выполнения резервного копирования у вас должен быть только ключ записи.

Вы можете хранить ключ чтения вдали от системы, для которой выполняется резервное копирование, и использовать его только тогда, когда вам нужно восстановить файлы.

Резервные копии зашифровываются с помощью ключей перед отправкой в ​​службу резервного копирования.

Я понимаю, что стандартный сервер svnserve (тот, который обрабатывает протокол "svn: //" или "svn + ssh: //" для репозитория управления версиями Subversion) позволяет людям фиксировать новые версии в репозитории, но делает это практически невозможно «потерять» версии, ранее внесенные в репозиторий.

(Возможно, ваше онлайн-пространство для резервного копирования уже настроило для вас такой сервер).

Проблема, на которую вы ссылаетесь, на самом деле является проблемой защиты ваших резервных копий после того, как вы их создали.

1. Стандартный подход к этой проблеме - использовать съемные носители в той или иной форме, которые регулярно снимаются с сайта.

   • Как правило, с ленточными носителями LTO все ленты с резервными копиями будут перемещаться за пределы объекта по регулярному графику, так что единственные ленты с резервными копиями, которые у вас есть на месте, - это те, которые активно используются в ленточной библиотеке для записи данных резервного копирования.
   • Я также иногда видел, как это делалось с USB-флешками и съемными дисками. Такой подход защищает ваши резервные копии как от злонамеренных действий, так и от физических катастроф.
     
     
2. Немного другой подход к этому подходу - использовать носители с однократной записью, чтобы резервные копии не могли быть удалены после их создания.
   • CD / DVD или носители WORM LTO, как правило. Обычно этот подход несколько более ограничен по объему, потому что он может довольно быстро стать дорогостоящим и трудоемким.
     • Например, в среде с высоким уровнем безопасности, в которой я работал, у нас были сценарии для непрерывного копирования журналов нашего сервера на резервный сервер, а затем записи их на DVD каждую ночь в качестве механизма для сохранения информации в них. . В случае, если что-то пошло не так или нас взломали, очистка журналов на рассматриваемом сервере не принесет особой пользы.

В наши дни с распространением систем резервного копирования с диска на диск ни один из вариантов не всегда доступен или осуществим, но есть много способов добиться того же. В основном они делятся на две категории.

1. Одна категория, как упоминалось в комментариях, представляет собой использование криптографии с открытым ключом для разделения разрешений на чтение и запись на криптографическом уровне.
   • Одна из таких услуг - тарзнак. Поскольку для чтения и записи данных используются разные ключи, вы можете хранить каждый ключ в другом месте, чтобы злоумышленник, скомпрометировавший ваши резервные копии, не мог их прочитать.
   • Tarsnap - далеко не единственный поставщик такой услуги, и вы даже можете развернуть собственное решение с помощью широко доступных криптографических инструментов с открытым ключом. Предположительно, однако, они все равно смогут «возиться» с резервными копиями (уничтожить или повредить их).
   • Это наиболее полезно в ситуациях соответствия или в ситуациях, когда важна конфиденциальность данных и есть опасения, что злоумышленник сможет получить информацию (прочитать ваши резервные копии), но не защищает от уничтожения или повреждения злоумышленником этих резервных копий.
     
     
2. Другая категория состоит в том, чтобы фактически сегментировать разрешения, чтобы у вашего сервера резервного копирования не было разрешений, необходимых для изменения или перезаписи данных.
   • Очевидный способ сделать это - предоставить вашему серверу / службе резервного копирования только права на чтение и запись на уровне файловой системы, но не изменять или удалять разрешения.
   • Вы можете добиться того же, отделив сервер резервного копирования от сервера, на котором хранятся резервные копии, так что компрометация фактических резервных копий включает в себя больше, чем просто компрометацию сервера, который используется для создания ваших резервных копий.
     • Это подход, который я использую сейчас для $ [enterprise_overlord]. Резервные копии реплицируются вне сайта (система с диска на диск), но доступ к основному резервному узлу и внешнему узлу осуществляется с использованием разных учетных записей, поэтому компрометация одного узла не позволяет скомпрометировать другой. Каждый узел может читать данные другого, но каждый узел может изменять / удалять только свои собственные данные.
       
       
3. Эти два подхода можно даже комбинировать для истинно параноиков / лучшего из обоих миров.

Наконец, даже если вы используете сценарий «диск-диск», нет причин, по которым вы не можете реализовать решение, которое эффективно переводит резервные копии в автономный режим. Вы можете настроить систему, чтобы автоматически переводить сервер / диск, на котором хранятся ваши резервные копии, в автономный режим после завершения резервного копирования и возвращать его в оперативный режим только тогда, когда запланировано выполнение следующих резервных копий, или, менее радикально, перемонтировать том, сохраняя ваши резервные копии как прочитанные -только. Кажется, больше работы, чем настройка разрешений, как указано выше, но это возможно.

Мы справляемся с этим путем использования amazon S3, который позволяет записывать новые объекты, но не удалять их с помощью учетных данных на сервере, а затем использовать версонирование в корзине, поэтому даже если злоумышленник хранит плохие резервные копии, старые (хорошие) все еще там.

Пока работает нормально.