Securing Azure API Traffic End-to-End: APIM, Application Gateway, Firewall, and SIEM Integration

If you're running APIs on Azure in a regulated environment, you likely have some combination of Azure Firewall, Application Gateway with WAF, and API Management sitting in front of your backends. Each service has a clear role. But the security gaps don't live inside any single layer — they live in the seams between them.

This post covers how these services work together as a layered defense chain, how to get unified observability into Sumo Logic when Sentinel isn't your SIEM, and how to handle one of the most overlooked risks in enterprise API programs: managing APIM subscription keys when external partners need access to your APIs.

The Layered Architecture: What Each Layer Does

The traffic flow for a properly secured Azure API deployment looks like this:

Client → Azure Firewall → Application Gateway (WAF) → API Management → Backend Services

Azure Firewall is your network-layer gatekeeper. It handles L3/L4 filtering, threat intelligence-based blocking, FQDN filtering for egress, and TLS inspection. It sees all traffic — not just HTTP — and enforces network segmentation between your public edge and internal services. It does not understand API semantics.

Application Gateway with WAF operates at L7. It terminates TLS, inspects HTTP payloads against OWASP Core Rule Set, and blocks SQL injection, XSS, and request smuggling before traffic reaches APIM. It understands HTTP but does not understand your API contracts.

API Management is your API-aware layer. It enforces authentication, rate limiting, subscription key validation, request/response transformation, and API-specific policies. It understands your API contracts, your consumers, and your business logic boundaries.

The mistake most teams make: assuming one layer covers what another should. Azure Firewall won't catch a SQL injection in a JSON payload. WAF won't enforce per-partner rate limits. APIM won't block a DDoS at the network layer. Each layer has a job. Overlap is intentional — gaps are not.

Common Misconfigurations That Create Risk

APIM exposed directly to the internet without App Gateway. This bypasses WAF inspection entirely. APIM has built-in rate limiting but no payload inspection for OWASP threats. If an attacker sends a crafted payload that exploits a backend vulnerability, APIM will happily proxy it through.

App Gateway without Azure Firewall in front. App Gateway handles HTTP traffic well, but without Azure Firewall you lose network-level threat intelligence blocking, non-HTTP protocol filtering, and centralized egress control. Attackers can probe non-HTTP ports, and compromised backends can exfiltrate data without egress filtering.

TLS termination in the wrong place. If you terminate TLS at App Gateway but don't re-encrypt to APIM, traffic between App Gateway and APIM traverses the network in plaintext. In a shared VNet or peered environment, that's a lateral movement risk. Always re-encrypt — end-to-end TLS is non-negotiable in regulated environments.

No mutual TLS between APIM and backends. APIM authenticating to backends with a shared secret or no authentication at all means any service that can reach the backend network can bypass APIM entirely. Use client certificates or managed identity authentication between APIM and your backend services.

Partner Subscription Key Management: The Overlooked Risk

Here's where most enterprise API programs introduce risk without realizing it: you have external partners consuming your APIs through APIM, and those partners need subscription keys to authenticate. The question is — how do you issue, rotate, scope, and revoke those keys without creating a security liability?

The Problem

APIM subscription keys are bearer tokens. Whoever has the key can call the API. If a partner embeds the key in a client application, shares it across teams, or stores it in a config file that gets committed to a repository — you now have an uncontrolled credential in the wild with no way to know who's actually using it.

Worse: if you issue a single subscription key per partner with access to multiple APIs, a compromised key gives an attacker access to your entire API surface for that partner's scope. That's not defense in depth — that's a single point of failure.

Best Practices for Partner Key Management

One subscription per partner per API product. Never issue a single key that grants access to multiple API products. Scope subscriptions to the narrowest set of APIs the partner actually needs. If a key is compromised, the blast radius is limited to one product.

Enforce key rotation on a defined cadence. APIM supports primary and secondary keys per subscription. Require partners to rotate keys every 90 days. Publish the rotation schedule in your partner onboarding documentation. Use APIM's built-in key regeneration and give partners a grace period where both old and new keys work simultaneously.

Layer OAuth 2.0 on top of subscription keys. Subscription keys alone are not sufficient for partner authentication in regulated environments. Require partners to also present a valid OAuth 2.0 token issued by your identity provider (Entra ID). Use APIM's validate-jwt policy to verify the token, check audience claims, and enforce scopes. The subscription key becomes a product-level gate; the OAuth token becomes the identity-level gate.

Never transmit keys outside of secure channels. Provide partner keys through a secure portal — not email, not Slack, not a shared document. APIM's developer portal can serve this purpose, or use Azure Key Vault with time-limited access policies to share keys with partner technical contacts.

