「企業ネットワークの仕組み」のタイトルバナー。ティールのノード線で 3 ゾーンと門番(ゲート)を表したモチーフ。

この記事の要点

  1. 核心: 企業ネットワークは「3 つのゾーン + 二段の門番(ファイアウォール)」で組み立てられており、装置の「配置」と通信の「流れ」で捉えると、用語の暗記なしに自社の構成判断に使える土台になる。
  2. 対象読者: 社内システムやクラウド移行で ネットワーク構成の判断を任された企業の実務担当(製造業 IT 部門など、インフラ専任ではない方)。前提知識は不要。
  3. 得られる成果: 3 ゾーン地図 / 主要な部品の早見 / 実際の通信フロー 3 シナリオ / VPN と ZTNA の使い分け・クラウド接続方式の選び方 + 計画時・リリース前のチェックリスト。
  4. 扱わないこと(専門家 / 社内インフラ部門、または関連記事へ): 通信プロトコルの詳細・物理層の配線 / メールセキュリティ(SPF / DKIM / DMARC)/ 仮想化(VM・コンテナ)の分離原理 / ベンダ製品の優劣比較 / 個別環境の設計判定。

Key Points (for international readers)

  1. Core — Enterprise networks are built from three zones and two layers of gatekeepers (firewalls). Reading them by device placement and traffic flow — not by memorizing terms — gives you a foundation for your own design calls.
  2. Who this is for — practitioners asked to make network design decisions (e.g., manufacturing IT) without being infrastructure specialists. No prior knowledge required.
  3. Portable takeaway — the zone map, the traffic-flow lens, and the VPN-vs-ZTNA / cloud-connectivity choices hold regardless of jurisdiction; regulation is where jurisdictions diverge most (the US, EU, and Japan each differ — read the regulatory part against your own), and a few design inputs such as data residency and procurement can vary too.
  4. What's out of scope (for a specialist or the related posts) — protocol internals & physical layer / email security (SPF/DKIM/DMARC) / virtualization isolation (VM/container) / vendor product comparisons / case-by-case design judgments.

執筆時点: 2026-06 / 対象: 技術は法域に中立・規制のみ日本国内向け / last_updated: 2026-06-06 更新履歴: 2026-06-06 初版公開

本記事は教材であり、特定環境の設計助言ではない

本記事は 企業ネットワークの構成を理解するための一般的な整理 であり、特定のシステム・組織に対する設計助言やセキュリティ監査の代替ではありません。内容の正確性・完全性・最新性を保証するものではなく、製品名・サービス名・規制は改称や改正で変わります。実際の構成・移行・調達の判断は、必ず 社内のインフラ / セキュリティ部門・専門家・各製品の公式ドキュメント にご確認ください。本記事の情報は「現状有姿(AS IS)」で提供され、これを利用または信頼した結果生じたいかなる損害・損失についても、執筆者および YATA-NODE は一切の責任を負いません。ご利用は自己責任でお願いします。

本シリーズの位置づけ: YATA-NODE blog では、ここから「仕組みを理解するシリーズ」を始めます。本記事はその入口で、企業ネットワークの全体像を 1 本で掴むハブとして書いています。通信路を「どの層で何で守るか」といった一段深い話は 通信の守り方 で扱っています。権利・契約面が気になる場合は別シリーズの 公開前の権利チェック を参照してください。既存の短い考察記事とは別軸の「調査ベース長文解説」です(更新頻度は固定せず、情報が古くなった際に随時見直します)。

