ハッカーのルートアクセスの場合でも、安全なオフサイトバックアップ
悪意のあるハッカーが私のサーバーへのルートアクセスを取得した状況からもデータを保護するオフサイトバックアップを実行するより安全な方法を実装する方法を探しています。 SSHとパスワードのセキュリティが適切に設定されており、システムが適切に最新の状態に保たれている場合、そのような可能性は他の種類のリスクよりも小さいですが、恒久的に実行できる被害の量は非常に大きいため、それを制限する解決策を見つけたいと思います。
私はすでに2つの方法でオフサイトバックアップを試しました。
バックアップされたデータがコピーされる単純なルート書き込み可能なwebdavマウント（およびfstabで構成）。 問題：オフサイトの場所への接続（さらにはアクセス）は常にファイルシステムのフォルダーとして開いたままなので、実際にはオフサイトのバックアップではありません。マウントのアクセス権限が制限されている場合（ルートのみの読み取りアクセス）、これは多くの種類の攻撃に対する十分な保護ですが、ルートアクセスを持つ悪意のある人からは保護しません。
キー認証付きのSSHによるBorgバックアップ。 問題：悪意のあるユーザーがホストへのrootアクセス権を持っている場合、そのオフサイトサーバーへの接続は、ホストに保存されているキーを使用して実行できます。
解決策として、これらの潜在的な方法について考えていますが、方法と内容はわかりません。
- バックアップは、宛先への書き込みまたは追加のみが可能で、削除はできません。
- オフサイトバックアップを処理し、最初のホストからのオフサイトバックアップの一括削除をサポートしないバックアップソフトウェアの使用。
私の状況ではあまり面白くない解決策：
- （技術的な制限により）最初のホストからアクセスできない場所にそれらを転送するオフサイトホスト上の追加のバックアップジョブ。
私のケースに適切なオフサイトバックアップを実装する方法について誰かがアドバイスできますか？
現在、すべての提案には1つの共通点があります。バックアップソースがバックアップを実行し、バックアップ先にアクセスできます。場所をマウントする場合でも、SSHやrsyncなどのツールを使用する場合でも、ソースシステムは何らかの方法でバックアップにアクセスできます。したがって、サーバーのセキュリティが侵害されると、バックアップも侵害される可能性があります。
代わりに、バックアップソリューションがサーバーにアクセスできる場合はどうなりますか？バックアップシステムは読み取り専用アクセスでそのジョブを実行できるため、バックアップシステムでの妥協はありません。サーバーを危険にさらしている可能性があります。また、バックアップシステムをその目的にのみ使用することもでき、バックアップの内容が唯一の攻撃ベクトルになります。それは非常にまれであり、本当に高度な攻撃が必要です。
改ざんまたは破損したコンテンツでバックアップを上書きしないようにするには、定義された復元期間内に以前の状態を復元できるincrementalバックアップを実行します。
不変のストレージ
1つの適切なオプションは、バックアップストレージを不変にするか、少なくとも効果的な不変性を提供する信頼性の高いバージョン管理を提供することです。明確にするために：不変とは、変更できない、または永続的であることを意味します。
これを行うことができる複数のサービスがあります。 AWS S3、BackBlaze B2、そしてAzureとGoogleの両方が同様のサービスを提供していると思います。サーバーを設定してこれを行うこともできますが、方法はわかりません。
不変/バージョン管理されたリポジトリがある場合、バックアップを任意の時点に復元できるため、ホストが危険にさらされている場合でも、任意の時点で復元できます。
* AWS S3 **
AWS S3に最も精通しています。 S3は、バージョン化された暗号化ストレージを提供し、高いレベルの耐久性を備えています。
S3はバージョニングをサポートしており、効果的な不変性を提供します。構成可能な期間が経過した後、ライフサイクルルールを使用して古いバージョンのファイルを削除することを選択できます。バージョンをコールドストレージにアーカイブすることもできます（氷河コールドアーカイブ）。これには、約$ 1/TB /月かかります。
インテリジェントストレージ階層化クラス を使用してコストを削減できます。ライフサイクルルールを使用して、すべての静的データをまれなアクセスクラスに移動することを選択します。これは、耐久性があり、適度な（ホット）パフォーマンスですが、S3標準のスケーラビリティまたはパフォーマンスはありません。
S3は、IAM（IDアクセス管理、つまりユーザー管理）のユーザーとポリシーを使用します。これにより、バックアップソフトウェアがストレージで実行できる処理を非常に細かく制御できます。バックアップユーザーにアップロードの権限を与えることはできますが、更新と削除は拒否できます。ファイルを削除するために多要素認証を要求したり、ファイルを削除できないように object lock を提供したりすることもできます。
推奨ソフトウェア
Restic を使用して増分バックアップを作成します。 Resticは新しいファイルを保存場所にアップロードします。私はそれが新しいファイルを作成すると信じています（しかし、私は正しくない可能性があります）が、一般的な操作では、ファイルを更新または削除しません。
ボーグは別のオプションです。以前はBorgを使用していましたが、中規模サイズの数百MBのバックアップで、EC2からS3に毎日すべてのデータを効率的にアップロードしたことがわかりました。私にはこれは段階的ではないので、使用をやめました。これに関するドキュメントは見つかりましたが、リンクがありません。
クラウドストレージにアップロードできるソフトウェアは数十種類あります。
保護されたストレージ
一部のバックアップソフトウェアでは、IAMユーザーに新しいファイルの書き込みを許可するが、既存のファイルの更新は許可しないようにすることができます。 AWS IAMでこの制限を設定するのは簡単ですが、以下のコメントのとおり、Resticはこれらのアクセス許可では機能しません。 S3からファイルを削除するために必要な多要素認証を持つこともできます。
設定したポリシーに従ってバージョンを破棄し、アーカイブの定期的なクリーンスクラブを実行する別のIAMユーザーをPCから実行することもできます。
Borg Backupは append-only remote repositories をサポートしています。バックアップされているサーバーが侵害されると、新しいバックアップが作成されるだけで、古いバックアップだけが上書きされることはありません。
私の状況ではあまり面白くない解決策：
最初のホストからアクセスできない場所に転送するオフサイトホスト上の追加のバックアップジョブ。
基本的な問題は、バックアップにリモートでアクセスできる場合はそれからハッカーもできるです。
（技術的な制限のため）
技術的な制限は克服するために作られています。
私の場合のために適切なオフサイトバックアップを実装する方法について誰かがアドバイスできますか？
テープドライブは、ほぼ70年間、ハッカーを含むあらゆる種類の災害に対する安全なオフサイト保護を提供してきました。
キー認証を使用したSSHによるBorgバックアップ。問題：悪意のあるユーザーがホストへのrootアクセス権を持っている場合、そのオフサイトサーバーへの接続は、ホストに保存されているキーを使用して実行できます。
Authorized_keysでオプションコマンドを使用できます。リモートで許可されているコマンドを修正します。
ssh authorized_keysにコマンドを追加する方法
攻撃者がログインルートを回復しても、定義されたコマンド以外は何もできません。
ルートアカウントにバケットへのPUT権限を付与できますが、DELETE権限は付与できないAWS S3（またはおそらくGoogleまたはAzureの同等のもの）のようなストレージサービスを使用できます。そうすれば、プッシュモデルを使用でき、攻撃者はバックアップを削除できなくなります。
バケットでDELETEを実行するようMFAに要求するが、MFAなしでPUTおよびGETを許可するなど、AWSで実行できるその他のセキュリティ対策があります。そうすれば、MFAデバイスを使用せずにデータのバックアップと取得の両方を行ってサービスを復元できます。これは、MFAデバイスにアクセスするとデータが危険にさらされる可能性がある極端な（そしてあまりにもあいまいな）場合に役立ちます。
また、興味深い/有用であると思われる範囲外のコメントもあります。メインデータソースがオフラインの場合に自動フェイルオーバー用にS3および同様のサービスを構成する方法はいくつかあります。
サーバーとリモートバックアップサーバーの間で同期を使用して、リモートバックアップサーバーにスナップショットなどを実行させ、消去サーバー側で消去がオフサイトにならないようにすることができます。