--- title: "SASEソリューションにおける識別ブローカーの役割" url: "https://www.aryaka.com/ja/blog/identity-broker/" markdown_url: "https://www.aryaka.com/ja/blog/identity-broker.md" llm_canonical: "https://www.aryaka.com/ja/blog/identity-broker.md" canonical_for_llm: true entity_type: "Article" primary_entity: "SASEソリューションにおける識別ブローカーの役割" citation_value: "Published on Aryaka; canonical URL https://www.aryaka.com/ja/blog/identity-broker/." last_updated: "2024-12-09T05:56:44-08:00" ---

SASEソリューションにおける識別ブローカーの役割

![アイデンティティ・ブローカー](https://www.aryaka.com/wp-content/uploads/2023/03/Blog-banner.jpg) [アイデンティティを意識したSASEに関する](https://www.aryaka.com/blog/realizing-identity-aware-sase/)前回のブログでは、ゼロトラスト、SASEの役割、アクセス制御におけるアイデンティティの重要性について述べました。 [SASEプロキシに関する](https://www.aryaka.com/blog/proxies-in-sase/)別のブログでは、SASEソリューションが、アイデンティティ・プロバイダ（IdP）を通してユーザを認証した後、ユーザのアイデンティティをどのように取得するかについて説明しています。 要約すると、SASE ソリューションのフォワードプロキシ部分は、Kerberos、NTLM、Digest、Basic 認証方式によってユーザを認証します。 一方、キャプティブ・ポータルは、KerberosまたはOIDCを通じてユーザーを認証します。 SASEソリューションのリバースプロキシ部分は、通常、ユーザーを認証するためにKerberosまたはOIDCのいずれかを使用します。 SASEのVPNゲートウェイは、エンタープライズ認証データベースでユーザーを認証します。 SASE ソリューションは、[JWT](https://www.rfc-editor.org/rfc/rfc7519)(JSON Web Token) フォーマットで、ユーザ認証情報を検証した ID プロバイダ、ユーザのメールアドレス、ユーザが所属するグループやロールなどのユーザ情報を期待します。 SASEソリューションは、この情報（JWT用語ではクレームと呼ばれる）を使用して、ID固有のアクセス制御を実施します。

アイデンティティ・ブローカー

IDブローカーとは、SASEソリューションによるエンドユーザの認証を、様々なIDプロバイダー（IdP）に仲介するサービスです。 すべての IdP がすべての認証プロトコルを実装しているわけではなく、OIDC、OAuth2、または SAMLv2 のみを実装している場合もあります。 SASEソリューションは、複数のIdPと連携するように設計されているため、異なる認証プロトコルをサポートする必要があり、複雑さが増します。 アイデンティティ・ブローカは、信頼された仲介サービスとして、SASE ソリューションがバックエンドで単一の認証プロトコルを使用することを可能にし、アイデンティティ・ブローカが、IdP がサポートする認証プロトコルを介して IdP に認証プロセスをプロキシさせることができます。 次の図は、IDブローカーを使用した場合と使用しない場合のSASEソリューションを示しています。 ![SASEソリューション](https://www.aryaka.com/wp-content/uploads/2023/03/SASE-solution.png) 図の左側は、アイデンティティブローカを持たないSASEです：ユーザのブラウザやアプリは、Kerberos、NTLM、ユーザ名/パスワード、ユーザ名/ダイジェストパスワードを使って、SASEのフォワードプロキシに認証を行います。 SASEはユーザ認証情報を検証する必要があります。 複数のバックエンド機能モジュールを使用して、さまざまな IdP/認証システムと通信します。 Kerberosの場合、サービスチケットは、SASEデータプレーン内でローカルに検証され、その後、LDAPやSCIMを介してADのような認証システムからユーザーの装飾を取得します。 ユーザ名/パスワードの場合、LDAPバックエンドはユーザ認証の検証にも使用されます。 SASEのリバースプロキシとキャプティブポータルは、OIDC(Open ID Connect)またはSAMLv2を介してユーザを認証します。 バックエンドの IdP も OIDC または SAMLv2 ベースの場合は、ユーザを IdP にリダイレクトします。 LDAPベースのシステムの場合、SASEはIdPとして動作し、LDAPをADに使用してユーザー認証情報を検証し、JWT形式でIDトークンを作成するためのユーザー装飾を取得することが期待されます。 VPNゲートウェイは、リモートアクセスに使用されるもう一つのモジュールです。 IKEv2トンネル確立の一環として、VPNゲートウェイはユーザーを認証します。 ユーザー認証情報は、ローカル DB、RADIUS サーバー、または LDAP サーバーで検証されます。 ご覧のように、さまざまなユーザーブラウザやネイティブアプリケーションで動作するために、さまざまなプロトコルをサポートする複数のデータプレーンコンポーネントが必要です。 また、さまざまなテナントだけでなく、テナント環境内の複数のIdP要件に対応する必要があります。 写真の右側は、IDブローカーを内蔵したSASEです：IDブローカーにより、SASEのデータプレーンは劇的に簡素化されます。 SASEのデータプレーンは、ブローカーに向けた1つの認証プロトコルのみで動作する必要があります。 上の図では、OIDC は、SASE データプレーンがサポートする必要がある唯一のプロトコルです。 Brokerは、複数のIdPとの認証セッションをオーケストレーション/フェデレートできます。 アイデンティティ・ブローカは、SAMLv2セキュリティ・トークンのユーザ情報、上流のIdPサーバからのJWT、またはローカル・データベースやLDAP経由でアクセス可能なユーザ情報からJWTを作成することも期待されています。 つまり、SASE用に設計されたIDブローカは、ユーザがプロキシ・ヘッダ経由のKerberos、WWWヘッダ経由のKerberos、OIDC、IKEv2、およびIdPがOIDC、SAMLv2、またはLDAPに基づいているかどうかに関係なく、すべてのケースでJWTを提供することが期待されます。 SASE IDブローカーからSASEデータプレーンを分解することには、複数の利点があります。 いくつかの利点を以下に挙げます。 1. モジュール化することで、ソリューション全体が複雑でなくなり、エラーの発生が少なくなり、その結果、より堅牢になります。 2. Secure:Identityブローカは、機密性の高いコンピューティング環境においてSASEデータプレーンとは別にインスタンス化することができ、IdPとの通信に使用される鍵/パスワード/認証情報が使用中であっても確実に保護されます。 3. 拡張性：SASEデータプレーンに影響を与えることなく、新しい認証プロトコルを持つ新しいIdPをサポートすることができます。 4. 統合：アイデンティティ・ブローカー・ソリューションは、他の用途でも検討されるようになってきています。 企業は、個別のIDブローカーサービス/ソリューションを利用する代わりに、SASEソリューションに付属するIDブローカーをアプリケーションに利用することができます。

SASE特有の機能

アイデンティティ・ブローカの機能は、ポリシー・チェックを実施し、適切なアクセス制御を行った認証ユーザーのみがこれらのリソースにアクセスできるようにすることで、SaaS/クラウド・サービスへの直接アクセスを阻止する上で、実際に重要な役割を果たすことができます。 さらに、従来のIDブローカーは、SASE認証に不可欠なプロキシKerberosをうまくサポートしていない場合があります。 したがって、ID ブローカが SASE ソリューションと効果的に統合するためには、プロキシ Kerberos およびその他の SASE 要件をサポートすることが重要です。 これらの機能拡張を提供することで、IDブローカーは企業の[SASEソリューションの](https://www.aryaka.com/managed-sase/)セキュリティと使いやすさを向上させることができます。 1. SaaSやクラウドサービスのIDベースのアクセス制御を常時かつ確定的に実現します：企業は、どこからでもアクセスできるSaaSやクラウドインフラストラクチャサービスをますます利用するようになっています。 これは大きな利点ですが、多くの企業にとってセキュリティ上の懸念でもあります。 企業は、SaaS/クラウドサービス内のデータへのアクセスを特定の従業員に制限したいと考えており、SASEはそれを確実にすることが期待されています。 しかし、これはSaaS/クラウド・サービスへのユーザ・トラフィックがSASEデータプレーンを経由している場合にのみ可能です。 トラフィックがSASEデータプレーンをバイパスして直接SaaS/クラウドサービスに向かう場合、アクセスが拒否されることが予想されます。 IDブローカーは、このようなアクセスを阻止するのに役立ちます。 SaaS/クラウドサービスがSASE IDブローカーを使用するように設定することで、新しいユーザ認証セッションは、まずSASE IDブローカーに着地します。 SASEのIDブローカーは、そのポリシーチェックを通して、ユーザが直接サービスにアクセスするのを止めることができます。 2. Kerberosグラントのサポート：多くのユースケースでは、暗黙の承認グラント・タイプとパスワード・グラント・タイプで十分です。 しかし、これら2つのグラント・タイプだけでは、Kerberos認証をサポートするには不十分です。 SASEデータプレーンは、Kerberosサービスチケットを受け取ると、プロキシヘッダまたはWWWヘッダを介して、ユーザ（ブラウザなど）から、サービスチケットを検証し、認証データベースから対応するユーザ情報を取得することが期待されています。 ブローカーは認証情報を検証するために使用されるため、OIDCプロトコルの実装は、SASEデータプレーンからIDブローカーへのサービスチケットの送信をサポートし、認証情報が検証された場合にJWTを取得するための拡張が必要です。

最終的な感想

アイデンティティ・ブローカーは、包括的なSASE（セキュア・アクセス・サービス・エッジ）ソリューションにおいて重要な役割を果たすことができます。 アイデンティティ・ブローカーを[SASEアーキテクチャに](https://www.aryaka.com/sase/sase-architecture/)統合することで、企業はアイデンティティとアクセス管理（IAM）ソリューションとSASEインフラストラクチャの統合を簡素化することができます。 これにより、ユーザーの認証とアクセス制御プロセスがより合理化され、安全になります。 さらに、ゼロトラストのセキュリティ原則を実施することで、IDブローカーは、許可されたユーザのみがSASE環境内のリソースにアクセスすることを保証することができます。 これにより、データ漏洩やその他のセキュリティ事故のリスクを軽減することができます。 業界アナリストは現在、SASEの文脈でIDブローカーについて議論していないかもしれませんが、組織がIT環境のセキュリティと効率を強化する方法を探し続けるにつれて、これが変わる可能性があります。 -

CTOインサイトブログ

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