Secure an Azure AI Search service

This article provides security best practices to help protect your Azure AI Search service. You're responsible for implementing these customer-configurable security controls. For information about Microsoft's built-in protections, such as network architecture, encryption, and compliance certifications, see Data, privacy, and built-in protections in Azure AI Search.

As a solutions architect, you should configure security controls across three domains:

• Network security: Control inbound and outbound traffic to your search service.
• Authentication and authorization: Define how, who, and what can access your search service and data.
• Data protection: Implement encryption, access controls, and monitoring.

Understand network traffic patterns

Before you configure network security, understand the three network traffic patterns in Azure AI Search:

• Inbound traffic: Requests from clients to your search service, such as queries, indexing, and management operations. This traffic is configurable by customers.

• Outbound traffic: Requests from your search service to external resources, such as indexers that connect to data sources, vectorizers, and custom skills. This traffic is configurable by customers.

• Internal traffic: Service-to-service calls over the Microsoft backbone network. This traffic is managed by Microsoft and isn't configurable by customers. For more information, see Internal traffic protection.

Configure network security

Use one of the following approaches to restrict inbound access to your search service. These approaches are listed from least secure to most secure:

• Create IP firewall rules
• Create a private endpoint
• Join a network security perimeter

Create IP firewall rules

Create inbound firewall rules to admit requests only from specific IP addresses or address ranges. All client connections must be made through an allowed IP address. Otherwise, the connection is denied.

When to use: Basic protection scenarios where you need to restrict access to known IP addresses.

How to get started: See Configure network access and firewall rules for Azure AI Search.

Create a private endpoint

Create a private endpoint for Azure AI Search to allow clients on a virtual network to securely access data in a search index over a Private Link. The private endpoint uses an IP address from your virtual network address space.

Network traffic between the client and the search service traverses over the virtual network and a private link on the Microsoft backbone network, eliminating exposure from the public internet.

When to use: High-security scenarios requiring complete network isolation from the public internet.

How to get started: See Create a private endpoint for Azure AI Search.

Join a network security perimeter

Create a network security perimeter around your platform-as-a-service (PaaS) resources deployed outside of a virtual network to establish a logical network boundary. This establishes a perimeter that controls public network access through explicit access rules.

Inbound client connections and service-to-service connections occur within the boundary, simplifying defenses against unauthorized access. In Azure AI Search, it's common for solutions to use multiple Azure resources.

When to use: Solutions using multiple Azure PaaS resources that need coordinated network boundary protection.

How to get started:

• Start by joining Azure AI Search to a network security perimeter. See Add a search service to a network security perimeter.

• Add related services, such as Azure OpenAI, Azure Storage, and Azure Monitor, to the same perimeter.

Configure authentication and authorization

Azure AI Search supports two authentication approaches. You can use one approach and disable the other, or you can use both with appropriate controls.

(Recommended) Enable role-based access control

Use Microsoft Entra authentication to establish the caller, rather than the request, as the authenticated identity. Azure role assignments determine authorization, providing centralized identity management, conditional access policies, and comprehensive audit trails.

The workflow for role-based access control is:

1. Enable role-based access control: Configure your search service to accept Microsoft Entra ID authentication instead of (or in addition to) API keys. See Enable or disable role-based access control in Azure AI Search.

2. Assign roles to users and groups: Grant least-privilege access using built-in roles (Search Service Contributor, Search Index Data Contributor, and Search Index Data Reader) to control who can manage and query indexes. See Connect to Azure AI Search using roles.

3. Connect your application using identities: Authenticate without API keys by using DefaultAzureCredential, which supports managed identities, developer credentials, and other token-based flows. See Connect your app to Azure AI Search using identities.

Configure API key authentication

With key-based authentication, each request must include an admin or query API key to prove it originates from a trusted source. This approach is suitable for development environments, backward compatibility with existing applications, or scenarios where Microsoft Entra ID isn't available.

The workflow for key-based authentication is:

1. Provide an API key in each request: Admin keys grant full access to all operations. Query keys grant read-only access to the documents collection of an index. See Connect to Azure AI Search using keys.

2. Rotate admin keys on a schedule: Reduce the risk of key compromise by regularly regenerating admin keys. Search services support two admin keys for zero-downtime rotation. See Regenerate admin keys.

Authorize control plane operations

Control plane operations (service creation, configuration, and deletion) are authorized through Azure Resource Manager role-based access control, the same model used across all Azure services. API keys don't apply to control plane operations. Three built-in Azure roles govern access:

The workflow for authorizing control plane operations is:

1. Assign administrative roles: Use built-in Azure roles (Owner, Contributor, and Reader) to grant least-privilege access and control who can create, configure, or delete search services. See Assign roles for service administration.

2. Apply resource locks: Prevent accidental deletion of production search services by applying CanNotDelete or ReadOnly locks. See Lock your Azure resources to protect your infrastructure.

Authorize data plane operations

Data plane operations target content hosted on a search service, such as index creation, document loading, and queries. Authorization is available through role-based access control, API keys, or both. For configuration steps, see the previous sections on role-based access control and API key authentication.

Grant access to individual indexes

Restrict user access to individual indexes by creating custom role definitions. This approach is essential for multi-tenant scenarios where each tenant's data must be isolated at the index level. See Grant access to a single index.

For solutions requiring security boundaries at the index level, see Design patterns for multitenant SaaS applications and Azure AI Search.

Configure outbound connections

Outbound requests originate from a search service to other applications, typically made by indexers, custom skills, and vectorizers. Configure these connections to use secure authentication and network access.

(Recommended) Use a managed identity

Create a managed identity for your search service to authenticate to other Azure resources without storing credentials in your code. A managed identity eliminates the need to store and rotate connection strings with credentials.

The workflow for using a managed identity is:

1. Configure a managed identity for the search service: Choose between a system-assigned or user-assigned managed identity. See Configure a search service to connect using a managed identity.

2. Connect to external resources using the managed identity: Supported connections include Azure Storage, Azure Cosmos DB, Azure SQL Database, SQL Managed Instance, and Azure Functions.

Secure access to external data

Configure secure connections based on how external resources are protected:

• Create firewall exceptions for the search service: Allow indexer traffic through data source firewalls by adding the search service's outbound IP addresses to allowlists. See Configure IP firewall rules to allow indexer connections from Azure AI Search.

• Create shared private links: Connect indexers to data sources protected by Azure Private Link without exposing traffic to the public internet. See Make outbound connections through a shared private link.

• Use trusted service exception for same-region storage: Enable indexer access to secured Azure Storage accounts in the same region without firewall configuration. See Make indexer connections to Azure Storage as a trusted service.

• Configure resource instance rules: Grant specific search services access to Azure Storage accounts protected by network rules. See Grant access from Azure resource instances.

• Connect to SQL Managed Instance private endpoints: Access SQL Managed Instance databases through private endpoints while maintaining network isolation. See Create a shared private link for a SQL managed instance from Azure AI Search.

Secure connections for external AI processing

Outbound requests for AI enrichment and vectorization require special consideration:

For basic retrieval-augmented generation (RAG) patterns where your client application calls a chat completion model, the connection uses the client or user identity, not the search service identity. For agentic retrieval using knowledge bases, the outbound request is made by the search service managed identity.

Implement document-level access control

User permissions at the document level, also known as row-level security, control which documents users can access through query execution.

Configure document-level security

Configure fine-grained permissions at the document level, from data ingestion through query execution. This capability is essential for building secure AI agentic systems grounding data, RAG applications, and enterprise search solutions that require authorization checks at the document level. For more information, see Document-level access control.

Use sensitivity labels (preview)

Configure an indexer to automatically detect Microsoft Purview sensitivity labels during indexing and apply label-based access controls when queries are executed. For more information, see Sensitivity labels.

Configure data encryption

Azure AI Search encrypts all data automatically using Microsoft-managed keys. For information about built-in encryption, see Data encryption.

For enhanced data protection, you can implement the following encryption controls.

(Optional) Add customer-managed key encryption

