13

そこで私は、人事部門が元従業員の記録を保存および検索するために必要とする補助的な Web ベースのシステムに取り組んでいます。私はこの要件に抵抗しましたが、最終的には、システムは完全な SSN による検索と、完全な SSN の取得の両方を可能にする必要があると言い渡されました。私の抗議はさておき、このデータを保護するためにいくつかの措置を講じることは、実際に彼らが現在行っていることよりも大幅に改善されます (知りたくありません)。

私は多くの調査を行っており、合理的な計画を思いついたと思いますが、暗号化/セキュリティ関連のすべてのものと同様に、非常に多くの複雑さがあり、間違いを犯しやすい. 私のおおまかな計画は次のとおりです。

  1. アプリケーションの初回実行時に、RijndaelManaged を使用して大きなランダム ソルトと 128 ビット AES キーを生成します。
  2. 緊急時の復旧のために、これらの両方をプレーンテキスト ファイルに書き出します。このファイルは、安全な物理的な場所にオフラインで保存されます。アプリケーションはファイルの存在をチェックし、ファイルがまだ存在する場合は警告を発します。
  3. ソルトと鍵はどこかに安全に保管してください。これは私が素晴らしい答えを持っていない部分です。私は DPAPI を使用することを計画していましたが、最終的にどれだけ安全かはわかりません。プレーンテキストのままにして、保存されているディレクトリへのファイルシステムアクセスを制限する方がよいでしょうか?
  4. データベースにレコードを書き込むときは、上記の大きなソルト値とともに SSN をハッシュして、検索可能なフィールドを生成します (ただし、可能性のあるすべての SSN をソルトおよびブルート フォースで取得しないと回復できません)。AES は生の SSN 値を新しい IV (一緒に保存) を使用して、(キー/iv を使用して) 取得可能であるが検索可能ではないフィールドを生成します (同じ SSN を 2 回暗号化すると、異なる出力が生成されるため)。
  5. 検索するときは、検索値を同じソルトでハッシュしてDBで検索するだけです
  6. 取得するときは、AESキー/ivを使用してDBから値を復号化します

鍵を比較的安全な方法 (上記の 3) で保管する必要があることを除けば、それで十分なようです。

私たちにとってうまくいかないこと：

  • 「これをしないでください」という選択肢はありません。これを行う必要があり、それを行わないと、a) 私たちに腹を立て、b) 電子メールですべての数値をプレーンテキスト ドキュメントで渡すだけになります。

これは私たちのネットワークの内部でのみ行われるため、少なくともここで実装されているものの上にその保護レイヤーがあります. また、アプリケーション自体へのアクセスは Active Directory によって制御されます。

読んでくれてありがとう、そしてアドバイスをくれてありがとう。

更新 #1: コメントから、SSN 取得フィールドに非公開の IV を保持する意味がないことに気付きました。各レコードに対して新しい IV を適切に生成し、暗号化された値と一緒に保存するように計画を更新しました。

更新 #2: できないことのリストからハードウェアのことを削除します。少し調べてみたところ、思ったよりアクセスしやすいようです。これらの USB セキュリティ トークンの 1 つを利用することで、キー ストレージに意味のあるセキュリティが追加されますか?

4

4 に答える 4

2

キー ストレージに関しては、AES キーを web.config に保存することを選択した場合に使用できる方法が 2 つあります。あなたが言及したように、最初の方法はDPAPIを使用することです。これにより、そのボックスの web.config アプリケーション設定が暗号化されます。使用できるもう 1 つの方法は、RSA キーを使用する方法です (このMSDN チュートリアルを参照してください)。これにより、DPAPI と同じように web.config が暗号化されますが、複数のボックスで RSA キーを使用できるため、アプリケーションがクラスター化されている場合は、RSA キーの方が適しています。 （セットアップがさらに複雑になります）。

このようにアプリを実行しているマシン上ではなく、アプリケーションを実行する前にキーを生成する限り、ディレクトリにテキスト ファイルを残す可能性はありません。次のようにキーを生成する必要があります。

  1. RngCryptoServiceProviderを使用してランダムな値を生成する
  2. RngCryptoServiceProviderを使用してランダムなソルト値を生成する
  3. 2 つの値を PBKDF2 ( Rfc2898DeriveBytes )でハッシュします。

キー派生メソッドを使用する理由は、RngCryptoServiceProvider が何らかの理由で乱数ジェネレーターで発生する安全でないことが判明した場合に保護するためです。

