DMZとは何か

DMZは Demilitarized Zone の略です。

企業ネットワークでは、Webサーバーやメールサーバーなど、 インターネットからアクセスさせる必要があるシステムを、 社内LANとは別のネットワークへ配置するために利用されます。

なぜ公開サーバーを社内LANへ直接置かないのか

まず、DMZを使わない構成を考えてみます。

Webサーバーを公開するため、例えばインターネットから TCP/443 を許可します。

Webサーバーが正常な間は問題ありません。 しかし、Webサーバーの脆弱性が悪用され、 攻撃者に制御を奪われた場合を考えてみましょう。

Internet
   |
   v
侵害されたWeb Server
   |
   +--- Employee PC
   |
   +--- File Server
   |
   +--- Database Server
   |
   +--- Directory / Management Server

Webサーバーと重要システムが同じネットワークに存在すると、 侵害されたWebサーバーが内部探索や攻撃の足掛かりになる可能性があります。

そこで、公開サーバーをDMZへ分離します。

Internet
   |
[ Firewall ]
   |
   +---------------- DMZ
   |                    |
   |                 Web Server
   |
   +---------------- Internal
                        |
                        +--- Employee PC
                        +--- File Server
                        +--- Database Server

DMZ設計の基本となる3つのセキュリティゾーン

基本的なDMZ構成では、ネットワークを次の3つに分けて考えます。

DMZには何を配置するのか

DMZへ配置する候補は、 主にインターネットや外部ネットワークとの通信が必要なシステムです。

Web・AP・DBの3層構成をどう配置するか

企業システムでは、次のような3層構成がよく利用されます。

Web Server
    |
Application Server
    |
Database Server

3台すべてを同じDMZへ配置すると、 Webサーバーが侵害された場合にDBサーバーへ到達しやすくなります。

重要なのは、物理ファイアウォールを何台も設置することではありません。

VLAN、仮想ファイアウォール、セキュリティゾーン、 クラウドのセキュリティ制御などを利用して、 役割ごとに必要な通信だけ許可できる構造 にすることが重要です。

DMZの代表的な構成パターン

          Internet
              |
        +-------------+
        |  Firewall   |
        +-------------+
          /         \
        DMZ        Internal
         |            |
      Web Server    LAN

Internet
   |
External Firewall
   |
======== DMZ ========
   |
Internal Firewall
   |
Internal LAN

DMZ設計で最も重要なのは通信要件

DMZを作っただけではセキュリティ設計は完成しません。

最も重要なのは、 誰から、どこへ、何の通信を許可するのか を決めることです。

Internet → DMZのポリシーを設計する

WebサーバーをHTTPSで公開する場合を考えます。

Source      : Internet
Destination : Public-Web-Server
Service     : HTTPS / TCP 443
Action      : Allow
Log         : Enable

インターネットへ公開するのがHTTPSだけであれば、 必要のない管理ポートなどを許可する必要はありません。

Internet → TCP/443 → Web Server   Allow
Internet → TCP/22  → Web Server   Deny
Internet → TCP/3389 → Server      Deny

DMZ → Internalのポリシーは特に厳しくする

DMZ設計で特に重要なのが、 DMZから内部ネットワークへの通信です。

避けたい設定

Source      : DMZ
Destination : Internal
Service     : ANY
Action      : Allow

この設定では、DMZ上のサーバーが侵害された場合に、 内部ネットワークの多数のシステムへアクセスできる可能性があります。

絞り込んだ設定例

Source      : Web-Server-01
Destination : App-Server-01
Service     : TCP/8443
Action      : Allow
Log         : Enable

DB通信であれば次のようにします。

Source      : App-Server-01
Destination : DB-Server-01
Service     : TCP/5432
Action      : Allow
Log         : Enable

管理通信は業務通信と分離する

内部ネットワークの方が信頼度が高いからといって、 Internal → DMZ = ANY Allow にする必要はありません。

特に、SSHやRDP、管理GUIへのアクセスは管理経路として分けて考えます。

管理アクセスでは、次の項目も検討します。

• 管理端末の限定
• 接続元IPアドレスの限定
• 踏み台サーバー
• MFA
• 管理IDの分離
• 操作ログ
• 接続時間帯の制限

DMZ → Internetの通信も設計する

見落とされやすいのがDMZサーバーからインターネットへの外向き通信です。

DMZサーバーから、次のような通信が必要になる場合があります。

