Part 2: Securing Your Azure AI Foundry Hub - Network, Identity & Encryption

Sakaldeep Yadav

Dec 19, 2025 • 5 min read

Part 2 of 13: Securing Your Azure AI Foundry Hub - Network, Identity & Encryption

Published by: Azure User Group Nepal
Series: Enterprise AI Governance, Security & Infrastructure with Azure AI Foundry

Introduction

In Part 1, you learned that Azure AI Foundry has three architectural tiers: Hub, Projects, and Connections. Now comes the critical question: How do I secure this?

Security in Azure AI Foundry isn't an afterthoughtâ€”it's built into the architecture. But understanding how to implement it requires understanding four security layers: network security, identity security, encryption, and audit logging.

Your retail company handles sensitive employee data (HR records, IT support tickets, operational information). Your compliance team requires GDPR compliance for EU employees and PCI-DSS compliance for payment-related data. Your security team requires encryption at rest and in transit. Your audit team requires complete audit trails.

This post explains how Azure AI Foundry's security architecture enables all of this.

What you'll learn in this post:

How network security isolates your Hub
How identity controls protect access
How encryption protects data
How audit logging enables compliance
How these four layers work together

Prerequisites: Part 1 (Understanding Azure AI Foundry architecture)

Complexity Level: Medium

Azure AI Foundry Security Architecture

Security in Azure AI Foundry operates at four layers:

Layer 1: Network Security

Network security controls who can access your Hub from the network level.

Key components:

Virtual Network (VNet): Your Hub lives in a VNet, isolated from the public internet
Private Endpoints: Services (Hub, Azure OpenAI, Storage, Key Vault) are accessed through private endpoints, not public endpoints
Network Security Groups (NSGs): Firewall rules control traffic between subnets
Service Endpoints: Additional network-level access control

In your retail scenario:

Your Hub is deployed in a VNet with private subnets
Azure OpenAI is accessed through a Private Endpoint (not the public internet)
Your HR system is accessed through a Private Endpoint
NSGs allow traffic only between authorized subnets
No one can access your Hub from the public internet

Why this matters:

Prevents unauthorized network access
Ensures data doesn't traverse the public internet
Enables compliance with data residency requirements
Reduces attack surface

Layer 2: Identity Security

Identity security controls who can access your Hub and what they can do.

Key components:

Azure AD Integration: Hub uses Azure AD for authentication
Managed Identities: Services authenticate to each other without storing credentials
Role-Based Access Control (RBAC): Fine-grained permissions for Hub Admin, Project Owner, Team Member roles
Service Principals: Applications authenticate to the Hub

In your retail scenario:

Employees authenticate to the Hub using their Azure AD credentials
The Hub has a system-managed identity for accessing Key Vault and Storage
Hub Admin role can create Projects
Project Owner role can manage team members
Team Member role can access Project resources
Data Scientists authenticate using their Azure AD identity

Why this matters:

Ensures only authorized users can access the Hub
Prevents credential theft (managed identities don't use passwords)
Enables fine-grained access control
Simplifies credential management

Layer 3: Encryption

Encryption protects data at rest and in transit.

Key components:

Encryption at Rest: Data stored in Storage Account, Key Vault, and databases is encrypted using customer-managed keys (CMK)
Encryption in Transit: All communication uses TLS 1.2 or higher
Key Management: Keys are stored in Key Vault and rotated regularly
Transparent Data Encryption (TDE): Databases are encrypted transparently

In your retail scenario:

Employee data stored in the Hub is encrypted using your own encryption keys
Communication between the Hub and Azure OpenAI uses TLS 1.2
Communication between the Hub and your HR system uses TLS 1.2
Encryption keys are stored in Key Vault and rotated every 90 days
Even if someone gains access to the storage account, they can't read the data without the encryption key

Why this matters:

Protects data even if storage is compromised
Ensures data privacy in transit
Enables compliance with encryption requirements
Provides key rotation for security

Layer 4: Audit Logging

Audit logging tracks all activity for compliance and forensics.

Key components:

Activity Logs: All Hub activity (project creation, team member additions, model deployments) is logged
Diagnostic Logs: Detailed logs of Hub operations
Audit Logs: Compliance-relevant events are logged separately
Log Analytics: Logs are stored in Log Analytics for analysis and alerting

In your retail scenario:

Every time someone creates a Project, it's logged
Every time someone adds a team member, it's logged
Every time someone accesses a Connection, it's logged
Every time a model is deployed, it's logged
Logs are stored for 90 days for compliance
Alerts are triggered for suspicious activity

Why this matters:

Enables compliance audits
Provides forensic evidence for security incidents
Detects unauthorized activity
Demonstrates compliance to regulators

Terraform Implementation Approach

To implement these four security layers, you'll use Terraform to create:

# Layer 1: Network Security - VNet and Private Endpoints
resource "azurerm_virtual_network" "hub_vnet" {
  name                = "vnet-hub-prod"
  location            = "eastus"
  resource_group_name = azurerm_resource_group.hub_rg.name
  address_space       = ["10.0.0.0/16"]
}

# Private Endpoint for Hub
resource "azurerm_private_endpoint" "hub_endpoint" {
  name                = "pe-hub-prod"
  location            = azurerm_virtual_network.hub_vnet.location
  resource_group_name = azurerm_resource_group.hub_rg.name
  subnet_id           = azurerm_subnet.hub_subnet.id

  private_service_connection {
    name                           = "psc-hub"
    private_connection_resource_id = azurerm_machine_learning_workspace.hub.id
    subresource_names              = ["amlworkspace"]
    is_manual_connection           = false
  }
}

# Layer 2: Identity Security - Managed Identity
resource "azurerm_user_assigned_identity" "hub_identity" {
  name                = "id-hub-prod"
  location            = "eastus"
  resource_group_name = azurerm_resource_group.hub_rg.name
}

# Layer 3: Encryption - Key Vault
resource "azurerm_key_vault" "hub_kv" {
  name                = "kv-hub-prod"
  location            = "eastus"
  resource_group_name = azurerm_resource_group.hub_rg.name
  sku_name            = "premium"
  
  # Enable purge protection for compliance
  purge_protection_enabled = true
}

# Layer 4: Audit Logging - Log Analytics
resource "azurerm_log_analytics_workspace" "hub_logs" {
  name                = "law-hub-prod"
  location            = "eastus"
  resource_group_name = azurerm_resource_group.hub_rg.name
  sku                 = "PerGB2018"
  retention_in_days   = 90
}

What this does:

Creates a VNet with private subnets for network isolation
Creates a Private Endpoint for the Hub (not accessible from public internet)
Creates a managed identity for the Hub
Creates a Key Vault for encryption key management
Creates a Log Analytics workspace for audit logging

For complete Terraform code with all parameters, networking, RBAC, and monitoring, see:

Compliance & Governance Implications

These four security layers enable compliance:

Network Security: Data residency (EU data stays in EU VNet)
Identity Security: Access control (only authorized users)
Encryption: Data protection (encrypted at rest and in transit)
Audit Logging: Compliance evidence (audit trail for regulators)

PCI-DSS Compliance

Network Security: Cardholder data network isolation
Identity Security: Access control for payment data
Encryption: Encryption of payment data
Audit Logging: Audit trail for payment transactions

SOC 2 Type II Compliance

Network Security: Network access controls
Identity Security: User access controls
Encryption: Data protection controls
Audit Logging: Audit trail for compliance

Operational Considerations

Monitoring Security

Monitor network traffic for anomalies
Alert on failed authentication attempts
Monitor encryption key usage
Alert on audit log anomalies

Key Rotation

Rotate encryption keys every 90 days
Automate key rotation in Key Vault
Log all key rotation events
Test key rotation in non-production first

Troubleshooting

If users can't access the Hub, check RBAC and network connectivity
If data can't be encrypted, check Key Vault permissions
If audit logs are missing, check Log Analytics configuration
If Private Endpoints aren't working, check NSG rules

Conclusion & Next Steps

You now understand the four security layers of Azure AI Foundry:

Network Security: VNet, Private Endpoints, NSGs
Identity Security: Azure AD, Managed Identities, RBAC
Encryption: CMK, TLS, Key Vault
Audit Logging: Activity logs, Diagnostic logs, Audit logs

These four layers work together to protect your Hub and enable compliance.

In Part 3, we'll dive deeper into governance: how to control who can do what in your Hub.

Next steps:

Review your network architecture and plan your VNet
Review your identity requirements and plan your RBAC
Review your encryption requirements and plan your Key Vault
Review your audit requirements and plan your Log Analytics
Read Part 3 to understand governance controls

Relevant Azure documentation:

Connect & Questions

Want to discuss Azure AI Foundry security, share feedback, or ask questions?

Reach out on X (Twitter) @sakaldeep

Or connect with me on LinkedIn: https://www.linkedin.com/in/sakaldeep/

I look forward to connecting with fellow cloud professionals and learners.

Published by: Azure User Group Nepal
Series: Enterprise AI Governance, Security & Infrastructure with Azure AI Foundry
Part: 2 of 13

Part 2 of 13: Securing Your Azure AI Foundry Hub - Network, Identity & Encryption

Introduction

Azure AI Foundry Security Architecture

Layer 1: Network Security

Layer 2: Identity Security

Layer 3: Encryption

Layer 4: Audit Logging

Terraform Implementation Approach

Compliance & Governance Implications

GDPR Compliance

PCI-DSS Compliance

SOC 2 Type II Compliance

Operational Considerations

Monitoring Security

Key Rotation

Troubleshooting

Conclusion & Next Steps

Connect & Questions