SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

SB C&S

【第1回】HPE Aruba Networking SSEのご紹介 - 概要/準備編

ネットワーク
2024.03.25

2023年にHPE ArubaはAxis Securityを買収し、HPE Aruba Networking SSEがリリースされました。
製品検証を行いましたので、製品概要と検証結果をご紹介させていただきます。

 目次 

【第1回 概要/準備編】 ←本記事
1.概要
2.ユーザーのプロビジョニング
3.社内リソースの接続
4.IPsecトンネルの構築

【第2回 ZTNA編】
5.エージェントレスZTNA
6.エージェントZTNA

【第3回 SWG/CASB編】
7.SWG
8.CASB
9.DLP


1.概要

Networking SSEは製品名称の通り、SSEカテゴリの製品となります。

SSE製品のため様々なSD-WAN製品との組み合わせが可能ですが、
HPE Arubaにてリリース済みとなるSD-WAN製品のHPE Aruba EdgeConnect SD-WANと組み合わせることで、シングルベンダーでのSASEの実現が可能です。

図1.png
図1.1:HPE Aruba SASEコンポーネント


検証時点ではNetworking SSEとEdgeConnect SD-WANとの接続はワンタッチでとまではいきませんでしたが、今後は接続も簡易化され、より統合されていくことが予想されます。

Axis Security自体が2019年創立とSSEベンダーの中でも新しく、ガートナーがSASEを提唱したのとほぼ同時期に創立されています。

SASEベンダーでもその入り口は様々でSWGからSASEへシフトしていったベンダーや、CASBからのシフトといったベンダーがある中で、Axis SecurityはZTNAから始まっています。
検証する中でもZTNA機能の充実度合いを感じ取ることができました。

機能面の概要として、図1の右側がNetworking SSEについてとなりますが、SSEとして大きく4つの機能を押し出しています。

・ZTNA
・SWG
・CASB
・DEM

SSEのコンポーネントの中ではRBIやWAAPaaSには現状非対応となります。

とここまではメーカーのホームページやドキュメント、セミナーといった媒体から誰もが得られる情報かと思いますが、当方の検証の中で感じた優位点としては以下のものがあげられます。

・Webアプリケーション(80/443)以外にも対応したエージェントレスZTNA

・エージェントZTNAでは社内リソース→リモートアクセスクライアントや、リモートアクセスクライアント間での通信を実現

・SWGでの送信元IP固定機能を無償にて提供

では実際の検証の内容をご紹介しながら、上記の優位点についての解説を行いたいと思います。

2.ユーザーのプロビジョニング

SSEを利用するにあたって重要な点の一つとして、SSE製品がユーザー情報を認識できるようにすることがあげられます。(ユーザープロビジョニング)
これは通信許可/拒否の際のアクセスポリシーや、アクセスログの確認等を行うにあたってユーザーの情報が不可欠となるからです。

どこの誰がアクセスしてきているかがわからない状況でアクセスポリシーを設定するのは困難ですし、ログを見ても誰が通信したログなのかがわからなければあまり意味がありません。

Networking SSEではSCIM(System for Cross-domain Identity Management)に対応しており、SCIMに対応したIDaaSよりユーザー情報を取り込み、SAMLによって認証を行うことを基本としています。

また内部DBとしてAxis IdPと呼ばれる簡易的なIdP機能を有しています。

IDaaSを持たないユーザーがNetworking SSEを導入するにあたって、IDaaSの導入を待つことなく迅速にNetworking SSEを導入するための手段としての利用が可能です。

図2.png
図2.1:Axis IdP

Axis IdPへのユーザー登録は手動での登録か、CSV形式での一括登録かのどちらかとなります。

メーカードキュメントを見る限り、Axis IDPはあくまで一時的な利用を想定しており、恒久的にはIDaaSを導入してのSCIM/SAML連携が推奨されます。

About Axis Security Identity Provider

これはNetworking SSEに限った話ではなく、SASEの導入時にIDaaSは不可欠といっても過言ではないので、SASE導入時にはIDaaSも併せて検討いただくのが良いかと思います。

当方の検証環境においてはMicrosoft Entra IDを利用して検証を行いました。

図3.png
図2.2:IdP登録

図3の通りIdPの登録ではMicrosoft Entra ID、Okta、PingFederate、JumpCloudに関しては登録方法がメニュー化されており、その他のSAML対応のIdPであれば連携が可能となっています。

図4.png
図2.3:Microsoft Entra ID Atmosアプリケーション

Microsoft Entra IDの場合、ギャラリーに登録済みの「Atmos」アプリケーションが利用可能です。

図5.png
図2.4:Networking SSEでのMicrosoft Entra ID登録設定

Primary DomainやApplication IDをコピー&ペーストで設定していく必要がありますが、このあたりはマニュアルを参照しながら設定すれば迷うことなく設定が可能かと思います。

Azure (Entra) IdP Integration

次にSCIMを有効にする必要があります。

図7.png
図2.5:Networking SSEでのMicrosoft Entra ID SCIM設定

SCIM設定方法は以下のドキュメントとなります。

