DMZにサーバーを配置するvsファイアウォールポートを開く
DMZ vs.ファイアウォールのポートを開いてネットワーク内に維持する場合、いつサーバーを配置する必要がありますか？私はActive Directoryサーバーを参照していますIISサーバー、そしてほとんどがWindowsベースのセットアップに関するものです。
DMZに配置することで気付いたいくつかの問題は、ドメインに存在しないこと、内部サーバーへのネームサーバーアクセス権がないこと、およびその他いくつかの奇妙なことです。一緒に働きます。
DMZに配置されたサーバーは、（DMZの定義により）ファイアウォールが途中にあるため、ネットワークへの接続を開くことができません。そのため、ネットワークは保護されますit、攻撃者によって侵害された場合：このシナリオでは、侵害されたサーバーは、残りのサーバーに対して新しい攻撃を開始するための開始点として使用できませんでしたこれは、サーバーがネットワーク内に配置されており、ファイアウォールポートを開いて、外部ユーザーが提供するサービスを使用してサーバーにアクセスできるようにする場合には当てはまりません。同じ成功した外部攻撃（Webサイトに対するFE）により、サーバーが十分に保護されたDMZまたはLAN内にある場合、非常に異なる結果になります。
つまり、サーバーをDMZに配置することは、サーバーと内部ネットワーク間のトラフィックを実際にフィルタリングできる場合にのみ非常に役立ちます。認証にドメインコントローラーのアクセスが必要で、バック（Exchange CASのような）メッセージを送信するためのデータおよびメールアクセスを終了し、それが内部サーバーとの間のすべてのポートを開いて実際に何かを実行する必要がある場合、実際にはそれほど重要ではありません。ドメインメンバーサーバーは、ここで最悪の違反者です。ドメインアクセスには、コンピューターとそのドメインコントローラーの間に非常に多くの開いているポートが必要です。それらと同じネットワーク;そして侵害されたドメインメンバーコンピューターはbigドメインの多くのものにアクセスできるため、セキュリティ上の問題です。
Windowsサーバーの経験則：ドメインメンバーにする必要がある場合は、DMZはA）正しく配置するのに苦労し、B）ほとんど役に立たない。それらをLANに保持しますが、完全にパッチを適用し、適切なウイルス対策を実行し、十分にロックダウンされた外部ファイアウォールで保護するようにしてください。ここでの最良のアプローチは、リバースプロキシ、インバウンドメールリレー、またはアプリケーションゲートウェイとして機能できるその他のものを使用し、それらを直接インターネットに公開しないことです。
経験則として、開いたサービスを介してサーバーが危険にさらされた場合に発生する可能性のある損害を考慮することです。各デバイスについて2つの要素を検討する必要があります。リスクレベル（「これが危険にさらされる可能性はどのくらいありますか？」-この指標は、サービスがインターネットに公開されるとすぐに上がるはずです）と感度レベル（「方法このシステムが危険にさらされた場合、多くの損失が発生しますか？重要/機密データはありますか？」）。
高リスクのシステムでは、システムの感度をできるだけ低く保つように努力する必要があります。これが、DMZを構築する理由です。
DMZ=の概念は、リスクの高いシステムを分離することです。そのため、攻撃者は、非常に機密性の高いシステムにアクセスするために、追加のセキュリティ層（別のファイアウォール）に侵入する必要があります。 DMZと内部ネットワークとの間にいくつかの接続が必要ですが、内部ネットワークへの受信接続を許可する代わりに、データを外部にDMZにプッシュします。
内部ネットワークへのポートを開いたときにサーバーが危険にさらされた場合、攻撃者は内部システムへの攻撃を実行する、またはより簡単な方法を使用できる可能性があります。今日の世界では、DMZで展開する予定のシステムのほとんどは、内部/ DMZネットワークの区別を実行するように調整および構成できます。実際には、唯一のトラフィックの流れ方は、内部ネットワークからDMZへ、つまり、内部サーバーがDMZ内のサーバーへの接続を開くことです。