SSE（Security Service Edge）入門 ｜＜後編＞　～SSE PoCから得られた知見、主要4製品の特徴と違い、導入時の注意点

Text＝堀口 稔和、佐野 悠輝　（日本アイ・ビー・エム システムズ・エンジニアリング）

＜前編からつづく＞

SSE PoCから得られた知見

後編では、複数ベンダーのSSEのPoCから得られた知見を紹介する。ベンダー固有の特徴や制約などもあったが、複数の製品で共通しているトピックもあり、今後SSEの導入を検討する際には有益な情報と考えられる。

PoCの概要

「ローカル・ブレイクアウトを活用しつつ、セキュリティも担保できる」ソリューションとして、SSEのPoCを実施した。SSEの本番環境での導入展開はフェーズ分割する方針のため、PoCの検証構成もフェーズに応じて2つの構成（STEP1、STEP2）で実施している。

まず現状の構成では拠点内／拠点外のいずれも、ブレイクアウト対象のサービスへはDC経由の通信経路となっている（図表8）。

STEP1では拠点内端末のPACファイルの定義を修正し、ブレイクアウト対象サービスの通信はSSEを経由する経路へ変更する（図表9）。

STEP2では新端末にエージェントを導入し、拠点内、拠点外においてWeb以外の通信も含めて保護を実施する。STEP2では、拠点外からのリモート・アクセス機能も提供される（図表10）。

SSEの導入によって、オンプレミスのプロキシサーバーを廃止する方針が多いと思われるが、本件では、SSE導入後もブレイクアウト対象サービス以外の社内外システムサービスにDCのプロキシサーバーを利用する要件があったため、「SSEとオンプレミスのプロキシサーバーの併用が問題なくできる」ことがPoCでの重要な確認ポイントであった。

PoCは、SSEベンダー4社（Zscaler、Cisco、Palo Alto、Netskope）の製品を対象に実施した。

PoC検証項目

PoCでは機能要件の充足度や制約事項の洗い出しに焦点を置き、図表11の項目を検証した。

PoC検証構成

検証では前述したSTEP1、STEP2の構成を簡易的に構築した。

ベンダーごとに詳細な差異はあるが、重複する部分が多いためZscalerとPalo Altoの検証構成を取り挙げて紹介する。なおユーザー／グループ情報の連携先にはAzure ADを使用した。

図表12はZscaler STEP1の検証構成となる。

端末はエージェントレスでブレイクアウト対象サービスの接続先となるURLに対して、PACでZscalerへのプロキシ定義、およびオンプレミスのプロキシ対象の接続先URLに対して疑似社内サーバー上のProxyサーバーへプロキシ定義を実施して、宛先に応じて経路制御を行っている。

ユーザー／グループ情報ベースでの機能を実装するために、ZIA（Zscaler Internet Access）とAzure ADはSAML連携設定を行った。

図表13はZscaler STEP2の検証構成である。

STEP2は、拠点外にてエージェント導入済みの端末から通信する環境としている。エージェントにより、Web通信以外もSSEを経由して通信できるようになっている。

ZscalerではZTNAの機能がZPA（Zscaler Private Access）という製品に実装されているため、追加で構築を実施した。社内システム宛てやDCバックホールでのインターネット宛ての通信には、「App Connector」と呼ばれるZPAのコンポーネント（リバース・プロキシ相当の機器）を経由して通信する経路となる。

続いて、Palo Alto社のPrisma Accessを使用した検証構成を紹介する。

Zscalerと異なり、STEP1構成では拠点からPrisma Accessに対してIPsecトンネル接続している点が大きな違いである。なぜ拠点からIPsec接続する構成としているかについては、SSE導入時の注意点として後述する。

Palo AltoのSTEP1構成（図表14）の場合、ブレイクアウト対象サービス宛ての通信は、拠点内に追加したVPN装置とPrisma Access間のIPsec Tunnelを経由する経路となっている。

オンプレミスでのProxyサーバー経由の通信は、Zscalerの構成と同様にPACファイルで経路制御を実施した。

図表15がPalo Alto STEP2の検証構成となる。

Zscalerと同様に、STEP2は拠点外にてエージェント導入済みの端末から通信する環境としている。

エージェントにより、Web通信以外もSSEを経由して通信できるようになっている。ZTNAでの社内サービス宛て通信については、Prisma Accessの場合、社内リソースが設置してあるDCとPrisma AccessがIPsec接続することでオンプレミスのリソースにアクセスする構成となる。

エージェント経由でオンプレミスのProxyサーバーと通信できるポリシーとすれば、PACファイルを使った経路制御も可能である。

続いて、検証を通して得られたSSE導入時の注意点について紹介する。

SSE導入時の注意点

① エージェントレス構成の制約　

一般的に、SSEベンダーは経路制御やユーザー／端末認証、EDR連携などの各種機能をエージェントで接続する構成を推奨、または前提としている。

