Microsoft Sentinel: Workspaces, Roles, Data Connectors, Content Hub
The Microsoft Sentinel foundations: Log Analytics workspaces, Sentinel-specific RBAC roles, data connectors for Azure resources, and the Content Hub solutions that package analytics rules, workbooks, hunting queries, and playbooks per source.
Sentinel, the SIEM that builds on Log Analytics
Microsoft Sentinel is Azure’s native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response). It runs on top of a Log Analytics workspace — Sentinel is essentially “Log Analytics workspace + analytics rules + automation + content”.
Four SC-500 foundations:
- Workspace + Sentinel enablement — a Log Analytics workspace exists; Sentinel is enabled on it; Sentinel-specific tables and features become available.
- Sentinel roles — Sentinel-specific RBAC roles (Reader, Responder, Contributor, Automation Contributor, Playbook Operator) on top of the underlying Log Analytics Contributor/Reader.
- Data connectors — the ingestion machinery for getting telemetry IN from Azure resources (diagnostic settings → Log Analytics → Sentinel), Microsoft services (Defender XDR, Entra ID, Office 365, Defender for Cloud), and third parties (AWS, GCP, syslog, CEF).
- Content Hub — the catalogue of pre-built Sentinel solutions per source: analytics rules, workbooks, hunting queries, parsers, playbooks. One-click install per source.
Workspace + Sentinel
Sentinel is enabled per Log Analytics workspace. Key workspace decisions:
- Region — determines where data is stored. Choose by data residency requirements.
- Pricing tier — Pay-as-you-go (per GB ingested) or Commitment Tiers (discounted, pre-purchased capacity).
- Retention — 30 to 730 days in the Analytics tier. Beyond 730 days requires the new Auxiliary or Data Lake tiers (different cost/queryability trade-offs).
- Daily cap — optional ingestion ceiling per day to prevent runaway bills.
- Network access — enable Private Link / private endpoint to restrict workspace access to private networks only.
Once enabled, Sentinel adds the Sentinel-specific features (analytics, automation, content hub) on top of the underlying workspace.
Sentinel-specific roles
| Sentinel role | What it grants |
|---|---|
| Microsoft Sentinel Reader | View Sentinel artifacts (incidents, analytics rules, workbooks, hunting queries, watchlists, automation rules). Cannot modify. |
| Microsoft Sentinel Responder | Reader rights, plus manage incidents — assign, comment, close — and run playbooks against incidents and entities. |
| Microsoft Sentinel Contributor | Responder rights, plus create/edit analytics rules, workbooks, hunting queries, watchlists, and automation rules. |
| Microsoft Sentinel Automation Contributor | Manage automation rules (create, edit, configure triggers and actions). Used by SOC engineering staff who tune the automation but not the analytics. |
| Microsoft Sentinel Playbook Operator | Run playbooks manually (against an incident or entity) but not create/edit them. Used by SOC analysts who need to invoke pre-built playbooks. |
These layer on top of Log Analytics Reader (for workspace query access) and Logic Apps Contributor (for playbook execution / management). For SC-500, know which Sentinel role fits the persona: a tier-1 SOC analyst typically gets Sentinel Responder + Log Analytics Reader; a SOC engineer building detections gets Sentinel Contributor; a senior SOC lead might get Sentinel Contributor + Automation Contributor + Playbook Operator.
Data connectors for Azure resources
The pattern for Azure resources: each Azure resource has diagnostic settings that can send logs and metrics to a Log Analytics workspace (and/or Event Hub for streaming, and/or Storage for archive). Configure the diagnostic setting to send the desired log categories to your Sentinel workspace; the data lands in named tables (e.g. AzureActivity, KeyVaultLogs, AppServiceHTTPLogs).
Sentinel’s Data connectors gallery offers per-source connectors that may package:
- A Sentinel-side configuration step (e.g. enabling the Defender XDR connector to pull M365 Defender data)
- A guided source-side configuration (instructions for enabling the right diagnostic categories)
- A linked Content Hub solution that includes analytics rules and workbooks tailored to the source
Common Microsoft data connectors
| Connector | Source | Notes |
|---|---|---|
| Azure Activity | Azure subscription control-plane operations | Foundational — enable across all subscriptions in scope |
| Microsoft Defender XDR | M365 Defender (Endpoint, Office 365, Identity, Cloud Apps) + Defender for Cloud incidents | Brings Defender XDR incidents and entities into Sentinel for SOC-grade enrichment and automation |
| Microsoft Entra ID | Sign-in logs, audit logs, provisioning, risky users/events | Critical for identity-focused detections |
| Microsoft Defender for Cloud (legacy) | Alerts from Defender for Cloud workload protection plans | Largely superseded by the Defender XDR connector when the Defender XDR ↔ Defender for Cloud integration is enabled |
| Office 365 | Exchange, SharePoint, Teams audit logs | Office 365 management activity in Sentinel |
| Microsoft Purview (legacy connector evolving) | Purview Information Protection, DLP, Insider Risk | Purview's data security signals in Sentinel |
| Azure resource (per-service) | Key Vault, Storage, SQL, App Service, etc. | Via diagnostic settings to the Sentinel workspace |
| Amazon Web Services / GCP | AWS CloudTrail, GuardDuty, VPC Flow Logs / GCP Audit / Security Command Center | Multi-cloud ingestion for SOC visibility — complements the Defender for Cloud multicloud connectors (which give posture + workload protection) |
Content Hub
Content Hub is the marketplace of pre-built Sentinel content. Each solution packages:
- Analytics rules — scheduled, NRT, ML-driven, anomaly-based detections tuned to the source
- Workbooks — pre-built dashboards for the source data
- Hunting queries — KQL queries for proactive threat hunting
- Parsers — KQL functions that normalise custom log formats into standard schemas
- Playbooks — Logic Apps that automate response to alerts from the solution
A typical SC-500 deployment pattern: enable the data connector for the source, install the matching Content Hub solution, review and tune the analytics rules (most ship Disabled by default to avoid alert storms — turn on the high-signal ones first).
Solutions are versioned and updated by Microsoft and partners; updates flow through Content Hub.
Scenario: Dom stands up Sentinel for a new MSSP customer
Kestrel Cyber Co-op onboards a new client (a 200-user fintech). Dom’s standup:
- Workspace: new Log Analytics workspace in the client’s tenant, region matching their data residency, 90-day retention, daily cap of 50 GB to protect against runaway bills.
- Sentinel enabled on the workspace.
- Sentinel roles:
- Client’s internal IT lead: Sentinel Reader.
- Kestrel tier-1 analysts: Sentinel Responder + Log Analytics Reader (via Azure Lighthouse delegation from the client tenant to Kestrel’s tenant).
- Kestrel SOC engineers: Sentinel Contributor + Automation Contributor + Playbook Operator (via Lighthouse).
- Data connectors:
- Azure Activity across all client subscriptions
- Microsoft Defender XDR (M365 + Defender for Cloud incidents)
- Microsoft Entra ID (sign-in, audit, risky users)
- Office 365 (Exchange, SharePoint, Teams audit)
- Key Vault, Storage, SQL diagnostic settings on critical resources
- AWS CloudTrail (client has 2 AWS accounts)
- Content Hub solutions installed: Microsoft Entra ID, Microsoft Defender XDR, Office 365, Azure Activity, Microsoft Defender for Cloud, AWS, plus the Threat Intelligence solution. ~120 analytics rules ship; Dom enables 35 of them (the high-signal ones) and queues the rest for later tuning.
Day-1 Sentinel: ingestion live, analytics rules firing, incidents flowing to Defender XDR (and bidirectionally back), automation rules deferred to module 27.
Key terms
Knowledge check
Dom at Kestrel Cyber Co-op needs his tier-1 SOC analysts to view all Sentinel incidents, change incident status, comment, and run pre-built playbooks against incidents — but NOT to create new analytics rules or modify playbooks. Which combination fits?
Esme at Northwind Bank is enabling Microsoft Sentinel detections for the bank's Azure Key Vaults. She wants to ingest Key Vault audit logs and apply the matching Microsoft-published detections. What's the SC-500 right sequence?
Asha at Aurora Health Service is enabling Sentinel for the first time. She wants to bring in Microsoft Defender XDR incidents (including Defender for Cloud alerts) AND Microsoft Entra ID sign-in/audit data. Which two data connectors should she enable?
What’s next
Next module covers Sentinel event collection at scale — Syslog and CEF ingestion via the Linux Azure Monitor agent, Windows Security event collection via Data Collection Rules and Windows Event Forwarding (WEF), and creating custom log tables to store ingested data.