MySQLの暗号化とキー管理
クライアントデータを管理するために、PHP/MySQLでローカルイントラネットシステムを開発しています。入力時にMySQLサーバー上の機密データを暗号化するのがベストプラクティスのようです。
ただし、データに簡単にアクセスできる状態でこれを行うための最善の方法はわかりません。
答えるのは難しい質問のようです：キーはどこに保存されていますか？キーを最もよく保護する方法は？キーが各ユーザーのマシンに保存されている場合、マシンが悪用された場合にキーを保護するにはどうすればよいですか？キーが悪用された場合、キーを変更するにはどうすればよいですか？
キーをDBに保存する場合、そこで保護するにはどうすればよいですか？ユーザーはどのようにアクセスしますか？
高度な暗号化キー設定を処理するための組み込みのMySQL機能は実際にはありません。暗号化ロジックの大部分を独自のPHPおよび/またはブラウザ側（javascript？）コード）に実装する必要があります。
しかし、あなたが述べた懸念は少し独特です。あなたの唯一の本当の懸念は、リモートクライアントデスクトップ/ラップトップワークステーションからのSQLインジェクションまたはブルートフォース（パスワード推測）攻撃であるようです。それはあなたがすでに他のいくつかの言及されていないセキュリティ対策を計画していて、あなたが妥協の可能な道を分析したのではないかと私に思わせます。
1つは、承認されていないリモートクライアントIPからのあらゆる種類のアクセスからMySQL/PHPホストを保護するファイアウォールルールがあることを前提としています。私が正しければ、侵害されたユーザーのワークステーションからの攻撃だけを心配しているのは理にかなっています。
また、リモートクライアントホストの攻撃者がroot/Admin特権にエスカレートしたり、実際のユーザー自身のアカウントを直接侵害したりする可能性がある場合、暗号化やその他の保護手段に関係なく、そのクライアントのデータは保護されないことを理解していると思います。 （攻撃者は、ディスクに保存されている場所からキーを読み取ったり、実際のユーザーがログオン時にキーを入力したときにキーをスヌープしたりできます。キーはデータにつながります。）
これらの2つの仮定から始めて、関連する2つの脅威はA）ブルートフォースパスワード推測とB）SQLインジェクションの試みだけであると結論付けるのは理にかなっています。
- 攻撃者が実際のユーザーのキーを入手できない場合、または実際のユーザーのデータ以外のデータにアクセスしたい場合は、実際のユーザーまたは別のアカウントに対してブルートフォース攻撃のログオン資格情報を試すことができます。 （理論的には、各アカウントを特定のリモートクライアントIPにロックダウンすることができます。これは、リスクを区分化するのにも役立ちます。）
- 攻撃者が実際のユーザーの有効なキーを取得した場合、攻撃者はログオン画面（おそらく安全であるために十分に単純です）を通り過ぎて、潜在的にバグのあるアプリコードのソフトアンダーベリーに到達します。実際のユーザーのコンテキストからのSQLインジェクションが成功すると、他のクライアントデータにもアクセスできるようになります。
それでは、サーバー側の暗号化がこれらの状況にどのように適用されるかについて説明しましょう。
- サーバー側の暗号化は、SQLインジェクションの脅威に対して確実に役立ちます。行の値がDBテーブルで暗号化されている場合、攻撃者は他のアカウントに属するデータの意味不明な暗号文しか見ることができません。脅威は封じ込められ、区分化されています。
- ただし、ブルートフォースパスワードの推測は、サーバー側の暗号化に直面している攻撃者にとってはそれほど難しくありません。ユーザーのキーがサーバーに保存されているか、パスワードからその場で生成されているかに関係なく、重要なのは、正しいパスワードを持っているかどうかだけです。サーバーは、パスワードが正しいことを確認するために有効な保存済みキーの使用を許可するか、パスワードがそのキーを生成するための正しい入力であるために有効なキーを計算します。
一方、クライアント側の暗号化では、ブルートフォースパスワード攻撃は実際には無関係になります。適切に構築されたキーをブルートフォースすることはできません。クライアント側の暗号化は、サーバー側の暗号化と基本的に同じレベルのSQLインジェクションに対する保護を維持します。クライアントはログオン時にキーをサーバーに渡すことができ、セッションが終了するまでコピーをメモリに保持します。これにより、サーバーに暗号CPUの負担がかかります。または、クライアントはブラウザで暗号化/復号化を単独で処理できます。両方の手法には浮き沈みがあります。
- そのキーをサーバーに渡すことは、コーディングと管理がはるかに簡単であり、通常、より最適化された暗号コード（おそらくコンパイルされたC）のためにはるかに高速です。
- 純粋なクライアント側のアプローチでは、攻撃者がサーバーをルートにしたとしても、暗号化されたデータを読み取ることができず、データを読み取ることができないため、セキュリティが強化されます。考えられる唯一の攻撃経路は、リモートクライアントワークステーションを危険にさらすことです。
最後に、データベース内のデータを暗号化することには、運用上の大きな欠点があることに注意してください。暗号化されたデータ表現は本質的にランダムなパターンであるため、インデックス作成、結合などの基本的なデータベース機能は機能しません。クライアントは大きな論理的負担を負い、データベース機能が通常もたらす多くの利点を失う可能性があります。
あなたはスキュタレーを使うことができます。これは、最新のDBMSおよびWebアプリケーション用のNoSQL暗号プロキシです。複数の受信者とグループの暗号化をサポートします。強力なRSA/AES暗号システムを搭載。また、100％無料でオープンソースです。
ezNcrypt を確認することをお勧めします。これは、ecryptfs、アクセス制御、およびキー管理を使用して、MySQLデータベースおよびその他のプロセスのLinux暗号化に高いセキュリティとパフォーマンスを提供します。いいえ、私は彼らのために働いていません。