"今からプロキシを立てる" 以外の選択肢を先に見る

「上長から "とりあえずプロキシを立てて" と言われた」「情報漏えい対策としてプロキシが必要らしい」「既存のプロキシがそろそろ EOL で、更新すべきか迷っている」──こうした相談は今も少なくありません。ただ、正直なところ、答えは会社によって割れます。

近年は SaaS 利用が中心となり、社内ネットワークを介さない通信も増えました。従来型のプロキシで全通信を絞る発想から、UTM への集約や、SASE / SWG ( Secure Web Gateway ) を含めた "出口対策の再設計" へと軸足が移りつつあります。中小企業の現場では、実際に「既存のプロキシサーバーを廃止して、UTM に機能を寄せる」ケースも増えてきました。運用効率化や機器集約 ( コスト削減 ) を狙った動きです。

つまり、選択肢は 1 つではありません。整理すると、次の 4 択があります。

1. 新たにプロキシを構築する ( Squid などで自社構築 )

2. 既存プロキシを同じ構成で更新する

3. UTM に集約してプロキシを廃止する

4. クラウド型 SWG に寄せる

本記事では、( A ) の構築手順を押さえつつ、( C ) の "UTM 代替" が現実的な選択肢になり得る条件を、機能単位で丁寧に切り分けます。

プロキシサーバーとは ─ フォワード / リバース / 透過型の違いを 1 分で整理

プロキシサーバーは、社内の端末から Web への通信をいったん受け止め、代わりに外部へ問い合わせて結果を返す "中継役" にあたる装置です。イメージとしては、事務所の受付が郵便物や来訪者を一度取り次いでから、社内へ通したり外へ送ったりする役割に近いといえます。端末から見れば通信相手は常にプロキシで、外部の Web サーバーから見れば通信相手は常にプロキシです。この "間に立つ" 位置取りが、後述するアクセス制御やログ取得を成立させています。

フォワードプロキシ

社内 → 外部方向、つまり従業員の PC からインターネット側へ抜けていく通信を仲介するタイプです。世の中で「社内プロキシ」「出口プロキシ」と呼ばれているものは、ほぼこの方式を指しています。本記事で主に扱うのもこのタイプです。

リバースプロキシ

向きが逆で、外部 → 社内方向の通信を最初に受け止める役割を担います。自社で運用している Web サイトや業務システムの前段に配置し、複数のバックエンドへ振り分ける、SSL 処理を集約する、公開範囲を絞る、といった使い方が中心です。用途も設計思想もフォワード型とは別物なので、本記事のスコープからは外します。

透過型プロキシ

端末側にプロキシ設定を入れずに、ネットワーク経路上で自動的にプロキシへ吸い込ませる方式です。利用者にはプロキシの存在が見えないため、端末の設定作業から解放される反面、経路設計や障害時の切り分けが難しくなります。手離れの良さと運用の難しさがトレードオフになる方式、と押さえておくとよいでしょう。

プロキシサーバーを構築する目的を、機能で分解する

"セキュリティー強化のため" だけでは、要件定義には落ちません。プロキシの機能を分解し、"自社では何を目的にしているか" を言語化する必要があります。この分解が、後段の "UTM で代替できるか" の判定にそのままつながります。

Web フィルタリング ( カテゴリー / URL 単位の制限 )

ギャンブル、アダルト、業務に無関係なサービスなど、あらかじめ決めたカテゴリーや URL への通信を止める用途です。運用してみると分かりますが、"完全なブラックリストを作り切る" というアプローチは長続きしません。SaaS の URL は日々増減し、業務利用の許可申請も継続的に発生するためです。カテゴリー方式を主軸に、個別 URL は例外運用として最小限に絞る設計が、実務では扱いやすい傾向にあります。

セキュリティー ( 悪性サイト・不正通信の遮断 )

フィッシングサイト、マルウェア配布サイト、C&C サーバーなど、業務利用の意思とは無関係に "そもそも接続させたくない" 通信を止める用途です。この領域はブラックリストの鮮度が命なので、脅威情報を継続的に更新する仕組み ( 有償のレピュテーションサービスや UTM のシグネチャ契約 ) とセットで考える必要があります。

通信ログの取得

どの端末が、いつ、どこへ通信したかを後から追える状態にしておく用途です。インシデントが起きた瞬間に威力を発揮する一方、平時は "とりあえず取っている" 状態になりがちです。ログを "活かせる状態" にするには、保存期間、閲覧できる人の範囲、確認するタイミングと責任者を、社内ルールとして先に決めておくことが欠かせません。

