Azure AI 検索のネットワーク アクセスとファイアウォールの規則を構成する
この記事では、検索サービスのパブリック エンドポイントへのネットワーク アクセスを制限する方法について説明します。 パブリック エンドポイントへの "すべての" データ プレーン アクセスをブロックするには、プライベート エンドポイントと Azure 仮想ネットワークを使います。
この記事では、Azure portal でネットワーク アクセスのオプションを構成することを前提とします。 Management REST API、Azure PowerShell、または Azure CLI を使うこともできます。
前提条件
Basic レベル以上の検索サービス (任意のリージョン)
所有者または共同作成者のアクセス許可
どのようなときにネットワーク アクセスを構成するか
既定では、Azure AI 検索はパブリック エンドポイント経由の接続を許可するように構成されます。 パブリック エンドポイント経由での検索サービスへのアクセスは、認証と認可のプロトコルによって保護されますが、エンドポイント自体はデータ プレーン要求を受け付けるためにネットワーク層でインターネットに対して開かれています。
ホストするのがパブリック Web サイトではない場合は、承認済みのデバイスやクラウド サービスからの要求以外は自動的に拒否するようにネットワーク アクセスを構成することをお勧めします。
パブリック エンドポイントへのアクセスを制限するメカニズムは、次の 2 つがあります。
- 要求が許可される IP アドレス、範囲、またはサブネットを一覧表記するインバウンド規則
- 要求が信頼されたサービスから送信されている場合に限り要求をチェックなしで許可する、ネットワーク規則に対する例外
ネットワーク規則は必須ではありませんが、プライベートまたは社内用のコンテンツを見つけるために Azure AI 検索を使用する場合は、追加しておくことがセキュリティのベスト プラクティスです。
ネットワーク規則のスコープは、検索サービスのパブリック エンドポイントに対するデータ プレーン操作です。 データ プレーン操作には、インデックスの作成またはクエリ、および Search REST API に関する記事で説明されているその他のすべてのアクションが含まれます。 コントロール プレーン操作の対象はサービスの管理です。 それらの操作で指定されるリソース プロバイダー エンドポイントは、Azure Resource Manager でサポートされているネットワーク保護の対象になります。
制限事項
パブリック エンドポイントのロックダウンには、いくつかのデメリットがあります。
IP 範囲を完全に特定してファイアウォールを設定するには時間がかかります。現在は概念実証テストと調査の初期段階で、サンプル データを使用しているという場合は、ネットワーク アクセス制御は実際に必要になるまで延期することをお勧めします。
ワークフローによっては、パブリック エンドポイントへのアクセスが必要になります。 具体的には、Azure portal のインポート ウィザードが、組み込みの (ホストされる) サンプル データと埋め込みモデルにパブリック エンドポイント経由で接続します。 コードまたはスクリプトに切り替えると、同じタスクをファイアウォール規則が適用されているときも完了できますが、ウィザードを実行したい場合は、パブリック エンドポイントがアクセス可能であることが必要です。 詳細については、インポート ウィザードでの安全な接続に関するページを参照してください。
Azure portal でネットワーク アクセスを構成する
Azure portal にサインインして、検索サービスを見つけます。
左端のペインで、[設定] の [ネットワーク] を選びます。 このオプションが表示されない場合は、サービス レベルを確認してください。 [ネットワーク] のオプションは、Basic レベル以上で使用できます。
[選択した IP アドレス] を選びます。 プライベート エンドポイントを構成する場合を除き、[無効] オプションは使わないでください。
このオプションを選ぶと、さらに多くの設定を使用できるようになります。
[IP ファイアウォール] で [クライアント IP アドレスを追加する] を選んで、お使いの個人用デバイスのパブリック IP アドレスに対するインバウンド規則を作成します。 詳しくは、「Azure portal IP アドレスからのアクセスを許可する」をご覧ください。
検索サービスに要求を送信する他のデバイスとサービスの他のクライアント IP アドレスを追加します。
IP アドレスと範囲は CIDR 形式です。 CIDR 表記の例として、8.8.8.0/24 があります。これは、8.8.8.0 から 8.8.8.255 の範囲の IP を表しています。
検索クライアントが Azure 上の静的な Web アプリである場合は、「Azure App Service における受信 IP アドレスと送信 IP アドレス」をご覧ください。 Azure Functions の場合は、「Azure Functions の IP アドレス」をご覧ください。
[例外] で、[信頼されたサービス リストにある Azure サービスに対し、この検索サービスにアクセスすることを許可します] をオンにします。 信頼されたサービスのリストには、次のものが含まれます。
- Azure OpenAI と Azure AI サービスに対する
Microsoft.CognitiveServices - Azure Machine Learning に対する
Microsoft.MachineLearningServices
この例外を有効にすると、Microsoft Entra ID 認証、マネージド ID、ロールの割り当てに依存します。 検索サービスに対する有効なロールの割り当てを持つ Azure AI サービスまたは AML 機能は、ファイアウォールをバイパスできます。 詳しくは、信頼されたサービスへのアクセスの許可に関するセクションをご覧ください。
- Azure OpenAI と Azure AI サービスに対する
変更内容を保存します。
Azure AI Search サービスに対して IP アクセス制御ポリシーを有効にした後は、許可された IP アドレス範囲リストに含まれていないマシンからのデータ プレーンへの要求はすべて拒否されます。
許可リストに含まれていない IP アドレスから要求が送信された場合は、他の詳細を含まない汎用的な 403 Forbidden 応答が返されます。
重要
変更が有効になるまで数分かかる場合があります。 ネットワーク構成に関連する問題のトラブルシューティングは、少なくとも 15 分待ってから行ってください。
Azure portal IP アドレスからのアクセスを許可する
IP 規則が構成されている場合は、Azure portal の一部の機能が無効になります。 サービス レベルの情報は表示して管理できますが、インポート ウィザード、インデックス、インデクサー、その他の最上位レベルのリソースへのポータルからのアクセスは制限されます。
ポータル IP アドレスを許可すると、ポータルからすべての検索サービス操作へのアクセスを元に戻すことができます。
ポータルの IP アドレスを取得するには、次に対して nslookup (または ping) を実行します。
stamp2.ext.search.windows.netは、Azure パブリック クラウドのトラフィック マネージャーのドメインです。stamp2.ext.search.azure.us(Azure Government クラウドの場合)。
nslookup の場合、IP アドレスは応答の "権限のない回答" 部分に表示されます。 次の例では、コピーする必要がある IP アドレスは 52.252.175.48 です。
$ nslookup stamp2.ext.search.windows.net
Server: ZenWiFi_ET8-0410
Address: 192.168.50.1
Non-authoritative answer:
Name: azsyrie.northcentralus.cloudapp.azure.com
Address: 52.252.175.48
Aliases: stamp2.ext.search.windows.net
azs-ux-prod.trafficmanager.net
azspncuux.management.search.windows.net
サービスが異なるリージョンで実行されている場合は、異なるトラフィック マネージャーに接続します。 ドメイン名に関係なく、ping から返された IP アドレスは正しいもので、リージョン内の Azure portal で受信ファイアウォール規則を定義するときに使用します。
ping の場合、要求はタイムアウトしますが、IP アドレスは応答に表示されます。 たとえば、メッセージ "Pinging azsyrie.northcentralus.cloudapp.azure.com [52.252.175.48]" 内の IP アドレスは 52.252.175.48 です。
IP 規則がポータルのエクスペリエンスに影響することがバナーで示されます。 このバナーは、ポータルの IP アドレスを追加した後も表示されたままになります。 テストする前に、ネットワーク規則が有効になるまで忘れずに数分待ってください。
信頼された Azure サービスにアクセスを許可する
信頼されたサービスの例外を選択しましたか。 "はい" の場合は、その検索サービスでは信頼される Azure リソースからの要求と応答が IP アドレスの確認なしで許可されます。 信頼されるリソースには、マネージド ID (システムまたはユーザーが割り当てますが、通常はシステム) が必要です。 信頼されるリソースには、データと操作に対するアクセス許可を付与する Azure AI 検索でのロールの割り当てが必要です。
Azure AI 検索の信頼されたサービス リストには、次のものが含まれます。
- Azure OpenAI と Azure AI サービスに対する
Microsoft.CognitiveServices - Azure Machine Learning に対する
Microsoft.MachineLearningServices
このネットワーク例外のワークフローは、Azure AI Studio またはその他の AML 機能から Azure AI 検索に送信される要求です。 信頼されたサービスの例外は、通常、取得拡張生成 (RAG) およびプレイグラウンド環境の Azure OpenAI On Your Data シナリオ用です。
信頼されるリソースにはマネージド ID が必要
Azure OpenAI と Azure Machine Learning のためのマネージド ID を設定するには:
Azure AI サービスのためのマネージド ID を設定するには:
- マルチサービス アカウントを見つけます。
- 左端のペインの [リソース管理] で、[ID] を選びます。
- [システムが割り当て済み] を [オン] に設定します。
信頼されるリソースにはロールの割り当てが必要
Azure リソースがマネージド ID を持つようになったら、Azure AI 検索でのロールを割り当ててデータと操作へのアクセス許可を付与します。
信頼されるサービスは、ベクトル化ワークロードに使用されます。つまり、テキストと画像のコンテンツからベクトルを生成してペイロードを検索サービスに送り返し、これでクエリの実行またはインデックス作成ができるようになります。 信頼されるサービスからの接続は、ペイロードを Azure AI 検索に届けるために使用されます。
左端のペインの [アクセス制御 (IAM)] で、[ID] を選びます。
[追加] を選択し、[ロールの割り当ての追加] を選択します。
[ロール] ページで次の操作を行います。
- 埋め込みモデルによって生成されたベクトルとともに検索インデックスを読み込むには [検索インデックス データ共同作成者] を選択します。 インデックス作成時に垂直統合を使用する場合は、このロールを選択します。
- 埋め込みモデルによって生成されたベクトルをクエリに提供するには、[検索インデックス データ閲覧者] を選択します。 クエリで使用される埋め込みがインデックスに書き込まれることはないため、書き込みアクセス許可は必要ありません。
[次へ] を選択します。
[メンバー] ページで、[マネージド ID] と [メンバーを選択する] を選択します。
システムマネージド ID でフィルター処理してから、使用する Azure AI マルチサービス アカウントのマネージド ID を選択します。
Note
この記事では、検索サービスへの要求を許可するための信頼された例外について説明しますが、Azure AI 検索自体が他の Azure リソースの信頼されたサービス リストに含まれます。 具体的には、Azure AI 検索から Azure Storage への接続に信頼されたサービス例外を使用できます。
次のステップ
要求は、ファイアウォールの通過を許可されたら、認証と認可を受ける必要があります。 2 つのオプションがあります。
キーベースの認証では、要求に対して管理またはクエリの API キーが提供されます。 これは既定のオプションです。
Microsoft Entra ID を使用するロールベースのアクセス制御。この方法では、呼び出し元は検索サービスでのセキュリティ ロールのメンバーです。 これは最も安全なオプションです。 データと操作に対するアクセス許可のための Azure AI 検索での認証とロールの割り当てには、Microsoft Entra ID を使います。