Azure OpenAI でサポートされる認証方式
Azure OpenAI は、そのリソースへの安全かつ制御されたアクセスを確保するために、いくつかの認証方法をサポートしています。 主な方法は次のとおりです。
- API キー: Azure OpenAI では、API キーベースの認証もサポートされています。 API キーは Azure portal 内で生成され、Azure OpenAI Service への要求を認証するために使用できます。 この認証方法はセキュリティの観点から推奨されず、最後の手段としてのみ使用するようにしてください。 この認証方法を使用する必要がある場合は、API キーを安全に処理し、定期的にローテーションして不正アクセスのリスクを軽減することが重要です。
- Microsoft Entra ID: この方法では、Microsoft Entra の堅牢な ID およびアクセス管理機能を活用します。 ユーザーとアプリケーションは、Microsoft Entra ID (従来のユーザー アカウントまたはマネージド ID) を使用して認証します。 この方法にすることで、認証および認可されているユーザーのみが Azure OpenAI リソースにアクセスできるようになります。
- Entraマネージド ID: Azure リソースのマネージド ID は、Microsoft Entra 認証をサポートするリソースに接続するときにアプリケーションが使用するために、Microsoft Entra で自動的にマネージド ID を提供します。 これらの ID はシステム割り当て (つまり、特定の Azure リソースに関連付けられるもの) またはユーザー割り当ての場合があります。そのため、1 つの ID が複数のリソースで共有される可能性があります。 マネージド ID を使用すると、アプリケーション コードに資格情報をハードコーディングする必要がなくなるため、資格情報の管理が簡略化され、セキュリティが強化されます。
マネージド ID が API キーよりも安全である理由
Microsoft Azure のマネージド ID は、次のような理由から、API キーよりも安全な代替手段となります。
- マネージド ID を使用すると、開発者が資格情報を直接処理する必要がなくなるため、偶発的な開示や誤用のリスクが軽減されます。
- API キーを使用する場合、開発者はこれらのキーをアプリケーション コードまたは構成ファイル内に埋め込む必要があります。
API キーは、ソース コード リポジトリ、ログ、またはその他の手段を通じて誤って開示される可能性があります。 この開示は、不正アクセスや潜在的なセキュリティ侵害につながる可能性があります。 対照的に、マネージド ID により、自動的に管理される ID が提供され、Microsoft Entra (旧称 Azure AD) 認証をサポートするリソースにアプリケーションが接続するときに使用されます。 これは、資格情報がアプリケーション コードに保存されないことを意味し、漏えいや不正アクセスのリスクが軽減されます。
さらに、マネージド ID により、明示的な資格情報を必要とすることなく、Azure サービスが他の Azure サービスに対して安全に認証できるようになるので、認証プロセスが合理化されます。 これを達成するには、Microsoft Entra から発行されたトークンを使用します。これは自動的に管理およびローテーションされるため、資格情報が常に最新の状態に保たれ、資格情報の盗難のリスクが軽減されます。 一方、API キーは静的であり、手動でローテーションする必要があります。これはエラーが発生しやすく、忘れられがちなので、潜在的な脆弱性につながる可能性があります。 マネージド ID を使用すると、開発者はロールベースのアクセス制御 (RBAC) などの Azure の組み込みのセキュリティ機能を利用して、リソースに正確なアクセス許可を付与し、セキュリティをさらに強化できます。
Microsoft では、Azure OpenAI、またはマネージド ID をサポートするその他の Azure サービスに対して認証するときに、API キーではなくマネージド ID を使用することをお勧めします。
Azure OpenAI 内での API キーとマネージド ID の使用の違い
漏えいしたクライアント ID と漏えいした API キーの影響を評価してみましょう。
API キーは通常のパスワードと同様に機能します。 侵害された場合、キーを持っている人は誰でもリソースにアクセスできます。 Azure OpenAI の場合、これは GPT-4 などの AI モデルを無制限に使用できることを意味します。 ネットワークにパブリックにアクセスできる場合、セキュリティへの影響はさらに大きくなる可能性があります。
一方、クライアント ID が漏えいしてもリスクは最小限に抑えられます。 これは、クライアント ID だけでは Azure OpenAI への接続を確立できないためです。 マネージド ID を利用するには、サービスが Azure 上で機能している必要があり、Azure OpenAI がパブリックであっても、アプリケーションを使用してローカル環境やネットワーク経由で接続することはできません。
まとめると、漏えいした API キーの影響と比較して、漏えいしたクライアント ID を悪用するにはいくつかの手順が必要なので、悪意のあるアクターが悪用することは困難になります。
これらの理由があるので、マネージド ID は、API キーと比較してより安全に操作を管理できる方法です。 Microsoft では、Azure OpenAI、またはマネージド ID をサポートするその他の Azure サービスに対して認証するときに、API キーではなくマネージド ID を使用することを強くお勧めします。
システムまたはユーザー割り当て ID
Azure OpenAI アプリケーションを構築する場合、最適なセキュリティとリソース管理のためには、システム割り当てとユーザー割り当ての ID の違いを理解することが重要です。
- システム割り当て ID は、特定のリソースに対して Azure によって作成および管理されます。 リソースが削除されると、それに関連付けられたシステム割り当て ID も削除され、ID ライフサイクルはそのリソースが属するリソースと密接に結合されます。 この種類の ID は、ID を 1 つのリソースでのみ使用する必要があるシナリオに最適です。Azure が ID の資格情報を管理するため、シンプルになり、管理のオーバーヘッドが軽減されます。
- ユーザー割り当て ID は、特定のリソースとは別に作成され、複数のリソース間で共有できます。 そのため多用途であり、さまざまなリソースに一貫した ID を必要とするアプリケーションに適しています。また、アクセス許可とアクセス制御の管理が容易になります。 ユーザー割り当て ID は、それを使用しているリソースが削除された後も保持されるため、ID の再デプロイと再利用をより柔軟に行うことができます。
システム割り当てとユーザー割り当ての ID のどちらを選択するかは、アプリケーションの具体的なニーズによって異なります。 シンプルさと最小限の管理を優先する単一リソース アプリケーションの場合、通常はシステム割り当て ID が最良の選択です。 逆に、複数のリソースで共有される ID を必要とするアプリケーションの場合、ユーザー割り当て ID の柔軟性と再利用性は向上します。
