さまざまな種類のプロキシの統合 SASE

プロキシを使用する理由 SASE?

パケット レベルのセキュリティが十分であると考えられていた時代は終わりました。 攻撃が巧妙化しているため、さまざまな種類の保護のために詳細なコンテンツ検査を行うことが不可欠になってきています。 従業員とアプリケーションが分散しているため、ID を意識したアクセスは重要な要件です。 これ ブログ投稿 ID を認識したアクセスに関連する要件を詳細に掘り下げます。 API/アプリケーション リソース レベルでの詳細なコンテンツ インスペクションと ID 認識アクセスには、クライアント接続の終了、脅威検出とアクセス制御のためのコンテンツ インスペクション、およびプロキシを介した接続の開始が必要です。 したがって、多くの SASE 溶液 プロキシを介してセキュリティを実装します。

プロキシタイプ

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

• 交通状況を把握する
• クライアント接続を終了します。
• クライアントを認証します。
• ユーザー ID を取得します。
• サーバーへの接続を開始します。
• TLS の復号化と暗号化
• IP とドメインの評判を確認します。
• ID ベースのアクセス制御を実行します。
• 実行する CASB 機能します。
• データの損失を確認し、損失を防ぎます。
• 侵入検知・防御機能を実行します。
• Webアプリケーションファイアウォール機能を実行します。
• トラフィック内でマルウェアとエクスプロイトの兆候を探して行動します。

それらが互いにどのように異なるかは、次の要因に基づいています。

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

透過的プロキシのタイプ

このタイプでは、クライアントとサーバーはプロキシの存在を認識しません。 これらのプロキシは、トラフィックが通過するネットワーク ルーターからトラフィックをキャプチャします。 ネットワーク管理者の責任は、オフィス ユーザーからのトラフィックと在宅勤務ユーザーからのトラフィックが ent 経由で確実に送信されるようにすることです。erpルーティングエンティティを上昇させます。 WFH ユーザーからのトラフィックが Ent を通過するようにするにはerpライズルーターを活用するのが通常の方法です VPN Ent に接続するクライアントerpネットワークを立ち上げます。 の場合 SD-WAN, VPN トンネルは次で終了します VPN 最寄りの PoP ロケーションにあるコンセントレータ。

ユーザー認証とそれに対応するユーザー識別は、次の方法で行われます。

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

「明示的ポータル」の場合、ユーザーは積極的にポータルにログインします。 ポータル サービスは ent を使用してユーザーを認証しますerp認証システムの台頭。 ユーザー資格情報の検証が成功すると、ユーザーの IP アドレス (接続のソース IP から) が記録され、ユーザー ID と IP アドレスのマッピング情報がプロキシに通知されます。 プロキシがこれらのマッピングを認識すると、プロキシはトラフィックの IP アドレスからユーザーを識別し、アイデンティティを認識したポリシーの適用を実行します。

ユーザーがポータルでプロアクティブに認証せずにセッションを開始した場合、プロキシはユーザーをポータルにリダイレクトできます。 ポータル アクセスはオンデマンドであるため、この認証方法はオンデマンド ポータル認証とも呼ばれます。 注意すべき点の XNUMX つは、ポータルへのユーザーのリダイレクトは、接続が HTTP/HTTPS ベースの場合にのみ可能であるということです。 HTTPS の場合、リダイレクトは TLS 復号化後にのみ可能です。 ent以外へのアクセスの場合erpサービス/サイトを上昇させるには、ent を使用してサーバー証明書を模倣する必要がありますerp所有する CA 証明書が上昇します。 さらに、ユーザーがブラウザを使用している人間のユーザーではない場合、リダイレクトは役に立ちません。 このような注意点があっても、プロキシがユーザーを認証および識別するための強力な方法であることに変わりはありません。

簡単に説明したように、ent の一部になるにはerpWFH (Work From Home) ユーザーはネットワークに接続する必要があります。erp経由でネットワークを立ち上げる VPN トンネル。 VPN トンネル確立ではすでにユーザー認証が行われています。 VPN コンセントレータは、各クライアントに一意のプライベート IP アドレスを割り当てます。 クライアントは次を使用するように構成できます。 VPN トンネルのため、この IP アドレスが大部分の接続 (無効なスプリット トンネリングを含む) のソースとして使用されます。 VPN コンセントレーターは、クライアントに割り当てられた IP アドレス、ユーザー ID (イニシエーター ID) マッピングを外部関係者にアドバタイズする機能を備えています。 プロキシは、後でクライアントがセッションを開始したときに、このマッピングを使用してユーザーに対してセッションを識別します。

TLS セッションが確立されたクライアント プログラムに TLS クライアント証明書がある場合、それを使用してユーザーを認証および識別できます。 これは今日では非常にまれに使用されます SASE, しかし、それは利用可能なオプションの XNUMX つです。

透過プロキシ タイプの主な利点の XNUMX つは、HTTP/HTTPS だけでなく、すべてのプロトコル トラフィックをキャプチャできることです。 もう XNUMX つの大きな利点は、入口で特別な設定が必要ないことです。erpクライアント マシンまたはサーバー マシンを上昇させます。

このタイプのプロキシには欠点がほとんどありません。 トラフィック内で観察される IP アドレスに基づいてユーザーを識別するため、そのユーザー マシン内のすべてのアプリケーションは同じセキュリティ処理を受けます。 マルチユーザー マシンの場合、そのマシンのすべてのユーザーが同じセキュリティ処理/特権を取得します。 この IP アドレスが複数のマシンを NAT 接続している場合、その NAT IP アドレスの背後にあるすべてのマシンが同じアクセスとセキュリティ処理を受けます。 ユーザーのラップトップがマルウェアに感染した場合を考えてみましょう。 マルウェアは、ユーザーがポータルにログインするのと同じマシンの一部であるため、そのユーザーに定義されているのと同じアクセス権を取得します。 このため、少なくとも HTTP/HTTPS セッションでは、透過的なプロキシ タイプは注意して使用する必要があります。

もう XNUMX つの欠点は、このタイプのプロキシには次のものが必要なことです。 VPN クライアントがデバイス内に存在する必要があります。 管理対象デバイスにとっては問題ではありませんが、従業員にインストールするよう説得するのは難しい場合があります。 VPN 従業員所有のデバイス上のクライアント。

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

フォワード プロキシは、外部サービス/サイトと通信するクライアント デバイスを対象としています。 クライアント アプリケーションは、フォワード プロキシを経由して外部サービスと通信するように構成されています。 クライアント アプリケーションは、プロキシがリッスンするプロキシの FQDN/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」トランザクションから始まります。 お気づきかもしれませんが、トラフィックを Ent に送信する必要はありません。erpプロキシがトラフィックをキャプチャするためにルーターを立ち上げます。 つまり、トラフィックは直接プロキシに送信されます。 このように、ネットワークに依存しません。

フォワード プロキシは、proxy-authenticate ヘッダーと proxy-authorization ヘッダーを介してユーザーを認証し、識別することもできます。 TLS 接続の場合、これらのヘッダーは HTTP CONNECT トランザクションの応答と要求でそれぞれ送信されます。 注意すべき点は、ユーザーの認証と識別を目的として TLS 接続を復号化する必要がないことです。 ポータル認証は必要ありません。 追加の利点が XNUMX つあり、多くのブラウザーとクライアント アプリケーションがプロキシ認証の一部として Kerberos をサポートしていることです。 これにより、自分のデバイスにログインするユーザーは、追加のログイン ポップアップ (SSO とも呼ばれる) を使用せずに、プロキシを使用して自動的に自分自身を認証できるようになります。

外部サービスと通信するクライアントにフォワード プロキシ タイプを使用すると、いくつかの利点があります。 その一部を以下に示します。

• ユーザーの認証と識別は決定的です。 透過プロキシ タイプの場合、ユーザーがポータルへのプロアクティブな認証を忘れた場合、ユーザー認証のためのオンデマンド ポータルまたはキャプティブ ポータルのリダイレクトは、TLS 復号化後にのみ可能になります。 いくつかのエントerpPII を収集するサイトへの 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 メソッド。 各エントのFQDNerp従業員または一般ユーザーに公開されるrise サービスは ent で構成されますerp上昇 DNS サーバーがリバース プロキシ インスタンスの IP アドレスを指すようにします。 このため、ユーザーが ent に接続しようとするたびに、erpサービスが上昇すると、対応するトラフィックがリバース プロキシに到達します。

リバース プロキシは、HTTPS/HTTP セッションも終了します。 このプロセスの一環として、ユーザーを認証し、OIDC、SAMLv2、および SPENGO/Kerberos メソッドを介してセッションのユーザーを識別します。 アプリ間通信の場合、ユーザーは TLS 証明書からも識別されます。

SASE プロキシ

プライマーとして SASEのブログ投稿をお読みください。 解読 SASE。 お察しの通り、 SASE ソリューションは包括的なセキュリティを提供することが期待されています – クライアントの保護、セキュリティの保護 SaaS データとセキュリティ保護erpアプリケーションを上昇させます。 で説明されているように、 アイデンティティを意識する-SASE ブログ投稿では、ID ベースのアクセス制御が主要な機能です SASE。 多くのエントがerpRise は HTTP/HTTPS アクセスのみで動作しますが、他のプロトコルでのアクセス制御も必要とする場合もあります。 こうしたニーズから、私たちは次のように考えています。 SASE プロキシは、非 HTTP トラフィックおよびプロキシ設定をサポートしないクライアント アプリケーションに対して透過的に機能します。 の SASE プロキシは、インターネットにアクセスするクライアント アプリケーションのフォワード プロキシとして機能し、 SaaS 決定論的な ID ベースのアクセス制御を提供し、ECH が採用された場合の将来の保証を提供するサービス。 の SASE プロキシは、エンタープライズを保護するためのリバース プロキシとしても機能します。erpアプリケーションを上昇させます。 複数のプロキシ タイプのこの収束は、成功するために必要です。 SASE ソリューションを提供します。

• CTO の洞察ブログ

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