SSEのフル機能は、エージェント構成が必要と理解してよい。ただし、何かしらの理由によってスムーズにエージェントを導入できないケースもそれなりに存在する。以下はその例である。

・端末のスペックやOSバージョンの制約で導入できない
・エージェント導入時の業務影響を評価できないので、まずはエージェントレスで導入したい

PoCでもエージェントレスでの検証を実施したが、「エージェントレス構成の場合は、顧客テナント識別やユーザー認証の仕組みが必要である」という制約のあることが判明した。

SSEはインターネット経由で世界中の顧客からの通信を制御する必要があるため、どの顧客ユーザーの通信かを識別する必要がある。

エージェント構成の場合は問題ないが、エージェントレス構成についてもIdP（アイデンティティ・プロバイダ）とSSE間のSAML連携による認証で対応することが可能である。しかし、「ブラウザベースで稼働しない専用クライアントのアプリケーション」がSAML認証に非対応となっていたことで、通信に失敗するという問題が発生した。

エージェントレス構成でSAML認証後のユーザー識別データは、ブラウザセッションのCookieにセットされる仕組みを持っているので、ブラウザの利用が前提となる。

従って、エージェントレス構成ではアプリケーションの専用クライアントを使用せず、ブラウザ版の使用が推奨されるが、ブラウザ版に対応していないアプリケーションの場合はどういった手段がとれるかを紹介する。対応策には、以下の3つがある。

対応策1　固定IPアドレス登録
1つ目の対応策は、拠点のグローバルアドレスをSSEに設定する方法である。固定のグローバルアドレスであれば、一意の識別子として取り扱える（図表16）。

対応策2　IPsec/GREトンネル接続
2つ目の対応策は、拠点のネットワーク機器でSSEとトンネル接続する方法である。トンネルを経由してSSEに転送された通信は、一意の顧客からの通信として識別が可能である。図表14で説明したPrisma AccessのSTEP1検証構成では、この方法を使用した。

対応策3　専用プロキシポート接続
3つ目の対応策は、顧客に専用のポート番号を払い出してプロキシ接続する方法である。専用ポートは別の顧客に払い出されないことになるので、通信の宛先ポート番号で顧客の識別が可能である。図表12で説明したZscalerのSTEP1検証構成では、この方法を使用した。

以上、3つの対応方法を紹介したが、それぞれデメリットやベンダーごとの対応状況が異なる。図表19にそれらをまとめる。

対応策1は、対応ベンダーは多いものの、固定グローバルIPが必須となる。全拠点で固定グローバルアドレスの取得は難しいため、この方法を採用する機会は少ないと想定される。

対応策2は、対応ベンダーが多く内容もシンプルだが、既存環境からの変更作業が多く発生するデメリットがある。

対応策 3についてはZscalerしか対応していないが、PACのポート番号を修正する作業のみで変更作業量は最も少ない。オプションでの有償ライセンスとなるが、トータルコスト観点では他の方法に比べて高価とも言えず、有力な対応方法になるだろう

② SSL復号の可否

次の注意点は、SSL復号に関するものである。SSE導入前にすでにSSL復号装置を使用しているユーザーは知っているだろうが、アプリケーションによってはSSL復号の割り込みに対応できない製品が存在する。

SSEで初めてSSL復号機能を適用する環境では要注意である。そのため単純にすべてのインターネット経由通信をSSL復号対象にすると、一部のアプリケーションで通信障害が起こり、業務が停止するリスクがある。

SSL復号の割り込みができない通信としては、Windows Updateのように特定のSSL証明書の使用に限定されていることが原因として多く見受けられる。

従って、次のようにSSL復号対象を検討する必要がある。

・すべてのアプリケーションをSSL復号する必要があるのか
・どのような宛先をSSL復号すべきなのか
・法的にSSL復号してはいけないこともあるのではないか

図表20はSSL復号対象とすべきか、否かの筆者の考え方をカテゴリごとにまとめたものである。SSEに限らず、SSL復号装置を導入する場合の参考にしてほしい。

また、事前に業務で使用するすべてのアプリケーションに対してSSL復号可否を見極めることは難しいので、必ずパイロット期間を設け、必要に応じてチューニングも実施する。

実際にSSL復号の問題が出た場合の対応方針は、プロジェクトメンバー間で意識統一しておいたほうが後の対応作業はスムーズになるだろう。たとえば、以下のような方針である。

・該当アプリケーションの開発元から問題時にSSL復号除外のガイドが公表されている場合は、SSL除外設定
・該当アプリケーションのSSL復号の必要性が低ければ、SSL除外設定
・SSL復号が必要なアプリケーションの場合は開発元に問い合わせ、SSL復号の可否を確認

③ 送信元IP固定機能の要件

次の注意点は、SSEの送信元IP固定機能についてである。

SSEを使用することで宛先のアプリケーションに到達する際の送信元IPは、ユーザーがインターネットに出る際のIPアドレスではなく、SSEを経由するためSSEベンダーが保有しているIPに変化して到達することになる。

