WANをCatoクラウドに移行するには?

本記事は TechHarmony Advent Calendar 12/12付の記事です。

昨日に引き続き、Catoクラウドについてです。どうぞお付き合いください。

現在稼働中のWANをCatoクラウドに移行しようとしたとき、どのような点に考慮が必要でしょうか。またどういった順序で進めるべきでしょうか。

今年もいくつかの移行をご支援した振り返りとして、移行の進め方の例をご紹介します。

一般的な閉域網WAN構成と移行後イメージ
移行フェーズの例
最後に

一般的な閉域網WAN構成と移行後イメージ

現状のWAN構成として、以下のような構成で運用されている例は多いかと存じます。

拠点を閉域WANサービスで接続
データセンタに社内システムを集約
インターネット向けの通信は、データセンタに設定したセキュリティアプライアンスを通って、データセンタのインターネット回線から出ていく
データセンタにリモートアクセスシステムを設置し、社外から社内のシステムへアクセスする
データセンタまたは閉域WANから、SaaSやパブリッククラウドへのアクセス経路がある

このWAN構成のイメージが下図の左側、これをCatoクラウドに移行した場合の例が右側です。

データセンタでのボトルネックを解消し、セキュリティアプライアンスをCatoクラウドのセキュリティ機能に置き換え、シンプル化するイメージです。

移行フェーズの例

では、Catoクラウドの移行はどのように取り組んでいけばよいのでしょうか。おおよその流れは以下です。

現状構成の調査
移行要件の整理
移行設計
移行の実施

それぞれのフェーズでの実施内容をご紹介します。

1. 現状構成の調査

ネットワークを切り替えるにあたり、まずは現状の構成がどうなっているかを整理する必要があります。

具体的には、以下のような情報を確認し、最新化します。

ネットワーク全体のIPアドレス設計
通信フロー
ルーティング設計 (使用しているルーティングプロトコル、拠点間通信の制限有無、例外ルールの有無等)
データセンター内の物理・論理構成、回線情報
各拠点の物理・論理構成、回線情報
リモートアクセスシステムの利用者数、アクセス制限

これらの情報に不明瞭な箇所があると、移行時に考慮漏れが起こってしまうことがあるため、情報が最新でない場合には、稼働中の機器のConfig確認や現地の調査を行います。

2. 移行要件の整理

Catoクラウドへの移行にあたり、支障となる点や、特別な考慮が必要な点がないかを検討します。多くの場合は、これらを確認するためにPoCを実施します。

また、あわせて移行後の構成を検討します。

移行要件の確認ポイント

フェーズ1で調査した現状の構成情報を用いて、以下のような点を確認していきます。

IPアドレス体系はそのまま移行できるか。拠点間での重複や、Catoの管理アドレス(10.254.254.0/24)の利用がないか。
※あった場合移行設計時に考慮が必要になるため
リモートアクセスをCatoに移行できるか。現状のリモートアクセス装置でないと実現できない、固有の通信要件がないか。
拠点間通信・Internet向け通信において特殊な経路・要件がないか。
外部向けの公開サーバなど、Internetから内部向けの通信があるか。ある場合、その通信の宛先となるグローバルIPアドレスは変更が可能か。
※Catoに移行するとグローバルIPアドレスが変更されるため
現行のセキュリティアプライアンスとCatoセキュリティ機能を比較し、対応できない機能がないか。あった場合にはその機能の必要性や代替手段を検討する。

移行後構成の検討ポイント

同じく、現状の構成情報をもとに、移行後の構成を検討していきます。

各拠点のCatoクラウドへの接続を冗長化するか、シングル構成とするか。
各拠点の接続帯域の検討。
各拠点で利用する回線の選定、手配。
※申込みから開通まで2～3ヶ月かかるため早めの手配が必要です
モバイル接続ユーザ数の検討。
モバイル接続ユーザの登録・認証方法・接続制限の検討。
パブリッククラウド(AWS/Azure/GCP等)がある場合、Catoクラウドへの接続方法の検討。

拠点間通信の見直しについて

なお、閉域ネットワークからCatoクラウドへの移行は、境界型防御からゼロトラストモデルへの移行でもあり、セキュリティ環境を見直す絶好の機会です。

境界型防御は社内ネットワーク=安全とするモデルのため、拠点間の通信に制限をかけていない場合が多いですが、ゼロトラストにおいてはすべての通信を信頼せず、許可すべき通信のみを許可することが推奨されます。

Catoクラウドでは「WAN Firewall」機能にて、拠点間やユーザ間、またユーザと拠点間の通信の制御を簡単に実現できます。また、ルール内で、アプリケーションやサービスの指定や、OS等デバイス条件の指定も可能ですので、許可すべき通信だけを細かに指定して許可し、ネットワーク内のセキュリティを高めることが可能です。

このフェーズにて、ネットワーク内通信の厳格化を検討することをおすすめしております。

WAN Firewallの機能については、以下の記事もご参照ください。

3. 移行設計

移行後の構成が描けましたら、続いて実際の移行方法を考えていきます。

移行Stepの検討

多くの場合、全拠点の一斉移行は難しく、各拠点の都合にあわせて順次移行していくことになります。

順次移行は、データセンター等、主要なシステムがある拠点にまずCato Socketを設置し、その拠点を中継してCatoクラウドと既存網の間を相互通信させることにより実現します。

以下は移行Stepの一例です。

Step0 主要なシステムのある拠点(データセンタ等)にCato Socketを設置し、限定したユーザで導入テストを行う。
※このStep0をPoCとして実施する場合が多いです
Step1 リモートユーザの接続をCatoクラウドに切り替える。

Step2 パイロット拠点をCatoクラウドに切り替える。
Step3 各拠点を順次Catoクラウドに切り替えていく。
Step4 パブリッククラウド(AWS/Azure等)をCatoクラウド経由の接続に変更する。
※Catoへ切り替え済みの拠点/ユーザとの通信効率を重視する場合には、より早い段階で移行します