オンプレミス型プロキシから「SWG」に上手く移行するには？考慮ポイントを徹底解説

インターネットアクセスにおいて、プロキシ（フォワードプロキシ）は有効なセキュリティ対策です。ゼロトラストモデルの登場により、社外でも社内でも同様のセキュリティを担保することが求められる中で、クラウドサービス型プロキシが普及し始めています。

オンプレミス型プロキシを利用している多くの企業においては、社外からはVPNクライアントを利用して、社内ネットワークに接続し、社内のプロキシを介してインターネットアクセスを行う方法を用いているケースも多いかと思います。

しかしながら、リモートアクセスの増加に合わせたVPN機器の増強やリプレースなどのリソース管理、脆弱性に対するバージョンアップなどの運用管理は十分に考慮して行っていく必要があります。VPN機器だけでなく、プロキシや通信経路上の機器も同様です。

これらの課題に対しては、オンプレミス型プロキシからクラウドサービス型プロキシに移行することで、対応可能です。

クラウドサービス型プロキシにより、経路上の各機器に対して検討する必要があったリソース管理や運用管理から解放され、高可用性や災害時のDR対策も併せて対応可能になります。さらに、クラウドサービス型のプロキシは、オンプレミス型プロキシより、高度なセキュリティ対策を包括して提供するSecure Web Gateway（SWG）として多くの製品が登場しています。

オンプレミス型プロキシを利用する企業の中には、クラウドサービス型プロキシ、SWGの導入を検討されているものの、どのような障壁があり、どのような考慮が必要なのかが不明瞭で踏み切れない管理者もいるかと思います。本稿では、このような管理者に向けて移行のイメージが持てるよう、考慮点をピックアップしてご紹介します。

▶「クラウド活用で複雑化したIT環境：効率的なセキュリティ運用策とはPrisma Access とSOC・MSS を組み合わせて自社の負担を軽減」を読む

SWG移行にあたって考慮するポイント

プロキシは特定の利用者や管理者の管轄で収まるアプリケーションサーバなどと異なり、一般的には、従業員の全員が利用しています。利用者が多く、セキュリティの要ともなるプロキシにおいて、「オンプレミス型プロキシで提供していた機能が低下・劣化しないことを目標」に置くことと思います。

そういった場合に、特にポイントとなる以下2点の考慮事項を取り上げてご紹介します。

• 機能差分に対する考慮
• 移行段階に対する考慮

機能差分に対する考慮

SWGにはプロキシにはなかった様々な機能が含まれます。もちろん、プロキシ機能単体をとっても、製品が異なることによる機能差分は少なからずあります。

※本項では、SWGとしてZscaler（Zscaler Internet Access：ZIA）を例に、機能差分の抽出方法の例と考慮ポイントをご紹介します。クラウドサービスの特性上、メーカによるバージョンアップや仕様変更により、機能・制御が変更になることがあるため、最新の情報をもとに対応することを推奨します。

①大まかな機能差分の確認

まずは、オンプレミス環境でのセキュリティ機能・制御と通信フローを整理する必要があります。通信経路上には、プロキシサーバだけではなく、ファイアウォールやIPSなどもあるはずです。プロキシサーバについても、URLフィルタリングやウイルスチェック、さらに、SSLデコード処理の有無も漏れなく抽出し、通信フローの整理を行います。

図1：オンプレミス環境におけるセキュリティ機能と通信フローの例

次に、SWGについてもメーカの紹介資料やマニュアル・ヘルプページを参照し、セキュリティ機能・制御内容および通信フローを整理します^[1]。

図2-1：SWGにおけるセキュリティ機能の例

図2-2：SWGにおける通信フローの例

オンプレミス環境とSWGにおいて、整理した機能・制御および通信フローを照らし合わせて、機能の不足や、制御順序の違いによる不都合がないかを確認します。

上記の例をもとに整理した内容を、数点ピックアップしますと、以下が確認できます。

