Restic: 非対称バックアップをサポートする

前の議論からの簡単な要約：

• 電子メールサーバーのバックアップや、そのようなサーバーが危険にさらされた場合のログデータのリモートバックアップに役立ちます。 サーバーから細断処理された機密データがバックアップに存在する可能性があり、そのような履歴データへの攻撃者のアクセスを拒否できると便利な場合があります。 同時に、追加専用/読み取り専用/読み取り/書き込みアクセスを適切に構成できる機能システムを備えた「blobネットワークサーバー」があると便利である可能性があることも議論されました。 非対称暗号化を導入すると、機能を発行するための対称鍵のセットをもう1つ用意する必要がなくなり、機能システムの実装も簡素化される可能性があります。
• 複数のマシンがある設定では、_one_バックアップキーを使用して、多数の対称キーを管理することなく、複数のバックアップデータセットにアクセスできます。 Daniel BernsteinのCurve25519などの暗号システムが使用されている場合、そのようなキーはパスフレーズから派生している可能性があります。つまり、1つのマスターパスフレーズを使用して、（潜在的に多数の）異なるセキュリティドメインによって作成されたバックアップを管理できます。 もちろん、同様のことがn対称鍵と暗号化された鍵ストレージで実現できます。

@heipei参考までに、この号を購読することをお勧めします

さて、最も明白で差し迫った使用例は、本番システム（バックアップクライアント）に侵入し、そこからresticを使用する方法を知っている攻撃者によってバックアップが消去されないことです。

非対称暗号を使用するだけでは、それはほとんど不可能です。 ここでのポイントは、サーバーに侵入した攻撃者が古いバックアップコンテンツ（必ずしもメタデータである必要はない）を利用できないようにする必要があるということです。

データの機密性（ write-only ）は、非対称暗号化を実装することで、これらのシナリオで実現できます。

データの整合性はわずかに異なる獣です：
非対称暗号化（およびワンタイム署名スキーム）を使用して、特定のデータセットが変更されていないことを証明できますが、その完全な削除または置換を防ぐことはできません。 これは、 append-only （および一部のパーツではread-only ）のストレージシステムを必要とする問題です。
sshなどのバックエンドを使用して* nixに実装するのが比較的簡単な随意アクセス制御のおかげです（ chmod 、 chown 、 chattr +i 、 chattr +aなどのコマンドを使用） append-onlyバックアップは、攻撃者が読み取るのを防ぐために暗号化する必要はありませんが（たとえば、 rsyslog機能の一部です）、突然バックアップサーバーが興味深いターゲットになります。機密データをより多くのデバイスに暗号化しても、データの機密性を維持

非対称暗号を実装すると、信頼できないダムのシステムでこの種のバックアップを実行できるようになります。これは、 resticすべてのことの1つです（重複排除の改善やその他すべての優れた機能は別として）。 この詳細が私のポイントを少し明確にすることを願っています。

これは、 https： //github.com/restic/restic/issues/187#issuecomment-101974306で説明されている2つのケースで興味深いものです。 私はこれを監視するためにこのスレッドを購読しています。

データの整合性について：AFAIKでは、IAMクレデンシャルにPutObjectとGetObjectアクセス許可を付与するだけで、Amazon S3でappend-only動作を実現できますが、 DeleteObject差し控えます。許可。

データの機密性に関して、対称暗号を使用することで可能になる攻撃シナリオについて説明したいと思います。
攻撃者がresticを使用してバックアップを実行する時点で、攻撃者が被害者のユーザーアカウントを制御している場合、攻撃者は次のことができます。

• 被害者のresticキーを盗む
• 被害者のIAMクレデンシャル/ sftpログイン/を盗む...

攻撃者は、被害者のシステムから攻撃の痕跡を即座に消去して、検出の可能性を低くすることができます。 彼はリモートストレージシステムのresticキーとクレデンシャルを盗んだので、被害者は（バックアップされた）将来のデータを便利に彼に配信します。攻撃者は、リモートストレージシステムから新しいバックアップをダウンロードして復号化するだけで済みます。時間。

非対称暗号化は、被害者がバックアップをオフラインで復元するためのキーを保存できるようにすることで、これを防ぐのに役立ちます。

