次の方法で共有

Azure AI Search のセキュリティの概要

  • [アーティクル]

この記事では、データと操作を保護する Azure AI Search のセキュリティ機能について説明します。

データ フロー (ネットワーク トラフィック パターン)

Azure AI Search サービスは Azure でホストされ、通常はパブリック ネットワーク接続を使用してクライアント アプリケーションからアクセスされます。 このようなパターンとなることが多いですが、他のトラフィック パターンにも注意する必要があります。 開発環境と運用環境をセキュリティ保護するには、すべてのエントリ ポイントと送信トラフィックについて理解しておく必要があります。

Azure AI Search には、3 つの基本的なネットワーク トラフィック パターンがあります。

  • ユーザーまたはクライアントによって行われる、検索サービスへのインバウンド要求 (主要なパターン)
  • 検索サービスによって発行される、Azure やそれ以外の場所の他のサービスへのアウトバウンド要求
  • セキュリティ保護された Microsoft バックボーン ネットワークを介して行われる内部サービス間の要求

受信トラフィック

検索サービス エンドポイントを対象とする受信要求には、次が含まれます。

  • 検索サービスでインデックスやその他のオブジェクトを作成、読み取り、更新、または削除する
  • 検索ドキュメントのインデックスを読み込む
  • インデックスのクエリ
  • インデクサーまたはスキルセットの実行をトリガーする

REST API のページで、検索サービスによって処理される受信要求の全範囲が説明されています。

少なくとも、すべての受信要求は、次のいずれかのオプションを使用して認証される必要があります。

  • キーベースの認証 (デフォルト)。 受信要求が、有効な API キーを提供します。
  • ロールベースのアクセス制御。 認可は、検索サービスの Microsoft Entra ID とロールの割り当て経由で行われます。

さらに、ネットワーク セキュリティ機能を追加して、エンドポイントへのアクセスをさらに制限できます。 IP ファイアウォールでの受信の規則、またはパブリック インターネットから検索サービスを完全に遮断するプライベート エンドポイントのいずれかを作成することができます。

内部トラフィック

内部要求は、Microsoft によってセキュリティで保護され、管理されます。 これらの接続を構成または制御することはできません。 ネットワーク アクセスをロックダウンしている場合、顧客が内部トラフィックを構成できないため、顧客からのアクションは必要ありません。

内部トラフィックは次で構成されます。

送信トラフィック

送信要求は、ユーザーがセキュリティで保護および管理できます。 送信要求は、検索サービスから他のアプリケーションに向けて発生します。 通常、これらの要求は、クエリ時にテキストベースのインデックス作成、カスタム スキルベースの AI エンリッチメント、ベクター化を行うために、インデクサーによって行われます。 送信要求には、読み取りと書き込みの両方の操作が含まれます。

次の一覧は、セキュリティで保護された接続を構成できる送信要求の完全な列挙です。 検索サービスは、検索自体のため、およびインデクサーまたはカスタム スキルのために要求を行います。

操作 シナリオ
インデクサー 外部データ ソースに接続してデータを取得します。 詳細については、「Azure ネットワーク セキュリティで保護されたコンテンツへのインデクサー アクセス」を参照してください。
インデクサー Azure Storage に接続して、ナレッジ ストア、キャッシュされたエンリッチメント、デバッグ セッションを持続させます。
カスタム スキル サービス外でホストされている外部コードを実行している Azure Functions、Azure Web アプリ、またはその他のアプリに接続します。 スキルセットの実行中に、外部処理に対する要求が送信されます。
インデクサーと垂直統合 Azure OpenAI とデプロイされた埋め込みモデルに接続するか、カスタム スキルを経由して、指定する埋め込みモデルに接続します。 検索サービスは、インデックス作成中にベクター化のために埋め込みモデルにテキストを送信します。
ベクター化 クエリ時に Azure OpenAI またはその他の埋め込みモデルに接続して、ベクター検索のためにユーザー テキスト文字列をベクターに変換します。
検索サービス 機密データの暗号化および復号化に使用されるカスタマー マネージド暗号化キーを取得するために、Azure Key Vault に接続します。