• OSアップデート
• セキュリティ定義ファイル更新
• 外部DNS
• NTP
• 外部API
• 証明書関連サービス
• SaaS

通信マトリクスを作る

DMZ設計では、構成図だけでなく 通信マトリクスを作ると設計を整理しやすくなります。

ファイアウォールポリシーの具体的な設計方法は、 前回の記事も確認してください。

42. ファイアウォールポリシー設計

NATとDMZを混同しない

DMZ設計でよくある誤解の一つが、 「プライベートIPアドレスを使ってNATしているから安全」 という考え方です。

Public IP
203.0.113.10
     |
    DNAT
     |
Private IP
10.10.10.10

NATとファイアウォールポリシー、DMZはそれぞれ役割が異なります。

DMZではルーティング設計も重要

DMZはセキュリティだけで完結する設計ではありません。

次のような通信経路が成立するか確認します。

Internet
   |
Firewall
   |
DMZ Server
   |
Firewall
   |
Internal Server

特にステートフルファイアウォールを利用する場合、 往路と復路が想定どおりの経路を通るか確認することが重要です。

例えば次のような非対称経路には注意します。

往路
Internet → Firewall-A → Web Server

復路
Web Server → Firewall-B → Internet

DMZ設計では、次の項目も確認します。

• デフォルトゲートウェイ
• スタティックルート
• 動的ルーティング
• NAT
• 冗長化時の経路
• 障害切り替え後の経路

DMZの冗長化設計

外部公開サービスの停止による影響が大きい場合は、 セキュリティだけでなく可用性も設計します。

             Internet
                 |
           Router × 2
                 |
          Firewall × 2
             HA構成
                 |
          DMZ Switch × 2
            /        \
          Web1       Web2

主な確認ポイントは次のとおりです。

• ファイアウォールを冗長化するか
• DMZスイッチを冗長化するか
• Webサーバーを複数台にするか
• ロードバランサーを利用するか
• インターネット回線を冗長化するか
• フェイルオーバー時にセッション維持が必要か
• 切り替え試験をどのように行うか

DMZの監視・ログ設計

DMZはインターネットからアクセスされる領域だからこそ、 通信やセキュリティイベントを監視できる状態にします。

クラウド環境ではDMZをどう考えるのか

クラウドでは、必ずしも 「DMZ」という名前の物理ネットワークを用意するとは限りません。

重要なのは、外部公開部分と重要リソースの間に セキュリティ境界を作ることです。

DMZ設計でよくある失敗

DMZ設計の進め方

1. 公開するサービスを確認する Web、メール、DNS、VPNなど、 インターネットから利用させるサービスを整理します。
2. 守るべき内部システムを確認する DB、認証基盤、ファイルサーバー、管理ネットワークなどを洗い出します。
3. セキュリティゾーンを決める Outside、DMZ、Application、Database、Managementなどに分類します。
4. 通信要件を洗い出す Source、Destination、Protocol、Port、Purposeを整理します。
5. 通信マトリクスを作る 必要通信を一覧化し、不要な通信を明確にします。
6. ファイアウォールポリシーへ落とす 必要最小限の通信だけを許可します。
7. 管理経路を決める 管理端末、管理ネットワーク、踏み台サーバーなどを決定します。
8. 冗長化を決める ファイアウォール、スイッチ、サーバー、回線などの単一障害点を確認します。
9. 監視とログを設計する 障害だけでなく、不正通信も検知できる状態にします。
10. 侵害を前提にレビューする DMZサーバーが侵害された場合にアクセス可能な範囲を確認します。

DMZ設計書へ記載する主な項目

顧客・上司へDMZをどう説明するか

技術に詳しくない相手へ 「DMZを作ります」とだけ説明しても、 なぜ必要なのかは伝わりにくいでしょう。

技術用語だけではなく、 「攻撃を受けた場合の影響範囲を小さくするため」 と業務上のメリットへ変換して説明します。

DMZ設計で使われる英語表現

設計レビューで使える表現

The public-facing web servers are located in the DMZ.
外部公開WebサーバーはDMZに配置されています。

Only HTTPS traffic is allowed from the Internet to the DMZ.
インターネットからDMZへはHTTPS通信のみ許可しています。

Traffic from the DMZ to the internal network is strictly restricted.
DMZから内部ネットワークへの通信は厳しく制限されています。

Administrative access is allowed only from the management network.
管理アクセスは管理ネットワークからのみ許可されています。

自分の言葉で説明する課題