Restic: Поддержка асимметричного резервного копирования

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

• Полезно для резервного копирования почтовых серверов или удаленного резервного копирования данных журнала в случае взлома такого сервера. Конфиденциальные данные, которые были уничтожены с сервера, могут присутствовать в резервной копии, и может быть полезно запретить злоумышленнику доступ к таким историческим данным. Одновременно обсуждалось, что было бы полезно иметь «сетевой сервер BLOB-объектов» с системой возможностей, которая позволяет настраивать доступ только для добавления / только для чтения / для чтения и записи по мере необходимости. Наличие асимметричной криптографии устранит необходимость в наличии _ еще другого_ набора симметричных ключей для выдачи возможностей, а также, вероятно, упростит реализацию системы возможностей.
• В конфигурации с несколькими машинами _one_ резервный ключ может использоваться для доступа к нескольким наборам данных резервных копий без необходимости управлять множеством симметричных ключей. Если используется криптосистема, такая как Curve25519 Дэниела Бернштейна, такой ключ может быть получен из парольной фразы, то есть вы можете использовать одну главную парольную фразу для управления резервными копиями, созданными (потенциально большим) количеством различных доменов безопасности. Хотя чего-то подобного, конечно, можно добиться с помощью симметричных ключей n и зашифрованного хранилища ключей.

@heipei FYI, возможно, вы захотите подписаться на этот выпуск

Что ж, наиболее очевидный и актуальный вариант использования - это не стирать резервные копии злоумышленником, который взломал вашу производственную систему (клиент резервного копирования) и знает, как использовать restic оттуда.

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

Конфиденциальность данных ( write-only ) будет достижима для этих сценариев с применением асимметричного шифрования.

Целостность данных - это немного другое дело:
Хотя вы можете использовать асимметричную криптографию (и схему одноразовой подписи), чтобы доказать, что данный набор данных не был изменен, вы не можете предотвратить его полное удаление или замену. Это проблема, для решения которой требуется система хранения append-only (и read-only для некоторых частей).
Благодаря дискреционному контролю доступа, который относительно просто реализовать в * nix с помощью бэкэнда, такого как ssh (с использованием таких команд, как chmod , chown , chattr +i , chattr +a для настройки политик доступа). append-only резервные копии даже не нужно шифровать, чтобы злоумышленники не могли их прочитать (например, это часть того, что делает rsyslog ), но это внезапно делает сервер резервного копирования интересной целью, и клонирование конфиденциальных данных на большее количество устройств точно не конфиденциальности данных .

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

Это представляет для нас интерес для двух случаев, описанных в https://github.com/restic/restic/issues/187#issuecomment -101974306. Я подписываюсь на эту тему, чтобы следить за этим.

Что касается целостности данных : AFAIK, вы можете добиться поведения append-only на Amazon S3, только предоставив своим учетным данным IAM разрешения PutObject и GetObject , но отказавшись от DeleteObject разрешение.

Что касается конфиденциальности данных , я хотел бы упомянуть сценарий атаки, который возможен за счет использования симметричного шифрования:
Если злоумышленник контролирует учетную запись пользователя жертвы в момент времени, когда жертва использует restic для выполнения резервного копирования, он может:

• украсть ключ restic жертвы
• украсть учетные данные IAM жертвы / логин sftp / ...

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

Асимметричное шифрование может помочь предотвратить это, позволяя жертве хранить ключ для восстановления резервных копий в автономном режиме.

Что касается целостности данных: AFAIK, вы можете добиться поведения только добавления на Amazon S3, только предоставив своим учетным данным IAM разрешения PutObject и GetObject, но отказавшись от разрешения DeleteObject.

К сожалению, PutObject также дает вам право перезаписать ранее загруженный файл. Так, может быть, дело не в полной целостности данных?

Асимметричное шифрование также позволит использовать ключ OpenPGP, например yubikey или что-то в этом роде.

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

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

Я использую как системный администратор для ряда серверов.

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

Для этого требуется поддержка на стороне сервера либо через слой хранения только с добавлением, либо через демон сервера, аналогично тому, как rdiff-backup имеет параметр --restrict-update-only. В настоящее время я работаю над этим, используя доступные только для чтения моментальные снимки репозитория резервных копий на сервере резервного копирования (доступ через sftp).

