公開2026.07.11更新2026.09.07 14 人が閲覧（直近 30 日）セキュリティ

DMZとは？非武装地帯の仕組み・構成2タイプと設定手順、クラウド時代の設計を解説

DMZとは、インターネットに公開するサーバーを、社内ネットワークからも外部ネットワークからも切り離した専用エリアに置く、ネットワーク分離の考え方です。Web・メール・DNSといった「外に見せる必要のあるサーバー」だけをここに隔離し、万一そこが乗っ取られても被害を社内へ波及させません。この記事で扱うのは、非武装地帯という名前の由来と通信ルール、DMZに置くサーバー、シングルファイアウォール型とデュアルファイアウォール型という2つの構成、firewalldとAWSでの具体的な設定コマンド、導入のメリットとデメリット、そしてクラウドのパブリックサブネットが果たす論理的なDMZの役割です。最後に、ゼロトラストへ移る流れのなかでDMZを残すべきか、リバースプロキシやWAFで代替すべきかの判断基準まで踏み込みます。

まとめ｜DMZとは外部公開サーバーを隔離する緩衝ネットワーク

DMZ（DeMilitarized Zone＝非武装地帯）は、外部に公開するサーバーを社内LANから切り離して置く緩衝エリアです。狙いは1つ、「公開サーバーが侵入されても、そこを踏み台に社内へ入られない」構造を作ることにあります。外部→DMZの通信は許可し、DMZ→社内の通信は原則遮断する。この非対称なルールが、DMZの本質です。

用語としてのDMZは、米国NISTのNIST SP 800-41 Rev.1「Guidelines on Firewalls and Firewall Policy」（2009年9月）でも定義されており、同書の用語集では「ルーティングファイアウォール上のインターフェースで、保護側のインターフェースに似ているが、DMZと保護側の間を行き来する通信にはポリシーが適用される」と説明されています。本文にも「Firewall with a DMZ」の構成図が掲げられ、境界設計の標準的な型として扱われてきました。

構成は、1台のファイアウォールで3つのエリアを仕切るシングルファイアウォール型と、2台で挟むデュアルファイアウォール型の2系統に整理できます。オンプレならfirewalldのゾーンとポリシーオブジェクト、クラウドならパブリックサブネットとセキュリティグループが、同じ分離を実装する手段です。自社のネットワーク分離をどう設計するか、オンプレとクラウドのどちらに寄せるかで迷う場合は、インフラ構築（AWS/GCP/Azure）で構成段階から相談を受け付けています。

DMZ（非武装地帯）とは何か｜社内ネットワークを守る緩衝エリアの仕組み

DMZの発想は単純です。外に見せるサーバーと、絶対に見せたくない社内システムを、同じネットワークに同居させない。両者の間に「どちらからも隔てられた中間地帯」を1つ挟むことで、外部からの侵入が社内へ直通するのを断ちます。

DMZの由来と役割｜軍事用語「非武装地帯」がネットワークで指すもの

DMZはDeMilitarized Zoneの略で、もとは対立する二国間に設ける非武装の緩衝地帯を指す軍事用語です。ネットワークではこれを転用し、信頼できない外部（インターネット）と、信頼する内部（社内LAN）のどちらにも属さない中立エリアを指します。ここに公開サーバーを置くことで、外部からアクセスできる範囲をDMZ内に限定し、社内ネットワークへの直接の到達を防ぎます。役割を一言で言えば、「攻撃者を招き入れてよい範囲を、あらかじめ区切っておく」構造です。

この考え方はOSSのファイアウォール実装にもそのまま組み込まれています。Linuxの標準的なファイアウォール管理ツールであるfirewalldは、定義済みゾーンの一覧に dmz ゾーンをあらかじめ持ち、「内部ネットワークへのアクセスを制限したうえで公開されるコンピューター向け。選択した着信接続だけを受け入れる」と定義しています。DMZは特定ベンダーの製品機能ではなく、ネットワーク設計の一般名詞として実装側にも定着した概念だと分かります。

DMZに置くサーバーと3つの通信ルール（外部・DMZ・内部の許可設計）