用語ミニ解説(はじめての方へ): 本記事で繰り返し出る言葉の最小限の説明です。

  • ゾーン: ネットワークを信頼度で区切った区画(社内 / 緩衝地帯 / 外部など)。
  • DMZ(De-Militarized Zone / 非武装地帯): 社外に公開するサーバを置く、内外の FW で挟まれた緩衝区画。
  • ファイアウォール(FW): 通信を許可 / 拒否する門番。IP・ポート・アプリ単位でルールを当てる。
  • プロキシ: 通信を代理で中継する装置。社員の外向き通信をまとめる「フォワード」と、外部からの入口をまとめる「リバース」がある。
  • ゲートウェイ: 何かの「出入口」に立ち、中継・検査・制御をする装置の総称(VPN ゲートウェイ = 社外から社内へ入る入口、など)。
  • (Software as a Service。ソフトを手元に置かず、ネット越しに使う提供形態)。
  • (Domain Name System。ドメイン名を IP アドレスに変換する、ネットの住所案内の仕組み)。
  • (データベース。データを保存・検索・管理する仕組み)。
  • (Transport Layer Security。通信を暗号化する仕組み。https:// を支える)。
  • (Virtual Private Network。公衆回線上に暗号化トンネルを作り、社外から社内へ安全に入る仕組み)。
  • (Virtual LAN。物理配線を変えずにネットワークを論理的に分割する仕組み)。
  • (Web Application Firewall。Web アプリへの攻撃〔SQLi / XSS 等〕を検知・遮断する防御)。
  • (Cross-Site Scripting。Web ページに悪意のスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃)。
  • (Content Delivery Network。利用者に近いサーバから配信し、高速化・負荷分散する仕組み)。
  • (Intrusion Prevention System。不正な通信を検知して自動で遮断する仕組み)。
  • (Intrusion Detection System。不正な通信を検知して警告する仕組み。遮断はしない)。
  • エッジ(ネットワークの出入口・末端側。外側との境界だけを指すとは限らず、内部の区切りも含む)。
  • レイテンシ(通信の遅延。データが届くまでにかかる時間)。
  • (政府情報システム向けに、クラウドサービスのセキュリティを評価・登録する日本の制度)。

ネットワーク機器は名前が多くて圧倒されがちですが、「どのゾーンの、どの境界に座って、何を守るか」という見方に揃えると、初めて見る装置でも位置づけを推測できるようになります。本記事は ①まず地図(3 ゾーン)を描き ②そこに主要な部品を置き ③実際の通信がどう流れるかを追い ④境界型からゼロトラストへの移行とクラウド接続の選び方、という順で、用語の暗記ではなく「配置と流れ」で理解していきます。

企業ネットワークは 3 つのゾーンに分かれる

伝統的な企業ネットワークは、信頼度の違う 3 つのゾーンに分かれています。まずこの地図を頭に入れると、後から出てくる装置が「どこに座っているか」で整理できます。

企業ネットワークの 3 ゾーン地図。左から Internet(信頼ゼロ)、DMZ(緩衝地帯)、社内 LAN(従来は信頼あり)。Internet と DMZ の間に Edge FW、DMZ と社内 LAN の間に Internal FW。
ゾーン何があるか信頼度
Internet外部ユーザ、クラウド SaaS、攻撃者(混在)信頼ゼロ
DMZ(緩衝地帯)外向けの Web / メール / DNS など公開サーバ中立(両側を FW で挟む)
社内 LAN社員 PC、認証サーバ、内部 Web / DB / ファイルサーバ従来モデルでは信頼あり

この 3 ゾーンの境界に、門番(ファイアウォール)が二段で立ちます。Internet と DMZ の間に Edge FW(境界 FW)、DMZ と社内 LAN の間に Internal FW(内部 FW) が座り、外から内へ深く入るほど厳しいルールを適用します。外部に公開する受け口(リバースプロキシや公開 DNS など)は DMZ に置き、実体の Web / アプリサーバや社内の重要データは Internal FW のさらに奥に隔離する — これが「多層で守る」の出発点です(シナリオ B で見るように、DMZ の受け口が社内側の実体サーバへ中継する形が一般的です)。

「信頼あり = 安全」ではない

従来モデルは「社内 LAN は信頼できる」という前提で組まれていました。しかし、いったん内部に侵入されると被害が一気に広がる(横展開、ランサムウェア)という弱点があります。この前提を見直すのが、後半で扱う ゼロトラスト の発想です。まずは「3 ゾーン + 二段 FW」という従来の地図を押さえ、そのうえで「その前提をどう補強するか」へ進みます。

主要な部品 — 何が・どこで・何を守るか

地図ができたら、そこに部品を置いていきます。装置の名前は多いのですが、実務でまず押さえたい中核は次の 9 種です。各行を「どこに置かれ、何を守るか」で読んでください。

部品何をするか(1 行)主な配置主に守る / 効く脅威
フォワードプロキシ(F-Proxy)社員の外向き通信を一元管理(URL フィルタ・ログ集約)社内 LAN の出口危険サイト・情報漏洩・C&C 通信
リバースプロキシ(R-Proxy)外部から社内 Web への入口を一元化(TLS 終端・振り分け)DMZ実サーバ IP の露出・TLS 管理の分散
ファイアウォール(FW)IP / ポート / アプリ単位で通信を許可・拒否ゾーン境界不要ポート経由の侵入・不正アクセス
WAF(Web アプリ専用の FW)HTTP の中身を見て Web 攻撃を弾くR-Proxy の前段 or 同居SQLi / XSS などの Web アプリ攻撃
DNS サーバ(内部 / 外部)名前解決(ドメイン名 → IP)。内部は社内向け、外部は公開応答社内 LAN / DMZ・クラウド不正な名前誘導・DNS 経由の持ち出し
Active Directory(AD)社員の身分証 + リソースの認可を管理社内 LAN認証情報の悪用・権限の過剰付与
SSO + MFA(統合ログイン + 多要素認証)1 度のログインで複数サービスへ + 2 要素以上で本人確認IdP(ID 提供者)パスワード使い回し・なりすまし
VPN暗号化トンネルで社外から社内へ入るDMZ / クラウド入口盗聴・なりすまし接続
ZTNA(ゼロトラスト型のアクセス)アプリ単位で都度検証して接続(用途により VPN を補完・置き換え)クラウド(Broker)VPN 突破後の横展開・過剰な公開範囲

このほかにも、可用性や配信・経路を支える部品(ロードバランサ、DDoS 防御、CDN、API ゲートウェイ、ルータ / VLAN、IPS/IDS など)がありますが、本記事では中核 9 種に絞ります。

この表の読み方: 部品は「外側(エッジ)→ 内側(社内 LAN・アプリ)」へ向かって役割が変わります。外側では通信をろ過し(FW / WAF / プロキシ)、内側ではアクセスを検証する(認証・ZTNA)。1 つの装置で全部を守るのではなく、「どこを誰が守るか」を重ねる(多層防御)のが要点です。次の章では、この部品たちを実際の通信が「どう通り抜けるか」で動かしてみます。

実際の通信はこう流れる(3 シナリオ)

部品の配置がわかったら、最後は「動き」です。代表的な 3 つの流れを追うと、どの経由点で何がチェックされるかが腑に落ちます。

2 つの通信フロー(簡素版)。上=シナリオ A(社員 PC → フォワードプロキシ → Edge FW → Internet、プロキシで URL 確認 / ログ集約)、下=シナリオ B(Internet → Edge FW → リバースプロキシ + WAF → 社内 Web、WAF で HTTP 検査・SQLi / XSS 遮断)。経路の詳細は本文参照。

シナリオ A: 社員 PC が外部 Web を見る(社内 → 外向き)

[社員 PC]
   ↓ ① ブラウザで https://example.com を開く
[社内 DNS サーバ]    → ② 名前を解決して IP を返す(必要に応じ外部 DNS へ再帰・フォワード)
[フォワードプロキシ] → ③ URL を確認、許可ならアクセス(ログを集約)
[Edge ファイアウォール] → ④ 出口ポート(443)の許可を確認・記録
[Internet]           → ⑤ TLS(443)でサーバへ接続
[example.com の Web サーバ]
   ↑ レスポンスは逆順。F-Proxy がキャッシュしていれば次回は速い

何が守られるか: F-Proxy が危険なサイトを遮断し(マルウェア対策)、アクセスログを集約します(後から監査できる)。Edge FW が不要な出口ポートを閉じることで、万一マルウェアが入っても外部の指令サーバ(C&C)と通信しにくくなります。

シナリオ B: 外部から自社 Web を見る(外 → 内向き)

[外部ユーザのブラウザ]
   ↓ ① https://www.example.co.jp を開く
[外部 DNS]            → ② R-Proxy の公開 IP を返す
[Edge ファイアウォール] → ③ 入口ポート(443)の許可を確認
[リバースプロキシ + WAF] → ④ TLS を終端、中身を WAF が検査(SQLi / XSS 等を弾く)
[Internal ファイアウォール] → ⑤ DMZ → 社内 LAN の通信が許可ルールに合うか確認
[社内 Web サーバ]
   ↑ レスポンスは逆順。R-Proxy で再暗号化して外へ

何が守られるか: WAF がアプリ層の攻撃(SQLi / XSS など)を弾き、R-Proxy が本物の Web サーバの IP を隠して攻撃面を縮小します。二段の FW により、DMZ を経由しても内部へ直接は届きません。なお、WAF を通り抜けてくるアプリ自身の弱点(認可ロジックの穴など)は別の備えが必要で、本記事では扱いません(誰に何を許すかの設計そのものは 認証と認可の基礎 を参照してください)。

シナリオ C: リモート社員が社内システムへ(2 通りを対比)

リモートワークでは「社外から社内へどう入るか」が論点です。従来の VPN と、現代的な ZTNA を並べます。

C-1: 従来の VPN モデル

[リモート社員 PC](自宅・外出先)
   ↓ ① VPN クライアント起動 → ID/パスワード + MFA
[VPN ゲートウェイ](DMZ or クラウド)
   ↓ ② 認証成功 → 暗号化トンネルを確立
   ↓ ③ 以後「社内 LAN の一員」として扱われる
[社内 LAN の任意のリソース] — ファイルサーバ / 内部 Web / DB など

→ 問題: 設定次第ではあるものの、いったん VPN がつながると 社内の広い範囲に到達できてしまいがちです(横展開のリスク)。ネットワークを細かく区切らないフラットな構成ほど、この傾向が強くなります。

C-2: ZTNA モデル(現代的)

[リモート社員 PC]
   ↓ ① アクセス先(特定アプリの URL)を指定
[ZTNA Broker](クラウド)
   ↓ ② セッション単位で評価し継続的に再確認: 身元(IdP)+ デバイス状態 + 場所 + 時刻
   ↓    OK なら対象アプリへトンネル(適切に設計すれば他リソースには届きにくい)
[特定の社内アプリ] — 適切に構成すれば横展開のリスクを大きく下げられる

→ 改善: アプリ単位で許可し、継続的に再評価するため、「社内 LAN が既定で丸ごと見える」状態がなくなります。この C-1 と C-2 の差こそが、次章のゼロトラストの核心です。

境界型からゼロトラストへ、そしてクラウド接続の選び方

「社内 LAN は信頼できる」という境界型の前提を見直し、アクセスをセッション単位で検証し、動的なポリシーで継続的に再評価するのがゼロトラストの考え方です。

境界型からゼロトラストへの移行図。左 Before=1 つの大きな信頼の輪(社内 LAN)+ VPN ゲートウェイ。右 After=信頼境界が消え、リクエストごとに判定。信頼境界がネットワーク全体からリクエスト単位へ縮小するメッセージ。
観点Before(境界型)After(ゼロトラスト)
信頼の単位ネットワーク全体(LAN)アプリ単位
認証のタイミング接続時に 1 回セッション単位 + ポリシーで継続評価
評価する情報ID + パスワード + MFA+ デバイス状態 / 場所 / 時刻
公開範囲VPN の IP がネットから見えるアプリは隠蔽、エージェント経由のみ
失敗時の影響認証を突破されると社内全部1 アプリのみ + 検知・ブロック可能

この発想の技術的な土台が NIST SP 800-207(Zero Trust Architecture) です。中核は「ネットワーク上の位置だけで信頼しない / アクセスはセッション単位で付与する / 動的なポリシーで継続的に検証する」という原則群で、シナリオ C-2 の「継続的に再評価する」流れはこれを具体化したものです [一次] NIST SP 800-207。

現実的な移行: 一気に VPN を捨てる必要はありません。VPN を当面残しつつ、新規のアクセスから順に ZTNA へ寄せるのが無理のない進め方です。特権ユーザ(管理者・インフラ・経理)から MFA を必須化し、アクセスログを集約しておくと、移行の効果も測りやすくなります。

オンプレとクラウドを併用する時代では、社内 LAN とクラウドをどうつなぐかも設計の分かれ目です。代表的な 4 方式があります。次の表で各方式の仕組みと主な使い所を整理し、実際は 規模・レイテンシ・コスト の 3 点で選びます。

方式仕組み主な使い所
インターネット + TLS公開エンドポイントを TLS で暗号化開発環境・低トラフィック
サイト間 VPN(IPsec)暗号化トンネルで拠点とクラウドを接続中規模、設定が比較的容易
専用線専用回線で低レイテンシ + 安定帯域(AWS Direct Connect / Azure ExpressRoute / GCP Cloud Interconnect が代表)大規模・ハイブリッド
Private Link / プライベートエンドポイントクラウドのサービス(DB / ストレージ等)をプライベート IP で受ける内部経路で DB / API へ

製品名は改称が早いため、選定時は各クラウドの公式ドキュメントで現行名と条件を確認してください。なお、ここまで挙げた F-Proxy / R-Proxy / DNS といった装置も、現代では多くが VM やコンテナの上で動くのが主流ですが、その分離の原理は 仮想化とサンドボックス入門 で扱っています。

クラウドや SaaS をつなぐ際は、接続方式と同じくらい「データの取り扱いと利用規約」も判断材料になります。規約・契約面は AI サービスを使う前に読む利用規約 で扱っているので、必要に応じて参照してください。

こうした設計の方向性は、公的な方針とも無関係ではありません。日本では、デジタル庁が政府情報システム向けに「ゼロトラストアーキテクチャ適用方針」を示しており [補助] デジタル庁 標準ガイドライン群、政府が使うクラウドのセキュリティ評価制度として ISMAP が運用されています [補助] ISMAP。また、能動的サイバー防御を導入するサイバー対処能力強化法が成立し、段階的な施行が進められています。本記事は制度解説を目的とはしませんが、ゼロトラストや MFA・アクセス制御の文書化は、公共・大企業の調達に関わる場面ほど計画段階から織り込んでおくと安全です(各制度の最新の適用範囲・期限は公式情報をご確認ください)。

まとめ

企業ネットワークは「3 ゾーン + 二段 FW」を土台に、部品の配置と通信の流れで読み解けます。最後に、自分のプロジェクトでそのまま使えるチェックリストを置きます(コピーしてお使いください)。

text
【プロジェクト計画時】
□ ゾーン分けを決める(社内 / DMZ / Internet、クラウドなら public / private サブネット)
□ DNS 設計を決める(内部用ドメインの命名規約、社内外の名前解決の分け方)
□ アイデンティティを統合する(AD / Entra ID 等を中心に SSO + MFA を必須化)
□ アクセス方式を選ぶ(VPN か ZTNA か。新規プロジェクトは ZTNA を優先)
□ クラウド連携方式を選ぶ(専用線 / サイト間 VPN / インターネット経由を規模で判断)

【リリース前 / 運用中】
□ WAF を有効化する(クラウド WAF または専用 WAF)
□ 公開エンドポイントを最小化する(可能なら Private Link で隠蔽)
□ 特権ユーザ(管理者・インフラ・経理)に MFA を必須化する
□ ログを集約する(FW / WAF / プロキシ / 認証基盤 / VPN のログをまとめる)
□ ZTNA 移行のロードマップを持つ(VPN を当面残しつつ新規から ZTNA へ)

関連記事: 公開前の権利チェック / AI サービスを使う前に読む利用規約

出典 / References

ゼロトラストの技術標準

主要プロトコル(IETF RFC)

クラウド接続(各社公式ドキュメント、代表)

日本の制度(公式)

各製品名・サービス名・制度は改称や改正で変わります。利用時は上記の公式情報で最新の名称・適用範囲・期限を確認してください。

ネットワークや環境の守りをテーマ別にまとめた連載を note「セキュリティマガジン」に置いています：セキュリティマガジン。

著者について

大手電機メーカーで制御工学から 20 年以上の電機・ソフトウェア開発、加えて個人開発 約 10 年の実務経験を持ちます。ハードとソフト、企業と個人の両面で「知らないとリスクになる」基礎から発信し、いずれは AI の実践的な活用法なども扱っていく予定です。詳しくは このブログについて。