Безопасное резервное копирование вне сайта, даже в случае хакерского root-доступа
Я ищу способ внедрить более безопасный способ резервного копирования за пределы площадки, который также защитит мои данные от ситуации, когда злонамеренный хакер получил root-доступ к моему серверу. Даже если вероятность этого меньше, чем другие виды рисков, если SSH и защита паролем правильно настроены, а система поддерживается в актуальном состоянии, количество повреждений, которые можно навсегда нанести, действительно велико, и поэтому я Я хотел бы найти решение, чтобы ограничить это.
Я уже пробовал два способа резервного копирования за пределы сайта:
простое монтируемое в корневой каталог webdav-монтирование (и настроенное в fstab), куда копируются резервные копии данных. Проблема: на самом деле резервное копирование не выполняется из-за того, что соединение - и, более того, доступ - к удаленному расположению постоянно остается открытым как папка в файловой системе. Это достаточная защита от многих видов атак, если монтируемое устройство имеет ограниченные права доступа (доступ только для чтения с правами root), но не защищает от злоумышленника с root-доступом.
Резервное копирование Borg через SSH с ключом аутентификации. Проблема: подключение к этому внешнему серверу можно выполнить с помощью ключа, который хранится на хосте, если злонамеренный пользователь имеет root-доступ к хосту.
В качестве решения я думаю об этих возможных путях, но я не знаю, как и с чем:
- Резервные копии могут быть только записаны или добавлены к месту назначения, но не могут быть удалены из
- Использование программного обеспечения для резервного копирования, которое обрабатывает внешние резервные копии и не поддерживает массовое удаление внешних резервных копий с первого хоста.
Решения, которые не очень интересны в моей ситуации:
- Дополнительное задание резервного копирования на внешнем хосте, которое передает их в место, недоступное первому хосту. (Из-за технических ограничений)
Может ли кто-нибудь дать совет о том, как создать правильное резервное копирование для моего случая?
7 ответов
Все ваши предложения в настоящее время имеют одну общую черту: источник резервного копирования выполняет резервное копирование и имеет доступ к месту назначения резервной копии. Независимо от того, монтируете ли вы расположение или используете такие инструменты, как SSH или rsync, исходная система каким-то образом имеет доступ к резервной копии. Следовательно, компрометация на сервере может также поставить под угрозу ваши резервные копии.
Что, если решение для резервного копирования имеет доступ к серверу? Система резервного копирования может выполнять свою работу с доступом только для чтения, поэтому любой компромисс в системе резервного копирования, вероятно, не скомпрометирует сервер. Кроме того, система резервного копирования может быть выделена только для этой цели, что делает содержимое резервной копии единственным вектором атаки. Это было бы очень маловероятно и потребовало бы действительно сложной атаки.
Чтобы избежать перезаписи резервных копий с подделанным или поврежденным содержимым, делайте инкрементные резервные копии, которые позволяют восстановить любое предыдущее состояние в течение определенного периода восстановления.
Неизменное хранение
Один из вариантов - сделать ваше хранилище резервных копий неизменным или, по крайней мере, сделать версии неизменяемыми.
Я создаю инкрементные резервные копии, используя Restic. Restic загружает новые файлы в AWS S3, используя пользователя IAM с прикрепленной политикой, которая дает разрешение на запись новых файлов, обновление файлов и удаление файлов. У меня включено ведение версий S3, поэтому, если учетные данные скомпрометированы, а файлы изменены или удалены, я могу восстановить ведро / резервные копии на определенный момент времени. Поскольку файлы, как правило, не изменяются, это не займет дополнительного места для хранения, если что-то не так. Вы также можете удалить старые версии через заданное количество дней, недель или месяцев.
Защищенное хранилище
Вы можете попробовать дать пользователю IAM разрешение на запись новых файлов, но не обновлять существующие. С AWS IAM легко сделать это ограничение, но я не уверен, будет ли Restic работать с этими разрешениями, я не пробовал. Вы также можете иметь многофакторную аутентификацию, необходимую для удаления файлов из S3.
Backblaze B2 имеет аналогичные функции, но имеет более дешевое хранилище и пропускную способность.
Borg Backup поддерживает удаленные репозитории только для приложений. Любой компромисс резервного копирования сервера может привести только к созданию новых резервных копий, а не к перезаписи только старых.
Решения, которые не очень интересны в моей ситуации:
Дополнительное задание резервного копирования на внешнем хосте, которое передает их в место, недоступное первому хосту.
Основная проблема заключается в том, что если вы можете получить удаленный доступ к резервным копиям, то и хакер может.
(Из-за технических ограничений)
Технические ограничения сделаны для преодоления.
Может ли кто-нибудь дать совет о том, как создать правильное резервное копирование для моего случая?
Ленточные накопители уже почти 70 лет обеспечивают надежную внешнюю защиту от всевозможных бедствий, включая хакеров.
Резервное копирование Borg через SSH с ключом аутентификации. Проблема: подключение к этому внешнему серверу можно выполнить с помощью ключа, который хранится на хосте, если злонамеренный пользователь имеет root-доступ к хосту.
Вы можете использовать команду option в ваших авторизованных ключах. Вы исправляете команду, разрешенную в удаленном режиме.
Как добавить команды в SSH авторизованных ключей
Даже если злоумышленник восстановит учетную запись root, он не сможет сделать ничего, кроме определенной команды.
Вы можете использовать службы хранения, такие как AWS S3 (или, возможно, Google или эквивалент Azure), где вы можете предоставить полномочия PUT вашей корневой учетной записи для вашего сегмента, но не УДАЛИТЬ разрешения. Таким образом, вы можете использовать push-модель, и злоумышленник не сможет удалить резервную копию.
Существуют и другие меры безопасности, которые вы можете предпринять с AWS, например, требовать, чтобы MFA выполнял DELETE на корзине, но разрешать PUT и GET без MFA. Таким образом, вы можете как резервировать свои данные, так и извлекать их для восстановления своих услуг без использования устройства MFA, что может быть полезно в каком-то экстремальном (и, возможно, слишком неясном, чтобы даже упоминать) случае, когда доступ к устройству MFA может скомпрометировать его.
Кроме того, комментарий, выходящий за рамки, может показаться интересным / полезным, есть несколько способов настроить S3 и аналогичные службы для автоматического переключения при сбое в случае, если основной источник данных отключен.
Техника, которую вы можете настроить, - это использовать синхронизацию между вашим сервером и удаленным сервером резервного копирования и позволить удаленному серверу резервного копирования делать моментальные снимки или что-нибудь еще на его конце, чтобы сторона сервера стирания не приводила к удалению вне сайта.