DMZに配置するのは、外部と通信する必要のあるサーバーに限られます。代表例はWebサーバー、メールサーバー（送受信の中継）、DNSの外向けサーバー、リバースプロキシ、公開用のFTPサーバーなどです。逆に、データベースサーバーや業務システム、ファイルサーバーといった「社内だけで使うもの」はDMZに置かず、社内ネットワーク側に隔離します。前段で受けて背後のサーバーへ振り分ける機器の役割そのものは、リバースプロキシの仕組みとフォワードプロキシとの違いで実装目線から整理しています。

通信の許可設計は、3つのエリア間で次のように非対称に組みます。

通信の向き	原則の扱い	典型例
外部 → DMZ	必要なポートのみ許可	インターネットから公開Webサーバーの443番へ
DMZ → 内部	原則遮断（必要時のみ限定許可）	WebサーバーからDBへ、特定ポートだけ許可
内部 → DMZ／外部	用途に応じ許可	社内からの管理アクセス、外部サイト閲覧

肝はDMZ→内部を絞ることです。公開サーバーが乗っ取られた前提で、そこから社内DBへ自由に入れないよう、必要な1経路だけを穴として開けます。管理者がDMZ内サーバーへSSHで入る経路も同じ考え方で絞り込み、踏み台サーバー経由の多段接続に寄せておくと、DMZに常時開けておく管理ポートを減らせます。

なぜ公開サーバーをDMZに隔離するのか｜侵入時の被害を内部に波及させない

公開サーバーは、24時間インターネットからアクセスを受け続ける以上、攻撃対象になりやすい存在です。仮に社内LANにWebサーバーを直置きすると、そのサーバーが侵害された瞬間、攻撃者は社内ネットワークの内側に立つことになります。DBもファイルサーバーも同じセグメントにあれば、横移動（ラテラルムーブメント）で次々と到達されかねません。DMZに隔離しておけば、被害はDMZ内でいったん止まり、社内への侵入にはもう一段のファイアウォールを越える必要が生じます。この「被害を局所化する一段」が、DMZを設ける最大の理由です。

DMZの構成2タイプ｜シングルファイアウォール型とデュアルファイアウォール型

DMZの作り方は、使うファイアウォールの台数で大きく2つに分かれます。守りの厚さと運用のしやすさがトレードオフの関係にあり、規模と予算で選び分けます。

シングルファイアウォール型（3インターフェース型）の構成と向く規模

1台のファイアウォールに、外部・DMZ・内部の3つのネットワークをそれぞれ別ポート（インターフェース）で接続する構成です。1台の設定で3エリア間の通信ルールを一括管理でき、機器コストも運用の手間も抑えられます。中小規模の拠点や、公開サーバーが数台程度の環境ではこの型が実務的な選択になります。弱点は、そのファイアウォール1台が突破されると3エリアの仕切りが同時に失われる点です。設定ミスが全体に直結するため、ルールの見直しは慎重に行います。1台に防御機能を集約する発想をさらに進めた製品分類がUTM（統合脅威管理）で、中小規模ではUTM1台でDMZ用インターフェースまで賄う構成もよく採られます。

デュアルファイアウォール型の構成と多段防御で社内を守る設計の考え方

外部とDMZの間に1台目、DMZと内部の間に2台目のファイアウォールを置き、DMZを2台で挟む構成です。社内へ到達するには2台のファイアウォールを続けて越える必要があり、しかもメーカーの異なる機器を組み合わせれば、片方の脆弱性がもう片方に通用しにくくなります。防御は厚くなる一方、機器代と保守費が2台分かかり、ルール設計も2重になります。金融機関や大規模なシステムなど、内部ネットワークの保護を最優先する環境で選ばれる型です。DMZという緩衝地帯を、そもそもファイアウォールの設定で作り出す仕組みは、ファイアウォールとは何か・種類と選び方の記事で仕組みから整理しています。

構成タイプの選び方｜規模・予算・保護対象から決める判断軸の整理

2つの型は、優劣ではなく適材適所で選びます。判断軸を絞ると次の通りです。

観点	シングルFW型	デュアルFW型
機器台数・コスト	1台・低め	2台・高め
防御の厚み	1段	2段（多段防御）
運用の手間	一括管理で軽い	2重設計で重い
向く規模	中小拠点・公開サーバー少数	大規模・高い機密要件

