DMZとは？ネットワーク非武装地帯の設計・構成・セキュリティ設定を現場目線で解説

「外部公開サーバーを社内ネットワークに直接置くのは怖いけど、どう分離すればいいんだろう」
「DMZという言葉は知っているけど、実際にどう設計すればいいのかよくわからない」
こういった疑問を持つインフラ担当者は少なくありません。

DMZ（非武装地帯）は、外部と内部ネットワークの間に設ける「緩衝ゾーン」です。Webサーバーやメールサーバーなど、インターネットからのアクセスが必要なサーバーをここに置くことで、万が一そのサーバーが攻撃されても、社内の業務システムへの被害を最小限に食い止めることができます。

この記事では、DMZの基本概念・設計パターン・具体的なファイアウォール設定まで、現場で使えるレベルで解説します。情シス担当者が今日から取り入れられる実践的な内容を中心にまとめました。

DMZとは？（概要とネットワーク上の位置づけ）

DMZ（Demilitarized Zone、非武装地帯）は、インターネット（外部）と社内ネットワーク（内部）の間に設ける、セキュリティ上の中間ゾーンです。

元々は軍事用語で、敵対する2勢力の間に設ける緩衝地帯を指しますが、ネットワークセキュリティでも同じ概念が使われています。インターネットに公開するサービスを「どちら側にも完全に属さない場所」に隔離することで、攻撃が成功しても被害を局所化する設計思想です。

社内ネットワークをDMZなしで直接インターネットに接続した場合、外部公開サーバーが侵害されると、攻撃者はそのサーバーを踏み台に社内の業務システムや顧客データベースへ横展開（ラテラルムーブメント）できてしまいます。DMZを挟むことで、この横展開を構造的に阻止します。

DMZに置くサーバーの例

・Webサーバー: 外部向けコーポレートサイト、ECサイト、Webアプリケーション
・メールサーバー（SMTPリレー）: 外部メールの中継・受信処理
・DNSサーバー（外部向け）: 外部クライアントへのDNS応答
・VPNゲートウェイ: リモートワーカーの接続受付口
・リバースプロキシ: 外部→内部Webアプリへの中継
・FTPサーバー（外部取引先用）: ファイル授受専用

攻撃者の視点から見るDMZ未設置のリスク

外部公開サーバーを社内ネットワークに直接置いた場合、攻撃者はどう動くかを整理します。セキュリティ対策は「攻撃者の手口を知ること」から始まります。

1. 攻撃者が外部公開Webサーバーの脆弱性（例: CMSのプラグインの既知CVE）を突いてシェルを取得する
2. 同一ネットワークセグメントにある社内PCや業務サーバーへのスキャンを開始する
3. 社内ファイルサーバーのSMBポートが開いていれば、認証情報の窃取・ランサムウェア展開へ進む

DMZがあれば、ステップ1で侵害が止まります。攻撃者は「DMZのWebサーバー」にしかアクセスできず、その先にある社内ネットワークへの通信はファイアウォールで遮断されているからです。

DMZの設計パターン

1. シングルファイアウォール型（3本足構成）

最も基本的な構成です。1台のファイアウォールに3つのインターフェースを持たせ、それぞれをインターネット・DMZ・内部ネットワークに接続します。

・メリット: 機器台数が少なく、コストを抑えられる。中小企業に向いている
・デメリット: ファイアウォールが単一障害点になる。ファイアウォール自体が侵害された場合にDMZと内部ネットワーク両方が危険にさらされる

2. デュアルファイアウォール型

外部ファイアウォール（インターネット↔DMZ）と内部ファイアウォール（DMZ↔内部）の2台を直列に配置する構成です。

・メリット: 外部FWが突破されても内部FWが第2の防壁となる。高いセキュリティ要件の環境に向いている
・デメリット: 機器コスト・管理コストが増加。ルール設計が複雑になる

メーカーを異なるものにすることで、一方の脆弱性が他方に影響しないという考え方（異種FW構成）も存在します。コストと管理工数がかかるため、大企業・官公庁向けの設計です。