データの整合性について：AFAIKでは、IAMクレデンシャルにPutObjectおよびGetObjectのアクセス許可を付与するだけで、DeleteObjectのアクセス許可を保留することで、AmazonS3で追加のみの動作を実現できます。

残念ながら、 PutObjectには、以前にアップロードしたファイルを上書きする権限もあります。 それで、多分それは完全なデータ整合性ではありませんか？

非対称暗号化により、yubikeyなどのOpenPGPキーの使用も可能になります。

今日、私は、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-無人バックアップです。 そこに述べられているように、非対称暗号はこれを行う方法の1つにすぎませんが、問題に対する最初の明白な解決策のようです。

リポジトリがリモートサーバー上にあるシナリオでは、リポジトリ上のローカルコマンドのみが忘れたり削除したりできるはずです。

Resticバックアップは、復元/バックアップ権限のみを持つそのシステムの一意のキーで接続する必要があります。

リポジトリがリモートサーバー上にあるシナリオでは、リポジトリ上のローカルコマンドのみが忘れたり削除したりできるはずです。

これは、リポジトリレベルでファイルを削除/変更するためのアクセスを制限することによって実現する必要があります。 これらの権限を管理することは、resticの範囲外（そして安全ではない）だと思います。 結局のところ、誰かがリポジトリまたはキーさえも削除して、そのアクションがresticクライアントによって許可されているかどうかに関係なく、リポジトリ全体を役に立たなくする可能性があります。

サーバーをハッキングする誰かによってバックアップデータが破壊されるのを防ぐことに関して：rest-serverは最近、これを正確に防ぐPRhttps：//github.com/restic/rest-server/pull/28で「追加専用モード」を取得しました。

私の使用例は、多くのシステムを同じリポジトリにバックアップし、それらすべてのマシン間で重複排除を利用することですが、1つのシステム（およびそのバックアップスクリプト）が危険にさらされているため、攻撃者は他のシステムのバックアップを読み取ることができません。

私が探している機能は、システムが書き込み（バックアップ）と読み取り（復元）できるようにするが、管理（プルーニング、キーの追加、その他の存在の確認など）を実行できない「バックアップ」キーを持つことです。キー、（ユーザー）、または$ backup_keyに関連付けられていないスナップショット）。 （バックアップ時間を比較することでサイドチャネル攻撃が可能かもしれませんが、データの存在を判断できるかどうかは関係ありません。データをランサムウェア化できず、他のユーザーを表示できないことだけです。）自分のパスフレーズをロールフォワードできるようにするためのバックアップ（のみ）キーの所有者。 したがって、 michbsdの要求とは異なり、特権キーを使用して非ローカルマシンから管理することができます。 （SELinuxを何年も使用してきましたが、今ではMACの粒度が好きです）読んでくれてありがとう。 （これに独自の問題がある場合は申し訳ありません。）この機能を使用する場合#ResticKillsRansomware

この機能で#ResticKillsRansomware

一般に、プル指向のバックアップ（プッシュ指向のバックアップではなく）はランサムウェアを解決しますよね？ :)

おそらく、しかしそれはリモートアクセスを提供し、別の攻撃ベクトルを追加します。 バックアップサーバーはデータを保存するためのものであり、本番環境にアクセスすることはできません。 機能ドメインの明確な境界。

Resticはバックアップリポジトリを直接操作するように設計されているため、解決策ではないと思います。

たぶん、ある種の仲介サーバーで何かをすることができます。 プロダクションマシンにtarballをサーバーにアップロードさせてから、別のシステムにtarballをダウンロードして抽出し、コンテンツをローカルにバックアップさせます。 どちらの側も、中間サーバーにのみアクセスできます。 これは、Resticを変更せずに行うのはかなり簡単です。 受信専用のResticモードにバグがあると、バックアップが侵害されたバックアップクライアントに対して脆弱になる可能性があるため、おそらくより安全で堅牢になります。

