Aracılığıyla paylaş


Microsoft Sentinel verilerine erişimi kaynağa göre yönetme

Genellikle, Microsoft Sentinel için etkinleştirilmiş bir Log Analytics çalışma alanına erişimi olan kullanıcılar da güvenlik içeriği dahil olmak üzere tüm çalışma alanı verilerine erişebilir. Yöneticiler, ekiplerindeki erişim gereksinimlerine bağlı olarak Microsoft Sentinel'deki belirli özelliklere erişimi yapılandırmak için Azure rollerini kullanabilir.

Ancak, çalışma alanınızda yalnızca belirli verilere erişmesi gereken ancak Microsoft Sentinel ortamının tamamına erişimi olmaması gereken bazı kullanıcılarınız olabilir. Örneğin, sahip oldukları sunucular için Windows olay verilerine erişimi olan güvenlikle ilgili olmayan işlemler (SOC olmayan) bir ekip sağlamak isteyebilirsiniz.

Bu gibi durumlarda, rol tabanlı erişim denetiminizi (RBAC) çalışma alanına veya belirli Microsoft Sentinel özelliklerine erişim sağlamak yerine kullanıcılarınıza izin verilen kaynaklara göre yapılandırmanızı öneririz. Bu yöntem, kaynak bağlamı RBAC'sini ayarlama olarak da bilinir.

Kullanıcılar çalışma alanı yerine erişebilecekleri kaynaklar aracılığıyla Microsoft Sentinel verilerine eriştiklerinde, aşağıdaki yöntemleri kullanarak günlükleri ve çalışma kitaplarını görüntüleyebilir:

  • Azure Sanal Makinesi gibi kaynağın kendisi aracılığıyla. Yalnızca belirli bir kaynağın günlüklerini ve çalışma kitaplarını görüntülemek için bu yöntemi kullanın.

  • Azure İzleyici aracılığıyla. Birden çok kaynağa ve/veya kaynak grubuna yayılan sorgular oluşturmak istediğinizde bu yöntemi kullanın. Azure İzleyici'de günlüklere ve çalışma kitaplarına gezinirken kapsamınızı belirli bir veya daha fazla kaynak grubu veya kaynak olarak tanımlayın.

Azure İzleyici'de kaynak bağlamı RBAC'sini etkinleştirin. Daha fazla bilgi için bkz . Azure İzleyici'de günlük verilerine ve çalışma alanlarına erişimi yönetme.

Not

Verileriniz Syslog, CEF veya Microsoft Entra ID verileri gibi bir Azure kaynağı veya özel toplayıcı tarafından toplanan veriler değilse, verileri tanımlamak ve erişimi etkinleştirmek için kullanılan kaynak kimliğini el ile yapılandırmanız gerekir. Daha fazla bilgi için bkz . Azure dışı kaynaklar için kaynak bağlamı RBAC'sini açıkça yapılandırma.

Ayrıca, işlevler ve kaydedilen aramalar kaynak odaklı bağlamlarda desteklenmez. Bu nedenle, ayrıştırma ve normalleştirme gibi Microsoft Sentinel özellikleri Microsoft Sentinel'de kaynak bağlamı RBAC için desteklenmez.

Kaynak bağlamı RBAC senaryoları

Aşağıdaki tabloda, kaynak bağlamı RBAC'nin en yararlı olduğu senaryolar vurgulanır. SOC ekipleri ile SOC olmayan ekipler arasındaki erişim gereksinimleri arasındaki farkları not edin.

Gereksinim türü SOC ekibi SOC olmayan ekip
İzinler Çalışma alanının tamamı Yalnızca belirli kaynaklar
Veri erişimi Çalışma alanı içindeki tüm veriler Yalnızca ekibin erişim yetkisine sahip olduğu kaynaklara ilişkin veriler
Deneyim Büyük olasılıkla kullanıcıya atanan işlevsel izinlerle sınırlı olan tam Microsoft Sentinel deneyimi Yalnızca günlük sorguları ve Çalışma Kitapları

Ekibinizin yukarıdaki tabloda açıklanan SOC olmayan ekiple benzer erişim gereksinimleri varsa, kaynak bağlamı RBAC kuruluşunuz için iyi bir çözüm olabilir.

