Я ищу способ реализовать более безопасный способ резервного копирования вне офиса, который также защитит мои данные от ситуации, когда злонамеренный хакер получил root-доступ к моему серверу. Несмотря на то, что вероятность того, что это произойдет, меньше, чем другие виды рисков, если SSH и защита паролем правильно настроены и система поддерживается в актуальном состоянии, размер ущерба, который может быть нанесен навсегда, действительно велик, и поэтому я Я хотел бы найти решение, чтобы ограничить это.
Я уже пробовал два способа резервного копирования вне офиса:
простое монтирование webdav с возможностью записи root (и настроенное в 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 для своей корзины, но не разрешения DELETE. Таким образом, вы можете использовать модель push, и злоумышленник не сможет удалить резервную копию.
Есть дополнительные меры безопасности, которые вы можете предпринять с AWS, например, требовать от MFA выполнять DELETE в корзине, но разрешать PUT и GET без MFA. Таким образом, вы можете как резервировать свои данные, так и извлекать их для восстановления своих сервисов без использования устройства MFA, что может быть полезно в некоторых крайних (и, вероятно, слишком непонятных, чтобы даже упоминать) случаях, когда доступ к устройству MFA может поставить под угрозу его.
Кроме того, комментарий, выходящий за рамки, может показаться вам интересным / полезным, существует несколько способов настроить S3 и аналогичные службы для автоматического переключения при отказе в случае, если основной источник данных отключен.
Бэкап Borg через SSH с аутентификацией по ключу. Проблема: подключение к этому внешнему серверу может быть выполнено с помощью ключа, хранящегося на хосте, если злоумышленник имеет root-доступ к хосту.
Вы можете использовать команду option в вашем authorized_keys. Вы исправляете команду, разрешенную в удаленном.
как добавить команды в ssh authorized_keys
Даже если злоумышленник восстановит корень входа в систему, он не сможет делать ничего, кроме определенной команды.
Метод, который вы могли бы настроить, - это использование синхронизации между вашим сервером и удаленным сервером резервного копирования и разрешение удаленному серверу резервного копирования делать снимки или что-то еще на его конце, чтобы на стороне сервера стирания не происходило стирание за пределами площадки.