ユーザー向けのWebアプリケーションをリリースしようとしていますが、他のユーザーがサーバーをDMZに配置するのか、それともファイアウォールの背後にあるドメインから遠ざけてファイアウォールルールを介してアクセスを大幅に制限するのかを把握しようとしています。ここで誰かがファイアウォールルールとO/Sパーマを介してアクセスを制限することの短所を見つけましたか?
このサイトは、SQLServerバックエンドを備えたASP.NETMVCフロントエンドであることに注意してください。
また-これはHR/Financeアプリケーションであり、データベースバックエンドには最も価値のあるデータが含まれています。セキュリティの観点から、データベースサーバーへのアクセスを許可するよりも、イントラネットへのルートアクセスをワールドに許可したいと思います。その結果、私の当初の計画では、DMZを使用せずに、ファイアウォールのポート443のみをWebサーバーに開くことでした...これは、dbサーバーを=に配置するよりも悪くはないようです。 DMZ Webサーバーを使用。
通常、構成は次のようになります。
Internet facing servers connected to Firewall's DMZ Port
Trusted servers (SQL, AD, etc) connected to Firewall's Trusted/LAN Port
Internet connected to Firewall's WAN port
次に、ファイアウォールはこれらのサブネット間をルーティングするように構成され、定義したACLに従ってアクセスを許可します。
私は通常DMZを使用せず、ファイアウォールのみを使用します。 IISアプリケーションプールが実行されているアカウントは、すでに制限されています。
あなたが求めているのは、ベストプラクティスは何ですか?
物がどこに置かれているかは関係ありません。つまり、どのように保護したか。
1つのファイアウォールルールですべてを開いたり、閉じたりすることができます。多分あなたはそれを別の視点から見る必要があります。
ファイアウォールがサーバー間のアクセスを制限することなく、これらのサーバーに直接アクセスできるほど従業員を信頼していますか。インターネットについても同じことが言えます。その場合は、両方をDMZに入れてください。
個人的には、最大のパフォーマンスを保証するため、ファイアウォールのない同じサブネット上でそれらが好きです。ただし、Webサーバーが侵害された場合は、安全なLAN側にある場合よりもDBサーバーが開いたままになります。他のサービスは、RDPのようにLAN側からDBサーバーで利用できる必要がありますか?設置場所によっては、LANからDMZ)までポートを開いてアクセスなどを許可する必要がある場合があります。
黄金律:インターネットからアクセスでき、そうしない実際的な理由がない場合は、DMZに入れてください。マシンが危険にさらされた場合、内部ネットワークに到達できないようにする必要があるという考えです。事実上、それは一種の二重ファイアウォールのようなものです。