送信接続は、キーまたはデータベース ログインを含むリソースのフル アクセス接続文字列を使用して確立することも、Microsoft Entra ID とロールベースのアクセスを使用している場合はマネージド ID を使用して確立することもできます。

ファイアウォールの内側にある Azure リソースにアクセスするには、他の Azure リソースに検索サービス要求を許可する受信規則を作成します。

Azure Private Link によって保護された Azure リソースにアクセスするには、インデクサーが接続を確立するために使用する共有プライベート リンクを作成します。

同じリージョンの検索サービスとストレージ サービスの例外

Azure Storage と Azure AI Search が同じリージョンにある場合、ネットワーク トラフィックはプライベート IP アドレス経由でルーティングされ、Microsoft バックボーン ネットワークで発生します。 プライベート IP アドレスが使用されるため、ネットワーク セキュリティ用に IP ファイアウォールまたはプライベート エンドポイントを構成することはできません。

次のいずれかの方法を使用して、同じリージョンの接続を構成します。

ネットワークのセキュリティ

ネットワーク セキュリティは、ネットワーク トラフィックに制御を適用することにより、未承認のアクセスや攻撃からリソースを保護します。 Azure AI Search は、未承認のアクセスに対する防御の前線になり得るネットワーク機能をサポートしています。

IP ファイアウォール経由の受信接続

検索サービスは、パブリック IP アドレスを使用して、アクセスを許可するパブリック エンドポイントによりプロビジョニングされます。 パブリック エンドポイントを経由するトラフィックを制限するには、特定の IP アドレスまたは IP アドレスの特定の範囲から要求を許可する受信ファイアウォール規則を作成します。 すべてのクライアント接続は、許可された IP アドレスを使用して行う必要があります。それ以外の場合、接続は拒否されます。

IP 制限アクセスのサンプル アーキテクチャの図

ファイアウォール アクセスを構成するには、ポータルを使用します。

または、管理 REST API を使用します。 API バージョン 2020-03-13 以降では、IpRule パラメーターを指定することで、検索サービスへのアクセスを付与する IP アドレスを個別に、あるいは範囲で特定することで、サービスへのアクセスを制限できます。

プライベート エンドポイントへの受信接続 (ネットワーク分離、インターネット トラフィックなし)

より強力なセキュリティには、Azure AI Search のプライベート エンドポイントを確立して、仮想ネットワーク上のクライアントが Private Link を介して、検索インデックス内のデータに安全にアクセスできるようにします。

プライベート エンドポイントでは、検索サービスに接続するために仮想ネットワークのアドレス空間の IP アドレスが使用されます。 クライアントと検索サービス間のネットワーク　トラフィックは、仮想ネットワークおよび Microsoft バックボーン ネットワーク上のプライベートリンクを経由することで、パブリック インターネット上での露出を排除します。 仮想ネットワークを使用すると、オンプレミス ネットワークやインターネットで、リソース間の安全な通信が可能になります。

プライベート エンドポイント アクセスのサンプル アーキテクチャの図

このソリューションは最も安全ですが、追加のサービスを使用すると、さらなるコストがかかります。そのため、使用の前に利点の詳細を明確に理解しておく必要があります。 コストの詳細については、価格ページを参照してください。 これらのコンポーネントを連携させる方法の詳細については、こちらのビデオをご覧ください。 プライベート エンドポイント オプションの説明は、ビデオの 5:48 から始まります。 エンドポイントを設定する方法については、Azure AI Search でのプライベート エンドポイントの作成に関するページを参照してください。

認証

検索サービス宛ての要求が承認された後も、要求が許可されているかどうかを判断する認証と認可を受ける必要があります。 Azure AI Search は、2 つの方法をサポートします。

  • Microsoft Entra 認証では、認証された ID として (要求ではなく) 呼び出し元が確立されます。 Azure ロールの割り当てが認可を決定します。

  • キーベースの認証は、API キーにより (呼び出し元のアプリやユーザーではなく) 要求に対して行われます。このキーは、要求が信頼できるソースからの要求であることを証明する、ランダムに生成された数字と文字で構成される文字列です。 キーは要求ごとに必要です。 有効なキーの送信は、要求が信頼されたエンティティのものであることの証明と見なされます。

