最近のコードスペースの削除オフサイトバックアッププロセス（現在はパスワード入力で手動で実行）について考えさせられました。チュートリアルduplicity を通じてバックアップを自動化する方法を示します。これらは、SSH キーを使用してバックアップ サーバーへの認証プロセスを自動化することを中心に展開されます。
しかし、これは穴だらけのように思えます。バックアップ対象のサーバーが侵害され、悪意のあるユーザーがアクセスできるようになると、バックアップ サーバーに自動的にログインしてバックアップを削除できます。管理者がバックアップ ユーザーのファイル/usr/bin/nologinを使用したと仮定すると/etc/passwd(これがどの程度信頼できるか、またはリモートでの duplicity の動作を阻止できるかどうかはわかりません)、悪意のあるユーザーは、コマンドを使用して duplicity にバックアップを消去させることができますduplicity remove-older-than [time now]。
唯一の安全な解決策は、ssh 経由の rsync を使用してファイルをバックアップ サーバーに送信し、バックアップ サーバーの「マスター ユーザー」に、すべてのユーザー アカウントのローカル反復バックアップを独自のストレージ領域に実行させることです (たとえば、独自のファイルへのアクセス許可のみを持ち、他のすべてのアカウント ファイルを読み取るアクセス許可を持つ)。または、重複によるバックアップの削除を防ぎ、リモート ログインを防ぐ方法はありますか。
答え1
私の知る限り、duplicity ではリモート ディレクトリをローカル ディレクトリにバックアップすることはできません。私は 2 つの手順でこの問題を解決します。バックアップ サーバーで以下を実行します。
SSHキーを使用してSSH経由でrsyncを実行し、リモートディレクトリをローカルディレクトリに同期します。
rsync -avz -e ssh ユーザー@リモート:/リモート/ディレクトリ ローカルディレクトリ
あるディレクトリから別のディレクトリに duplicity を実行します。非対称 GnuPG キーを使用すると、暗号化中にパスフレーズは必要ありません。
duplicity --encrypt-key=YOUR_KEYID local_directory file://backup_directory
またはバックアップを暗号化せずに:
duplicity --no-encryption local_directory file://backup_directory
答え2
バックアップをアップロードした後、 を使用してchattr +iバックアップを変更不可にし、変更または削除できないようにすることができます。このフラグを設定またはクリアできるのは、root だけです。
代わりに、chownアップロード後にファイルを別のユーザーに渡して、バックアップ アカウントがファイルにアクセスできないようにすることもできます。