Azure Functions Security

Azure Functions is a serverless compute service that runs code in response to events. Because functions are stateless and can be triggered by HTTP requests, timers, queues, or other Azure services, securing them requires a multi-layered approach. The AZ-500 exam focuses on the following security controls:

Azure Functions supports several authentication mechanisms. The most important for the exam are:

1. Function-Level Keys: By default, HTTP-triggered functions require a function key, host key, or master key. These keys are stored in the function app's settings and can be managed via the portal or CLI. The master key ("_master") grants full access to all functions and should be protected like a root password. The exam tests that you know the key hierarchy: master key > host keys > function keys. Keys can be regenerated, and you can disable anonymous access.

2. EasyAuth (App Service Authentication): This is a built-in authentication layer that runs before the function code. It supports Azure AD, Microsoft Account, Facebook, Google, Twitter, and Apple. For enterprise scenarios, Azure AD is most common. EasyAuth can be configured to require authentication for all requests, and it automatically populates HTTP headers with claims (e.g., X-MS-CLIENT-PRINCIPAL). The exam tests that you know EasyAuth is a reverse-proxy authentication module that runs at the App Service platform level, not within the function code.

3. Azure AD Authentication: You can configure the function app to require Azure AD tokens. This is done via the "Authentication" blade in the portal. You specify the Azure AD app registration, and the function app validates tokens. The exam may ask about token validation: the function app uses the OpenID Connect discovery URL to validate the token's issuer, audience, and signature. You can also configure token exchange (e.g., for on-behalf-of flow).

4. Authorization in Code: Even with authentication, you need authorization logic within the function. The exam expects you to know how to check claims from the authenticated user (e.g., roles) using the ClaimsPrincipal object in .NET or the req.headers in other languages. A common pattern is to use [FunctionName("MyFunc")] with [Authorize] attribute or manual checks.

Azure Functions can be network-isolated to prevent public internet access. The exam covers:

1. Access Restrictions (IP Whitelisting): You can restrict inbound traffic to a function app by specifying allowed IP addresses or virtual network (VNet) source IPs. This is configured in the "Networking" blade under "Access Restrictions". You can create rules with priority (lower number = higher priority) to allow or deny traffic. The default is to allow all. The exam tests that you can configure this to allow only specific IP ranges (e.g., your corporate VPN) and deny all others.

2. VNet Integration: For outbound traffic, you can integrate the function app with a VNet using VNet Integration (for regional VNet) or a gateway-required VNet (for classic). This allows the function to access resources in the VNet (e.g., databases) without going over the public internet. Inbound traffic can be restricted using Service Endpoints or Private Endpoints. The exam focuses on Private Endpoints: they place the function app on a private IP in your VNet, accessible only from within that VNet or peered networks. You must know that Private Endpoints require a Premium plan (Elastic Premium or Dedicated).

3. Service Endpoints: For PaaS services like Azure SQL, Service Endpoints allow the function app to connect securely. However, for inbound traffic to the function app, Service Endpoints are not supported; you need Private Endpoints.

Functions often need secrets like connection strings, API keys, or certificates. The exam tests:

1. Key Vault References: Instead of storing secrets in app settings, you can reference them from Azure Key Vault. The syntax is @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/). The function app must have a Managed Identity assigned and granted GET permission on the secret. The exam tests that you know the format and that Managed Identity is required.

2. Managed Identities: System-assigned or user-assigned managed identities allow the function app to authenticate to Azure resources without storing credentials. For example, you can use a managed identity to access Key Vault, Azure SQL, or Storage. The exam expects you to know the difference: system-assigned is tied to the function app and deleted when the app is deleted; user-assigned is a separate resource that can be shared. You must know how to grant permissions (e.g., using Azure RBAC) and how to use the identity in code (e.g., DefaultAzureCredential).

3. Application Settings Encryption: All app settings are encrypted at rest by default using Azure's platform-managed keys. You can also use customer-managed keys (CMK) for additional control. The exam may test that CMK is supported for Functions on Dedicated plans but not on Consumption (though this is changing; check current docs).

