SaaS

Netskope Cloud Firewall（CFW）の初期設定・展開・運用はこうやった、こうしたかった話

セキュリティチームのぐっちーです。先日、Netskope Cloud Firewall（CFW）のコンセプト等を紹介するブログを出させていただきましたが、その続編です。

当社において、Netskope Cloud Firewall（CFW）を展開した際、大きな事故等はございませんでした。しかし、反省点は出てきているので、その点を踏まえて「もし2回目やるならこの順番、この作業内容でやりたい」という内容をブログにしています。また、公式の手順では設定方法などはカバーされてますが、CFWはNetskope管理コンソールでの設定以外にも考慮すべきこと（窓口の設置など）が多いのでそこを補足できればと思っています。これからCFWを展開する予定の皆様の助けになれば幸いです。

前提条件

  • 公式な初期設定手順としてはNetskope社のサポートサイトをご確認ください。
  • Netskope Cloud Firewall（CFW）をホワイトリスト型式で展開することをゴール地点としています。
  • 本ブログは、2022年12月3日時点の情報を元に書いています。
  • 以下の状態をスタート地点としています。
    • IdP（Okta・Azure AD等）からNetskopeへのユーザープロビジョニングを構成していること。
    • NetskopeのCASB・SWGは展開されていること。
    • 利用しているクラウドサービスの一覧がまとめられていること。
  • 製品の概要や気になる点については別ブログにまとめております。その内容が本ブログを読むための前提知識となりますので、そちらを確認されていない方は是非そちらを読んでいただきたいです。

注意
当然、個社の事情によって進め方は異なります。また、「ベストなやり方を見つけた」とは思っていないため、今後もNetskope Cloud Firewall（CFW）と深く向き合ってより良い方法を模索していきたいと思いますし、読者の皆様も気になる点があれば、忌憚のない意見をお聞かせ下さい。

初期設定フェーズ

ライセンス調達と有効化

Netskope Cloud Firewall（CFW）はCASB・SWGとは別ライセンスです。Netskope購入先の担当者と連携して、ライセンスの購入とNetskope社によるテナントでNetskope Cloud Firewall（CFW）の有効化作業がまず必要です。詳細はNetskope購入元の担当営業までお問合せください。

カスタムアプリの設定

Netskope Cloud Firewall（CFW）がテナントで有効化されたら、「利用しているサービスの一覧」などをインプットにカスタムアプリの設定を実施した方がいいと考えています。カスタムアプリとはユーザーが通信先やポート等を指定してNetskopeに個別に登録するアプリのことです。Netskope Cloud Firewall（CFW）ではこのカスタムアプリ単位でのポリシーを作成することができます。

また、カスタムアプリを登録することで、ログを確認した時にアプリケーションを識別することができるようになります。カスタムアプリを登録しないままだと[unkown]というログばかりで、後続のホワイトリスト定義の工数が増えます。

注意
当社ではCFW有効化から1週間で300件ぐらいユニークなIPアドレスが見つかりましたが、ほぼ同じサービスのIPでした。（僕は全部ググって調べました。。）最終的にカスタムアプリに登録したアプリはそう多くなかったので、もし僕がカスタムアプリの登録をCFW有効化前にしていたら、めちゃくちゃ工数削減できたと思っています。

カスタムアプリ登録までのステップとしては、まず、利用しているクラウドサービスやツールのサポートサイトから情報を拾ってきます。「利用しているサービス名」と「FW」とか「ネットワーク要件」とか「IPアドレス」という条件でGoogle検索をかけるという地道な方法でやりました。

登録するカスタムアプリの例

ググると下記のようなサイトがヒットするので、そのサイトをインプットにします。

登録方法

Netskopeの管理コンソールから[Settings] > [Security Cloud Platform] > [App Definition] > [New App Definition Rule] > [Firewall App]の順番に遷移し、カスタムアプリを登録します。

