はじめに こんにちは、セキュリティを気にする年頃の ネクストモード株式会社 のtommyです...
はじめに
こんにちは、セキュリティを気にする年頃の ネクストモード株式会社 のtommyです
ネクストモードではSaaSやWebへのアクセスの際にNetskopeを経由する構成を取り、通信の可視化や制御を行っています
特定の環境に接続する際にIP制限が必要なケースがあり、様々な方法を検討したので、今回はその過程を残してみようと思います
自分の中で「これだ！」という結論は出ていないですが、検討の流れはすごく大事だと思ったので自分の備忘録も兼ねて残します
Netskopeとは
Netskopeとは、クラウドサービス使用時に生じる情報漏洩のリスクや、外部の第三者による不正アクセス、マルウェアの感染といった脅威から機密情報を守り、SaaS環境のセキュリティを強化することができるSASEソリューションです
Netskopeは会社が許可していないクラウドサービスの挙動を制御する機能や、通常と異なるアクティビティを検知し防御する機能が豊富な特徴を持っています
ことの始まり
ネクストモード社内で利用しているSaaSについては基本的にはOkta経由でのシングル・サインオンにしているのでIP制限は必要ありません
しかし、お客様のシステムにアクセスする必要がある際にIP制限を求められた場合など、別途IP制限の仕組みを考える必要が出てきました
課題
リモートワーク中心で業務をしているため、ほとんどのメンバーが固定IPを持っていません
そのため、IP制限が必要なケースで制限するIPが可変となってしまうことが課題でした
対策を考えてみた
社内でも要望があったので、対策案をいくつか考えて、メリデメを洗い出してみました
案１：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制限としては不十分と言えるでしょう
案２：AWS Client VPNからNAT Gatewayを抜ける
案1のデメリットを解消すべく、自社の固定IPアドレスを持つことを考えました
構成としてはAWSにClient VPNで接続し、NAT Gatewayでインターネットに抜けるという方法です
Client VPNからNAT Gatewayを利用してインターネットに接続する設定については下記のエントリーを御覧ください
メリット
案１の全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の固定IPオプションを使う
Netskopeのグローバルインフラである「Netskope Security Cloud」のIPアドレスを自社専用で利用することも可能です
ライセンスは「Netskope Dedicated Egress IP」というライセンスが必要になります
メリット
サーバ管理やサーバ利用料がかからないため、最小稼働での運用が可能です
デメリット
ライセンス購入のためのコストがかかります。また、このライセンスを購入するための最低ライセンス数による条件があります
今回は条件をクリアできないことから採用できませんでした
案5：Netskope Private Access(NPA)を使う
案2,3のデメリットを解消すべく、Netskope Private Access(NPA)の利用を検討してみました
NPAは社内システムへのVPN接続の代替となり、かつNetskopeで可視化・制御することができるので、NPAの終端サーバーとなるNetskope Publisherを経由して特定ドメインへPrivateAccessできれば良いのではと考えました
メリット
Netskopeの１機能として利用できるため通信の可視化や制御も可能になります
HTTP/S以外の通信の制御も可能です
下記のように特定のホスト・ポートを指定してフォワーディングすることが可能です
通信の制御も細かく制御することができるので、例えば特定のユーザのみに制御を限定することも可能となります
デメリット
NPA用のパブリッシャーと呼ばれるサーバ管理コストとNetskope Private Accessのライセンス費用が発生します
NPAの設定については、別途設定毎にブログにアップしていこうと思っていますが、設定についてはユーザーガイドをご参照ください
現状の方針
ネクストモードではIP制限が必要なケースはそこまで多くありませんが、今後の需要増加を見越して案5:NPAで対応します
しかし、サーバ管理コスト等は発生しますので、なるべく費用を抑えるために夜間は停止する仕組みの導入を検討する必要がありそうです
お客様専用のVPNでアクセスが必要なシステムについてはNetskopeへの通信からの除外設定しています
まとめ
上記の案１～案５をまとめます
案１：NetskopeのIPレンジでIP制限
Netskopeの導入ができていれば簡単に利用できますが、他社とIPレンジが共通なためIP制限としては不十分です
案２：AWS Client VPNからNAT Gatewayを抜ける
案1のデメリットは補えていますが、Netskopeと干渉するため可視化・制御ができません
案３：踏み台サーバを立てる
お客様環境へのアクセスは出来ますが、可視化や制御ができずサーバ管理や費用も発生してしまいます
案４：Netskopeの固定IPオプションを使う
IP制限ができますが、最低購入ライセンスの条件があります
案５：Netskope Private Access(NPA)を使う
通信の可視化や制御ができますが、サーバ管理費用とNPAライセンス費用が発生します
さいごに
端切れの悪い記事になってしまったかもしれないですが、リモートワークが進む中で同じような悩みを抱えている方も多いかと思います
コスト（費用、稼働）を抑えつつ、セキュリティ面を意識した形を模索し続けますので、またアップデートがあれば紹介させていただきます
