17

Google App Engineアプリは、ユーザーを識別するためにかなりの量の個人識別情報（メール、社会保障番号など）を保存します。そのデータを保護する方法についてのアドバイスを探しています。

私の現在の戦略

機密データを次の2つの形式で保存します。

  • ハッシュ-SHA-2とソルトを使用
  • 暗号化-公開/秘密鍵RSAを使用

ルックアップを行う必要がある場合：

  • ハッシュされたデータを検索します（クエリでPIIをハッシュし、データストアでハッシュされたPIIと比較します）。

データを再ハッシュする必要がある場合、またはその他の方法で生の形式で処理する必要がある場合：

  • 暗号化されたバージョンを秘密鍵で復号化します。生の形式で保存することは絶対に避けてください。処理してから、再ハッシュして再暗号化してください。

私の懸念

ハッシュソルトを秘密にしておく

攻撃者がデータストア内のデータとハッシュソルトを入手した場合、機密データをブルートフォース攻撃する可能性があるのではないかと心配しています。一部（SSN、9桁の数字など）には大きなキースペースがないため、最新のハッシュアルゴリズムを使用しても、攻撃者がソルトを知っていれば実行できると思います。

私の現在の考えは、ソルトをソース管理から外し、独自のファイルに保存することです。そのファイルはデプロイ中にGAEにロードされ、アプリは着信データをハッシュする必要があるときにファイルを読み取ります。

展開の合間に、ソルトファイルは怒っているクマ（または貸金庫）で保護されたUSBキー上に存在します。

塩は2か所にしか住んでいない

  1. USBキー
  2. Googleアプリにデプロイ

コードのダウンロードが完全に無効になっているため、誰かがそのUSBキーを盗むことなくソルトを入手する方法を考えることはできません。私は何かが足りないのですか？

プライベートRSAキーの秘密を守る

これについてはあまり心配していません。暗号化されたバージョンを復号化する必要があることはめったにありません（ハッシュアルゴリズムまたはデータ形式を変更した場合のみ）。

秘密鍵はGAEサーバーに触れる必要はありません。暗号化されたデータをプルダウンし、ローカルで復号化して処理し、暗号化/ハッシュ化されたバージョンを再アップロードできます。

RSA秘密鍵は、クマとトラで保護されたUSBスティックに保持し、必要なときにだけ取り出すことができます。

この質問はGoogleアプリに固有のものではないことは承知していますが、GAEによって状況がやや独特になると思います。

完全に制御できる場合は、展開アクセスをロックダウンしたり、2要素認証を使用してデータストアビューアにアクセスしたりしますが、現時点ではこれらのオプションは利用できません（GAE固有のパスワードを設定することは適切ですが、気に入っていますRSAトークンが含まれている）。

私もGAEの専門家でもセキュリティの専門家でもないので、足りない穴やプラットフォームに固有のことを考えていないことがあれば、ぜひ聞いてみたいと思います。

4

3 に答える 3

11

セキュリティアーキテクチャを決定するとき、最初に頭に浮かぶのは常に脅威モデルである必要があります。あなたの潜在的な攻撃者は誰ですか、彼らの能力は何ですか、そしてあなたは彼らに対してどのように防御することができますか？脅威モデルを明確に理解していないと、提案されたセキュリティ対策が十分であるかどうか、または必要であるかどうかを評価する方法がありません。

あなたのテキストから、あなたは次のサブセットから保護しようとしていると思います：

  1. データストアデータを侵害するが、アプリケーションコードを侵害しない攻撃者。
  2. アプリの管理コンソールにアクセスするための資格情報へのアクセスを取得し、新しいコードをデプロイできる攻撃者。

前者の場合、データストアデータを暗号化またはハッシュするだけで十分です（ただし、この回答の後半にある警告を参照してください）。後者からの保護はより困難ですが、管理ユーザーが新しいアプリバージョンをデプロイせずに任意のコードを実行できない限り、ソース管理にチェックインされていないモジュールにキーを保存すると、問題なく機能するはずです。 、管理者アクセスがあっても、キーを回復することも、キーを公開する新しいバージョンを展開することもできないためです。もちろん、ソースのダウンロードを無効にしてください。

限られた量のエントロピーを使用したデータのハッシュに関するいくつかの懸念に正しく注意します。そして、心配するのは当然です。ある程度、ソルトは事前計算攻撃を防ぐことでこれを助けることができ、PBKDF2、scrypt、bcryptで採用されているようなキーストレッチは、攻撃者がしなければならない作業量を増やすことで攻撃者の生活を困難にする可能性があります。ただし、SSNのようなものでは、キースペースが非常に小さいため、キーストレッチの量は役に立ちません。データをハッシュし、攻撃者がハッシュを取得した場合、攻撃者は元のSSNを特定できます。

このような状況で実行可能な唯一のアプローチは、秘密鍵を使用してデータを暗号化することです。これで、攻撃者はデータを取得するためにキーをブルートフォースする必要があります。これは桁違いに難しい課題です。

つまり、標準（秘密鍵）暗号を使用してデータを暗号化し、鍵をソース管理されていないモジュールに保存することをお勧めします。代わりにハッシュを使用すると、データが弱くなるだけですが、公開鍵暗号を使用しても、標準の暗号を使用してまだ持っていないもっともらしい脅威モデルに対して、感知できるほどのセキュリティは提供されません。

もちろん、ユーザーのデータを保護するための一番の方法は、可能であれば、そもそもデータを保存しないことです。:)

于 2012-04-11T01:38:22.387 に答える
3

HMAC、秘密鍵、およびエントリごとの一意のソルトを使用することで、ハッシュ アルゴリズムのセキュリティを高めることができます (これについて人々が私に同意しないことはわかっていますが、特定の攻撃を回避するのに役立つというのが私の研究からの私の信念です)。bcrypt または scrypt を使用してハッシュすることもできますが、これにより、ハッシュを元に戻すのに非常に時間のかかるプロセスになります (ただし、アプリがハッシュを計算するのに時間がかかるため、これも考慮に入れる必要があります)。

コードのダウンロードを無効にして秘密鍵を保護しておくことで、誰かがそれを手に入れる方法が想像できません。コードが同様のセーフガードの下で保護されていることを確認するか、開発中にコードから秘密鍵を削除し、展開する場合にのみ引き出すようにしてください. コード内に秘密鍵を保持することを想定しています (非常に安全にするために秘密鍵をメモリに保持するよう多くの人が言っていると聞きましたが、AppEngine とインスタンスの性質を考えると、これは現実的ではありません)。

更新: アプリの管理者権限を持つすべての Google アカウントで 2 要素認証を有効にしてください。Googleはこれを提供しているため、これを有効にするための制限が外部の力によって課されたかどうかはわかりません.

于 2012-04-10T22:38:42.950 に答える
1

データストア上のデータを暗号化する興味深いアプローチ。これを経験した後、私の頭に浮かぶ 1 つの質問は、ハッシュのデータをどのように照会するかということです。2 つのハッシュまたはより細かいハッシュの比較を使用していますか? テーブル内のデータをハッシュして暗号化した後、値よりも大きい、値よりも小さいなどの操作をどのように実行しますか?

細粒度ハッシュの意味は、データストリームの連続するバイトをハッシュして、累積されたハッシュを取得しますか。つまり、hash(abcd) = hash(a,b) + hash (b,c) + などです。このタイプのハッシングは、一致ではなく、基になるデータがどの程度類似しているかを示します。

于 2013-07-07T18:12:20.913 に答える