Örneğin, aşağıdaki görüntüde, güvenlik ve operasyon ekiplerinin farklı veri kümelerine erişmesi gereken ve gerekli izinleri sağlamak için kaynak bağlamı RBAC'sinin kullanıldığı çalışma alanı mimarisinin basitleştirilmiş bir sürümü gösterilmektedir.

Kaynak bağlamı RBAC için örnek mimari diyagramı.

Bu görüntüde:

  • Microsoft Sentinel için etkinleştirilen Log Analytics çalışma alanı, uygulama ekiplerinin iş yüklerini barındırmak için kullandığı abonelikten izinleri daha iyi yalıtmak için ayrı bir aboneliğe yerleştirilir.
  • Uygulama ekiplerine, kaynaklarını yönetebilecekleri ilgili kaynak gruplarına erişim verilir.

Bu ayrı abonelik ve kaynak bağlamı RBAC, günlükler doğrudan erişimi olmayan bir çalışma alanında depolansa bile, bu ekiplerin erişimi olan tüm kaynaklar tarafından oluşturulan günlükleri görüntülemesine olanak tanır. Uygulama ekipleri günlüklerine Azure portalının Günlükler alanı üzerinden erişebilir, belirli bir kaynağın günlüklerini veya Azure İzleyici aracılığıyla aynı anda erişebilecekleri tüm günlükleri gösterebilir.

Azure dışı kaynaklar için kaynak bağlamı RBAC'sini açıkça yapılandırma

Azure kaynakları, kaynak bağlamı RBAC için yerleşik desteğe sahiptir, ancak Azure dışı kaynaklarla çalışırken ek ince ayarlama gerektirebilir. Örneğin, Microsoft Sentinel için etkinleştirilen Log Analytics çalışma alanınızda Azure kaynakları olmayan veriler Syslog, CEF veya AAD verileri ya da özel toplayıcı tarafından toplanan verilerdir.

Kaynak bağlamı RBAC'sini yapılandırmak istiyorsanız ancak verileriniz bir Azure kaynağı değilse aşağıdaki adımları kullanın.

Kaynak bağlamı RBAC'sini açıkça yapılandırmak için:

  1. Azure İzleyici'de kaynak bağlamı RBAC'sini etkinleştirdiğinizden emin olun.

  2. Microsoft Sentinel ortamının tamamı olmadan kaynaklarınıza erişmesi gereken her kullanıcı ekibi için bir kaynak grubu oluşturun.

    Ekip üyelerinin her biri için günlük okuyucu izinleri atayın.

  3. Oluşturduğunuz kaynak ekibi gruplarına kaynak atayın ve olayları ilgili kaynak kimlikleriyle etiketleyin.

    Azure kaynakları Microsoft Sentinel'e veri gönderdiğinde, günlük kayıtları otomatik olarak veri kaynağının kaynak kimliğiyle etiketlenir.

    İpucu

    Erişim verdiğiniz kaynakları, bu amaçla oluşturulan belirli bir kaynak grubu altında gruplandırmanızı öneririz.

    Bunu yapamazsanız, ekibinizin erişmesini istediğiniz kaynaklara doğrudan günlük okuyucu izinlerine sahip olduğundan emin olun.

    Kaynak kimlikleri hakkında daha fazla bilgi için bkz:

Günlük iletme ile kaynak kimlikleri

Olaylar Ortak Olay Biçimi (CEF) veya Syslog kullanılarak toplandığında, birden çok kaynak sistemden olay toplamak için günlük iletme kullanılır.

Örneğin, BIR CEF veya Syslog iletme VM'si Syslog olayları gönderen kaynakları dinlediğinde ve bunları Microsoft Sentinel'e ilettiğinde, ilettiği tüm olaylara günlük iletme VM kaynak kimliği atanır.

Birden çok ekibiniz varsa, her ayrı ekip için olayları işleyen ayrı günlük iletme VM'leriniz olduğundan emin olun.

Örneğin, VM'lerinizi ayırmak, A Ekibine ait Syslog olaylarının toplayıcı VM A kullanılarak toplanmasını sağlar.