(Возможно, актуально): в Linux можно добиться только добавления с помощью флага append-only в каталоге (который отключает отключение) вместе с флагом immutable для файлов. За установку этих флагов отвечают команды chattr +a /path/to/directory и chattr +i /path/to/directory/myfile01 соответственно.

мой вариант использования # 533 - автоматическое резервное копирование. как там сказано, асимметричная криптография - это только один из способов сделать это, но кажется первым очевидным решением проблемы.

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

Восстановленная резервная копия должна подключаться к уникальному ключу для этой системы только с правами восстановления / резервного копирования.

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

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

Что касается предотвращения уничтожения данных резервных копий кем-то, кто взламывает сервер: rest-server недавно получил «режим только добавления» с PR https://github.com/restic/rest-server/pull/28, который предотвращает именно это.

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

Функция, которую я ищу, - иметь «резервные» ключи, которые позволят системе писать (резервное копирование) и читать (восстанавливать), но не могут выполнять какие-либо действия администратора (например, удалять, добавлять ключи или даже видеть существование других ключи, (пользователи) или снимки, не связанные с $ backup_key). (Хотя атака по побочному каналу может быть возможна при сравнении времени резервного копирования, для меня не имеет значения, могут ли они определить наличие данных, только то, что они не могут вымогать мои данные и не могут просматривать других пользователей.) Я ожидал обладатель резервного (только) ключа, чтобы иметь возможность продвигать свои собственные парольные фразы. Поэтому, в отличие от запроса michbsd, я мог бы администрировать с нелокальной машины с привилегированным ключом. (Пользуясь SELinux в течение многих лет, я теперь поклонник детализации MAC) Спасибо за чтение. (Извините, если у этого возникла отдельная проблема.) С этой функцией #ResticKillsRansomware

С помощью этой функции #ResticKillsRansomware

В общем, резервные копии, ориентированные на извлечение (в отличие от резервных копий, ориентированных на извлечение), решают проблему с программами-вымогателями, верно? :)

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

Я предполагаю, что Restic - не решение, поскольку он предназначен для работы непосредственно с репозиториями с резервными копиями.

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

Функция, которую я ищу, - иметь «резервные» ключи, которые позволят системе писать (резервное копирование) и читать (восстанавливать), но не могут выполнять какие-либо действия администратора (например, удалять, добавлять ключи или даже видеть существование других ключи, (пользователи) или снимки, не связанные с $ backup_key). (Хотя атака по побочному каналу может быть возможна при сравнении времени резервного копирования, для меня не имеет значения, могут ли они определить наличие данных, только то, что они не могут вымогать мои данные и не могут просматривать других пользователей.) Я ожидал обладатель резервного (только) ключа, чтобы иметь возможность продвигать свои собственные парольные фразы. Поэтому, в отличие от запроса michbsd, я мог бы администрировать с нелокальной машины с привилегированным ключом. (Пользуясь SELinux в течение многих лет, я теперь поклонник детализации MAC) Спасибо за чтение. (Извините, если у этого возникла отдельная проблема.) С этой функцией #ResticKillsRansomware

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

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

Я даже не подозревал, что это существует. D:

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

На данный момент restic (в основном) взаимодействует с «тупым» хранилищем (local, s3, b2, gcs, azure, все, кроме REST-сервера с --append-only ). Он может сохранять, перечислять, получать и удалять данные в бэкэнде. Это необходимо для резервного копирования, поэтому необходимо предоставить необходимые учетные данные для доступа к бэкэнду. С другой стороны, restic может использовать практически любое хранилище, ограничений очень мало. С другой стороны, как только злоумышленники получают доступ к серверу, они могут легко извлечь учетные данные для доступа к бэкэнду и пароль restic, что дает им все возможности: расшифровать исторические данные из репозитория, изменить данные, удалить весь репозиторий.

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

Другая идея состоит в том, чтобы получить доступ к «тупому» хранилищу не напрямую, а косвенно через пользовательскую реализацию сервера. Мы поэкспериментировали с этой идеей и добавили параметр --append-only для REST-сервера , который можно рассматривать как «адаптер» для доступа к «тупому» хранилищу на локальном жестком диске. У меня есть несколько идей, как улучшить эту идею, не обязательно с помощью REST-сервера.

