今日のZTNAでは多様な用途に対応できません

認証と認可には様々な色があります。

SASEのZero Trust Network Access (ZTNA)コンポーネントは、企業のプライベートアプリケーションへのセキュアなインバウンドアクセスを提供するように設計されています。 Zero Trust Architecture (ZTA) における ID ベースのアクセス制御の基本原則に沿って、ZTNA は、エンタープライズアプリケーションへのすべての受信セッションにおいて、ユーザーを認証し、ユーザータイプ、グループ、およびロールに基づくアクセス制御を実施する上で重要な役割を果たします。 ZTNAのセキュリティは、以下のようなシナリオにおいて大きなメリットをもたらします：

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

現在の多くのZTNAソリューションは、シンプルなエンタープライズアプリケーションのフロントエンドには適していますが、SaaSアプリケーションのようなマルチテナント型アプリケーションの認証と認可を提供することはできません。 SaaSアプリケーションにおけるZTNAの役割：SaaS（Software-as-a-Service）アプリケーションの文脈では、ZTNAは認証と認可のメカニズムを強化・強化する上で重要な役割を果たすと私は考えています。 SaaS アプリケーションには、マルチテナント、DoS/DDoS 攻撃への耐性、認証バイパスや特権昇格攻撃に対する堅牢な保護など、特有の要件があります。 この記事では、SaaSアプリケーションの認証および認可プロセスをオフロードまたは強化するのに役立つ次世代ZTNAの機能について掘り下げます。 この記事では、WAAP（Web Application and API Protection）、HTTPS 終端、様々なアプリケーションインスタンスへの着信セッションのトラフィック管理、SSH/RDP/VNC サービスの Web 化、ポートスキャナからアプリケーションを不可視にするといった ZTNA の他の機能については取り上げませんのでご注意ください。 その主な焦点は、ZTNAの認証と認可の側面です。 SaaSの文脈では、CASB（Cloud Access Security Broker）とZTNAの役割が混同される可能性があることに注意することが重要です。 SASEのCASBコンポーネントは、企業が使用するSaaSサービスへの接続を保護することに重点を置いており、企業はSaaSとCASBサービスの消費者です。 一方、SaaSの文脈におけるZTNAは、SaaSアプリケーション自体を保護するように設計されており、SaaS企業はZTNAサービスの消費者となります。 この区別は、SASEソリューションにおけるCASBとZTNAの明確な役割と責任を理解するために不可欠です。 IDブローカーに関する前回の記事では、ブローカーをSASEソリューションに統合することの多くの利点について説明しました。 その利点は、主にモジュール性と設計のシンプルさであり、最終的にSASEソリューションの耐障害性を向上させるものです。 この記事では、特にSaaSアプリケーションを中心に、複雑なアプリケーションをサポートする上でIDブローカーが果たす極めて重要な役割について掘り下げます。

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

SASEのZTNAは、ポリシーベースの認可を強固にサポートすることに優れています。 SASEの認可エンジンは、複数のポリシーテーブルを管理する機能を提供し、各テーブルには複数のポリシーが含まれています。 各ポリシーは複数のルールで構成され、一致に成功した場合に実行されるアクションを指定します。 ルール自体には、ソース属性とデスティネーション属性に分類されるさまざまなマッチング属性が含まれます。 宛先属性は主に、アクセスされるアプリケーションのリソース（URIや、それらのリソースと相互作用するために使われるメソッド（GET、PUT、POST、DELETEなど）に関係します。 一方、ソース属性は通常、リソースにアクセスするサブジェクトに関連付けられます。 これらの属性には、名前、グループ、役割、ユーザー認証情報を検証した認証サービス、その他のユーザークレームなどのユーザー関連属性が含まれます。 また、対象者が使用するデバイスの安全な姿勢と、ユーザーがリソースにアクセスしているデバイスの場所をキャプチャするデバイスコンテキスト属性も含まれます。 しかし、多くのZTNAソリューションは、包括的な認証シナリオに対応するには不十分であり、多くの場合、非SaaSアプリケーションに機能を限定しています。 SASE/SSEソリューションにIdentity Brokerを組み込むことは、あらゆる種類のアプリケーションで包括的な認証を実現するための先進的なステップです。 SaaSベンダーは、アプリケーション内で認証と認可を処理する能力を持っていると主張するかもしれませんが、状況は大きく進化しています。 今日のアジャイル環境では、SaaSプロバイダーは、SASEのような外部エンティティにセキュリティ責任をオフロードすることの利点をますます認識するようになっています。 そうすることで、生産性が向上し、全体的なセキュリティ体制に対する信頼が高まるというメリットが得られます。 さらに、このアプローチにより、新規のSaaSプロバイダーは、認証と認可を外部のエンティティにオフロードし、主に自社のコア・ビジネス・ロジックに集中できるため、より迅速に市場に参入することができます。 SASEソリューションは、このような新しいSaaSプロバイダーをサポートする上で、極めて重要な役割を果たすことができます。 SASEソリューションは、SaaSアプリケーションのような複雑なアプリケーションに代わって、認証と認可のセキュリティを提供するという、この課題に取り組む準備ができているはずであり、そうなるはずだと、私たちは確信しています。 以下のシナリオは、SaaSアプリケーションの代表的な例を示し、IDブローカーを統合することによって、SASEがアプリケーションからの認証と認可の委譲をどのように支援できるかを探ります。 複数の API リソースで構成される SaaS アプリケーション（app.example.com でホスト）のシナリオ例を考えてみましょう：

