Google で調べたところ、 Fast Search on Encrypted Fieldへの参照が見つかりました。「データの匿名化」というコメントがありました。受け入れられている方法のようです。
これが私がそれがどのように機能するかを想像する方法です。この例では、患者名を患者レコードの残りの部分から分離します。
Patient Row: [id=1, name_and_link=9843565346598789, …]
Patient_name Row: [id=1, name=”John”, patient_link=786345786375657]
name_and_link フィールドは、名前と Patient_name へのリンクの 2 つのフィールドの暗号化されたコピーです。両方のテーブルに名前を持つことは冗長です。より高速なアクセスを提供することをお勧めします (Patient_name テーブルから読み取る必要はありません)。必要に応じて、Patient_name テーブルを再作成することもできます (たとえば、2 つのテーブルが同期しなくなった場合)。
Patient_name テーブルには、名前の値の暗号化されていないコピーが含まれています。名前行は、高速アクセスのために索引付けできます。名前で検索するには、Patient_name テーブルで一致する名前を見つけてから、Patient テーブルに戻る暗号化されたリンクを使用します。
注: 上記の例では、暗号化されたデータのサンプルとして長い数字を示しています。実際の生活ではもっとひどいです。暗号化方法にもよりますが、暗号化された値の最小の長さは、Postgres の pgp_sym_encrypt() 関数を使用して約 67 バイトです。つまり、文字「x」を暗号化すると 67 バイトになります。そして、ID を削除したフィールドごとに 2 つの暗号化フィールドを提案しています。そのため、Patient テーブルで名前とリンクを一緒に (JSON タプルとして?) 暗号化することをお勧めします。2 つのフィールドを別々に暗号化する場合と比較して、スペースのオーバーヘッドを半分に削減します。
注: これには、いくつかのフィールドを分割する必要があります。(例: 電話番号、SSN、住所)。各パーツは個別のテーブルに格納する必要があります。住所のストリート部分でさえ、さらに細分化する必要があります。これは複雑になってきています。Postgres がこれを自動化することを望みます。
注: パスワードへのアクセスを制御すること自体が難しい問題です。