Например, я хотел бы определить протокол для бэкэнда, который обрабатывается парой файловых дескрипторов, например stdin / stdout. Затем мы можем реализовать это в программе, которая запускается через SSH на удаленном компьютере, точно так же, как мы делаем это для бэкэнда sftp. Затем реализация сервера может решить, где хранить данные (локальные, s3, b2 и т. Д.) И какие ограничения применяются (например, «добавлять только старые или новые данные для чтения», без возможности удалить что-либо, кроме файлов блокировки. Сервер например, может быть запущен через ForceCommand при входе в систему через SSH с определенной учетной записью пользователя или SSH-ключом.

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

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

Я скопирую этот текст в первый комментарий в этом выпуске, чтобы его было легче найти.

да, размышляя над этим дальше, я согласен с тем, что асим-шифрование не так полезно для защиты от поглощений - оно более полезно для автоматического резервного копирования (# 533).

наличие собственного протокола связи может быть полезно, но я не уверен, что вы получите от этого по сравнению с текущим сервером REST - не могли бы вы расширить это? чердак / Борг пошел туда: есть клиент-сервер «патентованный» (как, Борг-специфический) протокол там и можно реализовать некоторые ограничения для клиентов. и да, это зависит от ограниченных флагов ForceCommand и "borg serve" ... в документации borg есть некоторые

и, конечно же, наиболее естественный способ защитить резервные копии от скомпрометированного клиента - просто не позволить клиенту выполнять резервное копирование самому, а вместо этого попросить сервер извлекать файлы из резервных копий, «в стиле бакулы» («Это происходит в ночь и высасывает суть из ваших компьютеров », для тех, кто помнит эту запоминающуюся фразу). похоже, что нет хорошо задокументированного или элегантного способа сделать это в borg, FAQ указывает на https://github.com/borgbackup/borg/issues/900 в качестве обсуждения по теме. здесь это отслеживается в № 299, о котором здесь еще не упоминалось.

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

1. серверу резервного копирования не нужен root-доступ на всех машинах
2. тем не менее, компрометация машины все еще может быть восстановлена, даже если они могут испортить резервные копии

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

Привет,

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

Я считаю, что сейчас все капли зашифрованы одним и тем же ключом, и это отлично работает.
Если бы мы использовали асимметричное шифрование, как работает OpenPGP, каждый сделанный снимок генерировал бы симметричный ключ, зашифрованный с помощью открытого ключа, и добавлял бы его в репозиторий. Но я предполагаю, что проблема в том, что для того, чтобы узнать, что нужно дедуплицировать, а что резервировать, вы должны сначала прочитать информацию, следовательно, вам также понадобится закрытый ключ. Это правильно?
Если это так, может ли какое-нибудь доказательство с нулевым разглашением помочь в этом?

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

Я обновил резюме в первом посте. Бэкэнд rclone был добавлен тем временем, его можно использовать как «адаптер», как описано выше, и получить к нему доступ, например, через SSH.

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

Я надеюсь, что это опечатка: вы ведь имеете дело с зашифрованным материалом ключевого файла, не так ли? Надеюсь, злоумышленник, получивший доступ к серверу, не имеет доступа к паролю в виде открытого текста. Худшее, что они могут сделать, - это попытаться подобрать или угадать «пароль пользователя», который используется для расшифровки основных ключей шифрования и аутентификации в репозитории.

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

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

Я предполагаю, что это зависит от точного сценария: если вы вводите пароль вручную, правильно. С другой стороны, если вы выполняете запланированное автоматическое резервное копирование, «пароль пользователя» должен храниться где-то на сервере.

И, конечно же, злоумышленник может заменить двоичный файл Restic на тот, который утекает введенный пароль, и ждать, пока вы его введете. Вы не можете доверять скомпрометированной системе.

«пароль пользователя» должен храниться где-нибудь на сервере.

Под «сервером» вы имеете в виду «машину, на которой мы запускаем restic, на которой мы сохраняем данные» или «машина, которая получает / хранит данные из резервной копии»?

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

Под «сервером» вы имеете в виду «машину, на которой мы запускаем restic, на которой мы сохраняем данные» или «машина, которая получает / хранит данные из резервной копии»?

Машина, на которой мы запускаем restic, сохраняем данные.

Я понимаю вашу точку зрения, вы правы, это неоднозначно. Мое понимание из всего, что я знаю о модели Рестика, такое же, как и у вас, я вполне уверен в этом, но я не могу дать вам определенного подтверждения, которое вы хотите.

В сводке упоминается опция --append-only для REST-сервера. Возможно, это должно оставаться единственным официально рекомендованным методом резервного копирования только с добавлением, но было бы хорошо задокументировать, какие файлы в restic должны быть доступны для записи для нормальной работы, чтобы помочь понять, как настроить другие подходы.

Я считаю, что restic backup будет работать нормально, если data , index , keys и snapshots разрешат создание файла, но не изменение или удаление ( и config также были защищены). Однако я думаю, что locks необходимо разрешить удаление, чтобы репозиторий не был заблокирован навсегда. Кроме того, некоторые реализации только для добавления (например, атрибут для файловых систем ext4 и xfs) не рекурсивны, поэтому 256 двухсимвольных подкаталогов data должны быть предварительно сгенерированы, а затем атрибут должен быть быть настроенным на них.

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

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

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

Re: ваш последний абзац:

• Основным преимуществом асимметричного шифрования, помимо упомянутого вами сценария «расшифровать исторические данные», является возможность хранить резервные копии с нескольких независимых машин в одном репозитории резервных копий без необходимости предоставлять отдельные ключи (что требует хранения где-то резервного ключа каждый раз, когда вы установить новую клиентскую машину). Если вы используете общий ключ, вы получаете неприятный сценарий угрозы, когда client1 может читать данные client2, что не идеально.

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

Я не знаю, пропустил ли я что-то здесь, но я успешно выполняю перезагрузку с этим параметром политики в хранилище S3. Это не мешает злоумышленнику читать данные, но предотвращает их удаление.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

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

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

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

@andrewchambers Я немного завален другими вещами, давайте поговорим о ваших идеях, когда мы действительно реализуем это! Да, мне интересно;)

Итак, эта проблема касается (в конечном итоге) реализации асимметричного резервного копирования, а не конфигурации доступа для внутреннего хранилища. Спасибо! :)

