DMZ(非武装地帯).

DMZ は 2 台のファイアウォール(または多脚構成のファイアウォール)に挟まれた境界サブネットで、インターネットから到達可能である必要があるシステム(Web サーバー、メールリレー、リバースプロキシ、VPN 集約装置など)を配置します。外側のファイアウォールは定義された受信トラフィックを DMZ に通し、内側のファイアウォールは DMZ から内部ネットワークへの通信を厳しく制限し、理想的には特定アプリプロトコルから特定ホストへのみ許可します。これにより万一 DMZ のホストが乗っ取られても、内部データへ到達するには強固なポリシー境界を超える必要があり、侵害の影響範囲を抑えられます。現代の設計ではゼロトラスト制御・WAF・マイクロセグメンテーションを重ねて境界をさらに強化します。

内側のファイアウォールが重要な理由

境界上のホストが内部システムに自由に到達できてしまえば、DMZ の価値はすべて崩れ去ります。2017 年の Equifax の侵害はその失敗パターンを如実に示しています。攻撃者はインターネットに面したオンライン異議申し立てポータルの未修正の Apache Struts の脆弱性(CVE-2017-5638)を悪用し、内部データベースへ移動して、2017 年 5 月から 7 月にかけて約 1 億 4,700 万人分のデータを持ち出しました。送信方向を厳しくフィルタリングした DMZ、すなわち侵害された Web アプリが内部へ任意の接続を開けない構成であれば、その横方向の移動を鈍らせられたはずです。

ここから 2 つの設計原則が導かれます。第一に、DMZ は準信頼であって決して信頼しないものとして扱うことです。インターネットからの受信ルールは狭く、DMZ から LAN への送信ルールはさらに狭くし、各サービスが必要とする正確なプロトコル・ポート・宛先ホストのみを許可します(Web 層は 1 つの API エンドポイントへ、メールリレーは 1 つの SMTP ホストへ)。第二に、両ゾーンにまたがるデュアルホームホストを避けることです。1 枚の NIC が侵害されるだけでファイアウォールが完全に迂回されてしまうためです。

クラウドの対応物は、物理ファイアウォールをサブネット・セキュリティグループ・NACL に置き換えます。ロードバランサーを前面に置いたパブリックサブネットと、アプリケーション層・データ層のためのプライベートサブネットという構成ですが、原則は同一です。すなわち、公開された層が通信できる相手を制限することです。

flowchart LR
  I[Internet] -->|inbound 443| OF[外側ファイアウォール]
  OF --> DMZ[DMZ サブネット<br/>web / mail / reverse proxy]
  DMZ -->|定義済みアプリプロトコルのみ| IF[内側ファイアウォール]
  IF --> LAN[社内 LAN<br/>DB / AD / ユーザー]
  DMZ -.->|遮断: LAN への<br/>任意の受信| LAN