キーを使用してAzure AI 検索に接続する

Azure AI 検索は、Azure ポータルREST APIおよびAzure SDKから使用できます。 また、Foundry IQ は、エンタープライズ コンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジ ベースに変換するマネージド ナレッジ レイヤーです。

Azure AI 検索では、検索サービスへの接続に対して、ID ベースの認証とキーベースの認証 (既定) の両方がサポートされます。

検索サービス エンドポイントに対して行われた要求は、要求と API キーの両方が有効であり、検索サービスが要求で API キーを許可するように構成されている場合に受け入れられます。

重要

検索サービスを作成する際には、キーベース認証が既定値となりますが、これが最も安全な選択肢というわけではありません。 これをロールベースのアクセスに置き換えることをお勧めします。

[前提条件]

キーを表示または管理するには、所有者、共同作成者、または Search Service 共同作成者 である必要があります。

既定で有効

Azure ポータルでは、認証は Settings>Keys ページで指定されます。 API キー (既定) または両方に設定されたオプションは、要求で API キーを許可します。

Azure portal の [キー] ページのスクリーンショット。

キーの種類

API キーは、ランダムに生成された 52 個の数字と文字から成る一意の文字列です。 管理者キーとクエリ キーに見た目の違いはありません。 アプリケーションで指定されているキーの種類を把握できない場合は、Azure ポータルでキー値を確認

要求の認証には、次の 2 種類のキーが使用されます。

タイプ アクセス許可レベル 作成方法 最大値
管理者 すべてのデータ プレーン (コンテンツ) 操作に対するフル アクセス (読み取り/書き込み) プライマリセカンダリの 2 つの管理キーは、サービスの作成時に生成され、必要に応じて個別に再生成できます。 2 つを使用すると、サービスへの継続的なアクセスに 2 番目のキーを使用しながら、1 つのキーをロールオーバーできます。 2
クエリ 検索インデックスのドキュメント コレクションを対象とした読み取り専用アクセス サービスで 1 つのクエリ キーが生成されます。 検索サービス管理者は、さらに必要に応じて作成できます。 50

既存のキーを見つける

API キーは、Azure ポータルPowerShellAzure CLI、または REST API を使用して表示および管理できます。

  1. Azure ポータルで検索サービスに移動します。

  2. 左側のウィンドウで [設定]>[キー ]を選択して、管理者キーとクエリ キーを表示します。

    API キーを示すポータル ページのスクリーンショット。

接続でキーを使用する

キーベースの認証は、インデックスの作成やクエリ、 Search Service REST API を使用して実行されるその他のアクションなど、データ プレーン (コンテンツ) 要求にのみ使用されます。

ソース コードでは、要求ヘッダーで API キーを直接指定できます。 または、 環境変数またはアプリ 設定としてプロジェクトに格納し、要求で変数を参照することもできます。

  • 管理キーは、オブジェクトの作成、変更、または削除に使用されます。
  • 管理キーは、 LIST インデックスGET サービス統計などの GET オブジェクト定義とシステム情報にも使用されます。
  • 通常、クエリを発行するクライアント アプリケーションにクエリ キーが配布されます。

キー認証は既定で有効になっており、インデックス作成やクエリなどのデータ プレーン操作をサポートしていることを思い出してください。

ただし、API キーを無効にするとロールの割り当てを設定すると、Azure ポータルでは代わりにロールの割り当てが使用されます。

クエリ キーを作成する

クエリ キーは、ドキュメント コレクションをターゲットとする操作のために、インデックス内のドキュメントへの読み取り専用アクセスに使用されます。 検索、フィルター、および推奨クエリは、いずれもクエリ キーを取得する操作です。 インデックス定義やインデクサーの状態など、システム データまたはオブジェクト定義を返す読み取り専用操作には、管理者キーが必要です。

