今回のテーマはパケットのゼロトラスト検証であるSPA/Single Packet Authorizationです。

Appgate SDPの独自かつ強力な機能なのでしっかり見ていきましょう。

Appgate SDP 6 Layer Trust Model

---

Appgate SDPの象徴的な機能概要で、全てのアクセスデバイスが、ファイアウォールの外側に存在しているという前提で、プライベートなアプリケーションへリモートアクセスする際のイメージ図です。

Appgate SDPが提供するゼロトラストアプローチは、6階層のセキュリティチェックによってパケット、デバイス、ユーザー、コンテキストが常に検証されている状態を保証することです。

1. シングルパケット認証（パケットの検証）
2. 登録されたデバイス（オンボーディング）
3. 正しいアイデンティティ（ユーザー認証）
4. コンテキストの定義とアクセス権限
5. 要求に応じて信頼の昇格
6. 振る舞いの監視

これらの6階層はユーザーから目的のアプリケーションに至る過程において、1つの例外もなくゼロトラストネットワークアクセスとして検証、証明される機能です。

今回のブログでは、この6 Layer Trust Modelの図をイメージしながら確認すると、とても良くわかると思います。

SPA (Single Packet Authorization)とは

---

Appgate SDPが提供するパケットレベルでのゼロトラスト検証技術です。

上記の図の1で記載される、外枠で活用される技術であり、インターネットを通してアクセスされるサービスを適切に保護するためのソリューションとなります。

このSPAによって、Appgate SDPのサービスを外部に公開しても、アタックサーフェスを最小化することと、正しいユーザー/デバイスだけにSDPのシステムを提供することができます。

SPAの利用目的としては、Appgate SDPが提供するサービスに対しての、Exploit攻撃から守るための仕組みで、DDoS(Distribute-Denial-of-Service)、MitM（Man-in-the-Midle)、CSRF（Cross-Site-Request-Forgy)、XSS（Cross-Site-Scripting)、SQLi(SQL-Injection)などからの脅威から安全にサービスを保つことにあります。

レガシーVPNの多くの製品では、パブリックにVPNサービスを公開するのにあたって、VPN装置自体のExploitに対する安全性の担保がファームウェアでの対応のみとなりますが、Appgate SDPはこのSPAによって強力かつ効率に保護されます。

SPAの超概略

SPAの細かいパケットレベルでの挙動は、ぜひWiresharkなどでも見ていただきたいのですが、ざっくりと図で記載すると以下のようになります。

