今日の ZTNA は多様なアプリケーションには十分ではありません

認証と認可にはさまざまな色があります

のゼロトラスト ネットワーク アクセス (ZTNA) コンポーネント SASE ent への安全な受信アクセスを提供するように設計されていますerpプライベートアプリケーションの増加。 ゼロ トラスト アーキテクチャ (ZTA) の ID ベースのアクセス制御の中核原則に沿って、ZTNA は、ユーザーを認証し、Entity へのすべての受信セッションでユーザー タイプ、グループ、および役割に基づいてアクセス制御を実施する上で重要な役割を果たします。erpアプリケーションを上昇させます。

ZTNA セキュリティは、次のシナリオで大きな利点をもたらします。

• レガシー アプリケーション: セキュリティ対策が組み込まれていないレガシー アプリケーションは、多くの場合、セキュリティ上の懸念から Work-From-Anywhere (WFA) ユーザーに公開されません。 ZTNA をこれらのレガシー アプリケーションのフロントエンドに利用することで、証明書管理による HTTPS 終端、OIDC などのプロトコルを使用した認証、およびコンテキスト認識型のアクセス制御に基づく認可を提供できます。 これにより、WFA ユーザーはインターネット経由でレガシー アプリケーションに安全にアクセスできるようになります。
• 壊れたアプリケーション: セキュリティを念頭に置いて開発されているにもかかわらず、一部のアプリケーションは長期間更新されていない可能性があります。 これらのアプリケーションには適切な証明書管理が欠けている可能性があり、古い証明書や新しい証明書のアップロードや自動更新がサポートされていない可能性があります。 ZTNA は、これらの壊れたアプリケーションのセキュリティ代替として機能し、セキュリティ制限を克服しながら安全なアクセスを確保します。
• 新しいアプリケーション アーキテクチャ: 最新のアプリケーションerpライズ アプリケーションは、多くの場合、セキュリティの考慮事項を ZTNA やサービス メッシュ テクノロジなどの外部エンティティに移して設計されています。 このアプローチでは、セキュリティがフロントエンド エンティティにオフロードされるため、アプリケーション開発者は HTTPS、認証、認可を処理する負担から解放されます。 セキュリティ管理を一元化することで、均一なセキュリティ ポリシーの適用、アプリケーション開発の生産性の向上、メンテナンスの簡素化などのメリットが得られます。 さらに、セキュリティ更新は外部で処理されるため、セキュリティ問題に対処することを目的としたパッチのリリース頻度が大幅に削減されます。

現在の ZTNA ソリューションの多くは、フロントエンドのシンプルな Ent に優れています。erpアプリケーションは増加しますが、次のようなマルチテナント アプリケーションの認証と認可を提供できません。 SaaS 分野の様々なアプリケーションで使用されています。

ZTNAの役割 SaaS アプリケーション: Software-as-a-Service のコンテキスト (SaaS) アプリケーションでは、ZTNA は認証および認可メカニズムの強化および強化において重要な役割を果たすだろうと私の考えではあります。 SaaS アプリケーションには、マルチテナント、DoS/DDoS 攻撃に対する回復力、認証バイパスや権限昇格攻撃に対する堅牢な保護など、特定の要件があります。 この記事では、認証および認可プロセスのオフロードまたは強化を支援できる次世代 ZTNA の機能について詳しく説明します。 SaaS アプリケーション。 この記事では、WAAP (Web アプリケーションおよび API 保護)、HTTPS 終端、さまざまなアプリケーション インスタンスへの受信セッションのトラフィック管理、SSH/API の Web 化などの ZTNA の他の機能については説明しないことに注意してください。RDP/VNC サービス、およびアプリケーションをポート スキャナーから見えないようにする。 その主な焦点は、ZTNA の認証と認可の側面にあります。

の役割の間で混同が生じる可能性があることに注意することが重要です。 CASB (Cloud Access Security Broker) と ZTNA のコンテキスト SaaSを選択します。 CASB のコンポーネント SASE への接続を保護することに重点を置いています SaaS ent が使用するサービスerp上昇、どこでerp上昇するのは消費者です SaaS & CASB サービス。 一方、ZTNA の文脈では、 SaaSを保護するように設計されています。 SaaS アプリケーション自体の作成 SaaS ZTNA サービスの企業消費者。 この区別は、企業の明確な役割と責任を理解するために不可欠です。 CASB とZTNAの SASE ソリューションを提供しています。