Functions automatically encrypt data at rest (e.g., code, configuration) and in transit (TLS 1.2 by default). You can enforce HTTPS only and set the minimum TLS version. The exam tests that you can require TLS 1.2 or higher and that HTTP traffic can be redirected to HTTPS.

Security monitoring is crucial. The exam covers:

1. Application Insights: You can enable Application Insights to monitor function executions, failures, and performance. Security events like authentication failures are logged. You can set alerts on failed requests.

2. Diagnostic Logs: The function app can stream logs to Log Analytics, Storage, or Event Hubs. You can audit who accessed the function and when. The exam may ask about enabling diagnostic settings for the Function App resource.

3. Azure Policy: You can enforce security policies on function apps, such as requiring HTTPS, disabling FTP, or enforcing minimum TLS version. The exam tests that you can create custom policies or use built-in ones.

Azure CLI examples:

# List function keys
az functionapp keys list --name MyFunctionApp --resource-group MyRG

# Add IP restriction
az functionapp config access-restriction add --name MyFunctionApp --resource-group MyRG --rule-name AllowCorporate --action Allow --ip-address 203.0.113.0/24 --priority 100

# Enable Managed Identity
az functionapp identity assign --name MyFunctionApp --resource-group MyRG

# Add Key Vault reference to app setting
az functionapp config appsettings set --name MyFunctionApp --resource-group MyRG --settings "MySecret=@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)"

# Enforce HTTPS only
az functionapp update --name MyFunctionApp --resource-group MyRG --set httpsOnly=true

PowerShell example:

Set-AzWebApp -Name MyFunctionApp -ResourceGroupName MyRG -HttpsOnly $true

Verification:

A large bank uses Azure Functions to expose an internal API that retrieves customer account balances. The function is triggered via HTTP and must only be accessible from the bank's internal network and from authorized applications. The security team configures IP restrictions to allow only the bank's VPN IP range (10.0.0.0/8) and a specific Azure VNet where the frontend app resides. They enable Azure AD authentication so that only service principals with the 'Reader' role on the function app can call it. The function uses a managed identity to connect to Azure SQL Database, which is also firewalled to allow only the function's outbound IP. All secrets (like the SQL connection string) are stored in Key Vault with managed identity access. The function app is on a Premium plan to support VNet integration and private endpoints. In production, they handle about 1 million requests per day with p99 latency under 200ms. A common misconfiguration is forgetting to add the deny-all IP rule, leaving the function exposed to the internet. Another issue is not rotating the master key, which could allow unauthorized access if leaked. The team uses Azure Policy to enforce HTTPS only and minimum TLS version across all function apps.

A media company uses Azure Functions to process video uploads. The function is triggered by a Blob Storage event (new blob) and then processes the video using Azure Media Services. Security here focuses on the trigger: the function must only be invoked by the storage account, not by external callers. They set the authorization level to 'System' (which requires a specific system key) and configure the storage account to use a managed identity to authenticate to the function. They also enable network restrictions so that only the storage account's service endpoint can reach the function. The function accesses Key Vault for API keys to third-party services. The team uses Application Insights to monitor for failed executions, which could indicate a security issue. A common mistake is leaving the function with 'Anonymous' authorization level, allowing anyone with the URL to trigger it, potentially causing unexpected costs or data leaks.

A SaaS provider uses Azure Functions as the backend for a multi-tenant application. Each tenant has its own function app instance. Security is critical: tenants must not access each other's data. They use Azure AD B2C for tenant-specific authentication, with each tenant having a separate user pool. The function app validates the token's 'tid' (tenant ID) claim and uses it to filter data. They also implement IP restrictions per tenant if needed. Managed identities are used to access tenant-specific storage accounts. The challenge is scaling: with hundreds of tenants, managing individual function apps becomes complex. They use Azure API Management as a front door to handle tenant routing and rate limiting. A common failure is misconfigured CORS, which can block legitimate browser requests but is often mistaken for a security issue. The exam tests understanding that CORS is not a security mechanism but a browser policy.