Microsoft Sentinel Nedir? Bulut Tabanlı SIEM Çözümüne Giriş

Microsoft Sentinel Nedir?

Microsoft Sentinel, Microsoft tarafından sunulan bulut tabanlı bir SIEM ve SOAR çözümüdür. Sentinel’in yaptığı işi temel olarak farklı sistemlerden logları tek bir yerde toplamak şeklinde düşünebiliriz. Toplanan bu loglar üzerinde kurallar ve sorgular çalıştırılarak şüpheli aktiviteler tespit edilebilir. Bir alarm oluştuğunda ise Logic Apps gibi servisler kullanılarak bazı müdahale adımları otomatik hale getirilebilir.

Sentinel kullanmak için ortamın tamamen Microsoft ürünlerinden oluşması gerekmez. Entra ID, Microsoft 365 ve Defender gibi Microsoft servislerinden veri alınabildiği gibi firewall, EDR, Linux veya Windows sunucular ve farklı ağ cihazlarının logları da Sentinel’e gönderilebilir. Burada önemli olan ilgili kaynaktan verinin Sentinel tarafına nasıl aktarılacağının belirlenmesidir.

Sentinel’in klasik SIEM ürünlerinden önemli farklarından biri bulut tabanlı olmasıdır. On-prem bir SIEM ortamında sunucu kapasitesi, disk alanı ve platformun altyapısı gibi konularla ayrıca ilgilenmek gerekirken Sentinel’de bu yükün önemli bir kısmı Azure tarafında yönetilir. Bu nedenle operasyon tarafında daha çok hangi logların toplanacağı, detection kurallarının nasıl oluşturulacağı ve alarmlara nasıl müdahale edileceği gibi konulara odaklanılır.

Sentinel Mimarisi Nasıl Çalışır?

Sentinel tarafındaki temel akış aşağıdaki gibi düşünülebilir:

Bu yapıyı anlamanın en kolay yolu, bir logun kaynaktan çıkıp Sentinel’de alarma dönüşene kadar izlediği yolu takip etmektir. Her ortamda bütün bileşenlerin kullanılması gerekmez ancak genel akış bu yapı üzerinden ilerler.

• Data Source: Log üreten sistemdir. Örneğin Entra ID, Windows Server, firewall veya EDR.
• Data Connector: Sentinel ile veri kaynağı arasındaki entegrasyonu sağlar.
• DCR (Data Collection Rule): Özellikle Azure Monitor Agent kullanılan yapılarda hangi verinin nasıl toplanacağını ve nereye gönderileceğini belirler.
• DCE (Data Collection Endpoint): DCE kullanılan veri toplama senaryolarında, verinin Azure Monitor veri toplama altyapısına ulaşacağı endpoint’i sağlar. Özellikle custom log ve Logs Ingestion API senaryolarında DCR ile birlikte karşımıza çıkabilir. DCR verinin nasıl işleneceğini ve nereye gönderileceğini belirlerken, DCE veri toplama için kullanılan bağlantı uç noktasıdır.
• Log Analytics Workspace: Sentinel’in sorguladığı güvenlik verilerinin önemli bir bölümünün tutulduğu çalışma alanıdır.
• KQL: Logların sorgulanması, filtrelenmesi ve korelasyon geliştirilmesi için kullanılan sorgu dilidir.
• Analytics Rule: KQL sorgusu belirli aralıklarla çalıştırılarak şüpheli bir durum aranabilir. Belirlenen koşullar sağlandığında Sentinel bunun üzerinden alert oluşturabilir.
• Incident: İlişkili alert’lerin analistin inceleyebileceği bir güvenlik olayı altında birleştirilmesini sağlar.
• Automation Rule: Incident veya alert üzerinde otomatik aksiyonların ne zaman çalışacağını belirler.
• Playbook: Azure Logic Apps tabanlı müdahale ve orkestrasyon akışıdır.

Örnek Bir Veri Akışı

Örneğin bir Windows Server’dan başarısız oturum açma loglarının toplandığını düşünelim. Bu loglar AMA ve ilgili DCR üzerinden Log Analytics Workspace’e gönderilebilir. Sentinel tarafında yazılan bir Analytics Rule, belirli bir süre içerisinde aynı kullanıcı için çok sayıda başarısız giriş olup olmadığını KQL ile kontrol eder. Koşul sağlandığında alert oluşur ve ilgili alert’ler bir incident altında birleştirilebilir. Sonrasında Automation Rule ile bir Logic App playbook’u tetiklenerek Teams bildirimi göndermek veya kullanıcı hakkında ek bilgi toplamak gibi aksiyonlar alınabilir.

Data Connector ve DCR Arasındaki Fark

Sentinel öğrenirken Data Connector ile DCR‘ın görevleri ilk başta birbirine karışabiliyor. Aslında ikisi veri toplama sürecinin farklı noktalarında görev yapar.

Data Connector, bir ürün veya servisten Sentinel’e veri alınabilmesi için gerekli bağlantıyı sağlar. Örneğin Microsoft Defender XDR veya Entra ID gibi Microsoft servisleri için hazır connector’lar bulunur. Firewall veya farklı güvenlik ürünlerinde ise ürüne göre farklı entegrasyon yöntemleri kullanılabilir.

DCR (Data Collection Rule) ise özellikle Azure Monitor Agent kullanılan yapılarda hangi verinin toplanacağını ve bu verinin nereye gönderileceğini belirlemek için kullanılır. Örneğin bir Windows sunucudan hangi Windows Event Log’larının alınacağı veya Linux tarafında hangi Syslog facility ve severity değerlerinin toplanacağı DCR üzerinden belirlenebilir.

Bu yüzden ikisini ayırmanın en kolay yolu şöyle düşünmektir:

Data Connector: “Bu veri kaynağını Sentinel’e nasıl bağlarım?”

DCR: “Bu kaynaktan hangi verileri toplayacağım ve nereye göndereceğim?”

Analytics Rule, Alert ve Incident İlişkisi

Sentinel’de Analytics Rule, Alert ve Incident kavramları birbirine bağlı çalışır ancak aynı şeyi ifade etmez. Aralarındaki farkı anlamanın en kolay yolu, bir güvenlik olayının Sentinel içerisinde nasıl ilerlediğine bakmaktır.

Analytics Rule, Sentinel’in hangi davranışı şüpheli olarak değerlendireceğini belirler. Örneğin kısa bir süre içerisinde aynı kullanıcı için çok sayıda başarısız oturum açma işlemi gerçekleşmesi bir Analytics Rule ile takip edilebilir. Kuralın arka tarafında KQL sorgusu çalıştırılarak belirlediğimiz koşulun gerçekleşip gerçekleşmediği kontrol edilir.

Kural eşleştiğinde Alert oluşabilir. Alert’i, Analytics Rule tarafından tespit edilen şüpheli durumun Sentinel üzerindeki karşılığı olarak düşünebiliriz.

Incident ise analistin asıl inceleme yaptığı güvenlik olayıdır. Bir veya birden fazla ilişkili alert aynı incident altında bir araya getirilebilir. SOC tarafında inceleme, analiste atama, durum değiştirme ve müdahale gibi işlemler genellikle incident üzerinden yürütülür.

Örnek Akış

Örneğin Entra ID’den gelen Sign-in Logs içerisinde aynı kullanıcıya ait kısa süre içerisinde çok sayıda başarısız giriş olduğunu düşünelim. Analytics Rule içerisindeki KQL sorgusu bu davranışı tespit ederse bir alert oluşturulabilir. Oluşan alert daha sonra yeni veya mevcut bir incident içerisinde analistin karşısına gelir.

Analytics Rule’lar kullanım senaryosuna göre farklı türlerde oluşturulabilir. Scheduled kurallar belirlenen aralıklarla sorgu çalıştırırken, Near Real-Time (NRT) kurallar daha kısa aralıklarla çalışarak olayların daha hızlı tespit edilmesini sağlar.

KQL Neden Önemli?

Sentinel tarafında çalışırken KQL (Kusto Query Language) sürekli karşımıza çıkar. Toplanan logları incelemek, belirli olayları filtrelemek, farklı veriler arasında ilişki kurmak veya şüpheli bir aktiviteyi araştırmak için KQL kullanılır. Threat hunting ve Analytics Rule oluştururken de sorguların büyük bölümü yine KQL ile yazılır.

Basit bir örnek üzerinden gidelim. Son 24 saat içerisinde gerçekleşen başarısız Entra ID girişlerini görmek istediğimizi düşünelim:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| project TimeGenerated, UserPrincipalName, IPAddress, ResultDescription
| order by TimeGenerated desc

Bu sorguyu çalıştırdığımızda son 24 saatteki başarısız girişleri görebiliriz. Ancak sorgunun kendisi bir alarm değildir. Sorgu belirli koşullar ve çalışma aralıklarıyla bir Analytics Rule içerisinde kullanıldığında detection sürecinin bir parçası haline gelir.

Buradaki ayrım önemli:

KQL veriyi sorgular ve aradığımız olayı bulmamızı sağlar. Analytics Rule ise bu sorgunun hangi koşullarda ve ne zaman çalışacağını belirleyerek tespit sürecini yönetir.

Automation Rule ve Playbook Aynı Şey mi?

Hayır. İkisi Sentinel’in otomasyon tarafında birlikte kullanılabilir ancak farklı görevleri vardır.

Automation Rule, belirli bir olay gerçekleştiğinde Sentinel’in nasıl davranacağını belirler. Örneğin belirli bir Analytics Rule’dan incident oluştuğunda incident’i otomatik olarak bir ekibe atayabilir, tag ekleyebilir, durumunu değiştirebilir veya bir playbook tetikleyebilir.

Playbook ise yapılacak otomasyon adımlarının bulunduğu akıştır ve Azure Logic Apps üzerinde çalışır. Örneğin Teams üzerinden bildirim göndermek, kullanıcı hesabını devre dışı bırakmak, bir IP adresini firewall üzerinde engellemek, ticket oluşturmak veya farklı bir güvenlik ürününün API’sine istek göndermek gibi işlemler playbook içerisinde gerçekleştirilebilir.

Aralarındaki farkı basitçe şöyle düşünebiliriz:

Automation Rule → Ne zaman ve hangi koşulda çalışacak?

Playbook → Tetiklendiğinde hangi işlemleri yapacak?

Örnek Bir Otomasyon Akışı

Bir kullanıcı için şüpheli oturum açma incident’i oluştuğunu düşünelim. Automation Rule, incident’in hangi Analytics Rule’dan geldiğini veya severity değerini kontrol ederek ilgili playbook’u otomatik olarak tetikleyebilir. Playbook çalıştığında kullanıcı bilgilerini Entra ID üzerinden sorgulayabilir ve SOC ekibine Teams üzerinden bildirim gönderebilir.

Incident → Automation Rule → Playbook → Entra ID sorgusu → Teams bildirimi

Threat Hunting ve Workbook

Sentinel yalnızca alarm üretmek ve incident yönetmek için kullanılmaz. SOC ekipleri platformu şüpheli aktiviteleri araştırmak, geçmiş veriler üzerinde inceleme yapmak ve verileri görselleştirmek için de kullanabilir.

Threat Hunting, mevcut detection kurallarının yakalamadığı veya henüz bir alarma dönüşmemiş olabilecek şüpheli aktiviteleri araştırma sürecidir. Analist, KQL sorguları kullanarak loglar üzerinde belirli davranışları arayabilir ve farklı olaylar arasında bağlantı kurmaya çalışabilir. Özellikle olay araştırmalarında veya yeni bir IOC/TTP hakkında geçmişe dönük inceleme yapılırken oldukça kullanışlıdır.

Workbooks ise Sentinel’deki verileri grafik, tablo ve farklı görsel bileşenlerle takip etmek için kullanılır. Örneğin başarısız oturum açma girişlerinin ülkelere göre dağılımı, firewall deny loglarının zaman içerisindeki değişimi, incident sayıları veya belirli bir veri kaynağının ingest durumu bir Workbook üzerinden dashboard haline getirilebilir.

Aralarındaki farkı basitçe şöyle düşünebiliriz:

Threat Hunting → Verinin içinde şüpheli bir davranış arıyorum.

Workbook → Elimdeki veriyi daha anlaşılır şekilde görmek ve takip etmek istiyorum.

Örneğin tehdit istihbaratı kaynağından zararlı olduğu bilinen bir IP adresi geldiğini düşünelim. Analist KQL kullanarak bu IP’nin son 30 gün içerisinde firewall veya sign-in loglarında görülüp görülmediğini araştırabilir. Herhangi bir alert oluşmamış olsa bile geçmiş veriler üzerinde bu şekilde inceleme yapılabilir.

Örnek Bir SOC Senaryosu

Bir kullanıcı hesabına kısa süre içinde farklı IP adreslerinden çok sayıda başarısız oturum açma denemesi yapıldığını düşünelim.

1. Entra ID sign-in logları Sentinel’e aktarılır.
2. Analytics Rule içerisindeki KQL sorgusu belirlenen eşiğin aşıldığını tespit eder.
3. Sentinel bir alert üretir.
4. Alert bir incident altında SOC analistinin karşısına gelir.
5. Automation Rule incident’e otomatik tag ekler ve ilgili playbook’u tetikler.
6. Playbook kullanıcı ve IP bilgilerini zenginleştirir, SOC ekibine Teams/e-posta bildirimi gönderir ve gerekiyorsa ek bir aksiyon başlatır.

Buradaki önemli nokta, otomasyonun analisti tamamen devreden çıkarmak zorunda olmamasıdır. Bildirim gönderme veya bilgi toplama gibi işlemler otomatik yapılabilirken, hesap kapatma veya IP engelleme gibi müdahalelerde analist onayı alınabilir

.

Microsoft Sentinel Kimler İçin Uygun?

Sentinel özellikle Microsoft 365, Entra ID, Defender XDR ve Azure servislerini yoğun kullanan kurumlarda entegrasyon açısından avantajlıdır. Ancak ürün yalnızca Microsoft ekosistemine yönelik değildir; CEF/Syslog ve üçüncü parti connector’lar üzerinden farklı üreticilerden veri toplanabilir.

