> For the complete documentation index, see [llms.txt](https://docs.blusapphire.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blusapphire.io/log-forwarding/03_log-forwarding-guide/cloud-log-forwarding/azure-microsoft/azure-activity-logs.md). # Azure Activity Logs Integration Guide for **Azure Activity Logs** with **BluSapphire SIEM** **1. Prerequisites** | **Item** | **Details** | | ------------------------ | ------------------------------------------------------------------------------------------------ | | **Azure subscription** | Contributor or Owner access, or at minimum Microsoft.Insights/DiagnosticSettings/Write | | **Event Hub Namespace** | Standard tier or higher (Basic tier does not support multiple consumer groups) | | **Event Hub** | Dedicated Event Hub instance for Activity Logs (recommended: don't mix with other log types) | | **Shared Access Policy** | A policy on the Event Hub with Listen permission for BluSapphire to consume | | **Consumer Group** | Dedicated consumer group created for BluSapphire (avoid using $Default if other consumers exist) | **2. Configuration Steps** **Step 1 — Create an Event Hub Namespace and Event Hub** 1. In the Azure Portal, go to Event Hubs → Create Namespace. 2. Choose Standard tier (minimum) to support multiple consumer groups and higher throughput. 3. Inside the namespace, create an Event Hub (e.g., activity-logs-eh). 4. Create a dedicated Consumer Group (e.g., blusapphire-cg) under this Event Hub. **Step 2 — Create a Shared Access Policy for BluSapphire** 1. Navigate to the Event Hub → Shared Access Policies. 2. Create a new policy (e.g., blusapphire-listen) with Listen permission only (principle of least privilege). 3. Copy the Connection String – Primary Key; this will be used in BluSapphire's collector configuration. **Step 3 — Configure Diagnostic Settings on the Subscription (Activity Log)** 1. Go to Monitor → Activity Log → Export Activity Logs (or Subscription → Diagnostic settings). 2. Click Add diagnostic setting. 3. Select the log categories to stream (see Section 6 — recommend enabling all categories for full SOC visibility, at minimum Administrative, Security, Policy, Alert). 4. Under Destination details, select Stream to an event hub. 5. Choose the Event Hub namespace and Event Hub created in Step 1. 6. Save the configuration. ***Note:*** *Diagnostic settings for Activity Log are configured per subscription. If you have multiple subscriptions in scope under one Azure tenant, repeat this for each one (or automate via ARM/Bicep/Terraform/Azure Policy for consistency at scale).* **3. Azure Activity Log Categories — Description & SOC Importance**


Log Category	What It Contains	SOC Importance	Why
Administrative	All create, update, delete, and action operations performed via Resource Manager (e.g., role assignments, resource creation/deletion, NSG changes, VM operations)	Critical	Primary source of control-plane activity. Almost all attacker actions post-compromise (privilege escalation, persistence, resource abuse, exfil infrastructure setup) show up here first. Essential for detecting unauthorized configuration changes.
Security	Alerts generated by Azure Security Center / Microsoft Defender for Cloud (e.g., suspicious process execution, malware detection, brute-force attempts)	Critical	Direct security detections from Microsoft's native threat detection engine. High-fidelity signal for active threats; should feed directly into SOC alerting/correlation rules.
Policy	Results of Azure Policy evaluations (audit, deny, effect actions) — records when a resource is evaluated against a policy definition	High	Tracks compliance posture and policy violations. Useful for detecting drift from security baselines and unauthorized attempts to bypass guardrails.
Alert	Activity generated by Azure Monitor Alerts (metric alerts, log alerts, activity log alerts firing/resolving)	High	Provides operational and security alert lifecycle visibility. Important for correlating downstream automated responses and verifying alert-to-incident workflows.
ServiceHealth	Microsoft-initiated notifications about Azure service incidents, planned maintenance, and health advisories affecting your resources	Medium	Not a security signal by itself, but helps the SOC distinguish platform outages from real incidents, reducing false-positive investigations.
ResourceHealth	Health status changes of individual resources (available, unavailable, degraded) as detected by Azure	Medium	Helps correlate resource downtime with potential DoS conditions, misconfigurations, or malicious resource manipulation.
Recommendation	Azure Advisor recommendations (cost, performance, reliability, security best practices)	Low	Primarily a hygiene/optimization signal, not a real-time threat indicator. Useful for periodic security posture review rather than active SOC alerting.
Autoscale	Events related to autoscale engine actions (scale-out/scale-in operations and the reasons behind them)	Low	Mostly operational telemetry. Minor security relevance (e.g., abnormal scale-out could indicate resource-abuse/cryptomining), but a secondary/contextual signal.

**Priority Summary for SOC Onboarding** 1. Must-have (Critical): Administrative, Security 2. Should-have (High): Policy, Alert 3. Good-to-have (Medium): ServiceHealth, ResourceHealth — mainly for noise reduction/context 4. Optional (Low): Recommendation, Autoscale — enable if log volume/licensing allows, useful for enrichment and anomaly baselining rather than direct alerting