両方の認証方法を使用することも、検索サービスで使用可能にしない方法を無効にすることもできます。

承認

Azure AI Search には、サービス管理とコンテンツ管理のためのさまざまな認可モデルが用意されています。

Azure サービス管理

リソース管理は、Microsoft Entra テナント内のロールベースのアクセス制御によって認可されます。

Azure AI Search では、Resource Manager を使用して、サービスの作成または削除、API キーの管理、サービスのスケーリング、セキュリティの構成が行われます。 そのため、ポータル、PowerShell、Management REST API のどれを使用しているかにかかわらず、Azure で割り当てられているロールによって、これらのタスクを実行できるユーザーが決定されます。

3 つの基本ロール (所有者、共同作成者、閲覧者) が検索サービスの管理に適用されます。 ロールの割り当ては、サポートされている任意の方法 (ポータル、PowerShell など) を使用して行うことができ、サービス全体に適用されます。

Note

Azure 全体のメカニズムを使用して、サブスクリプションまたはリソースをロックし、管理者権限を持つユーザーが検索サービスを誤って、または許可なく削除しないようにすることができます。 詳細については、リソースのロックによる予期せぬ削除の防止に関するページを参照してください。

コンテンツへのアクセスを承認する

コンテンツ管理とは、検索サービスで作成およびホストされるオブジェクトを指します。

  • ロールベースの認可の場合、Azure のロールの割り当てを使用して、操作に対する読み書きアクセスを確立します。

  • キーベースの認可の場合、API キーと修飾されたエンドポイントによってアクセスが決定されます。 エンドポイントはサービス自体、インデックス コレクション、特定のインデックス、ドキュメント コレクション、特定のドキュメントなどである場合があります。 連結されている場合、エンドポイント、操作 (作成要求など)、キーの種類 (管理者またはクエリ) によってコンテンツへのアクセスと操作が承認されます。

インデックスへのアクセスの制限

Azure ロールを使用している場合は、プログラムによって実行される限り、個々のインデックスに対するアクセス許可を設定できます。

キーを使用すると、サービスに対する管理者キーを持っている人は誰でも、そのサービスのインデックスの読み取り、変更、削除を行えます。 インデックスが誤って削除されたり、悪意によって削除されたりすることを防止するうえで、コード資産の社内ソース管理は、望ましくないインデックスの削除または変更を元に戻すための解決策になります。 Azure AI Search は可用性を確保するためにクラスター内のフェールオーバーを備えていますが、インデックスの作成または読み込みに使用される専用コードを格納したり実行したりしません。

インデックス レベルでセキュリティ境界を必要とするマルチテナント ソリューションの場合、通常、アプリケーション コードの中間層でインデックス分離を処理します。 マルチテナントのユース ケースの詳細については、「マルチテナント SaaS アプリケーションと Azure AI Search の設計パターン」を参照してください。

ドキュメントへのアクセスの制限

"行レベル セキュリティ" とも呼ばれるドキュメント レベルのユーザー アクセス許可は、Azure AI Search でネイティブにはサポートされていません。 Azure Cosmos DB など、行レベル セキュリティを提供する外部システムからデータをインポートする場合、Azure AI Search によってインデックス付けされているため、そのようなアクセス許可はデータと共に転送されません。

検索結果のコンテンツに対するアクセス許可が必要な場合、ユーザー ID に基づいてドキュメントを含めるか、除外するフィルターを適用する手法があります。 この回避策では、グループまたはユーザー ID を表す文字列フィールドをデータ ソースに追加します。このフィールドは、インデックスでフィルター可能にできます。 このパターンの詳細については、「ID フィルターに基づくセキュリティ トリミング」を参照してください。

データの保存場所

検索サービスを設定するときに、顧客データがどこで格納および処理されるかを決定するリージョンを選びます。 各リージョンは、多くの場合、複数のリージョンを含む地理的な場所 (Geo) 内に存在します (たとえば、スイスはスイス北部とスイス西部を含む Geo です)。 Azure AI 検索では、持続性と高可用性のために、同じ Geo 内の別のリージョンにデータをレプリケートする場合があります。 構成した機能が別の Azure リソースに依存し、そのリソースが別のリージョンにプロビジョニングされている場合を除き、指定した Geo の外部で顧客データがサービスによって格納されたり、処理されることはありません。

