Tags: Sentinel · SIEM · SOAR · Azure · KQL · Log Analytics · Threat Detection

Por Duarte Spínola · 5 de Julho de 2026

Microsoft Sentinel: SIEM e SOAR para PMEs em 2026

O Microsoft Sentinel é a solução cloud-native de SIEM (Security Information and Event Management) e SOAR (Security Orchestration, Automation and Response) da Microsoft. Corre sobre Azure Log Analytics e usa KQL (Kusto Query Language) para detectar ameaças. Este guia cobre arquitectura, data connectors, regras de detecção, incidentes, automation e custos para PMEs, com base na documentação oficial.

Para complementar, consulta os artigos sobre Defender para Endpoint, Zero Trust, Grafana, Segurança AD e Azure IaaS Custos.

Conteúdos

• 1. O Que é o Microsoft Sentinel
• 2. SIEM vs SOAR: Qual a Diferença
• 3. Arquitectura do Sentinel
• 4. Data Connectors
• 5. Log Analytics Workspace
• 6. KQL: Kusto Query Language
• 7. Regras de Detecção
• 8. Incidentes e Investigação
• 9. Workbooks (Dashboards)
• 10. Automation Rules e Playbooks
• 11. Custos e Licenciamento PME
• 12. Cenário Prático PME
• 13. Boas Práticas
• 14. Checklist de Implementação

1. O Que é o Microsoft Sentinel

O Sentinel é uma plataforma de segurança cloud-native que agrega logs de múltiplas fontes (Microsoft 365, Azure, on-premise, terceiros), detecta ameaças com regras analíticas e responde automaticamente com playbooks de automação.

2. SIEM vs SOAR: Qual a Diferença

O Sentinel combina ambos: detecta (SIEM) e responde (SOAR) numa só plataforma.

3. Arquitectura do Sentinel

# Arquitectura:
# Fontes → Data Connectors → Log Analytics Workspace → Sentinel
#   ↓                                          ↓
# Analytics Rules → Incidentes → Investigação → Playbooks (automacao)
#
# Fontes suportadas:
# - Microsoft 365 (Exchange, Teams, SharePoint, OneDrive)
# - Microsoft Entra ID (sign-in logs, audit logs)
# - Microsoft Defender para Endpoint/Office/Identity
# - Azure Activity Log
# - Windows Event Forwarding (WEF) via AMA agent
# - Syslog (Linux, firewalls, network devices)
# - AWS CloudTrail
# - Terceiros (Okta, Palo Alto, Cisco, Fortinet, etc.)

# Criar Sentinel via Azure CLI
az sentinel create \
  --resource-group rg-security \
  --workspace-name log-analytics-empresa \
  --sku PerGB

4. Data Connectors

# No portal Sentinel > Data connectors
# Os conectores mais importantes para PME:

# 1. Microsoft Entra ID — sign-in logs, audit logs, risky users
# 2. Microsoft 365 — Exchange, Teams, SharePoint
# 3. Defender para Endpoint — alertas, dispositivos
# 4. Defender para Office 365 — email threats
# 5. Windows Security Events via AMA — Event IDs 4624, 4625, 4688, etc.
# 6. Azure Activity Log — operações Azure
# 7. Syslog — firewalls, routers, Linux

# Verificar conectores activos via PowerShell
Connect-AzAccount
Get-AzSentinelDataConnector -ResourceGroupName rg-security -WorkspaceName log-analytics-empresa

