Azure Sentinel ile SIEM Kurulumu ve Yapılandırması

Tarafındankomut
0 Yorum

Güvenlik olaylarını takip etmek, logları analiz etmek ve tehditlere hızlı yanıt vermek artık küçük ekipler için bile zorunlu hale geldi. Şirket içi bir SIEM kurmak ciddi donanım, lisans ve bakım maliyeti demek. Azure Sentinel (artık resmi adıyla Microsoft Sentinel) bu noktada bulut tabanlı, ölçeklenebilir ve görece hızlı kurulabilen bir alternatif sunuyor. Ben bu yazıda sıfırdan bir Sentinel ortamı nasıl kurulur, hangi veri kaynaklarını bağlarsınız, analitik kuralları nasıl yazarsınız ve maliyet kontrolünü nasıl sağlarsınız bunların hepsini adım adım ele alacağım.

Azure Sentinel Nedir ve Neden Kullanmalısınız

Microsoft Sentinel, Azure üzerinde çalışan bir bulut tabanlı SIEM (Security Information and Event Management) ve SOAR (Security Orchestration, Automated Response) platformudur. Geleneksel SIEM’lerden farkı şu: altyapı yönetimi sizin sorununuz değil. Sunucu kurmak yok, storage yönetmek yok, patch uygulamak yok. Siz sadece veriyi bağlıyorsunuz ve analiz ediyorsunuz.

Gerçek hayattan bir örnek verayim: 150 kişilik bir şirkette IT ekibi 2-3 kişiden oluşuyor. Splunk veya QRadar gibi bir çözüm kurmak hem maliyetli hem de o ekip kapasitesiyle yönetilmesi güç. Sentinel burada mantıklı bir seçenek çünkü Pay-As-You-Go modeliyle çalışıyor ve Microsoft 365, Azure AD, Defender gibi araçlarla native entegrasyonu var.

Tabii her şey pembe değil. Log hacmi arttıkça maliyet de artıyor. Bu yüzden yazının sonlarında maliyet optimizasyonuna da mutlaka değineceğim.

Ön Gereksinimler

Başlamadan önce şunların hazır olması gerekiyor:

  • Aktif bir Azure subscription (en azından Contributor yetkisi)
  • Log Analytics Workspace oluşturma yetkisi
  • Bağlamak istediğiniz sistemlere erişim (Azure AD, Windows/Linux sunucular, firewall vb.)
  • Eğer şirket ortamındaysanız, güvenlik ekibiyle koordinasyon

Azure CLI kurulu değilse önce onu kurun:

# Ubuntu/Debian
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# RHEL/CentOS
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo dnf install azure-cli

# Kurulum sonrasi login
az login
az account set --subscription "SubscriptionID_buraya"

Log Analytics Workspace Oluşturma

Sentinel, Log Analytics Workspace üzerine oturuyor. Her şeyden önce bu workspace’i oluşturmanız gerekiyor. Resource Group da oluşturuyoruz ki her şey organize olsun:

# Resource Group olusturma
az group create 
  --name rg-sentinel-prod 
  --location westeurope

# Log Analytics Workspace olusturma
az monitor log-analytics workspace create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --location westeurope 
  --sku PerGB2018 
  --retention-time 90

# Workspace ID ve Primary Key al (connector kurulumlari icin lazim olacak)
az monitor log-analytics workspace show 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --query "{WorkspaceID:customerId, SKU:sku}" 
  --output json

Retention süresini 90 gün olarak ayarladım. Compliance gereksinimlerinize göre bunu artırabilirsiniz ama her ek günün maliyeti var. 90 gün sonrası için daha ucuz olan Archive tier‘a geçiş yapabilirsiniz.

Azure Sentinel’i Aktive Etme

Workspace hazırsa Sentinel’i bu workspace üzerine aktive ediyoruz:

# Sentinel extension'ini ekle
az extension add --name sentinel

# Sentinel'i workspace'e bagli olarak aktive et
az sentinel workspace onboard 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod

# Dogrulama
az sentinel workspace show 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod

Portal üzerinden de yapabilirsiniz: Azure Portal > Microsoft Sentinel > Create > Workspace seçin. Ama CLI’yi öğrenmek uzun vadede çok daha verimli, özellikle birden fazla ortam yönetiyorsanız.

Veri Bağlayıcıları (Data Connectors) Kurulumu

Sentinel’in değeri bağladığınız veri kaynaklarıyla doğru orantılı. Ne kadar çok kaynak bağlarsanız korelasyon o kadar güçlü olur. En yaygın kullanılan bağlayıcılara bakalım.

Azure Active Directory Bağlantısı

Azure AD sign-in ve audit logları güvenlik analizinin bel kemiği. Failed login denemeleri, imkansız seyahat uyarıları, şüpheli hesap aktiviteleri hepsi buradan geliyor:

# Azure AD Diagnostic Settings ile Sentinel'e log gonder
az monitor diagnostic-settings create 
  --name "AAD-to-Sentinel" 
  --resource "/subscriptions/$(az account show --query id -o tsv)/providers/microsoft.aad/diagnosticSettings" 
  --workspace "/subscriptions/$(az account show --query id -o tsv)/resourceGroups/rg-sentinel-prod/providers/microsoft.operationalinsights/workspaces/law-sentinel-prod" 
  --logs '[
    {"category": "SignInLogs", "enabled": true},
    {"category": "AuditLogs", "enabled": true},
    {"category": "NonInteractiveUserSignInLogs", "enabled": true},
    {"category": "ServicePrincipalSignInLogs", "enabled": true}
  ]'

Windows Sunuculardan Log Toplama

Şirket ortamında Windows sunucularınız varsa, bunlardan Security Event loglarını almak için MMA (Microsoft Monitoring Agent) veya yeni nesil AMA (Azure Monitor Agent) kullanılıyor. AMA’yı tercih edin, MMA desteği 2024’te bitti:

# Azure Arc ile on-premise Windows sunucuyu Azure'a kaydet (onprem senaryosu icin)
# Once Azure Arc agent'i Windows sunucuya yukleyin, sonra:
az connectedmachine extension create 
  --name "AzureMonitorWindowsAgent" 
  --publisher "Microsoft.Azure.Monitor" 
  --type "AzureMonitorWindowsAgent" 
  --machine-name "WINSERVER01" 
  --resource-group rg-sentinel-prod 
  --location westeurope

# Data Collection Rule olustur - Windows Security Events icin
az monitor data-collection rule create 
  --name "dcr-windows-security-events" 
  --resource-group rg-sentinel-prod 
  --location westeurope 
  --data-flows '[{
    "streams": ["Microsoft-SecurityEvent"],
    "destinations": ["law-sentinel-prod"]
  }]' 
  --log-analytics '[{
    "name": "law-sentinel-prod",
    "workspace-resource-id": "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-sentinel-prod/providers/microsoft.operationalinsights/workspaces/law-sentinel-prod"
  }]'

Linux Sunuculardan Syslog Toplama

Linux tarafı için Syslog connector’ı veya CEF (Common Event Format) kullanılıyor. Firewall ve IDS cihazları genellikle CEF formatında log gönderiyor:

# Linux sunucuda syslog ayarlari (rsyslog icin)
sudo bash -c 'cat >> /etc/rsyslog.conf << EOF

# Azure Sentinel - Forward to Log Analytics
auth,authpriv.*     @127.0.0.1:25226
cron.*              @127.0.0.1:25226
daemon.*            @127.0.0.1:25226
kern.*              @127.0.0.1:25226
EOF'

sudo systemctl restart rsyslog

# AMA agent kurulumu (Linux)
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
sudo sh onboard_agent.sh 
  -w YOUR_WORKSPACE_ID 
  -s YOUR_PRIMARY_KEY 
  -d opinsights.azure.com

KQL ile Analitik Kurallar Yazma

Sentinel’in kalbi KQL (Kusto Query Language). Log sorgulamak, tehdit tespiti yapmak, dashboard oluşturmak için KQL bilmek şart. Birkaç gerçekçi senaryo üzerinden gidelim.

Başarısız Login Denemelerini Tespit Etme

Bu klasik bir brute force detection senaryosu. 10 dakika içinde aynı IP’den 10’dan fazla başarısız giriş denemesi geliyorsa uyarı üret:

// Kural adi: Brute Force Login Detection
// Log Analytics > Sentinel > Analytics > Create > Scheduled Query Rule

SigninLogs
| where TimeGenerated > ago(10m)
| where ResultType != "0"  // 0 = basarili login
| summarize
    FailedAttempts = count(),
    DistinctUsers = dcount(UserPrincipalName),
    UserList = make_set(UserPrincipalName)
    by IPAddress, bin(TimeGenerated, 10m)
| where FailedAttempts >= 10
| extend
    Severity = case(
        FailedAttempts >= 50, "High",
        FailedAttempts >= 20, "Medium",
        "Low"
    )
| project TimeGenerated, IPAddress, FailedAttempts, DistinctUsers, UserList, Severity
| order by FailedAttempts desc

İmkansız Seyahat Tespiti

Aynı kullanıcı kısa süre içinde farklı coğrafi konumlardan login olduysa bu ciddi bir tehdit işareti:

// Impossible Travel Detection
let timeDelta = 1h;
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| project
    UserPrincipalName,
    TimeGenerated,
    Location,
    IPAddress,
    Latitude = toreal(LocationDetails.geoCoordinates.latitude),
    Longitude = toreal(LocationDetails.geoCoordinates.longitude)
| sort by UserPrincipalName asc, TimeGenerated asc
| serialize
| extend
    PrevLocation = prev(Location, 1),
    PrevTime = prev(TimeGenerated, 1),
    PrevUser = prev(UserPrincipalName, 1),
    PrevLat = prev(Latitude, 1),
    PrevLon = prev(Longitude, 1)
| where UserPrincipalName == PrevUser
| extend TimeDiff = datetime_diff('minute', TimeGenerated, PrevTime)
| where TimeDiff < 60 and Location != PrevLocation
| project
    UserPrincipalName,
    FirstLogin = PrevTime,
    FirstLocation = PrevLocation,
    SecondLogin = TimeGenerated,
    SecondLocation = Location,
    TimeDifferenceMinutes = TimeDiff
| where isnotempty(FirstLocation) and isnotempty(SecondLocation)

Privilege Escalation Tespiti

Birisi kendine birden fazla Azure rolü atadıysa veya Global Admin rolüne eklenme olduysa anında haber almak istiyoruz:

// Privilege Escalation - Role Assignment Detection
AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName has "Add member to role"
    or OperationName has "Add eligible member to role"
| extend
    TargetUser = tostring(TargetResources[0].userPrincipalName),
    RoleName = tostring(TargetResources[0].displayName),
    InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)
| where RoleName in (
    "Global Administrator",
    "Privileged Role Administrator",
    "Security Administrator",
    "Exchange Administrator"
)
| project
    TimeGenerated,
    TargetUser,
    RoleName,
    InitiatedBy,
    Result,
    CorrelationId

Bu kuralları Sentinel üzerinde Scheduled Analytics Rule olarak kaydettiğinizde, her X dakikada bir otomatik çalışıyor ve koşul sağlandığında incident oluşturuyor.

Playbook ile Otomatik Yanıt (SOAR)

Tespit etmek yetmez, yanıt vermek de lazım. Sentinel’de Logic Apps tabanlı Playbook’lar otomatik yanıt için kullanılıyor. Örneğin, brute force tespitinde kullanıcıyı otomatik block edin ve Teams kanalına bildirim gönderin:

# Playbook icin Managed Identity olustur ve gerekli izinleri ver
az identity create 
  --name "sentinel-playbook-identity" 
  --resource-group rg-sentinel-prod

IDENTITY_ID=$(az identity show 
  --name "sentinel-playbook-identity" 
  --resource-group rg-sentinel-prod 
  --query principalId -o tsv)

# Azure AD'de kullanici yonetimi icin izin ver
az role assignment create 
  --assignee $IDENTITY_ID 
  --role "Security Reader" 
  --scope "/subscriptions/$(az account show --query id -o tsv)"

# User Account Administrator rolunu AAD'de ver (portal uzerinden)
# Azure AD > Roles and Administrators > User Account Administrator