キャッシュ機能

一度取得した Web コンテンツを保存し、次回以降のアクセスを高速化・帯域節約する機能です。近年は HTTPS 化が進み、キャッシュが効きにくくなっていますが、社内ポータルや業務システムで一定の効果があるケースもあります。

ユーザー認証 ( ユーザー / グループ単位の制御 )

Active Directory などと連携し、"どのユーザーが、どのカテゴリーの Web にアクセスできるか" を細かく制御する用途です。部署や役職ごとのポリシーを厳格に運用したい場合に必要になります。

プロキシサーバーの機能は UTM で代替できるのか

プロキシサーバーの機能を UTM で代替することは、目的が Web フィルタリング ( 不適切サイトの閲覧制限 ) やセキュリティー対策 ( 悪意あるサイトへのアクセス遮断 ) であれば、十分に可能です。実際、運用効率化や機器集約によるコスト削減を狙って、既存のプロキシサーバーを廃止し UTM に集約する中小企業は少なくありません。

一方で、プロキシサーバー特有の "キャッシュ機能" や "認証機能" を目的としている場合は、UTM では代替しきれません。移行を検討するときは、"代替できる機能" と "できない機能" を機能単位で切り分けることが出発点になります。

中小企業で採用例のある UTM 搭載ルーターの一例として、バッファローの VR-U500X が挙げられます。別売の UTM ライセンスを追加することで、Web フィルタリング、アンチウイルス、不正侵入防御などの機能が利用可能になり、既存のプロキシサーバーで担っていた "Web フィルタリング" や "悪性サイト遮断" の役割を集約できます。ただし、これはあくまで "UTM 機能を備えたルーターの選択肢の一つ" であり、拠点数、ユーザー数、必要な認証機能、リモートワーカーの比率によって、上位機種の UTM やクラウド型 SWG の方が向くケースもあります。

機能単位の代替可否マップ

凡例：⭕ 代替可 / 🔺 一部代替可 / ❌ 代替困難

表を見たうえで、自社の状況を整理する観点

• 現在のプロキシの主目的が Web フィルタリング + 悪性サイト遮断 に集約されているなら、UTM への集約は現実的な選択肢です。

• キャッシュ機能で帯域を節約している 場合、UTM に寄せると帯域使用量が増える可能性があります。回線帯域とセットで再検討が必要です。

• Active Directory と連携したユーザー単位の Web アクセス制御 を行っている場合、UTM だけでは代替しきれず、SWG やアイデンティティー基盤との組み合わせが必要になることが多いです。

• 拠点・テレワーカーが多い 場合、本社集約型の UTM ではなく、クラウド型 SWG も比較対象に加えたほうが判断を誤りません。

構築前に整理すべき 6 つの前提 ( 導入前チェックリスト )

新設・更新・UTM 集約のいずれに進むにせよ、次の 6 項目は共通で整理が必要です。「軽微 / 要検討 / 要外部支援」で自己診断してみてください。

"要外部支援" が 2 つ以上あるなら、いきなり Squid での自社構築へ進む前に、UTM 集約やクラウド型 SWG も含めた再検討をおすすめします。運用まで含めた総所有コスト ( TCO ) で見ると、自社構築が必ずしも安いとは限りません。

プロキシサーバー構築の流れ ( Linux / Squid の例 )

自社構築を選ぶ場合、代表的な OSS である Squid を使った最小構成の流れを示します。検証環境での実装イメージとしてお読みください。

1. サーバー環境の準備

まず、プロキシを動かす土台を用意します。小規模な環境であれば、仮想サーバー 1 台からでも始められます。ただし、いざ本番投入する段階では、想定同時接続数、日次ログ量、キャッシュを有効化する場合の I/O 負荷を踏まえて、CPU・メモリ・ストレージ・回線帯域をひととおり見積もっておく必要があります。特にログ容量は油断すると数か月でディスクを埋め尽くします。

2. Squid のインストール

Ubuntu 系ディストリビューションでは、パッケージマネージャー経由で導入します。

sudo apt update

sudo apt install squid

sudo systemctl enable squid

sudo systemctl start squid

RHEL 系の場合は dnf を用います。

sudo dnf install squid

sudo systemctl enable squid

sudo systemctl start squid

ここで気をつけたいのが、"インストール直後の Squid" をそのまま業務に使わないことです。既定の設定ファイルは検証用途を想定した挙動になっており、そのまま起動すると想定外の範囲に対して応答してしまうケースがあります。次章の ACL を先に整えたうえで、実運用に移すのが安全です。

3. アクセス制御 ( ACL ) の設定

プロキシの心臓部にあたるのが、"誰の通信を通し、誰の通信を遮るか" を定義する ACL です。squid.conf に、自社ネットワークだけを許可する記述を加えます。

acl localnet src 192.168.1.0/24

http_access allow localnet

http_access deny all

http_port 3128

ACL の並び順は上から評価される点に注意してください。特に最後の "http_access deny all" は "許可リストに載っていない通信をすべて拒否する" という守りの一文で、この一行が抜けると意図せず外部からの通信まで受け付ける状態になりえます。設定を書き終えたら、シンタックスチェックとサービス再起動を挟みます。

sudo squid -k parse

sudo systemctl restart squid

4. 端末側のプロキシ指定

サーバー側の準備ができたら、各端末に "この IP とポートに向けて通信を投げるように" と指定します。台数が数十で収まる規模なら手動でも回りますが、それを超えると必ず設定漏れが発生します。Windows なら Active Directory のグループポリシー、Mac / モバイルなら MDM を経由した一括配布に切り替えるのが実務的です。

5. 動作確認

最後に、想定した挙動と実際の挙動が一致しているかを検証します。ここは "接続できた / できなかった" だけを見るのではなく、次の 3 点を組で確認します。

• 許可対象の端末から外部サイトへアクセスできるか

• 対象外の端末からは正しく拒否されるか

• アクセスログに、期待した粒度でイベントが記録されているか

ログが正しく取れていないと、後の運用フェーズで詰まります。

構築後にじわじわ効いてくる、運用の落とし穴

現場でよく聞かれる "しんどさ" を、時系列で並べてみます。

半年後にやってくるログ問題

運用開始直後は快調でも、3〜6 か月ほど経つ頃にストレージ使用量のアラートが鳴り始めます。ローテーション、圧縮、古いログのアーカイブ先、といった "後始末の設計" を、稼働前に決め切れているケースは多くありません。

右肩上がりで増える例外申請

新しい SaaS を採用するたびに「このサービスが開けない」という問い合わせが飛んできます。申請フォーム、承認者、反映タイミングを整えておかないと、担当者のメール受信箱が申請書で埋まります。

後回しになりがちなバージョン管理

Squid 本体や OS の更新、SSL 証明書の入れ替え、脆弱性情報のウォッチ。どれも "止めても誰も気付かない" 種類のタスクなので、後手に回りがちです。担当者が異動した瞬間に、更新が半年〜数年間止まる、というのはよくあるパターンです。

属人化する切り分け対応

「あのサイトだけ見られない」という個別事象は日常的に起きます。切り分け手順やナレッジ化が進んでいないと、そのつど担当者の記憶頼りの対応になり、その担当者が抜けた瞬間に立ち行かなくなります。

プロキシは "作れば終わり" ではなく、"作ったあと 3 年、5 年と回し続けられるか" で真価が問われます。この観点から見たとき、"運用対象の機器を UTM に集約して 1 台減らせる" という利点は、意外に大きく効いてきます。

プロキシが単一障害点になるリスクと HTTPS の扱い

全社通信を 1 台のプロキシに集約すると、そのプロキシが止まった瞬間に全社のインターネットが止まります。冗長化 ( アクティブ / スタンバイ ) や迂回経路の設計、監視・アラートの整備は、規模に応じて検討が必要です。UTM に集約する場合も同様で、小型ルーター型の UTM を単機運用する構成では、SPOF 化のリスクは残ります。

もう一つ悩ましいのが HTTPS 通信の扱いです。SSL インスペクションを行えばプロキシや UTM で中身を検査できますが、社内端末への証明書配布、対象外サイトの例外設定、労務・プライバシー面の説明責任が発生します。「見られるから見る」ではなく、「業務上どこまで必要か」を先に決めてから設計するのが順序です。

選択肢の比較 ─ 自社構築 ( Squid ) / UTM 集約 / クラウド SWG

プロキシの実装手段は Squid だけではありません。中小企業で現実的な選択肢を並べると、次のような整理になります。

"どれが正解" ではなく、"社内のスキルセット" と "拠点構成" と "残り耐用年数" の 3 点で決まる問題です。既存のプロキシが EOL を迎えているなら、置き換え先を Squid の再構築とするのか、UTM に集約するのか、クラウド SWG に寄せるのかは、この機会に整理しておきたい論点です。

外部委託・相談を検討すべきサイン

以下のいずれかに当てはまるなら、初期段階で外部の専門会社に相談する価値があります。

• 複数拠点にまたがる構成で、経路設計から必要になる

• HTTPS インスペクションを全社適用する予定がある

• 実質ひとり情シスで、運用継続と引き継ぎに不安がある

• 既存プロキシや UTM が EOL を迎え、更新方針が固まっていない

• プロキシの廃止・UTM 集約を検討しているが、代替可否の判断に自信がない

• ログの取り扱いについて、労務・法務との整理が必要になりそう

相談は必ずしも導入を意味しません。要件整理の壁打ち相手として使うだけでも、社内での意思決定はずいぶん進みます。

「作る」「更新する」「UTM に寄せる」を並べて考える

プロキシサーバーは、アクセス制御・ログ管理・セキュリティー強化を支える有効な仕組みですが、"作れること" と "作った後に回し続けられること" は別の話です。さらに、Web フィルタリングと悪性サイト遮断が主目的であれば、UTM への集約という選択肢も現実的です。ただし、キャッシュ機能や AD 連携のユーザー認証を使っているなら、そのまま UTM に寄せると機能が欠落します。

• 目的の分解：自社は何のためにプロキシを使っているのか

• 代替可否の切り分け：UTM で代替できる機能 / できない機能はどれか

• 運用の見立て：作った後、誰がどう回すのか

この 3 点を踏まえて、"作る" "更新する" "UTM に寄せる" を並べて比較することをおすすめします。

FAQ

Q1. プロキシサーバーの機能は、UTM に置き換えて廃止できますか？

目的が Web フィルタリング ( 不適切サイトの閲覧制限 ) やセキュリティー対策 ( 悪意あるサイトへのアクセス遮断 ) であれば、UTM への集約は十分現実的です。運用効率化や機器集約を狙って、既存のプロキシを廃止し UTM に寄せる中小企業も少なくありません。ただし、キャッシュ機能や AD 連携によるユーザー単位の認証を使っている場合は、UTM では代替しきれません。移行前に、機能単位で "代替できる / できない" を切り分けることをおすすめします。

Q2. VR-U500X のような UTM 搭載ルーターだけで、社内の Web アクセス制御は完結しますか？

Web フィルタリングと悪性サイト遮断が主目的なら、別売の UTM ライセンスを追加することで多くのケースで対応可能です。ただし、拠点数が多い、リモートワーカーが多い、AD 連携でユーザー単位の細かい制御を行いたい、といった要件がある場合は、上位機種の UTM やクラウド型 SWG との組み合わせを検討したほうがよい場面もあります。

Q3. 自社で Squid を構築する場合、どれくらいの体制が必要ですか？

小規模な検証環境なら 1 名でも構築できますが、運用フェーズでは日常の問い合わせ対応、例外追加の申請フロー、OS / Squid の更新、障害時の一次切り分けが発生します。実質ひとり情シスの体制では、引き継ぎ不能になるリスクがあるため、UTM 集約やクラウド型 SWG も含めた比較検討をおすすめします。

Q4. HTTPS 通信の中身は、プロキシや UTM で見るべきですか？

技術的には SSL インスペクションで可能ですが、証明書配布、対象外サイトの管理、労務やプライバシー面の説明責任がセットで発生します。「見られるから見る」ではなく、「業務上どこまで必要か」を先に定義してから、範囲を絞って適用する形が現実的です。

Q5. 既存プロキシが EOL です。まず何から手を付けるべきですか？

「同じ構成で更新する」「Squid で作り直す」「UTM に集約する」「クラウド型 SWG に置き換える」の 4 択で比較するのが出発点です。判断軸は、現在のプロキシで使っている機能 ( キャッシュ・認証を含むかどうか )、拠点構成、リモートワーク比率、社内で運用を継続できるかどうか。EOL 対応は、単なる置き換えではなく、出口対策の再設計の機会として捉えると、長期的な負荷を下げやすくなります。

まとめ

プロキシサーバー構築は、手順どおりに作ることよりも、「なぜ作るのか」「作った後、誰がどう回すのか」「そもそも UTM に集約できないか」を先に決めることが成否を分けます。本記事の代替可否表と 6 項目チェックリストが、自社の状況を整理する一助になれば幸いです。

横河レンタ・リース株式会社では、ネットワーク・サーバー・セキュリティーの設計から運用支援まで、中小企業のインフラ更新に関する相談を承っています。プロキシの新設・更新はもちろん、"UTM への集約で廃止できるか" の要件整理の壁打ちからでも構いませんので、必要に応じてお気軽にお声がけください。 

お問い合わせ (総合) | 法人向けパソコン (PC) ・計測器レンタルなら横河レンタ・リース