6

私は、ユーザーの購入リストを保持することを主な目的とするアプリを書いています。

開発者としての私（またはデータベースへの完全なアクセス権を持つ人）でさえ、特定の人が費やした金額や購入した金額を把握できないようにしたいと思います。

私は最初に次のスキームを思いついた：

    -------------- + ------------ + -----------
    user_hash | アイテム| 価格
    -------------- + ------------ + -----------
    a45cd654fe810 | ストリップクラブ| 400.00
    a45cd654fe810 | フェラーリ| 1510800.00
    54da2241211c2 | ビール| 5.00
    54da2241211c2 | iPhone | 399.00
  • ユーザーはユーザー名とパスワードを使用してログインします。
  • パスワードから計算しますuser_hash（おそらく塩漬けなどで）。
  • ハッシュを使用して、通常のSQLクエリでユーザーデータにアクセスします。

十分な数のユーザーがいることを考えると、特定のユーザーが自分の名前を知っているだけでどれだけのお金を費やしたかを知ることはほとんど不可能です。

これは賢明なことですか、それとも私は完全に愚かですか？

4

7 に答える 7

4

残念ながら、あなたのアプリケーションが人をそのデータにリンクできるのであれば、開発者/管理者なら誰でもできるでしょう。

あなたができる唯一のことは、リンクを難しくして開発者/管理者を遅くすることですが、ユーザーをデータにリンクするのを難しくすると、サーバーも難しくなります.

@no idea に基づくアイデア:

アプリケーションへの従来のユーザー/パスワード ログイン (ハッシュされたパスワードなど) と、データを安全に保つために使用される特別な「パス」を使用できます。この「パス」はデータベースに保存されません。

クライアントがアプリケーションにログインするときに、ユーザー/パスワード/パスを提供する必要があります。ユーザー/パスワードはデータベースでチェックされ、パスはデータのロード/書き込みに使用されます。

データを書き込む必要がある場合は、「ユーザー名/パス」のペアのハッシュを作成し、クライアントをデータにリンクするキーとして保存します。

データをロードする必要がある場合は、「ユーザー名/パス」のペアのハッシュを作成し、このハッシュに一致するすべてのデータをロードします。

この方法では、データとユーザーの間にリンクを作成することは不可能です。

一方、(@no へのコメントで述べたように) 衝突に注意してください。さらに、ユーザーが悪い「パス」を書いた場合、それをチェックすることはできません。

更新: 最後の部分では、別のアイデアがありました。「パス/パスワード」のペアのハッシュをデータベースに保存できます。この方法で、「パス」が問題ないかどうかを確認できます。

于 2010-09-17T17:26:35.463 に答える
2
  1. 次を使用して users テーブルを作成します。
    1. user_id: ID 列 (自動生成された ID)
    2. ユーザー名
    3. パスワード: ハッシュ化されていることを確認してください!
  2. 例のように製品テーブルを作成します。
    1. ユーザー_ハッシュ
    2. アイテム
    3. 価格

user_hash は、変更されることのない user_id に基づいています。ユーザー名とパスワードは必要に応じて自由に変更できます。ユーザーがログインすると、ユーザー名とパスワードを比較して user_id を取得します。セッション中に user_hash をクライアントに送り返すか、ハッシュの暗号化/間接バージョン (サーバーが user_hash をセッションに格納するセッション ID の可能性があります) を送信できます。

ここで、user_id を user_hash にハッシュして保護する方法が必要です。

  1. @noが提案したようにクライアント側で行う場合、クライアントにはuser_idが必要です。大きなセキュリティ ホール (特に Web アプリの場合)、ハッシュは簡単に改ざんされる可能性があり、アルゴリズムは一般に公開されています。
  2. データベースの関数として持つことができます。データベースにはレコードをリンクするためのすべての要素があるため、悪い考えです。
  3. Web サイトまたはクライアント/サーバー アプリの場合、サーバー側のコードに含めることができます。はるかに優れていますが、1 人の開発者がハッシュ アルゴリズムとデータにアクセスできます。
  4. 別の開発者にハッシュ アルゴリズム (アクセス権がない) を作成してもらい、TCP/Web サービスとして別のサーバー (アクセス権がない) に固執します。次に、サーバー側のコードはユーザー ID を渡し、ハッシュを取得します。アルゴリズムはありませんが、すべてのユーザー ID を送信してすべてのハッシュを取得できます。#3 の利点はあまりありませんが、リスクを最小限に抑えるためにサービスにログ記録などを含めることができます。
  5. 単純なクライアント データベース アプリの場合、選択肢は #1 と 2 しかありません。データベース サーバーとは別の、サーバー側の別の [ビジネス] レイヤーを追加することを強くお勧めします。