カスタムアプリは以下の項目を組み合わせて利用することで定義します。

  • プロトコル（TCP、UDP、TCP/UDP、ICMP、All）
  • ポート番号（1-65535）
  • 宛先（IP、IPレンジ、CIDR、FQDN、PQDN）

豆知識
カスタムアプリはFirewall App（CFW用）と、Cloud App（CASB/SWG用）に別れます。そして、両方ともReal-time Protectionポリシーの設定で利用できますが、Real-time Protectionの設定画面からは両者をパッと識別することができません。そのため、アプリケーションの命名規則で「CFW-XXXX」などという名前をつけておくといいかと思いました。

また、「カスタムアプリ」という名称で読んでいますが、必ずしもアプリ単位で設定する必要はありません。例えば「22番ポート」というカスタムアプリを作成し、ポート単位での制御に利用することも可能です。運用は楽ですが、きめ細かく管理することができなくなるので、当社はなるべく個別にアプリを指定して登録しています。

IPアドレス制限への対応

Netskope Cloud Firewall（CFW）を有効化すると、全ての通信はNetskopeのデータセンターを経由した通信となります。そのため、「通信先アプリから見た送信元IPアドレス」はNetskopeのIPアドレスに変わります。IPアドレス制限をしている80/443以外のアプリ」がある場合は、アクセスできなくなるので事前に調整が必要です。調整の方法は以下の2種類があります。

IPアドレス制限の調整

アクセス先のサービス側で、許可するIPアドレスにNetskopeのIPアドレスを登録します。NetskopeのIPアドレスの確認方法は別で記事を書いているので、そちらをご覧ください。

NetskopeデータセンターのIPアドレスを調べる方法を教えて（よくあるお問合せ-Netskope編）
NetskopeデータセンターのIPアドレスを調べる方法を紹介しています。
blog.cloudnative.co.jp

Exception設定

特定の通信をNetskopeのデータセンターを経由することなく、アクセス先のアプリに通す設定がException設定です。これをすると、指定した通信の送信元IPアドレスはCFW導入前と変わらないものとなります。設定方法としては、まず上記で紹介したカスタムアプリの設定を行なった上で、[Settings] > [Security Cloud Platform] > [Steering Configuration] > 設定を変更したいCONFIGURATION > [EXCEPTIONS]の順番に遷移し、[New Exceptions]を登録します。

注意
怒られそうな話ですが、私は初回導入時には、IPアドレス制限の調整やException設定を考慮しないまま、CWFを有効化してしまいました。もし当社に「IPアドレス制限をしている80/443以外のアプリ」があれば、アクセスできない事故になっていたと思います。（パイロット展開するユーザーは「IPアドレス制限をしている80/443以外のアプリ」を使っていないことを知っていたから考慮しなかったと言い訳させてください。）

インバウンド通信への対応

CFWを有効化するとインバウンド向けの通信はブロックされてしまいます。もし、CFWを展開する端末に対して、インバウンド通信（例えばRDPなど）を行うユースケースがある場合は事前に、Exception設定を行い、CFWの制御の対象から外しておくことが必要です。Exception設定に関しては、IPアドレス制限への対応と同様の手順となります。

「なんか動かないんだけど」の報告窓口の設置とフロー定義

Netskope Cloud Firewall（CFW）に限らず、Firewall系のサービスで怖いのは、接続できなくなって業務が止まることです。「なんか動かないんだけど」というケースにおいての、報告窓口の設置と以下の様な観点を踏まえたフロー定義（対応手段の確認）は、有効化前に絶対に必要だと思います。

  • どこに報告するか？（緊急時にその窓口が機能するかも含めて検討）
  • 報告を受けて誰が対応するか？
  • 報告を受けてどう対処するのか？（Exceptionする？Real-time Protectionで許可する？そもそもCFWをオフにする？Netskope Client をDisableにしてもらう？等々）

パイロットユーザー用のグループの作成

