Microsoft Sentinel çalışma alanı mimarinizi tasarlama

Not

Azure Sentinel artık Microsoft Sentinel olarak adlandırılıyor ve önümüzdeki haftalarda bu sayfaları güncelleştireceğiz. En son Microsoft güvenlik geliştirmeleri hakkında daha fazla bilgi edinin.

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.

Ö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ölgelerde ç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 yerleşik bağlayıcılar 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 denetleme gereksinimi 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 konuları ve çalışma alanı tasarımındaki önemli faktörlerden biridir.

Çoğu bulut ve karma ortamda, güvenlik duvarları veya ara sunucular gibi ağ cihazları ve Windows ve Linux sunucuları en çok alınan verileri üretir. En doğru sonuçları elde etmek için Microsoft, veri kaynaklarının kapsamlı bir envanterini önerir.

Alternatif olarak, Microsoft Sentinel maliyet hesaplayıcısı veri kaynaklarının ayak izlerini tahmin etmek için kullanışlı 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ış çizelgesi gösterilmektedir.

Microsoft Sentinel workspace design decision tree.

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 , doğrudan 2. adımla 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 veri alımı yapacaksanı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 tutma

  • Verileri farklı Azure coğrafyalarında tutmak için yasal 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 gerekmiyorsa3. adımla devam edin.

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

  • Yalnızca tek bir kiracınız varsa doğrudan 4. adımla devam edin.

  • Birden çok Azure kiracınız varsa, Office 365 veya Microsoft 365 Defender 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 doğrudan 4. adımla devam edin.

    • Kiracıya özgü günlükleri topluyorsanız, her Azure AD kiracı 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ı not 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 ç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ınacaktı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.
      • Azure İşlevleri ve Logic Apps kullanma gibi özel bağlayıcılar için gereken ek maliyet ve çaba.

      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ünüyor mu?

Faturanızı veya geri ödemenizi bölmeniz gerekiyorsa, kullanım bildiriminin veya el ile çapraz ücretin sizin için çalışıp çalışmadığını göz önünde bulundurun.

5. Adım: SOC olmayan herhangi bir veri mi topluyorsunuz?

  • İşletimsel veriler gibi SOC olmayan 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ı veri alımının 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ıma geçin.
    • Hayır: Maliyet verimliliği açısından aynı çalışma alanının kullanılmasını ö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 verileriniz yoksa hem SOC hem de SOC olmayan veriler için ayrı ayrı veri alımının 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ıma geçin. Daha fazla bilgi için bkz. not 3.
    • Hayır: Maliyet verimliliği açısından aynı çalışma alanının kullanılmasını önermiyoruz. Daha fazla değerlendirme için 6. adımla devam edin.

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, günlük 50 GB'lık işlem günlükleri ve Doğu ABD bölgesinde bir çalışma alanı alan bir kuruluş 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ılır.

Not

Aşağıdaki tabloda listelenen maliyetler ve terimler sahtedir ve yalnızca açıklama amacıyla 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.

Operasyon ekibinin, Microsoft Sentinel etkinleştirilmeden 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'lık Log Analytics maliyeti ayda yaklaşık 3.500 ABD dolarıdır.
- İlk 31 günlük saklama ücretsizdir.

Her ikisinin de toplam maliyeti aylık 10.000 TL'ye eşittir.
Hem SOC hem de Ops ekipleri, Microsoft Sentinel etkinken aynı çalışma alanını paylaşır. Her iki günlük de birleştirilerek alım 100 GB /gün olur ve Taahhüt Katmanı için uygun olmaya hak kazanır (%50 Sentinel için ve %15 LA için).

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 birinin alma boyutu >=50 GB/gün ve <100 GB/gün olduğunda geçerlidir.

Karar ağacı not 10: SOC olmayan verilerin Microsoft Sentinel maliyetlerine tabi olmaması 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?

  • Azure VM'lerinden günlükleri yalnızca tek bir bölgede topluyorsanız, 7. adımla doğrudan devam edin.

  • Birden çok bölgedeki Azure VM'lerinden günlük topluyorsanız veri çıkış maliyeti konusunda ne kadar endişelisiniz?

    Karar ağacı not 4: Veri çıkışı, verileri Azure veri merkezlerinden taşımak için 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 yetecek kadar önemliyse, veri çıkış maliyetini azaltmanız gereken her bölge için ayrı bir Microsoft Sentinel çalışma alanı kullanın.

      Karar ağacı not 5: Mümkün olduğunca az çalışma alanınız olmasını öneririz. 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 parçası olabilir.

      Örneğin, maliyetiniz aşağıdaki gibi tahmin edilebilir:

      • 1.000 VM, her birinin günde 1 GB'ı oluşturması;
      • 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 cost

      Bu örnek maliyeti, 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.

      Not

      Listelenen maliyetler sahtedir ve yalnızca açıklayıcı amaçlar için kullanılır. Güncel maliyet bilgileri için bkz. Microsoft Sentinel fiyatlandırma hesaplayıcısı.

7. Adım: Verileri ayırma veya sahipliğine göre sınırları tanımlama

  • Verileri ayırmanız veya sahiplik sınırları tanımlamanız gerekmiyorsa, 8. adımla doğrudan devam edin.

  • Verileri ayırmanız veya sahipliği temel alan 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 izinlerine sahip en az bir Microsoft Sentinel Okuyucusu rolüne sahip olmasını gerektirir. Bir kullanıcının çalışma alanı içindeki 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 İzinler.

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.

  • Veri erişimini kaynağa veya tabloya göre 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, satır düzeyinde erişimi denetlemeniz, ayrı izinlere sahip birden çok özel veri kaynağı/tablo sağlamanız gerekmediğinde , veri erişim denetimi için tablo düzeyinde RBAC içeren 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ı not 7: Azure dışı kaynaklar için kaynak bağlamı RBAC'sini yapılandırmak için Microsoft Sentinel'e gönderirken verilerde kaynak kimliğini 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ı not 8: Kaynak izinleri veya kaynak bağlamı , kullanıcıların yalnızca erişimi olan kaynaklar için günlükleri 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 verilere daha ayrıntılı denetim tanımlamanızı sağlar. Bu denetim, yalnızca belirli bir kullanıcı kümesi için erişilebilir olan 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 karar ağacının uygulama örnekleri için bkz. Microsoft Sentinel örnek çalışma alanı tasarımları.

Daha fazla bilgi için bkz.