データベースダンプによる損傷を軽減する方法
潜在的なデータベースダンプによる潜在的な損傷を軽減するための良い方法はありますか？
データをまったく保存しないことをお勧めしますが、保存する必要のある機密データは常に存在することはわかっています。
パスワードなどについては、bcryptまたはPBKDF2ハッシュを使用することで回避できる可能性があります。しかし、住所、クレジットカード、医療情報などの他の情報はどうですか？データベース内で暗号化することもできますが、そうすると検索できなくなります。データベースのフィールドへのデータを暗号化することは実際に意味がありますか？
また、実際にデータベースを別の場所にある複数のデータベースに分割することも提案されています。これは理にかなっていますか？ 1つが侵害された場合、他の1つをダンプする可能性は非常に簡単です。
考えれば考えるほど、情報を保存せず、そもそもそれが実際に発生するのを防ぐ以外に、データベースダンプの被害を軽減できるものはありません。本当にそうですか？
あなたはアプリケーション層でデータを正しく暗号化し、データベースに保存することは検索に制限がありますが、巧妙なアプリケーションアーキテクチャは、メモリなどのアプリケーションの実行中にデータの一時的な復号化を許可することでこれのいくつかを回避することができます-依存データセットのサイズ、セキュリティ要件、必要なコンプライアンスレベルについて。
ご指摘のとおり、シャードオプションは保護をほとんど提供せず、システムを複雑にしてほとんどメリットがありません。
完全なデータベース暗号化オプションはどうですか？これらはデータベースエンジンによって処理され、アプリケーションに対して透過的です https://docs.Microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-tde
暗号化は良い考えです。しかし、問題は、攻撃者がどのようにしてDBをダンプできるかです。暗号化/復号化するアプリケーションを超えても、何の影響もありません。正しく言ったように、完全なDB暗号化は内部攻撃に対する保護にすぎません。
カードデータに関しては、いわゆるカードホルダーデータを保存したい場合に従う必要がある正確な要件があります。認定に合格したい場合は、静かで高い確率で、処理および保存するデータの種類に応じてHarware Security Moduleを使用するよう求められます。あなたがそれを避けることができるなら、私はそれらをまったく保存しないで、PCI DSS標準の範囲外であることをお勧めします。
私が知る限り、DBダンプを操作したり、検索したりすることはまだ簡単に可能ですが、DBダンプに対する適切な保護スキームはありません。
どのようにしてDBがダンプされ、DB（環境全体）がそれから保護されるかを検討することをお勧めします。そして、これにはもっと多くの行の書き込みが必要です;）
グローバルに分散、シャーディング、ソルト化、ハッシュ化、暗号化、およびインデックス化されたソリューションを開発するとします。データは、トークン化された一連のSHA256ハッシュとして、世界中のデータセンターに分散された行暗号化されたKey-Valueテーブルに格納されます。すべてのデータセンターは相互にファイアウォールで保護されており、すべてがフルディスク暗号化を実行しています。
- 誰も単一のサーバーにログインしてデータをダンプすることはできません。
- 誰もがハードドライブをヤンクしてデータを持ち去ることはできません。
- たとえあったとしても、任意のデータを取得します（ '1568de12b5c51ac272fcd9112b5c9'： '2b472568deac272fcd9112b5c51880f0ac443d1c'）。
保存したものをどうすることを正確に提案しますか？
ビジネスケースのデータを検索、取得、解読するために開発するメカニズムがどのようなものであっても、システムが危険にさらされることになります。それはおそらくソーシャルエンジニアリングまたはソーシャルエンジニアリングを介して導入されたマルウェアの結果でしょう。アクセス権のある人が資格情報をフィッシングメールで漏らしたり、コールセンターの担当者がリクエストを実行する前に発信者の認証に失敗したりします。
干し草の山から重要なデータを取り出すアルゴリズムが現在存在しているという事実により、すべてのセキュリティ管理策を無効にすることができます。
それで、どのように軽減するのですか？アーキテクチャを複雑にしすぎないでください。それは結局あなたを救うことはありません、そしてあなたが残されるすべては使用不可能な悪夢です。
正気なコントロールを実装して、最も弱いリンクを強化するだけです。
あなたが言ったように、パスワードはハッシュ化することができます。まれに（たとえあったとしても）読み取る必要があるデータを連結する必要がある場合があります。ここでは、公開鍵（対応する秘密鍵をオフラインにしておく）を使用した非対称暗号化が解決策になることがあります。値。それ以外はすべて読み取り可能である必要があります。
つまり、アプリケーションにはデータを復号化する手段が必要です。したがって、データベースへのバックドアがない限り、（暗号化された）データへのルートはキー（またはクリアテキスト）へのアクセスも提供します。すべてのデータを256ビットのAESで暗号化すると聞いて株主に印象づけるかもしれませんが、SQLインジェクション攻撃によってクリアテキストを引き続き取得できる場合は、メリットはありません。データベースの暗号化には、少なくとも20％のパフォーマンスオーバーヘッドがあります（場合によってははるかに高い）。ほとんどの人はセキュリティのための限られた予算を持っています、そして私は攻撃面を保護するためにその時間とお金を使う方が良いことを提案します。
データベース（またはアプリケーションレベル）のデータ暗号化（あなたが話していると思います）は、ファイルやブロックデバイスの暗号化とはかなり異なります。これは、物理メディアへの不要なアクセスから保護します。これははるかに低く、一貫したパフォーマンスのオーバーヘッドがあります。多くのdbmsはファイルの暗号化（多くの場合fullデータベースの暗号化と記述されています）を提供します。ストレージインフラストラクチャを制御しない場合は、これが不可欠だと思います。その場合、ファイルシステムは潜在的に攻撃面の一部になります。