かなり以前から気になってた製品をようやく検証することができました。

SonicWallさんからリリースされる新しいクラウドを利用したZTNA/SDPのソリューションで、SonicWall Cloud Edge Service Edgeという製品です。 ベースはPerimeter 81というイスラエル発のSDP製品をベースに提供されるクラウドサービスです。

SonicWall Cloud Edge Secure Accessの特徴

SonicWall Cloud Edge Secure Access(以下SWCESA)の特徴はなんと言っても、既存のネットワークエッジを使ってそのままSDPソリューションへアップグレードできるという点ではないでしょうか？

SDPといえば、ソフトウェアで提供されることが多いため、既存のエッジの裏にコネクターやゲートウェイを設置して、クラウドのブローカーとコネクターを接続させる方式が主流です。ただ簡単とはいえ、コネクターを構築する手間や、仮想環境が必要となり、何らかの機能上、構成上の制限が出てしまいます。

SWCESAはクラウドに設置されたエッジとユーザー先のエッジをIPSec VPNで接続することで、リモートアクセスVPNにおけるアタックサーフェスをSonicWall社が管理しているクラウドに限定することができるので、ユーザー環境へダイレクトにVPNアクセスを許可すること必要性がなくなります。

メリットとしては、接続元のユーザーからは、拠点にばらまかれた拠点のエッジを意識させずに、1つの窓口だけを提供しながら、アタックサーフェスを最小化できるメリットがあります。 つまり、拠点のエッジとしては、送信元はSonicwallのクラウドエッジからの送信のみ許可をすればいいので、無駄に外部からの通信を精査する必要も無く、使い慣れたファイアウォールやルータを使い続けることができます。

リモートアクセスVPNにおけるアタックサーフェスのイメージ

特に最近のリモートアクセスVPNにおいて、ユーザーの利便性とサービスの公開による危険性を両立することは難しい場合があります。 SWCESAのようなサービスは既存のネットワーク環境をオーバーレイする形でSDP化できるというような製品だと思います。

多彩な展開方法

個人的にこの製品を触ってみて最初にいいなと思ったのが、とても柔軟な方法でSWCESAを展開できる点です。

• 既存のエッジルータ/ファイアウォールを使って展開する場合（IPSecVPN）を使う
• 専用コネクターエージェントを使った展開する場合（WireGuard）を使う

参照: CLOUD EDGE SECURE ACCESS GETTING STARTED GUIDE

この2種類での展開が可能という点は他社製品にはない特徴です。

既存のエッジルータであれば、SonicWallを始め、Cisco、Fortigate、PaloAltoなどの大手の製品との連携も可能ですし、AWSやAzureといったゲートウェイとの接続も可能ということです。 これは、標準的なIPSecVPNをベースに使っていることで実現するので、新たに機器を購入しなくても、サイトツーサイトのVPNが構成できるルータさえ用意できれば、ユーザー環境に依存しないということです。

一方専用コネクターエージェント方式にも対応していて、Linux（Ubuntu/CentOS）が動かせるのであれば、エッジルータを使わず、社内ネットワーク上にSDPのコネクターを数分で設置することができます。

VPNの設定の手間を書けたくない場合や、ネットワーク構成の変更を最小限に抑える場合は専用コネクターを使うメリットがあります。

Perimeter 81について

SWCESAを語る上で、避けて通れないのが、Perimeter 81の存在です。こちらの製品はSonicWall社のSASE機能として提供されますが、Powerd by Perimeter 81となっていて、ベースのテクノロジーはPerimeter 81の機能が利用されています。

Perimeter 81はイスラエル出身のSDPソリューションで、革新的なSDP技術を持ったメーカーです。 このような先進的なメーカーの製品技術をSonicWallのサービスとして利用できるため、技術的なサポート面において安心感はあると思います。

実装2パターンあります

今回私は既存のエッジルータを使うパターンと専用のコネクターを使う2つのパターンで導入してみました。 本来であれば、エッジルータとしてSonicWallのTZ/NSaを持っていればよかったですが、手持ちがなかったので、FortiGateを使って接続を行いました。

この方式だと、SSL-VPN方式よりも高速処理がしやすい拠点間IPSec接続なので、ハードウェアベースのSDPという新しい分野を開けるのかもしれません。

既存のエッジルータを利用する（IPSec）

