MySQL暗号化とキー管理


10

クライアントデータを管理するために、PHP / MySQLでローカルイントラネットシステムを開発しています。入力中のMySQLサーバー上の機密データを暗号化することをお勧めします。

ただし、データに容易にアクセスできる状態でこれを行うための最良の方法は何なのかはわかりません。

答えるのは難しい質問のようです:キーはどこに保存されていますか?鍵を最もよく保護する方法は?キーが各ユーザーのマシンに保存されている場合、マシンが悪用された場合にそれを保護するにはどうすればよいですか?キーが悪用された場合、キーを変更するにはどうすればよいですか?

キーをDBに保存する場合、それをどのように保護しますか?ユーザーはどのようにアクセスしますか?


暗号化とキーストレージの種類は、防止するシナリオの種類によって異なります。明らかに、攻撃者がサーバーでrootユーザーまたはアプリユーザーを取得した場合、攻撃者は同じルーチンを使用して、アプリケーションが使用するのと同じように復号化できます。では、どのようなシナリオを避けたいですか?誰かがバックアップを盗んでいますか?SQLインジェクション攻撃?他に何か?
Aleksandar

返信いただきありがとうございます!バックアップについてはそれほど心配していません。私は、誰かがユーザーのマシンを悪用し、そこからSQLインジェクションを介してサイトにアクセスするか、ユーザーのアプリケーションの資格情報を破壊することについて、より心配しています。マシン自体についてはあまり気にしていません。suの認証情報は非常に強力です(ただし、100%安全であるという幻想はありません)。
暴風雨

回答:


9

高度な暗号化されたキー設定を処理するための組み込みのMySQL機能は実際にはありません。暗号化ロジックの大部分を独自のPHPおよび/またはブラウザー側(javascript?)コードに実装する必要があります。

しかし、あなたが述べた懸念は少し独特です:あなたの唯一の本当の懸念は、リモートクライアントのデスクトップ/ラップトップワークステーションからのSQLインジェクションまたはブルートフォース(パスワード推測)攻撃だと思われます。これにより、言及されていない他のセキュリティ対策がすでに計画されており、侵害の可能性のある手段を分析したと思われます。

  • たとえば、承認されていないリモートクライアントIPからのあらゆる種類のアクセスからMySQL / PHPホストを保護するファイアウォールルールがあるとします。私が正しければ、侵害されたユーザーのワークステーションからの攻撃についてのみ心配しているのは理にかなっています。

  • また、リモートクライアントホストの攻撃者がroot / Admin権限に昇格したり、実際のユーザー自身のアカウントを直接侵害したりできる場合、暗号化やその他の保護手段に関係なく、そのクライアントのデータは保護されないことを理解していると思います。(攻撃者は、ディスクに保存されている任意の場所からキーを読み取るか、ログオン時に実際のユーザーがキーを入力するとキーをスヌープし、キーがデータにつながる可能性があります。)

これらの2つの仮定から始めて、関連する脅威は、A)ブルートフォースパスワードの推測、およびB)SQLインジェクションの試みの2つだけであると結論付けるのは理にかなっています。

  • 攻撃者が実際のユーザーのキーを把握していない場合、または実際のユーザーのデータ以外にもアクセスしたい場合は、攻撃者は実際のユーザーまたは別のアカウントに対して総当たりのログオン資格情報を試すことができます。(理論的には、各アカウントを特定のリモートクライアントIPにロックダウンすることもできます。これは、リスクを区分するのにも役立ちます。)
  • 攻撃者が実際のユーザーの有効なキーを取得した場合、攻撃者はログオン画面(おそらくセキュリティで保護するのに十分簡単なもの)を通り過ぎて、バグのある可能性のあるアプリコードのやわらかい腹をたどります。実際のユーザーのコンテキストからSQLインジェクションが成功すると、他のクライアントデータへのアクセスも可能になります。

次に、サーバー側の暗号化がこれらの状況にどのように適用されるかについて話しましょう。

  • サーバー側の暗号化は、SQLインジェクションの脅威に対して確実に役立ちます。行の値がDBテーブルで暗号化されている場合、攻撃者は他のアカウントに属するデータの意味不明な暗号文しか見ることができません。脅威は隔離され、封じ込められています。
  • ただし、ブルートフォースによるパスワードの推測は、サーバー側の暗号化に直面している攻撃者にとって実際には難しくありません。ユーザーのキーがサーバーに保存されているか、パスワードからその場で生成されているかに関係なく、重要なことは、正しいパスワードを持っているかどうかだけです。サーバーは、パスワードが正しいことを確認するために有効な格納されたキーを使用することを許可するか、パスワードがそのキーを生成するための正しい入力であるために有効なキーを計算します。

一方、クライアント側の暗号化は、ブルートフォースパスワード攻撃を実際には無関係にします。適切に構築されたキーを総当たりにすることはできません。クライアント側の暗号化でも、SQLインジェクションに対する保護はサーバー側の暗号化と基本的に同じです。クライアントはログオン時にサーバーにキーを渡し、セッションが終了するまでコピーをメモリに保持します。これにより、サーバーに暗号化CPUの負荷がかかります。または、クライアントはブラウザで暗号化/復号化を単独で処理できます。どちらの手法にも、浮き沈みがあります。

  • そのキーをサーバーに渡すと、コーディングと管理がはるかに簡単になり、最適化された暗号コード(おそらくコンパイルされたC)のため、通常ははるかに高速になります。
  • 純粋なクライアント側のアプローチでは、セキュリティがさらに強化されます。攻撃者がサーバーでrootになったとしても、暗号化されたデータを読み取ることはできず、読み取ることはできません。考えられる唯一の攻撃方法は、リモートクライアントワークステーションを危険にさらすことです。

最後に、データベース内のデータを暗号化することには、運用上の大きな欠点があることにも触れておきます。暗号化されたデータ表現は基本的にランダムなパターンであるため、インデックス付け、結合などの基本的なデータベース機能は機能しません。クライアントは大きなロジックの負担を引き受け、データベース機能が通常もたらす多くの利点を失う可能性があります。


1
うわー!驚くほど完全な答え。どうもありがとうございました。過去数日間、私はいくつかのオプションを検討してきましたが、あなたが提案したようにクライアント側のソリューションを試して実装することにしました。理想的には、ユーザーがシステムで作業している間(物理的なセキュリティは非常に厳しい)にのみマウントされるサムドライブにキーが保存され、セッションが存続する間だけキーがメモリに保持されます。私は、モニターのトラフィックに存在していたときにキーが唯一の勤務時間中のシステムにアクセスできるようになりますということでアイデアなど
stormdrain

2

MySQLデータベースおよびその他のプロセスのLinux暗号化に高いセキュリティとパフォーマンスを提供するためにecryptfs、アクセス制御、およびキー管理を使用するezNcryptを確認することをお勧めします。いいえ、私は彼らのために働きません。


2

Scytaleを使用できます。これは、最新のDBMSおよびWebアプリケーション用のNoSQL暗号プロキシです。複数の受信者およびグループの暗号化をサポートします。強力なRSA / AES暗号システムを搭載。また、100%無料でオープンソースです。

https://bitbucket.org/maximelabelle/scytale

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.