Securing Azure Open AI apps in the Enterprise

Securing Azure Open AI apps in the Enterprise

Speakers: Karl Ots

Conference: BSidesSF 2024

YouTube: https://www.youtube.com/watch?v=eA1ym40CnlU

Overview

This talk, presented by Karl Ots at BSidesSF 2024, delves into the critical and often complex task of securing Azure OpenAI applications within an enterprise environment. As a consultant specializing in cloud and security, with a recent focus on AI, Ots shares lessons learned from a real-world engagement with a large banking organization. The core of the presentation addresses the challenges faced when integrating a rapidly adopted, "generally available" generative AI service into a highly regulated and continuously audited corporate infrastructure.

The session highlights the significant gap between the perceived readiness of new AI services and the stringent security requirements of large enterprises. Ots outlines a structured approach to evaluating and implementing security controls for Azure OpenAI, drawing parallels with established Azure services while exposing the unique complexities and undocumented features specific to this nascent technology. The talk is particularly relevant for security professionals, cloud architects, and compliance officers grappling with the rapid adoption of generative AI and the need to ensure its secure deployment in production.

Background

▶ Watch: Introduction: Securing Azure OpenAI for a large banking enterprise. (0:00)

The impetus for this talk stems from a specific experience approximately a year prior, following the public release of ChatGPT and Microsoft's subsequent rapid rollout of its own Azure OpenAI service, labeled as "generally available." Karl Ots was engaged by a large banking organization—a typically slow-moving entity known for its meticulous, "not invented here" approach to technology adoption—which, surprisingly, embraced generative AI with unprecedented speed. The client, assured by Microsoft's "general availability" and "great security story," expected a swift integration, anticipating only "a few Sprints" or "a couple of weeks" to secure the new service.

Ots, leveraging his extensive background in Azure projects, initially approached the task with confidence, only to discover a landscape far more intricate than anticipated. The core problem revolved around the immaturity of enterprise-grade security features for Azure OpenAI at the time, coupled with the client's urgent need for compliance and control.

The talk begins by outlining the different hosting models for generative AI, specifically contrasting ChatGPT (a Software-as-a-Service, or SaaS, offering) with Azure OpenAI (a Platform-as-a-Service, or PaaS, offering). Ots introduces the concept of a shared responsibility matrix for AI services, analogous to the well-known cloud shared responsibility model, where control shifts from the vendor to the customer as one moves from SaaS to PaaS and ultimately to self-hosted Infrastructure-as-a-Service (IaaS) models.

While ChatGPT offers free and "plus" versions, and an "Enterprise" tier with claims of enhanced features like SSO integration and domain allow listing, Ots expresses skepticism about some of its security claims, particularly regarding "encryption at rest" for non-Enterprise versions, given its underlying Azure Kubernetes Service and Cosmos DB infrastructure. For enterprises requiring granular control over data residency (e.g., for European or Asian environments), network isolation, and customer-managed keys (CMK), Azure OpenAI emerges as the clear choice, despite its own set of security challenges.

Ots's plan for securing Azure OpenAI involved a systematic approach, starting with understanding the available hosting models, integrating the service into the client's existing Azure environment (including sandboxing and production landing zones), and ensuring continuous auditability. His primary tool for this evaluation was the Microsoft Cloud Security Benchmark (MCSB), a framework designed to consolidate various external security requirements (e.g., CIS controls) into actionable technical controls and documentation for Azure services. This benchmark, in theory, should provide a clear path for compliance and security hardening.

Key Findings

▶ Watch: Microsoft Cloud Security Benchmark: Initial lack of coverage for Azure OpenAI. (8:00)

The speaker's deep dive into securing Azure OpenAI revealed several critical findings, highlighting both the progress and the persistent challenges in integrating this cutting-edge technology into enterprise environments:

