Безопасное резервное копирование вне сайта, даже в случае хакерского root-доступа

Я ищу способ реализовать более безопасный способ резервного копирования за пределы площадки, который также защитит мои данные от ситуации, когда злонамеренный хакер получил root-доступ к моему серверу. Даже если вероятность этого меньше, чем другие виды рисков, если SSH и защита паролем правильно настроены, а система поддерживается в актуальном состоянии, количество повреждений, которые можно навсегда нанести, действительно велико, и поэтому я Я хотел бы найти решение, чтобы ограничить это.

Я уже пробовал два способа резервного копирования за пределы сайта:

• простое монтируемое в корневой каталог webdav-монтирование (и сконфигурированное в fstab), куда копируются резервные данные. Проблема : на самом деле не резервное копирование вне сайта, потому что подключение - и, более того, доступ - к удаленному расположению постоянно остается открытым как папка в файловой системе. Это достаточная защита от многих видов атак, если монтируемое устройство имеет ограниченные права доступа (доступ только для чтения с правами root), но не защищает от злоумышленника с root-доступом.

• Резервное копирование Borg через SSH с ключом аутентификации. Проблема : подключение к этому внешнему серверу можно выполнить с помощью ключа, который хранится на хосте, если злонамеренный пользователь имеет root-доступ к хосту.

В качестве решения я думаю об этих возможных путях, но я не знаю, как и с чем:

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

Решения, которые не очень интересны в моей ситуации:

• Дополнительное задание резервного копирования на внешнем хосте, которое переносит их в местоположение, недоступное первому хосту (из-за технических ограничений).

Может ли кто-нибудь дать совет о том, как создать правильное резервное копирование для моего случая?

Все ваши предложения в настоящее время имеют одну общую черту: источник резервного копирования выполняет резервное копирование и имеет доступ к месту назначения резервной копии. Независимо от того, монтируете ли вы расположение или используете такие инструменты, как SSH или rsync, исходная система каким-то образом имеет доступ к резервной копии. Следовательно, компрометация на сервере может также поставить под угрозу ваши резервные копии.

Что, если решение для резервного копирования имеет доступ к серверу? Система резервного копирования может выполнять свою работу с доступом только для чтения, поэтому любой компромисс в системе резервного копирования, вероятно, не скомпрометирует сервер. Кроме того, система резервного копирования может быть выделена только для этой цели, что делает содержимое резервной копии единственным вектором атаки. Это было бы очень маловероятно и потребовало бы действительно сложной атаки.

Чтобы избежать перезаписи резервных копий с подделанным или поврежденным содержимым, делайте инкрементные резервные копии, которые позволяют восстановить любое предыдущее состояние в течение определенного периода восстановления.

Неизменное хранение

Один хороший вариант - сделать хранилище резервных копий неизменным или, по крайней мере, обеспечить надежное управление версиями, которое обеспечивает эффективную неизменность. Чтобы было ясно: неизменный означает, что не может быть изменен или постоянный.

Есть несколько служб, которые могут сделать это для вас. AWS S3, BackBlaze B2 и я подозреваю, что Azure и Google предлагают аналогичную услугу. Возможно, вы могли бы настроить сервер для этого, но я не уверен, как.

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

* AWS S3 **

Я наиболее знаком с AWS S3. S3 обеспечивает версионное, зашифрованное хранилище с высоким уровнем надежности.

S3 поддерживает управление версиями, что дает вам эффективную неизменность. Вы можете использовать правила жизненного цикла для удаления старых версий файлов после периода времени, который вы можете настроить. Вы также можете заархивировать версии в холодное хранилище (архив ледника), стоимость которого составляет около 1 долл. США / ТБ / месяц.

Вы можете использовать интеллектуальный класс многоуровневого хранения для сокращения затрат. Я предпочитаю использовать правило жизненного цикла, чтобы переместить все статические данные в нечастый класс доступа, который имеет длительную и умеренную (горячую) производительность, но не обладает масштабируемостью или производительностью стандарта S3.

