SQLフィールドレベルの暗号化、どれくらい安全ですか？
データベースの暗号化 および/またはいくつかのテーブルの特定の列のみを暗号化することを検討しています。時間の価値はありますか？つまり、私の暗号化されたデータベースを手に入れようとすると、誰かにどれほどの負担がかかりますか？誰かがこれを破る方法を見つけたことはありますか？
SQL Server 2005以降で列レベルの暗号化を使用することに関心がある場合は、SQL Serverの組み込みの暗号化機能を使用して機密データを保護する方法のサンプルコードがたくさんあります。コードはすべて http://sqlcrypto.codeplex.com/ で入手できます。
コードでは、機密データを暗号化し、許可されたユーザーだけが暗号化を解除できるようにする方法を示します。私は組み込みのキー管理機能を利用して、データベースエンジンによって管理されるランダムに生成された強力な対称AESキーを使用し、それらのAESキーは証明書で保護されます。データベースロールは、誰がどのキーにアクセスできるかを制御し、SQL Serverの組み込み暗号化を使用すると、パスフレーズを使用してキーまたは証明書をさらに保護できるため、データの機密性が非常に高い場合でもDBAを信頼する必要はありません。そうは言っても、DBAを信頼しないと、他の問題が発生します:)
SQL Serverは暗号化で正しいことを行うため（一意のIVを保証）、テーブルスキャンを実行し、すべての行を復号化して一致があるかどうかを確認しないと、暗号化された列を検索できません。暗号化されたデータのHMACを構築するためのサンプルコードをいくつか提供します。これにより、クリアテキスト情報を漏らすことなく少なくとも基本的な検索を実行できます。
また、組み込みのハッシュアルゴリズム（本番環境での使用には不十分）と、はるかに優れたパスワードストレージのためのbCryptハッシュアルゴリズムのSQLCLR実装の両方を使用して、ソルトされたストレッチハッシュのパスワードを格納する方法の例もあります。
透過的なデータ暗号化を使用して、ディスク上のデータとログファイルの完全なコンテンツを暗号化する方法を示すサンプルコードもあります。
組み込みの暗号化を使用する利点は次のとおりです。
- 優れたキー管理、サーバーは暗号化キーを生成するときに正しいことを行い、複数のレベルの暗号化を使用してキーを保護します
- 正しい暗号化により、サーバーはすべてのデータが書き込まれるたびにナンスIVで暗号化されることを保証します。つまり、誰かが2つの暗号化された値を見て、それらが同一のクリアテキスト値であると判断できません。
- 暗号化された列のオプションの整合性チェックにより、暗号化された値を別の暗号化された値で上書きできないようにする
- 移植性。複数のプラットフォームからデータにアクセスできます。プラットフォームの実装の違いによる頭痛の種に対処する必要はありません。
- 保存時のデータのセキュリティが良好です。暗号化はログまたはデータページがディスクに書き込まれる前に行われるため、ログに記録されるデータにはクリアテキストが含まれません。
- 最小限の特権の原則に従い、暗号化キーへのアクセス権を、それを必要とするロールやユーザーにのみ付与する機能。
編集：Microsoft SQL Serverの特定の情報については、 @ Joeのコメント を参照してください。また、
あなたが説明する機能はbinlogs（またはファイルシステムへの侵入の場合と同様）を暗号化しますが、復号化の自動性質のため、SQLインジェクションを使用してデータにアクセスした場合、おそらく役に立たないでしょう。機密情報を別のSQLユーザーにボックス化する（そしてメインユーザーから制限する）か、暗号化/ハッシュのレイヤーを追加することもできます。
SQLインジェクション防止の再確認は言うまでもありません。
前述のように、暗号化されたデータベースは、プログラミングの努力は言うまでもなく、計算コストが高くなります。
いくつかの提案
すでに述べたように、機密情報を暗号化しますパスワード（他のアカウントの機密情報にアクセスするために使用される可能性があります）、またはクレジットカード番号、SSN（もちろん）などです。 復号化する必要がない場合（たとえば、1つの暗号化されたパスワードをファイル上のパスワードと比較するために、復号化する必要はありません）ハッシュ関数を使用します。
SQLインジェクションの場合リスクの軽減については、 SQLユーザーアクセスのボックス化 をご覧ください。システムの認証部分は、システムの他の部分から分離できます。これは、より注意深くレビューされ、変更の頻度が少ない、はるかに少量のコードである可能性があります。
暗号化する場合 AESなどの強力で推奨されるルーチンと、完全なランダムキー（単純なパスフレーズだけでなく）を使用してデータを[その後、データはキーがないと役に立たなくなります、ただし、重複の検出、行のカウント、暗号化されていない情報との関係の確認などの基本を除きます。
侵入者はデータベース以外のものにアクセスする可能性があります。侵入者がデータベースおよびキーにアクセスできる場合（たとえば、プログラムにハードコードされている場合）、ほとんど効果がありません。必要に応じて、 プレーンキーでのストレージを防止する複雑なモデル を検討できます。もちろん、これは既存のシステムを改造する場合には非常に複雑です。
SQL組み込み暗号化を使用しない関数。侵入者がデータベースにアクセスした場合も同様の問題が発生しますおよびbinlogs。 （MySQLなどのSQLステートメントログ）SQL組み込みルーチンは、ステートメントが評価された後ステートメントの後に、プレーンログ内のパラメーターがbinlogにコピーされます。ステートメント形式のログ（bin-logs、slow-logs）に侵入するプレーンバージョンのリークを防止するために、プログラム内の暗号化に固執する必要があり、プロセスリストにもリークする可能性があります。
でも本当に
- 最初にSQLインジェクションがないことを確認する必要があります。
そして、他のより明白な脆弱性。 外部シェルを強化することは、より経済的な投資のようです。
- Patching Web向けサービス、
- 無効化未使用のアクセスドア、
- アクセスリストは防ぐことをお勧めします非信頼IPアドレス、または非VPNユーザーが脆弱性を悪用（負荷を軽減できることは言うまでもありません）サービス拒否攻撃に対して）
暗号化は潜在的に価値があります後続の防衛線 /責任の軽減。
しかし私が参照した複雑なモデルは、最も弱いリンクと同じくらい強力です。
- 多くの人は本当にパスワードに単一の単語を使用します、
そして、あなたはあなたがあなたのような何かを逃していることに気付くかもしれません
- 十分に遅いハッシュルーチンを使用していない、または
- 侵入者がクラッキングクラスターを短時間レンタルできるとは予想していませんでした。
しかし、それでも最善の努力をする必要があります。
理想的に、あなたのコンピュータは許可されたものだけを与えるでしょう、そしてストレージの暗号化は無意味でしょう。これはまれにケースです。
この回答は、直接的なハッキングにのみ焦点を当てていることに注意してください。物理的なアクセスや、システム管理者のPCの1つを介したアクセスは対象外です。
多くの場合、暗号化は問題ではありません。ほとんどの場合、データベース全体の暗号化はほぼ間違いなく時間の無駄です。
多くの場合、暗号化する必要がある非常に重要な値があります。見落とされがちな値は、セッションID、csrfトークン、パスワードソルト、および忘れられたパスワードトークンです。セッションIDをデータベースに保存するのに十分なほど愚かである場合、SQLインジェクションの欠陥を持つハッカーは、パスワードハッシュをクラックする必要なく、この値を引き出してログインすることができます。
他のユーザーがすでに述べたように、データベース全体の暗号化はおそらくやり過ぎです。つまり、暗号化する必要のないフィールドを暗号化するため、余計なセキュリティは得られず、パフォーマンスが低下します。
このように考えてください。SQLインジェクションのおかげで、攻撃者がデータベース内のすべてのデータにアクセスできたとします。攻撃者が絶対に見てはならない情報と、代わりにそれほど重要ではない情報。つまり、攻撃者はそれを読むことができたとしても、それを使って何もできなかったのですか？最初のタイプの例はユーザーのパスワードであり、2番目のタイプの多くの例の1つは、何らかの理由でこの情報をデータベースに格納する必要がある場合、ユーザーの好みの色です。
したがって、データベース全体を暗号化することは、時間とパフォーマンスの損失に値しませんが、絶対に暗号化する必要があるいくつかのフィールド（パスワード、クレジットカード番号、SSN、セッションID、およびこのリストに個人ユーザー情報を追加することもできます）電話番号などのように、ユーザーはこれに感謝します:)）。
攻撃者がデータベースにアクセスできる場合、一部のフィールドが暗号化されていても、最終的にはデータベース内のすべての情報にアクセスできる可能性があることを忘れないでください。データベースに非常に重要な情報がある場合、この余分な時間は非常に重要です。
そして最後に提案：SQLインジェクション攻撃の防止に時間を費やす。これはおそらく、攻撃者がデータベースに不正にアクセスできる最もよく使用される手法です。
場合によります。攻撃者は常にシステム内の最も弱いセキュリティリンクを標的とすることに注意してください。暗号化されていないデータベースデータがシステムで最も弱いリンクだと思いますか？それはややありそうにないようです。それは確かに追加の保護を提供しますが、あなたの時間はおそらくシステムの他の部分を保護することに費やされ、セキュリティの最も弱いリンクである可能性が高くなります。
また、DBの暗号化は、一般に、計算上はかなりコストがかかることに注意してください。 DBが多くのクライアントに大量のデータを提供する場合、これはシステムを本当に遅くする可能性があります。