以前の記事で、 アイデンティティブローカーにブローカーを統合することの数多くの利点を調査しました。 SASE ソリューション。 説明した利点は主に設計のモジュール性とシンプルさを中心に展開し、最終的には復元力を強化します。 SASE ソリューション。 この記事では、複雑なアプリケーションをサポートする際のアイデンティティ ブローカーの極めて重要な役割について詳しく掘り下げていきます。特に次の点に焦点を当てます。 SaaS 分野の様々なアプリケーションで使用されています。

マルチテナント アプリケーションの課題は何ですか?

ZTNAの SASE ポリシーベースの認可に対する強力なサポートを提供することに優れています。 内部の認可エンジン SASE 各テーブルに複数のポリシーが含まれる複数のポリシー テーブルを管理する機能を提供します。 各ポリシーは複数のルールで構成され、一致が成功した場合に実行されるアクションを指定します。 ルール自体には、ソース属性と宛先属性として分類できるさまざまな一致属性が含まれています。

宛先属性は主に、URI やそれらのリソースと対話するために使用されるメソッド (GET、PUT、POST、DELETE など) など、アクセスされるアプリケーションのリソースに関係します。 一方、ソース属性は通常、リソースにアクセスするサブジェクトに関連付けられます。 これらの属性には、名前、グループ、ロール、ユーザー資格情報を検証した認証サービス、その他のユーザー クレームなどのユーザー関連の属性が含まれます。 これらには、対象者が使用するデバイスの安全な姿勢と、ユーザーがリソースにアクセスしているデバイスの場所をキャプチャするデバイス コンテキスト属性も含まれます。

ただし、多くの ZTNA ソリューションは、包括的な認証シナリオに対応するには不十分であり、多くの場合、その機能が非認証に制限されています。SaaS アプリケーション。 ID ブローカーの組み込み SASE/SSE ソリューションは、あらゆる種類のアプリケーションにわたる包括的な認証の実現に向けた進歩的なステップです。 という議論もあるかもしれないが、 SaaS ベンダーはアプリケーション内で認証と認可を処理する機能を備えており、状況は大幅に進化しています。

今日のアジャイル環境では、 SaaS プロバイダーは、セキュリティ責任を外部エンティティにオフロードすることの利点をますます認識しています。 SASE。 そうすることで、生産性が向上し、全体的なセキュリティ体制に対する自信が高まるという恩恵を受けることができます。 さらに、このアプローチにより、新たな SaaS プロバイダーは、認証と認可を外部エンティティにオフロードし、主にコア ビジネス ロジックに集中できるため、より迅速に市場に参入できます。 SASE ソリューションは、これらの新しいサポートにおいて極めて重要な役割を果たすことができます。 SaaS プロバイダ。

それが私たちの信念です SASE ソリューションは、次のような複雑なアプリケーションに代わって認証と認可のセキュリティを提供するというこの課題に取り組む準備ができているはずですし、これからも取り組むつもりです。 SaaS アプリケーション。 次のシナリオでは、その代表的な例を XNUMX つ示します。 SaaS アプリケーションを開発し、その方法を探ります SASE、アイデンティティ ブローカーを統合することにより、アプリケーションからの認証と認可の委任に役立ちます。

この例を考えてみましょう SaaS 複数の API リソースで構成されるアプリケーション (app.example.com でホストされている) シナリオ:

このシナリオでは、 SaaS プロバイダーは example-idp です。

XYZ と ABC という 1 つのテナントがあり、それぞれの IDP サービスは XYZ-idp と ABC-idp です。 各テナントには 2 つのパートナーもあり、それぞれが独自の IDP サービスを備えています。 XYZ-P1-idp および XYZ-P2-idp は、XYZ パートナーの IDP サービスです。 ABC-PXNUMX-idp および ABC-PXNUMX-idp は、ABC パートナーの IDP サービスです。

さらに、XYZ テナントはパブリック API スペースにアクセスするために Google と Facebook を介した認証を必要としますが、ABC テナントは LinkedIn と GitHub を介した認証を好みます。

上記のシナリオに対処するには、ZTNA で次の認可ポリシーが必要です。