3. クラウド時代のDMZ設計（VPCとサブネット分離）

AWSやAzureでは、VPC（仮想ネットワーク）のサブネットを「パブリックサブネット」と「プライベートサブネット」に分け、セキュリティグループとNACL（ネットワークACL）で通信を制御するのがDMZの現代的な実装です。

・パブリックサブネット: インターネットゲートウェイ経由でアクセスできる。ロードバランサーやリバースプロキシを配置
・プライベートサブネット: 直接インターネットからアクセスできない。アプリサーバー・DBサーバーを配置

クラウドの場合はセキュリティグループが「サーバー単位のファイアウォール」として機能するため、従来の物理的なFW構成とは概念が異なりますが、「公開ゾーン」と「非公開ゾーン」を明確に分ける思想は同じです。

具体的な防御手順

1. ファイアウォールの基本ルール設計

DMZ設計の要はファイアウォールのルール（ポリシー）です。基本的な考え方を整理します。

デフォルト拒否（Deny All）を原則とし、必要な通信だけを明示的に許可します。

# firewalldを使ったゾーン設計の例（CentOS/RHEL系）
# DMZゾーンの確認
firewall-cmd --zone=dmz --list-all

# DMZゾーンに許可するサービスを追加（HTTPSのみ）
firewall-cmd --zone=dmz --add-service=https --permanent

# DMZゾーンのインターフェース割り当て（eth1をDMZに）
firewall-cmd --zone=dmz --change-interface=eth1 --permanent

# 内部ゾーン（internal）のインターフェース設定
firewall-cmd --zone=internal --change-interface=eth2 --permanent

# 設定を反映
firewall-cmd --reload

2. DMZ→内部ネットワークの通信を禁止する

DMZ設計で最も重要なルールは「DMZから内部への通信を原則禁止すること」です。この方向への通信を許可してしまうと、DMZのサーバーが侵害された際に内部ネットワークへの横展開を許してしまいます。

例外的に許可が必要なケースは以下に限定します。

・DMZのWebサーバー → 内部DBサーバー: 特定IPアドレス・特定ポート（例: MySQL 3306）のみ許可。ポート範囲の全解放は絶対に避ける
・DMZのメールサーバー → 内部メールサーバー: SMTP（25番）のみ、内部サーバーのIPを宛先に限定

# iptablesでDMZ→内部への通信を制御する例
# FORWARD チェーンのデフォルトポリシーをDROPに設定
iptables -P FORWARD DROP

# DMZ（192.168.10.0/24）→内部（192.168.1.0/24）は基本禁止（デフォルトDROPで適用）

# 例外: DMZのWebサーバー(192.168.10.10)→内部DB(192.168.1.20)のMySQL(3306)のみ許可
iptables -A FORWARD -s 192.168.10.10 -d 192.168.1.20 -p tcp --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.1.20 -d 192.168.10.10 -p tcp --sport 3306 -m state --state ESTABLISHED -j ACCEPT

# インターネット→DMZのWebサーバー（80/443）は許可
iptables -A FORWARD -d 192.168.10.10 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -d 192.168.10.10 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

# 設定の保存
iptables-save > /etc/iptables/rules.v4

3. 管理アクセスの分離

DMZサーバーへの管理（SSH接続、設定変更など）は、社内ネットワークから一方向で行います。インターネット側からの直接SSH接続は禁止するのが基本です。

・社内PC → DMZサーバーへのSSH: 内部ネットワークの管理端末IPからのみSSH（22番）を許可
・インターネット → DMZサーバーへのSSH: 禁止（必要な場合はVPNを通してから内部ネットワーク経由でアクセス）

踏み台サーバー（ジャンプホスト）をDMZに置き、そこを経由して各DMZサーバーにSSHする構成も有効です。管理アクセスのログが一元化でき、監査証跡の取得が容易になります。

# DMZサーバー側のsshd_config設定例
# 管理端末のIPアドレスからのみSSH許可
AllowUsers admin@192.168.1.100

# rootログインは禁止
PermitRootLogin no

