Secure Web Gateway 移行：カットオーバーおよびロールバックのチェックリスト
- SWGの移行には、通常の本番環境への切り替えと同様に、資産調査、パイロット運用、テスト、段階的な展開、およびテスト済みのロールバックが必要です。
- 認証、TLS証明書と例外処理、トラフィックステアリング、およびICAPやDLPとの連携には、最も大きなリスクが伴います。
- 新しいゲートウェイを並行して稼働させ、ユーザーを一斉に切り替えるのではなく、段階的に移行させる。
- ロールバック・トリガーと受け入れ基準は、インシデント発生時ではなく、最初の本番展開の前に定義しておくこと。
- 移行は、長年にわたり使われていないルールや時代遅れの例外を廃止する絶好の機会です。
secure web gateway の移行とは、Webトラフィックの検査およびポリシーを、あるプロキシプラットフォームから別のプロキシプラットフォームへ移行することです。移行先は、オンプレミスのアプライアンスから新しいアプライアンスへ、クラウドサービスへ、あるいはハイブリッドモデルへなど、さまざまなケースが考えられます。このチェックリストでは、資産調査、移行先の設計、ポリシーの変換、ロールバックの準備、パイロット運用、テスト、段階的な切り替え、および検収に至るまでの全プロセスを網羅しています。
この記事は、「ハイブリッドクラウドのセキュリティ」ガイドの一部です。Blue Coat 、ProxySG、およびSymantec Edge SWGに関する詳細については、「Blue Coat 」および「ProxySGのサポート終了：移行計画」をご覧ください。
フェーズ1：棚卸し
フェーズ1では、設計作業に着手する前に、現在のゲートウェイ環境、トラフィック誘導、識別情報、TLS検査、ポリシー、および連携状況について記録します。
インフラ
- すべてのゲートウェイ：モデル、ソフトウェアバージョン、設置場所、役割、およびサポート終了日（ProxySG および Edge SWG については、Broadcomのライフサイクルに関する記事をご確認ください）
- サイトごとのトラフィック量およびピークスループット（TLS復号の割合を含む）
- サイトごとのユーザー数およびリモートアクセスによるユーザー数
- アップストリームおよびダウンストリームのプロキシチェーン、ロードバランサー、およびフェイルオーバーの設計
トラフィック・ステアリング
- 明示的なプロキシ設定、PACファイル、およびWPAD
- 透過型インターセプトポイント（WCCP、ポリシーベースルーティング）
- 支線からのトンネル（IPsec、GRE）
- エンドポイント上のエージェント
- インターネット直販の例外
アイデンティティ
- 認証領域（SAML、Kerberos/IWA、LDAP、クライアント証明書）
- ポリシーで使用されるグループのマッピング
- 認証されていないトラフィック（サーバー、IoT、OT）とその処理方法
TLS検査
- 検査CA、主要な配置場所、有効期限、および配布方法
- 復号バイパス一覧（理由および担当者を含む）
方針
- ルールの順序、カテゴリ、カスタムリスト、例外を含む、ポリシー全体のエクスポート
- 過去90日間でヒットがないルール（廃止候補）
連携
- ICAPとDLP、ウイルス対策、サンドボックスとの連携
- SIEMおよびレポート作成ツールへのログ転送
- 監視とアラート
フェーズ2：ターゲットの設計
フェーズ2では、各サイトおよびユーザーグループの検査対象箇所を決定するとともに、トラフィック、証明書、ログの取り扱い方法を定めます。
- 各サイトおよびユーザーグループについて、検査を行う場所（オンプレミス、クラウド、またはハイブリッド）を決定します。
- それぞれについて、トラフィック誘導方法を定義します。管理対象ネットワークの場合は「明示的なプロキシ」または「PAC」、ローミングユーザーの場合は「エージェント」または「ブラウザ制御」、支社の場合は「トンネル」です。
- 各フローが1回だけ復号されるよう、TLS検査の位置を確認してください。NSAのガイダンスでは、企業ネットワーク内で1回だけ検査を行い、プロキシの連鎖による冗長な検査を避けるよう推奨しています（NSA）。
- 復号化後のピークスループットおよび将来の成長を見込んだ容量
- 高可用性と障害時の挙動の設計
- ログおよびDLPの証拠データをどこに保存するかを決定する
- 新しい検査用CAの導入または既存のCAの移行を計画し、サポートされている鍵保管方法および必要なHSM統合を確認する
フェーズ3：政策の具体化
フェーズ3では、既存のポリシーを、単純なファイル変換ではなく、体系化され検証済みのマッピングを通じて、新しいプラットフォームに反映させます。
- 各ソースルールを対応するターゲットルールにマッピングするか、廃止対象としてマークする
- ベンダー間のURLカテゴリを照合し、影響の大きいカテゴリについて差異を確認する
- カスタムリスト、許可リスト、ブロックリストを再作成する
- 認証に依存するルールを変換し、グループのマッピングを確認する
- 復号化のバイパス手法を再現し、それぞれについて継続的な必要性を検討する
- 可能な場合は、ICAPベースのDLPハンドオフをプラットフォーム独自のデータ保護サービスに置き換え、検査が行われる場所を確認するか、連携を再構築する
- 構成変更管理プロセスに従い、すべての変更および廃止されたルールを、その理由とともに記録してください（NISTSP 800-128には、セキュリティに重点を置いた構成管理の実践方法が記載されています）。
一部のプラットフォームでは、既存のポリシーをインポートする機能を提供しています。どのようなインポートであっても、あくまで出発点に過ぎず、その後も確認とテストが必要であることを念頭に置いてください。
フェーズ4：ロールバックの準備
フェーズ4では、パイロット実施前にロールバックのトリガーと仕組みを定義します。パイロット期間中にロールバックのテストを行い、各本番展開の前に準備が整っていることを確認します。
ロールバック・トリガー（例）
- 合意された閾値を超える認証失敗
- 合意された時間を超えて利用できなくなった業務に不可欠なアプリケーション
- 基準値の一定倍数を超えるヘルプデスクのチケット
- セキュリティ対策が実施されていないことが確認された
ロールバックの仕組み
- 最終検収が行われるまで、旧ゲートウェイを稼働させ、パッチを適用し続けてください
- PACファイル、DNS、およびルーティングの変更にはバージョン管理を行い、元に戻せるようにしておく
- ロールバックの所要時間の見積もりにおいて、DNSおよびPACのキャッシュ時間を考慮に入れる
- 移行期間中、旧検査用CAが各デバイス上で引き続き信頼されていることを確認してください
- ロールバックを承認できる担当者を指定し、その手順を文書化する
- パイロット期間中にテストのロールバックを行い、各切り替えフェーズの前に準備状況を確認する
フェーズ5：パイロット
フェーズ5では、新しいゲートウェイについて、旧ゲートウェイと並行して、少なくとも1つのビジネスサイクルにわたり、代表的なパイロットグループによる運用を行う。
- 主要な部門、デバイスの種類、および拠点を代表するパイロットユーザーを選定する。これには、ITスタッフや、ビジネス部門のパワーユーザー数名も含まれる。
- 新しいゲートウェイを、古いゲートウェイと並行して稼働させる
- PAC、エージェント、またはルーティングの変更（これらは迅速に元に戻せるもの）を通じて、パイロットトラフィックを新しいゲートウェイに誘導する
- パイロットユーザーに対し、問題を報告するための明確な手段を提供する
- パイロット事業を、必要に応じて月末を含め、少なくとも1つの完全なビジネスサイクルにわたって継続する
フェーズ6：テスト
フェーズ6では、認証からパフォーマンス、フェイルオーバーに至るまで、ユーザーが違いを実感するあらゆる領域をテストします。
| テストエリア | 確認すべき事項 |
|---|---|
| 認証 | ユーザーとグループは正しく識別され、SSOは正常に機能し、認証されていないシステムトラフィックは設計どおりに動作する |
| カテゴリとURLに関するポリシー | 「許可」「ブロック」「警告」の各カテゴリは、ソースと同様に動作します |
| TLS検査 | すべての管理対象デバイスで証明書が信頼される；ワークをバイパスする；ピン留めされたアプリが機能する |
| 脅威からの保護 | テスト用のマルウェアサンプルおよび既知の悪意のあるURLはブロックされます |
| DLP | アップロード時に、各データクラスに対応するテストドキュメントが検出されます |
| ビジネス向けアプリケーション | ビジネスに不可欠なWebアプリおよびSaaSトップ50のエンドツーエンドの運用 |
| パフォーマンス | ページの読み込み時間とピーク時のスループットは許容範囲内である |
| ログ記録 | イベントは、所定のフィールドを含む状態でSIEMに送信されます |
| フェイルオーバー | ゲートウェイノードの障害は、ユーザーに影響を与えることなく処理されます |
フェーズ7：段階的な切り替え
フェーズ7では、リスクが最も低いサイトから順に、ユーザーとサイトを段階的に新しいゲートウェイへ移行します。
- リスクと複雑度に応じてユーザーとサイトを「ウェーブ」ごとにグループ分けし、リスクの低いサイトから順に開始する
- 各ウェーブの開始を事前に、サポート担当者に連絡してください
- 業務の繁忙期を避けてスケジュールを組む
- 各波の発生当初の数時間、危機対策室にスタッフを配置する
- ヘルプデスクのチケット、ブロック率、エラー率を基準値と比較して監視する
- 波と波の合間に一息ついて、問題を解決してから先に進む
フェーズ8：受入および廃止措置
フェーズ8では、受け入れ基準が満たされていることを確認した後、旧来のゲートウェイ、証明書、および契約を廃止します。
受け入れ基準（例）
- すべてのユーザーとサイトが移行されました
- ヘルプデスクの問い合わせ件数が2週間ぶりに通常水準に戻った
- 本番環境ではすべてのテストケースが成功している
- セキュリティ運用およびコンプライアンス部門によって検証されたログおよびレポート
- 例外リストの審査および承認が完了しました
廃止
- PACファイル、ルーティング、およびDNSから古いゲートウェイを削除する
- 古い検査用CAが置き換えられた場合は、デバイスからそのCAを無効化し、削除してください。
- 保存ポリシーに従って古いログをアーカイブする
- ハードウェアを安全に消去し、廃棄する
- ライセンスおよびサポート契約の終了
一般的なスケジュール
所要期間は、遺産の規模や保険契約の複雑さによって異なります。
単一拠点の組織であれば、移行を数週間で完了させることができます。大規模な多拠点企業の場合、多くの場合、6か月から12か月にわたって並行導入と段階的な導入を行うことが一般的です。 Skyhigh Security。
SkyhighによるSWG移行のサポート内容
Skyhighは、並行展開、検証済みのCPLポリシーのインポート、および柔軟な展開モデルを通じて、SWGへの移行をサポートします。
Skyhigh Hybrid SSE Meshは既存のゲートウェイと並行して導入されるため、本番切り替え前に並行トラフィックを用いてポリシーの有効性を検証できます。Skyhighは、検証済みのインポートプロセスを通じて、既存のBlue Coat CPLポリシーを統合ポリシーコンソールで再表現し、ポリシーはSkyhighクラウドコンソールで作成されます。Webおよびプライベートアプリケーションのポリシーはオンプレミスのゲートウェイで適用可能であり、クラウドでのデータ保護が必要なトラフィックはSkyhighクラウドに転送されます。 リモートユーザーへのサービス提供は、クラウドのPoP（接続拠点）を通じて行われます。Skyhigh SWGはオンプレミス、ハイブリッド環境、またはクラウド上で動作するため、移行によって導入モデルの変更を余儀なくされることはありません。「Blue Coat モダナイゼーション・プログラム」では、対象となる顧客に対してサービスサポートと商用オフセットが提供されます。
出典
- NSA. 「トランスポート層セキュリティ（TLS）検査に伴うリスクの管理」（2019年11月）。https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- NIST.SP 800-128：情報システムのセキュリティ重視の構成管理に関するガイドライン。 https://csrc.nist.gov/pubs/sp/800/128/upd1/final
- Broadcom。Edge SWG（ProxySG）およびAdvanced Secure Gatewayのサポート終了および製品ライフサイクルについて（KB 151102）。https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
- Skyhigh Security. 「Skyhigh Hybrid SSE Mesh による Symantec EdgeSecure Web Gateway の近代化」（2026年7月15日）。https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- Skyhigh Security. 「Skyhigh SSEプラットフォームにより、ハイブリッド環境の導入がさらに容易に」（2024年10月3日）。https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html