8

PostgreSQLのトップシークレットデータのデータベースを備えたサーバーがあり、パスワードを推測することは事実上不可能です（手作業で生成された、あらゆる種類の奇妙な文字の128文字の文字列）。サーバーのパスワードも事実上推測できません。

パスワードの推測は別として、このデータベースからデータを取得するのはどれほど簡単ですか？

仮定：

  1. サーバーにはDBのみが存在します。PHPスクリプトなどにパスワードはありません
  2. サーバーを盗んだのはサーバー/DB/ハードドライブの回復の専門家です
  3. 私は保護のためにハードドライブの暗号化や標準外のものを使用していません
  4. Ubuntu Hardy（最新の安定バージョン）を使用しています

私は、誰かが私のサーバーのハードドライブに物理的にアクセスすることに伴うリスクを理解しようとしています。

4

6 に答える 6

6

「標準的な考え方は、誰かがサーバーに座ったとき、それは危険にさらされ、話の終わりです。彼らがハードドライブを手に取り、それを開いて分析するためにラボに持っていくと、事態はさらに悪化します。」

同上。

攻撃者が永続的な物理的アクセスを取得すると（つまり、ブリーフケースにハードドライブを入れて建物から出て行くと）、ジグが上がります。やがてデータが危険にさらされると想定します。そこから、シナリオは、攻撃者を遅くする能力に対する遅延戦術のコストです。

攻撃者がインサイダーである場合、または一時的なアクセスしか持っていない場合は、少し異なります。そのような場合、あなたは彼を十分に遅くするか、攻撃が実行不可能になるように説明責任を強制することができるかもしれません。

ハードドライブの暗号化は遅延戦術です-アルゴリズムの強度、キーの強度、およびキーへのアクセスをロックするパスワードの強度（または個別に保存されたキーでハードウェアを挿入する機能）に一致する保護を提供します。暗号化を使用しても、それは遅延戦術であると想定されています。遅かれ早かれ、攻撃者はキースペースを通り抜け、どのキーがシステムを復号化するかを理解します。

改ざん防止は別のオプションです-特定の条件下でハードドライブを電子的に消去する方法を見つける（ケースから物理的に取り外すなど）。

物理的なアクセスが許可されると、攻撃者はブルートフォースに頼ることなく、パスワードを回避できます。最初に頭に浮かぶのは、ほとんどのシステムに組み込まれている「パスワードの修正」手法を使用して、パスワードをロックアウトして紛失したシステム管理者を支援することです。

すべての保護には代償が伴います。特殊なハードウェアが必要なため、改ざん防止には費用がかかります。暗号化は安価ですが、起動時間に影響します。また、暗号化がアプリケーションでどのように機能するかについて、いくつかの厄介な驚きを見てきました。暗号化を使用しようとするまで、実際にはわかりません。

于 2010-05-12T19:05:36.573 に答える
4

標準的な考え方は、誰かがサーバーに座ったとき、それは危険にさらされ、話の終わりです。彼らがハードドライブを手に取り、それを開いて分析するためにラボに持って行った場合にのみ、事態は悪化します。

まず、ドライブ全体の暗号化と、データベースのフィールドごとの暗号化から始めます。サーバーにインストールされているハードドライブハードウェアに生体認証ベースでアクセスする方法があるかどうかを確認するために、周りを見回すことができます。また、物理的なセキュリティ請負業者を掘り下げて、構成に関する推奨事項を入手する必要があります。また、警備員を雇います。

つまり、これが合理的に発生する可能性のあるシナリオである場合...

編集：

取得したいPostgresDBファイルがあり、リソースがある場合（つまり、安価なDellに4Kを費やしている場合）、Beowulf構成を使用して、並列ブルートフォースクラッキングを実行します。私がより多くのお金を手に入れ始め、たとえば、パスワードをブルートフォース攻撃を開始するためにプラグインされたこれらの甘いNVidiaスーパーコンピューターオンデスクトップマシンのいくつかを構成できると、事態はさらに悪化します。

泥棒が侵入に真剣に取り組んでいて、0日目からセキュリティがまだ計画されていない場合、DBファイルはイワシの缶のように開かれます。

于 2010-05-12T17:02:18.727 に答える
2

ハードドライブ/ファイルシステムを暗号化していない場合、Postgresはネイティブ暗号化を提供していないため、ほとんど運が悪いです。そして、ハードドライブを暗号化することは、盗まれたサーバーを保護する唯一の実際の方法です。

基本的には、ハードドライブまたはファイルシステムを暗号化する必要があります。また、Postgresが起動する前に、マシンが起動するたびに、ドライブを手動でマウントするときにパスワードを入力する必要があります。

于 2010-05-12T17:05:28.563 に答える
1

これはPostgreSQLやその他のデータベースアドレスの問題ではないと思います。データベース自体がパスワードで保護されている場合でも、すべてのデータはプレーンテキストであり、それが本当に重要です。攻撃者が生のデータベースファイルをキャットし、それを文字列にパイプすることを妨げるものは何もありません。このタイプの攻撃に対する最善の解決策は、暗号化されたファイルシステムを使用することです。これには、パーティションをマウントするためのパスワードを入力する必要があります。これにより、オーバーヘッドも増加します。

于 2010-05-12T17:02:23.140 に答える
1

投稿された特定の質問（および私が答えを探しに来た質問）については、Postgresqlはデフォルトでテーブルデータを暗号化せずに保存します。... / pgsql / 9.2 / data / base / *内のファイルを見て回ると、これらは1.1ギガバイトのチャンクでテーブルを格納していると思います。grepを使用すると、これらのファイルでASCII文字列を正常に見つけることができます。ファイルを調べると、データは列に格納されているように見えます。

この情報から、私は実験してコードを記述し、テーブルをリバースエンジニアリングして、パスワードを持っていないサーバー上にコピーを作成できると信じています。

したがって、物理メディアが盗まれるリスクから保護する必要がある場合、強力なデータベースパスワードだけに依存することは注意義務を果たしません。

PostgreSQLオンラインドキュメントは、さまざまなレベルでデータを暗号化するためのいくつかのオプションを提供します。この問題については、他の回答者が示唆しているように、特定の列を暗号化するか、何らかの方法で基盤となるメディアを暗号化するモジュールに限定されているようです。

于 2015-05-20T08:37:13.333 に答える
1

良いスタートは、フルディスク暗号化を有効にすることです。アプリケーション層で暗号化することもできます。（たとえば、データベースに送信する前にデータを暗号化し、データベースサーバーからアクセスできないキーを保存します）

于 2015-10-07T00:48:30.710 に答える