>
>
公開日
企業の情シス・IT管理者向けに、ネットワークセキュリティの中核を担う「DMZ（非武装地帯）」の基礎から最新の構成手法までをわかりやすく解説します。インターネットからの脅威から社内LANなどの内部セグメントを保護するため、本記事では、DMZネットワークの役割やファイアウォールを用いた構築パターンを整理します。従来の物理構成から、近年主流となっているクラウド環境での設計、ゼロトラスト時代における位置づけまでをカバーします。
DMZ（非武装地帯）とは
DMZとは、外部のインターネットと社内の安全なネットワークの間に構築する、公開サーバー専用の緩衝ネットワーク領域です。
本記事のポイント：
DMZは外部公開サーバーを社内LANから物理的・論理的に隔離し、万が一の不正侵入時にも内部セグメントへの被害拡大を食い止める。
ファイアウォールの構成には「シングル型」と「デュアル型」があり、自社のセキュリティ要件やコストに応じた多層防御設計が必要である。
ゼロトラストの普及に伴い、物理DMZから「クラウドDMZ（仮想DMZ）」への移行や「リバースコネクション（逆方向接続）」による脱DMZ化が最新のトレンドとなっている。
DMZの定義とセキュリティ上の役割
DMZは「DeMilitarized Zone」の略称であり、日本語では「非武装地帯」を意味するIT用語です。インターネットなどの危険にさらされた「信頼できない領域」と、社内LANやデータベースなどの「信頼できる内部セグメント」の中間に設けられます。demilitarizedの読み方は「ディミリタライズド」であり、軍事境界線において双方の武力を排除した緩衝地帯を指す言葉から転じて、IT分野のネットワーク構造を表す専門用語として広く定着しました。
情シス部門がDMZネットワークを構築する最大の目的は、外部公開しているWebサーバー、DNSサーバー、メールサーバーがサイバー攻撃によって侵害されたとしても、その被害を緩衝地帯に閉じ込め、社内LANのファイルサーバーや重要な社内システムへ攻撃が「ラテラルムーブメント（横展開）」するのを防ぐことにあります。公開サーバーは常にインターネットからの脅威にさらされているため、これらを直接社内ネットワークに接続することは極めて危険であり、DMZによる明確なセグメンテーションが基本設計として求められます。万が一公開サーバーが突破された場合でも、ファイアウォールによる適切な通信制御を行うことで、社内セグメントへの不正侵入を防ぎます。
▲ インターネット、DMZ、社内LANを隔離するDMZの基本ネットワーク構成と通信制御
DMZの仕組みとファイアウォール構成
DMZの構築には、ファイアウォールを適切に配置してトラフィックを厳密に制御する設計が必要になります。
DMZを実現するためのファイアウォール構成には、主に1台の機器で制御する「シングルファイアウォール型」と、2台以上の機器で多層防御を形成する「デュアルファイアウォール型」があります。さらに近年では、オンプレミスに依存しない「クラウドDMZ（仮想DMZ）」やAIを活用した動的制御が主流となっています。
シングルファイアウォール型構成
シングルファイアウォール型は、1台のファイアウォールに3つ以上の物理・論理ネットワークインターフェースを持たせ、それぞれ「外部（インターネット）」「DMZ」「内部（社内LAN）」に割り当てる手法です。アクセス制御リスト（ACL）の設定を1台の機器で一元管理できるため、構築の手間や機器の導入・運用コストを低く抑えられるメリットがあります。しかし、このファイアウォール自体が設定ミスやゼロデイ脆弱性などによって侵害された場合、すべてのネットワークセグメントが突破される「単一障害点（SPOF）」となるリスクを孕んでいます。
デュアルファイアウォール型構成
デュアルファイアウォール型は、外部ネットワークとDMZの間に1台目の外部ファイアウォールを設置し、DMZと内部ネットワークの間に2台目の内部ファイアウォールを配置する構成です。DMZを2台の機器で挟み込む「多層防御」を実現します。1台目と2台目で異なるセキュリティベンダーの製品を稼働（マルチベンダー構成）させることにより、片方の機器に脆弱性が発見された場合でも、もう一方の機器で防御を維持できるため、攻撃者が両方の機器を突破しなければならないため、侵害の難易度が大幅に上がります。この構成は、特に高い機密性を扱う金融機関や大企業のインフラとして広く採用されています。自社のセキュリティポリシーを確認したうえで、適切な構成を判断してください。
【比較表】シングル型とデュアル型の違い
比較項目 | シングルファイアウォール型 | デュアルファイアウォール型 |
|---|---|---|
機器コスト | 低い（FW1台の費用と保守で完結） | 高い（FW2台の本体購入費・保守ライセンス） |
ポリシー管理の難易度 | 低い（1台のポリシー定義で完結） | 高い（2台のFWで整合性を維持する必要あり） |
セキュリティレベル | 中（単一障害点のリスクを許容） | 極めて高い（マルチベンダーによる多層防御） |
推奨企業規模 | スタートアップ、中小・中堅企業 | 大企業、金融・医療機関、重要インフラ |
パブリッククラウド環境における「クラウドDMZ（仮想DMZ）」の標準化
オンプレミスのサーバー設備をAWS（Amazon Web Services）やMicrosoft Azureなどのパブリッククラウドへ移行することに伴い、物理ネットワークにおけるDMZから、仮想ネットワーク内のサブネット分離や、クラウド型次世代ファイアウォールを用いた「クラウドDMZ」が標準化されています。例えば、AWSのVPC（Virtual Private Cloud）において外部からのインバウンド通信を受け付ける「パブリックサブネット（クラウドDMZ）」と、顧客データなどを扱うDB（データベース）サーバーを保護する「プライベートサブネット」に分離する設計は、パブリッククラウドにおける設計の鉄則です。さらに、AWS Network FirewallやAzure Firewall Premiumはシグネチャベースの脅威検知機能を備えており、従来の静的ルールと組み合わせた多層防御が実現できます。機械学習を活用した動的なトラフィック分析を行う場合は、Amazon GuardDutyやMicrosoft Sentinel等の外部SIEMと連携することで実現できます。なお、Palo Alto Networks（VM-Series）やCheck Point CloudGuardといったサードパーティの次世代仮想ファイアウォール製品は、AIを活用した「動的ファイアウォール」機能（振る舞い分析・異常検知）をクラウド環境に組み込む選択肢として注目されており、静的ルールでは検知困難なゼロデイ攻撃への対応策として情シス部門での採用が進んでいます。
コンプライアンス（PCI DSS 4.0.1）によるDMZ設置の厳格化
クレジットカード情報を扱う企業において、セキュリティの国際基準である「PCI DSS 4.0.1」への準拠が義務付けられています。v4.0.1では要件1.2や1.3などのネットワークセキュリティコントロール（NSC）要件全体において、「インターネットとカード会員データ環境（CDE）の間にファイアウォール等のNSCを配置し、不要な通信を制限すること」が定義されています（なお、v3.2.1に存在した要件1.1.4は改訂時に整理・統合されています）。これにより、インターネット経由の不正アクセスが内部システムに直接到達しないように隔離することが、業界基準上のコンプライアンス要件として求められています。
▲ シングルファイアウォール型とデュアルファイアウォール型の特徴・リスク比較
DMZ構築時のアンチパターンとセキュリティ対策の注意点
DMZを構築する際は、DMZから内部ネットワークへのすべての通信を原則遮断することを大前提として設計する必要があります。
DMZをただ用意するだけではセキュリティは保たれません。ファイアウォールのルール設計やサーバー管理の運用方法に重大な欠陥がある場合、DMZを踏み台にして内部ネットワーク（社内LAN）まで容易に侵害されます。ここでは、情シス部門が設計・運用段階で避けるべきアンチパターンと対策を解説します。
アンチパターン①：DMZから内部への「不適切な通信穴あけ」と対策
DMZ内にある公開サーバー（Webサーバー等）がデータベース（DB）サーバーと通信する必要がある際、よくある誤解として「DMZから内部ネットワークのDBサーバー宛の通信ポートをすべて開放してしまう」という失敗があります。これが放置されると、Webサーバーがサイバー攻撃により乗っ取られた場合、攻撃者はその開いた穴を経由して内部のDBサーバーに格納されている顧客情報を容易に窃取できます。
この対策として、「DMZから内部ネットワークへの通信は原則100%禁止（Default Deny）」を徹底する必要があります。やむを得ずデータを連携する場合は、DMZからの接続開始要求を許可するのではなく、安全な内部ネットワーク側からDMZへ定期的にデータを取りにいく「ポーリング形式」を採用するか、どうしても双方向アクセスが必要な場合は、特定の送信元IPと「3306番（MySQL）」などの極小のポートのみを厳格にファイアウォールに静的設定する最小特権の原則を適用しなければなりません。万が一Webサーバーがランサムウェアに感染したとしても、この最小特権の原則が適用されていれば、内部への感染拡大を防ぐことができます。
アンチパターン②：脆弱性例外（パッチ適用見送り）の放置と対策
実務運用で最も多く発生しているセキュリティ事故の引き金が、DMZ上のサーバーやファイアウォール、VPN装置などの「脆弱性パッチ適用を『業務に影響が出る』という理由で見送り、そのまま例外運用として放置してしまう」ことです。WAFやアクセス制御リスト（ACL）などの暫定的な代替措置で一時的にしのぐつもりが、管理期限の曖昧さや監査の不備から数か月〜数年にわたって放置され、結果的に最新のゼロデイ脆弱性を突かれて社内ネットワークへの侵入を許すケースが多発しています。
対策として、情シス部門は「脆弱性パッチ適用例外」の承認ポリシーを厳格化し、最大適用猶予期間（例: 2週間以内）を設定、期間を過ぎた例外運用は自動的にネットワークから隔離される仕組みを運用プロセスに組み込む必要があります。
マイクロセグメンテーションによる「ラテラルムーブメント」の防止
従来のDMZは「インターネット、DMZ、内部LAN」という大きな3つのセグメントに分けるだけだったため、DMZ内で1台のWebサーバーが乗っ取られた場合、同じDMZセグメント内に存在するメールサーバーやDNSサーバーへ攻撃が「ラテラルムーブメント（横展開）」する脆弱性がありました。このリスクを排除するために、2025〜2026年現在はホストや仮想コンテナ単位で極小のセキュリティセグメントを定義する「マイクロセグメンテーション」の導入が推進されています。これにより、同一セグメント内であってもサーバー同士の不要な通信を一切禁止し、DMZ内での二次被害を最小限に抑え込みます。
【実用部品】DMZネットワーク・セキュリティ設計の診断フロー
自社のDMZが十分に機能しているかを検証するため、情シス部門では以下のステップを踏んで設定を監査してください。
STEP1：現在のFW設定（ACL）の棚卸し
外部からDMZへの通信ルールだけでなく、「DMZから内部セグメント」への通信許可ルールがどれだけ存在するかを完全に洗い出します。STEP2：通信の「方向性」の是正（Default Denyの徹底）
DMZ内のアプライアンスから社内ネットワークへの新規接続要求（インバウンド）を原則として全遮断し、通信開始の主権を常に内部セグメント側に持たせる設計へ変更します。STEP3：脆弱性パッチ適用のライフサイクル自動化
DMZ内に公開されているすべてのOS・ミドルウェアに対し、自動脆弱性スキャンツールを紐付け、CVSS（共通脆弱性評価システム）のスコアが「High」以上のものについては自動的に即時適用、または適用猶予アラートを出す運用フローを構築します。STEP4：多層防御ソリューションの整備
単なるIP・ポート制御だけでなく、アプリケーション層での攻撃を遮断するWAFや、不審なパケットの挙動を検知して遮断するIPS/IDSをDMZのインサイドに設置します。
ゼロトラスト時代におけるDMZの役割と移行事例
ゼロトラスト環境が主流となる現代においても、オンプレミスのレガシーシステムや一部の自社公開サーバーを保護する多層防御としてDMZは機能し続けます。
業務アプリケーションのSaaS移行やリモートワークの常態化に伴い、ネットワークの内と外を分けて守る「境界型防御」の限界が指摘され、すべての通信を疑って認証・認可を行う「ゼロトラストセキュリティモデル」へと舵を切る企業が急増しています。各種調査会社やセキュリティベンダーのレポートによると、過半数の企業が何らかの形でゼロトラストセキュリティモデルの導入を開始していると報告されています（出典：Gartner「Zero Trust Architecture」等、各社公開調査を参照。特定の単一レポートへの依存を避け、複数の一次情報をご確認ください）。
しかし、境界型防御（DMZ/VPNに依存するレガシー構成）からゼロトラストプラットフォーム（Zscaler Zero Trust Exchangeなど）に移行した企業では、Zscaler社が公表する導入事例（CSC社、Baker & Baker社等）において「インフラ複雑性の90%削減」「インフラコスト70%削減」といった効果が報告されています（個別事例によって数値は異なります。詳細はZscaler公式カスタマーページをご参照ください）。ここでは、実際に境界ベースのインフラから脱却し、ゼロトラストを成功させた日本企業の事例を紹介します。
国内企業におけるゼロトラスト移行・脱DMZ事例
事例①：武田薬品工業株式会社
業種・規模：製薬・グローバル展開（従業員数約5万人）
導入時期：2021年より段階的移行
課題：グローバル拠点や在宅勤務の増加により、従来の「社内ネットワーク＝安全」とする境界型ネットワークがボトルネックになり、外部接続のVPN帯域が逼迫していた。
施策：従来の物理境界ネットワークやVPNゲートウェイを順次廃止し、グローバル共通のIDベース認証を基軸としたゼロトラストアーキテクチャへと移行。
成果：場所を問わないセキュアなリモートアクセスをグローバルで実現し、ネットワークの遅延を解消、境界防御としてのDMZ管理コストの大幅な圧縮に成功。
事例②：株式会社LIXIL
業種・規模：製造・建材（グループ従業員数約5万5,000人）
導入時期：2022年導入
課題：基幹システムや多数の業務アプリケーションを抱える中、外部から社内アプリへアクセスするたびに、DMZに配置したプロキシサーバーやVPNを経由させる必要があり、管理が複雑化していた。
施策：AkamaiのIdentity-Aware Proxy「Enterprise Application Access（EAA）」を導入。
成果：インターネット上にDMZサーバーを一切介在させることなく、社内外からアプリケーションへ直接かつ極めてセキュアにアクセスできる環境を確立。物理DMZの保守運用負荷を大幅に削減した。
事例③：TIS株式会社
業種・規模：ITサービス・システムインテグレーション（従業員数約2万人）
導入時期：豊洲オフィス新設（2021年）を機に本格展開
課題：社内外のコラボレーションやDX推進にあたり、「社内ネットワークは安全」という境界ベースの管理が柔軟な働き方を阻害していた。
施策：社員の利用環境を「インターネットファースト（すべてのトラフィックをインターネットに流す）」に設計変更し、SASE（Secure Access Service Edge）を用いたゼロトラスト環境へ全面移行。
成果：場所に依存しない最高水準のセキュリティを確保し、かつDMZの維持に必要な物理ネットワークインフラの構成・保守運用負荷の劇的な軽減に貢献。
小規模自治体の事例：沖縄県恩納村教育委員会（2026年最新事例）
ゼロトラストやSASEの導入は大企業だけの特権ではありません。2026年の最新事例として、沖縄県恩納村教育委員会では、限られた予算と人員のなかで小規模環境に適したSASEソリューションを採用しました。従来の境界型セキュリティや複雑なネットワーク境界（DMZなど）の保守管理から解放されたことで、セキュリティ運用コストを「33%削減」することに成功したと報告されており（出典：各ベンダー公開の導入事例ページを参照）、教育機関におけるゼロトラストネットワークのコスト効果を示す事例として注目されています。
リバースコネクション（逆方向接続）による「物理DMZの廃止」トレンド
現代のゼロトラスト移行に伴う最新設計として、「リバースコネクション（逆方向接続）」による脱DMZアプローチが急速に普及しています。従来のDMZは、外部の接続元からDMZへ向けて「インバウンド（内向き）」の接続ポート（例: 80番や443番など）をファイアウォールに恒常的に開放する必要がありました。これはハッカーにとってのスキャン対象、つまり攻撃の入り口となっていました。
これに対し、Identity-Aware Proxy（IAP）やSASEのアーキテクチャでは、内部ネットワークに配置した「コネクター」と呼ばれる軽量エージェントから、外部のクラウドゲートウェイに向けて常に「アウトバウンド（外向き）」の通信セッション（リバースコネクション）を張りに行きます。ユーザーが社内アプリにアクセスする際は、この張られた外向きのセッションを再利用して内部に通信を通すため、ファイアウォールでインバウンドポートを開放する必要がまったくありません。これにより、外部に対して公開する「ポート」自体が消失するため、そもそも物理的なDMZセグメントを維持・構築する必要性がなくなるというパラダイムシフトが起きています。自社のSaaS管理（ゼロトラストの重要な柱）を進めつつ、レガシーシステムの保護においてこのようなリバースコネクション技術を活用することは、現代の情シス部門にとって有力な選択肢の一つです。
よくある質問
DMZやネットワーク境界の設計に関して、IT担当者や管理者から頻繁に寄せられる疑問について回答します。
Q：LAN（社内ネットワーク）とDMZの違いは何ですか？
A：LANは社内PCやファイルサーバーなどを配置し、原則として外部のインターネットから直接アクセスできないよう隔離された「最も安全な領域」です。一方のDMZは、外部からのアクセスが必要なWebサーバーやメールサーバーなどを配置するために、インターネットと社内LANの中間に設けられた「隔離された緩衝領域」であり、セキュリティの境界を区別する目的で設置されます。
Q：DMZ内にデータベース（DB）サーバーを配置してはいけない理由は何ですか？
A：DMZはインターネットに開かれた領域であるため、公開サーバー（Web等）が乗っ取られた際に直接DBの機密データ（顧客情報やパスワード等）へアクセスされてしまい、即座に大規模な情報漏洩につながるリスクがあるからです。DBサーバーは必ず内部ネットワークの安全な領域に配置し、DMZからは特定のポート（MySQLの3306番など）のみにアクセス権を絞った上で連携するのがセキュリティの鉄則です。
Q：クラウドDMZとは何ですか？オンプレミスと何が違いますか？
A：クラウドDMZとは、AWSのVPCやAzureの仮想ネットワーク（VNet）などのクラウド環境において、仮想的なサブネット分離や「Azure Firewall Premium」等の次世代仮想アプライアンスを用いて構築する、パブリッククラウド用の緩衝ネットワーク設計のことです。物理的なハードウェア（ファイアウォール製品等）を購入して配線する代わりに、すべてソフトウェア的に設定・スケールできる点や、AIによる動的なトラフィック検知を容易に組み込める点が異なります。
Q：マイクロセグメンテーションとDMZの違いは何ですか？
A：DMZは「外、DMZ、内」というネットワーク全体を大まかなゾーンに分ける境界防御ですが、マイクロセグメンテーションはホストや仮想サーバー、アプリケーション単位で極小のセキュリティセグメントを定義し、それぞれ個別にファイアウォール制御を適用する技術です。DMZ内で1つのサーバーが乗っ取られた際、同じDMZセグメントに属する別のサーバー（例えばメールサーバーからDNSサーバーなど）への横展開攻撃（ラテラルムーブメント）を防ぐための、よりきめ細かなゼロトラスト対策となります。
▲ セキュリティを担保するためのサーバー配置（DMZか内部LANか）決定フロー
まとめ
本記事では、企業の情シス部門やITインフラ管理者向けに、DMZ（非武装地帯）の基本定義やファイアウォール構成の設計、さらにクラウドDMZやゼロトラストアーキテクチャといった最新セキュリティトレンドとの融合方法まで解説しました。
デジタルセキュリティの重要性が高まる中、公開サーバーから社内LANへの経路が適切に遮断されているかを確認することは基本中の基本です。まず、社内で管理している「現在のネットワーク構成図」と、各ファイアウォールに設定されている「アクセス制御リスト（ACL）」を最新のセキュリティポリシーと突き合わせ、不要な通信許可が放置されていないか棚卸しすることから始めてみましょう。
【明日から取り組む】DMZ安全運用のチェックリスト：
✅ 社内のネットワーク構成図を開き、Web・DNS等の公開サーバーが本当にDMZに分離されているか確認する
✅ ファイアウォールのポリシーで、DMZ領域から内部セグメントへの通信が「原則遮断（Default Deny）」になっているか確認する
✅ DMZ内のアプライアンスやサーバーで、過去にパッチ適用を見送り「例外運用」として放置されている脆弱性がないか棚卸しする
✅ オンプレミスのレガシーなDMZ環境から、クラウドDMZや「リバースコネクション（逆方向接続）」への移行可否を検討する
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