公開サーバーが数台で情シスの人手が限られるなら、シングル型で1台に集約するのが合理的です。逆に、内部に守るべき機密が集中し、可用性要件も高い環境では、コストを払ってでもデュアル型で段を増やす価値があります。

DMZを実際に作る手順｜firewalldのゾーン設定とAWS VPCでの分離

ここからは構成図から実装へ降ります。オンプレのLinuxゲートウェイならfirewalld、クラウドならVPCのサブネットとセキュリティグループが、DMZを作る道具になります。以下のコマンドは、外部・DMZ（10.0.10.0/24）・内部（10.0.30.0/24）の3セグメントを想定した例です。

firewalldのdmzゾーンで公開サーバーへの受信を絞る設定

firewalldはインターフェース単位でゾーンを割り当て、ゾーンごとに受け入れるサービスやポートを宣言します。DMZ側のNICを dmz ゾーンに入れ、443番だけを受ける形にすると次のようになります。

# DMZ側のNICを dmz ゾーンへ割り当てる
firewall-cmd --permanent --zone=dmz --change-interface=ens192

# 外部から受けるのは HTTPS だけに絞る
firewall-cmd --permanent --zone=dmz --add-service=https

# 内部側のNICは internal ゾーンへ
firewall-cmd --permanent --zone=internal --change-interface=ens224

firewall-cmd --reload
firewall-cmd --zone=dmz --list-all

最後の --list-all で、そのゾーンに実際に紐づいたインターフェースと許可サービスが一覧表示されます。意図しないサービス（ssh や cockpit など既定で開いているもの）が残っていないかは、この出力で毎回確かめてください。ゾーンという抽象を使わず、パケット単位でルールを書き下ろす方式を理解しておきたい場合は、iptablesによるパケットフィルタ設定とnftablesへの移行が下地になります。

ポリシーオブジェクトでDMZから内部ネットワークへの転送を遮断する

DMZの本質は「DMZ→内部を絞る」ことでした。firewalldでゾーン間の転送を制御する仕組みが、2020年9月に公開されたfirewalld公式の解説記事で示されたポリシーオブジェクトです。0.9系で導入され、従来のdirectインターフェースを置き換える位置づけになっています。入口ゾーンと出口ゾーンを指定し、既定の扱いをDROPにしたうえで、必要な1経路だけを開けます。

# DMZ から内部への転送を規定するポリシーを作る
firewall-cmd --permanent --new-policy dmz-to-internal
firewall-cmd --permanent --policy dmz-to-internal --add-ingress-zone dmz
firewall-cmd --permanent --policy dmz-to-internal --add-egress-zone internal

# 既定は遮断
firewall-cmd --permanent --policy dmz-to-internal --set-target DROP

# DBの5432番だけを穴として開ける
firewall-cmd --permanent --policy dmz-to-internal \
  --add-rich-rule='rule family=ipv4 destination address=10.0.30.10/32 port port=5432 protocol=tcp accept'

firewall-cmd --reload
firewall-cmd --info-policy dmz-to-internal

ターゲットに指定できる値は CONTINUE、ACCEPT、DROP、REJECT の4種類です。DMZ→内部はDROP、内部→DMZは別ポリシーでACCEPT、というように向きごとにポリシーを分けて書くのが公式ドキュメントの想定する使い方になります。

AWS CLIでパブリックサブネットとセキュリティグループを作る

クラウドでは、同じ分離をサブネットの経路設定で表現する仕組みです。AWSのVPCユーザーガイド（サブネットの設定）は、インターネットゲートウェイへの経路を持つサブネットをパブリックサブネット、持たないものをプライベートサブネットと定義しています。パブリックサブネットが論理DMZ、プライベートサブネットが社内側に対応します。

# 論理DMZになるパブリックサブネットを作る
aws ec2 create-subnet --vpc-id vpc-0abc1234 \
  --cidr-block 10.0.10.0/24 --availability-zone ap-northeast-1a

# このサブネットのルートテーブルにだけ IGW 向けの経路を付ける
aws ec2 create-route --route-table-id rtb-0public \
  --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc1234

