顧客情報を含むデータベースはDMZに入れる必要がありますか？
DMZ社のスタンドアロンLAMPプラットフォームにシンプルなニュースレターWebアプリを展開しています。 MySQLサーバーをDMZ）から削除して、内部ネットワークに配置する必要があるかどうかについては、いくつかの議論があります。
サーバーはファイアウォールの背後にあり、ポート80のみが開いており、MySqlは非標準のポートに接続されます。データベースには、顧客の電子メールアドレスが含まれています。
これは安全な設定ですか（または十分に安全ですか）？データを2番目のファイアウォールの背後に配置することで、どれだけ安全になりますか？ （私は開発者なので、ここでのセキュリティのすべての側面を実際に認識しているわけではありません。誰かが私を教えてくれますか？）
更新明確にするため、およびコメントを追加するために、現在の設定は次のとおりです。
インターネット-ファイアウォール1-httpサーバー-ファイアウォール2-アプリサーバー-ファイアウォール3-エンタープライズリソース
この新しいアプリケーションは、ファイアウォール1と2の間のDMZ内に完全に入るはずでした。現在、MySQLサーバーを2番目のファイアウォールの背後にプルすることについて議論しています。
DMZから内部LANへの接続を許可することは、DMZの概念を破っています。
MySQLをローカルホストにバインドすることは、MySQLを他の場所に配置することと同じくらい安全です。データの盗難が懸念される場合は、2台のマシンが分割され、Apache部分が侵害されたと想定する必要があります。侵害されたマシンに保存されているMySQL接続の詳細は、攻撃者がデータを読み取るために再利用する可能性があります。
編集して追加：
あなたが説明するようにダブルホップDMZであっても、サービスを分離することによる実際のセキュリティ上の利点を購入することはありませんが、同時にセットアップがより複雑になります。おそらくより多くのマシンを持ち、ループバックにあるはずのデータをネットワーク経由で送信することで、攻撃対象領域をさらに増やします。
DBを内部ネットワーク（2番目のファイアウォールの後ろ）に配置します。
これにより、2番目のファイアウォール（DMZを内部）のファイアウォールルールをWebサーバーからのポートXXXX（DBポート）での接続のみを許可するように設定するため、DBの攻撃対象領域が大幅に減少します。
したがって、DMZが侵害された場合でも、DBは保護されます。
2つのシナリオを評価して、どちらが優れているかを見てみましょう。アプリケーションに固有のテーブルへの読み取り/書き込みアクセスのみを持つようにMySQLアカウントを構成したと思います。
ゼロデイエクスプロイトを使用してWebサーバーを攻撃します。これで、管理者がWebサーバーにアクセスできるようになり、ローカルファイルシステムに完全にアクセスできるようになりました。このウェブサーバーから発信されたネットワーク通信を送信することもできます。アプリケーションデータベースにアクセスするために必要な資格情報にアクセスできました。
データベースサーバーが同じマシン上にある場合、データベースに直接完全にアクセスできるようになりました。データベース内のすべてのテーブルの読み取りと書き込み、新しいテーブルの作成、およびこのデータベースサーバーとの他のすべての通信のリッスンを行うことができます。 評価：これは最悪のシナリオです。アプリケーションデータベースと他のすべてのデータベースが影響を受けます。
データベースサーバーが同じDMZ内の別のマシン上にある場合、データベースサーバーと完全に通信できます。これで、Windowsファイル共有サービスのエクスプロイトを使用して、このサーバーへの管理者アクセスを取得できます。 評価：Webアプリケーションアカウントを使用してデータベースサーバーにアクセスできますが、権限が制限される場合があります。データベースサーバーへのフルアクセスを取得するには、別のエクスプロイトが必要です。データベースで利用可能な任意のサービスを悪用できます。サーバー。
データベースサーバーがまったく別のネットワークにある場合、データベースポートにしかアクセスできません。その他の通信はファイアウォールによってフィルタリングされます。つまり、データベースプログラムでエクスプロイトを使用して、管理者アクセスを取得することしかできません。管理者アクセスを取得すると、内部ネットワーク全体が危険にさらされます。 評価：Webアプリケーションアカウントを使用してデータベースサーバーにアクセスできますが、権限が制限される場合があります。データベースポートを悪用してフルアクセスを取得することしかできません。これを行うと、データベースのネットワークが切断されます。危険にさらされています。
MySQLの部分は十分にカバーされていると思いますし、すでに言われていることに確かに同意します。最初のステップとして、世界のあなたの地域での法的要件はかなり異なるので、それらを見つける必要があることを指摘したいと思います。おそらくそれがあなたの構成を決定するでしょう。
DBサーバーは、外部のインターネット接続からファイアウォールで保護する必要があります。これにより、アプリサーバー（および管理に必要なもの）のみがデータベースに接続できます。アプリサーバーから分離されている場合（これを行うにはさまざまな理由があります）、ファイアウォールとセキュリティを適切に設定します。
アプリケーションサーバーを危険にさらすと、DB攻撃者がアプリケーションのログイン資格情報を利用できるようになる可能性が高いため、ある程度のDBまたはアプリケーションレベルのセキュリティが役立つ場合があります。たとえば、次のような責任の分離を行うことができます。
アプリケーションが顧客データを直接読み取ることはできないが、ストアドプロシージャを実行する必要があるように、DBオブジェクトの所有権を設定します。完全なクレジットカード番号は書き込みのみである可能性があります-sprocはそれらを更新することを許可できますが、「更新の詳細」画面の最後の4桁のみを読み取ります。 CC番号が必要なものはすべて、別のサーバーに存在し、別のアカウントを介して接続する可能性があります。
財務が物理的に異なるサーバーで管理されている場合（おそらくパブリックインターネットからファイアウォールで保護されている場合）、実際にサーバーを危険にさらすことなく、せいぜい偽の注文などを発行できます。クレジットカード情報を取得するには、2台のマシン（アプリサーバーとDBサーバーまたは財務サーバーのいずれか）を危険にさらす必要があります。また、侵害されたWebサーバーから攻撃を開始する必要があります。これにより、攻撃者は両方のマシンを同時に侵害できないため、アクティビティを検出するためのウィンドウが長くなります。
DBおよび財務サーバーマシンには、Webサーバーとの非常に特殊な一連の相互作用もあります。これにより、アプリに関連しないアクティビティのすべてではないにしてもほとんどが疑わしいと想定し、これらのマシンに超妄想的な構成でIDSを設定できます。
DMZから内部ネットワークへのトラフィックを許可しないでください。これは本当に悪い考えです！誰かがあなたのWebアプリのdmzを制御する可能性がある場合は、接続を開くことができます。内部ネットワーク内のサーバーに接続し、ネットワーク全体を完全に制御します。Webアプリをネットワークから分離する場合は、別のDMZを作成し、そこにDBを配置することをお勧めします。唯一のあなたのウェブサーバーから他のDMZ iへのトラフィックを許可しました。私はいくつかのひどいファイアウォール設計を見ました、そしてこれはそれらの1つです。
HåkanWintherシニアDBAおよびセキュリティ会社の元オーナー。
マシンが危険にさらされている場合、MySQLサーバーがDMZにあるかどうかは関係ありません。MySQLデータベースにアクセスするための資格情報は、Webアプリコードのどこかにあり、マシンはDMZはそれにアクセスできる必要があるため、この場合、ファイアウォールはデータを安全に保ちません。
より良い設計は、Webアプリにキューを書き込ませ、それを保護されたネットワーク内のMySQLデータベースにプルすることです。これにより、顧客データの公開がキューにあるものに制限されます。ここで大声で考えているだけです。これは、特定のアプリでは機能しないか、実用的でない場合があります。