検索可能性を維持しながら、MySQL DBで機密データを匿名化
個人に関する機密（個人）データを格納するMySQLデータベースがあります。そして、個人とそのデータを保護するために、このデータが何らかの方法で暗号化されていることを確認する義務があります。サーバーが侵害されているか、ホスティングサービスプロバイダーの悪意のあるユーザーが許可なくサーバーにアクセスしています。データベースは、同じサーバー上にあるPHP Webフレームワークによって使用されます。
私は、データを暗号化して適切な許可なしに読み取ることができないようにする適切なスキームに苦労しています。機能を維持しながら（インデックス、データベース関係、Webフレームワークでデータを読み戻すことができる）。最良の選択肢は何ですか？
私が検討した2つのアプローチは次のとおりです。
1）データベースの特定のフィールド/データをキーで暗号化することで、データベースが危険にさらされた場合でも、データベース内の情報を個々のユーザーが推測することはできません（たとえば、インデックスや関係を維持しますが、個人を特定できる情報は暗号化されます）。アプリは実行時にキーを使用して情報を復号化します。課題はキーを管理する方法にあります。キーがアプリロジックに配置されているか、アプリロジックから同じサーバー上のファイルとしてアクセスできる場合でも、キーは危険にさらされる可能性があります。おそらく、それは別のサーバー上にある可能性があります。ただし、アプリケーションロジックによって実行時にアクセスする必要があります。つまり、アプリのロジックにアクセスすることで、キーを取得することが可能になります。おそらく、サーバーの起動時にキーをメモリに保存することができます。ただし、安定性の問題が発生する可能性があります（再起動後にサービスが停止）。オプションとは何ですか？これは良いアプローチですか？
2）個人を特定できる情報と残りのデータベースとの間にある種の論理データ分割を実装する。例えば。個人情報（ユーザー名、電子メール）の表とインデックス。機密データを含むテーブル（健康情報のテーブルなど）と別のインデックス;次に、あるタイプの一方向キーベースの暗号化を導入します（例： http://en.wikipedia.org/wiki/Message_authentication_code と考えてください）、2つのテーブルのマッピング、個人情報間の関係キーを指定してテーブルを一致させることができる場合にのみ、機密データを作成できます（ランタイムはアプリロジックによっても可能です）。しかし、繰り返しになりますが、上記のシナリオで使用されているキーへのアクセスを管理する必要性に出会いました。上記と同様。
ベストプラクティスとは何ですか？
適切なデータベース情報処理の詳細はすべて、StackExchangeの迅速な回答の範囲をはるかに超えています。あなたは本当にこれを正しい方法でしたいです。問題の一部は、データベースと機密情報にアクセスするWebアプリが同じサーバー上にあるアーキテクチャです。そのサーバーが危険にさらされると、行う暗号化のキー情報も危険にさらされます。
設計理論ではなく、実用的な解決策を探しているだけの場合は、2つの提案があります。
1つは無料でオープンソースですが、活発に開発中です（したがって、ビジネスでの運用にどれほど適しているかはわかりません）。
もう1つは、購入できる商用ソリューションです（ビジネスには適していますが、予算やビジネスニーズはわかりません）。
オープンソース-cryptdb （githubで利用可能なコード）
私は両方を使用しましたが、あなたの状況についての詳細を知らなければ、どちらがあなたに適しているかは言えませんでした。電圧はよりビジネスに対応しており、フォーチュン500企業によって使用されています。cryptdbは、自分でできるタイプにアピールする可能性のある研究プロジェクトです。
データベース全体を暗号化するか、各レコードを個別に暗号化するかを決定する必要があると思います。
DB全体の暗号化-簡単に実行できます。実装できるさまざまなメカニズムがあります。このメカニズムは、ハッキング/ dbの盗難からの優れた保護を提供しますが、ITスタッフがデータを読み取ったり、盗んだりするのは簡単です。
各レコードの暗号化-ユーザーに最高のデータ保護を提供します。 Dbが盗まれたかのように、ハッカーはすべての記録を総当たりにする必要があります。 2サーバーソリューションとして実装し、1サーバーがキーを生成し、他のサーバーがデータを保存します。これにより、2つのデータベースが個別に管理されている限り、「Mr Black Hat」だけでなく、内部のスタッフからもデータが保護されます。 「Black Hat」氏は、データにアクセスするために、2つのシステムから両方のDbを盗む必要があります。
これが問題への取り組み方についていくつかのアイデアを提供することを願っています。
これは、 sys管理者など、すべてのユーザーからデータベースデータを保護する とよく似ています。
2番目のオプションは機能しません（少なくとも単独では）。健康情報データを知っているだけでも「十分に悪い」（そして間接的にユーザーと一致する）可能性があります。その関係をさらに隠すことは興味深いかもしれませんが、それを行う価値があると私は確信していません。
2番目のオプションは正しいです。 dbの検索機能を維持するために、キーとして使用されるフィールド（例：名前、患者番号）のインデックスを保持します。これは暗号化しません。その他のフィールドはアプリケーションによって復号化されます。
キーを保存する場所に関する最良の解決策は、キーを保存しないことです。ユーザーに手動でキーを入力させます。または、いくつかの公開鍵で暗号化し、ユーザーは使用する前に自分の鍵のロックを解除する必要があります。
次のスキーマがあるとします。
Table doctors:
Username, public key, disabled
Table patients:
Name, encrypted info
新しいユーザーが初めてアプリを開くと、ローカルで新しい（パスワードで保護された）公開鍵が作成され、それ自体がDoctorsテーブルに登録されます（検証などが必要）。
次回、ユーザーはパスワード（鍵のロック解除に使用）を要求され、秘密鍵の知識を使用してログインが制御されます。
患者から詳細を取得するときは、BLOBを回復し、公開鍵で復号化して詳細を抽出します（実際に一緒に使用する場合は、1つのBLOBに複数のフィールドを格納する方が効率的です）。
Dbにプレーンで保存するか（攻撃者が独自のキーを挿入できるようにする）、またはblobに暗号化できるため、既存の医師は新しい医師を「患者の治療」として追加する必要があります。
アプリが、無効化されたビットが設定されている（たとえば、会社を去った）患者が医師にリンクされていることを発見した場合、そのようなものは、暗号化されている人のリストから削除されます。