![エンタープライズIT [COLUMNS]](https://ent.iij.ad.jp/wp-content/themes/liquid-smart-child/img/logo.svg){kind=logo}
プロキシ環境でもローカルブレイクアウトはできる！IIJがリリースした“新たな選択肢”を徹底解説
SaaSをはじめとするクラウド利用の拡大に伴い、主にインターネット宛の通信が増加しました。その結果、ローカルブレイクアウトのニーズが高まっています。しかし、プロキシサーバがあるとその接続が優先されるため、結果的にブレイクアウトがうまくいかず諦めていた企業も少なくないでしょう。IIJはこの“常識”を打ち破る新機能の提供を開始しました。プロキシサーバがある環境でも、運用の手間をかけずローカルブレイクアウトが可能なのです。導入も非常に容易です。新機能の仕組みと、それがもたらすメリットを徹底解説します。
- 目次
なぜローカルブレイクアウトが必要なのか？
コロナ禍をきっかけに働き方の多様化が進み、リモートワークが浸透しました。しかし、近年ではリモートワーク率は減少傾向となり、オフィスへ回帰する流れも見られます。また、DXの推進を背景に企業のオンプレ系システムのクラウド化、SaaS利用が増加し、脱オンプレの波も広がりました。
結果、新たな課題として、クラウドサービス向けのトラフィック増大が企業ネットワークの輻輳による通信遅延を引き起こし、業務に影響が出ています。
クライアント端末がインターネットを利用する場合、企業ネットワーク内のセキュリティを施されたインターネットGWを経由して接続する形が一般的です。ファイアウォールやWebフィルタリング、アンチウイルスといったセキュリティ機能に加えて、ログ収集や監査を行う企業ネットワークを経由することで、セキュアな通信が可能になるからです。
しかし、SaaSなどのクラウド利用が増えると、インターネット宛のトラフィックが増大します。特にBoxやOneDriveといったクラウドストレージ、ZoomやTeams などのWeb会議系通信はトラフィックを多く消費するサービスです。それがWANやインターネットGWなどの設備リソースを圧迫すると、企業ネットワークの輻輳や遅延を引き起こします。これによってアプリケーションの動作が重くなるだけでなく、基幹システムへのアクセスなど、業務にも大きな影響を及ぼします。
そこで企業ネットワークの負荷分散手段として、ローカルブレイクアウトが注目されています（図1）。ローカルブレイクアウトとは、自社のインターネットGWなどのネットワーク環境を経由せず、拠点から特定のクラウドサービス宛通信を直接インターネットへ脱出（ブレイクアウト）させる機能です。通信量の多い特定のSaaS宛通信を拠点から直接インターネットへ抜けるようにすることで、企業ネットワークの負荷を軽減します。
（図1）ローカルブレイクアウトイメージ
これによって「遅い」「つながりにくい」といった不満を解消できます。インターネットGW関連の既存環境を増強せず導入できるのも大きなメリットです。
プロキシの設定があるとローカルブレイクアウトできない理由
最近はSaaSの宛先をリスト化し通信を制御可能なローカルブレイクアウト機能を備えたSD-WAN機器も増えてきました。これらを活用すれば、容易にローカルブレイクアウトが可能です。しかし、これらの機器の中にはプロキシの設定がある場合、ローカルブレイクアウトできないといった課題がありました。
実際、セキュリティのためにプロキシサーバを運用している企業も多いでしょう。プロキシサーバは社内ネットワークと外部インターネットの間に置かれ、外部サイトへのアクセスを制御します。プロキシサーバが外部への通信の窓口となるわけです。
例えば、Web通信などのhttp/https を利用した通信を行う場合、クライアント端末はまず、プロキシサーバへ向かう設定があるかを確認し、設定が入っている場合、プロキシサーバへアクセスを始めます。途中のネットワーク機器で特定のSaaS宛についてローカルブレイクアウトする設定があったとしても、通信はプロキシ経由となってしまい、プロキシサーバの負荷を軽減できないのです。当然、企業ネットワークの輻輳や遅延といった問題は解決できません（図2）。
（図2）既存プロキシがあるため、ローカルブレイクアウトができない
（クリックして拡大）
ローカルブレイクアウトの“裏技”とその課題とは
ではプロキシの設定があるとローカルブレイクアウトするのは絶対に不可能なのでしょうか。手立てはあります。PACファイルを用いて、該当SaaSの宛先をプロキシの「除外対象」とする方法です。
PACファイルとは、プロキシサーバを経由してアクセスするかどうかを定義した設定ファイル。クライアント端末は、まずこのPACファイルを参照します。Web通信などの場合、プロキシサーバを経由するように定義されているのが一般的ですが、「除外対象」を定義すれば、ホスト名やURLに基づいて直接アクセスさせることも可能です。つまり、SaaSの宛先をプロキシ経由から除外することで、ローカルブレイクアウトが可能になるのです。
除外対象はPACファイルの定義変更が必要です。これは人が手作業で行います。定義変更自体は難しい作業ではありませんが、実はここにも大きな課題があります。
SaaSの宛先情報は不定期に変更されます。新アドレスや新FQDNはSaaSの提供元より公開されますが、変更時において対外的にアナウンスはされません。SaaSの宛先がいつ、どのように変更されたかを知るには、ユーザ自身が公開された情報を確認しなければなりません。その上で新しい宛先の除外設定が必要です。いつ変更されるかわからない情報を常にチェックしなければならないのです。その手間と負担は決して小さなものではありません。
更新が遅れた場合の影響も甚大です。「昨日までブレイクアウトできたのに今日はできない」という事態に陥り、業務が混乱してしまいます。
手立てはあるものの、こうした理由からプロキシ設定がある場合、ローカルブレイクアウトを諦めている企業が多いのです。
「プロキシ設定があるとローカルブレイクアウトできない！」をIIJの新機能が解決
プロキシ設定があっても人手によるPACファイルの更新なしにローカルブレイクアウトができる――。これを可能にしたのが、今回IIJがリリースした新機能です。これは「IIJクラウドプロキシサービス」と「IIJクラウドナビゲーションデータベース」の2つのサービスの連携で成り立っています。「IIJクラウドプロキシサービス」がPACファイルの置き場を、「IIJクラウドナビゲーションデータベース」がPACファイルの生成・編集・宛先のテンプレートを提供します。
先述したようにクライアント端末からの通信はまずPACファイルを参照します。このPACファイルにローカルブレイクアウトしたいSaaSの宛先を除外対象として設定することにより、プロキシの設定があってもプロキシサーバを経由せず、直接SaaSにつながるローカルブレイクアウトを実現できるのです（図3）。
（図3）既存プロキシがあってもローカルブレイクアウトを実現
（クリックして拡大）
Microsoft 365やWindows Update、Google Workspace、ZoomやBoxをはじめとする代表的なSaaSの宛先はあらかじめテンプレートとして用意されています。
運用を効率化し、ローカルブレイクアウトの用途も拡大
テンプレート化されているものは、SaaSの宛先変更にも自動で追従します。SaaSの宛先情報が変更されても、PACファイルの除外対象が自動で更新される仕組みです。手作業による変更作業は不要です。最新の宛先情報を確認する必要もないため、情報システム担当者の負担も軽減できます。設定更新漏れによってローカルブレイクアウトできないという心配もなくなります。
PACファイルは分かりやすいWeb UIで、任意に作成・編集することが可能です。テンプレート化されている特定SaaSの宛先以外にも、任意のSaaSや社内ポータル宛などをお客様自身で除外設定することができるのです。セッション数やトラフィックの状況に応じて、ローカルブレイクアウトするサービスを柔軟に変更する。そんなことも容易に行えます。セキュリティの関係上、プロキシサーバを通したい通信と、会社が直接接続を許可するSaaSの通信を柔軟に振り分けできるため、プロキシサーバの増強対応も不要です。
プロキシの設定があるからとローカルブレイクアウトを諦める必要はありません。IIJが実現した新機能はローカルブレイクアウトの「新たな選択肢」と言えるでしょう。
新たな設備投資をすることなく、容易に導入でき、SaaSの利用が拡大してもプロキシ設定の有無にかかわらず柔軟な振り分けによって企業ネットワークの負荷増大を回避できます。働き方改革やDXを加速させる大きな可能性を秘めています。
- 前の記事
- 次の記事