• MCSB Maturity Gap: A significant initial finding was the absence of Microsoft Cloud Security Benchmark (MCSB) controls and documentation for Azure OpenAI for the first 10 months after its general availability. While now available, the coverage is still limited, with only 7 controls provided by Microsoft and 35 client-responsible controls. Many of these controls are generic Azure features, not specific to the unique aspects of AI services.
• Limited Specificity in Controls: Several MCSB controls for Azure OpenAI were found to be either redundant or lacking specificity. For instance, Key Vault integration was split into two controls, and a third for customer-managed keys (CMK), which could arguably be consolidated. Generic controls like resource logs are always on by default in Azure, making their inclusion as a specific AI service control less impactful.
• Network Security Nuances:
• Inbound Control (Resource Firewall): While configurable, the "resource firewall" is essentially an Access Control List (ACL), not a full-fledged firewall. It allows for restricting access based on virtual networks and IP address ranges, which are cumulative. A key concern raised was the need for diligent auditing to prevent unintended access, such as from consultants' home office IP addresses.
• Outbound Control (Data Exfiltration Prevention / DLP): A critical feature for preventing data exfiltration, termed "restricted outbound network access" or "DLP feature," exists as an FQDN allow list. This list can contain up to 1,000 fully qualified domain names that the Azure OpenAI instance is permitted to communicate with. However, this feature lacks a UI or SDK, requiring configuration solely via the REST API. Crucially, there are no audit logs for failed outbound attempts, making it difficult to verify its effectiveness or troubleshoot issues. This limitation was highlighted with a "burning cloud platform" icon, signifying a significant concern.
• Encryption at Rest Ambiguity: While Microsoft-managed keys (MMK) provide default encryption and customer-managed keys (CMK) can be integrated via Azure Key Vault, the speaker noted a lack of clear public information on what exactly is encrypted. Uncertainty remains whether it covers the entire cluster, runtime memory, or specific storage areas, which is a concern for auditors and compliance teams.
• Audit Logging and "Paid Privacy": Azure OpenAI leverages standard Azure logging features, offering audit logs, request and response logs, and trace logs. The "request and response" logs are particularly significant: when disabled, they provide the "paid privacy" guarantee that client data will not be used for model training. Enabling them, conversely, allows for deeper auditing but potentially permits data usage for training, similar to the free and plus versions of ChatGPT.
• Access Control Challenges: The service includes an account-level "Super Root admin key" (referred to as local authentication), which grants full control. While it can be disabled via the REST API (by setting disabledLocalAuth to true) in favor of Azure AD/Entra ID authentication, doing so breaks the Azure AI Studio UI, which relies on local authentication for developers. This creates a tension between developer experience and production security.
• Azure Policy Limitations for AI: There are currently no built-in Azure Policy definitions specifically for Azure OpenAI. To achieve continuous auditability, organizations must reuse policies designed for the broader microsoft.cognitiveServices resource provider. This necessitates manual filtering (e.g., using regex) to target only Azure OpenAI instances and avoid false positives with other cognitive services like Azure Cognitive Search.
• Undocumented Features and Discovery: A recurring theme was the discovery of critical security features and configuration options that are not exposed through the Azure Portal UI or SDKs. These "undocumented" features, such as the FQDN allow list and disabling local authentication, can only be found and configured by directly querying the Azure Resource Management API or exploring resources.azure.com.

Technical Deep Dive

▶ Watch: Encryption at Rest: MMK/CMK options, but critical lack of clarity on scope. (16:00)

The technical deep dive into securing Azure OpenAI applications reveals a blend of familiar Azure constructs and unique challenges posed by the nascent nature of generative AI services. Karl Ots structured his approach around the Microsoft Cloud Security Benchmark (MCSB), which serves as an "origami of different outside requirements" for auditors and CISOs. While the MCSB aims to simplify compliance by mapping technical controls to various security frameworks, its application to Azure OpenAI was initially problematic. For the first 10 months, no specific MCSB controls existed for Azure OpenAI. As of the talk, 35 controls are client responsibilities, and 7 are provided by Microsoft, though their coverage and specificity remain areas of concern.

The 7 Microsoft-provided controls include:

1. Network security (inbound)
2. Network security (outbound/DLP)
3. Resource logs
4. Key Vault integration (part 1)
5. Key Vault integration (part 2)
6. Customer-managed keys (CMK)
7. Data leakage and loss prevention (DLP)

Ots notes that some of these are redundant or generic. For instance, resource logs are a default Azure feature, and Key Vault integration is split into multiple controls. The most specific control, Data leakage and loss prevention, is unique to Azure OpenAI and Azure Cognitive Services.

Network Security:

The service, provisioned as a resource in an Azure subscription with a specific data center location, offers both inbound and outbound network controls.

• Inbound Network Controls: These are managed via a "resource firewall," which, despite its name, functions more like an Access Control List (ACL). It's configurable in the Azure Portal under the "Networking" tab, specifically "Firewalls and virtual networks." Options include "All networks," "Selected networks," or "Disabled." Critically, it supports both virtual networks and IP address ranges, and these are cumulative. This means an organization can allow traffic from specific virtual networks and additional IP ranges. Ots emphasizes the need for careful auditing of these IP ranges to prevent unauthorized access, such as from personal IP addresses.
• Outbound Network Controls (Data Exfiltration Prevention): This is a more complex and less visible feature. Known as "restricted outbound network access" or the "DLP feature," it's essentially an FQDN allow list. This list dictates which external fully qualified domain names the Azure OpenAI instance is permitted to communicate with. It can contain up to 1,000 FQDNs, useful for scenarios like downloading dependencies from external repositories like Hugging Face. However, this feature has no UI or SDK support; it must be configured by sending changes directly via the REST API. Ots highlights this as a significant "burning cloud platform" issue due to the lack of UI, SDK, and, crucially, audit logs for failed outbound attempts, making it challenging to verify its efficacy.