私が探している機能は、システムが書き込み（バックアップ）と読み取り（復元）できるようにするが、管理（プルーニング、キーの追加、その他の存在の確認など）を実行できない「バックアップ」キーを持つことです。キー、（ユーザー）、または$ backup_keyに関連付けられていないスナップショット）。 （バックアップ時間を比較することでサイドチャネル攻撃が可能かもしれませんが、データの存在を判断できるかどうかは関係ありません。データをランサムウェア化できず、他のユーザーを表示できないことだけです。）自分のパスフレーズをロールフォワードできるようにするためのバックアップ（のみ）キーの所有者。 したがって、michbsdの要求とは異なり、特権キーを使用して非ローカルマシンから管理することができます。 （SELinuxを何年も使用してきましたが、今ではMACの粒度が好きです）読んでくれてありがとう。 （これに独自の問題がある場合は申し訳ありません。）この機能を使用する場合#ResticKillsRansomware

これはあなたが求めているものと正確には一致しないかもしれませんが、 rest-serverを見ることができ

これはあなたが求めているものと正確には一致しないかもしれませんが、rest-serverを見ることができます。 既存のバックアップの削除と変更を防ぐ追加専用モードがあります。

私はそれが存在することにさえ気づいていませんでした。 NS：

ここにダンプしたい2つの構造的なもの（およびわずかに異なる攻撃者モデル）があります。

現時点では、resticは（ほとんど）「ダム」ストレージ（ローカル、s3、b2、gcs、azure、 --append-onlyのRESTサーバーを除くすべて）と対話します。 バックエンドでデータを保存、一覧表示、取得、削除できます。 これはバックアップに必要であるため、バックエンドにアクセスするために必要な資格情報が存在する必要があります。 利点として、resticはほとんどすべてのストレージを使用でき、制限はほとんどありません。 欠点として、攻撃者がサーバーにアクセスすると、バックエンドにアクセスするためのクレデンシャルとresticパスワードを簡単に抽出して、リポジトリから履歴データを復号化し、データを変更し、リポジトリ全体を削除することができます。

非対称暗号化を追加する場合、このような状況での攻撃者の唯一の違いは、リポジトリから履歴データを復号化できないことです。 他のすべて、特にすべてのデータの削除は引き続き可能です。 したがって、「非対称暗号を追加するだけ」がすべてではありません。

もう1つのアイデアは、「ダム」ストレージに直接アクセスするのではなく、カスタムサーバーの実装を介して間接的にアクセスすることです。 このアイデアを試してみて、 --append-onlyオプションを追加しました。これは、ローカルハードディスクの「ダム」ストレージにアクセスするための「アダプター」と見なすことができます。 必ずしもRESTサーバーを使用する必要はありませんが、そのアイデアを改善する方法についていくつかのアイデアがあります。

たとえば、stdin / stdoutなどのファイル記述子のペアを介して話されるバックエンドのプロトコルを定義したいと思います。 次に、sftpバックエンドの場合と同じように、リモートマシンでSSHを介して実行されるプログラムにこれを実装できます。 サーバーの実装では、データの保存場所（local、s3、b2など）と適用する制限（「古いデータの読み取りのみを追加するか、新しいデータを追加する」など）を決定できます。ファイルをロックする以外に何も削除することはできません。サーバーたとえば、特定のユーザーアカウントまたはSSHキーを使用したSSH経由のログイン時にForceCommandを介して開始できます。

「ダム以外の」ストレージだけでは、攻撃者がリポジトリからデータを読み取るのを防ぐことはできませんが（少なくともリポジトリの形式を変更せずに）、リポジトリ内のすべてのデータを削除することはできません。

したがって、結論として、バックアップにresticを使用するサーバーを攻撃者が乗っ取るのを防ぐには、両方（非ダムストレージと非対称暗号）を実装する必要があると思います。 それは長期的な目標です:)

このテキストをこの号の最初のコメントにコピーして、見つけやすくします。

ええ、これをさらに振り返って、私はasym暗号が乗っ取りから防御するのにそれほど有用ではないことに同意します-それは無人バックアップ（＃533）のためにより有用です。

ネイティブの通信プロトコルがあると便利かもしれませんが、現在のRESTサーバーでそれから何が得られるかわかりません-それを拡張できますか？ attic / borgはそのように進みました。クライアントからサーバーへの「独自の」（borg固有の）プロトコルがあり、クライアントにいくつかの制限を実装することが可能です。 はい、これはForceCommandと「borgserve」制限フラグに依存しています...これと注意すべき欠点について、borgドキュメントにいくつかの

