Microsoft Sentinel çalışma alanı mimarinizi tasarlama

Makale
11/18/2021
Okumak için 10 dakika

Not

Azure Sentinel artık Microsoft Sentinel olarak anılmıştır ve önümüzdeki haftalarda bu sayfaları güncelleştiriyor olacağız. En son Microsoft güvenlik geliştirmeleri hakkında daha fazla bilgi.

Bu makalede, Microsoft Sentinel çalışma alanı mimarinizi tasarlama hakkında önemli kararlar atayabilirsiniz. Daha fazla bilgi için bkz. Microsoft Sentinel örnek çalışma alanı tasarımları ve Microsoft Sentinel çalışma alanı mimarisi en iyi yöntemleri.

Önkoşullar

Karar ağacı üzerinde çalışmadan önce aşağıdaki bilgilere sahip olduğundan emin olun:

Önkoşul	Description
Azure veri varlığıyla ilgili mevzuat gereksinimleri	Microsoft Sentinel, Log Analytics için GA'da desteklenen bölgelerin çoğunda çalışma alanlarında çalışmasına izin ve kullanılamaz. Yeni desteklenen Log Analytics bölgelerini Microsoft Sentinel hizmetine ekleme biraz zaman alır. Microsoft Sentinel tarafından oluşturulan olaylar, yer işaretleri ve analiz kuralları gibi veriler, müşterinin Log Analytics çalışma alanlarından alınan bazı müşteri verilerini içerebilir. Daha fazla bilgi için bkz. Coğrafi kullanılabilirlik ve veri konumu.
Veri kaynakları	Hem Microsoft hem de Microsoft dışı çözümlere yönelik yerleşik bağlayıcılar da dahil olmak üzere hangi veri kaynaklarına bağlanmanız gerekir? Veri kaynaklarınızı Microsoft Sentinel'e bağlamak için Common Event Format (CEF), Syslog veya REST-API de kullanabilirsiniz. Günlükleri toplamanız gereken birden çok Azure konumda Azure VM'niz varsa ve veri çıkış maliyetinden tasarruf etmek sizin için önemli ise, her Azure konumu için Bant Genişliği fiyatlandırma hesaplayıcısını kullanarak veri çıkış maliyetini hesaplamanız gerekir.
Kullanıcı rolleri ve veri erişim düzeyleri/izinleri	Microsoft Sentinel, Azure'daki kullanıcılara, gruplara ve hizmetlere atanabilir yerleşik roller sağlamak için Azure rol tabanlı erişim denetimi (Azure RBAC) kullanır. Tüm Microsoft Sentinel yerleşik rolleri, Microsoft Sentinel çalışma alanınız içinde verilere okuma erişimi sağlar. Bu nedenle, çalışma alanı tasarım kararını etkileyene kadar veri kaynağı başına veya satır düzeyine göre veri erişimini denetleme ihtiyacı olup olmadığını bulmanız gerekir. Daha fazla bilgi için bkz. Özel roller ve gelişmiş Azure RBAC.
Günlük alımı oranı	Günlük veri alımı oranı (genellikle GB/gün olarak) Microsoft Sentinel için maliyet yönetimi ve planlamada dikkat edilmesi gereken önemli noktalardan ve çalışma alanı tasarımında önemli faktörlerden birisidir. Çoğu bulut ve hibrit ortamda, güvenlik duvarları veya sunucular gibi ağ cihazları ve Windows ve Linux sunucuları en çok veri alan verileri üretir. En doğru sonuçları elde etmek için Microsoft, veri kaynaklarının kapsamlı bir envanterini tavsiye eder. Alternatif olarak, Microsoft Sentinel maliyet hesaplayıcısı veri kaynaklarının ayak izi tahmininde yararlı tablolar içerir. Önemli: Bu tahminler bir başlangıç noktasıdır ve günlük ayrıntılı ayarları ile iş yükü varyanslar üretir. Değişiklikleri izlemek için sisteminizi düzenli olarak izlemenizi öneririz. Senaryoya göre düzenli izleme önerilir. Daha fazla bilgi için bkz. Azure İzleyici Logs ile kullanımı ve maliyetleri yönetme.