S3 использует пользователей и политики IAM (управление доступом к личности, т.е. управление пользователями). Это дает вам очень детальный контроль над тем, что ваша программа резервного копирования может делать с вашим хранилищем. Вы можете дать пользователю разрешения на загрузку, но запретить обновление и удаление. Вы также можете требовать многофакторной аутентификации для удаления файлов или даже обеспечить блокировку объекта, чтобы файлы не могли быть удалены.

Предлагаемое программное обеспечение

Я создаю инкрементные резервные копии, используя Restic . Restic загружает новые файлы в ваше хранилище. Я считаю (но я могу ошибаться), что он создает новые файлы, но в общем случае он не обновляет и не удаляет файлы.

Борг это еще один вариант. Раньше я использовал Borg, но обнаружил, что при моих средних размерах резервных копий в сотни МБ он каждый день эффективно загружал все мои данные из EC2 в S3. Для меня это не постепенно, поэтому я перестал его использовать. Я нашел документацию по этому вопросу, но у меня нет ссылки.

Существуют десятки программ, которые можно загружать в облачное хранилище.

Защищенное хранилище

С помощью некоторого программного обеспечения для резервного копирования вы можете попытаться дать пользователю IAM разрешение на запись новых файлов, но не обновлять существующие. Это легко сделать с помощью AWS IAM, но согласно приведенному ниже комментарию Restic не будет работать с этими разрешениями. Вы также можете иметь многофакторную аутентификацию, необходимую для удаления файлов из S3.

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

Borg Backup поддерживает удаленные репозитории только для приложений . Любой компромисс резервного копирования сервера может привести только к созданию новых резервных копий, а не к перезаписи только старых.

Решения, которые не очень интересны в моей ситуации:

Дополнительное задание резервного копирования на внешнем хосте, которое передает их в место, недоступное первому хосту.

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

(Из-за технических ограничений)

Технические ограничения сделаны для преодоления.

Может ли кто-нибудь дать совет о том, как создать правильное резервное копирование для моего случая?

Ленточные накопители уже почти 70 лет обеспечивают надежную внешнюю защиту от всевозможных бедствий, включая хакеров.

Вы можете использовать службы хранения, такие как AWS S3 (или, возможно, Google или эквивалент Azure), где вы можете предоставить полномочия PUT вашей корневой учетной записи для вашего сегмента, но не УДАЛИТЬ разрешения. Таким образом, вы можете использовать push-модель, и злоумышленник не сможет удалить резервную копию.

Существуют и другие меры безопасности, которые вы можете предпринять с AWS, например, требовать, чтобы MFA выполнял DELETE на корзине, но разрешать PUT и GET без MFA. Таким образом, вы можете как резервировать свои данные, так и извлекать их для восстановления своих услуг, не используя ваше устройство MFA, что может быть полезно в каком-то экстремальном (и, возможно, слишком неясном, чтобы даже упоминать) случае, когда доступ к устройству MFA может скомпрометировать его.

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

Резервное копирование Borg через SSH с ключом аутентификации. Проблема: подключение к этому внешнему серверу можно выполнить с помощью ключа, который хранится на хосте, если злонамеренный пользователь имеет root-доступ к хосту.

Вы можете использовать команду option в ваших авторизованных ключах. Вы исправляете команду, разрешенную в удаленном режиме.

Как добавить команды в SSH авторизованных ключей

Даже если злоумышленник восстановит учетную запись root, он не сможет сделать ничего, кроме определенной команды.

Техника, которую вы можете настроить, - это использовать синхронизацию между вашим сервером и удаленным сервером резервного копирования и позволить удаленному серверу резервного копирования делать моментальные снимки или что-нибудь еще на его конце, чтобы сторона сервера стирания не приводила к удалению вне сайта.