Catoクラウドへの移行を検討されるお客様よりよく聞かれる事の1つに「Cato移行後も、データセンターのDMZにある公開サーバを提供する事ができるか？」というのがあります。答えはYesですがその注意点について記載します。
方法は2つ。Remote Port Forwarding と Local Port Forwarding
Catoで内部のサーバを外部に公開するにはPort Forwarding機能を使用します。Port Forwardingという名前からイメージできるかと思いますが、インターネット上に公開するグローバルアドレスとポート番号を内部サーバのプライベートアドレスとポート番号に変換する機能です。これはアプライアンスのFirewall等でもよくある機能で私も利用した経験があります。
Catoの場合はRemote Port Forwarding と Local Port Forwarding の2つの方法がありますので、その違いを構成例を図1に示します。
図1. Remote Port Forwarding と Local Port Forwarding の”イメージ”
2つの大きな違いはCatoを通過するかしないかです。Local Port ForwardingだとCatoを通過しないので、当然Catoのセキュリティチェックは効かず通信ログも記録されません。2つの違いを表1に纏めました。
表1. Remote Port Forwarding と Local Port Forwarding の比較
| 項目 | Remote Port Forwarding | Local Port Forwarding |
| グローバルIPアドレス | IP Allocationで取得したアドレス | ISPから払い出されたSocketのwan1のアドレス |
| セキュリティチェック | 可能 | 不可 |
| 通信ログ出力 | 可能 | 不可 |
| 設定箇所 | Network >Remote Port Forwarding | Site Configuration > Local Port Configuration |
| 注意点 | ・グローバルアドレス個数問題（※1） ・Port forwardingの通信の優先度（※2） ・中国のPoPは非サポート（※3） |
・IPsec Siteでは非サポート ・NAT環境では不可（※4） |
（※1）IP Allocationで取得したアドレスのうち、例えばOffice365用の固定アドレスを公開サーバ用に使用する事も可能ですが、
アドレスを分けたい場合追加取得が必要になります。4つ以上は有償になります。
（※2）Port forwardingの通信はQoSの優先度で最も低い255が自動的に割り当てられ、且つ変更ができません。
（※3）中国のPoPに割り当てたIPは設定する事が出来ません。
（※4）上位にルータがあって、Socketのwan1ポートがプライベートアドレスの環境では利用できません。要するにwan1が固定グローバルアドレスの環境でないとLocal Port Forwardingは使えないという事です。尚、PPPの場合はアドレスが変わらなければ出来るかもしれませんが試せてません。
2つの内容を見ると、セキュリティチェック及び通信ログの出力ができる点においてRemote Port forwarding が推奨という事になります。またCatoのナレッジにも「可能な限りRemote Port Forwardingを使う事」という記載があります。
逆にLocal Port Forwardingを使用する例を考えると、公開サーバ設置拠点のトラフィック量が多く、Remote Port forwardingだと優先度が低いせいで公開サーバ宛ての通信が破棄されてしまうケースでしょうか。（上記「表1」の注意点※2です）
この場合、Cato契約帯域を増速すればRemote Port Forwardingを選択できる解決策はありますが、勿論コスト増となってしまうので、そこはLocal Port Forwardingのデメリットとのトレードオフになるかと思います。
外部アクセスを許可するリスク
公開サーバを設置するDMZとは、DeMilitarized Zoneの略で「非武装地帯」という意味です。
DMZはインターネットからのアクセスが許可された外部と内部のネットワークの中間にあるセグメントなので、内部ネットワークとの間には当然何らかのセキュリティ対策が施される事が前提とされています。(以前は「DMZの公開サーバが乗っ取られたらそこから社内ネットワークに侵入されるのでFirewallでDMZ→Trust間はAll Denyにしよう」という話をよく聞いたものでした)
したがってCato Socket配下のサーバをインターネットに公開する場合、同じSocket配下にいる社内サーバやクライアントPCとの間にセキュリティを施す必要があります。ではそのセキュリティ対策は何をどこまで行えばよいのでしょうか？
考えられる事は山ほどありますし完璧な対策を行う事が難しい事はご存じの通りです。また、せっかくCatoを導入する事でこういったところのコストや運用負荷から解放されるはずが、逆戻りとなるのは明らかです。
Catoクラウドはフラットでシンプルなネットワークという志向なので、セグメントの階層化や通信経路が複雑化する設計は避け、例外通信を極力なくす事がより安全で且つ運用負荷を軽減できると思います。
よって社内ネットワークにDMZを残すという考えは捨て「公開サーバはCatoとは別のクラウド（AWSなど）に置く」「公開サーバのセキュリティはAWSサービスを利用する」事とし、万が一公開サーバが攻撃を受けた場合も社内ネットワークには影響がない状態にしておくのが得策かと考えます。
尚、Catoのナレッジには、本機能を使用する場合は「外部の送信元アドレスを制限する」ことが強く推奨されていますが、公開サーバはだいたい不特定多数のアクセスを許可しているので「分かっちゃいるんだけど仕方ないんだよ」という声が聞こえてきそうです。
まとめ
Catoクラウドへの移行後も社内ネットワークにある公開サーバを継続利用する事は可能ではありますが、その拠点をCato Socketにした構成でその他サーバやクライアントPCとの境界のセキュリティを考える事が必要となってきます。
尚、2023年前半に「LAN Firewall」機能が追加されていますので、構成によってはこちらを活用できるかもしれません。