編集： これは以前のポイントの一部と重複しています。3 つのサーバーを用意します。

  • 認証サーバー: 従業員 A がアクセスできます。ユーザー テーブルを維持します。ユーザーとパスワードの組み合わせを取る Web サービス (暗号化された通信を使用) があります。パスワードをハッシュし、テーブルで user_id を検索し、user_hash を生成します。この方法では、単純にすべての user_id を送信してハッシュを取得することはできません。どこにも保存されておらず、認証プロセス中にのみ使用できるパスワードが必要です。
  • メイン データベース サーバー: 従業員 B がアクセスできます。user_hash のみを格納します。ユーザーIDもパスワードもありません。user_hash を使用してデータをリンクできますが、実際のユーザー情報は別の場所にあります。
  • Web サイト サーバー: 従業員 B がアクセスできます。ログイン情報を取得し、認証サーバーに渡し、ハッシュを取得して、ログイン情報を破棄します。データベースへの書き込み/クエリのためにハッシュをセッションに保持します。

したがって、従業員 A には user_id、ユーザー名、パスワード、およびアルゴリズムがあります。従業員 B には user_hash と data があります。従業員 B が生のユーザー/パスワードを保存するように Web サイトを変更しない限り、実際のユーザーにリンクする方法はありません。

SQL プロファイリングを使用して、従業員 A は user_id、ユーザー名、およびパスワードのハッシュを取得します (user_hash は後でコードで生成されるため)。従業員 B は user_hash とデータを取得します。

于 2010-09-17T19:03:04.490 に答える
2

個人の識別情報を実際にどこにも保存しなくても、十分な情報をすべて同じキーに関連付けるだけで、特定の情報に関連付けられた人物の身元を特定できる可能性があることに注意してください。簡単な例として、ストリップ クラブに電話して、どの顧客がフェラーリを運転しているかを尋ねることができます。

