基本情報 令和元年度 秋期 問42：テクノロジ系に関する問題

答えは c「WebをDMZに、DBを内部セグメントに」 です。

建物で例えると：

• 外部セグメント＝道路（誰でも歩ける）
• DMZ＝玄関ホール（お客様が入る場所）
• 内部セグメント＝金庫部屋（重要なものを守る）

Webサーバはお客様の窓口だから玄関ホール（DMZ）、データベースは大事だから金庫部屋（内部）に置くのが正解。

👉 覚え方：お客様接点はDMZ、大事なデータは内部。

ほかの選択肢：DBをDMZに置くと外部から狙われやすい／全部内部だと外部からWebが見えない／外部に置くと無防備。

なぜこれが正解か

正解は c。多層防御（Defense in Depth）の原則に従い、外部公開するWebサーバは DMZ（DeMilitarized Zone：非武装地帯）に、機密データを持つDBサーバは内部セグメントに配置する。これにより：

• 外部からの直接アクセスはDMZのWebサーバのみ
• DMZのWebサーバが侵害されても、内部DBへのアクセスは特定プロトコル（SQL等）に限定される
• 重要データへの2段階の防御線を構築

各選択肢の解説

• Web/DBともDMZ：DBが外部から比較的近く、侵害時の被害大。
• Web/DBとも内部：外部からWebサーバにアクセスできず公開目的を果たせない。
• Webを外部、DBをDMZ：Webサーバが無防備、DBも内部より外。最悪構成。

覚え方・ひっかけ注意

3セグメント構成の役割：

• 外部セグメント（インターネット側）：未信頼
• DMZ：外部公開サーバ専用、内部からも外部からも限定アクセス
• 内部セグメント（LAN側）：機密保護領域

公開サービス＝DMZ、機密データ＝内部を1セットで覚える。

理論的背景

DMZ（DeMilitarized Zone）は軍事用語「非武装地帯」に由来。ネットワークセキュリティでは境界防御モデルの中核概念で、信頼度の異なるネットワーク間の緩衝地帯として機能する。FW（ファイアウォール）のポリシー設計は：

• 外部 → DMZ：特定ポート（HTTPS:443、HTTP:80）のみ許可
• DMZ → 内部：必要なRPC／DB接続（SQL Server:1433、PostgreSQL:5432等）のみ
• 外部 → 内部：原則禁止
• 内部 → DMZ／外部：プロキシ経由で制限

DMZ構成パターン

• シングルFW三足構成：1台のFWで3セグメント分離（本問のパターン）
• デュアルFW構成：2台のFW（フロント＋バック）でDMZを挟む。コスト高だが多層化
• スクリーンドサブネット：教科書的な分離構成

現代的アーキテクチャの進化

• ゼロトラスト（Zero Trust）：境界防御を信頼しない。すべての通信を都度認証・認可。BeyondCorp（Google）、Zscaler、Cloudflare Access、Microsoft Entra Private Access
• マイクロセグメンテーション：仮想化／コンテナレベルでの細粒度分離。NSX、Calico Network Policy
• SASE／SSE：Secure Access Service Edge／Security Service Edge。クラウド統合セキュリティ
• WAF（Web Application Firewall）：L7攻撃（SQLi、XSS、CSRF）防御。AWS WAF、Cloudflare、ModSecurity
• IPS/IDS：侵入防止／検知。Snort、Suricata

実務での使われ方

• 3層Web系：プレゼン層（Web）をDMZ、ロジック層（APサーバ）を内部、データ層（DB）をさらに内部の3階層
• クラウド：AWS VPCのPublic Subnet（DMZ相当）＋Private Subnet（内部相当）＋NAT Gateway、Security Group／NACLで制御
• メールゲートウェイ／DNSキャッシュサーバ：DMZ配置の典型例
• リバースプロキシ：DMZでSSL終端、内部APサーバへL7振分け

試験での位置づけ

基本情報・応用情報・情報処理安全確保支援士・ネットワークスペシャリストで頻出。直近はゼロトラスト、SASE、クラウドセキュリティとの連動で出題増加。

選択肢の発展補足

WebサーバがDMZでDBが内部の構成では、SQLインジェクション対策（プリペアドステートメント）、APIエンドポイント認証（mTLS、API Key、OAuth2）、最小権限（DBユーザのテーブル別権限分離）が組合せられ多層防御を構成する。境界突破を想定して内部でも暗号化（TLS：mTLS）／認証を実施するのがゼロトラスト時代の標準実装。クラウドネイティブではサービスメッシュ（Istio、Linkerd）で東西通信のmTLS・認可ポリシを実現する。