Encryption at Rest:

Similar to other Azure data services, Azure OpenAI provides encryption at rest.

• Microsoft-Managed Keys (MMK): This is the default encryption, where Microsoft manages the encryption keys. Ots points out the irony that the free and plus versions of ChatGPT, built on similar Azure technology, somehow claim to lack this feature, or at least don't offer it as a user-configurable option.
• Customer-Managed Keys (CMK): Enterprises can bring their own keys by pointing the service to a Microsoft first-party Azure Key Vault. Direct integration with third-party key management solutions (e.g., HashiCorp Vault) is not natively supported, requiring synchronization if such a setup is desired. A significant ambiguity remains regarding what data is precisely encrypted by these mechanisms (e.g., the entire cluster, runtime data, or specific storage components).

Audit Logging:

Azure OpenAI integrates with standard Azure logging capabilities. Organizations can export logs from the resource, choosing from three types:

1. Audit logs: General operational logs.
2. Request and response logs: These are critical. When disabled, they provide the "paid privacy" guarantee, meaning client data is not used for model training. When enabled, they allow for deeper auditing but also permit data usage for training, a feature utilized by the free and plus versions of ChatGPT.
3. Trace logs: Detailed diagnostic logs.

Logs can be exported to Azure-native destinations like a storage account or Log Analytics workspace, or to external systems.

Access Control:

The service includes a powerful, account-level "Super Root admin key" referred to as local authentication. This key grants full administrative control. Ots strongly recommends disabling this in production environments in favor of Azure AD/Entra ID authentication for both users and workloads. Disabling local authentication is done via the REST API by setting disabledLocalAuth to true. However, this action will break the Azure AI Studio UI, which relies on local authentication for developers, posing a trade-off during development phases.

Continuous Auditability with Azure Policy:

A major challenge for continuous compliance is the lack of specific built-in Azure Policy definitions for Azure OpenAI. Since Azure OpenAI falls under the microsoft.cognitiveServices resource provider, existing cognitive service policies can be reused. However, this requires manual filtering (e.g., using regex) to target only Azure OpenAI instances and avoid false positives with other cognitive services like Azure Cognitive Search. Ots provides examples of custom policies, such as one filtering microsoft.cognitiveServices.publicNetworkAccess for openAI specifically, or another to restrict the use of certain model types or versions within deployments.

Undocumented Features:

Ots reveals that many critical security configurations, such as the FQDN allow list for outbound access and disabling local authentication, are not exposed in the Azure Portal UI or SDKs. These features are discoverable by directly querying the Azure Resource Management API or by exploring resources.azure.com, which provides a raw REST API view of Azure resources. This necessitates a proactive and investigative approach for security professionals.

Reference Architecture (Conceptual):

Ots briefly outlines a conceptual reference architecture for consuming Azure OpenAI in an enterprise. This typically involves:

• An API Gateway to expose the application to UIs or web apps.
• Azure Front Door for global access, WAF capabilities, and DDoS protection, especially if consumed by users worldwide.
• Retrieval Augmented Generation (RAG) components, such as Azure Cognitive Search for storing indexes and Azure Cosmos DB for vector embeddings.

Demo / Proof of Concept

▶ Watch: Audit Logging & Access Control: Request/response logging for privacy, disabli... (18:00)

Karl Ots did not perform a live demonstration or proof of concept during his talk. Instead, he presented a logical flow of the security configurations and challenges encountered, supported by conceptual diagrams and screenshots of policy definitions. He described how certain features, like the inbound resource firewall, are configured via the Azure Portal UI, while others, such as the outbound FQDN allow list and disabling local authentication, require direct interaction with the Azure Resource Management API due to the absence of UI or SDK support. He also mentioned using resources.azure.com as a tool for discovering these less-documented configuration options. The "burning cloud platform" icon served as a visual indicator for features he deemed problematic or incomplete from a security perspective, rather than being part of a live demo.

Defensive Implications

▶ Watch: Enterprise Concerns: Black box nature and lack of visibility compared to AKS. (27:00)

The insights from Karl Ots's talk provide several crucial defensive implications for enterprises deploying Azure OpenAI applications:

• Prioritize Azure OpenAI for Enterprise Use: For organizations with stringent compliance, data residency, and security requirements, Azure OpenAI is the preferred choice over SaaS ChatGPT. It offers a greater degree of control over network access, encryption keys, and data handling, aligning better with enterprise security postures.
• Scrutinize Microsoft Cloud Security Benchmark (MCSB) Coverage: While the MCSB is a valuable starting point, defenders must be aware of its current limitations for Azure OpenAI. Do not assume comprehensive coverage; instead, conduct a thorough gap analysis against internal security policies and external compliance frameworks.
• Implement Robust Network Segmentation:
• Inbound: Configure the "resource firewall" (ACL) to strictly limit inbound access to Azure OpenAI instances from specific virtual networks and approved IP address ranges. Regularly audit these configurations to prevent unauthorized access, especially from non-corporate networks.
• Outbound: Critically, leverage the FQDN allow list for "restricted outbound network access" to prevent data exfiltration. This requires direct REST API configuration. Due to the lack of audit logs for failed attempts, thorough testing and continuous monitoring of allowed FQDNs are essential. Treat this as a high-priority control for data governance.
• Manage Encryption Keys Strategically: For sensitive data, implement Customer-Managed Keys (CMK) via Azure Key Vault. Understand the limitations regarding third-party key management systems and plan for synchronization if necessary. Seek clarity from Microsoft on the exact scope of data encrypted by MMK and CMK to satisfy audit requirements.
• Control Data Usage with Logging: Carefully configure audit logging, particularly the "request and response" logs. If "paid privacy" (preventing data from being used for model training) is a requirement, ensure these logs are disabled. If comprehensive auditing is paramount, enable them but understand the implications for data usage. Export logs to a secure, centralized Log Analytics Workspace for long-term retention and analysis.
• Enforce Strong Authentication: Disable local authentication (the "Super Root admin key") in production environments. Mandate Azure AD/Entra ID authentication for all users and workloads interacting with Azure OpenAI. Be prepared for potential impacts on developer workflows using tools like Azure AI Studio and plan alternative authentication methods for development environments.
• Leverage Azure Policy for Continuous Compliance: Despite the absence of specific built-in policies for Azure OpenAI, utilize existing microsoft.cognitiveServices policies. Implement custom policies with manual filtering (e.g., regex) to target Azure OpenAI resources specifically. This enables continuous auditing and enforcement of security configurations, such as public network access restrictions or allowed model versions.
• Embrace Infrastructure as Code (IaC) and CI/CD: Deploy and manage Azure OpenAI resources and their security configurations using IaC tools (e.g., Terraform, Bicep, ARM templates) integrated into CI/CD pipelines. This ensures consistency, repeatability, and auditability, especially for features that are only configurable via REST API.
• Proactive Feature Discovery: Given the rapid evolution of AI services and the presence of undocumented features, security teams should proactively explore the Azure Resource Management API and resources.azure.com. This allows for early discovery and implementation of new security controls that may not yet be exposed through the Azure Portal or SDKs.
• Stay Informed: The security landscape for AI services is dynamic. Continuously monitor Microsoft's updates, security advisories, and community discussions to adapt defensive strategies as new features and best practices emerge.

Key Takeaways

• Azure OpenAI offers superior enterprise controls: For organizations with strict security and compliance needs, Azure OpenAI provides more granular control over data, network, and encryption compared to SaaS ChatGPT.
• MCSB for Azure OpenAI is evolving: While the Microsoft Cloud Security Benchmark is a good starting point, its coverage for Azure OpenAI is still maturing, requiring organizations to supplement with custom policies and manual checks.
• Undocumented features are critical: Key security controls, such as the outbound FQDN allow list and disabling local authentication, often lack UI/SDK support and must be configured via the REST API, necessitating proactive discovery.
• Logging controls data usage: The "request and response" logs are crucial for auditing and for enabling "paid privacy" by preventing client data from being used for model training when disabled.
• Azure Policy requires careful adaptation: Continuous auditing for Azure OpenAI requires reusing and carefully filtering microsoft.cognitiveServices policies, as specific built-in policies are not yet available.
• Rapidly evolving landscape: The security features and best practices for AI services are developing quickly, demanding continuous vigilance, adaptation, and a proactive approach to security engineering.

About the Speaker(s)

Karl Ots is a consultant with a strong background in cloud and security, who has recently expanded his focus to include artificial intelligence. He describes his professional role as primarily advising enterprises, often involving "hand waving and PowerPoint instead of PowerShell," though he maintains a deep technical understanding from his past as an engineer. His presentation at BSidesSF 2024 is directly informed by his real-world experience in securing Azure OpenAI applications for a large banking organization, highlighting the practical challenges and solutions in integrating cutting-edge AI services into complex enterprise environments.