プラットフォームネイティブの Azure サービスを介して Azure OpenAI サービスを使用するインテリジェントなアプリケーションでは、シームレスなユーザー認証と承認のアプローチが用意されています。 ただし、異なるアーキテクチャ設計を必要とするさまざまなシナリオがあり、複雑さが生じます。 これらのシナリオには、Azure 以外のホストされているクライアント アプリケーションを持つトポロジ、外部 ID プロバイダーの使用、同じ Azure OpenAI インスタンスにアクセスする複数のクライアントのデプロイが含まれます。 これらのシナリオでは、Azure OpenAI の前にゲートウェイを導入すると、デプロイされたインスタンスに認証に対して一貫性を確保するレイヤーが追加されることにより、セキュリティが大幅に向上する可能性があります。
この記事では、Azure OpenAI サービスを使用して認証する際の、次の主要なシナリオについて説明します。
- 外部 ID プロバイダーで認証されたクライアント アプリケーション
- 証明書で認証されたクライアント アプリケーション
- 共有 Azure OpenAI インスタンスにアクセスする複数のクライアント アプリケーション
- 複数の Azure OpenAI インスタンスにアクセスするクライアント アプリケーション
各シナリオでは、それぞれで生じる課題と、ゲートウェイを含めることでもたらされる利点について説明します。
重要
次のガイダンスは、Azure API Management (APIM) を含むすべてのゲートウェイ実装に適しています。 アーキテクチャ図は、これを説明するために、ほとんどのシナリオでコンポーネントを汎用的に表します。
外部 ID プロバイダーで認証されたクライアント アプリケーション
シナリオの制約
このシナリオの制約を次に示します。
- クライアント アプリケーションは、Okta、Auth0、ソーシャル ID プロバイダーなどの外部 OpenID Connect (OIDC) 対応 ID プロバイダーを使用しています。
- クライアント アプリケーションは、Azure OpenAI データ プレーンのテナントとは異なる Microsoft Entra テナントに対して認証されています。
これらの制約は、次のようなシナリオに適用できます。
- 外部 OIDC プロバイダーまたは Microsoft Entra ID に対して既に認証されている既存のクライアント アプリケーションが、Azure OpenAI インスタンスと統合されています。
- クライアント アプリケーションでは、複数の ID プロバイダーのユーザーを一貫した方法で認証する必要があります。
Azure OpenAI への直接接続
これらのシナリオのクライアント アプリケーションが (ゲートウェイを使用せず) Azure OpenAI に直接接続している場合は、キーベースの認証を使用して Azure OpenAI への認証を行う必要があります。 キーベースの認証では、他にもセキュリティ上の問題が生じます。たとえば、キーの安全な格納やキーのローテーションのほか、さまざまなクライアントに対して個々のモデル デプロイにクライアント独自のロールベースのアクセス制御 (RBAC) 構成を提供できない、といったことが挙げられます。
ゲートウェイの導入
ゲートウェイを導入すると、いくつかの方法でこのシナリオの課題に対処できます。
- ゲートウェイでは、既存の外部 ID プロバイダーを使用してユーザーを認証するのに OAuth を使用できます。 ゲートウェイは、ID プロバイダーが生成した、認証済みのユーザー アクセス トークン (JSON Web トークン (JWT) など) を検証してから、バッキング Azure OpenAI インスタンスに承認を付与します。
- クライアントのキーの管理は不要になり、キーベース認証の使用に関連するセキュリティ リスクがなくなります。
- ゲートウェイはマネージド ID を使用して Azure OpenAI に接続できるため、最小特権を持つ Azure RBAC を使用することでセキュリティが向上します。
このシナリオの推奨事項とガイダンス
- より多くの OAuth スコープを ID プロバイダーのアプリケーションの登録に追加して、コンシューマーに対する詳細なアクセス許可を有効にすることができます。 これらのスコープを使用すると、クライアント アプリケーションは、Azure OpenAI へのアクセスなど、ゲートウェイで特定の操作を実行するためのアクセス許可を要求できます。
- 受信ポリシーを使用して、Azure API Management 用にこのシナリオを構成できます。 validate-jwt ポリシーを使用して、サポートされている JWT の存在、有効性、および属性の値を適用します。
このシナリオでゲートウェイを回避する理由
Azure OpenAI にアクセスするインテリジェントなアプリケーションが 1 つの場合は、アプリケーション内でユーザー認証と承認を構成するほうが、ゲートウェイよりも容易である可能性があります。 このアプローチを使用して、インテリジェントなアプリケーションを Azure OpenAI で安全に認証するために必要な Azure RBAC を割り当てることができます。
証明書で認証されたクライアント アプリケーション
シナリオの制約
このシナリオの制約を次に示します。
- 証明書を使用してクライアント アプリケーションを認証する必要がある。
- クライアント アプリケーションで認証用に Microsoft Entra ID または OIDC プロバイダーを使用できないか、ユーザーがそうした使用を望んでいない。
- クライアントが認証用にフェデレーション ID を使用できないか、ユーザーがそうした使用を望んでいない。
これらの制約は、次のようなシナリオに適用できます。
- Azure OpenAI サービスに対して認証を行うクライアントが、ユーザー操作のないコンピューターまたはデバイスである。
- 組織が、セキュリティ標準とコンプライアンス規則により、認証に証明書を使用する必要がある。
- クライアント証明書の使用など、環境に基づいて認証するオプションを複数のクライアント アプリケーションに提供する必要がある。
Azure OpenAI への直接接続
Azure OpenAI では、クライアント証明書認証はネイティブでサポートされていません。 ゲートウェイなしでこのシナリオをサポートするため、インテリジェント アプリケーションは、ユーザーの証明書認証を使用し、Azure OpenAI インスタンスへの要求を認証する際に API キーまたはマネージド ID を使用するように制限されます。 証明書認証ロジックは、すべてのクライアントに実装する必要があります。 このシナリオでクライアントから Azure OpenAI に直接接続すると、キーベースの認証を使用する場合のリスクと管理オーバーヘッドが適用されます。
ゲートウェイの導入
クライアントからクライアント証明書の検証をオフロードするゲートウェイをこのアーキテクチャに導入できます。 ゲートウェイには、インテリジェントなアプリケーションによって提示されるクライアント デジタル証明書を検証して、発行者、有効期限、拇印、失効リストを確認する必要があります。 ゲートウェイは、マネージド ID を使用して Azure OpenAI で自身を認証する必要があります。 ゲートウェイでは、Azure Key Vault を使用してルート証明機関 (CA) を格納し、クライアント証明書の検証が一元化された場所で管理されるようにする必要があります。こうしておくと、メンテナンスのオーバーヘッドが軽減されます。
このシナリオに対処するためにゲートウェイを導入すると、次のような利点がいくつかあります。
- アクセス キーではなくゲートウェイのマネージド ID を使用すると、キーが盗まれるリスクがなくなり、キーのローテーションに伴うメンテナンスの負担が軽減されます。
- 証明書の検証を一元化することで、一貫性のあるセキュリティ ポリシーを使用して、すべてのインテリジェント アプリケーションのクライアント デジタル証明書を評価できます。
- 証明書の検証をゲートウェイにオフロードすると、クライアント コードが簡略化されます。
このシナリオの推奨事項とガイダンス
- 証明書の検証時には、ルート CA と中間証明書を含め、証明書チェーン全体を確認します。 完全な検証により、証明書の信頼性が確保され、承認されていないアクセスが防止されます。
- 証明書の侵害のリスクを最小限に抑えるために、クライアント証明書を定期的にローテーションし更新します。 Azure Key Vault を使用してこのプロセスを自動化し、証明書が常に最新の状態になるようにします。 今後の証明書の有効期限に関するアラートを設定すると、ゲートウェイでのサービスの中断も防げます。
- 相互 TLS (mTLS) を実装して、クライアントとサーバーの両方が相互に認証されるようにし、セキュリティの追加レイヤーを提供します。 適切なポリシーと制約を設定して、mTLS を適用するようにゲートウェイを構成します。
- Azure API Management を使用すると、validate-client-certificate ポリシーを使用して、Azure Key Vault で参照されているクライアント証明書を検証できます。 このポリシーは、クライアント アプリケーションによって提示されるクライアント証明書を検証し、発行者、有効期限、拇印、失効リストを確認します。
このシナリオでゲートウェイを回避する理由
クライアントが少ない単純な環境では、クライアントでセキュリティと証明書管理を処理するコストが、ゲートウェイの導入によって生じる複雑さの増加よりも大きくなる可能性があります。 さらに、ゲートウェイが単一障害点になり、レイヤーの追加が原因で待機時間が長くなり、カスタム実装よりも商用ソリューションを選択した場合にはベンダーのロックインにつながる可能性があります。
アプリケーションの特定のニーズ、リソースの可用性、および重要度を慎重に評価してから、クライアント証明書認証用のゲートウェイの実装を決定する必要があります。
キーを使用して共有 Azure OpenAI インスタンスにアクセスする複数のクライアント アプリケーション
シナリオの制約
このシナリオの制約を次に示します。
- 複数のクライアント アプリケーションが共有 Azure OpenAI インスタンスにアクセスしている。
- クライアントが認証に Microsoft Entra ID を使用できないか、またはユーザーがその使用を望んでいない。
- クライアントが認証用にフェデレーション ID を使用できないか、ユーザーがそうした使用を望んでいない。
- ユーザーがクライアント アプリケーションにキーベースの認証を使用する必要がある。
これらの制約は、次のようなシナリオに適用できます。
- クライアント アプリケーションが、Azure、他のクラウド プロバイダー、オンプレミスなど、複数の環境にわたってデプロイされている。
- 組織が、それぞれ固有のアクセスと使用制限を持つさまざまなチームに Azure OpenAI サービスを提供する必要がある。
Azure OpenAI への直接接続
Azure OpenAI では、共有キーを使用したキーベースの認証がサポートされています。 Azure OpenAI では主キーと 2 次キーが公開されますが、2 次キーの目的は、クライアント ID の分離ではなく、キー ローテーションをサポートすることです。 このシナリオで複数のクライアントを Azure OpenAI に対して直接認証する場合、各クライアントは同じキーを共有します。 この実装には、次のような課題があります。
- すべてのクライアントが同じキーを共有しているため、特定のクライアントのアクセス許可を取り消すことはできません。
- 同じ Azure OpenAI インスタンス デプロイ内の異なるモデルに対して、異なるクライアントに異なるアクセス権を付与することはできません。
- ログ記録の観点から、あるクライアントと別のクライアントを区別することはできません。
ゲートウェイの導入
このアーキテクチャには、各クライアント アプリケーションに専用キーを発行するゲートウェイを導入できます。 Azure API Management では、専用のクライアント キーを提供するためにサブスクリプションの概念を使用します。 ゲートウェイは、マネージド ID を使用して Azure OpenAI で自身を認証する必要があります。
このシナリオに対処するためにゲートウェイを導入すると、次のような利点がいくつかあります。
- 他のクライアントに影響を与えることなく、1 つのクライアント アプリケーションへのアクセスを取り消すことができる。
- キーをローテーションする前にすべてのクライアントのキー構成を更新する必要がないため、キーのローテーションは組織的に難易度が下がる。 専用キーのローテーションは、クライアント構成の更新後にクライアントごとに実行できる。
- ログ記録の観点から、各クライアントを一意に識別できる。
- ゲートウェイが、各クライアントのレート制限とクォータを個別に適用する責任を負っている。
このシナリオの推奨事項とガイダンス
- ゲートウェイからマネージド ID を使用しても、Azure OpenAI ログ内のエンド ユーザーとクライアント アプリケーションの追跡可能性が向上しないため、API 要求に関連するメトリックの監視を強化します。 ゲートウェイは、要求元のクライアント ID やユーザー ID など、要求に関連付けられているログ記録を提供する必要があります。
- ゲートウェイ経由で複数のクライアント アプリケーション要求を共有 Azure OpenAI サービスにルーティングする際は、ゲートウェイがクライアント ID に基づいて適切なモデル デプロイにルーティングの決定を行っていることを確認します。 複数の Azure OpenAI デプロイに関するゲートウェイ実装のベスト プラクティスについては、「複数の Azure OpenAI デプロイの前にゲートウェイを使用する」を参照してください。
複数の Azure OpenAI インスタンスにアクセスするクライアント アプリケーション
シナリオの制約
このシナリオの制約を次に示します。
- クライアント アプリケーションが、1 つ以上のリージョン内にある複数の Azure OpenAI インスタンスに接続している。
- クライアントが認証用に Microsoft Entra ID または OIDC プロバイダーを使用できないか、ユーザーがそうした使用を望んでいない。
- ユーザーがクライアント アプリケーションにキーベースの認証を使用する必要がある。
これらの制約は、次のようなシナリオに適用できます。
- 待機時間を短縮しパフォーマンスを向上させるために、クライアント アプリケーションのワークロードを地理的に分散する必要がある。
- クライアント アプリケーションが、複数のリージョンにインスタンスをデプロイすることで、1 分あたりのトークン数 (TPM) クォータの最適化を試みる。
- プロビジョニングされたスループット デプロイと従量課金制デプロイで構成される可能性のあるデュアル デプロイ戦略を管理して継続的な運用を確保するために、組織がシームレスなフェールオーバーとディザスター リカバリー機能を必要としている。
- クライアント アプリケーションで、特定の Azure リージョンでのみ使用できる特定のモデル機能を使用する必要がある。
複数の Azure OpenAI インスタンスへの直接接続
クライアント アプリケーションが複数の OpenAI インスタンスに直接接続する場合、各クライアントは各インスタンス用のキーを格納する必要があります。 キーの使用に関するセキュリティ上の考慮事項に加えて、キーのローテーションに関する管理上の負担増があります。
ゲートウェイの導入
複数の Azure OpenAI デプロイにアクセスするクライアント アプリケーションを処理するためにゲートウェイを導入すると、キーを使用して共有 Azure OpenAI インスタンスにアクセスする複数のクライアント アプリケーションを処理するためにゲートウェイを導入する場合と同じ利点が得られます。 これらの理由に加えて、1 つのユーザー定義マネージド ID を使用してゲートウェイから複数の Azure OpenAI インスタンスへの要求を認証することで、認証のプロセスが合理化されます。 このアプローチを実装すると、全体的な運用オーバーヘッドが減り、複数のインスタンスを操作するときのクライアントの構成ミスのリスクが最小限に抑えられます。
このシナリオの推奨事項とガイダンス
- 高トラフィックを処理し、高可用性を確保するために、Azure OpenAI サービスの複数のインスタンスにわたって API 要求を分散する負荷分散手法を実装する。 この実装の詳細については、「複数の Azure OpenAI デプロイまたはインスタンスの前にゲートウェイを使用する」を参照してください。
- 複数の Azure OpenAI インスタンスを使用してマルチテナント シナリオを実装する際に、特定のテナントに関するトークン使用量の追跡をゲートウェイで相互に関連付ける必要がある。 ゲートウェイでトークン使用量を相互に関連付けることで、要求の転送先であるバックエンドの Azure OpenAI インスタンスに関係なく、トークン使用量の合計を追跡できます。
一般的な推奨事項
ゲートウェイを介して Azure OpenAI サービスを統合する際に、すべてのシナリオで適用される、考慮すべき横断的な推奨事項がいくつかあります。
独自のソリューションを作成するのではなく、Azure API Management (APIM) を選択することで、いくつかの利点を得られます。 効率的な API オーケストレーション、他の Azure サービスとの簡単な統合、開発とメンテナンスの労力削減によるコスト削減を実現できます。 APIM では、認証と承認を直接サポートすることで、セキュリティで保護された API 管理を実現しています。 Microsoft Entra ID などの ID プロバイダーと統合して、OAuth 2.0 を可能にし、ポリシーベースの承認を提供します。 さらに、マネージド ID を利用して、Azure OpenAI へのセキュリティで保護されたメンテナンス頻度の低いアクセスを実現できます。
包括的なゲートウェイ ソリューションのシナリオの組み合わせ
実際には、ユース ケースは、このガイドで説明されている複数のシナリオにまたがる場合があります。 たとえば、外部 ID プロバイダーで認証し、複数の Azure OpenAI インスタンスへのアクセスを必要とするクライアント アプリケーションがあるとします。
これらのシナリオの推奨事項を組み合わせることで、特定の要件をサポートするゲートウェイを構築するための包括的なアプローチを手に入れられます。
ゲートウェイ ポリシーの適用
Azure OpenAI インスタンスへの要求がゲートウェイ経由で送信される前に、受信認証ポリシーと承認ポリシーを適用する必要があります。 ID プロバイダーからのユーザー アクセス トークンまたは証明書検証のどちらを使用する場合でも、このアプローチであれば、認証された要求と承認された要求のみが確実に転送されます。
ゲートウェイでクライアント アプリケーションのロールとアクセス許可を使用して、それ以上の承認に関するスコーピングを実装すれば、きめ細かい制御も可能です。 これらのスコープを使用すると、クライアント アプリケーションのニーズに基づいて特定の操作が許可されるため、セキュリティと管理容易性が向上します。
アクセス トークンの検証の場合、グループ メンバーシップやアプリケーション ロールなど、関連するワークロード固有の要求に加えて、iss、aud、exp、nbf など、キーが登録されているすべての要求を必ず検証してください。
Azure マネージド ID を使用する
Azure マネージド ID を使用すると、認証管理を一元化することで、すべてのクライアント アプリケーション シナリオでの認証が簡略化されます。 このアプローチにより、クライアント アプリケーションでの複数の API キーまたは資格情報の管理に関連する複雑さとリスクが軽減されます。
マネージド ID は本質的に Azure ロールベースのアクセス制御をサポートしているため、ゲートウェイには Azure OpenAI インスタンスへのアクセスに必要な最小限のアクセス許可のみが付与されます。 マネージド ID は、代替認証方法の無効化と組み合わせることで、承認されていないアクセスのリスクを軽減し、セキュリティ ポリシーへのコンプライアンスを簡素化します。
包括的な監視の実装
マネージド ID を使用してゲートウェイを実装すると、追跡可能性が低下する可能性があります。マネージド ID が表すのはゲートウェイであり、エンド ユーザーでも、要求を行ったアプリケーションでもないためです。 したがって、API 要求に関連するメトリックの監視を向上させることが不可欠です。 ゲートウェイでは、要求元のクライアント ID やユーザー ID など、より多くのトレース メタデータを提供して、アクセス パターンと使用状況の可視性を維持する必要があります。
ゲートウェイを通過するすべての要求のログを一元化することは、監査証跡の維持にも役立ちます。 一元化された監査証跡は、トラブルシューティング、コンプライアンス、および承認されていないアクセスの試行を確実に検出するうえで特に重要です。
ゲートウェイの実装
Azure では、このようなゲートウェイを構築するためのターンキー ソリューションや参照アーキテクチャが提供されていません。 紹介記事に示されているように、このゲートウェイを構築して運用する必要があります。 上記ユース ケースに対応する、コミュニティでサポートされている実装の例を以下に示します。 独自のゲートウェイ ソリューションを構築するときは、これらのサンプルを参照することをお勧めします。
| 実装 | 例 |
|---|---|
| Azure OpenAI アプリケーション ID とセキュリティ – Learn Live ウェビナー | Learn Live: Azure OpenAI アプリケーション ID とセキュリティ (youtube.com) |
次のステップ
ワークロード用のゲートウェイを実装すると、この記事で詳しく説明した認証と承認を向上させるためのシナリオ以外の利点を得られます。 ゲートウェイで解決できる他の 重要な課題 についてもご確認ください。
共同作成者
この記事を最初に書いた共同作成者は次のとおりです。
プリンシパルの作成者:
- Lizet Pena De Sola | FastTrack for Azure のシニア カスタマー エンジニア
- Bappaditya Banerjee | FastTrack for Azure のシニア カスタマー エンジニア
- James Croft | ISV & デジタル ネイティブ センター オブ エクセレンスのカスタマー エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。