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.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.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を利用して検証を行いました。

図2.2：IdP登録

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

図2.3：Microsoft Entra ID Atmosアプリケーション

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

図2.4：Networking SSEでのMicrosoft Entra ID登録設定

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

Azure (Entra) IdP Integration

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

図2.5：Networking SSEでのMicrosoft Entra ID SCIM設定

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

SCIM Provisioning with Azure AD

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

図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等でインバウンド方向での穴あけ作業は不要となります。

図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との接続を行いましたが、冒頭でお話しした通り接続設定は手動で行う必要がありました。

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