現在、検索サービスが書き込む唯一の外部リソースは Azure Storage です。 ストレージ アカウントは、お客様が指定したストレージ アカウントであり、任意のリージョンに存在する可能性があります。 次のいずれかの機能を使用する場合、検索サービスによって Azure Storage への書き込みが行われます。

データ所在地の詳細については、「Azure でのデータ所在地」を参照してください。

データ所在地のコミットメントに対する例外

オブジェクト名は、Microsoft がサービスのサポートを提供するために使うテレメトリ ログに表示されます。 オブジェクト名は、選択されたリージョンまたは場所以外で格納され、処理されます。 オブジェクト名には、インデックスとインデックス フィールド、エイリアス、インデクサー、データ ソース、スキルセット、シノニム マップ、リソース、コンテナー、キー コンテナー ストアの名前が含まれます。 お客様は、名前のフィールドに機密データを配置することや、これらのフィールドに機密データが格納されるように設計したアプリケーションを作成することはできません。

テレメトリ ログは 1 年半保持されます。 その間、Microsoft は次の条件下でオブジェクト名にアクセスして参照する場合があります。

  • 問題の診断、機能の改善、バグの修正を行います。 このシナリオでは、データ アクセスは内部のみであり、サード パーティがアクセスすることはありません。

  • サポート中、問題への迅速な解決策を提供し、必要に応じて製品チームを昇格させるために、この情報が使用される場合があります

データ保護

ストレージ層には、インデックスやシノニム マップ、およびインデクサー、データ ソース、スキルセットの定義など、ディスクに保存されるすべてのサービス マネージド コンテンツに対するデータ暗号化が組み込まれています。 サービス マネージド暗号化は、長期データ ストレージと一時データ ストレージの両方に適用されます。

必要に応じて、インデックス付きコンテンツの補足暗号化用にカスタマー マネージド キー (CMK) を追加し、保存データの二重暗号化を行うことができます。 2020 年 8 月 1 日以降に作成されたサービスでは、CMK 暗号化は一時ディスクの短期データにも拡張されています。

転送中のデータ

パブリック インターネット経由の検索サービス接続の場合、Azure AI 検索では HTTPS ポート 443 がリッスンされます。

Azure AI 検索では、クライアントからサービスへのチャネル暗号化のために TLS 1.2 と 1.3 がサポートされています。

以前のバージョン (1.0 または 1.1) の TLS はサポートされていません。

詳細については、「.NET Framework での TLS サポート」を参照してください。

保存データ

検索サービスによって内部で処理されるデータについて、次の表でデータ暗号化モデルを説明しています。 ナレッジ ストア、インクリメンタル エンリッチメント、インデクサー ベースのインデックス作成などの一部の機能は、他の Azure サービスのデータ構造から読み書きされます。 Azure Storage に依存するサービスでは、そのテクノロジの暗号化機能を使用できます。

モデル キー 必要条件 制限 適用対象
サーバー側暗号化 Microsoft のマネージド キー なし (組み込み) なし。2018 年 1 月 24 日以降に作成されたコンテンツについては、すべてのリージョンのすべての階層で使用できます。 データ ディスクおよび一時ディスク上のコンテンツ (インデックスとシノニム マップ) と定義 (インデクサー、データ ソース、スキルセット)
サーバー側暗号化 カスタマー マネージド キー Azure Key Vault 2020 年 8 月 1 日以降に作成されたコンテンツについては、特定のリージョンの請求対象階層で使用できます。 データ ディスク上のコンテンツ (インデックスとシノニム マップ)
サーバー側の完全暗号化 カスタマー マネージド キー Azure Key Vault 2021 年 5 月 13 日以降の検索サービスについては、すべてのリージョンの請求対象階層で使用できます。 データ ディスクおよび一時ディスク上のコンテンツ (インデックスとシノニム マップ)

サービス マネージド キー

サービス マネージド暗号化とは、256 ビット AES 暗号化を使用する Microsoft 内部操作です。 (2018 年 1 月より前に作成された) 完全に暗号化されていないインデックスに対する増分更新を含む、すべてのインデックス作成で自動的に行われます。