クライアント アプリでアクセスと操作を制限することは、サービスで検索アセットを保護するために不可欠です。 クライアント アプリから発信されたクエリには、常に管理者キーではなくクエリ キーを使用します。

  1. Azure ポータルで検索サービスに移動します。

  2. 左側のウィンドウで、[設定]>[キー] を選択して API キーを表示します。

  3. [クエリ キーの管理] で、サービス用に既に生成されているクエリ キーを使用するか、新しいクエリ キーを作成します。 既定のクエリ キーには名前はありませんが、生成された他のクエリ キーには、管理を容易にするために名前を付けることができます。

    クエリ キー管理オプションのスクリーンショット。

管理者キーを再生成する

ビジネス継続性のためにセカンダリ キーを使用しているときに、プライマリ キーをローテーションできるように、サービスごとに 2 つの管理者キーが作成されます。

  1. Azure ポータルで検索サービスに移動します。

  2. 次に、左側のペインで [設定]>[キー] を選択します。

  3. セカンダリ キーをコピーします。

  4. すべてのアプリケーションについて、セカンダリ キーを使用するように API キーの設定を更新します。

  5. プライマリ キーを再生成します。

  6. 新しいプライマリ キーを使用するように、すべてのアプリケーションを更新します。

誤って両方のキーを同時に再生成すると、それらのキーを使用するすべてのクライアント要求が HTTP 403 Forbidden で失敗します。 ただし、コンテンツは削除されず、永続的にロックアウトされることはありません。

引き続き、Azure ポータルまたはプログラムからサービスにアクセスできます。 管理機能は、サービス API キーではなくサブスクリプション ID を使用して操作するため、自分の API キーがない場合でも使用できます。

ポータルまたは管理レイヤーを介して新しいキーを作成した後に、要求時にそのキーを指定すると、アクセスがコンテンツ (インデックス、インデクサー、データ ソース、シノニム マップ) に復元されます。

キーからロールへの移行

ロールベースのアクセスに移行する場合は、Azure AI 検索組み込みロールにどのようにマップされるかを理解すると役立ちます>

  • 管理キーは、 Search Service 共同作成者 ロールと 検索インデックス データ共同作成者 ロールに対応します。
  • クエリ キーは、 検索インデックス データ閲覧者 ロールに対応します。

セキュリティで保護されたキー

ロールの割り当てを使用して、API キーへのアクセスを制限します。

カスタマー マネージド キー暗号化を使用して API キーを暗号化することはできません。 CMK で暗号化できるのは、検索サービス自体内の機密データ (データ ソース オブジェクト定義のインデックス コンテンツや接続文字列など) のみです。

  1. Azure ポータルで検索サービスに移動します。

  2. 左側のウィンドウで、[ アクセス制御 (IAM)] を選択し、[ロールの 割り当て ] タブを選択します。

  3. [ロール] フィルターで、キーを表示または管理するアクセス許可を持つロール (所有者、共同作成者、Search Service 共同作成者) を選択します。 これらのロールに割り当てられたセキュリティ プリンシパルは、検索サービスに対する主要なアクセス許可を持ちます。

  4. 予防措置として、[クラシック管理者] タブを確認して、管理者と共同管理者がアクセス権を持っているかどうかを確認します。

ベスト プラクティス

  • 運用ワークロードの場合は、Microsoft Entra ID ロールベースのアクセスに切り替えます。 また、API キーを引き続き使用する場合は、API キーに アクセスできるユーザーを 常に監視し、定期的に API キーを再生成 してください。

  • データ漏えいのリスクがない (サンプル データを使用する場合など) 場合や、ファイアウォールの背後で操作している場合にのみ、API キーを使用します。 API キーを公開すると、データと検索サービスの両方が不正使用のリスクにさらされます。

  • API キーを使用する場合は、Azure Key Vault。 API キーは、コード内に直接含めないようにし、絶対に公開しないでください。

  • コード、サンプル、トレーニング資料は公開前に必ず確認し、API キーを誤って公開しないようにしてください。