一般的なSSL-VPN装置を例にすると、パブリック（インターネット上）にHTTPS(TCP443）のサービスを公開する必要があります。

つまり、正規のユーザーに関わらず、インターネットを通して、あらゆるユーザーがIPアドレスまたはURLさえ入手できれば、パブリックに公開されているリモートアクセス用のサービスに到達できます。

VPNの認証はTCPのコネクションが確立した上で表示されるため、DDoS攻撃の対象やVPN装置自体に何らかの脆弱性がある場合は、TCPを使った攻撃の対象になりえます。

一方Appgate SDPのSPAは、レガシーVPNと同様にパブリックにHTTPS（TCP443）のサービスを公開しますが、この通信に対してSPA機能を有効化することができます。

SPAが有効化されると、Appgate SDPの各種サービスは、TCPの接続の前に、SPAパケットを受信して、その中身が正当なパケットであるかを検証しています。

上記図でいうと、Special TCP Synという表現をしていますが、1つのパケットの中に認証情報が埋め込まれていて、このパケットを受信することで正規のユーザーかそれ以外かを検証することになります。

逆に、Special TCP Synを生成できない端末、つまり、IPアドレスやURLなどから通常のTCP通信を受信した場合は、Appgate SDPはそのTCP通信に応答することはありません。

これによって、部外者からの完全なサービスの隠蔽（All-Denyの実現）を行いながら、サービスを必要とする正規のユーザーにのみインターネットを通して安全にVPNのサービスを提供することができます。

このSPAは、他社ゼロトラストでは実現が難しいとされる、パケットレベルでの検証を行うことで、VPNの認証に至る前の接続認証を行うことで、外部からのDDoSや各種Exploitに関連する攻撃から守られることになります。

SPAの設定方法

SPAの設定はとても簡単です。

Settings > Client Connectionsから新しいプロファイルを作成します。

• Profile Name --- ユーザーに提供する接続設定の名称
• Key name --- このキーを元にSPAに必要なパケットを生成します
• IDP --- このプロファイルを使うユーザーのユーザー認証先

なお、Profile DNS Nameは、可能であればFQDNを指定してください。

この状態でSaveをします。

すると、プロファイルの右側に、"Copy link to clipboard"やQRコードの選択が可能です。

ここで生成された、リンクを"プロファイルリンク"と呼び、ユーザーにこのリンクを提供することで、ユーザーはAppgate SDPに正しく接続することができます。

生成されたプロファイルリンクの中身

このプロファイルリンクの実態は、appgate://から始まるAppgate SDPへ接続するためのリンクです。このリンクをユーザーにわたすことで簡単にAppgate SDPへ安全に接続を促すことができます。

SPAはTCPとUDPにも実装可能

Appgate SDPは、TLS（TCP）の通信だけではなく、DTLS（UDP）の通信もサポートしています。

SPAはTCPだけでなく、UDPの通信にも適用可能です。

Settings > Global Settingの中からSPAの利用をCheck UDPにすることで、DTLS環境でもSPAによって保護することが可能です。

証明書の書換え

Appgate SDPの通信の多くが証明書を使っています。

Appgate SDPのホスト名やDNS名を変更した場合は、証明書の更新が必要になりますので、状況に応じて実施してください。

再度プロファイルリンクをクリップボードにコピーして次の作業に進みましょう。

Appgate SDP クライアント

---

Appgate SDPクライアントは各種デバイス（Windows、macOS、iOS、Android、Chromebook、Linux）にインストールする、Appgate SDPへの接続エージェントです。

こちらからAppgate SDPの各種エージェントを無償で入手できます。

Windows/macOSともにFull Clientを利用してください。

Windows11にも対応していますし、M1 MacについてはQualifiedサポートとなっていますが、私の手持ちのM1デバイスだと問題なく接続できています。

モバイルデバイス（iOSやAndroid）はAppStoreやPlayストアから検索してインストールします。

Appgate SDPクライアントのインストール

インストーラーをダウンロードして実行するだけです。

VPNのクライアントエージェントなので、他ソリューションと同じようにインストール時は管理者権限が必要です。

ライセンスに同意してエージェントのインストールを完了します。

インストールが終わると、自動的にアプリケーションが立ち上がります。

Approveをクリックして進みます。

プロフィール作成として"プロファイルリンクを使用"をクリック

クリップボードにコピーしたプロファイルリンクを貼り付けます。

このプロファイルリンクはメールやチャットなどを利用して、ユーザーに展開してください。

プロファイルリンクを送信するとこんな感じでプロファイルが作成されます。

つまり、先程のプロファイルリンクの送信によって、SPAが確認され、Appgate SDPから応答があったことがわかります。

Appgate SDPへ接続するとアイデンティティの確認が行われます。ユーザー認証の前にパケットによる検査が行われている状況です。

無事ユーザー認証、ポリシーの認証が通ればこんな感じになります。

ユーザー認証が正しくても、ポリシー違反があった場合はこんな感じになります。

この画面が出た時は、ポリシー設定（Windowsファイアウォールが有効になっているかなど）に接続デバイスが準拠しているか確認してください。

無事接続完了です。

SDPという1つのサイトに接続されています。同時に複数のサイトに接続することも可能です。

Appgate SDPのクライアントの接続状況は左上のボタンから"About"をクリックします。

自身のバージョンや接続先のコントローラー、仮想IPなどが確認できます。

エンタイトルメントの状況も確認できます。

もちろんPINGでも通信の確認が可能です。（IPアドレスでVPC内のWebサーバーに疎通確認）

WindowsではAppgate SDPというインターフェースが作成されていて、仮想IPが提供されています。

Appgate SDPの場合、コントローラーで認証すると、ゲートウェイ宛のダイレクト通信となるため、クラウドを経由せずに直接デバイスとゲートウェイの通信ができます。

Appgate SDPから見たユーザーとデバイスの管理

---

Appgate SDPクライアントが無事に接続できたことを確認するためには、Appgate SDPコントローラーから状態を確認する必要があります。

ダッシュボード

Appgate SDPに接続しているアクティブなセッション情報を確認できます。

• ユーザー名
• Identity Providor
• ホスト名
• Device ID

が必ず表示されます。つまり、同一ユーザーアカウントでログインしても、誰がどのデバイスでログインしているかすぐわかります。

コンテキストを確認する

そのセッションをクリックしてドリルダウンするとユーザーに適用されているEntitlementが表示されます。

下にスクロールしてみると3つのClaimsが表示されます。

これが、Appgate SDPが監視している、コンテキスト情報です。

• System Claims --- 接続元のシステム情報でグローバルIPやGeoLocationなど
• User Claims --- ユーザー情報に関連する情報
• Device Claims --- デバイスの固有の情報

を収集し、これらがポリシーのAssignmentの条件として設定することができます。

デバイス情報はとても細かく収集することができます。

• Clientに割り当てている実IP
• Appgate SDPクライアントのバージョン
• ドメインに参加の有無
• マルチユーザー環境（デバイスを複数で使い回す）
• 管理者権限の有無
• MACアドレスの情報
• OSの詳細情報
• SPAキーの情報
• など

SDPを構成する上で、組織が提供した端末を特定するためのとても詳細な情報を収集し、そこから共通のルールを作成することが可能です。

ここに表示される項目はすべてAssignmentの接続条件として定義することができるので、従来のVPN装置よりも多くの情報を使って、接続デバイスを定義できます。

シリーズ4まとめ

---

シリーズ4回では、Appgate SDPの環境構築からAppgate SDPクライアントの接続まで一通り詳細にまとめてみました。

ここまでのシリーズを読破したなら、無事Appgate SDPの機能を体験できる状態になっています。

今回のシリーズでは、SPA（Single Packet Authorization)からクライアントデバイスが接続されるまでのプロセスを確認しましたが、SPAといっても設定が難しいわけでもなく、とてもシンプルな方法で、確実にアタックサーフェスを保護しながら、クライアントの展開もプロファイルリンクを展開するだけなのでとても簡単です。

