統一されたSASEの役割 サイバー脅威ハンティング

なぜSASEでプロキシなのですか？

パケットレベルのセキュリティで十分だと思われていた時代は終わりました。 攻撃の巧妙化により、さまざまな種類の防御のために深いコンテンツ検査を行うことが不可欠になっています。 分散した従業員と分散したアプリケーションのために、アイデンティティを意識したアクセスは重要な要件です。 このブログ記事では 、IDを意識したアクセスに関連する要件について詳しく説明します。 API/アプリケーション・リソース・レベルでのディープ・コンテンツ検査とID認識アクセスには、クライアント接続の終了、脅威検出とアクセス制御のためのコンテンツ検査、プロキシを介した接続のオリジネーションが必要です。 したがって、多くのSASEソリューションは、プロキシを通してセキュリティを実装しています。

プロキシの種類

フォワード、リバース、トランスペアレントなど、さまざまなタイプのプロキシについて聞いたことがあるかもしれません。 どのタイプのプロキシも主な機能は同じです。 高レベルの機能はここに記載されています。

  • トラフィックの把握
  • クライアント接続を終了します。
  • クライアントを認証します。
  • ユーザーIDを取得します。
  • サーバーへの接続を開始します。
  • TLSの復号化と暗号化
  • IPとドメインのレピュテーションをチェックします。
  • IDベースのアクセス制御の実行
  • CASB機能の実行
  • データの損失をチェックし、損失を防止します。
  • 侵入検知/防止機能の実行。
  • ウェブアプリケーションファイアウォール機能の実行
  • トラフィックの中からマルウェアやエクスプロイトの指標を探し、行動します。

それぞれの違いは、以下の要素に基づいています：

  • 脅威検査とアクセス制御のためのトラフィックの取得
  • ユーザーの認証と識別

透過プロキシ型

このタイプでは、クライアントもサーバーもプロキシの存在を知りません。 これらのプロキシは、トラフィックが通過するネットワーク・ルーターからトラフィックをキャプチャします。 オフィスユーザーからのトラフィックとWFHユーザーからのトラフィックが、企業のルーティングエンティティを経由するようにすることは、ネットワーク管理者の責任です。 WFH ユーザーからのトラフィックが企業ルーターを経由するようにするには、VPN クライアントを活用して企業ネットワークに接続するのが一般的です。 SD-WANの場合、VPNトンネルは最も近いPoPロケーションのVPNコンセントレータで終端します。 ユーザー認証と対応するユーザー識別は

  • 明示的ポータル
  • オンデマンド・ポータル
  • VPNトンネルの確立
  • TLSクライアント証明書

明示的ポータル」の場合、ユーザーは積極的にポータルにログインします。 ポータルサービスは、企業認証システムの助けを借りてユーザーを認証します。 ユーザー認証情報の検証に成功すると、ユーザーのIPアドレス（接続元IPから）を記録し、ユーザーIDとIPアドレスのマッピング情報をプロキシに通知します。 プロキシがこれらのマッピングを知ると、プロキシはトラフィックのIPアドレスからユーザーを識別し、IDを意識したポリシー施行を実行します。 ユーザーがポータルで積極的に認証することなくセッションを開始した場合、プロキシはユーザーをポータルにリダイレクトすることができます。 ポータルアクセスはオンデマンドであるため、この認証方法はオンデマンドポータル認証とも呼ばれます。 注意点として、ポータルへのユーザーのリダイレクトは、HTTP/HTTPSベースの接続の場合にのみ可能です。 HTTPSの場合、リダイレクトはTLS復号化後にのみ可能です。 企業以外のサービスやサイトにアクセスする場合は、企業所有のCA証明書でサーバ証明書を模倣する必要があります。 さらに、ユーザーがブラウザを使う人間でない場合、リダイレクトは役に立ちません。 この注意点を考慮しても、プロキシがユーザーを認証し、識別するための強力な方法であることに変わりはありません。 簡単に説明したように、企業ネットワークの一部になるためには、WFH（在宅勤務）ユーザーはVPNトンネル経由で企業ネットワークに接続する必要があります。 VPNトンネルの確立では、すでにユーザー認証が行われています。 VPNコンセントレータは、各クライアントに固有のプライベートIPアドレスを割り当てます。 クライアントは、VPNトンネルを使用するように設定することができ、したがって、接続の大部分（スプリットトンネリング無効を含む）のソースとしてこのIPアドレスを使用します。 VPNコンセントレータは、クライアントに割り当てられたIPアドレスとユーザID（イニシエータID）のマッピングを外部にアドバタイズする機能を持っています。 プロキシは、後でクライアントがセッションを開始するときに、このマッピングを使用してユーザーへのセッションを識別します。 TLSセッションを確立したクライアントプログラムがTLSクライアント証明書を持っている場合、その証明書を使用してユーザーを認証し、識別することができます。 これはSASEではほとんど使われませんが、利用可能なオプションの一つです。 透過型プロキシタイプの大きな利点の1つは、HTTP/HTTPSだけでなく、すべてのプロトコルのトラフィックをキャプチャできることです。 もう一つの大きな利点は、企業のクライアントマシンやサーバーマシンで特別な設定をする必要がないことです。 このタイプのプロキシには欠点がほとんどありません。 トラフィックで観測された IP アドレスに基づいてユーザを識別するため、そのユーザマシン内のすべてのアプリケーショ ンは同じセキュリティ処理を受けます。 マルチユーザーマシンの場合、そのマシンのすべてのユーザーが同じセキュリティ処理/特権を得ます。 このIPアドレスが複数のマシンをNATしている場合、そのNAT IPアドレスの背後にあるすべてのマシンが同じアクセスとセキュリティ処理を受けます。 ユーザーのノートパソコンがマルウェアに感染した場合を考えてみましょう。 マルウェアは、ユーザーがポータルにログインするのと同じマシンの一部であるため、そのユーザーに対して定義されたのと同じアクセスを取得します。 このため、少なくとも HTTP/HTTPS セッションでは、透過的なプロキシタイプは注意して使うべきです。 もう一つの欠点は、このタイプのプロキシは、デバイスにVPNクライアントが存在する必要があることです。 管理されたデバイスの場合は問題ありませんが、従業員が所有するデバイスにVPNクライアントをインストールするよう従業員を説得するのは大変なことです。