Karar ağacı

Aşağıdaki görüntüde, çalışma alanınızı en iyi şekilde nasıl tasarlay diye anlamanıza yardımcı olacak tam bir karar ağacı akış grafiği yer alır.

Aşağıdaki bölümler, görüntüden başvurulan aşağıdaki notlar da dahil olmak üzere bu karar ağacının tam metin sürümünü sağlar:

Not #1 | Not 2 | Not #3 | Not #4 | Not #5 | Not #6 | Not #7 | Not #8 | Not #9 | Not #10

1. Adım: Yeni veya mevcut çalışma alanı?

Microsoft Sentinel için kullanabileceğiniz bir çalışma alanınız var mı?

Yoksa ve her durumda yeni bir çalışma alanı oluşturuyorsanız doğrudan 2.adımla devam edin.
Kullanabileceğiniz bir çalışma alanınız varsa, ne kadar veri alasınız göz önünde bulundurabilirsiniz.
- 100 GB/gün'den fazla alırsanız, maliyet verimliliği için ayrı bir çalışma alanı kullanılması önerilir.
- 100 GB/gün'den azını alırsanız, daha fazla değerlendirme için 2. adımla devam edin. 5.adımda ortaya çıktığında bu soruyu tekrar düşünün.

2. Adım: Verileri farklı Azure coğrafyalarında mı tutabilirsiniz?

Verileri farklı Azure coğrafyalarında tutmak için mevzuat gereksinimleriniz varsa, uyumluluk gereksinimleri olan her Azure bölgesi için ayrı bir Microsoft Sentinel çalışma alanı kullanın. Daha fazla bilgi için bkz. Bölgeyle ilgili dikkat edilmesi gerekenler.
Verileri farklı Azure coğrafyalarında tutmanız gerek yoksa 3. adımla devam edin.

3. Adım: Birden çok Azure kiracınız var mı?