AES 128 の代わりに AES 256 を使用してください。これらのアルゴリズムはとにかく非常に高速であるため、より高いセキュリティをほとんど無料で取得できます。また、CBC または CTR モードでアルゴリズムを使用していることを確認してください (CTR は BouncyCastle ライブラリで利用できます)。

誰かがあなたのディレクトリに aspx ファイルを置くことができた場合、これはあなたのキーを絶対的に保護するものではありません。そのファイルはアプリケーションの一部になるため、キーを含む復号化された値にアクセスできます。これについて言及している理由は、ネットワークとサーバーのセキュリティは一流でなければならないためです。そのため、ネットワーク セキュリティ チームと協力して、関係者以外は誰もそのボックスにアクセスできないようにすることを強くお勧めします。アクセスが必要な人事部門 (Active Directory ではなくファイアウォール)。このアプリケーションは、いかなる形や形式でも、インターネットから一般にアクセスできるようにしないでください。

また、人事部門を信頼することもできません。誰かがソーシャル エンジニアリング攻撃の犠牲者になり、最終的にログイン情報を提供してセキュリティ モデルを破壊する可能性があります。そのため、ネットワーク チームと連携することに加えて、システムに入るために 2 要素認証メカニズムを統合する必要があります。TOTPを実装するのではなく、実際の RSA キーなどを使用することを強くお勧めします。この方法では、部門の誰かが無料の iPad を獲得したと思ってパスワードを教えたとしても、攻撃者はアプリケーションにアクセスするために物理的なデバイスを必要とします。

すべてをログに記録する : 誰かが SSN を見たときはいつでも、定期的にアーカイブされる永続的な記録の一部となる場所にログを記録してください。これにより、迅速に軽減できます。また、特定の時間枠内に 1 人が表示できるレコード数にも制限を設けます。これにより、誰かがアプリケーション内からデータをマイニングしているかどうかがわかります。

このテーブルにアクセスするためだけに SQL ユーザーを作成し、他のユーザーがテーブルにアクセスできないようにします。これにより、特定のユーザー ID とパスワードでのみテーブル データを表示できるようになります。

実稼働環境に展開する前に、侵入テスト チームを雇ってアプリケーションをテストし、何が得られるかを確認する必要があります。これは、潜在的な攻撃者からアプリケーションを強化するのに大いに役立ちます。アプリケーションのセキュリティ。

于 2013-07-19T10:03:01.263 に答える
2

最近、同様の問題を解決する必要があり、ハッシュに HMAC を使用することにしました。これにより、特に値をソルトできないため、単純なハッシュよりもセキュリティが向上します (そうしないと、検索できなくなります)。

次に、あなたが言うように、可逆暗号化にランダムソルトを使用して AES を使用します。

このデータを暗号化する必要はないかもしれませんが、私には選択の余地がなく、これが合理的な解決策のように思えました。

IT セキュリティに関する私の質問https://security.stackexchange.com/questions/39017/least-insecure-way-to-encrypt-a-field-in-the-database-so-that-it-can-still-be -の

于 2013-07-18T22:47:49.123 に答える
0

限られた一連の入力をハッシュしてもまったく何も得られないことをどこかで読んだことがあると思います。簡単なグーグルは、同様の警告でこのSO投稿を見つけました：

SSN およびその他の限定ドメイン情報のハッシュ

私もセキュリティの専門家ではないことを認めなければなりませんが、可能な入力数が 10^9 よりもはるかに小さいことを考えると、まともなハッカーなら数時間で簡単に通過できるはずです。実際のセキュリティ/難易度の障壁ではなく、煩わしさの小さな層です。

このようにするのではなく、他にできることはありますか？たとえば、攻撃者が名前を番号に関連付けることができる場合にのみ、SSN は攻撃者にとって価値があります (誰でも簡単にすべての番号を列挙できるため)。その場合、SSN がリンクしているユーザー ID を、攻撃されにくい方法で暗号化できますか? 私はあなたの従業員テーブルに何らかのIDがあると仮定していますが、その代わりに電子メールまたは何らかのGUIDでハッシュを行うのでしょうか? そうすれば、彼らがあなたの SSN データを取得したとしても、そのリンクを総当たり攻撃するまで、それがどの従業員のものかを知ることはできません.

繰り返しになりますが、会社には合計でそれほど多くの従業員がいない可能性があるため、このアプローチにも欠陥があります。その時点で、会社のディレクトリを推測してチェックするだけで、すべてを達成することができます。どのようにスライスしても、SSN を他の識別データと一緒に保存する必要がある場合、このセキュリティ上の欠陥が存在することになります。

于 2013-07-18T20:54:46.053 に答える