Как отговорить хакера с root-доступом от удаления удаленных резервных копий?
В настоящее время я изучаю лучшее решение для резервного копирования для моего веб-сервера 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, Благодаря разным обновлениям и сжатию мои ежедневные резервные копии достаточно малы по размеру, поэтому они должны быть чрезвычайно экономичными.
Спасибо всем за помощь и предложения.