次の方法で共有


Azure 仮想マシン上の SQL Server インスタンスへのインデクサー接続

Azure 仮想マシン上のデータベースからコンテンツを抽出するように Azure SQL インデクサーを構成する場合は、セキュリティで保護された接続を行うために追加の手順が必要になります。

Azure AI Search から仮想マシン上の SQL Server インスタンスへの接続は、パブリック インターネット接続です。 セキュリティで保護された接続を成功させるには、次の手順を実行します。

  • 仮想マシン上の SQL Server インスタンスの完全修飾ドメイン名のために、認証機関プロバイダーから証明書を取得します。

  • この証明書を仮想マシンにインストールします。

VM に証明書をインストールすると、この記事の以降の手順を実行する準備が整います。

Note

Always Encrypted 列は、現在、Azure AI Search インデクサーではサポートされていません。

暗号化された接続を有効にする

Azure AI Search では、パブリック インターネット接続経由のすべてのインデクサー要求に対して暗号化されたチャネルが必要です。 このセクションでは、これを機能させるための手順を示します。

  1. 証明書のプロパティを調べて、サブジェクト名が VM の完全修飾ドメイン名 (FQDN) であることを確認します。

    プロパティは、CertUtils などのツールまたは証明書スナップインを使用して表示できます。 FQDN は、Azure portal で、VM サービス ページの [Essentials] セクションにある [パブリック IP アドレス/DNS 名ラベル]フィールドから入手できます。

    FQDN は通常、<your-VM-name>.<region>.cloudapp.azure.com と書式設定されます。

  2. レジストリ エディター (regedit) を使用して、証明書を使用するように SQL Server を構成します。

    このタスクにはよく SQL Server 構成マネージャーが使用されますが、このシナリオでは使用できません。 SQL Server 構成マネージャーでは、インポートされている証明書が検出されません。これは、Azure 上の VM の FQDN が、VM によって特定された FQDN と一致しないためです (VM は、ドメインをローカル コンピューターまたはそれが参加しているネットワーク ドメインとして識別します)。 名前が一致しない場合は、regedit を使用して証明書を指定します。

    1. regedit で、レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\[MSSQL13.MSSQLSERVER]\MSSQLServer\SuperSocketNetLib\Certificate に移動します。

      [MSSQL13.MSSQLSERVER] の部分は、バージョンとインスタンス名によって異なります。

    2. 証明書キーの値を、VM にインポートした TLS/SSL 証明書の拇印に設定します。

    拇印を取得する方法は複数ありますが、いくつかの方法は他の方法よりも優れています。 MMC の 証明書 スナップインからコピーする場合は、このサポート記事で説明されているように非表示の先頭文字を含めてしまい、その結果、接続を試みたときにエラーが発生する可能性があります。 この問題を修正するための回避策はいくつかあります。 最も簡単な方法は、regedit のキー値フィールドで Backspace キーを押してから拇印の最初の文字を再入力して、先頭文字を削除することです。 また、別のツールを使用して拇印をコピーすることもできます。

  3. サービス アカウントにアクセス許可を付与します。

    SQL Server サービス アカウントに TLS/SSL 証明書の秘密キーに関する適切なアクセス許可が付与されていることを確認します。 この手順を見落とすと、SQL Server は起動されません。 このタスクには証明書スナップインまたは CertUtils を使用できます。

  4. SQL Server サービスを再起動します。

SQL Server への接続

Azure AI Search に必要な暗号化された接続を設定したら、そのパブリック エンドポイントを介してインスタンスに接続します。 次の記事では、接続の要件と構文について説明しています。

ネットワーク セキュリティ グループを構成する

外部から Azure VM にアクセスできるように、ネットワーク セキュリティ グループ (NSG) および対応する Azure エンドポイントやアクセス制御リスト (ACL) を構成するのがベスト プラクティスです。 独自のアプリケーション ロジックから SQL Azure VM に接続できるようにするために、この構成を既に実行している可能性があります。 お使いの SQL Azure VM への Azure AI Search 接続でも変わりはありません。

次の手順とリンクでは、VM デプロイメントの NSG を構成する手順を説明しています。 これらの手順を、IP アドレスに基づいて ACL および 検索サービス エンドポイントに使用してください。

  1. Search サービスの IP アドレスを取得します。 手順については次のセクションを参照してください。

  2. Search サービスの IP アドレスをセキュリティ グループの IP フィルター リストに追加します。 手順については次の記事で説明されています。

IP アドレスの指定でいくつかの課題が生じる可能性がありますが、問題点と有効な回避策を把握していれば簡単に解決できます。 以降のセクションでは、ACL 内の IP アドレスに関する問題に対処するための推奨事項を説明します。

SQL Azure VM をすべての接続要求に開放するのではなく、ACL で Search サービスの IP アドレスと AzureCognitiveSearch サービス タグの IP アドレス範囲へのアクセスを制限することを強くお勧めします。

IP アドレスは、Search サービスの FQDN (<your-search-service-name>.search.windows.net など) に ping を実行することで確認できます。 Search サービスの IP アドレスが変わる場合がありますが、その可能性はほとんどありません。 この IP アドレスがサービスの有効期間中に変わることはほとんどありません。

AzureCognitiveSearch サービス タグの IP アドレス範囲を確認するには、ダウンロード可能な JSON ファイルまたは Service Tag Discovery API を使用します。 IP アドレス範囲は毎週更新されます。

Azure portal の IP アドレスを含める

Azure portal を使用してインデクサーを作成する場合は、ポータルに SQL Azure 仮想マシンへの受信アクセスを許可する必要があります。 ファイアウォールの受信規則では、ポータルの IP アドレスを指定する必要があります。

ポータルの IP アドレスを取得するには、ping stamp2.ext.search.windows.net を使用します。これはトラフィック マネージャーのドメインです。 要求はタイムアウトしますが、IP アドレスはステータス メッセージに表示されます。 たとえば、"Pinging azsyrie.northcentralus.cloudapp.azure.com [52.252.175.48]" というメッセージでは、IP アドレスは "52.252.175.48" になります。

異なるリージョンのクラスターは、異なるトラフィック マネージャーに接続します。 ドメイン名に関係なく、ping から返された IP アドレスは正しいもので、リージョン内の Azure portal で受信ファイアウォール規則を定義するときに使用します。

トークン認証を使用してネットワーク セキュリティを補完する

ファイアウォールとネットワーク セキュリティは、データと操作への未承認のアクセスを防ぐための最初の手順です。 次の手順となるのが承認です。

ロールベースのアクセスをお勧めします。この場合、Microsoft Entra ID のユーザーとグループは、サービスへの読み取りと書き込みのアクセス権を決定するロールに割り当てられます。 組み込みロールの説明とカスタム ロールを作成する手順については、ロールベースのアクセス制御を使用した Azure AI 検索への接続に関するページを参照してください。

キーベースの認証が必要ない場合は、API キーを無効にし、ロールの割り当てのみを使用することをおすすめします。

次のステップ

構成が間に合えば、Azure AI Search インデクサーのデータ ソースとして Azure VM 上の SQL Server を指定できるようになりました。 詳細については、Azure SQL のデータのインデックス作成に関する記事を参照してください。