3

私はスタック オーバーフローについて知ったばかりで、プロジェクトの友人と一緒に持っている制約のアイデアがあるかどうかを確認しているだけですが、これは私が見つけようとしてきた理論的な質問です。しばらくの間の答え。

私は暗号化にはあまり詳しくありませんが、十分に明確でない場合は、質問を明確にするために編集/コメントを試みます。

簡単に言うと、環境は次のようなものです。

  • キーの暗号化/復号化へのアクセスとしてのフロントエンドと、ストレージとクエリにのみ使用されるバックエンドを持つアプリケーション。

  • たとえば、いくつかのフィールドにアクセスできないデータベースがある場合、通常どおり「アドレス」が text/varchar であるとします。

  • 情報を復号化するためのキーにアクセスすることはできず、すべての情報は既に暗号化された状態でデータベースに到着します。

主な問題は、このようなものです。データベースに対して一貫してクエリを作成する方法、「'%F§YU/´~#JKSks23%' のような場所のアドレス」のようなことを行うことは不可能です。（これに対する答えを感じている人がいる場合は、遠慮なく撃ってください）。

しかし、それは大丈夫ですwhere address='±!NNsj3~^º-:'か？それとも、データベースを完全に使い果たしてしまうのでしょうか?

適用される可能性のあるもう 1 つの制約は、フロント エンドに利用できる処理能力があまりないため、既に情報の暗号化/復号化が限界に達し始めていることです。（これは、「テーブルの結合をフロントエンドにエクスポートしてそこでクエリを実行する」などの返信を避けるためだけに言っています。）

誰かがそれについて考え続ける方向に私を向けることができますか?

午前 4 時の非常に迅速な返信に感謝します。初めての使用で、このコミュニティに感銘を受けました。（または、タイムゾーンが違うだけなのかもしれません）

いくつかの情報を提供するだけです：

主な問題は、部分一致に関するものです。ほとんどのデータベースで必須要件として、部分一致を許可する必要があります。主な制約は、実際にはデータベースの所有者がデータベース内の情報を参照することを許可されないことです。最後の 10 分間で、考えられるデータベースの問題にまで拡張する解決策を思いついたので、ここに追加します。

部分一致を許可する解決策:

  • パスワード + ユーザーのいくつかの公開フィールドは、実際には暗号化の鍵です。認証のアイデアは、静的な値を暗号化し、データベース内で比較することです。
  • 情報が解析された方法で格納されるテーブルの新しいセットを作成します。つまり、「4th Street」は 2 つの暗号化された行になります (「4th」用に 1 行、「Street」用に 1 行)。これにより、別のテーブルで検索が既に実行されている可能性があるため、部分的な一致が可能になります。

新しい質問:

  • これはおそらくデータベースサーバーを再び食い尽くすのでしょうか、それとも部分一致の問題に対する実行可能な解決策であると誰かが考えていますか?

Post Scriptum: 私は Cade Roux からの回答を受け入れませんでした。これは、さらなる議論と、特に新しい質問に対する可能な回答を可能にするためです。

4

5 に答える 5

5

あなたが説明した方法でそれを行うことができます-たとえば、ハッシュを効果的にクエリしますが、その時点でセキュリティ要件がシステムを使用可能にするための他の要件と干渉しているため、その要件を持つシステムは多くありません-つまり、部分一致がない暗号化によってそれが決まります。圧縮と同じ問題です。数年前、非常に小さな環境で、データをデータ形式に変換する前にデータを圧縮する必要がありました。もちろん、それらのフィールドは簡単に検索できませんでした。

より典型的なアプリケーションでは、最終的に、キーはチェーン内の誰か (おそらく Web サーバー) が利用できるようになります。

エンド ユーザー トラフィックでは、SSL がそのパイプを保護します。一部のネットワーク スイッチは Web サーバーとデータベースの間でそれを保護することができ、暗号化されたデータをデータベースに保存することは問題ありませんが、そのような暗号化されたデータに対してクエリを実行するつもりはありません。

そして、データが表示されると、それはマシン上にあるため、その時点で汎用コンピューティング デバイスを回避でき、アプリケーションの外側に境界防御が実際に作用します。

于 2008-10-08T02:30:02.517 に答える
3

データベーステーブルを保持しているディスクを暗号化し、データベース接続を暗号化して、データベースを正常に動作させてみませんか？

[私はこのレベルのパラノイアを必要とする文脈/制約を本当に理解していません]

編集：「法の制約」え？私はあなたが違法なことに関与していないことを願っています、私は不注意なアクセサリーになりたくありません... ;-)

--ahem--法的な制約--がこのソリューションを強制する場合、実行する必要があるのはそれだけです-LIKEの一致はなく、クライアントマシンがそれを処理できない場合は応答が遅くなります。

于 2008-10-08T04:25:53.157 に答える
1

数か月前、同じ問題に遭遇しました。データベース全体 (インデックスを除く) が暗号化されており、部分一致の問題が発生しました。

解決策を探してインターネットを検索しましたが、これについてはあまりやるべきことがないように思われますが、「回避策」があります。

私が最終的に採用した解決策は次のとおりです。

  1. クエリが実行され、復号化されたフィールドのデータと、テーブルの主キーである別のフィールドのデータを使用して一時テーブルを作成します (明らかに、このフィールドはプレーンテキストのように復号化する必要はありません)。

  2. その一時テーブルに対して部分一致を実行し、識別子を取得します。

  3. これらの識別子について実際のテーブルをクエリし、結果を返します。

  4. 一時テーブルを削除します。

これが重要なオーバーヘッドを想定していることは承知していますが、データベースが完全に暗号化されていることが必須である場合に、このタスクを実行する別の方法を見つけられませんでした。

それぞれの特定のケースに応じて、結果のデータを失うことなく、一時テーブルに挿入される行数をフィルタリングできる場合があります (クエリを実行しているユーザーに属する行のみを考慮するなど...)。 .

于 2008-10-14T14:40:09.657 に答える
0

md5 ハッシュを使用します。基本的に、文字列を取得して、再現できないハッシュに変換します。その後、それを使用して後で検証できます。例えば：

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "INSERT INTO addresses (address) VALUES ('" . md5($salt . $address) . "')";
mysql_query($sql);

次に、今後アドレスを検証するには:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "SELECT address FROM addresses WHERE address = '" . md5($salt . $address) . "'";
$res = mysql_query($sql);
if (mysql_fetch_row($res))
    // exists
else
    // does not

現在はデータベース側で暗号化されているため、ソース コードを調べたとしても、誰も見つけることができません。ただし、ソルトを見つけることは、彼らがそれを解読するのに役立ちます.

http://en.wikipedia.org/wiki/MD5

于 2008-10-08T02:31:40.623 に答える
0

後でクエリを実行する機密データを保存する必要がある場合は、プレーン テキストで保存し、そのテーブルへのアクセスをできる限り制限することをお勧めします。

それができず、フロントエンドでオーバーヘッドが発生したくない場合は、サーバーで実行され、暗号化されたデータを処理するコンポーネントをバックエンドで作成できます。

暗号化されたデータに対してクエリを実行しますか? 優れた暗号化アルゴリズムを使用している場合、それを行う方法を想像できません。

于 2008-10-08T02:36:39.663 に答える