SSL暗号化データベース接続はいつ適切ですか？
設定したWebサーバーとデータベースサーバーがあるとします。
ただし、ローカルで通信しており、ファイアウォールの背後にあります。私の意見では、SSLは必要ありません。
SSLを使用してデータベース接続を暗号化する唯一の時間は、別の場所にあるデータベースサーバーとリモートで通信するサーバーに存在するWebサーバー間です。
データベース接続をSSLで保護することを提唱する前に、セキュリティのガイドラインを見てきましたが、それをいつ使用するかは曖昧でした。
この質問に対する以前の2つの回答では、SSLをオンにすることをお勧めしますが、別の推論角度を提案したいと思います（ただし、SSLをオンにしないことはお勧めしません）。
SSLが必要かどうかを評価する際の2つの重要なポイントは、（a）SSLによって保護されるものと（b）スレッドモデルとは何か、潜在的な脅威を列挙することです。
SSL/TLSは、クライアント（この場合はWebサーバー）とサーバー（この場合はデータベースサーバー）の間の情報の転送を、その間のネットワーク上の誰かによる改ざんや盗聴（それらに乗ることもできる）から保護します2台のマシン）。
SSLが有用かどうかを評価するには、攻撃者が攻撃を実行する立場にあると想定する必要があります。つまり、攻撃者はネットワーク上またはいずれかのマシン上でパケットを傍受することができる必要があります。
データベースサーバーからのパケットを傍受する立場にある誰かが、そのサーバーへのroot/adminアクセス権を持っている可能性があります。その段階でSSL/TLSを使用しても違いはありません。
Webサーバーとデータベースサーバー（これらのマシンを除く）の間のネットワーク上のパケットを傍受する立場にある場合、SSL/TLSを使用すると、アプリケーションのコンテンツを表示/変更できなくなります。 これが可能である可能性があると思われる場合は、SSLをオンにしてください。これを軽減する方法は、Webサーバーで2つのネットワークカードを使用することです。1つは外部に、もう1つはDBサーバーが存在する内部LANに（他のマシンがない場合、またはそれらをすべてとして扱うことができる方法で）です。単一の大きなマシン）。全体的なWebファームまたはクラスターを形成しているこのネットワークは、物理的に分離されており、外部からのエントリポイントは1つだけです。つまり、Webサーバー自体（リバースプロキシヘッドノードと同じ原理）です。
ヘッドノード（Webサーバー）自体でパケットを盗聴する立場にある場合、そのユーザーはそこにルートアクセス権を持っている可能性があります（マシンの非ルートユーザーが実行するプロセスは、パケットを読み取ることができません。彼らのためではありません）。この場合、とにかく大きな問題が発生します。
ここで私が疑っているのは、SSLを有効にすると、このシナリオで実際に多くのことが保護されるかどうかです。
Webサーバーでrootアクセス権を持つユーザーは、DBパスワードを含むアプリケーション構成を読み取ることができ、SSLを使用していても、DBサーバーに合法的に接続できるはずです。
逆に、これがSSLの使用を保証するものであると想定した場合（マシンにrootの制御権がある場合でも、ネットワークを見るだけでなく、プロセスが実際に何をしているかを調べることは難しいため）、これは意味します。ローカルホスト通信を有効にすることもできます（たとえば、Webサーバーに他のサービスがある場合、またはDBサーバーとWebサーバーの両方が同じマシン上にある場合）。
慎重すぎるのは必ずしも悪いことではありませんが、セキュリティ対策（SSL）によって保護されているものに対して攻撃を実行する立場にある場合、攻撃者が何をすることもできるという状況で質問をする必要があります。そして、このセキュリティ対策が、いったんこの位置にいたら、彼らがとにかく目標を達成することを妨げるかどうか。
ウィンドウは実際にはかなり狭いと思います（バックエンドネットワークが、いくつかのマシン間のファイアウォールによってだけでなく、物理的に安全に保護されていると想定しています）。
データベースサーバーとクライアントを含むローカルネットワークに他のプロセスが含まれている可能性がある場合は、2つの間の接続を暗号化する必要があります。
これはほとんどの場合に当てはまります。ローカルネットワークが侵入不可能であると想定しても（そうすべきではありません）、データベースクライアントとサーバーの他に、通常、
- ログインして問題を修正または更新できる必要がある管理者
- 機密データなしでファイルを取得して別の場所に移動する必要があるログコレクター
- オフサイトバックアップのためにデータベースのコンテンツをコピーする必要がある、またはデータマイニングシステムに大規模な低感度テーブルをフィードする必要があるレプリケーター
- 他がまだ生きているかどうかを確認する必要があるモニター
これらのうち、機密データを含むテーブルにアクセスする必要があるのはレプリケーターだけですが、これらのプロセスはすべて、IT部門内の悪意のある人物によって侵害される可能性があります。
機密データを伝送するすべてのチャネルを暗号化すると、正直な人々を正直に保ち、防御を深め、問題が発生したときに検索を絞り込むことができます。
サーバーと同じネットワーク上にいる人はだれでも、トラフィックを傍受したり、中間者攻撃を実行したりできる可能性があることに注意してください。 SSLは、適切に設定されていれば、これを防ぐはずです。また、データベースサーバーにファイアウォールを設定し、信頼できるIPアドレスからの接続のみを許可する必要があります。
私の提案は、それをオンにしてからオフにすることです次の場合のみパフォーマンス（またはその他の）問題を引き起こしていると思われます。これにより、攻撃ベクトルを大幅に削減できます。
実際には、ネットワークを介したSSL暗号化のオーバーヘッドは、特にSQLクエリの処理の負荷と比較すると、最小限になります。 SSLを無効にするよりも、クエリとサーバーのパフォーマンス構成を最適化する方がパフォーマンスが向上します。
設定したWebサーバーとデータベースサーバーがあるとします。ローカルで通信していて、ファイアウォールの背後にいます。
このアーキテクチャが可用性の点で問題があるという事実は別として...
- 「ファイアウォールの背後にある」すべての人とすべてを信頼していますか？
- ファイアウォールは完璧だと思いますか？
- より高い可用性をサポートしたり、データセンターを移行したり、バックアップを実行したりするためにリモートで接続する必要がなくなると予測できますか？
- dbmsのデフォルトの認証メカニズムは、破壊されないように安全ですか？
- データベースの資格情報が危険にさらされないようにする導入プロセスはありますか？
これらのいずれかに対する答えが明確な「はい」でない場合は、適切に構成されたSSL接続を使用することによる追加の保証の恩恵を受ける可能性があります。永続的な接続に依存していなくても、パフォーマンスコストはごくわずかです（ただし、永続的なトンネルを介してトラフィックをルーティングすることで、これはほとんど解消できます）。 SSLを構成するコスト（数時間の作業）が責任よりも大きい場合は、単純に解決することになります。