IPSecをつかうことで一般的なエッジルータとの接続が可能です。これは汎用性が高いという反面、相互接続の点で注意が必要です。 特にこの製品のように、汎用性が高い場合、重要なのがマニュアルの存在です。多くのエッジルータとの接続設定例が掲載されていて、記載されているマニュアル通りに設定すれば接続が可能です。 マニュアルはSonicWallが提供しているものもいいですが、ファイアウォール連携は残念ながらSonicWallとの連携しか掲載されていないので、Perimeter 81が提供しているものもとても参考になります。

Perimeter 81のIPSec Tunnel設定

今回の検証で利用したFortiGateの接続においては、ほぼマニュアル通りで接続が確認でき、ほんの少しカスタマイズすることで狙いどおりの環境を作ることができました。

• 設定のイメージとしては、クラウド上に仮想エッジルータのようなものを立ち上げます。（Tokyoリージョンあります）
• 仮想ルータにはグローバルIPが割り当てられていて、VPNプロファイルを設定できるようになっています。（IPSec IKEv1/IKEv2対応）
• 標準的なサイトツーサイトVPNで正しく構成できると、VPNトンネルインターフェースがアップします。

Cloud Edge上でFortiGateの対抗先となるトンネルゲートウェイを作成（トンネルアップ）

FortiGate上でVPNトンネル（ルートベースVPN）を設定画面 VPNの設定として、ポリシーやスタティックルーティングなどの設定を行います。

WireGuard方式は一瞬で構成が可能

ZTNA自体、設定の要領を掴んでいれば、実はどこのメーカーの製品も同じような設定で実装ができます。 IPSec方式は汎用性がある反面、相互接続性に関する不安がある場合は、他メーカー同様にコネクターを使った接続方法も提供されています。

このコネクターはWireGuardと呼ばれる従来のVPNプロトコル（IPSecやOpenVPN）と比べて、モダナイズされたVPNプロトコルが利用できます。UDPを使った軽量かつ高速な通信を提供することができます。 WireGuardを利用する場合はLinuxを用意することで、コマンド1行を入力するだけでインストールが可能で、素早くCloud Edgeのネットワークと接続が可能です。

WireGuardの設定に必要なコマンドライン

WireGuard用のゲートウェイを作成すると自動的にコマンドを生成されます。このコマンドをオンプレ側のLinuxへ入力するだけで、VPN接続が完了します。

WireGuard方式で接続した場合のイメージ WireGuard接続はUDP8000による接続なので、ファイアウォールで許可する必要があります。

アクセスはリバースプロキシとトンネルアクセスをサポート

SonicWallのエッジとユーザー環境のエッジ間でVPN接続ができれば、後はクラウド上からアプリケーションポリシーなどのルール設定を行います。

ユーザーからのアクセスは2つのパターンが用意されています。

• リバースプロキシによるWebアクセス（クライアントレス）
• VPN方式によるフルトンネルアクセス（クライアントインストール）

クライアントレス方式はWebブラウザを使うので、サービス（Web、RDP、VNC、SSH）に限定されますが、社内のリソースへクラウドポータルからアクセスすることができます。

ブラウザアクセス（リバースプロキシ）による社内アプリケーションポータルの表示

Windows/macOS/iOS/Androidへインストール可能なCloud Edgeアプリケーションを使った接続

最初のアクセス時に、自身のアクセスするワークスペースへログインし、端末をオンボーディングさせておけば、後はログインのユーザー認証だけでVPN接続が可能です。

VPN自体はスプリットトンネリングに対応していて、IPSecベースのアクセスとなるので、プロトコルの制限なくオンプレサイトへの完全なIPアクセスが可能です。

ユーザー認証/IDPの連携はローカルサーバーとの連携も可能

SASE/ZTNAで押さえておきたいのは、ユーザー認証DBの対応です。ZTNAの本質から考えるとSAML（Azure ADを含む）との連携ができれば問題ありません。しかし現状オンプレからクラウドへ移行が進んでいる段階では、SAMLしか使えないというとなると、ネットワーク、ID管理を含めて同時にクラウド化を進めなければなりません。そのため、スムーズな移行を目指すのであれば、SAMLだけではなく、オンプレ環境のAD/LDAPとの連携が取れることも重要な要素だと考えています。

SWCESA(Perimeter 81)は、SAML、AD/LDAPに対応しています。ZTNAの製品の要件のの１つです。 SWCSAでは、管理機能がクラウド上に存在するため、AD/LDAPの情報を取得する場合は、Auth0のAD/LDAP Connectorを利用します。

