ハッカーのルートアクセスの場合でも、安全なオフサイトバックアップ

悪意のあるハッカーがサーバーへのルートアクセスを取得した状況からデータを保護する、オフサイトバックアップを行うより安全な方法を実装する方法を探しています。SSHとパスワードのセキュリティが適切に設定され、システムが適切に最新の状態に保たれている場合、そのような可能性は他の種類のリスクよりも小さくなりますが、永続的に行える損害の量は非常に大きいため、 'それを制限する解決策を見つけたいです。

オフサイトバックアップの2つの方法を既に試しました。

• バックアップされたデータがコピーされる単純なルート書き込み可能なwebdavマウント（およびfstabで設定）。問題：オフサイトの場所への接続（さらにアクセス）がファイルシステム内のフォルダーとして常に開いたままになっているため、実際にはオフサイトのバックアップではありません。これは、マウントに制限されたアクセス権限（読み取り専用アクセス）がある場合、多くの種類の攻撃に対する十分な保護ですが、ルートアクセスを持つ悪意のある人からは保護しません。

• キー認証を使用したSSHによるボルグバックアップ。問題：悪意のあるユーザーがホストへのルートアクセス権を持っている場合、そのオフサイトサーバーへの接続は、ホストに保存されているキーを使用して実行できます。

解決策として、私はこれらの潜在的な方法を考えていますが、どのように、そして何で：

• バックアップは、宛先への書き込みまたは追加のみが可能で、削除はできません。
• オフサイトバックアップを処理し、最初のホストからのオフサイトバックアップの大量削除をサポートしないバックアップソフトウェアの使用。

私の状況ではあまり面白くないソリューション：

• （技術的な制限により）最初のホストがアクセスできない場所に転送する、オフサイトホスト上の追加のバックアップジョブ。

誰もが私のケースに適切なオフサイトバックアップを実装する方法についてアドバイスできますか？

現在、すべての提案には共通点が1つあります。バックアップ元がバックアップを行い、バックアップ先にアクセスできます。場所をマウントする場合でも、SSHやrsyncなどのツールを使用する場合でも、ソースシステムは何らかの形でバックアップにアクセスできます。したがって、サーバーのセキュリティが侵害されると、バックアップも侵害される可能性があります。

代わりに、バックアップソリューションがサーバーにアクセスできる場合はどうなりますか？バックアップシステムは読み取り専用アクセスでジョブを実行できるため、バックアップシステムのセキュリティが侵害されてもサーバーが侵害されることはありません。また、バックアップシステムをその目的だけに使用し、バックアップの内容を唯一の攻撃ベクトルにすることもできます。それは非常にまれであり、本当に洗練された攻撃を必要とします。

改ざんまたは破損したコンテンツでバックアップが上書きされないようにするには、定義された復元期間内に以前の状態を復元できる増分バックアップを実行します。

不変ストレージ

良い選択肢の1つは、バックアップストレージを不変にするか、少なくとも効果的に不変を与える信頼できるバージョン管理を提供することです。明確にする：不変とは、変更できない、または永続的でないことを意味します。

これを行うことができる複数のサービスがあります。AWS S3、BackBlaze B2、およびAzureとGoogleの両方が同様のサービスを提供していると思われます。おそらくこれを行うためにサーバーをセットアップできますが、どのようにすればよいかわかりません。

不変/バージョン管理されたリポジトリがある場合、バックアップを任意のポイントに復元できるため、ホストが危険にさらされた場合でも、いつでも復元できます。

* AWS S3 **

私はAWS S3に最も精通しています。S3は、バージョン化された暗号化ストレージを提供し、高レベルの耐久性を備えています。

S3はバージョン管理をサポートしているため、効果的な不変性が得られます。ライフサイクルルールを使用して、構成可能な期間が経過した後、古いバージョンのファイルを削除することを選択できます。バージョンをコールドストレージ（氷河コールドアーカイブ）にアーカイブすることもできます。

インテリジェントストレージ階層化クラスを使用して、コストを削減できます。ライフサイクルルールを使用して、すべての静的データを低頻度アクセスクラスに移動することを選択します。これは、耐久性があり、適度な（ホット）パフォーマンスですが、S3標準のスケーラビリティまたはパフォーマンスはありません。

