キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
2174
閲覧回数
1
いいね!
0
コメント
tkitahar
Cisco Employee
Cisco Employee

 

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 認証が導入された段階から用意されているもので、以下が大まかな処理の流れになります。

 

  1. SWG SAML 認証を有効にしている環境において、ユーザーが最初の Web リクエストを SWG に送る
  2. SWG は Web リクエストを IdP (Identity Providers) にリダイレクトする
  3. ユーザーは IdP の指示に従ってユーザー認証を行う
  4. SWG はユーザーから IdP の認証結果を受け取り、問題がなければ、認証されたアカウント情報を含む SWG ドメイン (gateway.id.swg.umbrella.com) のクッキーをユーザーに発行する
  5. 最後に SWG は宛先のサイトから得た Web レスポンスをユーザーへ返すが、その時、宛先ドメインのクッキーにトークンを埋め込む
  6. それ以降、同じ Web ブラウザからの同じサイトへの Web リクエストを SWG が受け取ったら、クッキー内のトークンを確認し、そのまま Web レスポンスをユーザーへ返す
  7. また、同じ Web ブラウザからの新しいサイトへの Web リクエストを SWG が受け取ったら、SWG ドメインのクッキーにあるアカウント情報を確認の上、そのまま宛先のサイトから得た Web レスポンスをクッキー付きで返す

 

つまり、最初の SAML 認証後、新しいサイトにアクセスするたびに、トークン付きのクッキーを埋め込むことで、有効期限が切れるまでの間、SAML 認証が再度行われないようにします。

 

当然のことですが、クッキー サロゲートを使用するには、ユーザー側でクッキーを完全にサポートしている必要があります。

 

現在主流となっている Web ブラウザでは基本的に問題なく利用できますが、セキュリティの都合でクッキーを制限する設定をしている場合などにおいては、クッキー サロゲートが正しく動作しない可能性があります。

 

そういったクッキーを完全にサポートしていない場合の代替案として、IP サロゲートが SWG SAML 認証に取り入れられました。次項で詳しく説明します。

 

3. IP サロゲートについて

 

IP サロゲートは、クッキーに保持されたトークンが SAML 認証後の代理をするのではなく、ユーザーのローカル IP アドレスが代理の役割を果たします。

 

IP サロゲートの設定箇所は、Umbrella Dashboard の導入 > 設定 > SAML設定画面で SAML 連携を行った後に表示されます。

 

tkitahar_0-1672104945051.png

 

※ 設定項目「ユーザの再認証」については、両方のサロゲート共通の設定となっており、再認証までの期間を「常にしない」「毎日 (24h)」「毎週 (24h x 7)」「毎月 (24h x 30)」から選択できます

 

以下に IP サロゲートの大まかな処理の流れを記載します。

 

  1. SWG SAML 認証を有効にしている環境において、ユーザーが最初の Web リクエストを SWG に送る
  2. SWG は Web リクエストを IdP (Identity Providers) にリダイレクトする
  3. ユーザーは IdP の指示に従ってユーザー認証を行う
  4. SWG はユーザーから IdP の認証結果を受け取り、問題がなければ、認証されたアカウント情報とローカル IP アドレスを含む SWG ドメイン (gateway.id.swg.umbrella.com) のクッキーをユーザーに発行する
  5. 最後に SWG は宛先のサイトから得た Web レスポンスをユーザーへ返す
  6. それ以降、同じローカル 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設定画面内の「内部ネットワーク バイパス」をクリックし、導入 > 設定 > 内部ネットワーク画面であらかじめ作成した内部ネットワークのエントリーから除外したいものを選択します。

 

tkitahar_1-1672105017791.png

 

※ 画像内の「Networks」が Proxy Chaining 用の内部ネットワークで、「Network Tunnels」がネットワークトンネル用の内部ネットワークになります

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします