Maintain an Azure AI Search Solution (Part 2)

 



Authenticate Requests To Your Search Solution

Your attention may go to how to verify search requests from your users and apps once you have the infrastructure in place to lessen the attack surface of your search solution.

Key-based authentication is the default setting when you set up your ACS. There are two different kinds of keys:

  • Admin Keys - grant write permissions and the right to query system information (maximum of 2 admin keys can be created per search service)

  • Query Keys - grant read permissions and are used by your users or apps to query indexes (maximum of 50 query keys can be created per search service)

Role-based access control (RBAC) is provided by the Azure platform as a global system to control access to resources. You can use RBAC in Azure AI Search in the following ways:

  1. Roles can be granted access to administer the service
  2. Define roles with access to create, load, and query indexes

The built-in roles you can assign to manage the Azure AI Search service are:

  1. Owner - Full access to all search resources
  2. Contributor - Same as above, but without the ability to assign roles or change authorizations
  3. Reader - View partial service information

If you need a role that can also manage the data plane for example search indexes or data sources, use one of these roles:

  • Search Service Contributor - A role for your search service administrators (the same access as the Contributor role above) and the content (indexes, indexers, data sources, and skillsets).

  • Search Index Data Contributor - A role for developers or index owners who will import, refresh, or query the documents collection of an index Search Index.

  • Data Reader - Read-only access role for apps and users who only need to run queries.

Secure Outbound Traffic

Usually, your outbound traffic uses artificial intelligence (AI) to enhance or index source data. Key-based authentication, database logins, or Microsoft Entra logins, if you are able to use Microsoft Entra ID, are supported for outgoing connections.

You can also use a system or user-assigned managed identity to safeguard connections if your data sources are housed on the Azure platform.  A firewall can be used to limit access to Azure services. You can set up your firewall to just permit the Azure AI Search service's IP address. If you're enriching your indexes with AI, you'll also need to allow all the IP addresses in the AzureCognitiveSearch service tag.

Your indexers may use a shared private link to secure your source data.

Secure Data At Document-Level

You can configure Azure AI Search to restrict the documents someone can search, for example, restrict searching contractual PDFs to people in your legal department. You must update every document in your search index in order to restrict access at the document level.

You need to add a new security field to every document that contains the user or group IDs that can access it. In order to filter search results on the security field, it must be filterable. With this field in place and populated with the allowed user or groups, you can restrict results by adding the search.in filter to all your search queries.

This would filter the returned search results on the user ID and groups that this user belongs to. If your application can use Microsoft Entra ID, it's possible to use the user's identity and group memberships from there.

Conclusion

We have successfully learnt about authentication and securing data at document level.




























Comments

Popular posts from this blog

Connect Data to Azure Sentinel Using Data Connectors

Information Protection Scanner: Resolve Issues with Information Protection Scanner Deployment

Azure AI Search plugin in Microsoft Security Copilot (Preview)