Event Grid and Event Hub Security Best Practices
Both Azure Event Grid and Azure Event Hub handle potentially sensitive business data — order events, user activity, IoT sensor readings, financial transactions. Securing these services protects data in transit and at rest, controls who can publish or consume events, and prevents unauthorized access to the event infrastructure.
Authentication Options: Identity vs Keys
Both services support two approaches for authenticating publishers and consumers.
Authentication Methods +---------------------------+ +---------------------------+ | Managed Identity / | | Access Keys / SAS | | Azure AD (Recommended) | | (Legacy / Simple) | +---------------------------+ +---------------------------+ | - No secrets to manage | | - Connection string with | | - Automatically rotated | | embedded key | | - Granular RBAC roles | | - Must rotate manually | | - Works across services | | - No per-resource control | +---------------------------+ +---------------------------+
For production environments, always use Managed Identity or Azure AD service principals. Access keys are convenient for local development and testing but introduce secret management overhead in production.
Event Hub Authentication with Managed Identity
Assigning the Right RBAC Role
| Role | Permission Level | Use Case |
|---|---|---|
| Azure Event Hubs Data Sender | Send events only | Producer applications |
| Azure Event Hubs Data Receiver | Receive events only | Consumer applications |
| Azure Event Hubs Data Owner | Full access | Administrative tools only |
Assign the minimal role needed. A producer application gets Data Sender only — it cannot read events even if compromised.
Assigning Role via Azure CLI
# Assign Data Sender role to an App Service's managed identity
az role assignment create \
--assignee <managed-identity-principal-id> \
--role "Azure Event Hubs Data Sender" \
--scope /subscriptions/<subId>/resourceGroups/<rg>/providers/
Microsoft.EventHub/namespaces/<namespace>/eventhubs/<eventhub>
C# Code Using Managed Identity
// No connection string. No secrets. Identity handles authentication.
var producerClient = new EventHubProducerClient(
"myNamespace.servicebus.windows.net",
"myEventHub",
new DefaultAzureCredential()); // Uses managed identity automatically
await producerClient.SendAsync(new[] { new EventData("Hello Event Hub") });
Event Grid Authentication
For System Topics and Azure Service Sources
Azure services publish to Event Grid topics using their own managed service identities. No keys are needed between Azure services. Permissions are granted through RBAC.
For Custom Topics: AAD or Key
Publishing to a Custom Topic:
Option A – Azure AD Token (Recommended):
POST https://myTopic.eastus-1.eventgrid.azure.net/api/events
Headers:
Authorization: Bearer <AAD token>
Content-Type: application/json
Option B – Access Key (Legacy):
POST https://myTopic.eastus-1.eventgrid.azure.net/api/events
Headers:
aeg-sas-key: <your-access-key>
Content-Type: application/json
Event Grid Topic Access Keys
Each Event Grid custom topic has two access keys. If one key is compromised, regenerate it. The second key keeps the system running during rotation.
Rotate keys regularly: Event Grid Topic → Access Keys → Regenerate Key 1
Shared Access Signatures (SAS) for Event Hub
SAS tokens provide time-limited, scope-limited access without sharing the master key. They are useful when granting temporary access to an external partner or a specific application.
SAS Token Structure:
SharedAccessSignature sr=myNamespace.servicebus.windows.net%2F
&sig=abcdef123==
&se=1735689600 ← expiry (Unix timestamp)
&skn=SendPolicy ← SAS policy name
SAS Policy Example:
Name: SendPolicy
Permissions: Send only
Valid for: 24 hours
Use case: Partner application needs to publish events
to your Event Hub for 24 hours only.
Issue a SAS token. Partner uses it.
Token expires automatically.
Network Security: Private Endpoints and VNet Integration
By default, Event Hub and Event Grid endpoints are accessible from the public internet. Restrict access using private endpoints or IP firewall rules.
Private Endpoint Architecture
Public Internet
|
| (blocked)
X
|
+-----+-------+ Private Endpoint +------------------+
| Your VNet | ----------------------> | Event Hub |
| | | Namespace |
| App Service | | (no public IP) |
| AKS Cluster | +------------------+
| Azure VM |
+--------------+
With Private Endpoint:
- Event Hub gets a private IP in your VNet
- No public internet exposure
- Traffic stays within Azure backbone
IP Firewall Rules
For simpler setups without private endpoints, add IP firewall rules to allow only trusted IP addresses.
Event Hub Namespace → Networking → Public Access
→ Add Firewall Rule:
IP Range: 203.0.113.0/24 (your office IP range)
IP Range: 198.51.100.5 (your CI/CD server)
All other IPs → blocked
Encryption
Encryption in Transit
Both Event Grid and Event Hub enforce TLS 1.2 or higher for all connections. All data transmitted over HTTPS or AMQP is encrypted. There is no option to disable this.
Encryption at Rest
Events stored in Event Hub (within the retention window) are encrypted at rest by default using Microsoft-managed keys. For higher compliance requirements, use Customer-Managed Keys (CMK).
Default: Microsoft-Managed Keys → Azure manages the encryption keys → Zero configuration needed → Keys rotated automatically Customer-Managed Keys (CMK): → You manage keys in Azure Key Vault → Full control over key lifecycle → Required for some compliance certifications → Available on Premium and Dedicated tiers
Event Grid Webhook Security
Webhook Security Layers: Layer 1: HTTPS Only - Event Grid only delivers to HTTPS endpoints - Plain HTTP endpoints are rejected Layer 2: Endpoint Ownership Validation - Subscription validation handshake confirms you own the URL - Prevents event delivery to URLs you don't control Layer 3: Shared Secret / Query Parameter - Add secret token to webhook URL - Your endpoint checks the token on every request Layer 4: Azure AD Authentication - Event Grid sends JWT bearer token with each delivery - Your endpoint validates the token signature and claims Layer 5: IP Allowlisting - Restrict your webhook to accept requests only from Event Grid IP ranges - Block all other sources at the firewall or API gateway
Audit Logging
Enable Azure Activity Log and Diagnostic Logs for both services to capture:
| Event Type | What Gets Logged |
|---|---|
| Management operations | Who created/deleted topics, subscriptions, or namespaces |
| Access key operations | Who regenerated access keys and when |
| Network rule changes | Who modified firewall or private endpoint settings |
| Delivery failures | Which events failed and why (for Event Grid) |
| Authorization failures | Failed authentication attempts |
Send all logs to a Log Analytics Workspace and set alerts for suspicious activity like repeated authorization failures.
Security Checklist
| Area | Recommended Action |
|---|---|
| Authentication | Use Managed Identity or Azure AD — avoid access keys in production |
| Authorization | Assign minimum required RBAC role per application |
| Network | Use private endpoints or IP firewall rules to restrict access |
| Encryption at rest | Use CMK for compliance-sensitive workloads |
| Webhook security | Add shared secret and validate on every request |
| Key rotation | Rotate SAS keys and access keys regularly |
| Audit logs | Enable diagnostic logging and route to Log Analytics |
| TLS | Enforce TLS 1.2 minimum on client applications |
Summary
Securing Event Grid and Event Hub involves authentication, authorization, network isolation, and encryption. Managed Identity removes secret management from producer and consumer applications. RBAC roles enforce minimum required permissions. Private endpoints or IP firewall rules eliminate public internet exposure. Webhooks need endpoint validation and shared secret checks. Customer-managed encryption keys satisfy high-compliance requirements. Audit logs capture all administrative actions and delivery events for investigation and compliance reporting.