私の場合、Appgate SDPを使い始めてから、VPNをつなぐという行為自体をほとんど意識しなくなりました。

これは、Appgate SDPへ常時接続しているだけで、私の環境が常にソフトウェアで定義されている状態になるからです。

私のしごと環境は、会社のラボ、執務室、自宅や出張先などそれぞれのネットワークにつなぐことで、インターネットを通して仕事をしますが、Appgate SDPはその状況を常に把握し、私の環境に応じた最適なネットワークによるアクセス権限を提供し続けます。

つまり私はパソコンを立ち上げてるだけで、ゼロトラストによるパケット、ユーザー、デバイスそしてアクセス権限の検証が行われ続けるということです。

ネットワークに対して1つのゲートウェイだけを用意するので、それ以外の接続方法を迷うことなく、簡単・便利でかつ安全に使うということがAppgate SDPの特徴ということです。

では次回はAppgate SDPじゃないとできない、コンディションアクセスについてまとめていきます！

SPAの余談

---

SSL-VPN装置が対外的にどのように見えるかという点ですが、例えばcURLコマンドを使えば簡単にわかります。

某SSL-VPN装置（デフォルト）のSSL-VPNサービスにアクセス

リモートアクセス用のサービスなので、インターネット上のだれでも行うことができます。 例えばcURLを使えば以下のようなものが伺えます。

デフォルトの設定で動作しているSSL-VPNサービスには、デフォルトの証明書が使われていて、シリアルNOから製品の型番まで見える場合があります。

最新のファームウェア、パッチが適用していれば問題ないですが、これがもし古いのファームウェアで稼働していると大変危険な状態に晒されているかもしれません。

Appgate SDPによるAll-Denyとは

Pingコマンドで存在を確認します

Appgate SDP側で明示的にICMPの応答を許可するように設定し、インターネット上での存在を確認しました。

SPAの設定の確認

Check TCP SPA keyの場合

画面右側の注意書き通り、"however only connection attempts that include the special TLS ClientHelo paket..."とあり、ポート自体は空いているが特殊なTLSパケットだけがコネクションが張れると書いています。

Check TCP SPA keyの状態のcURL確認

サービスの存在は確認できますが、エラーのためコネクションが張れない状態です。

Check UDP SPA Keyの場合

画面右側の注意書きには"TCP port 443 closed..""と書かれていて、特殊なUDPパケットだけが許容される仕組みになりました。

Check TCP SPA keyの状態のcURL確認

以下のように完璧にTCPのオープンポートを塞ぐことができました。

このようにAppgate SDPはファイアウォールやIPSを使わなくても、Appgate SDPの仕組みだけで、インターネットにサービス公開されるサービスを1つのパケットをチェックすることでコントロールできます。

今後、企業としてもテレワークやリモートワークを用意することは当然の設備となっていくと思います。導入したまま放置されたVPNサービスは標的にされやすく、かといってどこからいつアクセスしてくるかわからないリモートサービスをIPアドレス制限などで拒否するのは現実的ではありません。

SPAはとても単純な仕組みですが、この単純さが動作の快適性を提供し、それが信頼となって安心・安全のネットワーク環境を支えていきます。

セキュリティは不便とのトレードオフではなく、快適性のアドオンになればユーザーの満足度も上がるのではないでしょうか。SPAの余談でした。