My Home NW Lab

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

ProxySGからBIG-IP Forward Proxy構成への乗り換え時の考慮点

ProxySGからBIG-IP Forward Proxy構成への乗り換え時の考慮点を、筆者の経験に基づいて記します。

目次

ProxySGからの更改の難しさ

筆者はProxySGからBIG-IP Forward Proxy構成への更改を経験しましたが、多くの考慮点という名の苦難の道がありました。

まず、ProxySGはForward Proxy製品の中でも業界トップ クラスに高機能です。 筆者自身はProxySGの製品導入経験はありませんが、更改プロジェクトで既存ProxySGに関わっただけでも高機能さを実感するほどです。

その高機能さ故に、BIG-IPへ既存踏襲で乗り換えを行おうとすると、ProxySGが標準で出来ていたものをiRulesによるコード拡張で対処する可能性が出てきます。

f:id:myhomenwlab:20210815223313j:plain
機能の既存踏襲の観点

コード拡張によって、通常はメーカーが担保している機能を一から作り込む必要があると、 ネットワークの知見だけに限らず、アプリケーション開発の知見や、脆弱性を生み出さないようにセキュリティの知見なども必要となります。 その他にもBIG-IP Forward Proxy構成の難易度を加味したプロジェクトの運営を行いながら顧客要件を取りまとめたり、 どのような過酷な難易度の状況に置かれても屈しない忍耐強さなども要求されます。

なお、個々の知見を持ったエンジニアをそれぞれアサインする方法がありますが、 BIG-IP Forward Proxy構成の処理フローを全体を把握していなければ設計・構築が困難となるため、 確実にマルチ スタックなベテランのエンジニアが必要となってきます。

f:id:myhomenwlab:20210815223116j:plain
ベテラン エンジニアの必要性

何故なら、BIG-IPへ入力された通信に様々な処理が適用されるため、処理フロー全体を見渡して理解する必要があります。 関数化して機能単位でフォーカスするような視点で十分ではないかと思われるかもしれませんが、 一連の処理が密接に関係しているため、部分的なフォーカスをしていると考慮漏れが生まれやすくなります。 そのため、様々な知見が各々に必要になります。

実装の一例としては、通信要件を満たすためのVirtual Serverを通信パターンに応じて個々に用意した上で、 待ち受け用のVirtual Serverから振り分けるような実装にした場合は、 多段Virtual Serverの構成となり、全体を見渡さないと設定影響範囲が大きく広がります。 例として紹介しましたが、多段Virtual Server案は現実に実在する実装方法です。 注意点として、画像1枚で表現しておりますが、個々のiRulesやPer-Session / Per-Request Policy毎の処理フローもあるため、これでも簡単に表現しております。

f:id:myhomenwlab:20210815223456j:plain
処理フロー全体を見渡す必要性

また、私が作成したスライド資料では300スライドを超えるほどの内容になっていますが、 それでもスタート ラインに立つための基礎的な話であるため、考慮漏れを起こさないためには全てを把握しておく必要があります。 上述の情報を総合すると、エンジニアへ求められるスキルの幅や質が異様なため、筆者は「超絶的な技術難易度」と表現しております。

speakerdeck.com

設定データの保持構造の観点

BIG-IP Forward Proxy構成でiRulesによるコード拡張を駆使すると、ロジックが複雑になる可能性があります。 そして、その複雑性が設定データの保持構造にも影響を及ぼします。 コード拡張を用いて実装すると、条件に応じて挙動を変えるための設定データを別途保持する必要が生まれます。 ロジックが複雑になればなるほど、条件を変えるための設定データの保持数が膨れ上がっていく可能性があります。 iRules自体に設定データを変数などとして保持する方法もありますが、コード直書き状態では編集ミスによるサービス影響が懸念されます。 そのため、iRulesから設定データの参照を行うためにData Groupを用いることになると想定されます。

f:id:myhomenwlab:20210821143428j:plain
Data Group設定画面のサンプル