Logic Apps JSON template ile playbook tanımını yapıyorsunuz. Basit bir Teams notification playbook’u şöyle başlar:

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "triggers": {
      "Microsoft_Sentinel_incident": {
        "type": "ApiConnectionWebhook",
        "inputs": {
          "host": {
            "connection": {
              "name": "@parameters('$connections')['azuresentinel']['connectionId']"
            }
          },
          "path": "/incident-creation"
        }
      }
    },
    "actions": {
      "Post_Teams_Message": {
        "type": "ApiConnection",
        "inputs": {
          "host": {
            "connection": {
              "name": "@parameters('$connections')['teams']['connectionId']"
            }
          },
          "method": "post",
          "path": "/beta/teams/TEAM_ID/channels/CHANNEL_ID/messages",
          "body": {
            "content": {
              "contentType": "html",
              "content": "<b>Sentinel Alert:</b> @{triggerBody()?['object']?['properties']?['title']}<br>Severity: @{triggerBody()?['object']?['properties']?['severity']}"
            }
          }
        }
      }
    }
  }
}

Maliyet Yönetimi ve Optimizasyon

Bu konu çok kritik. Sentinel maliyeti temelde iki unsurdan oluşuyor: veri alımı (ingestion) ve veri saklama (retention). Veri alımı GB başına ücretlendirildiği için hangi logları aldığınıza çok dikkat etmeniz gerekiyor.

Maliyet optimizasyonu için uygulamanız gerekenler:

  • Commitment Tier kullanın: 100 GB/gün ve üzeri alımda Commitment Tier (önceki adıyla Capacity Reservation) Pay-As-You-Go’ya göre %30-60 daha ucuz olabiliyor
  • Gereksiz log kategorilerini kapatın: Her şeyi almak zorunda değilsiniz. Verbose audit logları yerine sadece Security eventlerini alın
  • Ingestion-time filtering kullanın: DCR (Data Collection Rules) ile loglar workspace’e girmeden önce filtreleyin
  • Archive Tier’ı değerlendirin: 90 günden eski loglar için interactive sorgu yerine Archive Tier çok daha ucuz
  • Custom table vs built-in table: CEF formatındaki bazı loglar için Custom Log Table kullanmak daha ucuz olabiliyor

Aylık ne kadar log aldığınızı izleyin:

// Son 30 gundeki toplam ingestion (GB cinsinden)
Usage
| where TimeGenerated > startofday(ago(30d))
| where IsBillable == true
| summarize
    TotalGB = round(sum(Quantity) / 1024, 2),
    DailyAvgGB = round(sum(Quantity) / 1024 / 30, 2)
    by DataType
| order by TotalGB desc
| take 20

Bu sorguyu düzenli çalıştırın. Hangi tablo en çok veri yiyor görün. Genellikle CommonSecurityLog (CEF logları) ve Syslog en büyük yer kaplayanlar. Bu tablolarda gereksiz verbose logları fark ederseniz DCR filtrelemesine alın.

Workspace’i Organize Etmek: RBAC ve Yapılandırma

Sentinel’e birden fazla kişi erişecekse roller önemli. Least privilege prensibini uygulayın:

# SOC Analyst icin okuma yetkisi
az role assignment create 
  --assignee "[email protected]" 
  --role "Microsoft Sentinel Reader" 
  --scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-sentinel-prod/providers/microsoft.operationalinsights/workspaces/law-sentinel-prod"

# SOC Lead icin incident yonetim yetkisi
az role assignment create 
  --assignee "[email protected]" 
  --role "Microsoft Sentinel Responder" 
  --scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-sentinel-prod/providers/microsoft.operationalinsights/workspaces/law-sentinel-prod"

# Sentinel yonetici
az role assignment create 
  --assignee "[email protected]" 
  --role "Microsoft Sentinel Contributor" 
  --scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-sentinel-prod/providers/microsoft.operationalinsights/workspaces/law-sentinel-prod"

Microsoft Sentinel Reader: Sadece okuyabilir, incident görebilir Microsoft Sentinel Responder: Incident atayabilir, kapatabilir, playbook tetikleyebilir Microsoft Sentinel Contributor: Kural yazabilir, bağlayıcı ekleyebilir, her şeyi yönetebilir

Content Hub’dan Hazır Çözümler

Sıfırdan her şeyi yazmak zorunda değilsiniz. Sentinel Content Hub’da yüzlerce hazır analytic rule, workbook ve playbook var. Microsoft Defender for Endpoint, Fortinet, Palo Alto, AWS, GitHub gibi pek çok vendor için hazır paketler mevcut.

Portal üzerinden: Microsoft Sentinel > Content Hub > aradığınız vendor veya ürün. Oradan “Install” deyin, ilgili connector, analytic rules ve workbook’lar otomatik gelsin.