フォワードプロキシタイプ

フォワードプロキシは、外部サービス/サイトと通信するクライアントデバイス向けのものです。 クライアントアプリケーションは、外部サービスと通信するためにフォワードプロキシを経由するように設定されています。 クライアントアプリケーションは、プロキシがリッスンしているFQDN/IPとポートで構成されます。 トランスペアレントプロキシの場合、セッションのソースIPアドレスとデスティ ネーションIPアドレスがプロキシIPアドレスを持つことはありません。 フォワードプロキシの場合、クライアントからの接続はプロキシIPアドレスになり、サーバへの接続はプロキシIPアドレスからになります。 PACファイルは、ブラウザなどのクライアント・アプリケーションのプロキシ設定に使用されます。 PACファイルは、宛先サービスドメインに基づいて、さまざまなプロキシへのトラフィックのルーティングを選択できるようにします。 PACファイルは、システム管理ソリューションまたはWPAD（Web Proxy Auto Discovery）サービスを介してクライアントブラウザに配布されます。 プロキシ設定のクライアントアプリケーションは常にプロキシと通信します。 これが、フォワードプロキシがトラフィックを捕捉する方法です。 HTTPSなどのTLS接続の場合、すべてのTCP接続は “HTTP CONNECT “トランザクションで始まります。 このトランザクションはクライアントとプロキシの間でのみ行われます。 HTTP CONNECTトランザクションの後、クライアントとサーバー間のデータはプロキシによって仲介されます。 “HTTP CONNECT “トランザクションは、プロキシが最終的なデスティネーションのFQDNとポートを決定するために使用するホストヘッダーフィールドを持ちます。 HTTP2.0の場合、すべてのストリーム接続は “HTTP CONNECT “トランザクションで始まります。 お気づきのように、プロキシがトラフィックをキャプチャするために Enterprise ルータにトラフィックを送信する必要はありません。 つまり、トラフィックは直接プロキシに送られます。 そうすることで、ネットワークに依存しません。 フォワードプロキシはまた、proxy-authenticateヘッダとproxy-authorizationヘッダによってユーザーを認証し、識別することができます。 TLS接続の場合、これらのヘッダーはHTTP CONNECTトランザクションのレスポンスとリクエストでそれぞれ送信されます。 注意すべき点は、ユーザーを認証・識別する目的でTLS接続を復号化する必要はないということです。 ポータル認証は必要ありません。 もう一つの利点は、多くのブラウザやクライアント・アプリケーションがプロキシ認証の一部としてKerberosをサポートしていることです。 これにより、自分のデバイスにログインするすべてのユーザーは、ログインポップアップを追加することなく、プロキシで自動的に自分自身を認証することができます（SSOとしても知られています）。 外部サービスと通信するクライアントにフォワードプロキシ型を使うことには、いくつかの利点があります。 その一部を以下にご紹介します。

  • ユーザーの認証と識別は決定論的です。 トランスペアレントプロキシタイプの場合、ユーザーがポータルへの積極的な認証を忘れた場合、ユーザー認証のためのオンデマンドポータルまたはキャプティブポータルのリダイレクトは、TLS復号化後にのみ可能です。 PIIを収集するサイトへのTLS復号化を許可しない企業もあります。 サイトが証明書のピン留めを採用する場合、透過的なプロキシは証明書を模倣することは期待できず、したがってTLSの復号化は不可能です。 このような場合、アイデンティティを意識したポリシー実行を提供するためにユーザーを決定することはできません。 フォワードプロキシ型では、TLS交換の前にプロキシ認証フェーズが発生するため、ユーザー認証と識別は決定論的です。
  • 前述したように、フォワードプロキシはネットワークに依存しないので、クライアントアプリケーションがプロキシ設定で構成されている限り、どのようなネットワークでも動作します。 ユーザーが自宅で仕事をしている場合でも、デバイスにVPNクライアントがある必要はありません。
  • 多くのクライアントアプリケーションがKerberosをサポートしているため、ユーザーはSSOを体験できます。
  • TLS 1.3+のEncrypted Client Hello (ECH)が業界で注目を集めています。 ECHが採用されるとSNIが見えなくなるため、透過型プロキシでは基本的なURLフィルタリングやアクセス制御すらできなくなります。 フォワードプロキシ型では、HTTP CONNECTトランザクションのため、ECHを採用してもプロキシは宛先FQDNを知っています。 つまり、フォワードプロキシ型はECHセーフ。
  • IPホワイトリストはありません。 すべてのクライアントアプリケーションはプロキシと個別に認証する必要があり、したがって非常に安全です。

