【図解】DMZとは何か?ネットワークの要塞を守るセグメント分割の鉄則と設計パターン

企業や組織のネットワークセキュリティを語る上で、避けては通れないキーワードがあります。それがDMZ（DeMilitarized Zone：非武装地帯）です。

「WebサーバーはDMZに置く」「社内LANからインターネットへの接続はプロキシを経由する」

このようなフレーズを耳にしたことがある方は多いでしょう。しかし、なぜそのような構成が必要なのか、具体的にどのような通信が許可され、何が拒否されるべきなのか、その設計思想まで深く理解できているでしょうか？

情報処理安全確保支援士試験（SC）においても、DMZの知識は必須です。午後試験の記述問題では、ネットワーク構成図を見て「ファイアウォールの設定ミス」や「サーバーの配置ミス」を指摘させる問題が頻出します。ここで曖昧な理解のままだと、正解に辿り着くことはできません。

本記事では、DMZの基本的な役割から、ファイアウォールを用いたセグメント分割の具体的な手法、そしてWeb・メール・DNSといった主要サービスの配置パターンまでを徹底的に解説します。単なる用語の暗記ではなく、「攻撃者の視点」と「守る側の論理」を理解することで、どのようなネットワーク構成図が出題されても動じない応用力を身につけましょう。

ネットワークセキュリティの基本概念とDMZの役割

「内」と「外」を隔てる緩衝地帯

セキュリティの基本は信頼できる領域と信頼できない領域を明確に分けることから始まります。インターネットは、誰でもアクセスできる一方で、悪意ある攻撃者が潜む「信頼できない領域（Untrusted Zone）」です。対して、社内のPCや重要なデータベースが存在する社内LANは、絶対に守らなければならない「信頼できる領域（Trusted Zone）」です。

もし、社内LANの中にWebサーバーを直接置いて公開してしまったらどうなるでしょうか？外部からのアクセスを社内LANの深くまで許可することになり、万が一そのWebサーバーが乗っ取られた場合、隣接する社員のPCや顧客データベースまで瞬時に侵害されてしまいます。

そこで登場するのがDMZ（非武装地帯）です。DMZは、インターネット（外部）と社内LAN（内部）の間に設けられる、独立した緩衝地帯です。

外部に公開する必要があるサーバー（Webサーバーなど）は、内部ネットワークではなくDMZに配置します。これにより、仮にDMZ内のサーバーが攻撃を受けて侵害されたとしても、ファイアウォールによって遮断されているため、攻撃被害が社内LANへ直接波及することを防ぐことができます。これがDMZの最大の目的である封じ込めの思想です。

2つの主要なファイアウォール構成パターン

DMZを構築するには、ルーターやファイアウォール（FW）の設定が不可欠です。試験でよく問われる構成パターンには、大きく分けて以下の2種類があります。

1. 3脚構成（マルチホーム構成）

1台のファイアウォールに3つのネットワークインターフェース（3脚）を持たせる構成です。

• ポート1：インターネット（Untrust）
• ポート2：DMZ
• ポート3：社内LAN（Trust）

この構成のメリットは、コストが安く済むことです。1台のFWで全ての通信制御を一元管理できるため、小規模〜中規模のネットワークで頻繁に採用されます。しかし、FW自体が単一障害点（SPOF）になるリスクや、設定が複雑になりミスを誘発しやすいというデメリットもあります。

2. 2段構成（サンドイッチ構成）

DMZを挟むように、外側と内側にそれぞれ別のファイアウォールを設置する構成です。

インターネット ⇔ [外部FW] ⇔ DMZ ⇔ [内部FW] ⇔ 社内LAN

この構成はコストがかかりますが、セキュリティ強度は格段に向上します。例えば、外部FWと内部FWで異なるメーカーの製品を採用すれば、特定の製品の脆弱性を突かれたとしても、もう片方のFWで食い止めることができる多層防御が実現します。金融機関や大規模システムでは、この構成が採用されることが多いです。

ファイアウォールのパケットフィルタリング技術