このシナリオでは、SaaSプロバイダのIDPをexample-idpとします。 2つのテナントがあります：XYZとABCの2つのテナントがあり、それぞれのIDPサービスはXYZ-idpとABC-idpです。 また、各テナントには2つのパートナーがおり、それぞれ独自のIDPサービスを提供しています。 XYZ-P1-idpとXYZ-P2-idpはXYZパートナーのIDPサービスです。 ABC-P1-idpとABC-P2-idpは、ABCパートナーのIDPサービスです。 さらに、XYZテナントは公開APIスペースへのアクセスにGoogleとFacebook経由の認証を必要とし、ABCテナントはLinkedInとGitHub経由の認証を好みます。 上記のシナリオに対処するために、ZTNAでは以下の認可ポリシーが必要です：

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

SASEソリューションは、属性ベースのアクセス制御に優れています。 つまり、認証機能をうまく処理しているということです。 しかし、認証に関してはあまり包括的ではありません。 上記のポリシーでは、ユーザーが認証を選択した IDP サービスに基づいて、さまざまなレベルのアクセスが許可されます。 また、潜在的なデータ流出のミスを避けるために、最小限の権限でリソースにアクセスするために、意図的に特定のIDPサービスで認証したいユーザーもいるでしょう。

アイデンティティ・ブローカーの役割

このようなシナリオに対処するには、IDブローカーの統合機能が必要です。 アイデンティティ・ブローカーは、SASE/SSE プロキシ・コンポーネントの OIDC (OpenID Connect) プロバイダとして機能する一方、上流のアイデンティティ・サービス (認証サービス) の OIDC/SAML/LDAP クライアントとして機能します。 オープンソースのIAMシステムであるKeycloakは、多くの人に人気のある選択肢です。 IDブローカーの役割を果たすように構成することができ、SASEサービスプロバイダやサービスメッシュ製品ベンダーによって一般的に使用されています。 したがって、ここではキークローク用語を使用します。 Keycloakは、マルチテナントのSaaSアプリケーションを含む様々なタイプのアプリケーションの認証を処理する柔軟性を提供します。 マルチテナント SaaS アプリケーションの認証は、「ID ブローカー」を使用して次のように実現できます：認証フローを変更した SaaS アプリケーションごとに、1 つのレルムと 1 つのクライアント： URLパスやHTTPリクエストヘッダからアプリケーションやテナントを特定できない場合、SASEプロキシコンポーネントは、IDブローカーと通信するためのOIDCクライアントを1つだけ持つことができます。 ユーザー認証の際、IDブローカーはどのIDPサービスに対してユーザーを認証するかを知る必要があります。 Keycloakは、ブラウザフローのような標準的な認証フローを提供し、カスタマイズされたフローを作成し、Keycloakクライアントと関連付けることができます。 SASEは、ユーザがテナント情報を入力する認証フローを作成することで、この機能を活用しています。 この情報に基づいて、認証フローは、利用可能な ID プロバイダをユーザに提示して選択させることができます。 この情報により、ブローカーはユーザーを適切な ID サービスにリダイレクトできます。SaaSアプリケーションごとに複数のクライアントで1つのレルム： URLやHTTPリクエストヘッダからアプリケーションテナントを特定できる場合、SASEプロキシコンポーネントは、アプリケーションテナントごとに1つのクライアントを使用するように構成することができます。 この場合、異なるIDプロバイダー・セットを持つ標準的なブラウザー・フローを採用し、Keycloakの対応するクライアント・エンティティーと関連付けることができます。 この利点は、ユーザーがテナント名を入力する必要がないため、ユーザーエクスペリエンスが向上することです。 要約すると、これらの戦略により、SASEソリューションは、IDブローカーとしてのKeycloakの機能を活用して、マルチテナントSaaSアプリケーションの認証を効果的に処理できるようになります。

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