İpucu

  • Günlük ileticiniz olarak şirket içi vm veya AWS gibi başka bir bulut VM'si kullanırken Azure Arc'ı uygulayarak kaynak kimliğine sahip olduğundan emin olun.
  • Günlük iletme VM ortamınızı ölçeklendirmek için, CEF ve Sylog günlüklerinizi toplamak için bir VM ölçek kümesi oluşturmayı göz önünde bulundurun.

Logstash koleksiyonu ile kaynak kimlikleri

Verilerinizi Microsoft Sentinel Logstash çıkış eklentisini kullanarak topluyorsanız, özel toplayıcınızı çıkışınıza kaynak kimliğini içerecek şekilde yapılandırmak için azure_resource_id alanını kullanın.

Kaynak bağlamı RBAC kullanıyorsanız ve API tarafından toplanan olayların belirli kullanıcılar tarafından kullanılabilir olmasını istiyorsanız, kullanıcılarınız için oluşturduğunuz kaynak grubunun kaynak kimliğini kullanın.

Örneğin, aşağıdaki kod örnek bir Logstash yapılandırma dosyasını gösterir:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

İpucu

Farklı olaylara uygulanan etiketleri ayırt etmek için birden çok output bölüm eklemek isteyebilirsiniz.

Log Analytics API koleksiyonuyla kaynak kimlikleri

Log Analytics veri toplayıcı API'sini kullanarak toplama yaparken HTTP x-ms-AzureResourceId istek üst bilgisini kullanarak kaynak kimliğine sahip olaylara atayabilirsiniz.

Kaynak bağlamı RBAC kullanıyorsanız ve API tarafından toplanan olayların belirli kullanıcılar tarafından kullanılabilir olmasını istiyorsanız, kullanıcılarınız için oluşturduğunuz kaynak grubunun kaynak kimliğini kullanın.

Kaynak bağlamı RBAC'sine alternatifler

Kuruluşunuzda gereken izinlere bağlı olarak, kaynak bağlamı RBAC kullanmak tam bir çözüm sağlamayabilir. Örneğin, mimarisi önceki bölümde açıklanan kuruluşun bir iç denetim ekibine Office 365 günlüklerine de erişim izni vermesi gerekip gerekmediğini göz önünde bulundurun. Bu durumda, başka bir tabloya izin vermeden denetim ekibine OfficeActivity tablosunun tamamına erişim vermek için tablo düzeyinde RBAC kullanabilirler.

Aşağıdaki listede, veri erişimine yönelik diğer çözümlerin gereksinimlerinize daha uygun olabileceği senaryolar açıklanmaktadır:

Senaryo Çözüm
Yan kuruluş, tam bir Microsoft Sentinel deneyimi gerektiren bir SOC ekibine sahiptir. Bu durumda, veri izinlerinizi ayırmak için çok çalışma alanılı bir mimari kullanın.

Daha fazla bilgi için, şuraya bakın:
Belirli bir olay türüne erişim sağlamak istiyorsunuz. Örneğin, bir Windows yöneticisine tüm sistemlerdeki Windows Güvenliği olaylara erişim sağlayın.

Böyle durumlarda, her tablonun izinlerini tanımlamak için tablo düzeyinde RBAC kullanın.
Kaynağı temel alarak veya bir olaydaki alanların yalnızca bir alt kümesiyle değil, erişimi daha ayrıntılı bir düzeyle sınırlayın Örneğin, kullanıcının yan kuruluşuna göre Office 365 günlüklerine erişimi sınırlamak isteyebilirsiniz.

Bu durumda, Power BI panoları ve raporlarıyla yerleşik tümleştirmeyi kullanarak verilere erişim sağlayın.
Yönetim grubuna göre erişimi sınırlama Microsoft Sentinel'i güvenliğe ayrılmış ayrı bir yönetim grubuna yerleştirerek grup üyelerine yalnızca en az izinlerin devralınmasını sağlayın. Güvenlik ekibinizde, her grup işlevine göre farklı gruplara izinler atayın. Tüm ekipler çalışma alanının tamamına erişebildiğinden, yalnızca atandıkları Microsoft Sentinel rolleri tarafından kısıtlanan tam Microsoft Sentinel deneyimine erişebilirler. Daha fazla bilgi için bkz . Microsoft Sentinel'de izinler.

Sonraki adımlar

Daha fazla bilgi için bkz . Microsoft Sentinel'de izinler.