Monitor key usage patterns and alert on anomalies. Every APIM request logs the subscription ID. If a partner key suddenly starts calling APIs at 10x normal volume, from a new IP range, or at unusual hours — that's a signal. Build these alerts in your SIEM (more on that below).

Implement IP allowlisting per subscription. Use APIM's ip-filter policy scoped to the subscription level. Partners should provide their egress IP ranges, and APIM should reject requests from any other source — even if the subscription key is valid. A stolen key is useless if the attacker can't call from the partner's network.

Automate revocation on partner offboarding. When a partner relationship ends, their subscription keys must be revoked immediately — not at the end of the billing cycle, not when someone remembers. Build this into your partner lifecycle process. APIM subscriptions can be suspended or deleted via the management API, which means this should be automated as part of your offboarding workflow.

Getting Logs to Sumo Logic: The Diagnostic Architecture

If your SIEM is Sumo Logic rather than Microsoft Sentinel, you need a reliable pipeline to get Azure diagnostic logs out of the platform and into your collectors. The architecture is straightforward but the details matter.

The Pipeline

Azure Diagnostic Settings → Event Hubs → Sumo Logic Cloud-to-Cloud Source (or hosted collector with Azure Event Hub source)

Step 1: Enable diagnostic settings on every layer. Azure Firewall, Application Gateway, and API Management all support diagnostic settings that stream logs to Event Hubs. For each resource, enable all log categories relevant to security:

• Azure Firewall: AZFWApplicationRule, AZFWNetworkRule, AZFWThreatIntel, AZFWDnsQuery
• Application Gateway: ApplicationGatewayAccessLog, ApplicationGatewayFirewallLog
• API Management: GatewayLogs (includes subscription ID, client IP, response codes, latency)

Step 2: Use a dedicated Event Hub namespace for security logs. Don't mix security telemetry with application telemetry. Create a dedicated Event Hub namespace with a consumer group specifically for Sumo Logic. This ensures your SIEM ingestion doesn't compete with other consumers and gives you clear RBAC boundaries.

Step 3: Configure the Sumo Logic source. Sumo Logic's Cloud-to-Cloud Azure Event Hub source connects directly to your Event Hub namespace using a shared access policy with Listen permissions only. Configure one source per Event Hub (one per resource type) so logs are categorized correctly in Sumo Logic. Apply source categories that map to your security taxonomy — e.g., azure/firewall, azure/waf, azure/apim.

Step 4: Parse and normalize. Azure diagnostic logs arrive in a JSON format that varies by resource type. Build Sumo Logic Field Extraction Rules (FERs) for each source category to normalize fields like client IP, action (allow/deny/block), rule name, and subscription ID into a consistent schema your SOC team can query across all three layers.

What to Alert On Across the Chain

Once logs from all three layers are flowing into Sumo Logic, the real value is correlation. Individual alerts are useful. Cross-layer correlation catches what single-layer monitoring misses.

• WAF blocks followed by APIM success from the same IP. This means an attacker found a payload that bypasses WAF but still reaches APIM. Investigate immediately — your WAF rules may have a gap.
• Subscription key usage from unexpected IP ranges. If a partner key is being used from IPs outside their declared egress range, either their infrastructure changed (and they should have told you) or the key is compromised.
• Spike in 401/403 responses from APIM. Credential stuffing against your API surface. Correlate with Azure Firewall logs to see if the source IPs are known threat intelligence indicators.
• Azure Firewall threat intelligence hits from IPs that also appear in APIM logs. If a known-bad IP made it past the firewall (perhaps before the threat intel feed updated), check whether it successfully called any APIs.
• Partner subscription key used outside business hours. Legitimate partner integrations typically run on predictable schedules. Off-hours usage warrants investigation.

Compliance Implications

For regulated industries, this architecture isn't optional — it's expected. SOC 2 requires logging and monitoring of access to systems and data. PCI DSS requires network segmentation and monitoring of all access to cardholder data environments. HIPAA requires audit controls and integrity controls for ePHI.

The combination of Azure Firewall (network segmentation), App Gateway WAF (application-layer protection), APIM (access control and audit logging), and Sumo Logic (centralized monitoring and alerting) satisfies these requirements — but only if the logs are complete, retained for the required duration, and actively monitored. Logging without alerting is a compliance checkbox. Logging with correlation and response is actual security.

The Architecture Decision

If you're a security leader evaluating this stack: the individual services are well-documented. The gap in most organizations is the integration — how traffic flows between layers, how logs correlate across them, and how partner access is governed without creating unmanaged credentials. That's architecture work, not product configuration. And it's where most teams need help.