# 公開Web用SG: 外部からの443だけ許可
aws ec2 authorize-security-group-ingress --group-id sg-0web \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# DB用SG: 送信元をWebのSGに限定する（IP指定ではなくSG参照）
aws ec2 authorize-security-group-ingress --group-id sg-0db \
  --protocol tcp --port 5432 --source-group sg-0web

最後の --source-group がクラウド側の勘所です。セキュリティグループのドキュメントにある通り、送信元にIPレンジではなく別のセキュリティグループを指定できるため、「Web層に属するインスタンスからのみDBへ入れる」という関係をIPアドレスの管理なしに固定できます。VPCとサブネットの切り出し、IAMまで含めた初期設計の手順はAWS環境構築の手順にまとめており、アドレス設計そのものに迷う場合はCIDR表記の読み方とサブネット設計が参考になります。

DMZ設定後に確かめる3点｜経路・許可ポート・内部への遮断の実測

設定を入れたら、机上のルール表ではなく実際の通信で確かめます。確認するのは3点です。第一に、DMZのサーバーがインターネットから意図したポートだけで見えているか。第二に、DMZ側から内部セグメントへ、許可した1経路以外が届かないか。第三に、ログが取れているか。二番目は次のように実測できます。

# DMZサーバー上で実行する
# 許可した1経路（DB 5432）は open になるのが正
nc -zv -w 3 10.0.30.10 5432

# それ以外は timed out もしくは無応答になるのが正
nc -zv -w 3 10.0.30.10 22
nc -zv -w 3 10.0.30.20 445

# 待ち受けポートの棚卸し
ss -ltnp

2番目のコマンドが接続に成功してしまう場合、DMZ→内部の遮断が効いていません。ポリシーの向き（ingress／egress）の取り違えか、ルールの評価順の誤りを疑ってください。ここを実測せずに構成図だけで完了とすると、「DMZを作ったつもりで内部が素通し」という状態が長期間気づかれずに残ります。

DMZ構築のメリットとデメリット｜運用コストと防御効果のバランス

DMZは万能の解ではありません。得られる防御効果と、支払う運用コストの両方を見たうえで、自社に見合うかを判断します。

DMZ導入で得られる防御効果と、社内へ波及させない被害の局所化

最大の効果は、公開サーバーが侵害されても社内ネットワークへの直通を断てることです。外部からの攻撃はまずDMZで受け止められ、社内DBや業務システムへ到達するには追加のファイアウォールを越える壁が立ちはだかります。加えて、公開サーバーと社内サーバーの通信ルールを別々に管理できるため、「外向けにはこのポートだけ、社内向けにはこの経路だけ」という細かい制御がしやすくなります。監視やログ取得の対象もDMZに集約でき、外部に接する箇所を1エリアに束ねられる点も運用上の利点です。

見落とされがちなデメリット（構成の複雑化・運用負荷・単体では不十分）

デメリットは主に運用側に出ます。ネットワークが3つ以上のエリアに分かれるぶん構成は複雑になり、ファイアウォールのルールも増えます。ルールの1行が誤っていれば、通すべき通信が止まる、あるいは塞ぐべき穴が開く。設計と定期的な棚卸しの手間は、DMZを持たない構成より確実に増えます。そしてもう1つ、DMZは「通信の経路」を分離する仕組みであって、通信の中身までは検査しません。DMZ内の公開Webサーバーに対する、SQLインジェクションのようなアプリケーション層の攻撃は、経路が正規である以上DMZの仕切りだけでは防げません。ここは後述のとおり、WAFやIPS/IDSと組み合わせて初めて守れる領域です。

DMZ運用で実際に詰まる箇所｜ファイアウォールルールの棚卸しとログ集約

運用が破綻する典型は、ルールが増え続けて誰も消せなくなる状態です。案件ごとに「このIPからこのポートだけ」を追加していくと、数年で数百行のルールが積み上がり、どれが現役でどれが遺物か分からなくなります。対策は運用に組み込むしかありません。ルールへ申請番号と有効期限をコメントとして書き残し、四半期ごとにヒット件数ゼロのルールを洗い出して棚卸しの対象にします。firewalldなら --info-policy と --list-all の出力を構成管理に保存し、差分をレビュー対象にすると変更の追跡が効きます。