欠点もいくつかあります。 HTTP/HTTPSトラフィックに対してのみ機能します。 大半のクライアントアプリケーションはプロキシ設定をサポートしていますが、中にはサポートしていないものもあります。

リバースプロキシ型

リバースプロキシはサーバーアプリケーションのフロントエンドに使用されます。 リバースプロキシは、サービスを脅威から保護するため、RBACを提供するため、TLSセッションを終了するため、また複数のサービスのインスタンス間でトラフィックセッションを負荷分散するために使用されます。 リバースプロキシは、DNS方式でトラフィックをキャプチャします。 従業員や一般ユーザーに公開される各企業サービスのFQDNは、リバースプロキシインスタンスのIPアドレスを指すように企業のDNSサーバーに設定されます。 このため、ユーザーが企業サービスに接続しようとするたびに、対応するトラフィックがリバースプロキシに着地します。 リバースプロキシはHTTPS/HTTPセッションも終了させます。 このプロセスの一環として、ユーザーを認証し、OIDC、SAMLv2、SPENGO/Kerberos メソッドによってセッションのユーザーを識別します。 アプリ間通信の場合は、TLS証明書からもユーザーを識別します。

SASEプロキシ

SASEについての入門書は、ブログ記事「Deciphering SASE」をお読みください。 お気づきのように、SASEソリューションは、クライアントの保護、SaaSデータの保護、エンタープライズアプリケーションの保護といった包括的なセキュリティを提供することが期待されています。 Identity-aware-SASEのブログポストで説明したように、IDベースのアクセス制御は、SASEの重要な機能です。 多くの企業は HTTP/HTTPS アクセスだけで十分ですが、他のプロトコルのアクセス制御も必要な場合があります。 このようなニーズから、SASEプロキシは、非HTTPトラフィックやプロキシ設定をサポートしないクライアントアプリケーションに対して透過的に動作するものと考えています。 SASE プロキシは、インターネットや SaaS サービスにアクセスするクライアント・アプリケーションのフォワード・プロキシとして機能し、決定論的な ID ベースのアクセス制御を提供し、また ECH が採用された場合の将来的な証明となります。 SASEプロキシは、エンタープライズアプリケーションを保護するためのリバースプロキシとしても機能します。 SASEを成功させるには、このように複数のプロキシを収束させる必要があります。

  • CTOインサイトブログ

    Aryaka CTO Insightsブログシリーズは、ネットワーク、セキュリティ、およびSASEのトピックに関するソートリーダーシップを提供します。
    Aryaka製品の仕様については、Aryakaデータシートを参照してください。