Рассмотрим такой сценарий: у меня есть Linux-сервер, для которого ежедневно выполняется автоматическое резервное копирование в удаленное место через rsync или что-то в этом роде. Все в порядке, пока какой-то плохой парень не получит доступ к серверу, не найдет мой сценарий автоматического резервного копирования и не удалит все с сервера резервного копирования.
Я пытаюсь найти какую-то утилиту удаленного резервного копирования, которая позволяет только удаленно добавлять резервные копии, но не удалять их. Я не знаю, как сделать что-либо, что использует ssh только для записи, и я попытался найти что-то, что не использует ssh, но нашел только Коробка резервного копирования.
Теперь это возможно, но я хочу знать, есть ли какой-нибудь канонический способ добиться этого.
У меня много ответов, спасибо всем!
Если вы делаете наивное резервное копирование (единичная копия, перезапись всех данных), тогда нет способа добиться того, чего вы хотите - злоумышленник всегда может «сделать резервную копию» кучи пустых файлов (или пустого набора файлов), что приведет к все ваши данные прощаются. Итак, я предполагаю, что вы делаете правильные архивные резервные копии и достаточно хорошо отслеживаете свои резервные копии, чтобы любые попытки уничтожить резервную копию путем отправки пустого набора резервных копий были обнаружены до того, как будет нанесен какой-либо необратимый ущерб.
Если ваш rsync-over- (предположительно) -SSH использует принудительную команду для запуска rsync в пункте назначения, тогда вы максимально защищены от удаления. Поскольку вы хотите запустить только определенный rsync вы можете жестко закодировать все аргументы, и тогда единственное, что она сможет сделать, это записать новые данные. Архивировать достаточно просто, каждый раз создавая резервную копию в новом дереве и связывая неизмененные файлы с предыдущей резервной копией с помощью жестких ссылок, что экономит место и время передачи.
Другой способ - использовать резервное копирование по запросу, когда сервер резервного копирования инициирует и управляет rsync операция - это означает, что клиентский компьютер даже не имеет возможности запускать ограниченную команду rsync, что означает, что злоумышленник не имеет права удалять файлы.
Все это предполагает, что ваш сервер резервного копирования безопасен. Если злоумышленник может получить к нему доступ другим способом, вы попадете в кость независимо от того, что вы делаете.
Самым простым, вероятно, было бы пойти другим путем с резервными копиями, т.е. вытащить с резервного сервера. Вот как я запускаю резервные копии с помощью rdiff-backup.
Это одна из особенностей, которые мне нравятся в Tarsnap служба резервного копирования. Это позволяет мне создавать подключи с возможностями чтения, записи и / или удаления.
На своих серверах я обычно храню подключи с возможностью чтения и записи. Иногда, когда мне нужно / хочу удалить старые архивы резервных копий, я делаю это, используя главные ключи с моего локального настольного компьютера.
Обратите внимание, что Tarsnap сам по себе является службой хранения. Вы не можете использовать программное обеспечение Tarsnap для создания резервных копий на ваших собственных серверах хранения.
Попытайтесь использовать слой файловой системы только для записи, который будет маскировать ваше действительное место назначения.
Я нашел пример здесь, используя FUSE.
Вы также можете использовать зашифрованную файловую систему, в которую любой может писать, но вам нужно изменить сертификат ключа (кажется, наиболее безопасный вариант, хотя, вероятно, требует более тщательного планирования во время реализации). Если вы пойдете этим путем, посмотрите чек WOCFS (зашифрованная файловая система только для записи) и TrueCrypt
Итак, в то время как первое решение будет «маскировать» вашу файловую систему, которая на самом деле хранится в другом месте внутри машины и может быть изменена для пользователей системы с разрешениями, во втором решении ее можно изменить только с помощью соответствующих ключей.
ftp: например, vsftp имеет возможность отключить удаление, чтобы вы могли только загружать. Затем с другой стороны вы создаете сценарий, который удаляет резервные копии старше x дней. Я использую эту опцию, резервные копии на основном сервере - это простые резервные копии с использованием tar + gz, они загружаются на сервер nas через sftp, а затем сервер nas удаляет резервные копии старше 7 дней.
rsync: сервер rsync имеет возможность отключить удаление, чтобы это также могло работать для вас, но вы должны использовать протокол / сервер rsync. варианты отказа = удалить
Но тогда вам придется время от времени вручную удалять «удаляемые» файлы.
Итак, я узнал, что есть две основные стратегии:
Цитата из rdiff-backup справочная страница относится ко второй стратегии:
Хотя сам ssh может быть безопасным, использование rdiff-backup по умолчанию представляет некоторые риски для безопасности. Например, если сервер запущен от имени пользователя root, то злоумышленник, скомпрометировавший клиента, может затем использовать rdiff-backup для перезаписи произвольных файлов сервера путем "резервного копирования" поверх них. Такую установку можно сделать более безопасной, используя параметр конфигурации sshd command = "rdiff-backup --server", возможно, вместе с параметрами --restrict * для rdiff-backup. Для получения дополнительной информации см. Веб-страницу, вики и записи для параметров --restrict * на этой странице руководства.
--restrict-update-only path
ike --restrict, but only allow writes as part of an incremental
backup. Requests for other types of writes (for instance,
deleting path) will be rejected.
Конечно, ваши резервные копии должны быть инкрементными, и у вас должна быть какая-то система мониторинга, чтобы предотвратить сценарий, когда хакеры копируют ненужные данные, чтобы в конечном итоге «вытеснить» реальные данные из вашей системы инкрементного резервного копирования.
Вероятно, это было не так давно, когда задавался вопрос, но в настоящее время существуют различные утилиты резервного копирования, которые поддерживают это либо напрямую, как опция, либо с помощью простых сценариев / дополнительных настроек.
Один из терминов, широко используемых для обозначения этой функции, - «резервные копии только с добавлением».
Borg backup имеет эту функцию как встроенную опцию. Restic может быть настроен для взаимодействия с удаленной файловой системой, которая не поддерживает операции удаления, или для rclone сервер, который будет обслуживать любой бэкэнд, поддерживаемый rclone, для восстановления, со встроенной опцией rclone для обслуживания в стиле только для добавления.
Кроме того, при резервном копировании в облако многие облачные провайдеры (AWS, B2, Wasabi и т. Д.) Поддерживают наличие сегментов, которые не позволяют удалять данные или косвенно, за счет наличия вечной истории для всех файлов, фактически не поддерживая их удаление (этот параметр иногда настраивается для каждого ключа доступа, а не для самого сегмента).
(Обновление: кто-то удалил ссылки на то, что они назвали «недавно созданными продуктами». Обратите внимание, что ни один из этих продуктов не является новым, они очень хорошо зарекомендовали себя и являются одними из крупнейших продуктов в сфере резервного копирования. Я не имею отношения к этим продуктам и они все бесплатный и открытый исходный код. Они почти так же новы, как rsync или дублированность (преувеличение, чтобы проиллюстрировать точку зрения). В вопросе конкретно рассматривались способы реализации этого, и здесь приводятся ссылки на конкретные решения (в отличие от общего «какое-то программное обеспечение, вероятно, имеет эту функцию»). Фактически, я пришел к этому вопросу также в поисках конкретных решений.