そしてもちろん、侵害されたクライアントからバックアップを保護する最も自然な方法は、クライアントがバックアップ自体を実行することを許可せず、代わりにサーバーにバックアップからファイルをプルさせることです。夜、あなたのコンピュータから本質を吸います」、そのキャッチーなフレーズを覚えている人のために）。 ボルグのいずれか、でこれを行うには十分に文書またはエレガントな方法があるようには思えないのFAQにポイントhttps://github.com/borgbackup/borg/issues/900トピックに関する議論として。 ここでは、これはまだここで言及されていない＃299で追跡されます。

非常に長い話ですが、非対称暗号サポートの焦点を単純に保ちます。オフサイトのキーストレージと自動バックアップを簡単に作成できるようにします。 侵害されたクライアントを保護する方法は他にもありますが、プルサポートが最も興味深い方法だと思います。 実際、私の最適なバックアップソリューションでは、すべてのクライアントがバックアップを中央サーバーにプッシュし、次にオフサイトサーバーがメインバックアップサーバーからプルします。 こちらです：

1. バックアップサーバーは、すべてのマシンでルートアクセスを必要としません
2. それでも、バックアップを台無しにすることができたとしても、マシンの侵害は依然として回復可能です。

私は実際、この問題が「クライアントの乗っ取りから保護したい」に変わったのは奇妙だと思います。おそらく、ここでの問題と解決策を混同しているのかもしれません。 :)

やあ、

この問題は、非対称の暗号バックアップだけでなく、さまざまな攻撃ベクトルに関するもののようです。
コードを読んでいないので、本当に素朴な質問がありますが、私のユースケースは主に、秘密鍵を開示せずに（バックアップ所有者のオフライン秘密鍵の公開鍵を使用して）データをバックアップできることです。 そのユースケースでは、実装は簡単ですか？

この件についての私の理解は、現在、すべてのBLOBが同じキーで暗号化されており、うまく機能しているということです。
OpenPGPの動作方法でasymcryptoを使用する場合、作成された各スナップショットは、公開鍵で暗号化された対称鍵を生成し、それをリポジトリに追加します。 しかし、問題は、重複排除するものとバックアップするものを見つけることができるようにするには、最初に情報を読み取ることができる必要があるため、秘密鍵も必要になることだと思います。 そうですか？
その場合、ゼロ知識証明がそれらの線に沿って役立つ可能性がありますか？

@dolanorは、この問題に新しいユースケースや質問を追加しないでください。質問にはフォーラムを使用して

最初の投稿で要約を更新しました。 その間にrcloneバックエンドが追加されました。これは、上記のように「アダプター」として使用でき、SSHなどを介してアクセスできます。

欠点は、攻撃者がサーバーにアクセスできるようになると、バックエンドにアクセスするためのクレデンシャルと制限付きパスワードを簡単に抽出できることです。

これがタイプミスだといいのですが、ここに暗号化されたキーファイルの資料がありますね。 うまくいけば、サーバーにアクセスする攻撃者は、プレーンテキストのパスワードにアクセスできません。 彼らができる最悪の事態は、リポジトリへのマスター暗号化および認証キーを復号化するために使用される「ユーザーパスワード」を総当たり攻撃または推測しようとすることです。

それが正しければ、要約をもう一度変更して明確にすることを強くお勧めします。そのように述べた場合、それは確かに見栄えが悪いからです。 :)

うまくいけば、サーバーにアクセスする攻撃者は、プレーンテキストのパスワードにアクセスできません。 彼らができる最悪の事態は、リポジトリへのマスター暗号化および認証キーを復号化するために使用される「ユーザーパスワード」を総当たり攻撃または推測しようとすることです。

正確なシナリオによると思います。手動でパスワードを入力している場合は、そうです。 一方、スケジュールされた自動バックアップを実行している場合は、「ユーザーパスワード」をサーバーのどこかに保存する必要があります。

そしてもちろん、攻撃者はResticバイナリを、入力されたパスワードを漏らすものと交換し、あなたが入力するのを待つ可能性があります。 侵害されたシステムを信頼することはできません。

「ユーザーパスワード」はサーバーのどこかに保存する必要があります。

「サーバー」とは、「データを保存するために実行しているマシン」または「バックアップからデータを受信/保存するマシン」を意味しますか？