サービス マネージド暗号化は、長期および短期ストレージ上のすべてのコンテンツに適用されます。

カスタマー マネージド キー (CMK)

カスタマー マネージド キーには、Azure Key Vault という別の請求対象のサービスが必要です。これのリージョンは別であってもかまいませんが、Azure AI Search と同じサブスクリプションのものである必要があります。

CMK のサポートは、2 つのフェーズでロールアウトされました。 最初のフェーズで検索サービスを作成した場合、CMK 暗号化は長期ストレージと特定のリージョンに制限されていました。 2021 年 5 月以降の 2 番目のフェーズで作成されたサービスでは、任意のリージョンで CMK 暗号化を使用できます。 2 番目のウェーブのロールアウトの一環として、コンテンツは長期ストレージと短期ストレージの両方で CMK 暗号化されます。 CMK のサポートの詳細については、「完全二重暗号化」を参照してください。

CMK での暗号化を有効にすると、インデックスのサイズが増加し、クエリのパフォーマンスが低下します。 これまでの観測に基づくと、実際のパフォーマンスはインデックスの定義やクエリの種類によって異なりますが、クエリ時間が 30 から 60 パーセント増加することが予想されます。 パフォーマンスへの悪影響があるため、この機能を本当に必要とするインデックスでのみ有効にすることをお勧めします。 詳細については、Azure AI Search でのカスタマー マネージド暗号化キーの構成に関するページを参照してください。

セキュリティと管理

API キーを管理する

API キーベースの認証に依存するということは、Azure のセキュリティのベスト プラクティスに従って、定期的に管理者キーを再生成するための計画を立てる必要があることを意味します。 Search サービスごとに最大 2 個の管理キーがあります。 API キーのセキュリティと管理の詳細については、API キーの作成と管理に関する記事を参照してください。

アクティビティとリソースのログ

Azure AI Search では、ユーザー ID はログに記録されないため、特定のユーザーに関する情報のログを参照することはできません。 ただし、このサービスでは、ログの作成、読み取り、更新、削除の各操作がログに記録されるため、これらのログを他のログと関連付けて、特定のアクションの機関を理解できる場合があります。

Azure でアラートとログ記録インフラストラクチャを使用すると、クエリ ボリュームの急増や、予想されるワークロードから逸脱したその他のアクションを検出できます。 ログの設定の詳細については、ログ データの収集と分析およびクエリ要求の監視に関する記事を参照してください。

認定資格とコンプライアンス

Azure AI Search は通常の監査に参加し、パブリック クラウドと Azure Government の両方について、グローバル、リージョン、および業界固有のさまざまな標準に対して認定を受けています。 完全な一覧については、公式の監査レポート ページから Microsoft Azure Compliance Offerings ホワイトペーパーをダウンロードしてください。

コンプライアンスのために、Microsoft クラウド セキュリティ ベンチマークの安全性の高いベスト プラクティスを、Azure Policy を使用して実装できます。 Microsoft クラウド セキュリティ ベンチマークは、サービスやデータに対する脅威を軽減するために実行する必要のある主要なアクションにマップされる、セキュリティ コントロールに体系化された、セキュリティに関する推奨事項を集めたものです。 現在は、ネットワーク セキュリティ、ログ記録および監視、データ保護などを含む 12 のセキュリティ コントロールがあります。

Azure Policy は、Microsoft クラウド セキュリティ ベンチマークの標準を含む複数の標準に対するコンプライアンスの管理に役立つ、Azure に組み込まれた機能です。 広く知られたベンチマークについては、コンプライアンス非対応の場合に使用できる、基準と実施可能な対応の両方の組み込みの定義が、Azure Policy によって提供されています。

Azure AI Search には、現在 1 つの定義が組み込まれています。 これはリソース ログ用です。 リソース ログが欠落している検索サービスを識別するポリシーを割り当てて、有効にできます。 詳細については、「Azure AI Search 用の Azure Policy 規制コンプライアンス コントロール」を参照してください。

このビデオを観る

セキュリティ アーキテクチャと各機能カテゴリの概要については、こちらのビデオをご覧ください。

関連項目