アプリケーション レベルの暗号化を使用してデータベース内の機密情報を保護する API を設計しています。
問題の簡単な例は、次のフィールドを持つユーザー テーブルです。
- ユーザーID
- 名前
- 住所
- 電話番号
- クライアント識別子
上記のテーブルでは、すべてのフィールドが機密情報であり、テーブルのプライマリ キーである UserID を除いて暗号化する必要があります。外部キー制約には主キーが存在しますが、レコードの実際の識別値は ClientIdentifier です。これは、API のコンシューマーによって制御されるユーザーの ID です。
API のコンシューマーがユーザー レコードを作成する場合、すべての詳細 (ClientIdentifier を含む) を渡して保存します。それらの詳細を取得する場合は、再度 ClientIdentifier を渡します。このユース ケースでは、ユーザー ID を使用できません。
ClientIdentifier は、電子メール アドレスやアカウント番号などの一般に知られている可能性があり、実在の人物にまでさかのぼることができます。したがって、レコードの存在はその人物がシステムに存在することを意味するため、ClientIdentifier を保護する必要があります。
いくつかのオプションがあります。
ClientIdentifier をハッシュします。これの欠点は、ClientIdentifier が固定形式に従う可能性が高く、ブルート フォース攻撃に対して脆弱であることです。
すべてのデータを暗号化しますが、ClientIdentifier の場合は固定の IV を使用します。ここでの欠点は、API とデータベースの両方にアクセスできる攻撃者が、システムに対してプレーン テキスト攻撃を実行できることです。
データベースのスナップショットが失われた場合、プレーンテキスト攻撃はおそらく暗号化サービスを監視することで軽減できるのに対し、ハッシュオプションはかなり迅速に壊れる可能性があるため、私は2番目のオプションに傾いています.
私の質問は、私が正しい方向に進んでいると思いますか、それともより良い代替手段があると思いますか?
編集: データベースに同じ ClientIdentifier を持つ複数のレコードが存在する可能性があります。平文の ID があれば、それらすべてのレコードを選択できるはずです。