Keycloakブローカーは、複数の領域と各領域内の複数のクライアントをサポートしています。 標準認証フロー、カスタム認証フローの作成、およびこれらのフローとクライアントの関連付けが可能です。 Keycloakブローカー機能は、ユーザー側の認証メカニズムとバックエンド（アップストリーム）認証サービス間の認証セッションの仲介も可能にします。 Keycloakがユーザーにアプリケーション・テナントの識別を促し、認証用のIDサービスを選択させる方法については、以前に説明しました。 これらの機能は、マルチテナント・アプリケーションを含む様々な顧客アプリケーションのOIDCクライアント（OIDCリレーとしても知られています）として機能するSASEプロキシによっても活用されるべきです。 SASEプロキシは、複数のOIDCクライアントをサポートする必要があります。 1つのアプローチとして、顧客ごとにOIDCクライアントのセットを用意し、顧客固有の認証関連コンフィギュレーションが他から分離されるようにする方法があります。 通常、各SASE顧客のOIDCセットは、Keycloakのレルムに関連付けられます。 SASEプロキシの顧客が、それぞれ独自のドメイン名を持つ複数のアプリケーションを持っているシナリオでは、複数のアプリケーション管理者間で分離を提供する必要があります。 このような場合、OIDCクライアントのサブセットを構成し、各アプリケーションに1つのクライアントを割り当てる必要があります。 多くのアプリケーションでは、シングルテナントのアプリケーションである場合、または前述のようにトラフィックからテナントを特定できない場合は、単一の OIDC クライアントで十分です。 ただし、テナントが特定できれば、アプリケーションテナントごとに1つのOIDCクライアントを構成できます。 複数のOIDCクライアントが必要なため、SASEプロキシは適切なOIDCクライアントを選択するメカニズムを提供する必要があります。 そこで重要になるのが、ポリシーに基づいたOIDCの選択です。 複数のポリシーを持つポリシーテーブルが利用され、各ポリシーは対応するOIDCクライアントレコードを指します。 トラフィックフローの間、SASEプロキシはOIDC認証が必要かどうかをチェックし、顧客、アプリケーションドメイン名、アプリケーションテナントをテーブルのポリシーと照合します。 一致した場合、対応するOIDCクライアントレコードがブローカーとの通信に使用されます。 実装によっては、ポリシー・マッチング・プロセスを迅速化するために、各顧客に1つのテーブルを専用とする複数のポリシー・テーブルを持つ場合があります。

次世代ZTNAはマルチテナント・アプリケーションに適応します。

SASE（セキュア・アクセス・サービス・エッジ）ソリューション内のZTNA（ゼロ・トラスト・ネットワーク・アクセス）は、アプリケーションの安全性確保において重要な役割を果たします。 アプリケーションから認証と認可のタスクをオフロードできるため、開発者はコア・ビジネス・ロジックに集中できます。 このアプローチは生産性を高め、全体的なセキュリティを強化します。 すべての開発者がセキュリティの専門知識を持っているわけではないので、認証バイパスや権限昇格の脆弱性は、アプリケーショ ンによくあります。 セキュリティをオフロードすることで、これらの脆弱性を排除し、アプリケーションの耐障害性を強化することができます。 SASEのような共通基盤にセキュリティを一元化することで、セキュリティ管理者は、すべてのアプリケーションに対して単一のインターフェイスを管理するだけでよくなり、作業が簡素化されます。 セキュリティと柔軟性の両方を達成するために、SASEソリューション内の次世代のZTNAは、多様なアプリケーションタイプに対応する必要があります。 既存のZTNAソリューションの多くは、マルチテナント・アプリケーションを効果的にサポートするのに苦労しています。 今後の機能拡張では、IDブローカー機能やポリシーベースのOIDC（OpenID Connect）クライアントの選択機能を組み込み、幅広いアプリケーションシナリオに対応する予定です。

• CTOインサイトブログ

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