☰

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

tag-icon • tag-icon backup
Как защититься от администратора, который одновременно удалит и сервер, и его резервную копию в облаке?

У меня есть несколько (виртуальных) серверов. Они делают резервные копии на Backblaze B2 с использованием ключа приложения.

Я хочу нанять человека, который поможет мне администрировать эти серверы.

Когда этот человек получает root-доступ к серверу (что мне и нужно), он также получает доступ к ключу приложения B2. Это означает, что он может удалить серверирезервная копия.

Какую процедуру/настройку я мог бы использовать для защиты от этого пограничного случая? У меня есть автономные резервные копии, но они ежемесячные, тогда как резервные копии B2 — ежедневные.

решение1

В некоторых средах вы просто разделяете работу на две команды: одна команда управляет/охраняет серверы, другая управляет/охраняет резервные копии.

другая часть, на мой взгляд, даже более важна: если резервная копия доступна для записи, особенно из системы, резервная копия которой создается, то это НЕ хорошая резервная копия.

системная проблема многих инструментов, таких как borg. Лучше всего (в облачном мире) отправлять резервные копии в AWS Glacier, сохраняя их в S3 с ролью, которая может только их создавать. Существуют графики удаления, и никому не нужно иметь возможность делать это «быстро».

также не забывайте, что на эту тему есть книги.

решение2

Вот как это сделать:

  1. На Backblaze B2 создайте ключ приложения, который не может удалять файлы:

    b2 create-key --bucket MyBucket MyKeyName listBuckets,listFiles,readFiles,writeFiles

  2. Настройте резервную копию так, чтобы она использовала этот ключ и не пыталась удалить старые файлы резервной копии. Например, в duplicity, не используйте remove-older-than, remove-all-but-n-full, или remove-all-inc-of-but-n-full; в duply, не используйте purgeили purgeIncr.

  3. Чтобы удалить старые резервные копии, задайте пользовательские параметры жизненного цикла для контейнера; например, сделайте так, чтобы строки, начинающиеся с , duplicity-fullскрывались через 360 дней и удалялись еще через 360 дней; и так далее для файлов, начинающихся с duplicity-incи duplicity-new.

Обновлять:

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

За исключением этого, B2 также предоставляет функционал для фактического удаления версий файлов. Пользователь, у которого нет разрешения deleteFiles, на самом деле имеет разрешение скрывать файлы, но не удалять версии файлов.

Мне кажется, что remove-...функциональность Duplicity должна быть реализована путем скрытия файлов. (Затем настройка контейнера будет определять, удалять ли эти скрытые версии файлов по истечении некоторого времени.) Однако бэкэнд Duplicity B2 этого не делает; он фактически удаляет версии файлов.

решение3

В большинстве публичных облаков доступ к серверу по ssh не означает, что вы можете удалить сервер. Существует разница между администрированием на сервере и в облачной учетной записи. Поэтому вы можете разделить их. Вы также можете довольно сильно разделить разрешения, особенно на Amazon AWS. Например, вы можете дать кому-то разрешение на перезагрузку сервера, но не на его удаление. А в AWS есть опция защиты от удаления на виртуальных машинах.

В наши дни лучше всего использовать средства управления конфигурацией, такие как Chef/Puppet/Salt/Ansible, для внесения любых изменений на серверах и не входить на них.

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

Связанный контент