@ fd0 Надеюсь, это объясняет, что я имел в виду https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : на случай, если вы еще не столкнулись с проблемой только для записи (которую вы упомянули на своем сайте), это https://github.com/ncw/rclone/issues/2499.

@andrewchambers спасибо, что записали, мне очень интересно, как выглядит реальная реализация. Сообщение в блоге оставило открытыми некоторые интересные моменты :)

Мне нравится, что среди бесплатных программ резервного копирования softwar появится еще один претендент, ведь давать пользователям больше возможностей всегда здорово!

Таким образом, можно провести интересную параллель с двумя механизмами шифрования репозитория git.

С одной стороны, у вас есть git-crypt : он использует фильтры git

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

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

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

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

Что, если мы позволим указать отдельный каталог ключей, в котором хранятся файлы ключей? Этот каталог может храниться локально на каждой машине, которая должна делать резервные копии, и сама может быть создана для резервного копирования у другого облачного провайдера или даже с помощью QR-кода (~ 500 байт достаточно мало для QR-кодирования) для холодного автономного хранилища. в сейфе, например.

Если зашифрованные ключи никогда не касаются облачного провайдера, вектор атаки полностью исчезает. Ключи должны быть скомпрометированы из физического помещения или, например, извлечены с помощью вредоносного ПО.

Это _можно сделать на Restic уже_, если сохраняется локальная копия репозитория - просто исключите синхронизацию каталога ключей с ненадежным удаленным компьютером при запуске rclone. Этого _ нельзя_ сделать, если нет локальной копии и restic напрямую взаимодействует с ненадежным удаленным компьютером.

Я считаю, что мы должны применить принцип единой ответственности и разбить все на 2 задачи:

1. Храните данные в безопасности от расшифровки.
2. Защищайте данные от несанкционированного удаления.

Это 2 разных аспекта безопасности данных. Технически им не нужно полагаться друг на друга.

Очевидно, что для (1) мы можем «просто добавить поддержку асимметричного шифрования». Для (2) я считаю, что есть много возможных решений (например, как упоминалось выше, настройка S3 только для добавления).