それはかなり曖昧であり、私の懸念の原因：バックアップクライアント（resticを実行しているバックアップしているマシン）がクリアテキストでパスワードを持っていることを気にしません：データセット全体がとにかくそこにあるので、それが危険にさらされた場合、データはとにかく妥協した。 しかし、バックアップサーバーがクリアテキストにアクセスできないことを願ってい

「サーバー」とは、「データを保存するために実行しているマシン」または「バックアップからデータを受信/保存するマシン」を意味しますか？

データを保存する上で実行しているマシン。

私はあなたの主張を理解しています、あなたは正しいです、それは曖昧です。 Resticのモデルについて私が知っているすべてのことからの私の理解はあなたのそれと同じです、私はそれについてかなり確信しています、しかし私はあなたが望む明確な確認をあなたに与えることができません。

概要には、RESTサーバーの--append-onlyオプションが記載されています。 おそらくそれは、追加のみのバックアップの唯一の公式に推奨される方法として残るはずですが、他のアプローチを設定する方法を理解するのに役立つように、通常の操作のために書き込み可能である必要があるファイルを文書化することは良いかもしれません。

data 、 index 、 keys 、およびsnapshotsファイルの作成restic backupは問題なく機能すると思います（また、 configも保護されました）。 ただし、リポジトリが永続的にロックされないように、 locksは削除を許可する必要があると思います。 また、一部の追加のみの実装（ext4およびxfsファイルシステムの属性など）は再帰的ではないため、 dataの256個の2文字のサブディレクトリを最初に事前生成してから、属性を事前に生成する必要があります。それらに設定されます。

S3のような一部のバックエンドは、追加のみをサポートしていませんが、同じ効果を達成できるオブジェクトのバージョン管理をサポートしています。 ただし、これにはアクセス制御モデルを注意深くチェックする必要があります。 たとえば、B2にはオブジェクトのバージョン管理を許可するライフサイクルルールがありますが、B2へのバックアップに必要なAPIキーには、ライフサイクルルールを変更する機能があります（B2にはまだ多くのアクセス許可システムがありません）。

余談ですが、何かが足りないかもしれませんが、非対称暗号化が、クライアントを侵害した攻撃者から履歴データを保護しているだけの場合は、優先度が低いように思われます。 あると便利ですが、ほとんどの場合、現在のデータは以前のバージョンよりも価値があります（ただし、価値のあるものが誤ってバックアップ、削除されたが、パージされていない場合があります）。

@willsALMANJ良い観察。 S3の場合、特定のスナップショットを復元するために必要なBLOBの一貫したビューをフェッチできるように、異論のバージョンを記録できるかどうか疑問に思います（ただし、内容に基づいて検証できるため、それほど重要ではありません）。

再：あなたの最後の段落：

• 非対称暗号化の主な利点は、前述の「履歴を復号化する」シナリオに加えて、個々のキーをプロビジョニングすることなく、複数の独立したマシンからのバックアップを同じバックアップリポジトリに保存できることです（バックアップキーを毎回どこかに保存する必要があります）。新しいクライアントマシンをインストールします）。 共有キーを使用すると、client1がclient2のデータを読み取ることができるという厄介な脅威のシナリオが発生しますが、これは理想的ではありません。

@ fd0派生した共有秘密を使用したHMACアドレス指定を使用した非対称暗号化の適切なスキームがあると思います。 また、データをリークせずにサーバー側のガベージコレクションについていくつかのアイデアがあります。興味があるかどうかはわかりませんが、興味がある場合は、それについて話したいと思います。

ここで何かを見逃しているかどうかはわかりませんが、S3ストレージでこのポリシー設定を使用してresticを正常に実行しています。 攻撃者がデータを読み取ることを防ぐことはできませんが、攻撃者がvomを削除することはできません。

{
  "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/*"
    }
  ]
}

次に、prune / forgetコマンドは、書き込み権限を持つ信頼できるデバイスから実行されます。 また、すべてのresticリポジトリに2つのキーを作成します。 1つはサーバー用、もう1つは信頼できるデバイス用で、信頼できるデバイスが攻撃者をロックアウトできるようにします（ただし、攻撃者はキーを削除できないため、ロックアウトできません/ *）。

