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