SCIM Provisioning with Azure AD

SCIMによってユーザーのプロビジョニングが完了すると「Provisioned Users」として、Networking SSEの管理者ポータルから確認が可能になります。
またIdentity Providerとして「Microsoft Entra ID」からプロビジョニングされたものであることが確認できます。

図8.png
図2.6:Provisioned Users

以上でユーザーのプロビジョニングが完了し、Networking SSEがユーザーの識別が可能となりました。

3.社内リソースの接続

次にSSEのZTNA機能にて、リモートユーザーが社内のアプリケーションへ接続するために社内アプリケーションをNetworking SSEクラウドへ接続する必要があります。
Networking SSEではZTNAの社内リソースの接続方法としては一般的な「Connector」を構築してConnector経由で社内アプリケーションをクラウドへ接続します。

一般的なZTNAの構成等については当サイトでも過去に紹介していますので、そちらも参照ください。

ZTNAとは

Networking SSEのZTNAは上記ブログの「サービス開始型のZTNA」に該当します。

Connectorは提供されたOVAファイルから仮想環境上に構築したり、Linux上で動作させることも可能です。

詳細は下記を参照ください。

Server Requirements for the Connector

Connector構築時にはConnector Zoneを作成し、Zone内に複数のConnectorを構築して冗長化することが推奨となっています。
Active-Activeの冗長化となり、セッションはZone内のConnectorへ分散されます。
後ほど出てきますが、アプリケーション作成時にConnectorを指定することでどのConnector配下のアプリケーションかを定義しますが、その際にZoneを指定することでConnectorの冗長化を実現しています。

またConnectorはアウトバウンド方向でNetworking SSEのクラウドへ接続しますので、拠点内のFW等でインバウンド方向での穴あけ作業は不要となります。

図8.png
図3.1:ConnectorとConnector Zone

今回はあまり説明するつもりはないのですが、Connectorには2種類あり、上記で紹介したアプリケーション接続用のConnectorと、図8の下側にありますがsyslog転送用のConnectorがあります。

双方で機能を代替できないため、syslog転送が必要な際には別途Connectorの構築が必要となります。

以上が簡単ですがConnectorについての説明となります。

実際のインストール方法等はメーカードキュメントを参照ください。

Adding and Deploying Connectors

4.IPsecトンネルの構築

Networking SSEではインターネットアクセス保護の利用に関しては、拠点からのIPsecトンネル構成にも対応しています。
拠点のSD-WANルータや通常のルータ/ファイアウォール等からNetworking SSEのPoPに対してIPsecトンネルを設定することで、拠点からのインターネットトラフィックをSWGやCASBといった機能で保護することが可能です。

注意点としてIPsecトンネル構成では通信制御は後述するLocation(拠点)単位での設定となります。
IPsecトンネル構成では現状ユーザー認証の仕組みが無いため、ユーザー単位での制御は不可となっています。

またIPsec構成ではDNSトラフィックが制御対象外のため、URLフィルタ等での宛先の確認はSNI(Server Name Indication)を利用します。

今回はEdgeConnect SD-WANとの接続を行いましたが、冒頭でお話しした通り接続設定は手動で行う必要がありました。

主な手順としては以下です。

4-1.EdgeConnect SD-WANでのService Orchestration追加

EdgeConnect SD-WAN側でService OrchestrationにNetworking SSEの追加を行いますが、今回はこちらの設定は本筋から外れてしまうので簡単なご紹介のみです。

実際の設定時はメーカー側で詳細な手順書が用意されていますので、そちらを参照ください。

HPE Aruba Networking EdgeConnect and HPE Aruba Networking SSE Secure Web Gateway

図4-1.png
図4.1:EdgeConnect SD-WAN Service Orchestration設定

IPsecトンネルはPrimaryとSecondaryの2本を設定することが推奨となっています。
図4.1では2台のEdgeConnectからPrimaryとSecondaryトンネルをそれぞれ設定しています。

4-2.Networking SSE側でのLocations/Tunnel設定

図4-1.png
図4.2:Locations作成

最初にLocation Nameを設定し、sub locationを設定します。

図4-2.png
図4.3:Sub Location設定

Sub Locationでは名前と各Sub Location配下に存在するプライベートIPアドレスのレンジを設定します。

次にトンネル設定を行います。

図4.4.png
図4.4:トンネル作成

Tunnel IDはEdgeConnect SD-WAN側で払い出されたものを設定し、PSKも同様にEdgeConnect SD-WAN側に設定した値を入力します。

図4.5.png
図4.5:トンネルステータス

トンネル設定が完了するとStatusが「Connected」となります。

4-3.EdgeConnect SD-WANでのOverlay設定

図4.6.png
図4.6:Overlay設定

最後にEdgeConnect SD-WAN側のOverlay設定でトラフィックをNetworking SSEに向ける設定を行います。

今回は概要/準備編のためここまでとさせていただきます。

次回はZTNAのお話の予定です。

著者紹介

SB C&S株式会社
技術本部 技術統括部 第2技術部 1課
藤ノ木 俊