編集：申し訳ありませんが、これはすでに議論されていることを見逃しました。 このスレッドを乗っ取ろうとは思わなかった。
PutObjectは実際にはオブジェクトを上書きできるため、これはバックアップを保護するためのソリューションではありません。

@freswa私はS3の専門家ではないので、これが正しいかわかりませんが、この説明で上記で指摘したのは、 PutObject権限を使用して、データを上書きできるということです。これも同様に悪いことです。それを削除するように。 上記の私の投稿では、オブジェクトのバージョン管理を使用してこの問題を回避できることを指摘しました（バックアップシステムにバージョンを削除するためのアクセス権を与えないでください）。

@andrewchambers私は他のものに少し圧倒されています、実際にこれを実装するようになったら、あなたのアイデアについて話しましょう！ はい、興味があります;）

したがって、この問題は、バックエンドストレージの構成にアクセスするのではなく、（最終的には）非対称バックアップを実装することに関するものです。 ありがとう！ :)

@ fd0うまくいけば、これは私が意味したことを説明していますhttps://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers :(サイトで言及した）書き込み専用の問題にまだ遭遇していない場合に備えて、 https：//github.com/ncw/rclone/issues/2499です。

@andrewchambersそれを

私は、無料のソフトウェアバックアッププログラムの分野で別の候補者がいることを気に入っています。ユーザーにより多くのオプションを提供することは常に素晴らしいことです。

したがって、2つのgitリポジトリ暗号化メカニズムを使用して興味深い並列処理を行うことができます。

一方にはgit-cryptがあります。これはgitsmudge / cleanフィルターを使用して、blobストレージとチェックアウトされたコピーの間のファイルを（それぞれ）暗号化/復号化します。 これはうまく機能し、かなり最適ですが、1つの明白な穴があります。gitcommit自体は暗号化されず、blobのコンテンツのみが暗号化されます。つまり、ファイル名、commitlog、作成者、日付、その他のメタデータはすべて平文で保存されます。 これは多くのユースケースでは不要であり、（たとえば）一部のビット（すべてではない）を暗号化するパブリックリポジトリがある場合にのみ効果的です。

反対側にはgit-remote-gcryptがあります。これはgitリモートヘルパープロトコルをすべてのものを暗号化します。 ただし、特別なリモートの動作方法により、実行ごとにリポジトリ全体が再暗号化されるため、これは非常に非効率的です。

さて、これらはgit固有の実装上の課題ですが、ここで発生する可能性のある問題にうまく対応していると思います。 たぶん私はここで完全に私の深さから外れていて、この平行は無関係です、しかし私はそれがここで興味があるかもしれないと思いました...

余談ですが、現在（おそらく）かなり簡単に実装できる中間点があります。それは、キーをリポジトリの外部に保存できるようにすることです。

対処されている攻撃ベクトルの1つは、攻撃者がキーパスワードを入手し、（キーはリポジトリに保存されているため）簡単にキーを復号化できることです。

キーファイルが保存されている別のキーディレクトリの指定を許可するとどうなりますか？ このディレクトリは、バックアップを実行する必要のある各マシンにローカルに保存でき、それ自体を別のクラウドプロバイダーにバックアップしたり、コールドオフラインストレージ用のQRコード（約500バイトはQRエンコードするには十分小さい）でさえバックアップしたりできます。たとえば、貸金庫に入れます。

暗号化されたキーがクラウドプロバイダーに接触しない場合、攻撃ベクトルは完全になくなります。 たとえば、鍵は物理的な施設から侵害されたり、マルウェアで侵入されたりする必要があります。

これは、リポジトリのローカルコピーが保持されている場合、Resticですでに実行できます。rcloneの実行時に、キーディレクトリが信頼できないリモートに同期されないようにするだけです。 ローカルコピーがなく、resticが信頼できないリモートと直接対話する場合、これは実行できません。

単一責任の原則を適用し、物事を2つのタスクに分割する必要があると思います。

1. データを復号化から保護します。
2. 不正な削除アクションからデータを安全に保ちます。

これらは、データの安全性の2つの異なる側面です。 技術的には、お互いに依存する必要はありません。

（1）については、明らかに「非対称暗号化サポートを追加するだけ」です。 （2）については、考えられる解決策はたくさんあると思います（たとえば、前述のように、追加のみのS3セットアップ）。