MENU

SSE(Security Service Edge)入門 |<前編> ~SSEの概要から課題、導入のポイントまで

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

SSEの概要

SSE登場の背景 

2010年代以降、業務を行う際のアクセス先は多様化している。図表1のように、SaaSやIaaSなどのクラウドサービスにアクセスして作業するケースが増え、それが主流となりつつある。

図表1 業務通信経路の概要

この場合、企業が定めているセキュリティポリシーに沿って通信を行う必要がある。これを実現するために、社員はいったんデータセンター(以下、DC)のセキュリティ基盤を経由しているケースが大多数である。

またコロナ禍でリモートワークが増加し、拠点外からDCへのVPNセッション数が大きく増加したことは記憶に新しい。コロナウイルスが5類に移行して以降、出社制限が緩和される中でも、大多数の企業がリモートワークを継続していることから、この傾向が今後も続くと予想される。

SSEの課題

SaaSやIaaSへのアクセスやVPNセッション数が増えることで、3つの課題が生じる(図表2)。

図表2 社内ネットワークに対する課題

課題1:社内WAN回線の帯域不足
拠点内の社員がSaaSやIaaSへアクセスする場合、WAN回線を経由するため、WAN回線の帯域が逼迫し、通信遅延が発生するため業務効率が悪くなる。

課題2:DCのセキュリティ基盤のスペック不足
セキュリティ基盤を経由する通信量や通信セッション数が増加し、セキュリティ基盤のスペックを超えた場合、通信遅延の発生やセッションが確立できなくなる。これらはセキュリティ基盤のスペック強化で解消できるが、その分コストが発生する。

課題3:リモート・アクセス終端装置のセキュリティ脆弱性
脆弱性が発覚するたびに、情報収集や対策を講じる必要がある。そのため、作業コストが余計に発生することが挙げられる。

課題1は、拠点にインターネット回線やSD-WAN(トラフィックの種別に応じて使用する回線を制御する技術)とセキュリティ機器を導入することで解消できる(ローカル・ブレイクアウト)。

しかし各拠点にセキュリティ機器を設置する方法は、コストや運用面から現実的ではない。また、課題2や課題3に要するコストも軽視できない。そこでクラウド上のサービスを利用することで、セキュリティを担保しつつコストを抑えられる。このクラウドサービスをSSE(Security Service Edge)という。

図表3 課題に対する解決方法



このSSEとSD-WANを組み合わせたフレームワークをSASE(Secure Access Service Edge)と言う。SASEはGartner社が2019年に提唱したフレームワークである。本稿はSSEについて紹介する。

SSEとは

SSEの特徴やSSEを導入することにより得られるメリットを紹介する。SSEを構成するコンポーネントは、以下のようにSWG、CASB、FWaaS、ZTNAの4つである。

◎SWG(Secure Web Gateway)
ユーザーがWebサイトへアクセスする際、アクセス先のサイトが悪意のあるサイトであればブロックするクラウド上のプロキシサービスである。

◎CASB(Cloud Access Security Broker)
SaaS上のファイルに対する制御を実行する。たとえば、SaaS上のファイルへアクセスして閲覧することは可能であるが、ダウンロードを禁止するように制御する。このようにファイルに対する操作を制御することで、人為的な情報の流出を防ぐ。

◎FWaaS(Firewall as a Service)
SSE上でURLフィルタリング、IPS、DNSセキュリティなど、Web以外の通信に対して制御を実行するファイアーウォールサービスである。

◎ZTNA(Zero Trust Network Access)
DCや社内へのアクセスについてSSE上で定義されているアクセスポリシーに沿って、リモート・アクセスを制御する。

SSEを利用することで、本稿の冒頭で紹介した課題は図表4のように解消できる。

図表4 SSE導入によるメリット

課題1への対策
社内セキュリティを遵守しながらローカル・ブレイクアウトができるため、WAN回線を使用せずにインターネットアクセスができるようになる。

課題2への対策
SSEはクラウドサービスのため、ローカル・ブレイクアウトする拠点ごとにセキュリティ製品の設置が不要となる。さらにSSEのスペックを強化する際はSSEベンダーが実施するため、ハードウェアに関するコストを削減できる。

課題3への対策
パッチ適用などセキュリティ脆弱性対策はSSEベンダーが対応するので、その分作業コストが削減できる。

SSEの構成

FWaaSとCASBは構成に依存しないため、本稿ではSWGとZTNAの構成について紹介する。

◎SWG

端末の通信がSWGを経由する構成は、主に3つある(図表5)。

図表5 SWGの構成

① 端末にAgentを導入している構成
Agentを導入した端末の通信は、リモートから送信される場合でもSWGで保護される。端末からの全通信が保護対象である。

②端末にPAC ファイル(Proxy Auto-Configuration)を導入している構成
SWGで保護対象となる端末からの通信はポート80、443のWeb通信のみである。

