In the dynamic realm of artificial intelligence, the fusion of Microsoft’s Azure cloud services with OpenAI’s advanced models is essential for technology development as it combines the scalability and security of Azure’s cloud infrastructure with the power and capabilities of OpenAI’s models. Not Open AI itself. This blog delves into the cybersecurity aspects of the Azure and OpenAI collaboration, unveiling how the convergence of artificial intelligence and cloud computing heralds a transformative future.
As digital interconnectivity complicates the cybersecurity landscape, Azure stands as a bulwark, enabling enterprises to leverage cloud capabilities securely. Nevertheless, the validity of existing security measures in the context of AI warrants scrutiny. A foundational understanding of the service’s functionalities is essential for a comprehensive security assessment.
Overview
The Azure OpenAI Service facilitates access to OpenAI’s potent language models through REST APIs, Python SDK, or Azure OpenAI Studio. The available models, including GPT-4 and GPT-4 Turbo, GPT-3.5, Embeddings, DALL-E, and Whisper, cater to varied needs, with some premium options offering enhanced service quality. Pricing correlates with token usage and adheres to a rate limit and quota system detailed in Microsoft’s documentation (https://learn.microsoft.com/en-us/azure/ai-services/openai/). The service supports multiple programming languages, including C#, Go, Java, JavaScript, and Python.
Key Concepts
Key to the Azure Open AI service is Provisioned Throughput Units (PTUs), which denote the model processing capacity. These are intrinsically linked to quota management; exceeding rate limits triggers a 429 error, indicative of service interruption and a potential vector for DoS attacks, as exemplified in the provided image.
Azure OpenAI service provisioning, showing how as deployment utilization rises, capacity is gauged through utilization.
Another important concept is the content filtering system, aimed at detecting and preventing the output of harmful content. It detects and takes action on specific categories of potentially harmful content in both input prompts and output completions. The models filter harm categories such as hate and fairness, sexual, violence, self-harm, jailbreak risk (provoke AI to exhibit behaviors it was trained to avoid) and protected material (text and code). It is essential to thoroughly test these areas for potential vulnerabilities to prevent any possible loss of data integrity. Each of these categories has severity levels such as safe, low, medium, and high. In the official guide, each of these categories is detailed, including specific examples presented in tables for each severity level. By default, medium and high levels are filtered; however, clients can configure this, making it crucial for testers to verify and prevent potential negative impacts on the security of the AI application.
The guide addresses the topic of prompt engineering, referring to the importance of providing clear instructions to the AI, with explicit examples of usage. Similarly, the concept of fine-tuning is mentioned to describe the idea of adapting AI to the specific needs of each client or business. This is supervised by Azure Open AI and refers to the process of refining pre-trained models using specific datasets, to enhance model performance in particular tasks. Despite the allure, one must be cautious because there can be adverse effects on security if used improperly. If the fine-tuned model retains fragments of the sensitive data, it could pose a risk leading to data leakage. Membership inference attacks allow an adversary to determine if a particular data point was part of the model’s training set. Finally, manipulation of input data may lead the model to include inaccuracies.
Main differences between Open AI and Open AI on Azure
The following image shows some distinctions between OpenAI and its Azure integration.
Ensuring Security in Data Integration
When using the Azure OpenAI Service, the prompts, completions, embeddings, and training data are not shared with other customers, and not utilized to enhance OpenAI models or 3rd party products (unless explicitly fine-tuning models, which are exclusively available for client’s use). The following image shows the three stages of how the data is processed: processing prompts to generate content, creating a fine-tuned model, then analyzes inputs for harmful content.
As the models are stateless, no prompts or generations are stored in the model. Additionally, prompts and generations are not used to train, retrain, or improve the base models. When a user prompt is received, the service retrieves relevant data from the connected data source and augments the prompt. The model processes this augmented prompt and the generated content is returned as described in the next image.
In addition to illustrating the process of integrating the Azure Cognitive Search feature, the images show how customers can apply to modify the content abuse monitoring. This is an essential feature for the security of the application. Ideally, this parameter should be turned on to avoid potential risks during interactions with end users. However, depending on the needs of the customers, it may be necessary to turn it off. This involves the processing of sensitive, highly confidential, or legally-regulated input data which opens the door to harmful outputs or misuse by malicious actors. This can be verified by executing the following command in Azure CLI:
az cognitiveservices account show -n resource\_name -g resource \_group
Which will show in JSON format something like this:
{
“name”:”ContentLogging”,
“value”:”false”
}
The Official Guide explains how additional guardrails can be set, templates established, and also how to integrate this service with Azure ML Prompt Flow. This allows for the creation of flows to specify the behavior of the chatbot and add the paths desired in the interaction with users. When integrating these features, it is crucial to always ensure the security of the application, leaving no room for vulnerabilities such as membership inference or model inversion (for the fine-tuned model).
Finally, here one can find a complete guide on how to use OpenAI securely and protect data. In it, one can find relevant information on Data Ingestion and Inference Architecture, including a step-by-step diagram on how to ingest data from Azure Blob Storage or local files in a secure way. It also shows how to create a virtual network and resource groups, as well as configuring or enabling properties such as managed identity, trusted services, role-based access control on Azure OpenAI and AI Search. Additionally, one can find a guide to disable public network access and configuring storage account, gateway and client VPNs.
Final Remarks
The alliance between Azure and OpenAI is a beacon of innovation, blending robust cloud infrastructure with groundbreaking AI technologies. As the digital horizon expands, the imperative for uncompromised security becomes apparent. The thorough understanding and testing of these systems are not optional but a necessity to maintain a resilient and secure foundation for future advancements. By unraveling the complexities, we empower ourselves to navigate the digital terrain with confidence, aware of the protective measures that safeguard our endeavors.
