DMZに1つのWebサーバーに穴を開けることはどれほど大きな問題ですか？

現在、WebサーバーはDMZにあります。Webサーバーは内部ネットワーク内では何も見ることができませんが、内部ネットワークはWebサーバーを見ることができます。DMZと内部ネットワークの間のファイアウォールの穴をイントラネット内の1つのWebサーバーのみにパンチすることはどれくらい安全ですか？私たちはいくつかのバックオフィスアプリケーション（すべて1つのサーバー上にある）とインターフェイスすることに取り組んでおり、このデータを保持しているIBM iサーバーと直接通信できれば、このプロジェクトを実行するのがはるかに簡単になります（ Webサービス経由）。

私の理解から（そして私はブランドを知りません）、私たちは別のファイアウォールを持つプライマリIPとは異なる外部IPを持つDMZのための1つのファイアウォールを持っています。別のファイアウォールは、Webサーバーとイントラネットの間にあります。

だから次のようなもの：

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

意図した結果を達成するために必要な場合、DMZ内のホストが保護されたネットワーク内のホストにアクセスするためのアクセスメカニズムを作成しても何も問題はありません。おそらく、そうすることは望ましくありませんが、時にはそれが仕事を成し遂げる唯一の方法です。

重要な考慮事項は次のとおりです。

• 可能な限り最も具体的なファイアウォールルールへのアクセスを制限します。可能であれば、使用される特定のプロトコル（TCPおよび/またはUDPポート）とともに、ルールに関係する特定のホストに名前を付けます。基本的に、必要なだけ小さな穴を開けてください。

• DMZホストから保護されたネットワーク上のホストへのアクセスをログに記録していることを確認し、可能であれば、それらのログを自動化して異常を分析します。異常なことがいつ起こるかを知りたい。

• 間接的な方法であっても、内部ホストをインターネットに公開していることを認識してください。公開しているソフトウェアとホストのオペレーティングシステムソフトウェア自体のパッチと更新を常に把握してください。

• アプリケーションアーキテクチャで実現可能な場合は、DMZホストと内部ホスト間の相互認証を検討してください。内部ホストに送信されるリクエストは、実際にはDMZホストから送信されていることを知っておくと便利です。これを実行できるかどうかは、アプリケーションアーキテクチャに大きく依存します。また、DMZホストを「所有する」誰かが、認証が発生している場合でも（事実上、DMZホストになるため）内部ホストに要求を行うことができることに留意してください。

• DoS攻撃について懸念がある場合は、DMZホストが内部ホストのリソースを使い果たすのを防ぐためにレート制限の使用を検討してください。

• レイヤー7「ファイアウォール」アプローチの使用を検討することをお勧めします。DMZホストからのリクエストは、まずリクエストを「サニタイズ」し、それらをサニティチェックし、次に渡すことができる専用の内部ホストに渡されます。 「実際の」バックエンドホスト。IBM iSeriesのバックオフィスアプリケーションとのインターフェースについて話しているので、iSeries自体の着信要求に対して健全性チェックを実行する機能が制限されていると思います。

体系的な方法でこれにアプローチし、それについてある程度の常識を維持する場合、リスクを最小限に抑えながら、説明していることを実行できない理由はありません。

率直に言って、保護されたネットワークへの自由なアクセスを持たないDMZを持っていることは、私が見た多くのネットワークを超えて飛躍することを可能にします。一部の人々にとっては、DMZは「ファイアウォール上の別のインターフェースであり、RFC 1918アドレスがいくつかあり、基本的にインターネットおよび保護されたネットワークへの自由なアクセス」を意味するようです。ビジネス目標を達成しながらDMZをできる限りロックダウンしてみてください。そうすればうまくいきます。

明らかにいくつかの危険がありますが、あなたはそれを行うことができます。基本的には、誰かが通り抜けることができるピンホールを開いているので、小さくします。両端のサーバーのみに制限し、選択したポートのデータのみを許可します。奇妙なポートを使用するためにポートアドレス変換を使用するのは悪くありません。それでも、あいまいさによるセキュリティはまったくセキュリティではありません。反対側のサーバーがなんであれ、その接続を通過する情報が実際に見えるものであることを確認する何らかの方法を持っていることを確認するか、少なくとも何らかのコンテキスト認識ファイアウォールを設置してください。また、この種のもののために作られた特定のファイアウォールがあります... Microsoft ISAはOWAとExchangeサーバーに対してこれと同じことを行うことを知っています。