もう1つの詰まりどころがログです。DMZは外部との接点が集まる場所なので、ここのログこそ真っ先に見たいのに、ファイアウォール・Webサーバー・OSのログがそれぞれの機器に散らばったままになりがちです。少なくともDMZ内の全ホストと境界機器のログは1か所へ転送し、時刻同期を揃えたうえで保持期間を決めておきます。侵入の兆候を機械的に拾う段階まで進めるなら、次に置くのはIDS・IPSです。

クラウド時代のDMZ｜パブリックサブネットとセキュリティグループによる論理的分離

システムをクラウドに置く構成が広がり、DMZの作り方も物理機器の設置から論理的な設計へと軸足が移りました。考え方そのものは変わりません。「外に見せるサーバーと社内資産を、同じ区画に置かない」という原則を、クラウドの部品で実現します。

オンプレDMZとクラウドの「パブリックサブネット＝論理DMZ」の対応

AWSやAzure、Google Cloudでは、仮想ネットワーク（VPC／VNet）をサブネットに分け、インターネットから直接アクセスできるパブリックサブネットと、外部に露出しないプライベートサブネットを分けます。公開Webサーバーやロードバランサーはパブリックサブネットに、データベースはプライベートサブネットに置く。この配置が、そのままオンプレのDMZと社内LANの関係に対応します。物理的なファイアウォールを2台並べる代わりに、ルーティング設定でどのサブネットが外部と通信できるかを決める。パブリックサブネットは、いわば「論理的なDMZ」です。

用語と単位はクラウドごとに少しずれます。Google CloudはVPCのサブネットに関するドキュメントでサブネットをリージョン単位のリソースと定めており、AWSのようにアベイラビリティゾーン単位で切る前提とは異なる設計です。Azureではハブスポーク型のネットワーク構成が標準的な型として案内され、外部接点をハブ側の境界サブネットに集約し、業務システムはスポーク側の仮想ネットワークへ寄せます。DMZという名前は前面に出ませんが、「外部接点を1か所に集約して奥を守る」という構造は共通です。前段で受けるロードバランサーの振り分け方式そのものは、ロードバランサーの仕組みと種類で扱っています。

セキュリティグループ・ネットワークACLで通信を絞るクラウドの設計

クラウドでは、DMZ内サーバーへの通信制御を、セキュリティグループ（インスタンス単位のファイアウォール）とネットワークACL（サブネット単位のフィルタ）の2層で組みます。両者の性質の違いは、設計前に押さえておくべき相違点です。セキュリティグループはステートフルで、許可した通信の戻りは自動的に通ります。一方のネットワークACLはステートレスなので、戻りの通信を明示的に許可しなければ通信が片道で止まります。オンプレのDMZ設計から移ってきた直後は、この違いを取り違えて「行きは通るのに応答が返らない」事象に当たりがちです。

設計としては、粗い遮断（サブネット全体で特定レンジを拒否するなど）をネットワークACL、細かい許可をセキュリティグループに寄せるのが扱いやすい分担になります。オンプレのDMZで手で書いていたルールを、クラウドの設定として宣言的に管理できる形です。マネージドのロードバランサーやWAFサービスを前段に置けば、経路の分離と中身の検査を同じ構成の中で両立できます。オンプレからクラウドへネットワーク分離を移す設計は、既存構成の棚卸しから入るのが安全で、インフラ構築（AWS/GCP/Azure）では移行と新規構築の双方に対応しています。

ゼロトラストでDMZは不要になるのか｜境界防御との併存と移行順序

DMZを調べる担当者が次に突き当たるのが、「ゼロトラストの時代に境界の内外を分ける設計は古いのではないか」という疑問です。結論から言えば、DMZは不要になりません。ただし、DMZだけで守れる範囲は明確に狭まりました。

NIST SP 800-207が示す境界型防御の前提とDMZの位置づけ

ゼロトラストの参照文書であるNIST SP 800-207「Zero Trust Architecture」が問題視したのは、「ネットワークの内側にいる＝信頼できる」という前提そのものです。社内LANに入れた端末を無条件に信頼する設計では、認証情報を盗まれた1台から内部を自由に動かれます。DMZが守るのは外部からの直通経路であって、内部で起きる横移動には効きません。