Cloud EdgeでオンプレADを使う場合のイメージ

WindowsやLinuxへAD/LDAP Connectorをインストールして、ADの情報をCloud Edgeへ提供できるようにします。AD/LDAP Connectorはアウトバウンドの通信を使ってCloud Edgeと通信するだけです。

ADとの接続設定はSWCESAから発行したTicket URLをAuth0のエージェントへ貼り付ければOKです。無料です。

Ticket URLの発行とAuth0への設定

もちろん、SAMLにも対応しているので、一般的なIDaaSを使った認証連携ができます。

ロギングにはSIEMが必須か？

惜しいと思ったのが、ロギングの機能です。特にオンプレのゲートウェイとのVPN接続のところや、ユーザーのリモートアクセスログの表示がクラウド上でいい感じに見れると良かったのですが、今後期待したい改善ポイントだと思います。 特にゼロトラストという観点から考えると、なるべくログの見落としがないようにするべきです。

ただしっかりログを検証するのであれば、SIEM連携として、Splunkとの連携が可能です。ログダッシュボードのカスタマイズ、レポーティングが必要な場合は、組み合わせることで拡張することができます。Splunk連携については、HTTPイベントコレクターを使って取り込みます。Splunk Cloudとの相性が良さそうです。もちろんSplunk Enterpriseとも問題はありません。

連携可能なSIEMやストレージ

Splunkを始めAzure Sentinel、Amazon S3に対応しています。

ログはjson形式でSplunkへPOSTされています。外部にログを転送できるのは良いのですが、単独でも2週間ぐらいの期間のアクセスログやシステムログを分析する機能があればなお良いと思いました。

SIEM連携した際に送信されるログフォーマット

SonicWallブランドによるメリットとデメリットが混在する製品

SonicWallのSASEポートフォリオを補完するためのソリューションですが、SonicWallの独自の味付け（機能差異）という部分もあるような感じです。

メリットとしてはやはりSonicWallブランドなので定評のあるNGFWとの連携が考えられます。更にSonicWallのSASE自体が拡張すれば、ZTNA以外の機能強化をSASEとして強化されていく可能性があります。

一方デメリットとして感じてしまうのが、Perimeter 81のSDPソリューションとして見た場合、本来は特定のベンダーに依存しないところがメリットであるのが、SonicWallの製品との連携に寄ってしまう可能性があります。

このあたりは実際に評価することで、回避できる部分でもありますが、ZTNAの採用を考えている場合は、少し気になるポイントだと思います。

まとめ

コンセプトがとても面白い製品でした。 冒頭に書いたように、どんなゲートウェイとも連携できるということは、あらゆる既存のネットワークをSDPに変えることができるということです。標準的な技術をベースに作られていて、他社製品とのVPN接続の手順が用意されていたりとアーキテクチャーによってSDPを実現しているという点はとても好感が持てます。

トライアルを行う場合はこちらから
https://www.sonicwall.com/ja-jp/products/cloud-edge-secure-access/

企業のエッジゲートウェイのアタックサーフェスを最小化し、ダイレクトにリモートアクセスをさせない、正しく認証された通信だけが許可されるというアプローチは、ゼロトラストネットワークアクセスの根幹でもあります。

個人的にはこんなシーンで提案してみたいと思いました。

---

• ユーザーの環境で利用しているエッジルータのSSL-VPN機能を使わずにSonicWall Cloud Edge Secure Accessと連携することで、ZTNA/SDPへアップグレードを行う場合
• SSL-VPN方式におけるユーザーライセンスの値上がり、ゲートウェイ単位のユーザーライセンスの課金などをCloud Edgeのライセンスにまとめてしまって、実質利用するユーザー数ライセンスへ切り替えたい

---

このようにオンプレのシステムをZTNA/SDP化することによって、新しいアイデアが生まれます。例えば既存の機器を使い続けることができるので、セキュリティシステムをサスティナブルな活動とすることもできるわけです。なにもすべての機器を新しいハードウェアに入れ替えなくても、保守の期間が続く限り、なるべく長く利用することも検討しなければなりません。

現状ZTNA/SDPという分野では、たくさんの製品がリリースされていますが、実のところコンセプトなどの違いから機能に差があります。そのため、可能な限り多くの製品を実際に触った結果を率直に発信していきます。