# パスワード認証は無効化（鍵認証のみ）
PasswordAuthentication no

# ポートを変更（22から変更する場合）
# Port 2222

4. DMZサーバーのハードニング

DMZのサーバーはインターネットに直接さらされる性質上、社内サーバー以上に堅牢化（ハードニング）が必要です。

・不要なサービスを停止: 公開に必要なサービス以外は全停止する
・パッケージは最小構成: OSインストール時に余分なパッケージを含めない
・自動パッチ適用: セキュリティアップデートを自動適用する設定を有効化
・ログを内部の監視サーバーに転送: DMZサーバーのログを内部SIEMやsyslogサーバーに転送し、侵害時もログが保全されるようにする
・ファイル整合性監視: AIDEなどを使ってWebサーバーのドキュメントルートの改ざんを検知する

# rsyslogでDMZサーバーのログを内部syslogサーバーに転送する設定
# /etc/rsyslog.conf に追記

# すべてのfacility・severityを内部ログサーバー(192.168.1.50)に転送
*.* @@192.168.1.50:514   # TCP転送（@@）。UDPの場合は @192.168.1.50:514

# 設定反映
systemctl restart rsyslog

中小企業でも今日からできること

「DMZを設計するには高価なFW機器が必要では」と思う方もいるかもしれませんが、予算に応じた現実的な選択肢があります。

・既存のビジネスルーターでDMZ機能を活用: Yamaha RTXシリーズやFortiGateなど、多くのビジネス向けルーターにDMZ機能（3ポート設定）が内蔵されています。別途FW機器を購入しなくても、既存機器でDMZゾーンを設定できるケースがあります
・Linuxサーバー1台でソフトウェアFWを構成: firewalldやnftablesを使えば、廉価なx86サーバーをソフトウェアFWとして使用できます。冗長性は犠牲になりますが、コストを最小化できます
・外部公開サービスをクラウドに移行: WebサーバーやメールリレーをAWS・Azureのパブリックサブネットに移行することで、オンプレのDMZ設計に相当する分離を実現できます
・VPS+CloudFlareの組み合わせ: 外部公開WebサーバーをVPSに置き、オリジンIPを非公開にした上でCloudFlareをリバースプロキシとして使う構成も、中小企業にとって現実的な選択肢です

よくある誤解と注意点

【注意】DMZを設けたからといって内部は安全、ではない

DMZはあくまで「被害を局所化する仕組み」です。内部ネットワーク側でも以下の対策は継続して必要です。

・定期的なパッチ適用とOSアップデート
・EDRやアンチウイルスの導入
・不要なポートの閉鎖と定期的な内部スキャン
・多要素認証（MFA）の導入

【注意】DMZから内部への「必要な通信」を最小化する

「WebサーバーがDBを参照するから」という理由でDMZ→内部の通信を広く許可してしまうケースがあります。これはDMZの目的を半減させます。

WebサーバーとDBを同じDMZに置く構成（フロントエンドWEB+バックエンドDB両方をDMZに）も選択肢の一つです。ただし、DBに顧客の個人情報が含まれる場合は、DBを内部ネットワーク側に置き、アクセスを特定IPポートに絞る設計のほうがリスクを限定できます。

【注意】DMZの管理を「設定後放置」しない

ファイアウォールのルールは一度設定したら終わりではありません。ビジネスの変化に伴って不要なルールが残り続けることが多く、これが「ルール肥大化」と呼ばれる問題です。

半年に一度はFWルールを棚卸しし、不要な許可ルールを削除する習慣をつけましょう。変更管理台帳に記録を残すことで、誰が・いつ・なぜそのルールを追加したかを追跡できます。

本記事のまとめ

DMZは、インターネットに公開するサービスを持つ組織にとって「当たり前の設計」であるべきです。ランサムウェアや標的型攻撃の多くは、外部公開サーバーを踏み台にして内部に侵入してきます。DMZを正しく設計・運用することで、その侵入経路を構造的に断つことができます。

Linuxのファイアウォール設定（firewalldやnftables）の詳細については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。合わせてご参照ください。