パイロット展開方式で展開するために、「パイロットユーザーグループ」と「パイロットユーザー以外のグループ」のグループをIdP側で作成し、Netskopeへグループプロビジョニングを行います。ここで作ったグループは後続のRealtime-Protectionの設定や、Steering Configurationの設定で利用します。

注意
当社は上記のような2つの段階にて展開を行いましたが、従業員数が多い場合や組織が複雑な場合は、更に細かくグループを切って進める進め方も考えられます。

パイロット導入フェーズ

Realtime-Protectionで「暗黙の許可ポリシー」を作成

Netskope Cloud Firewall（CFW）は「暗黙のブロック（80/443以外の通信は全てブロック）」がテナント初期設定となっています。この状態でNetskope Cloud Firewall（CFW）を有効化すると、80/443以外の通信はNetskopeの管理コンソールから[Polices] > [Real-time Protection]の順番に遷移し、全ての通信を許可するポリシーを作成します。

  • [Source]の欄には、先ほど作ったグループを全てアサインします。
  • [Destination] は[Any Traffic] にします。
  • [Profile & Action] は[Allow]にします。

ちなみに、上記で紹介したRealtime-Protectionポリシーを利用するケースの他に、Real-time Protectionのページの一番下の[Default Action]の設定からも、「暗黙の許可ポリシー」を作成することができます。ただし、この設定はテナント単位の設定のため、段階的に展開していくためには、Realtime-Protectionポリシーを利用した方がいいと考えています。

パイロットユーザーへのCFW有効化

[Settings] > [Security Cloud Platform] > [Steering Configuration] に遷移し、現状利用しているSteering ConfigurationをCloneする形で、新しいConfigurationを作成します。

その後、作成した新しいConfigurationの設定の[Edit]にてCFWを有効化し、[User Group]にて「パイロットユーザーグループ」をアサインすることで、パイロットユーザーに対してCFWが動作し始めます。ただし、この前段において、Realtime-Protectionで「全許可ポリシー」を作成しているため、ブロックはされず、ログだけが残る状態となります。ちなみに、Steering Configurationが複数存在する場合は、上にあるConfigurationが優先的に適用されます。

動作確認として、各端末のConfigurationを確認します。Traffic Steering Typeが「All Traffic」になっていたら、CWFが有効化されている状態です。ただし、管理コンソールで設定してから、有効化されるまでに結構時間がかかった印象を受けましたので、別の作業をしながら待つのが良いと思います。

ブロックの動作確認

明らかにアクセスしてはならないアクセス先にてブロックの検証を行い、ブロックされた場合のユーザービリティや管理者からの見え方を確認します。この工程は、Netskope Cloud Firewall（CFW）が仕様通りに動くかの確認なので、考え方次第ではスキップすることも考えられるかもしれません。

まずは、ブロックの動作確認をしたいアプリを「カスタムアプリ」で定義します。カスタムアプリの定義の仕方は、「カスタムアプリの設定」をご参照ください。その後、登録したカスタムアプリをブロックするポリシーを[Polices] > [Real-time Protection]で設定します。ブロックにおいて、注意しなければならない仕様は以下の通りです。

  • CASB/SWGで利用できるブロック時のポップアップは現時点ではCFW利用できないため、ユーザ側ではNetskopeでブロックされたのかの確認はできない
  • メール通知の設定が現時点ではできないため、管理者はSkope ITのAlertsを都度確認する必要がある
注意

別ブログにも書きましたが、Netskope Cloud Firewall（CFW）にはブロックできない通信（例えばDNS等）があります。僕はブロックの検証でGoogle DNSを利用しましたが、「CFW動いてないじゃん」と沼にハマりました。CFWで制御できない通信の全容については、Netskope購入元にお問合せください。

ホワイトリスト定義・登録

続いて、最も手がかかる工程である「ホワイトリスト定義・登録」をやっていきます。まずは、[ScopeIT] > [Network Events] に遷移して、ログをエクスポートします。