このため、(研究などで使用するために) 医療記録を匿名化する場合は、89 歳以上の人の誕生日を削除する必要があります (特定の生年月日が 1 人の人物を指し示すほど古い人はまれであるため)。人口が 20,000 人未満の地域を指定する地理的コーディングを削除します。( http://privacy.med.miami.edu/glossary/xd_deidentified_health_info.htmを参照)

AOL が検索データを公開したとき、どの検索が匿名の人物に関連付けられているかを知るだけで人物を識別できるという難しい方法を発見しました。( http://www.fi.muni.cz/kd/events/cikhaj-2007-jan/slides/kumpost.pdfを参照)

于 2010-09-17T20:04:43.077 に答える
1

データが所属する人物に接続できないようにする唯一の方法は、そもそもID情報を記録しないことです（すべてを匿名にします）。ただし、これを行うと、アプリが無意味になる可能性があります。これをより困難にすることはできますが、不可能にすることはできません。

ユーザーデータと識別情報を別々のデータベース（場合によっては別々のサーバー）に保存し、2つをID番号にリンクすることは、おそらく最も近い方法です。このようにして、2つのデータセットを可能な限り分離しました。それらの間のリンクとして、そのID番号を保持する必要があります。そうしないと、ユーザーのデータを取得できなくなります。

また、ハッシュ化されたパスワードを一意の識別子として使用することはお勧めしません。ユーザーがパスワードを変更すると、すべてのデータベースを調べて更新し、古いハッシュ化されたパスワードIDを新しいものに置き換える必要があります。通常、ユーザーの情報に基づかない一意のIDを使用する方がはるかに簡単です（静的な状態を維持するため）。

これは結局、技術的な問題ではなく、社会的な問題になります。最善の解決策は社会的解決策になります。不正アクセス（ハッカーなど）から保護するためにシステムを強化した後、ユーザーとの信頼を確立し、データセキュリティに関するポリシーと手順のシステムを実装することに取り組むことで、おそらくより良いマイレージを得ることができます。顧客情報を悪用した従業員に対する特定の罰則を含めます。顧客の信頼を1回破るだけで評判が損なわれ、すべてのユーザーが追い払われるため、「トップレベル」のアクセス権を持つユーザーがこのデータを悪用する誘惑は、想像以上に少なくなります（通常、会社が崩壊するため）どんな利益よりも重要です）。

于 2010-09-17T17:54:14.053 に答える
0

実は、あなたが話していることを実行できる可能性がある方法があります...

名前と pw に基づいてハッシュを生成する純粋なクライアント側スクリプトを実行するフォームに、ユーザーに自分の名前とパスワードを入力させることができます。そのハッシュは、ユーザーの一意の ID として使用され、サーバーに送信されます。このようにして、サーバーは名前ではなくハッシュによってのみユーザーを認識します。

ただし、これが機能するためには、ハッシュが通常のパスワード ハッシュとは異なる必要があり、ユーザーが購入したものをサーバーが「記憶」する前に、ユーザーは自分の名前/パスワードを追加で入力する必要があります。

データベースにはユーザー アカウントと機密情報との間のリンクが含まれていないため、サーバーは、ユーザーがセッション中に何を購入したかを記憶し、「忘れる」ことができます。

編集

クライアントでのハッシュはセキュリティ上のリスクであると言う人たちへの返答: 正しくやればそうではありません。ハッシュ アルゴリズムが既知であるか、または認識可能であると想定する必要があります。別の言い方をすれば、「あいまいさによるセキュリティ」に相当します。ハッシュには秘密鍵は含まれず、動的ハッシュを使用して改ざんを防ぐことができます。

たとえば、次のようなハッシュ ジェネレータを使用します。

http://baagoe.com/en/RandomMusings/javascript/Mash.js

// From http://baagoe.com/en/RandomMusings/javascript/
// Johannes Baagoe <baagoe@baagoe.com>, 2010
function Mash() {
  var n = 0xefc8249d;

  var mash = function(data) {
    data = data.toString();
    for (var i = 0; i < data.length; i++) {
      n += data.charCodeAt(i);
      var h = 0.02519603282416938 * n;
      n = h >>> 0;
      h -= n;
      h *= n;
      n = h >>> 0;
      h -= n;
      n += h * 0x100000000; // 2^32
    }
    return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
  };

  mash.version = 'Mash 0.9';
  return mash;
}

n文字列をハッシュするたびに、どのように変化するかを確認してください。

  • 通常のハッシュ アルゴリズムを使用して、ユーザー名とパスワードをハッシュします。これは、データベース内の「秘密」テーブルのキーと同じですが、データベース内の他のものとは一致しません。
  • ハッシュされたパスをユーザー名に追加し、上記のアルゴリズムでハッシュします。
  • Base-16 でエンコードvar nし、区切り文字を使用して元のハッシュに追加します。

これにより、データベース内の各列に対してシステムがチェックできる一意のハッシュ(毎回異なります) が作成されます。特定の一意のハッシュを 1 回 (たとえば、1 年に 1 回) だけ許可するようにシステムをセットアップして、MITM 攻撃を防ぎ、ユーザーの情報がネットワークを介して渡されることはありません。私が何かを見逃していない限り、これについて不安なことは何もありません。

于 2010-09-17T17:34:42.387 に答える
0

問題は、誰かがすでにデータベースへの完全なアクセス権を持っている場合、記録を特定の人物に結び付けるのは時間の問題だということです。データベース (またはアプリケーション自体) のどこかで、ユーザーとアイテムの間の関係を作成する必要があります。誰かが完全なアクセス権を持っている場合、そのメカニズムにアクセスできます。

これを防ぐ方法は絶対にありません。

現実には、完全なアクセス権を持つことで、私たちは信頼できる立場にいます. これは、会社の管理者が、たとえあなたがデータを見ることができても、あなたがそれに基づいて行動しないことを信頼しなければならないことを意味します. これは、倫理のようなささいなことの出番です。

とはいえ、多くの企業は開発スタッフと生産スタッフを分けています。目的は、開発がライブ (つまり、実際の) データと直接接触することを排除することです。これには多くの利点があり、セキュリティとデータの信頼性が最優先されます。

唯一の本当の欠点は、一部の開発者が、本番アクセスなしでは問題をトラブルシューティングできないと考えていることです。しかし、これは単に真実ではありません。

その場合、本番サーバーにアクセスできるのは制作スタッフだけになります。それらは通常、保護する必要があるデータの種類に応じて、より高度に精査されます (犯罪歴やその他のバックグラウンド チェック)。

これらすべての要点は、これが人的問題であるということです。技術的な手段で本当に解決できるものではありません。

アップデート

ここにいる他の人々は、パズルの非常に重要で重要なピースを見逃しているようです. つまり、何らかの理由でデータがシステムに入力されているということです。その理由はほぼ普遍的であるため、共有することができます。経費報告書の場合、そのデータが入力されるため、経理部門は誰に返済するかを知ることができます。

つまり、システムは、あるレベルで、データ入力担当者 (つまり、営業担当者) がログインすることなく、ユーザーとアイテムを一致させる必要があります。

また、関係者全員が立ってセキュリティ コードを入力してデータを「解放」することなく、そのデータを結び付ける必要があるため、DBA はクエリ ログを確認して誰が誰であるかを確実に把握できます。そして、いくつのハッシュマークを入れたいかに関係なく、非常に簡単に追加できます。トリプル DES もあなたを救いません。

結局のところ、開発を難しくするだけで、セキュリティ上のメリットはまったくありません。これはいくら強調してもしすぎることはありません。DBA からデータを隠す唯一の方法は、1. そのデータを入力した本人だけがアクセスできるようにするか、2. そもそも存在しないようにすることです。

オプション 1 に関しては、アクセスできるのが入力した人だけである場合、企業データベースに存在する意味はありません。

于 2010-09-17T17:32:55.580 に答える
0

あなたはこれで順調に進んでいるように見えますが、あなたはそれを考えすぎているだけです (または私は単にそれを理解していません)

入力に基づいて新しい文字列を作成する関数を作成します（ユーザー名または時間の経過とともに変更できないものになります）

ユーザーハッシュを構築するときに、返された文字列をソルトとして使用します（ユーザーのパスワードや電子メールのように変更されないため、ユーザーIDまたはユーザー名をハッシュビルダーの入力として使用します）

すべてのユーザー アクションをユーザー ハッシュに関連付けます。

データベースへのアクセスしかない人は、ユーザーのハッシュが何を意味するのかを判断できません。別のシードとソルトの組み合わせを試して力ずくで実行しようとしても、ソルトはユーザー名の変形として決定されるため、役に立たなくなります。

最初の投稿で自分の質問に答えたと思います。

于 2010-09-17T20:18:39.180 に答える