既存で送信元IPを制限している場合は要注意である。たとえば、社員が自宅から業務利用しているSaaSへ接続しないように自社のDCのIPアドレスで制限しているケースなどがある。

送信元IP固定機能を使用する場合はSSEのライセンス費用にも影響があるので、事前に必要性を確認しておくことは重要である。

今回のPoCで4ベンダーの製品を対象としたが、送信元IP固定機能のアーキテクチャには大きく2つのパターンが存在することがわかった（図表21）。

Netskopeのみ両方の方式に対応しているが、基本的にはベンダーごとに方式が決まっているので、SSE選定の際には送信元IP固定機能のサポート有無だけでなく、どういった送信元IP固定のアーキテクチャになるかも考慮に入れてほしい。

③ ユーザー／グループ情報のプロビジョニング

続いてはユーザー名、グループ名を条件としてアクセス制御を行う要件がある場合の注意点である。

この要件を満足するには、IdPとのIDプロビジョニングが必要となる（図表22）。

オンプレミスのActive Directory/LDAPとのID同期はディレクトリ同期の機能を使うため、SCIM（System for Cross-domain Identity Management：スキム）連携は不要だが、本稿ではIdPとしてIDaaSを使用するケースを対象としている。

ユーザー情報を活用して制御を実現するといった場合、SAML連携をイメージする読者も多いと思うが、SAML連携はSSO（シングル・サインオン）のような認証機能の役割を担当し、IDプロビジョニングの機能とは異なる。

IDプロビジョニングには、SCIMという標準規格のプロトコルが担当する。SCIMによってID情報の提供や同期が可能となり、SSEへのユーザー／グループ情報のプッシュやIdP側でのID情報の変更がSSE側へも自動反映される動作を実現する。

PoCで複数のSSE製品を操作したが、ユーザーやグループをマニュアルでローカル作成できないものが大半であった。それらは外部のIdPから取得するアーキテクチャになっていることが想定された。

従って、連携先のIDaaSについてはSCIMをサポートしているかの確認が重要である。これはIDaaS側に依存した課題と言える。主要なIDaaS製品の多くはSCIMをサポートしているが、SCIMのサポートがないIDaaSも中にはあるので注意してほしい。

④ CASBの種類

最後に、SSEでサポートされるCASB機能の種類について紹介する。

SSEでは主に2種類ある。いずれか一方だけでなく、両方のCASBを使用することも可能である。2つのCASBについて、それぞれの特徴や注意点についてまとめたものを図表23に示す。

図表の左側は、「Inline CASB」と呼ばれるCASBについて説明している。名前のとおり、SSEを通過する通信を対象としたCASBが該当する。

通信が通過する際に検出・保護が実行されるため、リアルタイムでの制御が可能である。注意点としては、対象のクラウドサービスによってどれだけ詳細にCASB制御できるかが異なること、それがマニュアルなどに明記されていないことが挙げられる。

CASBではファイルのアップロード／ダウンロード制御だけではなく、ファイルの編集やユーザーの追加／削除、リンクの共有化を制御するような機能もあるが、実機を操作できない状況で、特定のクラウドサービスに対して使用できるかの判断を机上で行うのが難しい。

図表の右側は、「API CASB」と呼ばれるCASBについて説明している。SSEが対象のクラウドサービスに対して定期スキャンを実施する方式となり、端末からの通信がSSEを経由しない構成でも対象クラウドサービス上のデータを保護できる。

API CASBは、エージェントを導入できない協力会社のユーザーや、社員でもBYODユーザー（エージェント導入不可の場合）が保護対象のクラウドサービスを利用する場合などがユースケースとして考えられる。

Inline CASBであっても、リアルタイム制御はできない。また制御対象となるのはDLPやマルウェア保護といった範囲に限られているので、それらに違反しない内容のファイルのアップロードをAPI CASBでブロックするようなことはできない。

API CASBの注意点としては、対象にできるクラウドサービスがSSEベンダーによって決まっていること、それらのサービスでライセンスの制約があること、管理者権限を持つユーザーが必要になることなどが挙げられる

SSEとクラウドサービス間のAPI連携時に構築が必要になる場合は、一般権限のユーザーではなく、管理者権限のユーザーが必要になる点に注意してほしい。

SSEで必要なスキルエリア

SSEを構築・運用する上で必要と考えられるスキルエリアについて説明する。

SSEでは、従来さまざまな個別のセキュリティ製品に実装されていた機能が1つに統合されているため、カバーすべきスキルエリアが非常に多い。図表24に必要なスキルエリアの一覧を示す。スキルエリアごとの優先度は要件次第となるが、参考までに筆者の考えを記載した。

もちろん1人の担当者ですべてのエリアをカバーする必要はないので、プロジェクトチームメンバーで互いに補完してほしい。

以上本稿では、SSEの概要とSSEのPoCから得られた知見を紹介した。

選定時は、ベンダーごとの強みやユーザー環境を把握しておく必要がある。実際のSSE構築が決定した際は、導入に関する注意点の内容を参考にしてほしい。