③拠点のVPN装置がSWGとトンネルを形成する構成
端末からの全通信がトンネルを経由するため、端末からの全通信が保護対象である。

◎ZTNA

ZTNAは、大きく分けて2つの構成がある(図表6)。

図表6 ZTNAの構成

1つ目の構成は、リモート・アクセスVPN型である。この構成はZTNAとIPsec VPNを形成する必要があるため、VPN終端装置がDCに必要である。

2つ目の構成は、リバース・プロキシ型である。この構成はリモート・アクセスVPN型と異なり、リバース・プロキシの役割を担う仮想アプライアンスがDCに必要である。

導入時に検討すべきポイント 

前述したように、SSEを利用するにはPACファイルやVPN終端装置など、さまざまな要素が必要である。そのためSSEを導入する場合は、対応や変更など検討すべきポイントが多数ある(図表7)。さらに、導入するユーザー環境の固有な構成や設定も考慮が必要である。

図表7 SSE導入時の考慮ポイント



SSEベンダーごとの特徴 

本稿では、筆者がPoC案件を通じて「Zscaler」「Cisco」「Palo Alto」「Netskope」の4社製品について検証・調査した結果を元に、各ベンダーのSSE製品について特徴を紹介する。

◎Zscaler

ZscalerのSSE製品は、「Zscaler Internet Access」(以下、ZIA)と「Zscaler Private Access」(以下、ZPA)である。

ZIAはWebサイトやSaaSへアクセスする際にセキュリティを担保する。ZPAはリバース・プロキシ型のZTNA製品である。またZscalerは世界中に150を超えるDCを所持しており、セキュリティチェックを高速に実施できるため、SWGを重視する場合に強みがあると言える。

◎Cisco 

CiscoのSSE製品は、「Cisco Plus Secure Connect」(以下、CPSC)である。CPSCの前身はUmbrellaというセキュリティ製品である。Umbrellaは端末からDNS問い合わせが着信した後、宛先が危険なサイトであればブロックする製品である。

そのUmbrellaの機能を拡張したSSE製品が、CPSCである。Umbrellaでは80、443ポート通信のみが保護対象であるが、CPSCではポート番号によらず、全通信を保護対象としている点が特徴である。

それ以外にも、UmbrellaにはVPN機能はないが、CPSCではクラウド上のCPSCがDCとVPNを形成することも特徴として挙げられる。このCPSCは、2023年秋頃から日本DCもサポートが予定されている。

Ciscoはネットワーク分野でも高いシェアを誇っており、自社製品のSD-WANもリリースしている。そのため、SD-WANとSSEのどちらも自社製品で完結できる点が強みである。

◎Palo Alto

Palo AltoのSSE製品は、「Prisma Access」である。Palo Altoはセキュリティ分野に強みがあり、ファイアウォール製品で培われてきたセキュリティ機能がPrisma Accessに実装されている。そのため、ファイアウォールの機能を重視する場合に強みを発揮する。

◎Netskope

NetskopeのSSE製品は、「Netskope Security Services Edge」である。この製品は対応しているクラウドアプリケーション数が約4万種類と多く、さらに他ベンダーよりも詳細に制御できる。このような理由から、NetskopeのSSEはCASB市場で高い評価を受けており、CASBで詳細な制御の要件がある場合に強みを活かせる。

選定時の考慮点

前述したように、各ベンダーはSSEのコンポーネントで何かしらの強みや豊富な実績を持っている。また各ベンダーのSSE製品は、対応範囲に差はあるが、基本的に全SSEコンポーネントが含まれることが特徴である。

一般的に製品選定ではドキュメントベースで比較する場合が多い。しかし製品をテストしてみると、ドキュメントを読むだけでは気づかない制約や仕様が存在することを認識できる。

その制約や仕様が製品選定に大きく影響するケースもある。そのため、実際に機能テストをして制約や仕様を認識、考慮した上で、ユーザーにとって優先度の高い要件を満たすベンダーを選定する必要があると考える。

<後編につづく>

sano

著者
佐野 悠輝氏

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
オープン・コンピテンシー・センター
クラウド・ネットワーク
アドバイザリーITスペシャリスト

2014年、日本アイ・ビー・エム システムズ・エンジニアリングに入社。以来、ネットワークを中心とした技術支援に携わり、主に金融業界のネットワーク構築プロジェクトに携わる。現在はワイヤレスの技術支援活動や案件参画を主に活動している。

horiguchi

著者
堀口 稔和氏

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
オープン・コンピテンシー・センター
クラウド・ネットワーク
シニアITスペシャリスト

2009年、日本IBMシステムズ・エンジニアリング入社。入社以来、ネットワーク製品を中心とした技術支援に従事し、主に金融業界のネットワークプロジェクトに参画。ネットワークの設計や構築に携わる。現在はネットワーク・セキュリティ領域のPoCや提案案件にて活動を行っている。

[i Magazine・IS magazine]