両者は置き換えの関係ではなく、担う層が違います。整理すると次の通りです。

観点	境界型（DMZ前提）	ゼロトラスト
信頼の置き方	ネットワーク位置で判断	通信ごとに検証
守る単位	セグメントの境界	利用者・端末・リソース
公開サーバーの扱い	DMZに隔離	認証・認可の後段に置く
導入の前提	既存機器で始められる	IdPと端末管理の整備

ゼロトラストへ寄せても、インターネットに面したサーバーを社内資産と同じ区画に置いてよい理由にはなりません。境界を薄くする話と、境界を無くす話は別です。前提の違いはゼロトラストと境界型防御の違い・NIST7原則で詳しく扱っています。

DMZを残したままゼロトラストへ寄せる移行の順序と優先順位の判断軸

現実的な移行は、DMZを壊してから作り直すのではなく、DMZを土台に残したまま内側の検証を足していく順序になります。優先度の高い順に3段です。第一に、社内向けシステムへのアクセスを利用者と端末の認証で判断する形に変える。第二に、内部セグメントを業務単位で分け、横移動の範囲を狭める。第三に、通信経路そのものをクラウド側のゲートウェイへ寄せ、拠点のDMZ機器を減らす。第三段まで進めた構成が、SASE（構成要素とSSEとの違い）として製品化されている領域です。

逆に、外部接続を持たず専用線や閉域接続で完結する業務システムでは、DMZもゼロトラストも設計の主題になりません。ネットワークそのものを外部から切り離す選択肢との比較は、閉域網とVPN・専用線の違いで整理しています。

DMZを作るべきか｜自社構成での採用判断と、作らない選択の基準

ここからは構成図の説明ではなく、判断の話です。DMZは常に正解ではありません。設けるべき場面と、別の手段で代替したほうがよい場面を、条件付きで言い切ります。

DMZを設けるべき構成と、リバースプロキシ/WAFで代替できる場面

DMZを設ける価値が高いのは、自社で公開サーバーを複数台運用し、その裏に社内DBや業務システムを抱えている構成です。外部接点が多く、内部に守るべき資産が集中しているほど、経路を分離する効果は大きくなります。一方で、公開しているのが小規模なWebサイト1つで、その背後に守るべき社内システムが無い場合、専用のDMZを組む手間は過剰になりがちです。この規模なら、クラウドのマネージドサービス（マネージドWebホスティングやCDN＋WAF）に載せ、リバースプロキシで受ける構成のほうが、運用は軽く安全性も確保できます。判断軸はシンプルで、「DMZの奥に守るべき社内資産があるか」「その分離を自前で運用し続けられる人手があるか」の2点です。守る対象が薄いのにエリアだけ増やすのは、複雑さという名のリスクを自ら抱え込む選択になります。

DMZだけでは守れない領域と多層防御（IPS/IDS・WAFとの組み合わせ）

DMZを作っても、それ単体では防げない攻撃があります。DMZは通信の「経路」を仕切る仕組みで、正規のポートを通って届くアプリケーション層の攻撃には無力です。公開Webサーバーを狙うSQLインジェクションやクロスサイトスクリプティングは、443番の正規通信としてDMZに入ってきます。これを止めるにはWAFが要ります（Webアプリ層の防御はWAFの仕組みとファイアウォール・IPS/IDSとの違いで扱っています）。また、DMZ内サーバーへの侵入の兆候を検知し自動遮断するには、通信の中身の振る舞いを監視するIDS・IPSを重ねます。DMZは境界を区切る土台であり、その上にWAF・IPS/IDS・端末側の対策を積む多層防御が前提です。DMZ内の公開サーバーが受け取った不審なファイルそのものを、隔離環境で実行して検査する仕組みはサンドボックスとは何かで解説しています。DMZを1つ作れば安全、という理解で止まると、正規経路をすり抜ける攻撃をそのまま社内の入口まで通してしまいます。

よくある質問

DMZの検討でよく挙がる質問に回答します。

DMZとは何の略ですか？