ファイアウォールは、通過するパケットを検査して許可・拒否を判断します。この技術には大きく2つのタイプがあります。

静的パケットフィルタリングは、パケットのヘッダ情報（送信元IP、宛先IP、ポート番号など）のみを見て判断する古典的な手法です。シンプルですが、戻りパケットも明示的にルールで許可する必要があり、設定が煩雑になります。

一方、ステートフルインスペクションは、動的パケットフィルタリングを発展させた方式で、通信のセッション状態を記憶し、行きの通信を許可すれば戻りの通信を自動的に許可する高度な手法です。現代のファイアウォールのほとんどがこの機能を持っています。試験では、どちらの技術が前提になっているかで解答が変わるため、設問の前提条件をよく読む必要があります。

さらに高度な次世代ファイアウォール（NGFW）は、パケットの中身（アプリケーション層）まで検査し、マルウェア検知やアプリケーション制御、侵入防止システム（IPS）の機能を統合しています。単にポート番号で判断するのではなく、「HTTPSの中でどんなアプリケーションが動いているか」まで識別できるため、より精密なセキュリティ制御が可能です。

徹底解説！通信フローとアクセス制御の鉄則

DMZを設計する上で最も重要なのが、誰から誰への通信を許可するかというアクセスコントロールポリシーです。試験では、この通信方向のルールが適切かどうかを判断させる問題が頻出します。ここでは、4つの通信フローについて鉄則を解説します。

1. インターネット → DMZ

原則：公開サービスのみ許可

Web閲覧（HTTP/HTTPS）やメール受信（SMTP）など、外部向けに提供するサービスに必要なポート番号のみを許可します。

• 許可例：宛先ポート80（HTTP）、443（HTTPS）、25（SMTP）
• 拒否すべき通信：SSH（22）やRDP（3389）などの管理用ポート、データベース接続など

ここでのポイントは、必要最小限のポート以外はすべて遮断（Deny All）することです。これは最小権限の原則と呼ばれ、セキュリティ設計の基本中の基本です。

ファイアウォールのルールは、通常「上から順番に評価され、最初にマッチしたルールが適用される」仕組みです。そのため、具体的な許可ルールを先に書き、最後に「それ以外は全て拒否」というデフォルトルールを置くのが定石です。

2. DMZ → 社内LAN

原則：絶対に禁止（例外は最小限に）

これが最も重要なルールです。DMZから社内LANへの通信開始（New Session）は、原則として全て禁止します。なぜなら、DMZ内のサーバーが乗っ取られた場合、ここが開いていると攻撃者が社内LANへ侵入できてしまうからです。

しかし、実務上どうしても通信が必要なケースがあります。例えば、Webサーバー（DMZ）がバックエンドのデータベースサーバー（社内LAN）からデータを取得する場合や、DMZのメール中継サーバーが受信メールを社内のメールサーバーへSMTP（25）で転送する場合です。

この場合も、ファイアウォールで「WebサーバーのIPアドレスから、DBサーバーの特定ポート（例：3306のMySQL）への通信のみ」「メール中継サーバーから内部メールサーバーへのTCP25のみ」のようにピンポイントで許可し、それ以外は厳格にブロックする必要があります。さらに、この通信経路には侵入検知システム（IDS）や侵入防止システム（IPS）を配置し、異常な通信パターンを検知できるようにするのが望ましいです。

試験対策としては、「DMZ起点の内部への通信は悪」という前提を持ちつつ、業務要件上の例外をどう安全に設計するか（IPSの設置やWAFの導入など）を意識してください。

3. 社内LAN → DMZ

原則：管理・更新・利用のために許可

社内の管理者がDMZ上のサーバーにSSHでログインしてメンテナンスを行う場合や、社内からプロキシサーバー（DMZ配置）を経由してWeb閲覧を行う場合などです。

これは「信頼できる領域」から「緩衝地帯」への通信なので、比較的緩やかに許可されますが、それでも管理端末のIPアドレスを制限するなどの対策が推奨されます。具体的には、特定の管理用セグメントからのみSSH接続を許可し、一般社員のPCセグメントからは接続できないようにします。