# Activar conector Entra ID
Set-AzSentinelDataConnector -ResourceGroupName rg-security `
  -WorkspaceName log-analytics-empresa `
  -ConnectorName "AzureActiveDirectory" `
  -Enabled $true

5. Log Analytics Workspace

# Criar Log Analytics Workspace via Azure CLI
az monitor log-analytics workspace create \
  --resource-group rg-security \
  --workspace-name log-analytics-empresa \
  --location westeurope \
  --sku PerGB2018 \
  --retention-time 90  # dias de retenção

# Verificar
az monitor log-analytics workspace show \
  --resource-group rg-security \
  --workspace-name log-analytics-empresa

# Retenção recomendada por tipo:
# - Security events: 90 dias mínimo (NIS2 recomenda 180)
# - Audit logs: 365 dias
# - Sign-in logs: 30 dias (Entra ID guarda 30)
# - Performance: 30 dias

# Ver volume de dados ingerido (últimos 30 dias)
az monitor log-analytics query \
  --workspace log-analytics-empresa \
  --analytics-query "Usage | summarize sum(Quantity) by DataType | order by sum_Quantity desc"

6. KQL: Kusto Query Language

// KQL básico — procurar logins falhados
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize Count = count() by Account, Computer, IpAddress
| order by Count desc
| take 20

// Logins de utilizadores desactivados
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0  // sucesso
| join kind=inner (
    AadUsers
    | where AccountEnabled == false
    | project UserPrincipalName
) on UserPrincipalName
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location

// Detectar logins de localizações impossíveis
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
| summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated),
         Locations = make_set(Location) by UserPrincipalName
| where array_length(Locations) > 1
| extend TimeDiff = datetime_diff('minute', EndTime, StartTime)
| where TimeDiff < 60  // menos de 1 hora entre localizações diferentes

// Procurar PowerShell executado como admin
SecurityEvent
| where EventID == 4688
| where Process has "powershell.exe"
| where SubjectLogonId has "0x" and ElevatedToken == "Elevated"
| project TimeGenerated, Account, Computer, NewProcessName, CommandLine
| take 50

7. Regras de Detecção (Analytics Rules)

// Regra: Múltiplos logins falhados seguidos de sucesso (brute force)
// Sentinel > Analytics > Create rule > Custom

// Query da regra:
let threshold = 5;
SecurityEvent
| where EventID in (4625, 4624)
| where TimeGenerated > ago(1h)
| summarize FailedAttempts = countif(EventID == 4625),
         SuccessfulLogin = countif(EventID == 4624),
         FirstFail = min(TimeGenerated),
         LastEvent = max(TimeGenerated) by Account, IpAddress
| where FailedAttempts >= threshold and SuccessfulLogin >= 1
| extend TimeWindow = datetime_diff('minute', LastEvent, FirstFail)

// Configuração da regra:
// - Name: Brute Force Detection
// - Severity: Medium
// - Tactics: Credential Access, Initial Access
// - Run every: 1 hour
// - Lookback: 1 hour
// - Alert grouping: 24h (agrupa alertas do mesmo IP)

// Ver regras activas via PowerShell
Get-AzSentinelAlertRule -ResourceGroupName rg-security `
  -WorkspaceName log-analytics-empresa | Select-Object Name, Severity, Tactics

8. Incidentes e Investigação

// Quando uma regra dispara, cria um incidente no Sentinel
// O incidente pode agrupar múltiplos alertas relacionados

// Ver incidentes via KQL
SecurityIncident
| where TimeGenerated > ago(24h)
| where Status != "Closed"
| project IncidentNumber, Title, Severity, Status, Owner, CreatedTime
| order by Severity desc, CreatedTime desc

// Ver incidentes por gravidade
SecurityIncident
| where TimeGenerated > ago(30d)
| summarize Count = count() by Severity
| order by Severity desc

// Investigar um incidente específico
SecurityIncident
| where IncidentNumber == 1234
| project RelatedAlerts, Entities, FirstActivityTime, LastActivityTime

// No portal:
// 1. Sentinel > Incidentes
// 2. Clicar no incidente para ver detalhes
// 3. "Investigação" abre o grafo de entidades (users, IPs, hosts)
// 4. "Acções" permite atribuir, comentar ou fechar

9. Workbooks (Dashboards)

// Workbooks são dashboards interactivos baseados em KQL
// Sentinel tem workbooks pré-definidos:
// - Security Operations Efficiency
// - Identity Information
// - Azure Activity
// - Sign-in Analytics
// - Endpoint Health

// Criar workbook personalizado:
// 1. Sentinel > Workbooks > Add new
// 2. Adicionar parâmetros (time range, subscription)
// 3. Adicionar queries KQL como gráficos
// 4. Publicar para a equipa de segurança

