※ 2024 年 12 月 28 日現在の情報をもとに作成しています
1. はじめに
本記事では、SWG (Secure Web Gateway) の SAML 認証を有効にした際のオプション設定の 1 つ「IP サロゲート」について説明します。
Enable IP Surrogates for SAML
https://docs.umbrella.com/umbrella-user-guide/docs/enable-ip-surrogate
※ SWG を利用するには SIG または SIG 相当のサブスクリプション契約が必要です
2. (クッキー) サロゲートについて
英語のサロゲート (surrogate) は「代理」という意味ですが、SWG の SAML 認証におけるサロゲートは、「認証を代理する」という意味合いで使われます。
これをさらに具体的に表すと、「一度 SAML 認証が済んだ後は、一定期間、代理が認証を行うので、当面の間はユーザーが再認証させられることがない」と表現できます。
この代理による認証は、PC に保存されたクッキー情報に基づいて行われる方法と、ローカル IP アドレスに基づいて行われる方法があり、それぞれ「クッキー サロゲート」「IP サロゲート」と呼ばれます。
このうち、クッキー サロゲートは SWG の SAML 認証が導入された段階から用意されているもので、以下が大まかな処理の流れになります。
- SWG の SAML 認証を有効にしている環境において、ユーザーが最初の Web リクエストを SWG に送る
- SWG は Web リクエストを IdP (Identity Providers) にリダイレクトする
- ユーザーは IdP の指示に従ってユーザー認証を行う
- SWG はユーザーから IdP の認証結果を受け取り、問題がなければ、認証されたアカウント情報を含む SWG ドメイン (gateway.id.swg.umbrella.com) のクッキーをユーザーに発行する
- 最後に SWG は宛先のサイトから得た Web レスポンスをユーザーへ返すが、その時、宛先ドメインのクッキーにトークンを埋め込む
- それ以降、同じ Web ブラウザからの同じサイトへの Web リクエストを SWG が受け取ったら、クッキー内のトークンを確認し、そのまま Web レスポンスをユーザーへ返す
- また、同じ Web ブラウザからの新しいサイトへの Web リクエストを SWG が受け取ったら、SWG ドメインのクッキーにあるアカウント情報を確認の上、そのまま宛先のサイトから得た Web レスポンスをクッキー付きで返す
つまり、最初の SAML 認証後、新しいサイトにアクセスするたびに、トークン付きのクッキーを埋め込むことで、有効期限が切れるまでの間、SAML 認証が再度行われないようにします。
当然のことですが、クッキー サロゲートを使用するには、ユーザー側でクッキーを完全にサポートしている必要があります。
現在主流となっている Web ブラウザでは基本的に問題なく利用できますが、セキュリティの都合でクッキーを制限する設定をしている場合などにおいては、クッキー サロゲートが正しく動作しない可能性があります。
そういったクッキーを完全にサポートしていない場合の代替案として、IP サロゲートが SWG の SAML 認証に取り入れられました。次項で詳しく説明します。
3. IP サロゲートについて
IP サロゲートは、クッキーに保持されたトークンが SAML 認証後の代理をするのではなく、ユーザーのローカル IP アドレスが代理の役割を果たします。
IP サロゲートの設定箇所は、Umbrella Dashboard の導入 > 設定 > SAML設定画面で SAML 連携を行った後に表示されます。
※ 設定項目「ユーザの再認証」については、両方のサロゲート共通の設定となっており、再認証までの期間を「常にしない」「毎日 (24h)」「毎週 (24h x 7)」「毎月 (24h x 30)」から選択できます
以下に IP サロゲートの大まかな処理の流れを記載します。
- SWG の SAML 認証を有効にしている環境において、ユーザーが最初の Web リクエストを SWG に送る
- SWG は Web リクエストを IdP (Identity Providers) にリダイレクトする
- ユーザーは IdP の指示に従ってユーザー認証を行う
- SWG はユーザーから IdP の認証結果を受け取り、問題がなければ、認証されたアカウント情報とローカル IP アドレスを含む SWG ドメイン (gateway.id.swg.umbrella.com) のクッキーをユーザーに発行する
- 最後に SWG は宛先のサイトから得た Web レスポンスをユーザーへ返す
- それ以降、同じローカル IP アドレスからの Web リクエストを SWG が受け取ったら、そのまま Web レスポンスをユーザーへ返す
上記のとおり、IP サロゲートにおいてもクッキーは使用されます。アカウント情報とローカル IP アドレスをクッキーに保持することで、もしユーザーの PC 上で、ローカル IP アドレスが変化しても、SAML 認証を再度受けなくて済みます。
IP サロゲートにすることで、クッキー非対応の Web ブラウザが使えるようになるわけではない点に注意してください。ただし、IP サロゲートを利用することで多くのクッキーに関する互換性の問題を回避できます。詳しくは、以下のサポート記事を参照してください。
SAML IP Surrogates is now available for Umbrella SWG user identification
https://support.umbrella.com/hc/en-us/articles/5185728669460-SAML-IP-Surrogates-is-now-available-for-Umbrella-SWG-user-identification
より安全に利用できる便利な IP サロゲートですが、ローカル IP アドレスを使用することによるいくつかの制限事項があります。
まずは 1 つのローカル IP アドレスを複数のユーザーで共有してはいけないことが挙げられます。
例えば、ネットワーク経路の途中にある機器で NAT などにより IP アドレスが変換される場合や、何らかの共用 IP アドレスの仕組みを利用している場合は、IP サロゲートの使用は推奨されません。
※ 組織内に複数のネットワークトンネルがあり、それぞれに同じローカル IP アドレスのネットワークが存在する場合、サイトを分けることで共存できる仕組みが用意されています
また、そもそも SWG がユーザーのローカル IP アドレスを知る必要があることから、SWG の導入方法として、ネットワークトンネルと Proxy Chaining (XFF 必須) のいずれかに限られます。
以上のような制限事項に該当し、組織内に IP サロゲートを導入できないネットワークが存在する場合、指定したネットワークを IP サロゲートから除外し、そのネットワークだけクッキー サロゲートを使用するように設定することも可能です。
設定方法は簡単で、SAML設定画面内の「内部ネットワーク バイパス」をクリックし、導入 > 設定 > 内部ネットワーク画面であらかじめ作成した内部ネットワークのエントリーから除外したいものを選択します。
※ 画像内の「Networks」が Proxy Chaining 用の内部ネットワークで、「Network Tunnels」がネットワークトンネル用の内部ネットワークになります