現在、新しいサービスを導入する際には、事前にPoC（概念実証）を行うことが一般的となっています。
PoCの目的は、採用を検討するサービスを比較するために実際にサービスを体験してみる事だったり、採用の最終確認だったり、と状況は様々です。
私たちSCSKとしても、Catoクラウドへの切り替えを行う際には、最初にPoCをお勧めしています。
Catoクラウドの導入により、ボトルネックの解消やセキュリティの強化、運用の省力化など多くが期待できますが、本当に自社環境に適合するのかを確認するために、PoCの存在は重要です。
PoCで何をテストするか？何を確認するか？については各社異なりますが、参考までにいくつかのポイントを挙げさせていただきます。
- 社員が働く環境（オフィスや自宅、海外出張先）から、現状業務がCatoクラウド経由で問題なくできるか？
また、それぞれの環境でセキュリティが確保できるか？ - 既存のサービスとの連携が問題なくできるか？ 何か条件がある場合、解決手段はあるか？
- Catoクラウドに切り替える事で、現状抱えるネットワークやセキュリティの課題が解決できるか？
- 自社のセキュリティポリシーやデバイス管理方法を満たせるか？
- 自社ネットワークをCatoクラウドへの切り替えるイメージをもつ
- Catoクラウド切り替え後のネットワーク運用 / セキュリティ運用をイメージする
CatoクラウドのPoC用ライセンスは、原則として有効期間が1ヶ月間となっています。
そのため、お客様がPoCを効果的に実施できるよう我々SCSKでは、PoC構成のアドバイス、テストしたい内容に重点を置いた技術支援、PoC期間中のQA対応、といったサポートを提供しています。
お客様とPoCの話をする際に、ほぼ必ず「本番ネットワーク環境を使用したPoC構成をどうしようか？」といった相談を受けます。
業務は全てSaaSを利用している！というケースは除きますが、基本的には、まず社内システムのサーバがあるところにCato Socketを設置して、各テスト環境からCatoクラウド経由で接続するという構成になります。今回はその構成例をご紹介します。
データセンターにCato Socketを設置したPoC構成例
Catoクラウド切り替え前のネットワーク構成は、多少の違いはあれど次のような構成かと思います。
- 閉域網で各拠点を接続
- インターネットにはデータセンターのFirewallやUTMから接続
- 自宅や外出先からは、データセンターのVPN装置にSS-VPNなどで接続
<現行ネットワーク構成イメージ>
このような構成では、Socketをデータセンターに設置し、テスト用PCからCatoクラウドを経由して社内システムを利用することが可能です。下図では、本社にもSocketを設置し、個別のインターネット回線に接続した「Socket配下テスト環境」と、Cato Clientをインストールした「モバイルテスト環境（自宅や外出先を想定）」からデータセンターの社内システムにアクセスする構成を示しています。
見ての通り「Socket配下テスト環境」も「モバイルテスト環境」も本番環境と重複しないアドレスレンジを設定しているので、データセンターのL3SWにその戻りルートをSocket向けに追加することで、本番通信に影響を及ぼさずにテストを行うことが可能となります。
既存ネットワークの変更作業としては、以下の2点です。
- データセンターのFirewall・L3SWとCato Socketの接続、FirewallにSocket～Catoクラウド間のトンネル用ポート番号の許可
（必要なポート番号：443/TCP/UDP, 53/UDP） - L3SWにスタティックルートの追加
なお、Catoクラウドに接続するテスト環境のサブネットは、Catoクラウド内で動的にルーティグされます。
また、テスト環境からのインターネット接続は、Catoクラウドから直接でていくので特に考慮は不要です。
<PoC構成その1>
なお、Socketは、必ずWANポートとLANポートを接続する必要があります。（いわゆる1アーム構成には対応していません）
WANポートは回線（側）と接続してCatoクラウドとトンネルを形成し、LANポートはスイッチなどLAN機器と接続して、LAN内のデフォルトゲートウィとなるのですが、これらが同一VLANであっても問題ありません。
下図に示すように、Firewallの同一VLANのポートとSocketのWAN/LANポートを接続して、Socketが必要なポート番号でインターネットに出られるようにするのと、各テスト環境サブネット向けの戻りルーティングをSocketのLANポートのアドレス宛に追加すればOKです。
<PoC構成その2>
AWSにvSocketを設置したPoC構成例
社内システムがAWSなどのクラウドに移行されているネットワーク構成でも、考え方は同様です。
AWS内にvSocketを作成し、VPCなどのルートテーブルに各テスト環境向けのルーティングをvSocket宛てに追加することで、本番通信に影響を与えることなくテストを実施することが可能です。
<AWSでのPoC構成>
もちろん、社内システムがデータセンターとAWS（またはAzure）に存在する場合でも、物理SocketとvSocketをそれぞれ設置し、個別ルーティングを追加することで、各テスト環境から両方のシステムにアクセスしてテストを行うことが可能です。
実際に、そのような構成でPoCを実施しているお客様もいらっしゃいます。
Catoクラウドへの切り替えについて
少し補足ですが、既存ネットワーク拠点をCatoクラウドへ切り替える際には、各拠点のWANルータをSocketに置き換える作業となります。
拠点が多い場合は、一度に全てを切り替えるのは難しいかもしれません。その場合は、拠点ごとに順次切り替えを行います。
切り替え作業の基本的な考え方は、PoC構成で示した通りで、まずシステムがあるデータセンターやAWSなどのクラウドにSocketを設置し、切り替える拠点のサブネット向けのルーティングを順次Socketに切り替えていくといった流れです。
切り替えのたびにルーティングの変更を行うのは大変ですが、もし既存ネットワークでBGPを使用していれば、SocketはBGPをサポートしているので、自動的にルートの切り替えが可能です。
この辺りは、Catoクラウド自体の問題ではなく、ネットワーク切り替え設計の話になります。
さいごに
今回はPoC構成について記載しましたが、PoCを実施する上で、まだ多くの疑問点があるかもしれません。
たとえば、DNSの設定やIdaaS連携、デバイス認証、ローカルブレークアウトはどうなるのか、といった点です。
SCSKの技術ブログでは、この後もPoCに関する情報を提供していく予定ですので、ぜひご期待ください。
また、SCSKではこれまで数多くのPoC支援、導入支援を行っており、多くのお客様ネットワーク構成をみてきました。
Catoクラウドのサービス内容以外にも、PoC関連やCatoクラウドの切り替えについても、何かご心配・不明点などがありましたら是非お声がけ下さい。