そのData GroupはKVS (Key-Value Store)型のデータ構造となっております。 Firewall Policyのようなテーブル形式で設定データを保持する構造には向いていません。 しかし、ProxySGの場合は、Firewall Policyのように送信元セグメントや所属グループのような情報を柔軟に組み合わせて設定できます。 そのギャップをどのように埋めていくかが重要な設計要素となってきます。

f:id:myhomenwlab:20210821154846j:plain
設定データの保持構造

セキュリティ ポリシーをグループ会社などを含めて全社的に統一している場合は、 URLフィルタリングのポリシー セットを用途別にいくつか用意して、適用するだけかもしれません。 しかし、部署やグループ会社単位でのセンシティブな情報(例: 個人情報, 金融情報)の取り扱い有無や、サーバの用途などによって細かい粒度で適用するセキュリティ ポリシーを厳密に管理したい場合は、 Firewall Policyのように柔軟に組み合わせて設定できないと管理が難しくなる可能性があります。

そのため、ProxySGの設定データをBIG-IPのData Groupに移行/移植しようとすると、 一つの通信フローに対して、それぞれの条件が当てはまるように考えて作業を行う必要があるため、難易度が高くなります。

例えば、送信元セグメント, ホスト, 所属グループ単位で制御しようとすると、その粒度に応じてData Groupの数が膨れ上がったり、 iRulesに参照先のData Group名をハード コーディングするか否かの検討などが必要になります。 特に、文字列の比較では、完全一(equals), 前方一致(starts_with), 中間一致(contains), 後方一致(ends_with)のパターンがあり、 用途ごとにそれぞれの設定データ構造を一式保持するとData Group数が増大しやすい傾向になります。

f:id:myhomenwlab:20210821144244j:plain
Data Group(ユーザ定義データ)の参照の観点

Data Group名のハード コーディングを避けて、後からData Groupを追加しても参照できるようにする実装方法もありますが、 存在しないData Groupを参照してエラーが起きないようにハンドリングする必要があるため実装が複雑になります。

ユーザ定義データの保存先となるData Groupが増大していくと、既存の設定データをどのData Groupにどのように移行/移植したか追うのが困難になる問題もあり、 第三者のレビューで論理的に説明するのが難しくなる可能性があります。

f:id:myhomenwlab:20210821161023j:plain
肥大化するユーザ定義データの格納先

上述の内容を要約すると、複雑なロジックを加味した上で、複雑な設定データ移行/移植を行う可能性があります。 そして、厳密に静的に管理されているURLフィルタリングの場合は、 大量の設定データを対象に移行/移植の処理をする必要があり、難易度が設定データ数に比例して増大していきます。

そして、現状の要件を満たせても、時代の流れを踏まえての追加の要件が将来的に出てきた場合、 改修を行うには設定データ構造の見直しが必要になるかもしれません。また、既に設定済みの内容があるため、設定データ構造を一から再設定するのは困難になる点を踏まえる必要があります。

通信フローの制御要素の観点

一つの通信フローのアクセス制御を行うにも、一例を挙げれば、アクション, プロトコル, 認証有無, SSL復号化有無のような要素があります。勿論、その他の要素もあるかもしれません。 そして、設定やコードの修正を行う場合は、それら全ての一連の要素が想定通りの挙動をしているか確認する必要があります。 一つの通信フローに対する要素が増えるたびに、テスト ケースが増えていきますし、要素を保持するための設定データ構造の見直しが必要になるかもしれません。

f:id:myhomenwlab:20210821150820j:plain
一つの通信フローに対する条件パターン例

f:id:myhomenwlab:20210821150841j:plain
修正時の影響確認パターン案

上述の内容は、修正時の内容だけではありません。 そもそも一から設計・構築を行う際に、どのようなロジックにしたら全体的に俯瞰しても破綻しないかを常に意識する必要があります。 特に実装が難しい機能では試行錯誤の積み重ねとなり、何度も何度も全体的に処理フローに問題がないかを確認する必要が出てきて、骨の折れる作業になります。 例えるなら、常にBIG-IP Forward Proxy構成の処理フローを全体通りして見直しては、脳内でシミュレーションするような状態となり、 エンジニアの脳内CPUが焼き付き焦げるような状態となりかねません。

