11.2 Azure Functions and Logic Apps Security

11.2 Azure Functions and Logic Apps Security

Quick Answer: SC-500 skills measured include security controls for Azure Functions (authentication and network access) and Azure Logic Apps. Prefer Easy Auth / Microsoft Entra and managed identity over long-lived function keys and connection strings; lock inbound paths with private endpoints / access restrictions and outbound paths with VNet integration. For Logic Apps, control who can call and manage workflows and enable secure inputs/outputs so secrets do not appear in run history.

Serverless platforms shrink OS patching but expand identity and secret sprawl if teams default to keys and connection strings. This section is the SC-500 playbook for Functions and Logic Apps as first-class application platforms.

Azure Functions authentication models

Functions expose HTTP triggers and many other trigger types. Authentication choices determine who can invoke the app.

Function keys vs Entra / Easy Auth (the exam trap)

Function keys are shared secrets. Anyone with the key can call the endpoint (subject to network path). Keys do not give you:

• User or workload identity in Entra
• Conditional Access, MFA, device compliance
• Fine-grained app roles / scopes
• Easy enterprise revocation without rotating secrets everywhere

Easy Auth (App Service Authentication) validates tokens at the platform layer. Typical production patterns:

1. Register an app in Microsoft Entra ID.
2. Configure Functions authentication to require Entra.
3. Callers present bearer tokens; optional authorization policies map roles.
4. For service-to-service, use managed identity of the caller (for example APIM or another Azure app) rather than a shared function key.

Exam phrasing: When a scenario says “no shared secrets,” “Conditional Access,” or “only Contoso’s APIM managed identity may call the function,” choose Entra/Easy Auth + managed identity, not “email the function key to partners.”

Keys still appear in some automation and legacy integrations. If used, store them in Key Vault, rotate, never commit to Git, and prefer least-privilege function-level keys over master keys.

Network access for Functions

Authentication is not enough if the data plane is open to the world.

Inbound controls

Outbound controls

Combined pattern: Private inbound (only APIM or internal callers) + VNet integration outbound + managed identity to dependencies = no public function URL for attackers to spray keys against.

Hosting plan notes (exam awareness)

Networking features vary by plan (Consumption, Premium, Dedicated, Flex Consumption). SC-500 focuses on capability intent—private access, VNet integration, identity—not memorizing every SKU matrix cell. If a scenario requires private endpoints and VNet integration, choose a plan/configuration that supports them rather than arguing with Consumption limitations.

Managed identity for Functions

Enable system-assigned or user-assigned managed identity on the function app, then grant least-privilege RBAC:

• Key Vault Secrets User on vaults
• Storage data roles instead of account keys
• Azure RBAC on Service Bus, Event Hubs, Cosmos DB as needed

Use Key Vault references in application settings (@Microsoft.KeyVault(...)) so secrets are not stored as plain app settings. For triggers that support identity-based connections (Service Bus, Event Hubs, and others), prefer identity over connection strings.

Code still matters: Even with Easy Auth, developers must not reintroduce secrets in source. Identity removes the need for many credentials but does not stop hardcoding if developers ignore platform features.

Logic Apps security

Logic Apps automate workflows across SaaS and Azure connectors. Security focuses on who can start and manage runs, what connectors can access, and what appears in logs.

Consumption vs Standard (high level)

Know that Standard is the usual answer when the scenario demands VNet integration, private endpoints, and deeper isolation similar to App Service.

Access control

• Restrict who can manage the Logic App (Azure RBAC on the resource).
• Restrict who can invoke HTTP request triggers (SAS/callback URLs are secrets; prefer Entra-authenticated patterns where available, or put APIM in front).
• Treat trigger callback URLs like passwords—regenerate if leaked.

Secure inputs and secure outputs

Logic Apps run history can display action inputs and outputs. If a connector returns an API key, password, or personal data, that history becomes a sensitive data store.

Exam trap: Enabling managed identity does not automatically redact run history. You still configure secure inputs/outputs on sensitive actions.

Managed identity connectors

Many Azure connectors support managed identity authentication (Storage, Key Vault, Service Bus, Azure Resource Manager, and others depending on connector). Prefer identity over storing usernames/passwords or connection strings in the workflow definition.

For SaaS connectors that require OAuth user consent or API keys:

• Use least-privilege accounts
• Store secrets in Key Vault / secure parameters
• Review connector permissions during access reviews

Scenario: invoice automation workflow

A Logic App receives invoices, reads a storage account, calls a custom API, and emails finance.

Hardened design:

1. Standard Logic App in VNet-integrated environment where required.
2. HTTP trigger not anonymously on the open internet—front with APIM + JWT or authenticated trigger pattern.
3. Storage and Key Vault connectors use managed identity.
4. Actions that handle bank account numbers mark secure inputs/outputs.
5. Azure RBAC limits editors; production changes require PIM-eligible roles.
6. Monitor failed authentication and unusual run volume in logs / Sentinel.

Functions + Logic Apps + APIM (reference chain)

A frequent SC-500 architecture:

1. External client obtains Entra token.
2. API Management validate-jwt, rate-limits, optional IP filter.
3. APIM calls Function backend with authentication-managed-identity.
4. Function Easy Auth accepts only APIM’s app identity.
5. Function uses its managed identity for Key Vault and data stores.
6. Logic Apps (if orchestration) use managed identity connectors and secure I/O.

No function host keys in partner emails; every hop is attributable.

Keys vs identity decision table

SC-500 traps

1. Function key = MFA-backed user auth — False; keys are bearer secrets.
2. Private endpoint without DNS — Private Link requires correct private DNS or resolution fails.
3. Logic Apps “secure” because Premium connector — Connector SKU ≠ secret hygiene or run-history redaction.
4. Storing master key in app settings as plain text — Use Key Vault references and minimize master key use.
5. Assuming Consumption always supports every private networking feature — Match plan to network requirements.

Engineer checklist

1. Inventory Functions: anonymous vs key vs Easy Auth; eliminate anonymous on sensitive endpoints.
2. Move partner-facing APIs to Entra/Easy Auth and/or APIM JWT validation.
3. Enable managed identity; replace connection strings where possible.
4. Apply access restrictions or private endpoints; integrate outbound VNet when talking to private PaaS.
5. For Logic Apps: RBAC least privilege, protect trigger URLs, enable secure inputs/outputs, prefer identity connectors.
6. Send diagnostic logs to Log Analytics / Sentinel for auth failures and anomalous invocations.

Bottom line: On SC-500, Functions and Logic Apps security is mostly identity + network + secret hygiene. If the answer is “share the host key,” look for a better design using Entra, managed identity, and private access.