В настоящее время я ищу лучшее решение для резервного копирования для своего веб-сервера CentOS, и я подумываю использовать либо Tarsnap, либо Amazon S3.
Я пытаюсь понять, как отговорить хакера от удаления как содержимого моего сервера, так и моих удаленных резервных копий в худшем случае, когда он получает root-доступ к моему серверу и, таким образом, имеет доступ к учетным данным аутентификации удаленного резервного копирования. (Я полностью понимаю важность наличия надежного пароля и / или применения только SSH-аутентификации на основе ключа, а также других общих рекомендаций по обеспечению безопасности. Но иногда случается такое, что может быть уязвимость Linux или уязвимость на уровне VPS моего хозяина или что-то еще, более или менее неподвластное мне.)
Я знаю, что и Tarsnap, и Amazon S3 имеют права пользователя только на запись, но проблема в том, что мне также требуется автоматическое сокращение / ротация резервных копий. Можно ли настроить любую из этих служб (или, возможно, какую-либо другую), чтобы запретить удаление поколений резервных копий новее, чем, скажем, 2 дня? Это дало бы мне двухдневный буфер, чтобы заметить, что я был взломан, и не позволил бы хакеру удалить мои новейшие поколения данных.
Или какие-то другие идеи? Большое спасибо!
На фундаментальном уровне ваша проблема частично усугубляется отправкой резервных копий с хоста, а не их извлечением с него.
Вы можете исправить эту проблему и, кроме того, физически (или логически, если необходимо) отключить тома резервного копирования на центральном узле резервного копирования.
У меня есть машины, которые отправляют резервные копии на S3, но эти корзины S3 используют управление версиями, поэтому злоумышленник, отправляющий плохую резервную копию, не является проблемой (а используемые ключи api не имеют прав на удаление объектов, а только добавляют их). Я удаляю старые резервные копии с помощью boto, так как управление версиями и жизненный цикл корзины одновременно не разрешены).
Никакой «стимул» не сработает, эти люди не заботятся о ваших данных.
Что ж, я остановился на Duplicity, поскольку у нее есть собственный интерфейс Amazon S3. Я создал пользователя Amazon S3 через IAM с ограниченными разрешениями только для GETting и PUTting объектов. Я использую --full-if-older-than Возможность дублирования для создания новой полной резервной копии каждые 7 дней. Затем у меня есть автоматическая политика жизненного цикла S3, которая перемещает объекты старше 10 дней в Glacier. Затем вторичное правило удаляет объекты, которые старше 102 дней от Glacier (я добавил немного лишнего, чтобы убедиться, что меня не поразит плата за раннее удаление Glacier до 90 дней). Таким образом, это даст мне более 80 дней резервного копирования в Glacier (после удаления самой старой полной резервной копии ее дочерние инкрементальные копии все еще будут существовать еще несколько дней, но больше не будут действительны) и еще 10 дней новейших резервных копий в S3. . Благодаря разностным обновлениям и сжатию мои ежедневные резервные копии имеют довольно небольшой размер, поэтому это должно быть чрезвычайно экономичным.
Спасибо всем за помощь и предложения.