// Exemplo de query para workbook — Top 10 IPs com logins falhados
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago({TimeRange})
| summarize FailedCount = count() by IpAddress
| top 10 by FailedCount
| render barchart

10. Automation Rules e Playbooks

// Automation Rules: acções automáticas quando um incidente é criado
// Playbooks: Logic Apps que executam acções complexas

// Exemplos de Automation Rules:
// 1. Se gravidade = High → atribuir a equipa Tier 2 + enviar email
// 2. Se incidente contém IP conhecido malicioso → bloquear IP no firewall
// 3. Se incidente de phishing → bloquear utilizador + reset password

// Criar Playbook via portal:
// 1. Sentinel > Automation > Create Playbook
// 2. Seleccionar trigger: "When Sentinel incident is triggered"
// 3. Adicionar acções:
//    - Get incident entities
//    - Condition: if Severity == "High"
//    - Send email (Outlook)
//    - Post no Teams channel
//    - Create ticket in ServiceNow/Jira

// Playbook para bloquear utilizador automaticamente
// Logic App:
{
  "trigger": {
    "type": "SentinelIncident",
    "conditions": [{"field": "Severity", "eq": "High"}]
  },
  "actions": [
    {"type": "GetIncidentEntities"},
    {"type": "DisableUser", "connector": "AzureAD"},
    {"type": "RevokeUserSessions", "connector": "AzureAD"},
    {"type": "SendEmail", "to": "[email protected]",
     "subject": "Utilizador bloqueado automaticamente",
     "body": "Incidente: @{triggerBody()?['incidentNumber']}"}
  ]
}

11. Custos e Licenciamento PME

12. Cenário Prático PME

// PME com 50 utilizadores, M365 E5, 2 DCs on-premise
// Volume estimado: ~3GB/dia (incluído no E5)

// 1. Activar Sentinel no workspace Log Analytics
// 2. Activar conectores:
//    - Entra ID (sign-in, audit)
//    - Defender para Endpoint
//    - Defender para Office 365
//    - Windows Security Events (DCs via AMA)
//    - Azure Activity Log

// 3. Activar regras analíticas pré-definidas:
//    - Brute force detection
//    - Impossible travel
//    - Mass download
//    - Password spraying
//    - PowerShell misuse

// 4. Criar automation rule:
//    - Gravidade High → email + Teams + atribuir Tier 2

// 5. Criar workbook:
//    - Dashboard diário de segurança para management

// 6. Configurar retenção 90 dias (NIS2)

// Custo total: 0€ (incluído no E5, <5GB/dia)

13. Boas Práticas

• Filtrar logs na fonte — não enviar logs irrelevantes para poupar custos
• Usar regras pré-definidas — Microsoft fornece 300+ regras
• Configurar alertas por email/Teams — não depender de ver o portal
• Revisão semanal de incidentes — não deixar incidentes abertos
• Retention 90+ dias — NIS2 recomenda 180 dias
• Usar threat intelligence feeds — enriquecer detecção
• Testar playbooks — não activar automação sem testar
• Workspace dedicado — não partilhar com outras cargas

14. Checklist de Implementação

• ☐ Criar Log Analytics Workspace
• ☐ Activar Sentinel no workspace
• ☐ Configurar retenção 90+ dias
• ☐ Activar conector Entra ID
• ☐ Activar conector Defender para Endpoint
• ☐ Activar conector Defender para Office 365
• ☐ Activar conector Windows Security Events (AMA)
• ☐ Activar conector Azure Activity Log
• ☐ Rever regras analíticas pré-definidas
• ☐ Activar 10-15 regras essenciais
• ☐ Criar automation rule para gravidade High
• ☐ Configurar alertas por email
• ☐ Criar workbook de dashboard de segurança
• ☐ Testar com simulação de ataque
• ☐ Documentar procedimentos de resposta

Artigos Relacionados

• Microsoft Defender para Endpoint em PMEs
• Zero Trust para PMEs
• Grafana para PMEs
• Segurança Active Directory
• Azure IaaS: Optimizar Custos Cloud

Baseado na documentação oficial Microsoft Sentinel. Preços aproximados para Azure West Europe, Julho 2026. Licença: CC BY-SA 4.0.