• オンプレミス環境のセキュリティ機能はSWGで網羅できる
• オンプレミス環境の統合セキュリティ機器とファイアウォールで行っていたパケットフィルタリングは、SWGではファイアウォールコントロールで行われる
•   オンプレミス環境のプロキシで行っていたSSLデコードが、SWGでは通信の初めにSSLインスペクションで行われる

こういったパケットフィルタリングやSSLデコードの制御順序の変更が伴うため、通信不通や検知傾向の変化、ログ量の増減などが想定されます。

②機能レベルでの差分確認

大まかな機能差分を確認した後は、より掘り下げて各機能における差分を確認します。ここでは、影響の大きい「URLフィルタリング」、「パケットフィルタリング」の2点をご紹介します。

１．URLフィルタリング機能

プロキシのメイン機能です。これまでのオンプレミス型プロキシとの違いを考慮し、SWGにおける設計をします。

カテゴリ識別

Webサイトを特定のカテゴリに分類する機能です。カテゴリ項目や分類の基準は、製品によって異なるため、カテゴリの差分はどうしても発生します。オンプレミス型プロキシで設定しているカテゴリをSWGの新カテゴリに対して割り振りを行い、新しいカテゴリに対しても方針を検討します。

業務上重要なWebサイトなどについて、カテゴリの割り振り・方針検討をより細かく実施するために、オンプレミス型プロキシの特定カテゴリに判定されているWebサイトが、SWG上のどのカテゴリに含まれるのか、各製品の検索機能を利用して確認することを推奨します。

表1：製品による識別カテゴリの違いの例

※製品２は、本例で紹介※製品２は、本例で紹介のSWG：Zscaler（ZIA）の情報　　　

 ※製品２は、本例で紹介のSWG：Zscaler（ZIA）の情報

カスタムURLリストの記述方式

ホワイトリストやブラックリストなど、カスタムのURLリストに対しては、正規表現や部分一致での制御、およびワイルドカードの利用可否の違いにより、そのまま移行できないことがあるので考慮が必要です。

グループに対する制御方法

フィルタリング設定をグループに対して行う場合、製品の制御方法によっては、移行漏れを考慮する必要があります。例として以下の2つの制御方法を上げます。

• 特定グループに対して、許可・禁止するURL/URLカテゴリを設定する方法
• URL/URLカテゴリに対して、許可・禁止するグループを設定する方法

前者から後者へと制御方法が変更になる場合、ポリシーに対して、必要なグループの漏れがないよう移行に注意します。

ご紹介した2点の機能以外にも、ウイルスチェック・ファイル拡張子規制・ブラウザコントロールなどがあります。シグネチャの精度や対応拡張子、対応ブラウザの種類などの差異はありますが、機能においては特に大きな差異はありません。

２．ファイアウォール機能

統合セキュリティ製品や次世代ファイアウォールでは、「HTTP」「FTP」といった、アプリケーション指定で制御していることがあります。これに対して、SWG側でも同様にアプリケーション指定での制御に対応しているかを確認する必要があります。

例えば、購入したライセンスでは、TCP/UDPのポートレベルのL4レイヤーでの通信制御しか対応できず、アプリケーション指定で制御を行う場合、追加ライセンスの導入が必要なケースも考えられます。

③その他：クラウドならではの考慮点やSWGで提供される新機能

クラウドならではの考慮点

オンプレミス環境を経由する場合、利用企業を制限するために、企業が持つグローバルIPアドレスを送信元IPアドレスとして制御を行っているWebサイトがあるかと思います。

SWGになると、SWGが利用する送信元IPアドレスは、基本的にクラウドサービス提供者管理のIPアドレスになります。クラウドサービスによっては、SWGが利用する送信元IPアドレスを登録してしまうと、同じSWGを利用する他社もアクセスが可能になってしまうことがありますので、注意が必要です。

そのため、送信元IPアドレス制限を行っているWebサイトには、企業独自のグローバルIPアドレスを利用できるよう、必要に応じてオプションライセンスによる対応や、当該Webサイトのみオンプレミス型プロキシを継続利用するなど、接続方式を考慮する必要があります。

※Zscalerにおいては、Source IP AnchoringやZscaler-Managed Dedicated IPという機能により、送信元アドレスを制御することができます。^[2]

SWGで提供される新機能

その他、オンプレミス環境では利用していなかったセキュリティ機能がSWGに含まれていることがあります。今回の例では、クラウドアプリケーションコントロール機能が該当しますが、整理した通信フローの制御ポイントを確認して、活用・運用方法を検討しましょう（図2を参照）

URLフィルタリングの前段でアプリケーションの制御がされるため、URLフィルタリングで制御（カスタムホワイトリストでURLを列挙）しきれないアプリケーションレベルの制御や、アップロード・ダウンロードといった動作に応じた制御は、アプリケーションコントロール機能に任せることが可能です。

その他、アプリケーションコントロールの制御対象外のサイトや、URL単位の細かい制御を行いたいサイトは、従来のURLフィルタリングに任せるといったような、機能の棲み分けを行いましょう。

移行段階における考慮

移行段階においては、従業員向けの支援が大いに必要です。以下、移行時の考慮・検討事項をご紹介します。

• 従業員への事前の十分な周知・説明
• 社内ヘルプデスクなどの問い合わせ窓口の拡充

URLフィルタリングのカテゴリが異なるため、移行後に今まで閲覧できていたWebサイトへのアクセスができなくなることが往々にしてあります。そのため、従業員への十分な周知と問い合わせ体制の確保を行います。

各部署やグループの代表者による先行利用を行う段階的な移行

移行時の業務影響を減らす対応として、業務上特に重要なWebサイトが移行後も利用できることの確認と、事前のホワイトリストへの登録が有効です。そのため、トライアルユーザ等の代表者の先行利用による影響確認は重要です。

緊急時のホワイトリスト運用

Webサイトへのアクセス不可の問い合わせが入った際に、都度ログ調査にて禁止カテゴリへの分類状況などの確認を行うことが望ましいですが、調査時間が許容できない場合や、管理者の労力として耐え難い程の問い合わせが発生する可能性もあります。

期間限定での許可設定を行い、別途必要な社内手続き（禁止カテゴリURLへのアクセス許可申請など）を行っていただくなど、緊急時のホワイトリストへの登録方針を検討しましょう。

おわりに

本稿では、オンプレミス型プロキシからSWGへ移行するにあたって、特に考慮すべきポイントをご紹介しました。

上記以外にも非機能要件や運用要件に対する考慮も必要です。これらは、クラウドサービスという特性上、性能や冗長性、バージョンアップ運用など、サービス提供者側に委ねられる部分もあり、利用サービスに合わせた運用・管理方法の整備が必要となります。

ログ管理・監視、SOCについても考慮が必要です。特に重要なログの保存期間は、標準では社内ポリシーで定められた期間に達しないこともあるため、必要に応じて、外部保管やオプションライセンスの購入などの考慮も必要です。

移行にあたっての全容ではなく、あくまで一例ではありますが、導入にあたってのイメージや設計を行う上での参考となれば幸いです。

今回はSWGの例として、Zscaler社が提供するZscaler Internet Access（ZIA）をご紹介しましたが、企業にマッチする製品やライセンスを選択することも必要です。本稿は2023年7月時点の情報をもとに作成していますが、これ以降も様々な製品が登場し、各製品差別化のためにも機能エンハンスもめまぐるしく行われています。

一方で、機能エンハンスなどにより各製品において主流機能の有無では差が埋まりつつありますが、得意な分野というのも少なからずあります。

どのような製品を選択しても、本稿で取り上げた考慮ポイントは活用いただけるものと考えますが、SWGは、高機能な故に、製品選定段階から設計、運用においての考慮点も多くあります。SWGの導入・運用に長けた、マネージドサービスを活用することもご検討ください。

NRIセキュアでは、本稿で例に挙げたZscalerの他、NetskopeやPrisma Accsessなど、複数のSWG製品に対して、導入支援から運用監視までご提供が可能です（ゼロトラスト・コンサルティングサービス、OA・ワークプレイス環境 運用監視サービス）。お困りごとがありましたら、ご相談いただけますと幸いです。