У меня есть (виртуальные) серверы. Они делают резервную копию себя на Backblaze B2 с помощью ключа приложения.
Я хочу нанять человека, который поможет мне управлять этими серверами.
Когда этот человек получает root-доступ к серверу (который я хочу), он также получает доступ к ключу приложения B2. Это означает, что он может удалить сервер и резервная копия.
Какую процедуру / настройку я мог бы использовать для защиты от этого крайнего случая? У меня есть автономные резервные копии, но они ежемесячные, а резервные копии B2 - ежедневно.
В некоторых envs вы просто разделяете задание на две команды: одна команда запускает / охраняет серверы, а другая запускает / охраняет резервные копии.
другая часть, я думаю, даже более важна: если резервная копия доступна для записи, особенно из системы, для которой создается резервная копия, это НЕ хорошая резервная копия.
системная проблема во многих инструментах, таких как borg. Лучше всего, если вы можете (в облачном мире) продвигать резервные копии в AWS glacier, сохраняя их в S3 с ролью, которая может только их создавать. есть графики удаления, и никто не должен иметь возможность сделать это «быстро».
Кроме того, не забывайте, что есть книги об этом.
Вот как это сделать:
В Backblaze B2 создайте ключ приложения, который не может удалять файлы:
b2 create-key --bucket MyBucket MyKeyName listBuckets,listFiles,readFiles,writeFiles
Настройте резервную копию так, чтобы она использовала этот ключ и не пыталась удалить старые файлы резервной копии. Например, в duplicity, не используй remove-older-than, remove-all-but-n-full, или remove-all-inc-of-but-n-full; в duply, не используй purge или purgeIncr.
Чтобы удалить старые резервные копии, установите пользовательские параметры жизненного цикла для корзины; например, установите строки, начинающиеся с duplicity-full быть скрытым через 360 дней и удаленным еще через 360 дней; и так далее для файлов, начинающихся с duplicity-inc и duplicity-new.
Обновить:
B2 фактически не предоставляет никаких функций для «удаления файла». Каждый раз, когда вы заменяете один и тот же файл, он сохраняет свою историю, поэтому у файла могут быть «версии» - обычно вам нужна самая последняя версия. B2 предоставляет возможность «скрыть» файл. Когда вы скрываете файл, вы фактически записываете в историю файла, что файл был «удален», вы как бы добавляете новую версию файла, которая является скрытым или удаленным файлом.
Кроме того, B2 также предоставляет функциональные возможности для фактического удаления версий файлов. Пользователь, у которого нет разрешения deleteFiles, действительно имеет разрешение скрывать файлы, но не может удалять версии файлов.
Мне кажется, что двуличие remove-... функциональность должна быть реализована путем скрытия файлов. (В этом случае конфигурация корзины должна фактически удалить эти скрытые версии файлов через некоторое время.) Однако бэкэнд B2 не делает этого; он фактически удаляет версии файлов.
В большинстве общедоступных облаков доступ к серверу по ssh не означает, что вы можете удалить сервер. Есть разница между администрированием на сервере и в облачной учетной записи. Итак, вы можете разделить их. Вы также можете немного разделить разрешения, особенно на Amazon AWS. Например, вы можете дать кому-нибудь разрешение перезагрузить сервер, но не удалить его. А в AWS есть опция защиты от удаления на виртуальных машинах.
В наши дни лучше всего использовать управление конфигурацией, такое как Chef / Puppet / Salt / Ansible, чтобы вносить какие-либо изменения на ваших серверах, а не входить на серверы.
Кроме того, для AWS вы можете делать снимки серверов так часто, как захотите, и это наиболее эффективный способ их резервного копирования.