DMZ という言葉は、定義がないまま目の前に現れます。セキュリティレビューのチェックリストの一項目、ベンダーのハードニング文書の一文、求人票で TLS や最小権限の隣に並ぶ要件として。
調べてみると、ネットワークケーブルが 3 本刺さったファイアウォールの図が出てきます。1 本はインターネットへ、1 本はサーバー群へ、1 本はオフィスの LAN へ。しかしあなたが管理しているのは、公開 IP が 1 つだけ、予備のネットワークインターフェースなど 1 つもない、借りたサーバー 1 台です。
最初の図は本物の DMZ アーキテクチャです。1 台のサーバーでも、その安全性の目的の一部、つまりインターネットが届く範囲を狭めることは再現できます。同じホスト上で再現できないのは、DMZ を DMZ たらしめている独立したネットワーク境界のほうです。
短いバージョン
- DMZ は、見知らぬ相手が到達しなければならないサービスを、それ以外に動かしているものから切り離します。
- 本質は配線ではありませんでした。公開側で起きた侵害が、そこで止まることこそが狙いだったのです。
- ファイアウォールを設定していても、DMZ があるとは限りません。
- 公開 IP が 1 つだけのサーバー 1 台でも、リバースプロキシ、ホストのファイアウォールルール、ループバックやプライベートアドレスへのバインドによって露出を減らすことはできます。ただし、独立した DMZ セグメントが生まれるわけではありません。
- この方式は守る対象とカーネルを共有しているため、隔離ではなく露出の低減として数えてください。
本記事が扱わないこと
ここで扱う範囲は考え方のモデルであり、隣接する 3 つの話題は意図的に取り上げません。
- 構築手順は扱いません。リバースプロキシの設定も、ファイアウォールのルール構文も、どのツールを入れるべきかという推奨もありません。
- 家庭用ルーターの設定も扱いません。家庭用ルーターの「DMZ host」という項目は、まったく別の機能を指しています。
- ゼロトラストについての結論も出しません。ネットワーク境界が今も主たる制御として妥当かどうかは本物の論争であり、ここで決着はつけません。
DMZ とは何か、何のためにあるのか
DMZ、すなわち非武装地帯とは、信頼できないインターネットと内部ネットワークのあいだに置かれるネットワークセグメントです。ウェブサーバーやメールサーバーのように、外部から到達できなければならないサービスがここに置かれます。それ以外はすべて二つ目の境界の内側に残るため、公開サービスに到達できたからといって、残りに到達できるわけではありません。
Mozilla の用語集にある DMZ の項目 は、その肝心な半分を一つの節にまとめています。定義された一部のエンドポイントだけを公開し、外部から内部ネットワークへのアクセスは拒否する、というものです。設計上の目的はこれがすべてであり、機器への言及は一切ありません。
そこに置かれるサービスの種類は、この目的から自然に決まります。ウェブサーバー、メールサーバー、FTP サーバー、VoIP サーバーなど、見知らぬ相手が接続できてよいものです。ディレクトリサーバー、データベース、ファイル共有、社内アプリケーション、管理画面はその一覧に入りません。外部の誰にも届いてはならないものだからです。
絵ではなく性質のほうを覚えておいてください。3 つのネットワークインターフェースは、独立した信頼境界を作る一つの方法にすぎません。クラウドや単一サーバーの設計も、同じ露出制御の原則を別のかたちで適用できます。ただし DMZ そのものを再現できるのは、独立した境界ゾーンを持つ設計だけです。
従来型の 3 インターフェース DMZ はどう動くのか
従来型の DMZ には 2 つの作り方があります。単一ファイアウォール構成では、1 台のファイアウォールにインターネット、DMZ、内部ネットワークへの 3 つのインターフェースを持たせます。二重ファイアウォール構成では、独立した 2 台のファイアウォールのあいだに DMZ を置きます。どちらも同じ規則を強制します。インターネットは DMZ には届く。インターネットは内部ネットワークには決して届かない。
単一ファイアウォール(3 レッグ)モデル
ファイアウォール 1 台、ネットワークインターフェース 3 つ。1 つ目はインターネットに面します。2 つ目は公開サービスが置かれる DMZ に面します。3 つ目は内部ネットワークに面します。ファイアウォールは、インターネットから DMZ の特定ポートへの受信通信を許可し、アプリケーションが必要とする場合に限って DMZ から内部への狭い通信を許可し、それ以外はすべて拒否します。
この形は 3 レッグファイアウォールと呼ばれます。ゾーン間を越えるすべてのパケットが 1 台の機器を通るため、そのファイアウォールはゾーン間通信の単一障害点になります。停止した場合、接続性とポリシー適用がどう影響を受けるかは、ファイアウォールの障害時の挙動と、用意してある冗長構成しだいです。
私はある ISP でネットワーク運用を 10 年担当しましたが、DMZ インターフェースについて人が驚いたのは、それがいかに平凡かという点でした。ファイアウォールの設定で別の信頼ラベルが付いているだけの、ごく普通のイーサネットポートです。アーキテクチャは銅線の中にはありませんでした。ルールセットの中に、そして誰かが各フローをどちらの向きに許すかを丁寧に考えたという事実の中にありました。
二重ファイアウォール(バックツーバック)モデル
2 台のファイアウォールを直列に並べ、そのあいだに DMZ を置きます。外側のファイアウォールはインターネットからの通信を DMZ までは通し、その先には通しません。内側のファイアウォールは、アプリケーションが必要とする DMZ から内部への通信だけを許可します。DMZ にたどり着いた攻撃者も、内部ネットワークに届く前に内側ファイアウォールのポリシー境界を越えなければなりません。
ファイアウォールが 2 台あれば、別々に強制される 2 つのポリシー境界が手に入りますが、同時に設定作業、パッチ適用、運用の複雑さも増えます。外側の境界が落ちたり破られたりしても、内側の境界が自動的に消えるわけではありません。とはいえ、守りの強さは 2 台がどう設定され運用されているかに左右されます。
DMZ はファイアウォールと同じものか
いいえ。DMZ は独立した境界ネットワーク、あるいはネットワークセグメントです。ファイアウォールは、そのゾーンとインターネットと内部ネットワークのあいだの通信を制御するためによく使われる手段の一つにすぎません。フラットなネットワークでも DMZ を作らずにファイアウォールのルールは設定できます。つまりこの違いは設定の問題ではなく、構造の問題です。
この取り違えは無理もありません。ファイアウォールはログインする対象であり、設定ファイルとベンダーとサポート契約を持つ「物」です。だからこそ、それが生み出すもののほうの名前まで引き受けてしまう。セグメントにログインする人など、誰もいないのです。
その帰結は、いちばん都合の悪いときに姿を現します。公開しているウェブサーバーは侵害されたものと考えてください。いずれ実際にそうなるからです。フラットなネットワークでは、攻撃者はすでにデータベースにもファイルサーバーにも管理画面にも話しかけられるマシンの上に足場を得ており、その間を渡り歩くことは、もともと許可されていたアクセスを使うだけの話になります。この横方向の移動をラテラルムーブメントと呼び、二つ目の境界はまさにそれを止めるために存在します。DMZ はウェブサーバーが侵害されるのを防ぎません。侵害されたウェブサーバーが、ほかのすべてへのアクセスに化けるのを防ぐのです。
用語が目の前にあるうちに一つ補足しておきます。家庭用や小規模オフィス向けルーターの「DMZ host」という設定は、これとは別の機能です。要求していない受信通信を内部の 1 台に転送し、その機器をインターネットに直接さらすだけで、独立した保護された DMZ ネットワークを作るわけではありません。
1 台のサーバーで DMZ の原則をどう適用するか
公開 IP が 1 つだけのサーバー 1 台でも、DMZ の露出制御という目的の一部は再現できます。ネットワークの分離のほうは再現できませんが。リバースプロキシを唯一の公開入口にし、既定で拒否する受信ファイアウォールルールで残りを塞ぎ、内部サービスは公開アドレスではなくループバックやプライベートインターフェースで待ち受けさせる、というやり方です。
この節が前提とする制約から始めましょう。VPS が 1 台、公開インターフェースが 1 つ、そして 独立したファイアウォール機器はなし そして自分で管理する DMZ サブネットもありません。この構成では、従来型の 3 レッグ構成を同じホスト上に再現することはできません。ホストのファイアウォールルール、サービスの待ち受け先の選択、リバースプロキシは依然として露出を減らせますが、同じ隔離境界を作り出すことはありません。
リバースプロキシは、公開インターフェースの次のポートを占有できます: 80 と 443 を占有し、ウェブ通信におけるアプリケーション層の唯一の入口になれます。これで公開された攻撃面は狭まりますが、独立した DMZ インターフェースと同等にはなりません。プロキシは背後のサービスと同じホストを共有したままだからです。
ホストの受信ファイアウォールルールは、この 2 つのポートを許可し、それ以外を破棄します。マシン上のほかのサービスは動いていても待ち受けていてもかまいませんが、外部からそこへ接続を張ることはできません。これは 1 台のホストの中で「意図したポートだけが到達可能」という方針に近づくものであり、内部ネットワークとの独立した境界を作り出すものではありません。
アプリケーションサーバー、データベース、管理画面は、公開アドレスで待ち受けるべきではありません。プロキシが同じホスト上で動くならループバックで、プライベートネットワークの別の場所で動くならプライベートアドレスで待ち受けさせます。どちらの場合も、公開インターフェース上にそれらのサービスのリスナーは存在しないため、そのインターフェースで受信ルールを開けただけでは公開されません。
管理用のアクセスは DMZ 側ではなく内部側に属します。SSH や管理インターフェースを公開経路から外し、VPN やプライベートネットワークの背後に置いておけば、公開インターネットからそこへ直接接続されることはなくなります。
DMZ の考え方は VPC のサブネットとセキュリティグループにどう対応するか
従来型のモデルは、クラウドのネットワーク部品にかなり近く対応づけられますが、一対一ではありません。DMZ セグメントはパブリックサブネットになります。内部ネットワークは、インターネットゲートウェイへの経路を持たないプライベートサブネットになります。ファイアウォールのルールセットは、リソースのネットワークインターフェースに紐づくセキュリティグループと、サブネットに紐づくネットワーク ACL とに分かれます。
| 従来型の要素 | クラウドでの対応物 | 何を強制するか |
|---|---|---|
| DMZ セグメント | パブリックサブネット | インターネットへの経路を提供する。リソース側にはさらに、パブリックアドレスとその通信を許可するセキュリティルールが必要 |
| 内部ネットワークセグメント | プライベートサブネット | インターネットゲートウェイへの直接経路がないため、その経路を通じてインターネット側から直接接続を開始できない |
| ゾーン間のファイアウォールインターフェース | ルートテーブル + インターネットゲートウェイのアタッチ | 通信をどこへルーティングできるか。リソースに実際に到達できるかどうかは、依然としてパブリックアドレスとセキュリティ制御が決める |
| ファイアウォールのルールセット(ゾーン単位) | ネットワーク ACL | サブネット境界で評価される、ステートレスな許可・拒否ルール |
| ファイアウォールのルールセット(ホスト単位) | セキュリティグループ | 関連付けられたリソースのネットワークインターフェースに適用される、ステートフルな許可ルール |
| DMZ 内の公開サービス | パブリックサブネット内のロードバランサーまたはプロキシインスタンス | 通信が必ず通らなければならない唯一の入口 |
クラウド事業者自身がこの語彙を使っており、この用語が今も現役であることのよい証拠になっています。AWS のネットワーキングブログは次のものを解説しています: Amazon VPC 上の DMZ アーキテクチャ 公開向けサービスを内部ネットワークから切り離すもので、2024 年 11 月に提供が始まったリージョン単位の制御機能である VPC Block Public Access の上に構築されています。
この対応づけで荷重を支えているのはサブネットです。パブリックサブネットがパブリックなのは、そのルートテーブルがインターネットゲートウェイを指しているからです。 ルートテーブルがパケットの行き先を決める。つまりサブネットの配置は、個々のルールよりも先にあなたの露出範囲を決めてしまいます。
この対応づけは、ある一点だけ不完全です。ファイアウォールのインターフェースはセグメント全体に対して境界を強制していましたが、セキュリティグループは個々のリソースのネットワークインターフェースに紐づきます。同じプライベートサブネットにある 2 台のマシンが、まったく別のセキュリティグループを持つこともあり得ます。つまり強制の粒度は、物理インターフェースが到達し得なかったほど細かくなりました。たいていはそれで良くなっています。同時にそれは、サブネットの名前が「何に到達できるか」について、かつてのネットワーク図ほど教えてくれなくなったということでもあります。
単一サーバー版が届かないところ
1 台のホスト上では、公開されているプロセスと内部サービスがカーネルとマシンを共有します。セグメントが分かれていれば、攻撃者はファイアウォールが検査するネットワーク境界を越えなければなりませんが、1 台のホストではその必要がありません。単一サーバー方式が減らすのは露出です。分離を再現するものではありません。
リバースプロキシが、攻撃者にコード実行を許すかたちで侵害された場合、そのコードはすでにデータベースが動いているのと同じマシン上で動いています。ループバックへのバインドはそこでは助けになりません。ループバックはホストの内側から届くからです。コンテナやユーザーによる分離は必要な手間を引き上げますが、同じホスト上のコンテナはやはりそのホストのカーネルを共有します。従来のモデルでは、攻撃者の次の一歩は、何かが検査している線の上を流れるパケットでした。ここではそれが、ローカルのソケットになります。
実務上の帰結は、判定ではなくしきい値です。プロキシの背後にあるものの価値が、2 台目のマシンを用意する手間を上回ったなら、2 台目と、そのあいだのプライベートネットワークを使ってください。そのためにこの記事の内容を学び直す必要はありません。ここに書いたことは、どれ一つとしてハードウェアの話ではなかったからです。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見るセキュリティポリシーを適用できる場所は、もはや境界だけではありません。ゼロトラストアーキテクチャはネットワーク上の位置にもとづく暗黙の信頼を取り除きます。また、次のもので構築したプライベートな接続は WireGuard または Tailscale 公開範囲を狭められます。どちらの手法も、セグメンテーションや認可を自動的に置き換えるものではありません。より狭い問いについての私の立場ははっきりしています。考え方のモデルとして、到達できるものと到達できないものを仕分け、どの境界が侵害を閉じ込めるのかを把握しておくこと。この問いは、ここまで挙げたどのアーキテクチャよりも長く生き残ります。だからこそ、今も答える価値があるのです。
よくある質問
DMZ は VPN と同じものか
いいえ。この二つは別々の問題を解いています。DMZ は、信頼できない外部の相手が何に到達できるかを制御するもので、ごく少数のサービスだけを公開し、それ以外は公開しません。VPN は、信頼できる外部の相手に内部への私的な経路を与えるもので、本来なら到達できないネットワークへ認証のうえで通します。両方を運用しているネットワークは多く、どちらももう一方の代わりにはなりません。
DMZ は安全なのか
DMZ は、公開されたサービスそのものを安全にするわけではありません。そのサービスが破られたとき、被害がどこまで届くかを制限するだけです。公開サービスは相変わらず公開されており、インターネット上の全員にさらされたままで、それ自体としてパッチ適用も監視も堅牢化も必要なままです。DMZ が決めるのは、それが陥落したあとに何が起きるかであって、陥落するかどうかではありません。
サーバーが 1 台しかない場合、DMZ は必要か
従来の意味では必要ありませんし、そもそも 1 台のホスト上に作ることもできません。3 インターフェース構成には独立したネットワークセグメントが要りますが、公開 IP が 1 つだけのサーバーにはそれが一つもありません。できるのは露出を制御することです。リバースプロキシを唯一の公開入口にし、それ以外の受信ポートは既定で拒否し、内部サービスはループバックかプライベートアドレスで待ち受けさせる。これでインターネットが届く範囲は狭まりますが、公開サービスをホストの残りから隔離できるわけではありません。プロキシの背後にあるものの価値が 2 台目のコストを上回ったなら、2 台のマシンと、そのあいだのプライベートネットワークを使ってください。
なぜ「非武装地帯」と呼ばれるのか
この語は、対立する二つの勢力のあいだにあり、どちらも完全には支配していない緩衝地帯という軍事上の意味からの借用です。ネットワークでの用法もその比喩を保っています。DMZ は、信頼できない外側にも、信頼している内側にも、まるごとは属していないのです。

ディスカッション
コメント
ログインしてディスカッションに参加してください。