また、管理用の通信には多要素認証（MFA）を導入し、たとえ認証情報が漏洩しても不正アクセスを防ぎやすくする仕組みが重要です。さらに、操作ログを詳細に記録し、後から監査できるようにすることで、内部犯行や設定ミスを検知できます。

4. 社内LAN → インターネット

原則：直接通信はさせない（プロキシ経由）

セキュリティポリシーの厳しい組織では、社内PCからインターネットへの直接アクセス（NAT経由など）を禁止し、DMZに設置したプロキシサーバーを経由させる構成が一般的です。

これにより、プロキシサーバーでアクセスログを一元管理したり、ウイルスチェックを行ったり、URLフィルタリングで有害サイトへのアクセスを遮断したりすることが可能になります。

さらに、プロキシサーバーはキャッシュ機能を持つため、頻繁にアクセスされるWebページをローカルに保存しておくことで、インターネットへの通信量を削減し、アクセス速度を向上させる効果もあります。

ただし、近年はHTTPSが主流となり、プロキシサーバーで中身を検査するには「SSLインスペクション」という技術が必要になります。これは通信を一旦復号化して検査し、再度暗号化する仕組みですが、プライバシーの観点から慎重な運用が求められます。

主要サーバーの配置戦略とセキュリティ

DMZの設計において、どのサーバーをどこに置くかは戦略的な判断が必要です。代表的なサーバーの配置パターンと、それに伴うセキュリティ上のリスクを見ていきましょう。

Webサーバーとデータベース（Web-DB構成）

最も一般的な構成です。

• Webサーバー： DMZに配置。不特定多数からのアクセスを受け付けます。
• データベース（DB）サーバー： 社内LAN（または、DMZの裏にあるセキュアな別セグメント）に配置。

よくあるミスとして、DBサーバーまでDMZに置いてしまう設計があります。DBには顧客情報などの重要資産が含まれるため、インターネットから直接到達できるセグメントに置くべきではありません。Webサーバーが侵害されたとしても、DBサーバーが内部にあれば、FWでDB接続ポート（例：3306）以外の通信を遮断することで、被害を最小限に抑える多層防御が機能します。

さらに高度な構成では、Webサーバーの前段にWebアプリケーションファイアウォール（WAF）を配置します。WAFは、SQLインジェクションやクロスサイトスクリプティング（XSS）といったWebアプリケーション層の攻撃を検知・防御します。通常のファイアウォールがネットワーク層・トランスポート層（L3-L4）を守るのに対し、WAFはアプリケーション層（L7）を守る専門装置です。

また、DBサーバーへのアクセスには、データベース専用のファイアウォールやアクセス制御リスト（ACL）を設定し、許可された通信パターン以外は全て拒否する（ホワイトリスト方式）設定が推奨されます。

メールサーバー（リレーとメールボックスの分離）

メールシステムは、インターネットからの受信と、社員によるメール閲覧という2つの側面を持ちます。セキュアな構成では、機能を分割して配置します。

• メール中継サーバー（メールゲートウェイ）： DMZに配置。外部からのメール（SMTP）を受け取り、ウイルスチェックやスパム判定を行った後、内部のメールサーバーへ転送します。
• メールボックスサーバー： 社内LANに配置。実際にメールデータを保存するサーバーです。社員はここへアクセス（POP3/IMAP）してメールを読みます。

このように分離することで、重要なメールデータそのものを外部からの直接攻撃のリスクから遠ざけることができます。なお、中継サーバーから内部メールサーバーへの転送（SMTP 25）は、前述のDMZ→社内LANの限定的な例外として、送信元・宛先・ポートを固定して許可します。

メールゲートウェイでは、単なるウイルススキャンだけでなく、サンドボックス技術を用いた高度なマルウェア検知も重要です。サンドボックスとは、添付ファイルを隔離された仮想環境で実際に実行してみて、不審な動作をしないかチェックする技術です。未知のマルウェアや標的型攻撃にも有効です。