Yalnızca tek bir kiracınız varsa, 4. adımla doğrudan devam edin.
Birden çok Azure kiracınız varsa, bir kiracı sınırına özgü günlükler (örneğin, kiracı veya kiracı Office 365 Microsoft 365 Defender.
- Kiracıya özgü günlükler yoksa, doğrudan 4. adımla devam edin.
- Kiracıya özgü günlükler topluyorsanız, her Azure AD kiracısı için ayrı bir Microsoft Sentinel çalışma alanı kullanın. Dikkat edilmesi gereken diğer noktalar için 4. adımla devam edin.
  
  Karar ağacı notu #1:Office 365 ve Bulut için Microsoft Defender gibi kiracı sınırlarına özgü günlükler yalnızca aynı kiracı içindeki çalışma alanında depolandırabilir.
  
  Kiracıya özgü günlükleri başka bir kiracıda yer alan bir çalışma alanında toplamak için özel toplayıcılar kullanmak mümkün olsa da, aşağıdaki dezavantajlar nedeniyle bunu önerilmez:
  - Özel bağlayıcılar tarafından toplanan veriler özel tablolara alınacak. Bu nedenle, tüm yerleşik kuralları ve çalışma kitaplarını kullanasınız.
  - Özel tablolar UEBA ve makine öğrenmesi kuralları gibi bazı yerleşik özellikler tarafından dikkate alınmaz.
  - Özel bağlayıcılar için gereken ek maliyet ve çaba, örneğin Azure İşlevleri ve Logic Apps.
  Bu dezavantajlar, kuruluş için sorun oluşturmazsa, ayrı Microsoft Sentinel çalışma alanları kullanmak yerine 4. adımla devam edin.

4. Adım: Faturalamayı bölme/geri ödeme

Faturalamanızı veya ücretinizi bölmeniz gerekirse kullanım raporlama veya el ile çapraz ücret ödemenin sizin için uygun olup olmadığını göz önünde bulundurabilirsiniz.

Faturanızı bölmeniz veya geri ödemeniz gerek yoksa 5. adımla devam edin.
Faturalamanızı bölmeniz veya ücreti geri ödemeniz gerekirse, kullanım raporlama veya el ile çapraz ücret ödemenin size uygun olup olmadığını göz önünde bulundurabilirsiniz.
- Kullanım raporlama veya el ile çapraz ücretlendirme sizin için uygunsa 5. adımla devam edin.
- Kullanım raporlaması veya el ile çapraz ücretlendirme sizin için uygunsa, her maliyet sahibi için ayrı bir Microsoft Sentinel çalışma alanı kullanın.
Karar ağacı notu 2:Daha fazla bilgi için bkz. Microsoft Sentinel maliyetleri ve faturalaması.

5. Adım: SOC dışı veri toplama

İşletimsel veriler gibi SOC dışı veriler top çalışmıyorsanız, doğrudan 6.adıma atlayabilirsiniz.
SOC dışı veriler topluyorsanız, hem SOC hem de SOC olmayan veriler için aynı veri kaynağının gerekli olduğu çakışmalar olup olmadığını göz önünde bulundurabilirsiniz.

SOC ile SOC dışı veriler arasında çakışmalar varsa, çakışan verileri yalnızca SOC verileri olarak kabul edin. Ardından, hem SOC hem de SOC olmayan veriler için veri alımının tek tek 100 GB/gün'den az ama birleştirildikleri zaman günde 100 GB'den fazla olup olmadığını göz önünde bulundurabilirsiniz:
- Evet: Daha fazla değerlendirme için 6. adıma geçin.
- Hayır: Maliyet verimliliği için aynı çalışma alanının kullanılması önerilmez. Daha fazla değerlendirme için 6. adıma geçin.
Her iki durumda da , daha fazla bilgi için bkz. not 10.

Çakışan verileriniz yoksa, hem SOC hem de SOC olmayan veriler için veri alımının tek tek 100 GB/gün'den az ama birleştirilmiş olduğunda günde 100 GB'den fazla olup olmadığını göz önünde bulundurabilirsiniz:
- Evet: Daha fazla değerlendirme için 6. adıma geçin. Daha fazla bilgi için bkz. not 3.
- Hayır: Maliyet verimliliği için aynı çalışma alanının kullanılması önerilmez. Daha fazla değerlendirme için 6. adıma geçin.

SOC ve SOC olmayan verilerinizi birleştirme

Karar ağacı notu #3:SOC olmayan verilerin Microsoft Sentinel maliyetlerine tabi olması için müşterilerin SOC olmayan verileri için ayrı bir çalışma alanı tutmalarını öneririz, ancak SOC ile SOC dışı verileri birleştirmenin bunları ayırmaktan daha ucuz olduğu durumlar olabilir.

Örneğin, günde 50 GB güvenlik günlüğü alan, günde 50 GB'de alan işlem günlükleri ve Doğu ABD bölgesinde bir çalışma alanı olan bir kuruluşu düşünün.

Aşağıdaki tabloda, çalışma alanı seçenekleri ayrı çalışma alanlarıyla ve ayrı çalışma alanları olmadan karşılaştırıldı.

Not

Aşağıdaki tabloda listelenen maliyetler ve terimler sahtedir ve yalnızca açıklayıcı amaçlarla kullanılır. Güncel maliyet bilgileri için bkz. Microsoft Sentinel fiyatlandırma hesaplayıcısı.

Çalışma alanı mimarisi	Description
SOC ekibinin kendi çalışma alanı vardır ve Microsoft Sentinel etkindir. Operasyon ekibinin Microsoft Sentinel etkinleştirilmemiş kendi çalışma alanı vardır.	SOC ekibi: 50 GB/gün için Microsoft Sentinel maliyeti aylık 6.500 ABD dolarıdır. İlk üç aylık saklama ücretsizdir. Operasyon ekibi: - Günlük 50 GB olan Log Analytics maliyeti aylık yaklaşık 3.500 ABD dolarıdır. - İlk 31 günlük saklama ücretsizdir. Her iki için de toplam maliyet aylık 10.000 ABD dolarıdır.
Hem SOC hem de Operasyon ekipleri aynı çalışma alanını Microsoft Sentinel'in etkin olduğu şekilde paylaşır.	Her iki günlüğü de birleştirerek, giriş için 100 GB/gün, taahhüt katmanı için uygunluk (Sentinel için %50 ve LA için %15%) uygun olacaktır. 100 GB/gün için Microsoft Sentinel 'in maliyeti aylık $9.000 ' e eşittir.

Bu örnekte, her iki çalışma alanını birleştirerek ayda $1.000 maliyet tasarrufu elde edersiniz ve Ops ekibi de yalnızca 31 gün değil 3 aydan ücretsiz bekletme elde eder.

Bu örnek yalnızca hem SOC hem de SOC olmayan veriler >= 50/gün ve 100 GB/gün <bir alım boyutuna sahip olduğunda geçerlidir.

Karar ağacı note #10: SOC olmayan veriler için ayrı bir çalışma alanı kullanmanızı öneririz, bu sayede SOC olmayan veriler Microsoft Sentinel maliyetlerine tabi.

Ancak, SOC olmayan veriler için ayrı çalışma alanlarına yönelik bu öneri yalnızca maliyet tabanlı bir perspektiften gelir ve tek veya birden çok çalışma alanı kullanılıp kullanılmayacağını belirlerken inceleyecek başka temel tasarım faktörleri de vardır. İki giriş maliyetine engel olmak için, çakışan verileri tek bir çalışma alanında yalnızca tablo düzeyinde Azure RBAC ile toplamayı göz önünde bulundurun.

6. Adım: birden çok bölge?

Yalnızca tek bir bölgedeki Azure VM 'lerinden Günlükler topluyorsanız, doğrudan 7. adımladevam edin.
Birden çok bölgedeki Azure VM 'lerinden Günlükler topluyorsanız, veri çıkış maliyeti hakkında ne kadar endişelenirsiniz?

Karar ağacı note #4: veri çıkışı, verileri Azure veri merkezlerinden dışarı taşımaya yönelik bant genişliği maliyetini ifade eder. Daha fazla bilgi için bkz. bölge konuları.
- Ayrı çalışma alanlarını sürdürmek için gereken çaba miktarını azaltmak bir önceliktir, 7. adımladevam edin.
- Veri çıkış maliyeti, ayrı çalışma alanlarının korunmasıyla ilgili bir kaygıdan yeterince fazla olursa, veri çıkış maliyetini azaltmanız gereken her bölge için ayrı bir Microsoft Sentinel çalışma alanı kullanın.
  
  Karar ağacı notunun #5: mümkün olduğunca az sayıda çalışma alanınız olması önerilir. Maliyeti hesaplamak ve gerçekten ihtiyacınız olan bölgeleri öğrenmek için Azure Fiyatlandırma hesaplayıcısı ' nı kullanın ve düşük çıkış maliyetlerine sahip bölgeler için çalışma alanlarını birleştirin. Bant genişliği maliyetleri, ayrı Microsoft Sentinel ve Log Analytics alma maliyetleriyle karşılaştırıldığında Azure faturanızda yalnızca küçük bir bölüm olabilir.
  
  Örneğin, maliyetiniz şu şekilde tahmin edilebilir:
  - 1.000 VM, her biri 1 GB/gün oluşturuluyor;
  - ABD bölgesinden bir AB bölgesine veri gönderme;
  - Aracıda 2:1 sıkıştırma oranı kullanma
  Bu tahmini maliyetin hesaplaması şöyle olacaktır: 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost
  
  Bu örnek maliyet, ayrı bir Microsoft Sentinel ve Log Analytics çalışma alanının aylık maliyetleriyle karşılaştırıldığında çok daha ucuz olacaktır.
  
  Not
  
  Listelenen maliyetler sahte ve yalnızca tanım amacıyla kullanılır. Güncel maliyet bilgileri için bkz. Microsoft Sentinel Fiyatlandırma Hesaplayıcı.

7. Adım: verileri ayırma veya sınırları sahipliğe göre tanımlama?

Verileri ayırt etmeniz veya herhangi bir sahiplik sınırı tanımlamanız gerekmiyorsa doğrudan 8. adımladevam edin.
Verileri ayırt etmeniz veya sahipliği temel alarak sınırları tanımlamanız gerekiyorsa, her veri sahibinin Microsoft Sentinel portalını kullanması gerekir mi?
- Her bir veri sahibinin Microsoft Sentinel portalına erişimi olması gerekiyorsa, her bir sahip için ayrı bir Microsoft Sentinel çalışma alanı kullanın.
  
  Karar ağacı note #6: Microsoft Sentinel portalına erişim, her kullanıcının çalışma alanındaki tüm tablolarda okuyucu izinleri olan en az bir Microsoft Sentinel okuyucusurolüne sahip olmasını gerektirir. Bir kullanıcının çalışma alanındaki tüm tablolara erişimi yoksa, arama sorgularındaki günlüklere erişmek için Log Analytics kullanmaları gerekir.
- Log Analytics aracılığıyla günlüklere erişim, Microsoft Sentinel portalına erişimi olmayan tüm sahipler için yeterliyse, 8. adımladevam edin.
Daha fazla bilgi için bkz. Microsoft Sentinel 'Teki izinler.

8. Adım: veri kaynağına/tabloya göre veri erişimini denetleme

Kaynak veya tabloya göre veri erişimini denetlemenize gerek yoksa, tek bir Microsoft Sentinel çalışma alanı kullanın.
Kaynak veya tabloya göre veri erişimini kontrol etmeniz gerekirse, aşağıdaki durumlarda kaynak bağlamı RBAC kullanmayı göz önünde bulundurun:
- Her veri kaynağı veya tablo üzerinde birden fazla sahip sağlamak gibi, satır düzeyinde erişimi kontrol etmeniz gerekiyorsa
- Birden çok, özel veri kaynağınız/tablonuz varsa her birinin ayrı izinleri olması gerekir
Diğer durumlarda, satır düzeyinde erişimi denetlemenize gerek olmadığında , farklı izinlere sahip birden fazla, özel veri kaynağı/tablo sağlamanız, veri erişim denetimi için tablo düzeyi RBAC ile tek bir Microsoft Sentinel çalışma alanı kullanın.

Kaynak bağlamı veya tablo düzeyi RBAC ile ilgili konular

Kaynak bağlamı veya tablo düzeyi RBAC kullanmayı planlarken, aşağıdakileri göz önünde bulundurun:

Karar ağacı note #7: Azure dışı kaynaklar için kaynak bağlamı RBAC 'yi yapılandırmak Için, Microsoft Sentinel 'e GÖNDERILIRKEN kaynak kimliğini ilişkilendirmek isteyebilirsiniz, böylece izin Resource-Context RBAC kullanılarak kapsamlandırılır. Daha fazla bilgi için bkz. kaynak BAĞLAMı RBAC ve erişim modlarını dağıtıma göreaçıkça yapılandırma.
Karar ağacı note #8: kaynak izinleri veya kaynak bağlamı , kullanıcıların yalnızca erişimleri olan kaynaklar için günlükleri görüntülemesine olanak tanır. Çalışma alanı erişim modunun Kullanıcı kaynağı veya çalışma alanı izinleri olarak ayarlanması gerekir. Yalnızca kullanıcının izinleri olan kaynaklarla ilgili tablolar, Microsoft Sentinel 'deki Günlükler sayfasından arama sonuçlarına dahil edilir.
Karar ağacı note #9: tablo düzeyi RBAC , diğer izinlerin yanı sıra bir Log Analytics çalışma alanındaki verilere daha ayrıntılı denetim tanımlamanızı sağlar. Bu denetim, yalnızca belirli bir kullanıcı kümesi için erişilebilen belirli veri türlerini tanımlamanızı sağlar. Daha fazla bilgi için bkz. Microsoft Sentinel 'de tablo DÜZEYI RBAC.

Sonraki adımlar

Pratikte bu karar ağacının örnekleri için bkz. Microsoft Sentinel örnek çalışma alanı tasarımları.

Daha fazla bilgi için bkz.