その後、アプリケーション名が[unkown]となっているログを対象に、プロトコル・ポート・アクセス先IPで重複削除します。この作業を行うことで、調整が必要となるログが明らかとなります。そして、1件ずつプロトコル・ポート・アクセス先IPを確認し、それが何に利用されているかを調査していきます。調査の方法はひたすらググりました。

調査した結果、アプリケーションが判明したら、Excelで作ったパラメータシートに登録し、さらにカスタムアプリにも登録していきます。パラメータシートのフォーマットは参考までに下記に置いておきます。

パラメータシートのフォーマットサンプル

正直、パラメータシートを作らず、直接カスタムアプリに登録するという方法でも導入はできました。しかし、チームのメンバーなどに状況を共有するなどの目的で、若干泥臭く進めました。
Excel（表計算ソフト）でパラメータシートなどを作っていたら、「カッコ悪い」とか「意味ある？」などと刺されてしまいそうですが、現状いい方法が思いついていないので、この方法を取っています。この辺はスマートな管理方法を編み出したいですね。

さらに、登録されたカスタムアプリが会社として許可できるものであった場合、Real-time Protectionでホワイトリスト用のポリシーを作成し、そこに登録しました。

パイロットユーザーへ「暗黙のブロック」の展開

『2.5 Realtime-Protectionで「暗黙の許可ポリシー」を作成』で作成したポリシーの[Source]から、パイロットユーザーグループを抜く形で「暗黙のブロック」をパイロットユーザーに展開します。この設定により、ホワイトリストに設定したカスタムアプリ以外のアプリにはアクセスができなくなります。

運用と対象の拡大フェーズ

運用方面

報告窓口の運用

暗黙のブロックを展開すると、サービスに接続できないという事象が発生することが予想されます。これは、FWを暗黙のブロックで展開している以上仕方ないことです。ただし、それでビジネスを止めてしまっては元も子もありません。そのため、ブロックされた後の運用が非常に大事になってくると思います。CFWの展開と報告窓口の運用はセットで考える必要がありそうです。

CFWのお世話会

前述の通り、CFWは現状、ブロックがなされた場合の管理者へのメール通知を行うことができません。そのため、管理者がブロックのログを確認するには、能動的に管理画面を見に行く必要があります。初めのうちは、「お世話会」という形で定期的にメンテナンスする時間をとると良いと思いました。

新規サービス導入時のフローでチェック

新規サービス導入時のフローにCFWの調整を盛り込むとスムーズに導入が進むと思います。会社ごとにプロセスがあると思いますので、その中にCFWのポリシー調整を入れ込みましょう。

注意
完璧なホワイトリストを定義することはほぼ不可能と言っても過言ではありません。なぜなら、事業も利用するサービスも変化していくからです。そのため、CFWは入れた後のお世話が非常に重要です。

CFW有効化の対象の拡大方面

運用がある程度落ち着いてきたら、『2.7パイロットユーザーへのCFW有効化』『2.7ホワイトリスト定義』『2.9パイロットユーザーへ「暗黙のブロック」の展開』のプロセスの「パイロットユーザー」の部分を「全社ユーザー」に置き換えて、もう一度やる流れで全社に展開していきます。従業員が多い場合などは、段階に分けて実施することが考えられます。

終わりに

Netskopeの管理コンソール上からログが取れて分析できることがホスト型FWと比べての大きな強みではありましたが、それでも展開・運用は大変でした。また、冒頭にも書きましたが、「ベストなやり方を見つけた」とは思っていません。今後もNetskope Cloud Firewall（CFW）と深く向き合ってより良い方法を模索していきたいと思います。読者の皆様も気になる点があれば、忌憚のない意見をお聞かせ下さい。

ぐっち

コンサル会社にてISO27017やISMAP等のセキュリティ規格案件を経験した後、クラティブに入社。セキュリティチーム所属ですが、最近は生成AI等を使ったシステムの開発や導入をやっています。趣味はダンス。Microsoft MVP for AI Platform & M365(Copilot)

記事一覧