S3はIAM（IDアクセス管理、つまりユーザー管理）ユーザーとポリシーを使用します。これにより、バックアップソフトウェアがストレージで実行できることを非常にきめ細かく制御できます。バックアップユーザーにアップロードの許可を与えることができますが、更新と削除は拒否できます。また、ファイルを削除するために多要素認証を要求したり、ファイルを削除できないようにオブジェクトロックを提供することもできます。

推奨ソフトウェア

Resticを使用して増分バックアップを作成します。Resticは新しいファイルを保存場所にアップロードします。私はそれが新しいファイルを作成すると信じています（しかし間違っている可能性があります）が、一般的な操作ではファイルを更新したり削除したりしません。

ボルグは別のオプションです。以前はBorgを使用していましたが、数百MBの中規模のバックアップでは、毎日すべてのデータがEC2からS3に効果的にアップロードされることがわかりました。私にとってこれはインクリメンタルではないため、使用を中止しました。これに関するドキュメントは見つかりましたが、リンクがありません。

クラウドストレージにアップロードできるソフトウェアは数十個あります。

保護されたストレージ

一部のバックアップソフトウェアを使用すると、IAMユーザーに新しいファイルを書き込む許可を与えることができますが、既存のファイルは更新できません。AWS IAMでこの制限を設定するのは簡単ですが、以下のコメントによると、Resticはそれらのアクセス許可では機能しません。S3からファイルを削除するために必要な多要素認証を使用することもできます。

別のIAMユーザーをPCから実行して、アーカイブの定期的なクリーンスクラブを実行し、設定したポリシーに従ってバージョンを破棄することができます。

Borg Backupは、追加専用のリモートリポジトリをサポートしています。バックアップされるサーバーのセキュリティが侵害されると、新しいバックアップが作成されるだけで、古いバックアップのみが上書きされることはありません。

私の状況ではあまり面白くないソリューション：

オフサイトホスト上の追加のバックアップジョブ。最初のホストがアクセスできない場所にそれらを転送します。

基本的な問題は、バックアップにリモートアクセスできる場合、ハッカーもアクセスできることです。

（技術的な制限のため）

技術的な制限を克服するために作られています。

誰もが私のケースに適切なオフサイトバックアップを実装する方法についてアドバイスできますか？

テープドライブは、70年近くにわたって、ハッカーを含むあらゆる種類の災害に対する安全なオフサイト保護を提供してきました。

AWS S3（またはおそらくGoogleまたはAzureの同等物）のようなストレージサービスを使用して、バケットにルートアカウントにPUTパーミッションを付与できますが、DELETEパーミッションは付与できません。そうすれば、プッシュモデルを使用でき、攻撃者はバックアップを削除できません。

MFAにバケットのDELETEを実行するよう要求するなど、AWSで実行できるセキュリティ対策がありますが、MFAなしでPUTとGETを許可します。そうすれば、MFAデバイスを使用せずにデータをバックアップおよび取得してサービスを復元することができます。これは、MFAデバイスにアクセスするとデータが危険にさらされるような極端な（そしておそらく言及することすらわかりにくい）場合に便利です。

また、興味深い/有用であると思われる範囲外のコメントには、メインデータソースがオフラインの場合にS3および同様のサービスを自動フェールオーバー用に構成する方法がいくつかあります。

キー認証を使用したSSHを介したBorgバックアップ。問題：悪意のあるユーザーがホストへのルートアクセス権を持っている場合、そのオフサイトサーバーへの接続は、ホストに保存されているキーを使用して実行できます。

authorized_keysでオプションコマンドを使用できます。リモートで許可されているコマンドを修正します。

ssh authorized_keysにコマンドを追加する方法

攻撃者がログインルートを回復した場合でも、定義されたコマンド以外は実行できません。

設定できるテクニックは、サーバーとリモートバックアップサーバー間で同期を使用し、リモートバックアップサーバーにスナップショットなどを実行させて、消去サーバー側がオフサイトで消去しないようにすることです。