Hibrit veya multi-cloud altyapıya sahip kurumlar da farklı ortamlardaki güvenlik verilerini merkezi olarak analiz edebilir. MSSP yapılarında ise birden fazla müşterinin güvenlik operasyonlarını workspace ve tenant tasarımına göre yönetmek mümkündür.

Sentinel kullanmak tek başına iyi bir SIEM operasyonu kurulduğu anlamına gelmez. Hangi logların toplanacağı, hangi durumların alarm üreteceği ve oluşan incident’lere nasıl müdahale edileceği de doğru şekilde planlanmalıdır.

Maliyet Tarafında Dikkat Edilmesi Gerekenler

Sentinel tarafında maliyeti etkileyen konuların başında toplanan veri miktarı gelir. Her logun “belki lazım olur” düşüncesiyle Sentinel’e gönderilmesi gereksiz maliyet oluşturabilir.

Bu yüzden bir log kaynağını Sentinel’e eklemeden önce şu sorulara bakmak faydalı olur:

• Hangi log kaynağı gerçekten security use case üretiyor?
• İlgili tablodaki tüm event’lere ihtiyaç var mı?
• DCR veya transformation kullanılarak gereksiz veri filtrelenebilir mi?
• Verinin ne kadar süre analytics katmanında tutulması gerekiyor?
• Daha uzun süre saklanacak veriler için hangi retention/data lake yaklaşımı kullanılmalı?

Microsoft’un fiyatlandırma modeli ve commitment tier seçenekleri zaman içerisinde değişebildiği için burada sabit bir GB fiyatı vermek yerine, güncel Azure fiyatlandırması üzerinden hesaplama yapmak daha doğru olur.

Sentinel Kullanırken Sık Yapılan Hatalar

• Tüm logları ayrım yapmadan Sentinel’e göndermek.
• Hazır analytics rule’ları kurum ortamına uyarlamadan açmak.
• False positive üreten kuralları aylarca tuning yapmadan bırakmak.
• Incident ile alert kavramlarını aynı şey gibi değerlendirmek.
• Hesap kapatma veya IP engelleme gibi kritik aksiyonları analist onayı olmadan doğrudan otomatikleştirmek.
• DCR ve veri toplama mimarisini planlamadan agent dağıtımına başlamak.
• Sadece hazır Content Hub içeriğine güvenip kuruma özel detection geliştirmemek.

Sentinel’de amaç mümkün olduğunca fazla log toplamak değil, gerçekten ihtiyaç duyulan ve güvenlik operasyonunda kullanılacak veriyi toplamaktır.

Microsoft Sentinel’e Nasıl Başlanır?

Sentinel kurulumuna başlamadan önce workspace yapısının ve hangi kaynaklardan veri toplanacağının planlanması gerekir. Ardından ihtiyaç duyulan veri kaynakları connector’lar üzerinden bağlanır ve gerekiyorsa AMA/DCR yapısı oluşturulur.

Sonraki adımda verinin gerçekten geldiği KQL ile doğrulanmalı, ardından analytics rule’lar devreye alınmalıdır. Hazır içerikler için Content Hub kullanılabilir; fakat üretim ortamında kuralların kurum davranışına göre tune edilmesi gerekir.

Detection tarafı stabil hale geldikten sonra Automation Rule ve Playbook’lar ile müdahale süreçleri otomatikleştirilebilir.

Pratik bir sıra şu şekilde olabilir:

Log Source → Data Collection → KQL Validation → Analytics Rule → Incident Tuning → Automation

Böylece veri akışı ve detection tarafı oturmadan otomasyon geliştirmeye başlanmamış olur.

Microsoft Defender Portalına Geçiş

Microsoft Sentinel artık Microsoft Defender portalı üzerinden de kullanılabiliyor. Microsoft, Azure portalındaki Sentinel deneyiminin 31 Mart 2027 sonrasında sona ermesini planlıyor. Bu nedenle yeni kurulumlarda Defender portalı üzerinden ilerlemek daha doğru bir yaklaşım olacaktır.

Defender portalı ile Sentinel ve Defender XDR tarafındaki incident, hunting ve güvenlik operasyonları daha ortak bir yapı üzerinden yönetilebiliyor.

Sonuç

Microsoft Sentinel’i yalnızca “Azure üzerinde çalışan SIEM” şeklinde tanımlamak eksik kalır. Sentinel; veri toplama, KQL ile analiz, detection, incident yönetimi ve Logic Apps ile otomasyon gibi farklı ihtiyaçları tek bir güvenlik operasyonu içerisinde bir araya getirir.

Sentinel’i verimli kullanmak için ise sadece ürünü kurmak yeterli değildir. Hangi verilerin toplanacağı, hangi detection’ların geliştirileceği ve incident’lere nasıl müdahale edileceği en az platformun kendisi kadar önemlidir.