また、なりすましメール対策として、SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting, and Conformance）といった送信ドメイン認証技術の実装も欠かせません。これらにより、送信ドメインの詐称を検知し、ドメイン所有者のDMARCポリシーに従って隔離・拒否できます。ただし、似た綴りのドメイン（紛らわしい文字を使ったドメイン）からのメールは認証に通ってしまうため、別途の対策が必要です。

DNSサーバー（スプリットDNS構成）

DNS（ドメインネームシステム）も攻撃対象になりやすいサービスです。外部公開用と社内利用用でDNSを分けるスプリットDNS（分離DNS）が試験の定石です。仕組みの詳細はDNSの仕組みと脅威の記事も参照してください。

• 外部DNS（コンテンツサーバー）： DMZに配置。自社のドメイン名（例：example.co.jp）をIPアドレスに変換し、インターネット上のユーザーを自社のWebサーバーなどへ誘導します。ここには、Web・メールなど公開サーバーのホスト名とグローバルIPアドレス（A/MX/NSレコード等）という、外部に公開してよい情報だけを登録します。再帰問い合わせには応じません。
• 内部DNS： 社内LANに配置。役割は原則として「キャッシュ（再帰）」と「社内ゾーンのコンテンツ」に分けて考えます。キャッシュ（再帰）機能は社内PCからの名前解決要求（Web閲覧など）に応答し、コンテンツ機能は社内サーバー（ADサーバーなど）の名前解決を担当します。社内LANからインターネットへ直接通信させない方針と整合させるため、外部ドメインの名前解決は、内部DNSがDMZのキャッシュDNSなどへフォワード（転送）して行います。小規模環境では1台で兼用することもありますが、試験では役割を分けて考えるのが原則です。

もしDNSを分けず、1台のDNSサーバーですべてを処理してしまうと、ゾーン転送などの攻撃によって社内のサーバー構成（プライベートIPアドレスなど）が外部に漏洩してしまうリスク（内部情報の露見）があります。これを防ぐために、物理的または論理的にDNSを分割するのです。

外部DNSの主な脅威は、DDoS攻撃の標的化と、リフレクタ（反射役）としての悪用です。後者がDNSアンプ攻撃で、DDoS攻撃の一種です。主な対策は、①外部からの再帰問い合わせを受け付けないオープンリゾルバーの廃止（再帰の無効化）、②大量クエリへの応答を制限するResponse Rate Limiting（RRL）の実装です。

DNSキャッシュポイズニングの標的は、外部DNS（権威サーバー）ではなく、問い合わせ結果を保持するキャッシュサーバー（社内の内部DNSなど）です。対策は、キャッシュサーバー側でのソースポートのランダム化と、DNSSEC（DNS Security Extensions）の検証です。外部DNS側は、自社ゾーンにDNSSECの署名を付けておくことで、各地のリゾルバーが偽の応答を見破れるようにします（詳しくはDNSSECの仕組みを参照）。DNSSECはデジタル署名で応答の正当性と完全性を保証する技術です。なお、署名の付加によりDNS応答パケットが大きくなるため、DNSアンプ攻撃の増幅係数を逆に高めてしまう点には注意が必要です。

また、内部DNSを経由した通信を悪用するDNSトンネリングと呼ばれる攻撃手法にも注意が必要です。これは、マルウェアがDNSクエリの中に不正なデータを隠して外部のC&Cサーバーと通信する手法です。通常のファイアウォールではDNS通信（ポート53）を許可しているため、この攻撃を検知するにはDNSトラフィックを監視する専用のセキュリティ製品が有効です。

プロキシサーバー（フォワードプロキシとリバースプロキシ）

プロキシ（代理）サーバーには2つの役割があり、配置場所も重要です。

フォワードプロキシ： 社内LANまたはDMZに配置。社内PCがインターネットへアクセスする際の「身代わり」です。社内PCのIPアドレスを隠蔽し、キャッシュによる高速化や、URLフィルタリングによる有害サイトへのアクセスブロックを行います。

