既存インフラに優しいSaaSアプリの可視化と制約のない制御

Sep 14, 2022
1 minutes
49 views

はじめに

Shadow IT 対策の必要性が認知されて久しいですが、対策は進んでいますでしょうか。

対策が進んでいる皆様、おめでとうございます、しっかりと制約なく可視化/制御できているのであればこの記事をお読みいただく必要はないかもしれません。これから対策を行われる皆様は、できるだけ既存インフラの構成に変更を加えず、制御を実施したい場合に制約事項の少ないソリューションを選ばれたいのではないでしょうか。

じつは、SaaSセキュリティサブスクリプションがそうした要求にお応えできるサービスのひとつです。

そこで本記事では、弊社の次世代ファイアウォールとSASEソリューションサービスPrisma Accessを既にお使いの方、またはこれから検討される方に向けて、SaaSセキュリティサブスクリプションを中心としたShadow IT 対策を解説します。

SaaS可視化制御に必要な構成

1. 既存インフラから移行しやすいか?

SaaSアプリケーションを可視化するしくみにはいくつか種類があります。ここでは代表的なProxy型とAgent型を取り上げます。

Proxy型 すでにProxyサーバーを利用している場合、多段Proxy構成にすることで移行しやすくなります。一方、Microsoft 365をはじめとした多くのアプリケーションには「Proxy経由でのアクセスを推奨しない」という課題があります。実際、多くのProxy型製品が、セキュリティをバイパスしてこれらProxy非推奨アプリに接続してしまっています。つまり、「対象アプリを信頼すること」が前提となりますので、ゼロトラストの一環でSaaSセキュリティを考えている場合、ポリシーに反する実装・設計となりかねません。
Agent型 端末へのインストールや展開には手間がかかりますが、しっかり可視化して情報が取れるのが利点です。ただしソリューションは玉石混交なので注意が必要です。識別対象アプリを制約なく制御できるものもあれば、識別できるアプリ数が多くても制御できるアプリが極端に少ないものもあります。この点に注意して、できる限り制約なく制御できるソリューションを選ぶとよいでしょう。

2. SaaSアクセスインフラの構成はシンプルか?

Proxy型・Agent型のいずれを選ぶにせよ、Cloud型のSASEソリューションを選べばSaaSアクセスインフラの構成はシンプルになります。ここでは少し視野を広げ、「社内リソースへのアクセスやZTNA (Zero Trust Network Access) の要件を加味して、シンプルな構成をとれるSaaSセキュリティ対策か?」という点から評価するとよいでしょう。実際、筆者がSaaS可視化制御要件をお持ちのお客様とお話したなかでは、テレワーク時の社内アクセス要件を持たないお客様はおられませんでした。ですからこれはあながち的外れな拡大解釈でもないでしょう。

Proxy型製品:ZTNA要件ソリューションは別製品連携が必要

「最初はSaaSアクセス要件だけを比較検討してProxy型製品を選んだ。後から社内リソースアクセス要件を追加で検討したので別製品との組み合せになった。管理画面は別だし、それぞれのシステムの構成要素も別だし、構成も複雑になってしまった」。こんなふうに後悔されるお客様は、残念ながらゼロではありません。ほかにも「Proxy型製品だから、PACファイルの運用は必要でもAgentの展開は不要と考えていた。ところが後からZTNA要件が生じて結局クライアントへのインストール展開が必要になってしまって想定外だった」というケースもよく聞きます。こうしたケースを考えると、ZTNA要件がまったくない場合をのぞき、社内リソースへのアクセス要件は、当初から構成に含めて選定すべきでしょう。なおこのさい、多くの製品で「コネクタ」と呼ばれる仮想マシンを自社設備内に構築する必要がある点に注意してください。これを忘れていると「クラウドサービス採用でサイジングの苦労から開放されるはずが、当初の構想と違う」ということになりかねません。まとめると、Proxy型製品を選ぶ場合は「ZTNA要件は限りなく少ない」「Web以外の業務アプリケーションがない」という両方の条件に自社が当てはまることを確認すべきでしょう。

図1
図1 ポイントソリューションを複数利用した環境。複数の管理画面になったり結局Agentの展開が必要になるなど意外な落とし穴が

Agent型製品:ZTNA要件では「サーバー発クライアント宛」通信に注目を

Agent型製品のなかにも、社内リソースアクセス要件を満たすソリューションに別製品との連携が必要なものがあります。これだと構成と運用が複雑化してしまうので、まずは「SaaSセキュリティ対策と社内リソースアクセス要件の両方を同一製品で満たせるか」を評価基準にするとよいでしょう。また、「クライアント端末から社内リソースへのアクセス」と「社内リソースからクライアント端末宛のアクセス」の両方向の制御が可能かどうかも確認しておきましょう。たとえば「社内の資産管理サーバーからクライアント宛へのプッシュ型通知を制御したい」という要件が後から生じる場合があるからです。両方向の制御が可能な製品は意外とすくないので、この要件は重要な選定ポイントになります。いつなんどき、どんな種類の制御が必要になるかはわからないものです。できるかぎり事前の制約がすくない製品を選んでおきましょう。

図2
図2 Agent型製品を使う場合は対象アプリの制御や通信の方向にできるだけ制約のないものを探す必要がある。たとえば Prisma Access の場合、通信方向やアプリの種類に制約がない

SaaSセキュリティ要件とZTNA要件の両方をシンプルに満たす構成とは

これまでに見てきたSaaSセキュリティ要件とZNTA要件の両方を、できるだけ既存インフラ構成を変えずにシンプルに満たす方法のひとつが、Prisma AccessとSaaS Security Subscriptionを合わせて利用する方法です。

この方法では既存インフラの構成変更が必要ありません。Prisma Accessにクラウド提供型のSaaSセキュリティ対策をアドオンするだけなので、利用者から見た使い勝手もこれまでと変わりません。可視化はライセンスを追加するだけで手に入りますし、それ以外の要件が後から追加されても、管理者が必要に合わせた制御設定を追加するだけで実現できます。導入から運用まで、すべてがシンプルです。くわえて、機械学習によって識別・制御が可能なSaaSアプリケーションも随時追加されます。たとえばリリース当初1万5千種類だった対応アプリは、2022年7月22日現在では4万種類(40,783)以上に増えていますし、これらのアプリはすべて例外なく制御可能です。今後どれほどSaaSアプリが増えても、システムが自動で追加してくれるしくみを採用していれば、人手による作業量を減らしてくれます。この点も選定ポイントとなるでしょう。

図3
図3 CASB プラットフォーム。SaaS Security Inline が可視性を高めつつインライン制御を行い、SaaS Security API が承認済みアプリを可視化して制御
図4
図4 SaaS は今後ますます増加していくのでアプリを手動で追加していく手間がいらないことも重要な選択ポイントに

まとめ

SaaSセキュリティ対策を実施する場合は、テレワーク時の社内リソースアクセス要件を考慮し、構成・導入が煩雑にならないか、最終構成がどうなりそうかを加味し、自社のポリシーや運用方針にあったソリューションを選んでください。

パロアルトネットワークスでは、セキュリティインフラの設計を最初から最後までご支援するプログラムも提供しています。セキュリティインフラ設計のご相談は、ぜひ弊社営業担当窓口 infojapan@paloaltonetworks.com までお問い合わせ下さい。


Subscribe to the Newsletter!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.