1. ドメイン = app.example.com; ユーザーロール=アプリ管理者; authservice=example-idp; uri = /service-admin-api/* ALLOW: example-idp サービスに正常にログインし、ドメイン アプリを持つアプリケーションの admin-api の下にあるすべてのリソースに対する app-admin ロールを所有するユーザーにアクセスを許可します。 .example.com。
2. ドメイン = app.example.com; ユーザーグループ=管理者グループ; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW: XYZ/tenant-admin-api の下のすべてのリソースに対する admin-group ロールを持つ XYZ-idp サービスに正常にログインしたユーザーにアクセスを許可します。 。
3. ドメイン = app.example.com; ユーザーロール=管理者ロール; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW: ABC/tenant-admin-api リソースにアクセスし、ABC-idp サービスで認証され、admin-role を持つ任意のユーザーにアクセスを許可します。
4. ドメイン = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: ルールで指定されたリソースへのアクセスを、次のすべてのユーザーに許可します。 XYZ-idp サービスで正常に認証されました
5. ドメイン = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: ルールで指定されたリソースへのアクセスを、次のすべてのユーザーに許可します。 ABC-idp サービスで正常に認証されました
6. ドメイン = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: XYZ-P1-idp サービスで認証されたユーザーに XYZ コラボレーション スペースへのアクセスを許可します。
7. ドメイン = app.example.com; authservice=XYZ-P2-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: XYZ-P2-idp サービスで認証されたユーザーに XYZ コラボレーション スペースへのアクセスを許可します。
8. ドメイン = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: ABC-P1-idp サービスで認証されたユーザーに ABC コラボレーション スペースへのアクセスを許可します。
9. ドメイン = app.example.com; authservice=ABC-P2-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: ABC-P2-idp サービスで認証されたユーザーに ABC コラボレーション スペースへのアクセスを許可します。
10. ドメイン = app.example.com; authservice=google.com; uri = /tenants/XYZ/public-api/* 許可: google.com で認証されたすべてのユーザーに XYZ パブリック API スペースへのアクセスを許可します。
11. ドメイン = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* 許可: facebook.com で認証されたすべてのユーザーに XYZ パブリック API スペースへのアクセスを許可します。
12. ドメイン = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* 許可: linkedin.com で認証されたすべてのユーザーに ABC パブリック API スペースへのアクセスを許可します。
13. ドメイン = app.example.com; authservice=github.com; uri = /tenants/ABC/public-api/* 許可: github.com で認証されたすべてのユーザーに XYZ パブリック API スペースへのアクセスを許可します。
14. ドメイン = app.example.com; DENY: 上記のルールのいずれにも一致しない場合、アプリケーションへのアクセスを拒否します。

SASE ソリューションは属性ベースのアクセス制御に優れています。 これは、認証機能が適切に処理されることを意味します。 ただし、認証に関してはあまり包括的ではありません。 上記のポリシーでは、ユーザーが認証に選択したアイデンティティ プロバイダー (IDP) サービスに基づいて、さまざまなレベルのアクセスが付与されます。 また、一部のユーザーは意図的に wan潜在的なデータ漏洩の間違いを避けるために、特定の IDP サービスで認証して最小限の権限でリソースにアクセスします。

ID ブローカーの役割

このようなシナリオに対処するには、アイデンティティ ブローカーの統合機能が必要です。 ID ブローカーは、OIDC (OpenID Connect) プロバイダーとして機能します。 SASE/SSE プロキシ コンポーネントは、上流のアイデンティティ サービス (認証サービス) に対して OIDC/SAML/LDAP クライアントとして機能します。

オープンソースの IAM システムである Keycloak は、多くの人にとって人気のある選択肢です。 ID ブローカーの役割を果たすように構成でき、一般的に次のユーザーによって使用されます。 SASE サービスプロバイダーとサービスメッシュ製品ベンダー。 したがって、ここでは Keycloak の用語が使用されます。 Keycloakは、マルチテナントを含むさまざまなタイプのアプリケーションの認証を処理する柔軟性を提供します。 SaaS 分野の様々なアプリケーションで使用されています。

マルチテナントの認証 SaaS アプリケーションは、次の方法で「アイデンティティ ブローカー」を使用して実現できます。

XNUMX つのレルムとそれぞれに XNUMX つのクライアント SaaS 認証フローが変更されたアプリケーション:

アプリケーションテナントが識別できない場合 URL パスまたは HTTP リクエスト ヘッダー、 SASE プロキシ コンポーネントは、アイデンティティ ブローカーと通信するための OIDC クライアントを XNUMX つだけ持つことができます。 ユーザー認証中に、アイデンティティ ブローカーは、どの IDP サービスに対してユーザーを認証するかを認識する必要があります。 Keycloakはブラウザフローなどの標準認証フローを提供し、カスタマイズされたフローの作成とKeycloakクライアントとの関連付けを可能にします。 SASE は、ユーザーにテナント情報の提供を求める認証フローを作成することでこの機能を利用します。 この情報に基づいて、認証フローは、ユーザーが選択できる利用可能な ID プロバイダーを提示できます。 この情報を使用して、ブローカーはユーザーを適切な ID サービスにリダイレクトできます。

XNUMX つのレルムに複数のクライアントが存在する SaaS アプリケーション：

アプリケーションテナントが識別できる場合は、 URL または HTTP リクエスト ヘッダー、 SASE プロキシ コンポーネントは、アプリケーション テナントごとに XNUMX つのクライアントを使用するように構成できます。 この場合、さまざまなアイデンティティプロバイダーのセットを備えた標準のブラウザーフローを使用して、Keycloakの対応するクライアントエンティティに関連付けることができます。 この利点は、ユーザーがテナント名の入力を求められないため、ユーザー エクスペリエンスが向上することです。

要約すると、これらの戦略により次のことが可能になります。 SASE マルチテナントの認証を効果的に処理するソリューション SaaS Keycloak の機能をアイデンティティ ブローカーとして利用してアプリケーションを構築します。

ポリシーベースの OIDC クライアントの選択

Keycloak ブローカーは、複数のレルムと各レルム内の複数のクライアントのサポートを提供します。 これにより、標準の認証フロー、カスタム認証フローの作成、およびこれらのフローとクライアントの関連付けが可能になります。 Keycloakブローカー機能を使用すると、ユーザー側の認証メカニズムとバックエンド（アップストリーム）認証サービスの間の認証セッションの仲介も可能になります。 Keycloakがユーザーにアプリケーションテナントを識別し、認証用のアイデンティティサービスを選択するよう促す方法については以前に説明しました。

これらの機能は、 SASE プロキシ。マルチテナント アプリケーションを含むさまざまな顧客アプリケーションの OIDC クライアント (OIDC リレーとも呼ばれます) として機能します。

　 SASE プロキシは複数の OIDC クライアントをサポートする必要があります。 XNUMX つのアプローチは、顧客ごとに一連の OIDC クライアントを用意し、顧客固有の認証関連の構成を他の構成から確実に分離することです。 通常、それぞれ SASE 顧客の OIDC セットは Keycloak のレルムに関連付けられます。

の顧客が SASE プロキシには複数のアプリケーションがあり、それぞれが独自のドメイン名を持つため、複数のアプリケーション管理者間で分離を行う必要があります。 このような場合は、各アプリケーションに XNUMX つのクライアントを割り当てて、OIDC クライアントのサブセットを構成する必要があります。

多くのアプリケーションでは、シングルテナント アプリケーションである場合、または前述したようにトラフィックからテナントを識別できない場合は、単一の OIDC クライアントで十分です。 ただし、テナントが識別できる場合は、アプリケーション テナントごとに XNUMX つの OIDC クライアントを構成できます。

複数の OIDC クライアントの要件により、 SASE プロキシは、適切な OIDC クライアントを選択するためのメカニズムを提供する必要があります。 ここで、ポリシーベースの OIDC 選択が重要になります。

複数のポリシーを含むポリシー テーブルが利用され、各ポリシーは対応する OIDC クライアント レコードを指します。 交通の流れの中で、 SASE プロキシは、OIDC 認証が必要かどうかを確認し、顧客、アプリケーション ドメイン名、およびアプリケーション テナントをテーブル内のポリシーと照合します。 一致するものが見つかった場合、対応する OIDC クライアント レコードを使用してブローカーと通信します。 一部の実装では、ポリシー照合プロセスを迅速化するために、各顧客専用の XNUMX つのテーブルを含む複数のポリシー テーブルが存在する場合があります。

NextGen ZTNA はマルチテナント アプリケーションに適応します

ZTNA (ゼロトラスト ネットワーク アクセス) SASE (Secure Access Service Edge) ソリューションは、アプリケーションのセキュリティを確保する上で重要な役割を果たします。 これにより、認証および認可タスクをアプリケーションからオフロードできるため、開発者はコアのビジネス ロジックに集中できるようになります。 このアプローチにより、生産性が向上し、全体的なセキュリティが強化されます。

すべての開発者がセキュリティの専門知識を持っているわけではないため、認証バイパスと権限昇格の脆弱性はアプリケーションによく見られます。 セキュリティをオフロードすると、これらの脆弱性が排除され、アプリケーションの復元力が強化されます。

ありふれた場所にセキュリティを一元化する。 SASEにより、セキュリティ管理者の作業が簡素化され、すべてのアプリケーションに対して XNUMX つのインターフェイスを管理するだけで済みます。

セキュリティと柔軟性の両方を実現するために、次世代の ZTNA は SASE ソリューションは、さまざまな種類のアプリケーションに対応する必要があります。 既存の ZTNA ソリューションの多くは、マルチテナント アプリケーションを効果的にサポートするのに苦労することがよくあります。 将来の機能拡張には、幅広いアプリケーション シナリオに対応するために、アイデンティティ ブローカー機能とポリシー ベースの OIDC (OpenID Connect) クライアント選択が組み込まれることが期待されています。

• CTO の洞察ブログ

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