リバースプロキシ： DMZに配置。インターネットからのアクセスを、Webサーバーの「身代わり」として受け取ります。SSL/TLSの復号処理を肩代わりしたり（SSLオフロード）、Webアプリケーションファイアウォール（WAF）の機能を統合したりして、Webサーバーを保護します。

リバースプロキシは、バックエンドに複数のWebサーバーがある場合、それらへの負荷分散（ロードバランシング）も担当します。外部からは1つのIPアドレスに見えますが、裏側では複数のサーバーで処理を分散することで、高可用性とスケーラビリティを実現します。

さらに、リバースプロキシはHTTPフラッドなどのL7（アプリケーション層）攻撃の緩和にも有効です。大量のリクエストが来た際に、一定のレート制限をかけたり、不正なリクエストパターンを検知してブロックしたりすることで、バックエンドのWebサーバーを保護します。ただし、回線を埋め尽くすような大容量型のDDoS攻撃には効果がなく、上流のDDoS対策サービスなどと組み合わせる必要があります。

ネットワーク構成図問題の攻略法：どこを見るべきか？

情報処理安全確保支援士の午後試験において、ネットワーク構成図が出題された際、着目すべき「不審点」や「チェックポイント」を整理します。これを意識するだけで、記述問題の解答精度が飛躍的に上がります。

1. 通信経路のボトルネックとSPOF

構成図を見て、すべてのトラフィックが1箇所のFWやルーターに集中していないかを確認します。もし冗長化（HA構成）されていない場合、可用性の観点から「機器故障時に全サービスが停止するリスク」を指摘できる可能性があります。

高可用性を実現するには、アクティブ/スタンバイ構成またはアクティブ/アクティブ構成でファイアウォールを冗長化します。アクティブ/スタンバイでは、通常は主系のFWが稼働し、障害時に待機系が自動的に切り替わります。アクティブ/アクティブでは、両方のFWが同時に稼働し、負荷を分散します。

また、ネットワーク経路そのものも冗長化が必要です。上流のインターネット接続回線や、スイッチ間の接続が単一経路になっていないか、SPOF（単一障害点）がないかを常にチェックする習慣をつけましょう。

2. 管理用ポートの開放

FWのルール表（ACL）が出題された場合、インターネットからDMZへの許可ルールの中に「SSH（22）」や「Telnet（23）」、「RDP（3389）」が含まれていないか目を凝らしてください。これらが「Any（不特定多数）」に対して開放されている場合、それは明らかなセキュリティホールであり、正解となる指摘事項です。

管理用アクセスは、送信元IPアドレスを限定するか、VPN経由でのみ許可すべきです。具体的には、管理者が使用する拠点のグローバルIPアドレスのみを許可リストに登録し、それ以外からの接続は全て拒否します。

さらに、SSH接続には公開鍵認証を使用し、パスワード認証は無効化することが強く推奨されます。また、デフォルトポート（SSH：22、RDP：3389）を変更することで、自動化された攻撃ツールからの標的になりにくくする対策も有効です。ただし、これは「隠蔽による防御」であり、根本的な対策ではないことに注意が必要です。

3. 戻り通信の許可（ステートフルインスペクション）

現代のFWの多くはステートフルインスペクション（動的パケットフィルタリングを発展させた方式）機能を持っています。これは、行き（Outbound）の通信を許可すれば、それに対する戻り（Inbound）の通信を自動的に許可する機能です。

試験問題で、古いタイプの静的パケットフィルタリングが前提になっている場合、戻りパケット（ACKビットが立ったパケットなど）を明示的に許可するルールが必要かどうか、設問の前提条件をよく読む必要があります。

例えば、「社内LANからインターネットへのHTTP通信を許可する」というルールを静的フィルタリングで実装する場合、以下の2つのルールが必要になります。

• 社内LAN → インターネット：送信元ポート任意、宛先ポート80、プロトコルTCP
• インターネット → 社内LAN：送信元ポート80、宛先ポート1024〜65535（クライアント側の一時ポートを含む範囲）、プロトコルTCP、ACKフラグあり