Add an extra encryption layer for indexes and synonym maps by managing your own encryption keys in Azure Key Vault. Customer-managed keys (CMK) are for organizations with compliance requirements mandating customer control over encryption keys or key revocation capabilities. See Configure customer-managed keys for data encryption in Azure AI Search.

You can also configure the following options:

• Configure cross-tenant CMK: Support multi-tenant scenarios where keys are stored in a different Microsoft Entra tenant than the search service. See Configure customer-managed keys across different tenants.

• Find encrypted objects: Identify which indexes and synonym maps use CMK encryption. See Find encrypted objects and information.

Index encrypted blob content

Configure an indexer to process content from Azure Blob Storage that's encrypted at rest, which is separate from CMK encryption of the search index. See Tutorial: Index and enrich encrypted blobs.

(Optional) Enable confidential computing

Confidential computing protects data in use from unauthorized access, including from Microsoft, through hardware attestation and encryption. This compute type is only configurable during service creation. See Choose a compute type.

We only recommend confidential computing for organizations whose compliance or regulatory requirements necessitate data-in-use protection. For daily usage, the default compute type suffices.

¹ When you enable this compute type, indexers can only run in the private execution environment, meaning they run from the search clusters hosted on confidential computing.

Enable monitoring and logging

Track operations, detect anomalies, and support security audits by enabling logging and monitoring for your search service. For information about what Azure AI Search logs by default, see Data logging.

• Enable diagnostic logging: Capture operations for security audits and anomaly detection by sending logs to Azure Monitor, Event Hubs, or Azure Storage. See Configure diagnostic logging for Azure AI Search.

• Monitor queries: Track search query activity, latency, and throttling to detect unusual patterns. See Monitor query requests in Azure AI Search.

• Monitor indexer operations: Track indexing activity, errors, and data refresh operations. See Monitor indexer status and results in Azure AI Search.

• Configure alerts for anomalous activity: Create alert rules for query volume spikes, failed authentication attempts, and unusual access patterns. See Create or edit a metric alert rule.

• Visualize logs using Power BI: Build dashboards to analyze search service activity and identify security trends. See Visualize Azure AI Search logs and metrics with Power BI.

Maintain compliance

For information about Azure AI Search compliance certifications and the shared responsibility model, see Compliance and certifications.

Use Azure Policy

• Review built-in policy definitions: Use Azure Policy to audit and enforce security configurations such as diagnostic logging and private endpoint usage. See Azure Policy Regulatory Compliance controls for Azure AI Search.

• Assign the resource logging policy: Automatically identify search services missing diagnostic logging and remediate the configuration. See Azure Policy overview.

• Create custom policies: Define organization-specific security requirements and enforce them across all search services. See Tutorial: Create a custom policy definition.

Apply resource tags

Apply resource tags to categorize search services by environment, data sensitivity, cost center, or compliance requirements for improved governance. See Use tags to organize your Azure resources and management hierarchy.

Security checklist

Use this checklist to ensure you've configured appropriate security controls:

Network security:

• [ ] Configured IP firewall rules, private endpoint, or network security perimeter
• [ ] Restricted inbound access to known clients or networks
• [ ] Configured secure outbound connections using managed identities

Authentication and authorization:

• [ ] Enabled role-based access control
• [ ] Assigned appropriate roles to users and applications
• [ ] Implemented admin key rotation schedule (if using keys)
• [ ] Configured index-level permissions (if required)

Data protection:

• [ ] Configured document-level access control (if required)
• [ ] Configured sensitivity labels (if applicable)
• [ ] Implemented CMK encryption (if required)
• [ ] Evaluated confidential computing requirements (if applicable)

Monitoring and compliance:

• [ ] Enabled diagnostic logging
• [ ] Set up monitoring and alerts to identify anomalous activity
• [ ] Applied resource tags for governance
• [ ] Assigned Azure Policy for resource logging
• [ ] Reviewed compliance certifications against requirements

Related content

• Data, privacy, and built-in protections in Azure AI Search
• Azure security fundamentals
• Shared responsibility in the cloud