My Home NW Lab

逸般の誤家庭のネットワーク

BIG-IP Forward Proxy構成では宛先指定による認証除外は標準機能で出来ない (v17.0.0時点)

BIG-IP Forward Proxy構成の認証の設定はPer-Session Policyで行いますが、宛先 (URL, FQDN, サブネット)を指定するのItemが存在しないため、宛先指定の認証除外標準機能では出来ません。
v17.0.0時点の情報となります。Forward Proxyにおける必須機能な位置づけとなりますが、筆者が実案件で担当した際はv15系の時点から対応していませんでした。

Visual Policy EditorのProfile Type: SWG-Explicitの設定画面

注記しますが IP Subnet Match のItemは送信元サブネットに対しての制御です。宛先に対する指定はできない点に留意してください。

特に影響が受けると想定されるのが、ServerやPCからのシステム的な通信になると想定されます。 例えば、Internetへの疎通性を確認するようなシステム系の通信や、監視のための通信に認証が介在してしまうと誤判定を招く可能性があります。 また、代替策として IP Subnet Match により送信元サブネット単位で認証除外してしまうと、当該アドレスに対しては認証の除外が行われるため、ユーザーの所属グループに応じた制御が出来なくなってしまいます。

あくまでも標準の機能では出来ないだけで、iRulesによるコード拡張で要件を満たせるかもしれません。
しかしながら、様々な条件をハード コーディングするか、Data Groupを用いて知恵縄のような複雑なロジックをくみ上げる必要があります。

そしてコード拡張するにしても、宛先URLと宛先サブネットでは if 文での評価方法が異なるため、データ構造的に一緒くたには出来ません。 具体的には www.example.com はURLですが、10.0.0.0/8 はサブネットのため評価方法を分ける必要があります。 更にURLの場合は、文字列比較が「前方・中間・後方・完全一致」の4パターンあります。また、正規表現を使用するのも可能です。

ここでの論点は、宛先の比較をiRulesで行う際に評価式の都合でデータ構造を分ける必要が出てくるため、Data Groupの保持数が増加する傾向になってしまう点です。 そのため、意識して設定データの保持構造を設計しないと、スパゲッティ コードのデータ構造版になりかねません。

認証除外のDataGroupのイメージ (一例)

筆者の経験談となりますが、設定データ保持の保持構造が異様な設計となり、Data Group数も異様な数に膨れ上がったため実際に運用が困難になりました。 もっと根本的な話をすれば、設計ですら他者に説明するのが困難なほどの難易度になっております。

URLフィルタリングに関わる設定データは、別のメーカーの機器に乗り換えする際も重要となるため、データ保持構造が複雑だと移行を妨げる原因になりかねませんし、ユーザーからの依頼ベースの日常的なURLフィルタリングの設定作業すら困難になります。

ちなみに、他社メーカーの機器であるProxySGであれば、宛先指定による認証除外は標準機能で実現ができます。 そのため、ProxySGからの既存踏襲での移行先としてBIG-IP Forward Proxyを検討している場合は、大きな問題として立ちはだかります。