しかし、ステートフルインスペクションを使用する場合は、最初のルールだけで戻りの通信も自動的に許可されます。静的フィルタリングはACKフラグの有無で判断するため、攻撃者がACKを立てたパケットを偽装すると通り抜けられてしまう限界があります。ステートフルインスペクションなら、実際に開始されたセッションに対応する戻りだけを通せます。試験では、この違いを理解した上で適切な解答を選ぶことが求められます。

4. DMZ内での感染拡大（ラテラルムーブメント）

DMZ内にWebサーバーAとWebサーバーBがあるとします。通常、これら同士が通信する必要はありません。しかし、同じセグメント（同じVLAN）にあるため、互いに通信し放題の設定になっていることが多いです。

高度な問題では、「WebサーバーAが侵害された後、それを踏み台にしてWebサーバーBも攻撃されるリスク」を問われることがあります。これをラテラルムーブメント（横展開攻撃）と呼びます。

対策として、DMZ内であってもサーバーごとにVLANを分け、VLAN間の通信をFWやACLで制御する方法があります。VLANを分けただけでは通信は遮断されず、VLAN間のルーティング点でFWやACLを効かせる必要があります。同一セグメントのままなら、プライベートVLAN（PVLAN）も有効です。さらに、サーバー（ワークロード）単位で通信を制御するマイクロセグメンテーション（ホスト型FWや仮想化基盤の分散FWで実装）も有効な対策です。また、ゼロトラストの考え方では、同じセグメント内であっても「信頼しない」ことを原則とし、すべての通信を認証・認可・暗号化します。

さらに、各サーバーにはホストベースIPS（HIPS）やEDR（Endpoint Detection and Response）を導入し、サーバー内部での不審な動作を検知・ブロックする多層防御が重要です。

5. ログ監視と異常検知の重要性

ファイアウォールのルール設定が完璧でも、運用段階で継続的に監視しなければ、攻撃を見逃してしまいます。SIEM（Security Information and Event Management）システムを導入し、ファイアウォールやサーバーからのログを一元的に収集・分析することが推奨されます。

試験では、「どのようなログを記録すべきか」「どのような異常パターンを検知すべきか」という観点も問われます。例えば、短時間に大量の接続試行がある場合はポートスキャンやブルートフォース攻撃の可能性があり、通常とは異なる時間帯や異常なデータ量の通信があった場合はマルウェア感染の可能性があります。

実践的理解を深める：クラウド時代のDMZ

近年、AWSやAzureなどのクラウド利用が一般的になり、「物理的なDMZ」の概念は「論理的なサブネット」へと変化しています。しかし、設計思想の本質は変わりません。以下はAWSの用語で説明します。Azureでも仮想ネットワーク（VNet）のサブネットとNSG（ネットワークセキュリティグループ）などで同様の分離を行いますが、用語や既定の挙動が異なるため、同一視せずに確認してください。

AWSの場合：パブリックサブネットとプライベートサブネット

AWSでは、VPC（仮想ネットワーク）の中にサブネットを作成します。

• パブリックサブネット： インターネットゲートウェイ（IGW）へのルートを持つサブネット。従来のDMZに相当する役割を担います。ロードバランサー（ALB）や踏み台サーバー（Bastion）を配置します。
• プライベートサブネット： インターネットへの直接ルートを持たないサブネット。従来の社内LANやセキュアゾーンに相当します。Webアプリケーションサーバーやデータベースはここに配置します。

クラウドでは、セキュリティグループやネットワークACLを用いて、インスタンス（ENI）単位やサブネット単位で細かな通信制御が可能です。しかし、「インターネットに直接晒す部分」と「守るべきデータがある部分」を分けるという考え方は、オンプレミス時代と全く同じです。

クラウド特有のセキュリティ機能

クラウドプラットフォームには、オンプレミスにはない独自のセキュリティ機能があります。

AWS WAFやAzure WAFは、マネージドなWebアプリケーションファイアウォールとして、マネージドルールを適用することで、SQLインジェクションやXSSなどの攻撃を検知・遮断します。また、AWS ShieldやAzure DDoS Protectionは、DDoS攻撃からアプリケーションを保護します。

さらに、Amazon GuardDutyやMicrosoft Defender for Cloud（旧Azure Security Center）といったクラウドネイティブなセキュリティ監視サービスは、機械学習を用いて異常な動作を検知し、リアルタイムでアラートを発します。これらのサービスを適切に組み合わせることで、オンプレミス環境よりも高度なセキュリティを実現できる場合もあります。

試験でも、クラウド特有の用語が出ても焦らず、「これはDMZの話だな」「これは内部セグメントの話だな」と置き換えて考えることが重要です。クラウドもオンプレミスも、ネットワークセキュリティの基本原則は同じです。

【演習】DMZ・ネットワーク構成 理解度チェック（全10問）

午後試験では、ネットワーク構成図を見て配置ミスやFWルールの誤りを指摘させる形で出題されます。午前でも、DMZの役割や構成パターン、ステートフルインスペクションの違い、スプリットDNSの目的は定番です。ひっかけどころは、通信の方向（誰が通信を開始するか）と、どのサーバーをDMZに置くかの判断です。以下の練習問題で本記事の理解度を確認してみましょう。選択肢をクリックすると解説が表示されます。

まとめ：防御の要塞を設計する視点を持とう

DMZは、単に「サーバーを置く場所」ではなく、信頼できない外部から、組織の重要資産を守るための要塞の構造そのものです。

今回の記事の要点を振り返ります。

目的の明確化： DMZは「攻撃を受けても被害を局所化・遅延させる」ための緩衝地帯である。外部からの攻撃がDMZで食い止められれば、社内LANの重要資産は守られる。

通信の鉄則： インターネットからは「必要最小限の公開ポート」のみ許可し、DMZから社内LANへの通信は「原則禁止」する。この鉄則を破ると、DMZ内のサーバーが侵害された際に被害が連鎖する。

サーバーの適材適所： WebはDMZ、DBは内部。DNSやメールは機能を分割して配置する。それぞれのサーバーの役割と脅威を理解し、適切なセグメントに配置することが重要。

多層防御の実践： ファイアウォールだけでなく、IPS、WAF、EDRなど複数のセキュリティ層を組み合わせる。一つの防御が突破されても、次の層で攻撃を食い止める。

継続的な監視： 設計だけでなく、運用段階でのログ監視と異常検知が不可欠。SIEMやクラウドネイティブな監視サービスを活用し、攻撃の兆候を早期に発見する。

クラウドへの応用： AWSではパブリックサブネットとプライベートサブネットの関係は、DMZと社内LANの関係と同じである。クラウド特有の機能を活用しつつ、基本原則は変わらない。

情報処理安全確保支援士試験の午後試験において、ネットワーク図は「地図」です。その地図の中に、城門（FW）がどこにあり、外敵がどこから攻めてくるか、そして宝物（データ）がどこに隠されているかを読み解く力が求められます。

今回の解説で得た知識を使って、過去問のネットワーク図をぜひ見直してみてください。「なぜここにFWがあるのか？」「なぜDNSが2つあるのか？」といった疑問が氷解し、セキュリティ設計の意図が手に取るようにわかるはずです。

次回は、DMZのような固定的なセグメント分割をソフトウェアで柔軟に制御する、SDNとOpenFlowの仕組みを取り上げます。ネットワーク仮想化がもたらす新しいセキュリティ上のリスクと対策を解説しますので、お楽しみに。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• JPRS DNS関連技術資料（DNSの仕組み・DNSSEC）
• RFC 7489: DMARC
• RFC 9989: DMARC (2026年5月、RFC 7489を置換)
• RFC 5452 Measures for Making DNS More Resilient against Forged Answers
• RFC 4033 DNS Security Introduction and Requirements
• NIST SP 800-41 Rev.1 Guidelines on Firewalls and Firewall Policy
• AWS公式ドキュメント：VPCのサブネット
• IPA 情報処理安全確保支援士試験