Microsoft Sentinel çalışma alanı mimarinizi tasarlama
Bu makalede, Microsoft Sentinel çalışma alanı mimarinizi tasarlama hakkında önemli kararlar vermenize yardımcı olacak bir karar ağacı sağlanmaktadır. 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. Bu makale, Microsoft Sentinel dağıtım kılavuzunun bir parçasıdır.
Önkoşullar
Karar ağacı üzerinde çalışmadan önce aşağıdaki bilgilere sahip olduğunuzdan emin olun:
| Önkoşul | Açıklama |
|---|---|
| Azure veri yerleşimi ile ilgili mevzuat gereksinimleri | Microsoft Sentinel çoğu çalışma alanında çalışabilir, ancak Log Analytics için GA'da desteklenen tüm bölgeler çalışmaz. Yeni desteklenen Log Analytics bölgelerinin Microsoft Sentinel hizmetini eklemesi biraz zaman alabilir. 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 yerleşimi. |
| 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ını bağlamanız gerektiğini öğrenin. Veri kaynaklarınızı Microsoft Sentinel'e bağlamak için Ortak Olay Biçimi (CEF), Syslog veya REST-API de kullanabilirsiniz. Günlükleri toplamanız gereken birden çok Azure konumunda Azure VM'leriniz varsa ve veri çıkış maliyetinden tasarruf etmek sizin için önemliyse, 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 atanabilecek yerleşik roller sağlamak için Azure rol tabanlı erişim denetimini (Azure RBAC) kullanır. Tüm Microsoft Sentinel yerleşik rolleri, Microsoft Sentinel çalışma alanınızdaki verilere okuma erişimi verir. Bu nedenle, çalışma alanı tasarım kararını etkileyecek şekilde veri kaynağı veya satır düzeyi başına veri erişimini denetlemeye gerek olup olmadığını öğrenmeniz gerekir. Daha fazla bilgi için bkz . Özel roller ve gelişmiş Azure RBAC. |
| Günlük alım oranı | Genellikle GB/gün olarak günlük alım oranı, Microsoft Sentinel için maliyet yönetimi ve planlama konusunda dikkat edilmesi gereken önemli noktalardan ve çalışma alanı tasarımında önemli faktörlerden biridir. Çoğu bulut ve karma ortamda, güvenlik duvarları veya proxy'ler gibi ağ cihazları ve Windows ve Linux sunucuları en çok alınan verileri üretir. Microsoft, en doğru sonuçları elde etmek için veri kaynaklarının kapsamlı bir envanterini önerir. Alternatif olarak, Microsoft Sentinel maliyet hesaplayıcısı veri kaynaklarının ayak izlerini tahmin etmede yararlı olan tablolar içerir. Önemli: Bu tahminler bir başlangıç noktasıdır ve günlük ayrıntı ayarları ve iş yükü varyanslar oluşturur. Değişiklikleri izlemek için sisteminizi düzenli olarak izlemenizi öneririz. Senaryonuza göre düzenli izleme önerilir. Daha fazla bilgi için bkz. Azure İzleyici Günlükleri fiyatlandırma ayrıntıları. |
Karar ağacı
Aşağıdaki görüntüde, çalışma alanınızı en iyi şekilde tasarlamayı anlamanıza yardımcı olacak tam bir karar ağacı akış grafiği gösterilmektedir.
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 çalışma alanı mı yoksa var olan çalışma alanı mı?
Microsoft Sentinel için kullanabileceğiniz bir çalışma alanınız var mı?
Aksi takdirde ve her durumda yeni bir çalışma alanı oluşturacaksanız, 2. adımla doğrudan devam edin.
Kullanabileceğiniz bir çalışma alanınız varsa ne kadar veri alabileceğinizi göz önünde bulundurun.
Günde 100 GB'tan fazla verim alırsanız maliyet verimliliği için ayrı bir çalışma alanı kullanmanızı öneririz.
Günde 100 GB'tan az veri alımı yapacaksanız, daha fazla değerlendirme için 2. adımla devam edin. 5. adımda ortaya çıktığında bu soruyu yeniden düşünün.
2. Adım: Verileri farklı Azure coğrafyalarında mı tutuyorsunuz?
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 gerekmiyorsa 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, Office 365 veya Microsoft Defender XDR gibi bir kiracı sınırına özgü günlükleri toplayıp toplamadığınızı göz önünde bulundurun.
Kiracıya özgü günlükleriniz yoksa 4. adımla doğrudan devam edin.
Kiracıya özgü günlükleri topluyorsanız, her Microsoft Entra kiracısı için ayrı bir Microsoft Sentinel çalışma alanı kullanın. Diğer önemli 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 depolanabilir.
Başka bir kiracıdaki bir çalışma alanından kiracıya özgü günlükleri toplamak için özel toplayıcılar kullanmak mümkün olsa da, aşağıdaki dezavantajlardan dolayı bunu önermeyiz:
- Özel bağlayıcılar tarafından toplanan veriler özel tablolara alınır. Bu nedenle, tüm yerleşik kuralları ve çalışma kitaplarını kullanamazsı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 Azure İşlevleri ve Logic Apps kullanma gibi ek maliyet ve çaba gerekir.
Bu dezavantajlar kuruluşunuz için önemli değilse, ayrı Microsoft Sentinel çalışma alanları kullanmak yerine 4. adımla devam edin.
4. Adım: Faturalama / geri ödeme bölündü mü?
Faturanızı veya geri ödemenizi bölmeniz gerekiyorsa, kullanım bildiriminin veya el ile çapraz ücretlendirmenin sizin için uygun olup olmadığını göz önünde bulundurun.
Faturanızı veya geri ödemenizi bölmeniz gerekmiyorsa 5. adımla devam edin.
Faturanızı veya geri ödemenizi bölmeniz gerekiyorsa el ile çapraz ücretlendirmeyi kullanmayı göz önünde bulundurun. Varlık başına doğru maliyetleri elde etmek için Microsoft Sentinel Maliyet çalışma kitabının maliyeti varlığa göre parçalayan değiştirilmiş bir sürümünü kullanabilirsiniz.
Kullanım raporlama veya el ile çapraz ücretlendirme size uygunsa 5. adımla devam edin.
Kullanım raporlama veya el ile çapraz ücretlendirme işinize yaramazsa, 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 olmayan herhangi bir veri mi topluyorsunuz?
İşletimsel veriler gibi SOC dışı veriler toplamazsanız, doğrudan 6. adıma atlayabilirsiniz.
SOC olmayan 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 bulundurun.
SOC ile SOC olmayan veriler arasında çakışmalar varsa, çakışan verileri yalnızca SOC verileri olarak değerlendirin. Ardından, hem SOC hem de SOC olmayan veriler için ayrı ayrı alım işleminin 100 GB/günden az, birleştirildiğinde ise 100 GB/günden fazla olup olmadığını göz önünde bulundurun:
- Evet: Daha fazla değerlendirme için 6. adımla devam edin.
- Hayır: Maliyet verimliliği açısından aynı çalışma alanını kullanmanızı önermiyoruz. Daha fazla değerlendirme için 6. adımla devam edin.
Her iki durumda da daha fazla bilgi için bkz . not 10.
Çakışan veriniz yoksa, hem SOC hem de SOC olmayan veriler için ayrı ayrı alımın 100 GB/günden az, birleştirildiğinde ise 100 GB/günden fazla olup olmadığını göz önünde bulundurun:
SOC ve SOC olmayan verilerinizi birleştirme
Karar ağacı notu 3: SoC olmayan verilerin Microsoft Sentinel maliyetlerine tabi olmaması için müşterilerin SOC olmayan verileri için ayrı bir çalışma alanı tutmalarını öneririz ancak SOC ve SOC olmayan verileri birleştirmenin bunları ayırmaktan daha ucuz olduğu durumlar olabilir.
Örneğin, günlük 50 GB'lık güvenlik günlükleri, 50 GB/gün alan işlem günlükleri ve Doğu ABD bölgesindeki bir çalışma alanı olan bir kuruluş düşünün.
Aşağıdaki tabloda çalışma alanı seçenekleri ayrı çalışma alanlarıyla ve çalışma alanları olmadan karşılaştırılır.
Dekont
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 | Açıklama |
|---|---|
| SOC ekibinin, Microsoft Sentinel'in etkinleştirildiği kendi çalışma alanı vardır. Microsoft Sentinel etkinleştirilmeden Operasyon ekibinin 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 üç ay bekletme ücretsizdir. Operasyon ekibi: - Günlük 50 GB olan Log Analytics maliyeti ayda yaklaşık 3.500 ABD dolarıdır. - İlk 31 gün bekletme ücretsizdir. Her ikisinin de toplam maliyeti aylık 10.000 ABD dolarıdır. |
| Hem SOC hem de Ops ekipleri, Microsoft Sentinel etkinken aynı çalışma alanını paylaşır. | Her iki günlük birleştirilerek alım 100 GB /gün olur ve Taahhüt Katmanı için uygunluk için uygun olur (%Sentinel için %50 ve LA için %15). Microsoft Sentinel'in 100 GB/gün maliyeti aylık 9.000 ABD dolarına eşittir. |
Bu örnekte her iki çalışma alanını da birleştirerek aylık 1.000 ABD doları maliyet tasarrufu elde etmiş olursunuz ve Operasyon ekibi de yalnızca 31 gün yerine 3 ay ücretsiz saklama süresinden yararlanabilir.
Bu örnek yalnızca hem SOC hem de SOC olmayan verilerin her biri =50 GB/gün ve <100 GB/gün alım boyutuna >sahip olduğunda geçerlidir.
Karar ağacı notu #10: SOC olmayan verilerin Microsoft Sentinel maliyetlerine maruz kalabilmesi için SOC olmayan veriler için ayrı bir çalışma alanı kullanmanızı öneririz.
Ancak, SOC olmayan veriler için ayrı çalışma alanları için bu öneri tamamen maliyet tabanlı bir perspektiften gelir ve tek veya birden çok çalışma alanı kullanılıp kullanılmayacağını belirlerken incelenmesi gereken başka önemli tasarım faktörleri vardır. Çift alım maliyetlerini önlemek için, yalnızca tablo düzeyinde Azure RBAC ile tek bir çalışma alanında çakışan verileri toplamayı göz önünde bulundurun.
6. Adım: Birden çok bölge mi?
Yalnızca tek bir bölgedeki Azure VM'lerinden günlük topluyorsanız, 7. adımla doğrudan devam edin.
Birden çok bölgede yer alan Azure VM'lerinden günlük topluyorsanız veri çıkış maliyeti konusunda ne kadar endişe duyuyorsunuz?
Karar ağacı notu #4: Veri çıkışı, verileri Azure veri merkezlerinden taşımaya yönelik bant genişliği maliyetini ifade eder. Daha fazla bilgi için bkz . Bölgeyle ilgili dikkat edilmesi gerekenler.
Ayrı çalışma alanlarını korumak için gereken çaba miktarını azaltmak öncelikliyse, 7. adımla devam edin.
Veri çıkış maliyeti, ayrı çalışma alanlarının bakımını yapmaya değer hale getirmek için yeterliyse, veri çıkış maliyetini azaltmanız gereken her bölge için ayrı bir Microsoft Sentinel çalışma alanı kullanın.
Karar ağacı notu #5: Mümkün olduğunca az çalışma alanınız olması önerilir. Azure fiyatlandırma hesaplayıcısını kullanarak maliyeti tahmin edin ve gerçekten hangi bölgelere ihtiyacınız olduğunu belirleyin 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 alım maliyetleriyle karşılaştırıldığında Azure faturanızın yalnızca küçük bir kısmı olabilir.
Örneğin, maliyetiniz aşağıdaki gibi tahmin edilebilir:
- Her birinde 1 GB/ gün oluşturan 1.000 VM;
- BIR ABD bölgesinden AB bölgesine veri gönderme;
- Aracıda 2:1 sıkıştırma hızı kullanma
Bu tahmini maliyet için hesaplama şu şekilde olacaktır:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costBu ö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 düşük maliyetli olacaktır.
Dekont
Listelenen maliyetler 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ı.
7. Adım: Verileri ayrıştırma veya sahiplik sınırları tanımlama
Verileri ayırmanız veya sahiplik sınırları tanımlamanız gerekmiyorsa, doğrudan 8. adımla devam edin.
Verileri ayırmanız veya sahipliğe göre sınırlar tanımlamanız gerekiyorsa, her veri sahibinin Microsoft Sentinel portalını kullanması gerekir mi?
Her veri sahibinin Microsoft Sentinel portalına erişimi olması gerekiyorsa, her sahip için ayrı bir Microsoft Sentinel çalışma alanı kullanın.
Karar ağacı notu #6: Microsoft Sentinel portalına erişim, her kullanıcının çalışma alanı içindeki tüm tablolarda Okuyucu izinleri olan en az bir Microsoft Sentinel Okuyucusu rolüne sahip olmasını gerektirir. Bir kullanıcının çalışma alanında tüm tablolara erişimi yoksa, arama sorgularındaki günlüklere erişmek için Log Analytics'i kullanması gerekir.
Log Analytics aracılığıyla günlüklere erişim, Microsoft Sentinel portalına erişimi olmayan sahipler için yeterliyse 8. adımla devam edin.
Daha fazla bilgi için bkz . Microsoft Sentinel'de izinler.
8. Adım: Veri kaynağına/tablosuna göre veri erişimini denetleme
Kaynak veya tabloya göre veri erişimini denetlemeniz gerekmiyorsa, tek bir Microsoft Sentinel çalışma alanı kullanın.
Kaynak veya tabloya göre veri erişimini denetlemeniz gerekiyorsa, aşağıdaki durumlarda kaynak bağlamı RBAC kullanmayı göz önünde bulundurun:
Her veri kaynağında veya tabloda birden çok sahip sağlama gibi satır düzeyinde erişimi denetlemeniz gerekiyorsa
Her birinin ayrı izinlere ihtiyaç duyduğu birden çok özel veri kaynağınız/tablonuz varsa
Diğer durumlarda, erişimi satır düzeyinde denetlemeniz gerekmediğinde , ayrı izinlere sahip birden çok özel veri kaynağı/tablo sağlayın, veri erişim denetimi için tablo düzeyinde RBAC ile tek bir Microsoft Sentinel çalışma alanı kullanın.
Kaynak bağlamı veya tablo düzeyinde RBAC ile ilgili dikkat edilmesi gerekenler
Kaynak bağlamı veya tablo düzeyi RBAC kullanmayı planlarken aşağıdaki bilgileri göz önünde bulundurun:
Karar ağacı notu #7: Azure dışı kaynaklar için kaynak bağlamı RBAC'sini yapılandırmak için Microsoft Sentinel'e gönderirken kaynak kimliğini veriyle ilişkilendirmek isteyebilirsiniz; böylece izinlerin kapsamı kaynak bağlamı RBAC kullanılarak tamamlanabilir. Daha fazla bilgi için bkz . Dağıtıma göre kaynak bağlamı RBAC ve Erişim modlarını açıkça yapılandırma.
Karar ağacı notu #8: Kaynak izinleri veya kaynak bağlamı , kullanıcıların yalnızca erişim sahibi oldukları kaynakların günlüklerini görüntülemesine olanak tanır. Çalışma alanı erişim modu Kullanıcı kaynağı veya çalışma alanı izinleri olarak ayarlanmalıdır. Yalnızca kullanıcının izinlere sahip olduğu kaynaklarla ilgili tablolar, Microsoft Sentinel'deki Günlükler sayfasından arama sonuçlarına eklenir.
Karar ağacı notu #9: Tablo düzeyinde RBAC , Log Analytics çalışma alanında diğer izinlere ek olarak veriler için daha ayrıntılı denetim tanımlamanızı sağlar. Bu denetim, yalnızca belirli bir kullanıcı kümesi tarafından erişilebilen belirli veri türlerini tanımlamanızı sağlar. Daha fazla bilgi için bkz . Microsoft Sentinel'de tablo düzeyinde RBAC.
Sonraki adımlar
Bu makalede, Microsoft Sentinel çalışma alanı mimarinizi tasarlama konusunda önemli kararlar almak için bir karar ağacını gözden geçirdiniz.