DMZはDeMilitarized Zone（非武装地帯）の略です。もとは対立する二国間に設ける緩衝地帯を指す軍事用語で、ネットワークでは外部（インターネット）と内部（社内LAN）のどちらにも属さない中間エリアを意味します。ここに公開サーバーを置き、外部からのアクセスをこのエリアに閉じ込めることで、社内ネットワークへの直接の到達を防ぎます。

DMZにはどんなサーバーを置きますか？

外部と通信する必要があるサーバーを置きます。具体的にはWebサーバー、メールの中継サーバー、外向けのDNSサーバー、リバースプロキシ、公開用FTPサーバーなどです。逆に、データベースサーバーや業務システム、ファイルサーバーといった社内だけで使うものはDMZに置かず、社内ネットワーク側に隔離します。判断基準は「インターネットから直接アクセスされる必要があるか」です。

シングルファイアウォール型とデュアルファイアウォール型の違いは何ですか？

使うファイアウォールの台数が違います。シングル型は1台のファイアウォールに外部・DMZ・内部を別ポートで接続し、1台で3エリアを仕切る形です。コストと運用は軽い一方、その1台が突破されると仕切りが同時に失われます。デュアル型は2台でDMZを挟み、社内へ入るには2台を続けて越える必要があるため防御は厚くなりますが、機器代と設計の手間が2倍になります。中小規模はシングル型、高い機密要件の大規模環境はデュアル型が目安です。

クラウド環境でもDMZは必要ですか？

考え方は必要で、実装の形が変わります。クラウドでは物理的なDMZ機器を置く代わりに、VPCをパブリックサブネットとプライベートサブネットに分け、公開サーバーはパブリック側、DBはプライベート側に置く構成です。通信の制御はセキュリティグループとネットワークACLで行います。パブリックサブネットが論理的なDMZの役割を果たすため、「外に見せるものと社内資産を同じ区画に置かない」という原則はクラウドでも変わりません。

DMZとファイアウォールの違いは何ですか？

DMZは「ネットワークの区画（エリア）」の名前で、ファイアウォールは「通信を許可・遮断する装置」です。両者は対立する概念ではなく、DMZという緩衝エリアはファイアウォールの通信ルールによって作り出されます。1台または2台のファイアウォールで、外部・DMZ・内部の3エリア間の通信を非対称に制御することで、DMZが成立します。DMZは構造、ファイアウォールはその構造を実現する道具、という関係です。

家庭用ルーターの「DMZホスト」設定は企業のDMZと同じものですか？

別物として扱ってください。家庭用ルーターやブロードバンドルーターのDMZホスト機能は、指定した1台のIPアドレスに対して、外部からの通信をほぼ素通しで転送する設定です。エリアを分けているのではなく、フィルタを外しているだけなので、その1台が侵害されれば同じLAN内の他機器へ直接届きます。企業のDMZが「別セグメントに隔離して内部への転送を絞る」構造なのに対し、DMZホストは「1台だけ無防備にする」機能です。名前は同じでも、防御効果は逆方向に働きます。

DMZのサーバーにはグローバルIPとプライベートIPのどちらを割り当てますか？

現在はプライベートIPを割り当て、ファイアウォールやロードバランサーでNAT変換する構成が一般的です。サーバー自身にグローバルIPを直接持たせると、機器を入れ替えるたびにDNSの変更が必要になり、通信の入口を1か所に集約する設計も崩れます。DMZ用に10.0.10.0/24のようなプライベートレンジを切り、外向けのグローバルIPは境界機器側で保持する。クラウドでも同じで、EC2にはプライベートIPを持たせ、Elastic IPやロードバランサーを前段に置くのが標準的な形です。

ゼロトラストを導入したらDMZは廃止できますか？

廃止はできません。ゼロトラストが変えるのは「内側なら信頼する」という前提であって、インターネットに面したサーバーを社内資産と同じ区画に置いてよいという話ではないためです。実務上は、DMZによる経路分離を土台として残したまま、内部システムへのアクセスを利用者・端末の認証で判断する層を上に足していきます。拠点の境界機器をクラウド側のゲートウェイへ寄せて数を減らすことはできますが、外部接点を隔離する区画そのものは形を変えて残ります。