プロジェクトを円滑に進めるための案

改めて強調しますが、BIG-IPの標準機能で出来ないProxySGの機能を、iRulesによるコード拡張で実装すると、とても複雑となります。

その複雑性に対して、自社内で対応できるエンジニアが居なくても協力会社に頼る方法もありますが、 F5 Networksのパートナー会社であっても、対応に難儀するほどの複雑性を誇っているので一筋縄では行きません。

そのため、BIG-IP Forward Proxy構成を導入しなくてはならないのであれば、 F5 Networks社のコンサルティング サービスやチケット サービスをMUSTで購入をオススメします。 大事なので強調しますが、MUSTで購入をオススメします。 その上で、F5 Networksのパートナー会社への依頼の検討をオススメします。

ただし、コンサルティング サービスやチケット サービスを受けれたとしても、 考慮漏れがないように要件を伝えるのは顧客やSIerの責務となります。 そして、後から考慮漏れが発生すると、最悪の場合で、iRulesのコード改修に伴って設定データの保持構造の見直しが必要となり、膨大な改修コストが発生するかもしれません。 それではアプライアンス製品の特性を生かしきれなくなってしまうため、コード拡張を前提に導入する場合は十分な検討が必要です。

体制の構築と維持

iRulesを用いた既存踏襲での更改となると、コード拡張による複雑性が故に当初からプロジェクトに参画しているエンジニアでなければ全容を把握するのが困難となります。 顧客の要件に応じて、どのような実装方法にもなる可能性を秘めているため、 導入初期から運用フェーズや次期更改まで見据えてベテラン エンジニアを何人も確保して維持していないと、関係者のプロジェクトからの離脱に伴いブラック ボックス化する可能性が高くなります。

そのため、最初から総力戦を挑むような体制を組める体制があります。 それでも、途中で過剰なリソースを開放できれば良い方であり、超絶的な技術難易度の前では必要なリソースは未知数と言っても過言ではありません。

ですが、利益を生むための仕事で、一般的に総力戦をしようとするとコスト増になるため理解が得られません。それ故に、政治的にも難易度が高くなる恐れがあります。
具体的には、筆者が増員の進言を論拠に基づいて行っても、超絶的な技術難易度の前には思考を放棄されて、難しさが伝わらない状態となった実例があります。 その際は、超絶的な技術難易度 x 超絶的な政治難易度のダブル パンチで厳しい状況に陥りました。 そのため、政治力や鋼のメンタルもエンジニアには要求されます。

最後に

本記事ではProxySGの乗り換え先としてBIG-IPを対象としておりますが、 ProxySGの高機能さを理解して頂ければ、他の製品への乗り換えでも何かしらの考慮点が生まれるのは明白だと存じます。 実際、本経験を踏まえて、ProxySGからの乗り換え先候補となる各種Forward ProxyやSWG (Sevure Web Gateway)を調査しましたが、 筆者個人の考えとして、ProxySGと同等以上の高機能さを誇る製品は無いと感じました。

ですが、BIG-IP Forward Proxy構成は、iRulesによるコード拡張により無限の可能性を秘めているため、ProxySGからの更改候補となり得ました。 しかし、無限の可能性とは、同時に無限の考慮点を生み出す可能性があります。

f:id:myhomenwlab:20210821135720j:plain
コード拡張による無限の可能性と無限の考慮事項

無限の可能性に情報が収束せず、とある可能性に対してのとある考慮事項が無限地獄のように湧いてくる苦しみは未だに忘れられません。

同じような悲劇が二度と繰り返されぬことを願って此処に記しました。 BIG-IP Forward Proxy構成を担当される際は、本記事の内容を参考にしてプロジェクトを円滑に進めて頂けると幸いです。