CLI ile de content yönetimi yapabilirsiniz:

# Mevcut content solution listesi
az sentinel metadata list 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --query "[].{Name:name, Kind:kind, Version:version}" 
  --output table

Gerçek Dünya Senaryosu: Ransomware Öncesi İşaretler

Bir müşteri ortamında yaşanan olaydan ilham alan bu senaryoyu paylaşayım. Ransomware saldırılarından önce genellikle şu işaretler oluyor: toplu dosya şifreleme, shadow copy silme, lateral movement, C2 iletişimi. Bunları Sentinel’de yakalamak için:

// Shadow Copy silme girisimleri - Ransomware on-indicator
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4688  // Process Creation
| where CommandLine has_any (
    "vssadmin delete shadows",
    "wmic shadowcopy delete",
    "bcdedit /set recoveryenabled no",
    "wbadmin delete catalog"
)
| project
    TimeGenerated,
    Computer,
    Account,
    CommandLine,
    ParentProcessName
| extend AlertSeverity = "High"
| extend TTP = "T1490 - Inhibit System Recovery"

Bu kural MITRE ATT&CK framework’ündeki T1490 tekniğini kapsıyor. Sentinel analytic rule’larınızı yazarken MITRE ATT&CK taktik ve tekniklerini etiket olarak eklemenizi öneririm. Hem raporlama hem de tehdit modelleme için çok işe yarıyor.

Incidents Yönetimi ve SOC Workflow

Analitik kurallar tetiklendiğinde Sentinel otomatik olarak Incident oluşturuyor. Bunları yönetmek için bir workflow kurmanız şart:

  • Triage: Yeni gelen incident’ları öncelik sırasına koy
  • Atama: Analistlere dağıt
  • Investigation: Entity mapping ile kullanıcı, IP, host ilişkilerini incele
  • Response: Playbook tetikle veya manuel aksiyon al
  • Close: False positive, true positive olarak kategorize et ve not ekle

Incident durumlarını API ile de yönetebilirsiniz. Örneğin ticket sisteminizle entegrasyon için:

# Sentinel incident listesi - son 24 saatteki aktif incidentlar
az sentinel incident list 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --filter "properties/status eq 'New'" 
  --query "[].{ID:name, Title:properties.title, Severity:properties.severity, Status:properties.status}" 
  --output json

# Incident guncelleme - atama ve durum degisikligi
az sentinel incident update 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --incident-id "INCIDENT_ID" 
  --status "Active" 
  --owner '{"assignedTo": "[email protected]"}'

Sonuç

Azure Sentinel kurulumu ilk bakışta karmaşık görünse de adım adım gittiğinizde oldukça yönetilebilir. Önce Log Analytics Workspace ve Sentinel’i aktive edin, ardından en kritik veri kaynaklarını bağlayın, temel analitik kuralları yazın veya Content Hub’dan alın, sonra playbook’larla yanıtı otomatize etmeye başlayın.

En sık yapılan hata şu: Her şeyi bağlayıp her logu almaya çalışmak. Bu hem maliyeti patlatır hem de gürültü artınca gerçek tehditleri gözden kaçırırsınız. Önce “ne görmem gerekiyor?” sorusunu yanıtlayın, ardından sadece o kaynakları bağlayın. Kademeli genişleyin.

KQL öğrenmeye zaman ayırın, bu gerçekten kritik. Hazır kurallar bir noktaya kadar işe yarıyor ama ortamınıza özgü tehditleri ancak kendi yazdığınız sorgularla yakalarsınız. Kusto Query Language mantığını kavradıktan sonra hem Sentinel’de hem de Azure Monitor’da hayatınız kolaylaşıyor.

Maliyet takibini baştan oturtun. Ayda bir Usage sorgusunu çalıştırın, hangi tablonun ne kadar veri yediğini görün. Commitment Tier değerlendirmesini log hacminiz netleştikten sonra yapın, ilk ay Pay-As-You-Go’da kalın.

Son olarak: Sentinel bir araç, güvenlik kültürü değil. Aracı kurdunuz, şimdi asıl iş başlıyor. Düzenli kural review, false positive fine-tuning ve incident response tatbikatları olmadan en iyi SIEM bile size fazla katma değer sağlamaz.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir