Netskope環境下でのテレワークにおけるIP制限の方法を考えてみた

テレワーク環境下で課題となるシステムへの固定IPアクセスについてNetskope Private Accessを利用した方式を検討してみました。
2021.10.04

こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です。

はじめに

ネクストモードではSaaSやWebへのアクセスの際にNetskopeを経由する構成を取り、通信の可視化や制御を行っています。

特定の環境に接続する際にIP制限が必要なケースがあり、様々な方法を検討したので、今回はその過程を残してみようと思います。自分の中で「これだ!」という結論は出ていないですが、検討の流れはすごく大事だと思ったので自分の備忘録も兼ねて残します。

Netskopeとは

Netskopeとは、クラウドサービス使用時に生じる情報漏洩のリスクや、外部の第三者による不正アクセス、マルウェアの感染といった脅威から機密情報を守り、SaaS環境のセキュリティを強化することができるSASEソリューションです。

ことの始まり

ネクストモード社内で利用しているSaaSについては基本的にはOkta経由でのシングル・サインオンにしているのでIP制限は必要ありません。しかし、お客様のシステムにアクセスする必要がある際にIP制限を求められた場合など、別途IP制限の仕組みを考える必要が出てきました。

課題

リモートワーク中心で業務をしているため、ほとんどのメンバーが固定IPを持っていません。そのため、IP制限が必要なケースで制限するIPが可変となってしまうことが課題でした。

対策を考えてみた

社内でも要望があったので、対策案をいくつか考えて、メリデメを洗い出してみました。

案1:NetskopeのIPレンジでIP制限

Netskopeのグローバルインフラである「Netskope Security Cloud」のIPアドレスレンジが固定となります(Netskope側のアップデートでEdgeのIPレンジが追加・変更になることは稀にありました)。 Netskopeをクライアント方式(エージェントインストール)で利用している場合、HTTP/S通信はソースIPがNetskopeのIPアドレスになるため、このIPアドレスレンジで制限することを考えてみました。

メリットとデメリットを考えてみましたが、こちらの案はケース次第ですが採用は難しそうです。

メリット

Netskopeの既存の運用に手を加えることなく実施できます。Non-StandardPortをNetskopeに誘導する機能を利用すればHTTP/Sだけでなく他のポートへの通信の制御も可能です。

デメリット

NetskopeのIPレンジはユーザ/テナント個別に付与されるものではないため、Netskope全ユーザからアクセスできるようになってしまうため、IP制限としては不十分と言えるでしょう。

案2:AWS Client VPNからNAT Gatewayを抜ける

案1のデメリットを解消すべく、自社の固定IPアドレスを持つことを考えました。

構成としてはAWSにClient VPNで接続し、NAT Gatwayでインターネットに抜けるという方法です。

Client VPNからNAT Gatewayを利用してインターネットに接続する設定については下記のエントリーを御覧ください。

メリット

案1の全Netskopeユーザに解放されたIP制限という課題は解消されます。また、Client VPN、NAT GatewayというAWSのマネージドサービスを利用するためサーバ管理コストがありません。

デメリット

Client VPNとNetskopeは干渉するため、Netskopeへの通信からClient VPNの通信を除外(Exception)する必要があります。そのため、通信の可視化・制御が果たせなくなります

Client VPNは接続単位で課金が発生するため、サーバ管理コストは無くなりますが全体費用としては上がってしまう可能性があることも注意点となります。

案3:踏み台サーバを立てる

IP制限が必要なシーンがそこまで多くない場合は随時踏み台サーバを立てる運用もありかもしれないと思っていましたが、結論から言うとこちらはNetskope環境下ではメリットはほぼないと考えています。

デメリット

まず踏み台サーバへのアクセスは基本SSH/RDP通信なので、可視化や制御は出来ません。

先に記載した、Non-StandardPortをNetskopeに誘導する機能を使って、踏み台サーバへの通信をNetskopeに誘導したとしてもその先のどのサイトにアクセスしたかはわからないため、可視化という観点では不十分と言えます。

また、運用面のデメリットとして踏み台サーバの管理が煩雑となる可能性があります(サーバー費用の予測や管理も難しくなります)。

案4:Netskope Private Access(NPA)を使う

案2,3のデメリットを解消すべく、Netskope Private Access(NPA)の利用を検討してみました。

NPAは社内システムへのVPN接続の代替となり、かつNetskopeで可視化・制御することができるので、NPAの終端サーバーとなるNetskope PublisherへPrivateAccessしつつ、NAT Gateway(=固定IP)を経由して特定ドメインへポートフォワードができれば良いのではと考えました。

 

メリット

Netskopeの1機能として利用できるため固定IPでの通信の可視化や制御も可能になります。HTTP/S以外の通信の制御も可能です。

下記のように特定のホスト・ポートを指定してフォワーディングすることが可能です。

通信の制御も細かく制御することができるので、例えば特定のユーザのみに制御を限定することも可能となります。

デメリット

NPA用のパブリッシャーと呼ばれるサーバ管理コストとNetskope Private Accessのライセンス費用が発生します。

NPAの設定については、別途設定毎にブログにアップしていこうと思っていますが、設定についてはユーザーガイドをご参照ください。

現状の方針

ネクストモードではIP制限が必要なケースはそこまで多くないため、暫定的に案3:踏み台サーバで対応しています(お伝えしたとおり、得策ではありません)。しかし、他のNPA利用ケースも見据えて案4:NPAの導入を進めています。

お客様の専用のVPNでアクセスが必要なシステムについてはNetskopeへの通信からの除外設定しています。

さいごに

端切れの悪い記事になってしまったかもしれないですが、リモートワークが進む中で同じような悩みを抱えている方も多いかと思います。

コスト(費用、稼働)を抑えつつ、セキュリティ面を意識した形を模索し続けますので、またアップデートがあれば紹介させていただきます。