Secure your Azure AI resources before it's too late
AI is everywhere at the minute, and everyone is trying to develop a way to implement AI in their products or workflows. Azure’s open AI services are a great way to do this, but because they’re so easy to deploy and use, you can end up with a proliferation of AI services. The default security settings for these resources are often set up for convenience and ease of use, rather than locking down your precious data and IP. Hence, it’s worth understanding how to secure these resources and make your environments more secure. With the proliferation and popularity of AI services, they will become prime targets for attacks.
Policy Restrictions
One of the most significant risks we face is uncontrolled, unsecured instances of AI services being deployed by teams within your organisations. If you have tight control or limited access to your Azure subscriptions, this might be fine, but if your various teams are empowered to deploy their own resources (which is no bad thing), this becomes a risk.
You may want to set up Azure policies that block the deployment of specific AI resources altogether and have everyone use shared AI infrastructure managed by the IT team. Alternatively, you can implement policies that allow teams to deploy their own AI instances but enforce some of the security constraints we detail in the rest of this document.
Networking
By default, many Azure AI services are accessible from any network. Azure Open AI is a perfect example of this. There are very few use cases where something like Azure Open AI needs to be accessible from any network; most of the time, access is required only from inside your Azure networks or your on-premises network. Your application services may talk to the Azure Open AI service as part of a request from the internet, but this does not require them to be directly accessible and will usually sit behind an API.
AI services should be configured with Private Endpoints to restrict access to Azure networks (and connected on-prem networks) and any other access method disabled. If Private Endpoints cannot be used, service endpoints/IP Allow Lists should be used. Public network access should be disabled.
Some private endpoint configurations for Azure Open AI currently require manually completing forms to have MS enable this for you. It is expected that this will go away in the near future.
Authentication
Many Azure AI services support Entra ID and API Key-based authentication by default. API Key-based authentication is much more insecure as it relies on a key being shared between services, and that key does not identify who is calling the service. API Key Authentication should be turned off for production services.
Disabling API key authentication will stop the Azure Open AI Studio UI from working, as this does not currently support Entra ID auth. Generally, studio access should not be needed in production, but you may want to operate a separate development environment that supports API key auth if your developers need this access. This key should be rotated regularly, ideally through automation.
Where applications or other Azure services need to access the Azure AI services, this should be done via managed identity and access configured using Azure RBAC.
Data
Most Azure AI services now support Data Loss Prevention configurations that can prevent these services from calling out to external URLs. This should be enabled where possible. However, there are some limitations on where these can be used, especially if you use the “bring your own data” functionality.
Encryption of data at rest and in transit is done automatically by most AI services. However, it is possible to implement “bring your own key” for encryption, which you may want to consider if your data is sensitive. This key must be stored in Azure Key Vault.
Monitoring
Most Azure AI services can be configured to send diagnostic data to Azure Monitor and Log Analytics; this is useful for developers but also from a security perspective to monitor what your services are doing. This is not enabled by default, so consider collecting it.
An attacker doesn’t necessarily need to get hold of some admin credentials to cause problems. Most AI services operate on a per-request or per-token pricing model, so usage of the service is what drives the cost. Some of these services can be expensive, especially if using newer models like GPT4. If an attacker can manage to send requests to your AI service, they can send large volumes of requests to increase your costs. Monitoring usage and cost can help detect this kind of attack before it escalates too far.
Summary
The standard deployments of most AI services attempt to find a balance between ease of use and security. This may be OK for those just getting started, but with the amount of sensitive data and intellectual property going into some AI services, it is essential that these services are locked down and as secure as possible.
As Azure AI services grow and evolve, I am sure that more security controls will be added to make this process easier.
