こんにちは！セキュリティチームの ぐっちー です。Netskope Cloud Firewall（CFW）を検証したので、そちらの内容についてブログにしました。
本ブログのサマリー
- リモート環境においてもHTTP/HTTPS（TCP80/443）以外の通信を使った情報の持ち出しを防ぐために、Netskope Cloud Firewall（CFW）を検証しました。
- 検証の結果、大筋は期待通り動作しており、ホスト型のFirewallと比較して、運用面に大きなメリットがあると感じました。
- しかし、登場したばかりのサービスということも影響してか、ブロックした場合の通知など多少気になる点があります。今後のサービス改善にも期待したいです。
注意
本ブログの内容は、2022年9月27日時点までの情報を元に作成しておりますが、クラウドサービスの仕様変更等に伴い、将来的に状況が変化することがございます。当社側で仕様変更が確認できた場合は可能な限り修正をしますが、最新の情報を常に維持することは難しい点についてはご了承ください。
情報の流通経路はWebだけではない
今主流のクラウドサービスではHTTP/HTTPS（TCP80/443）の通信が最も利用されています。ここに関しては、主にNetskopeのCASB/SWGを利用した制御施策をブログやHP等で紹介してきました。しかし、当然のことですが、これ以外のプロトコルを利用するサービスは多数存在してます。この領域の制御は当社にとっても、当社のお客様にとっても課題となっていました。
- SSHコマンド（22）
- POP/IMAP/SMTP（995/993/587）
- SQL（1433）
- RDP（3389）
- Client-Sercer方式の独自アプリ（？）
- 等々
80/443以外の通信をリモート環境でどう制御するか？
80/443以外の通信に関して、一昔前は、境界に設置しているFirewall（FW）を利用して制御することが一般的でした。しかし、重要なデータがインターネットの向こう側や従業員自宅のPC等にある現代では、シンクラやVPN等を使わない限り、境界のFWだけで制御することはできません。
その課題に対して、「リモート環境はホスト型FWで対応しよう」という考え方があります。ホスト型FWはWindows FirewallやmacOSのPacket Filterなど、OSに搭載されたFWを指しています。ただし、ホスト型のFWはOSの機能に依存しているため、以下のような課題があります。
そもそもの設定が大変
ホスト型のFWは、境界に設置するFW（すなわち専用ツール）と比較して機能が劣り、設定が大変となる傾向があります。ホスト型FWはOSが提供する多種多様な機能の1つであり、さらに端末の大きさやスペックも限られているので仕方がない話です。
例えば、FWのホワイトリストを指定する場合、FQDNではなくIPアドレスを個別に登録する必要があったりします。使うサービスと紐づくIPがずっと固定だったらいいのですが、クラウドサービスは利用するIPがしれっと変わるのは日常茶飯事であり、運用はかなり大変です。また、新しいサービスを導入する場合には、都度IPアドレスの調査と設定が必要となるケースがあり設定や運用面が大きな課題です。
試しに、Zoomで利用しているIPアドレス一覧などを見てみると、運用の大変さのイメージが湧いてくると思います。
ポリシーのチューニングやブロックされた時の調査が難しい
ホスト型のFWは、通信ログ（許可・ブロック）を取得・分析することは簡単ではありません。そのため、ポリシーのチューニングやブロックされた時（ユーザーから「なんか動かないんだけど？」と連絡があった時）の調査が難しいという課題もあります。
FWの通信ログ（許可・ブロック）は集中管理し、それを基にチューニングすることが理想です。しかし、手頃な収集・分析ツールはなく、Wireshark等の分析ツールをPCにインストールして調査するなどひと工夫が必要です。
Windows・macOS混在環境の運用コスト
Windows・macOSが混在している環境では、当然、運用担当者のホスト型FWの運用習熟コストや実際の運用コストが跳ね上がります。片方を習得すると、もう片方の勘所がわかるという側面があるので、単純に工数が倍になるとまでは言いませんが、効率の良い管理とは言い難い状況となります。
注意
念の為の補足ですが、ホスト型FWを否定するものではありません。組織の状況や要件次第ではホスト型FWだけで事足りるケースもございます。（例えば境界に設置したFWのポリシーを転用することができるケースや、運用を行う人員が揃っているケースなど）
Netskope Cloud Firewall（CFW）でどうにかなるのか？
上記のような背景もあり、近年ニーズが高まっているのがFWaaS(Firewall as a Service)です。FWaaSとはこれまで境界に設置していたFWの機能をクラウドサービスとして提供しているものです。クラウドサービスとして提供することで、オフィス以外の場所にユーザーがいたとしても、オフィスに全ての通信を集めることなく、境界に設置しているFWと同じような制御を実施できます。
FWaaSのカテゴリに分類される製品はいつくかありますが、今回はNetskope Cloud Firewall（CFW）を検証しました。2021年秋に登場したばかりでWebなどの情報が少ないのですが、概要は以下の通りです。
FWの機能をクラウドで提供
Netskope Cloud Firewall（CFW）はアウトバウンド通信の全ポート/プロトコル（TCP/UDP 1-65535 & ICMP）にネットワークセキュリティ提供します。User-ID、Group-ID、送信元IP、FQDN、ワイルドカード、送信先IPなどを切り口で、柔軟に許可・ブロックのポリシー設定をすることができます。FQDNに対応している点などは運用がかなり楽になることが期待できます。
また、クラウドで提供されるので、WindowsとmacOSの機能差はほとんどなく、両プラットフォームの管理を統合することができる点もメリットだと考えています。
管理コンソールでログを一元管理
管理コンソールでログを一元管理できるという点も大きな強みの1つです。許可している通信やブロックしたログなどを確認し、Firewallポリシーを組んだり、接続できない場合のトラブルシューティングに役立てることができます。
単一エージェント・単一管理コンソールで提供
Netskopeには、CFW以外にもCASB・SWG・ZTNA（NPA）というソリューション群がありますが、これら全てのソリューションを単一のエージェント（Netskope Client）且つ単一の管理コンソール画面で利用できるという点にも大きなメリットがあります。
既にCASB・SWG・ZTNA（NPA）を利用していれば、新たなエージェント配布などは不要ですし、製品の習得コストは低くなります。
初期設定と展開までの道のり
当社では許可するポートやIPを指定する「ホワイトリスト型式」でCFWを展開しました。初期設定・ホワイトリスト作成・全体展開・運用までの道のりは長くなるので、別記事にしています。そちらも是非見ていただけたら嬉しいです。
検証結果（実際の挙動や気になる点）
検証結果の注意事項
- 本ブログでは「Basic Cloud Firewall」を検証してその内容を記載しています。2022年9月13日に発表された「Advanced Cloud Firewall」は未検証ですのでご了承ください。
- OSはWindows10/macOSBigSur以降、Netskope Clientはv91以降のバージョン利用が必要です。
- 現状、CFWでの制御が対応しているのはアウトバンドの通信だけです。一方、CFWを有効化するとインバウンド通信はすべてブロックされてしまいます。回避するためには、対象の通信をExceptionする必要があるのでご注意ください。
- 一部、CFWではブロックできない通信（DNS等）もございます。ブロックできない通信の詳細はNetskope購入先にお問い合わせください。
- 他にもFWaaSにカテゴライズされるサービスはありますが、それらのサービスとの比較は行っていません。
ポリシー（許可・ブロック）の組み方
ホワイトリスト型式にするにしても、ブラックリスト型式にするにしても、「カスタムアプリ（ユーザーが宛先やポート等を指定して個別に登録するアプリ）」を登録し、それに対してReal-time Protectionポリシーを作成する必要があります。カスタムアプリ登録に利用できる項目は以下の通りです。
- プロトコル（TCP、UDP、TCP/UDP、ICMP）
- ポート番号（1-65535）
- 宛先（IP、IPレンジ、CIDR、FQDN、PWDN）
登録したカスタムアプリを指定し、Real-time Protectionにて許可・ブロックを入れることで、ポリシーを組むことができます。
カスタムアプリを登録しなければいけないのは骨が折れますが、FQDNやCIDRを利用できるので、比較的楽に運用できそうだなという所感です。
ログの見え方（許可された通信）
初期設定を完了させると、[ScopeIT] > [Network Events]にCFWのログが上がってきます。送信先IPやポート番号に加えて、アプリによってはHost NameやDomein Nameを確認することができるので、そこからアプリケーションを確認することはできました。（例えばGithubやEC2へのSSHなどは確認できました。）
ただし、Network Eventsのトップ画面の[APPLICATION] 欄は、デフォルトでは「unkown」と表示されています。
[Settings] > [Security Cloud Platform] > [App Definition] にて、カスタムアプリに登録すると、アプリケーションが記録されるようになりました。
ログの見え方（ブロックされた場合）
ブロックされた際のログですが、ちょっと不思議な仕様となっており、設定方法によって掲載される場所が異なります。
「ポリシー（許可・ブロック）の組み方」で紹介した方法でブロックした場合
上記「ポリシー（許可・ブロック）の組み方」で紹介した方法でブロックした場合は、[ScopeIT] > [Alerts]にブロックのログが上がってきます。
デフォルトのテナント設定でブロックされた場合
ホワイトリスト運用を実施する場合は、テナントの[Default Action] の設定にてブロックを設定し、その上位のポリシーとして、ホワイトリストのポリシーを設定する流れとなります。
この設定においてブロックされた場合は、[ScopeIT] > [Network Events]にログが出ます。
ブロックした場合の通知（ユーザー＆管理者）
前提として、NetskopeのCASB・SWGでは、Real-time Protectionポリシーで許可されていない操作をした際には、ユーザーに対してポップアップを出してアラートを提示することができます。
CFWにおいても、同様のことができることを期待しておりましたが、現時点ではユーザーに対してポップアップの通知をすることはできません。ユーザー体験としては「なんか、つながらない」という形となります。ユーザーがNetskopeによりブロックされたことを切り分けするのは難しいという状況ですので、相談窓口の設置や呼びかけなどが重要になりそうです。
また、NetskopeのCASB・SWGでは、ブロックがなされた場合に、管理者に対してメール通知を行うことができますが、CFWには対応していないようです。ホワイトリスト運用開始後は、ブロックされたアラートを起点に調査し、ホワイトリストに入れるか、許可しないかの判断をする運用をしたいと考えておりましたが、現状は管理画面のパトロールをしています。この仕様に関してはイケテナイと思っているので、Netskope社にFBをしたいと思います。
送信元のIPアドレスはどうなるのか？
送信元のIPアドレスはについて疑問を持たれるかもしれませんが、通信がNetskope Cloud（データセンター）を経由するため、NetskopeのIPアドレスとなります。VM等の接続において送信元のIPを絞っている場合には、影響が出ますので事前に調整が必要です。
ちなみにCASB・SWGでは、通信をNetskopeのデータセンターに送らない「Exception」を設定することができますが、CFWにおいても同様に「Exception」は可能です。「Exception」することで、送信元IPはCFWを使っていない状態のIPとなりますが、CFWでログが取れなくなり、CFWによる制御ができなくなるので注意が必要です。
CFWで制御できない通信を知らないと沼にハマる
冒頭にも記載しましたが、DNSに対する通信など「CFWで制御できない通信」があります。これらの通信は、デフォルトでNetskope Cloud Firewall（CFW）からbypassされています。Real-time Protectionでもブロックのポリシーを組んでもブロックできないので、ご注意ください。
僕はブロックの検証でGoogle DNSを利用しましたが、「CFW動いてないじゃん」っと沼にハマりました。CFWで制御できない通信の全量については、Netskope購入元にお問合せください。
CASB・SWG・ZTNA（NPA）に影響はあるのか？
Netskope Cloud Firewall（CFW）を有効化することで、CASB・SWG（80/443の通信）やZTNA（NPA）など、既存のNetskopeの機能に何かしら影響するのではないかとかなり気になっておりましたが、当社で1ヶ月使った限りでは、影響でている箇所は確認できませんでした。これからも注視して見ていきたいと思います。
また、上記の図のように、ログの出方としても、「CASB・SWG（80/443の通信）」と「ZTNA（NPA）・CFW」のログはそれぞれ分離されています。同じ管理コンソールを利用するので「管理者のユーザービリティが下がるのでは？」という懸念がありましたが、少なくとも私はその印象は受けておりません。
ホスト型FWよりは楽そうだけど、FW運用はやっぱり大変
検証の結果、Netskope Cloud Firewall（CFW）は、ログの分析のしやすさや展開のしやすさに関しては、優れていると感じました。しかし、そもそもFWの運用は大変であることには変わりありません。ホワイトリストを展開してから3週間が経ちましたが、度々ブロックのログが上がって来ており、お世話が欠かせない状況です。バルタブ曲線の様に落ち着いてくれればいいのですが、完璧なホワイトリストを最初から作ることは難しそうなので、調査や運用プロセスとセットで導入する必要がありそうです。
ただし、重要なサービスは予め調べて展開したこともあり、ユーザーから「動かないんだけど」という報告は幸いありません。例え特定のホワイトリスト登録サービスにおいて、登録漏れのポートやIPがありブロックされたとしても、登録済みのポートなどにリダイレクトして動いているからではないかと予想しています。
また当社はクラウドサービスの利用を主軸としており、自社でのシステム開発を行うケースは少ないですが、自社でのシステム開発を行う場合は、パッケージマネージャーの通信などが引っかかる可能性があり、当社が導入するよりも難易度が上がることが予想されます。この辺の話は続編ブログにも書きたいと思います。
終わりに
ブロックされた際の通知の部分などは使いにくい部分はあったものの、ログの分析やCASB・SWGと合わせた運用面については大きなメリットがあるなと感じました。まだ、登場して間もないサービスであり、今後も機能追加されていくみたいなので、これからも注視していきたいと思います。また、FWaaSは他にもあるので機会があればそちらも触ってみたいです。
