Microsoft Sentinel Rehberi 3: Azure Arc ve Azure Monitor Agent ile Windows Güvenlik Loglarının Toplanması

Microsoft Sentinel rehberimizin üçüncü bölümünden devam ediyoruz.

Önceki makalelerimizde Microsoft Sentinel’in ne olduğunu, hangi amaçlarla kullanıldığını ve ücretsiz demo ortamının nasıl oluşturulabileceğini anlatmıştık. Bu yazımızda ise artık kurduğumuz ortama gerçek verileri çekmeye başlayacağız.

Bir SIEM ürünü kullanmaya başladığımızda ilk yapacaklarımızdan biri, kritik olanların öncelikli olarak sonrasında güvenliğini sağlamak istediğimiz sistemlerden log toplamaktır. Çünkü bir sunucuda gerçekleşen brute force saldırılarını, yeni oluşturulan bir kullanıcı hesabını veya kritik bir kullanıcı/yetki değişikliğini SIEM ürünümüze aktaramıyorsak bu olayları merkezi olarak analiz etmemiz de mümkün olmayacaktır.

Peki, şirketimizin localinde çalışan bir windows sunucusu olduğunu düşünelim. Bu sunucu üzerinde her gün binlerce Windows Event Log kaydı oluşuyor. Microsoft Sentinel ise Azure üzerinde çalışan bulut tabanlı bir SIEM çözümü.

Localde olan sunucumuzda oluşan event loglarını Microsoft Sentinel’e nasıl ulaştıracağız?

Tam bu noktada karşımıza üç önemli Microsoft teknolojisi çıkıyor: Azure Arc, Azure Monitor Agent (AMA) ve Data Collection Rules (DCR).

Azure Arc, şirket içindeki veya farklı cloud’da çalışan sunucularımızı Azure üzerinden yönetebilmemizi sağlamaktadır. Azure Monitor Agent (AMA), sunucularımızdan izleme ve güvenlik verilerinin toplanmasında görev almaktadır. Data Collection Rules (DCR) ise hangi verilerin toplanacağını ve nereye gönderileceğini belirlememize yardımcı oluyor.

Bu rehberde, Azure dışında çalışan bir Windows sunucusunu Azure Arc ile Azure’a bağlayacak, Azure Monitor Agent kurulumunu gerçekleştirecek ve Data Collection Rule oluşturarak Windows Security Event Log kayıtlarının Microsoft Sentinel’e aktarılmasını sağlayacağız.

Azure Arc Nedir ve Neden İhtiyaç Duyarız?

Günümüzde birçok kurum hâlâ kendi veri merkezlerinde (On-Premises) Windows ve Linux sunucular barındırıyor. Bazı şirketler ise AWS, Google Cloud veya Azure gibi farklı bulut sağlayıcılarını aynı anda kullanabiliyor.

Peki, Azure üzerinde bulunmayan bu sunucuları Microsoft’un bulut tabanlı yönetim ve güvenlik hizmetlerine nasıl dahil edebiliriz?

İşte Azure Arc bu ihtiyacı karşılamak için geliştirilmiş bir teknoloji.

Azure Arc sayesinde fiziksel veya sanal sunucularımızı Azure’a taşımadan, mevcut konumlarında çalışmaya devam ederken Azure üzerinden yönetebiliyoruz.

Örneğin, şirketimizin localinde çalışan bir Windows Server 2022 sunucusu olduğunu düşünelim. Bu sunucu Active Directory hizmeti veriyor ve kullanıcıların oturum açma işlemleri burada gerçekleşiyor.

Biz bu sunucuyu Azure’a taşımak istemiyoruz. Ancak sunucunun güvenlik loglarını Microsoft Sentinel üzerinde analiz etmek istiyoruz.

Azure Arc ile sunucumuzu Azure’a bağlı bir kaynak olarak kaydedebiliyoruz. Böylece sunucumuza Azure Monitor Agent gibi desteklenen uzantıları dağıtabiliyor ve merkezi yönetim özelliklerinden yararlanabiliyoruz.

Burada önemli bir noktaya dikkat etmek gerekiyor: Azure Arc tek başına log toplamaz veya Microsoft Sentinel’e log göndermez. Azure Arc, sunucumuz ile Azure yönetim hizmetleri arasında bağlantı kurulmasını sağlar. Güvenlik loglarının toplanması için AMA (Azure Monitor Agent) ve uygun veri toplama kurallarına da ihtiyacımız vardır.

Kısacası Azure Arc’ı, şirket içindeki sunucularımızı Azure ekosistemine dahil etmemizi sağlayan bir köprü olarak düşünebiliriz.

Azure Monitor Agent (AMA) Nedir ve Nasıl Çalışır?

Önceki bölümde Azure Arc sayesinde şirket içindeki sunucularımızı Azure’a nasıl dahil edebileceğimizden bahsettik. Ancak bir sunucunun Azure üzerinde görünür olması, o sunucudaki güvenlik loglarının otomatik olarak Microsoft Sentinel’e aktarılacağı anlamına gelmiyor.

Bunun için sunucumuz üzerinde çalışan ve gerekli verileri toplayan bir bileşene ihtiyacımız var.

Azure Monitor Agent (AMA) tam olarak bu noktada devreye giriyor.

AMA, Microsoft tarafından geliştirilen ve Windows ile Linux sistemlerden izleme verilerinin toplanmasını sağlayan bir agent yazılımıdır. Windows Event Log kayıtları, performans sayaçları ve desteklenen diğer veri kaynaklarından bilgi toplayarak bu verileri Azure Monitor altyapısına aktarabilir.

Örneğin, bir Windows sunucusunda başarısız oturum açma girişimi gerçekleştiğini düşünelim. Windows, bu olayı güvenlik günlüklerine 4625 Event ID’siyle kaydeder.

Azure Monitor Agent sayesinde bu kayıtları merkezi bir ortamda toplayabilir ve Microsoft Sentinel üzerinden sorgulayabiliriz.

AMA Her Log Kaydını Otomatik Olarak Toplar mı?

Hayır. Azure Monitor Agent’ın sunucuya kurulmuş olması, bütün logların otomatik olarak Azure’a gönderileceği anlamına gelmez.

Örneğin yalnızca başarısız oturum açma olaylarını incelemek istiyorsak binlerce farklı Windows olayını toplamak zorunda değiliz.

Peki, agent’a hangi logları toplaması gerektiğini nasıl söyleyeceğiz?

Burada Data Collection Rules (DCR) adı verilen veri toplama kuralları devreye giriyor.

DCR sayesinde hangi sunuculardan hangi verilerin toplanacağını ve bu verilerin hangi hedefe gönderileceğini belirleyebiliyoruz.

Böylece hem ihtiyacımız olmayan logların toplanmasını önleyebiliyor hem de gereksiz veri aktarımı ve depolama maliyetlerini azaltabiliyoruz.

Azure Arc ve AMA Arasındaki Fark Nedir?

Bu iki teknolojinin görevleri zaman zaman birbirine karıştırılabiliyor. Aslında farklı ihtiyaçlara hizmet ediyorlar.

Azure Arc, Azure dışında bulunan sunucularımızı Azure’un yönetim altyapısına dahil etmemizi sağlıyor.

Azure Monitor Agent ise bu sunuculardan, tanımladığımız veri toplama kurallarına uygun olarak log ve izleme verilerini topluyor.

Kısacası Azure Arc ile sunucumuzu Azure’a tanıtıyoruz, AMA ile gerekli verileri topluyoruz, DCR ile de hangi verilerin toplanacağını belirliyoruz.

Microsoft Sentinel tarafında Windows Security Events via AMA bağlayıcısını yapılandırdığımızda ise topladığımız Windows güvenlik olaylarını Log Analytics Workspace içerisindeki SecurityEvent tablosunda analiz edebiliyoruz.

Artık mimarimizin temel bileşenlerini tanıdığımıza göre bir sonraki aşamada Data Collection Rules yapısını biraz daha detaylı inceleyebiliriz.

Data Collection Rules (DCR) Nedir?

Azure Arc ve Azure Monitor Agent’ın ne işe yaradığını öğrendik. Şimdi de hangi logları toplayacağımıza nasıl karar vereceğiz? bunlara değinelim.

Bir Windows sunucusunda yalnızca başarısız giriş denemeleri oluşmuyor. Kullanıcı oturumları, servis işlemleri, yetki değişiklikleri ve daha birçok olay Windows Event Log içerisinde bulunabiliyor.

Özellikle Domain Controller gibi yoğun çalışan sistemlerde bu kayıtların sayısı oldukça yüksek olabiliyor. Bizim de Microsoft Sentinel’e göndereceğimiz verileri doğru belirlememiz gerekiyor.

Çünkü Microsoft Sentinel’de veri toplamanın bir maliyeti var. Her şeyi toplamak ilk başta mantıklı gelebilir ancak yüzlerce sunucunun bulunduğu bir ortamda ihtiyaç duymadığımız loglar da ciddi miktarda veri oluşturabilir.

Data Collection Rules (DCR) tam olarak burada işimize yarıyor.

DCR üzerinden Azure Monitor Agent’ın hangi verileri toplayacağını ve bu verilerin hangi Log Analytics Workspace’e gönderileceğini belirleyebiliyoruz.

Örneğin Windows sunucumuzdan yalnızca belirli güvenlik olaylarını toplamak istediğimizi düşünelim:

• 4624: Başarılı oturum açma
• 4625: Başarısız oturum açma
• 4720: Yeni kullanıcı hesabı oluşturulması
• 4728: Global güvenlik grubuna kullanıcı eklenmesi
• 4740: Kullanıcı hesabının kilitlenmesi

Bu olayların tamamı kurallarda işimize yarayabilecek kayıtlar. Ancak her kurumun ihtiyaçları aynı olmayabilir. Bir kurumda bütün oturum açma hareketlerinin takip edilmesi istenirken başka bir kurumda yalnızca belirli olayların toplanması yeterli görülebilir.

DCR Üzerinde Log Toplama Seçenekleri

Microsoft Sentinel’in Windows Security Events via AMA bağlayıcısı üzerinden veri toplama kuralı oluştururken farklı seçeneklerle karşılaşıyoruz.

All Events: Windows Security ve desteklenen AppLocker olaylarının tamamını toplamak için kullanılıyor. Ayrıntılı kayıt ihtiyacımız olduğunda tercih edilebilir ancak veri hacmini de dikkate almamız gerekiyor.

Common: Güvenlik ve denetim açısından önemli olan geniş bir olay kümesini topluyor. All Events seçeneğine göre daha kontrollü bir veri toplama imkânı sağlıyor.

Minimal: Daha sınırlı bir olay kümesini topluyor. Özellikle güvenlik açısından önemli olabilecek olaylara odaklanmak istediğimizde değerlendirebiliriz.

Custom: Toplamak istediğimiz olayları kendimiz belirleyebiliyoruz. XPath sorguları kullanarak belirli Event ID’lerini seçmemiz mümkün.

Burada dikkat etmemiz gereken bir konu var. Yalnızca belirli Event ID’lerini toplamak veri miktarını azaltabilir ancak bazı güvenlik analizleri için ihtiyaç duyduğumuz kayıtların eksik kalmasına da neden olabilir.

Örneğin bir brute force saldırısını araştırırken sadece başarısız girişleri değil, bu denemelerden sonra başarılı bir oturum açılıp açılmadığını da kontrol etmek isteyebiliriz.

Bu nedenle log toplama politikamızı oluştururken yalnızca maliyeti değil, gerçekleştirmek istediğimiz güvenlik analizlerini de dikkate almalıyız.

Bir DCR Birden Fazla Sunucuda Kullanılabilir mi?

Evet. DCR kurallarını her sunucu için ayrı ayrı oluşturmak zorunda değiliz.

Örneğin ortamımızda 10 Windows sunucusu bulunduğunu düşünelim. Aynı güvenlik olaylarını toplamak istediğimiz sunucuları tek bir DCR ile ilişkilendirebiliriz.

Bu ilişki Azure tarafında Data Collection Rule Association (DCRA) olarak adlandırılıyor.

Böylece aynı kuralı birden fazla sunucuda kullanabiliyoruz. Farklı log toplama ihtiyaçlarımız varsa sunucularımız için ayrı kurallar da oluşturabiliriz.

Bu noktaya kadar Azure Arc, AMA ve DCR’nin görevlerini inceledik. Artık bunların nasıl birlikte çalıştığını uygulamalı olarak görebiliriz.

Azure Arc ile Windows Server’ı Azure’a Bağlama

Artık kurulum aşamasına geçebiliriz. İlk olarak şirket içindeki Windows sunucumuzu Azure Arc’a dahil edeceğiz.

Bu işlemi gerçekleştirdiğimizde sunucumuz kendi ortamında çalışmaya devam edecek ancak Azure Portal üzerinden de görüntülenebilir ve yönetilebilir duruma gelecek.

Kuruluma başlamadan önce sunucumuzun Azure servislerine gerekli HTTPS bağlantılarını kurabildiğinden ve Azure üzerinde kullanacağımız abonelik ile kaynak grubunun hazır olduğundan emin olmamız gerekiyor.

İlk adım olarak Azure Portal adresine giriş yapıyoruz. Arama bölümüne Azure Arc yazarak ilgili servise ulaşıyoruz.

Azure Arc sayfasından Machines bölümüne geçerek yeni bir sunucu ekleme işlemini başlatacağız.

Azure Arc sayfasına geldiğimizde daha önce Azure’a dahil edilmiş sunucularımızı görüntüleyebiliyoruz. Benim ortamımda da daha önceden eklediğim sunucular bulunuyor.

Bu ekranda sunucuların hangi Resource Group ve Subscription altında bulunduğunu, Azure bölgesini ve kaynak türünü görebiliyoruz.

Şimdi yeni bir Windows sunucusu eklemek için üst menüde bulunan Onboard seçeneğine tıklıyoruz.

Onboard seçeneğine tıkladığımızda Azure Arc’ın farklı ortamlar için sunduğu bağlantı yöntemlerini görüyoruz.

Burada AWS, Google Cloud, VMware ve Azure Local gibi altyapılar için farklı seçenekler bulunuyor. Bizim amacımız kendi ortamımızda çalışan Windows sunucusunu Azure’a bağlamak olduğu için Any environment seçeneğini kullanacağız.

Bu yöntemle sunucumuza Azure Connected Machine Agent kurarak Azure Arc bağlantısını gerçekleştirebiliyoruz.

Burada küçük bir ayrıntıya da değinelim. Azure Connected Machine Agent ile Azure Monitor Agent aynı yazılım değil. Connected Machine Agent sunucunun Azure Arc’a bağlanmasını sağlarken Azure Monitor Agent güvenlik ve izleme verilerinin toplanmasında görev alıyor.

Any environment seçeneğinin detaylarını açtığımızda Azure Arc’a hangi kaynakları ekleyebileceğimizi görebiliyoruz.

Biz Windows sunucumuzu Azure’a bağlayacağımız için Machines bölümünden ilerleyeceğiz.

Burada iki seçenek bulunuyor. İlkinde Azure Portal üzerinden sunucumuza özel bir kurulum scripti oluşturabiliyoruz. İkinci seçenekte ise Windows Server için kurulum dosyasını indirebiliyoruz.

Bu rehberde Onboard with script yöntemini kullanacağız. Böylece Azure üzerinde gerekli bilgileri belirledikten sonra oluşturulan PowerShell scriptini Windows sunucumuzda çalıştırarak Azure Arc bağlantısını gerçekleştirebileceğiz.

Scripti çalıştıracağımız sunucuda yönetici yetkisine sahip olmamız ve sunucunun gerekli Azure servislerine ağ erişiminin bulunması gerekiyor.

Azure Arc Temel Yapılandırma Ayarları

Onboard seçeneğine tıkladığımızda karşımıza sunucumuzun Azure üzerindeki temel bilgilerini belirleyeceğimiz ekran geliyor.

Burada birkaç alanı doldurmamız gerekiyor.

Subscription: Sunucumuzun Azure üzerinde hangi abonelik altında yönetileceğini seçiyoruz.

Resource Group: Azure Arc’a ekleyeceğimiz sunucunun hangi kaynak grubunda bulunacağını belirliyoruz. İster mevcut bir Resource Group seçebilir ister yeni bir tane oluşturabiliriz.

Region: Azure Arc kaynağının hangi Azure bölgesinde tutulacağını belirliyoruz. Burada seçeceğimiz bölge, sunucumuzun fiziksel olarak taşınacağı anlamına gelmiyor. Sunucu mevcut konumunda çalışmaya devam ediyor.

Operating System: Azure Arc’a bağlayacağımız sunucunun işletim sistemini seçiyoruz. Biz Windows Server kullanacağımız için Windows seçeneğiyle devam ediyoruz.

Ekranda ayrıca Connect SQL Server seçeneği bulunuyor. Bu seçenek, sunucuda bulunan SQL Server örneklerinin Azure Arc’a dahil edilmesi için kullanılabiliyor. Bizim senaryomuzda SQL Server entegrasyonu yapmayacağımız için bu alanı işaretlemiyoruz.

Bu ayarları tamamladıktan sonra kurulum scriptini oluşturacağımız aşamaya geçebiliriz.

Azure Arc Kurulum Scriptinin Oluşturulması

Temel yapılandırma ayarlarımızı tamamladıktan sonra Download and run script bölümüne geliyoruz.

Bu ekranda Azure, seçtiğimiz Subscription, Resource Group, Region ve işletim sistemi bilgilerine göre bir PowerShell scripti oluşturuyor.

Oluşturulan scriptin içerisinde sunucumuzun Azure Arc’a bağlanabilmesi için gerekli yapılandırma bilgileri bulunuyor. Script çalıştırıldığında Azure Connected Machine Agent’ın kurulumu gerçekleştiriliyor ve sunucumuzun Azure’a kaydedilmesi için bağlantı işlemleri başlatılıyor.

Scriptimizi Download butonuyla indiriyoruz. Ardından Azure Arc’a dahil etmek istediğimiz Windows sunucusuna geçerek PowerShell’i yönetici yetkileriyle çalıştırıyoruz.

İndirdiğimiz PowerShell scriptini sunucumuz üzerinde çalıştırıyoruz. Kurulum sırasında Azure hesabımızla oturum açmamız ve gerekli yetkilendirme işlemlerini tamamlamamız istenebilir.

İşlem başarıyla tamamlandığında sunucumuz Azure Arc üzerinde kayıtlı bir kaynak olarak görüntülenmeye başlayacak.

İndirdiğimiz PowerShell scriptini Windows sunucumuz üzerinde yönetici yetkileriyle çalıştırıyoruz.

Script çalışmaya başladığında Azure Connected Machine Agent kurulum dosyasının indirildiğini, doğrulandığını ve sunucuya yüklendiğini görüyoruz.

Kurulumun ardından Azure servislerine erişim kontrolleri gerçekleştiriliyor. Bu aşamada Azure hesabımızla oturum açarak kimlik doğrulamasını tamamlıyoruz.

Ekran görüntüsünde de görüldüğü üzere agent kurulumu başarıyla tamamlanmış ve sunucumuz için Azure üzerinde kaynak oluşturma işlemi başlamış durumda.

Bu işlemin tamamlanmasının ardından Azure Arc üzerinden sunucumuzun bağlantı durumunu kontrol edeceğiz.

Azure Arc Bağlantısının Tamamlanması

PowerShell scriptimizin çalışması tamamlandı. Ekran görüntüsünde de görüldüğü üzere Azure Connected Machine Agent kurulumu başarılı bir şekilde gerçekleşti ve sunucumuz Azure’a bağlandı.

Kurulum sırasında agent paketinin indirilmesi, dijital imzasının doğrulanması, Azure servislerine bağlantı kontrolleri ve kimlik doğrulama işlemleri gerçekleştirildi.

Son aşamada ise Connected machine to Azure mesajını alıyoruz. Bu mesaj, sunucumuzun Azure Arc’a başarıyla kaydedildiğini gösteriyor.

Ayrıca işlem sonunda Azure Portal üzerinde sunucumuzun detaylarına ulaşabileceğimiz bir bağlantı da veriliyor.

Şimdi Azure Portal’a geri dönerek sunucumuzun gerçekten Azure Arc üzerinde görünüp görünmediğini ve bağlantı durumunu kontrol edelim.

Azure Arc Üzerinden Sunucumuzun Kontrol Edilmesi

PowerShell tarafındaki kurulum tamamlandıktan sonra Azure Portal’a geri dönüyoruz.

Azure Arc → Machines bölümüne geldiğimizde eklediğimiz WEC01 isimli Windows sunucusunu listede görebiliyoruz.

Sunucumuzun detaylarına girerek Overview bölümünden bağlantı durumunu kontrol ediyoruz. Burada Connected durumunu görmemiz, Azure Arc bağlantısının aktif olduğunu gösteriyor.

Şimdi sunucumuzun Extensions bölümüne geçiyoruz.

Bu bölümde Azure Arc üzerinden sunucumuza yüklenmiş uzantıları görüntüleyebiliyoruz. Ekran görüntüsünde de görüldüğü üzere henüz herhangi bir uzantımız bulunmuyor.

Daha önce bahsettiğimiz Azure Monitor Agent’ı da bu uzantılar üzerinden yönetebiliyoruz.

Ancak bizim amacımız Windows Security Event Log kayıtlarını Microsoft Sentinel’e aktarmak olduğu için AMA kurulumunu Sentinel’in Windows Security Events via AMA veri bağlayıcısı üzerinden yapılandıracağız.

Bu yöntemle veri toplama kuralımızı oluştururken Windows sunucumuzu da ilgili kuralla ilişkilendirebileceğiz.

Azure Monitor Agent (AMA) Kurulumu

Windows sunucumuzu Azure Arc’a bağladık. Şimdi sıra bu sunucudan güvenlik loglarını toplayabilmek için Azure Monitor Agent kurulumuna geldi.

Azure Arc üzerinde WEC01 sunucumuzu açarak Extensions → Add bölümüne geçiyoruz.

Bu ekranda Azure Arc üzerinden sunucumuza yükleyebileceğimiz farklı uzantılar bulunuyor. Biz Azure Monitor Agent for Windows (Recommended) seçeneğini seçiyoruz.

Burada Azure Monitor Agent’ın Windows sunucumuza bir uzantı olarak dağıtılacağını belirtelim. Bu sayede kurulum dosyasını manuel indirip sunucu üzerinde çalıştırmamız gerekmiyor. Azure Arc üzerinden agent kurulumunu başlatabiliyoruz.

Ancak AMA’nın kurulması, güvenlik loglarının hemen Microsoft Sentinel’e gönderilmeye başlayacağı anlamına gelmiyor. Bunun için sunucumuzu uygun bir Data Collection Rule (DCR) ile ilişkilendirmemiz gerekiyor.

Agent kurulumunu tamamladıktan sonra Microsoft Sentinel tarafında veri toplama kuralımızı oluşturacağız.

Azure Monitor Agent Kurulumunun Başlatılması

Azure Monitor Agent for Windows uzantısını seçtikten sonra kurulum işlemini başlatıyoruz.

Azure Portal bizi dağıtımın durumunu takip edebileceğimiz ekrana yönlendiriyor. Burada WEC01 sunucumuza AzureMonitorWindowsAgent uzantısının dağıtıldığını görebiliyoruz.

İlk aşamada dağıtım durumu Accepted olarak görünüyor. Bu durum, Azure’un kurulum isteğimizi kabul ettiğini ancak işlemin henüz tamamlanmadığını gösteriyor.

Kurulum tamamlandığında Azure Arc üzerinden WEC01 sunucumuzun Extensions bölümüne tekrar girerek Azure Monitor Agent uzantısının durumunu kontrol edeceğiz.

Agent’ın başarıyla kurulmasının ardından Windows Security Event Log kayıtlarının hangi Log Analytics Workspace’e gönderileceğini belirlemek için Microsoft Sentinel üzerinden DCR yapılandırmasına geçeceğiz.

Azure Monitor Agent Kurulumunun Doğrulanması

Kurulum işlemi tamamlandıktan sonra Azure Arc üzerinden WEC01 sunucumuzun Extensions bölümüne tekrar geliyoruz.

Ekran görüntüsünde AzureMonitorWindowsAgent uzantısının başarıyla yüklendiğini görebiliyoruz. Kurulum sırasında kullanılan agent sürümü 1.43.0.0 ve otomatik yükseltme özelliği de etkin durumda.

Böylece Windows sunucumuzda Azure Monitor Agent kurulumunu tamamlamış olduk.

Ancak şu anda yalnızca agent kurulu. Henüz hangi Windows güvenlik olaylarını toplayacağımızı ve bu kayıtların hangi Log Analytics Workspace’e gönderileceğini belirlemedik.

Bunun için Microsoft Sentinel tarafında Windows Security Events via AMA veri bağlayıcısını kullanarak bir Data Collection Rule oluşturacağız.

Oluşturacağımız DCR’yi WEC01 sunucumuzla ilişkilendirdikten sonra Windows Security Event Log kayıtlarının Sentinel’e aktarılmasını sağlayabileceğiz.

Microsoft Sentinel Üzerinden Windows Security Events Bağlayıcısının Kurulması

Azure Monitor Agent kurulumunu tamamladık. Şimdi Windows sunucumuzdaki güvenlik loglarını Microsoft Sentinel’e gönderebilmek için veri bağlayıcımızı yapılandıracağız.

Microsoft Sentinel üzerinden Content Hub bölümüne giriyoruz ve arama alanına Windows Security Events yazıyoruz.

Karşımıza Microsoft tarafından sağlanan Windows Security Events çözümü çıkıyor. Bu çözümün içerisinde Windows Security Events via AMA veri bağlayıcısı ve Windows güvenlik olaylarını analiz etmek için kullanılabilecek hazır içerikler bulunuyor.

Biz Azure Monitor Agent kullandığımız için Windows Security Events via AMA bağlayıcısıyla ilerleyeceğiz. Eski Log Analytics Agent (MMA) yöntemini kullanmayacağız.

Öncelikle Windows Security Events çözümünü seçerek kurulumunu gerçekleştiriyoruz. Ardından ilgili veri bağlayıcısını açıp hangi sunuculardan hangi güvenlik olaylarının toplanacağını belirleyeceğimiz DCR yapılandırmasına geçeceğiz.

Windows Security Events via AMA Bağlayıcısının Yapılandırılması

Windows Security Events çözümünü yükledikten sonra Microsoft Sentinel’in Data connectors bölümüne geri dönüyoruz.

Burada Windows Security Events via AMA bağlayıcısının listelendiğini görebiliyoruz.

Bağlayıcıyı seçtiğimizde sağ tarafta bağlantı durumu, son veri alınma zamanı ve ilgili çözümün içerikleri gibi bilgiler bulunuyor.

Şu anda bağlantı durumumuz Disconnected olarak görünüyor. Henüz Windows sunucumuzdan herhangi bir güvenlik logu toplamaya başlamadığımız için bu aşamada beklediğimiz bir durum.

Şimdi ekranın alt kısmındaki Open connector page butonuna tıklayarak bağlayıcının yapılandırma sayfasına geçiyoruz.

Buradan bir Data Collection Rule oluşturarak WEC01 sunucumuzdan hangi Windows güvenlik olaylarını toplayacağımızı belirleyeceğiz.

Data Collection Rule (DCR) Oluşturulması

Windows Security Events via AMA bağlayıcısının sayfasına geldiğimizde öncelikle mevcut yapılandırmamızı kontrol ediyoruz.

Table management bölümünde SecurityEvent tablosunu görüyoruz. Windows sunucumuzdan toplayacağımız güvenlik olayları bu tabloda saklanacak.

Bizim ortamımızda Log Analytics Workspace olarak sentinel-lab-2 kullanılıyor ve verilerin saklama süresi 30 gün olarak ayarlanmış durumda.

Configuration bölümüne geldiğimizde ise henüz herhangi bir Data Collection Rule oluşturulmadığını görüyoruz.

Şimdi Create data collection rule seçeneğine tıklayarak yeni bir kural oluşturacağız.

Bu kural üzerinden WEC01 sunucumuzu seçecek ve hangi Windows Security Event kayıtlarının Microsoft Sentinel’e gönderileceğini belirleyeceğiz.

DCR Temel Ayarlarının Yapılandırılması

Create data collection rule seçeneğine tıkladığımızda DCR Wizard ekranı açılıyor.

İlk olarak Basic bölümünde oluşturacağımız veri toplama kuralının adını ve Azure üzerindeki kaynak bilgilerini belirliyoruz.

Ben kural adını dcr-windows olarak belirledim. Bu isim tamamen bizim tercihimize bağlı. Özellikle birden fazla DCR bulunan ortamlarda kurallara anlaşılır isimler vermek, ileride yönetim açısından kolaylık sağlayacaktır.

Ardından kullanacağımız Subscription ve Resource Group bilgilerini seçiyoruz.

Bu aşamada henüz hangi logları toplayacağımızı belirlemiyoruz. Yalnızca DCR kaynağımızın temel bilgilerini oluşturuyoruz.

Ayarlarımızı tamamladıktan sonra Next: Resources butonuyla devam ediyoruz.

DCR İçin Kaynak Sunucunun Seçilmesi

DCR’nin temel ayarlarını tamamladıktan sonra Resources bölümüne geçiyoruz.

Bu ekranda Azure aboneliğimiz altında bulunan ve veri toplama kuralını uygulayabileceğimiz sunucular listeleniyor.

Biz daha önce Azure Arc üzerinden WEC01 isimli Windows sunucumuzu Azure’a bağlamıştık. Şimdi listeden bu sunucuyu seçiyoruz.

Burada birden fazla sunucu seçmemiz de mümkün. Örneğin aynı güvenlik loglarını toplamak istediğimiz 10 farklı Windows sunucumuz varsa hepsini aynı DCR ile ilişkilendirebiliriz.

Bizim ortamımızda yalnızca WEC01 sunucusunu seçerek devam ediyoruz.

Bu işlemle DCR ile sunucumuz arasında bir ilişki oluşturulacak. Azure tarafında bu ilişki Data Collection Rule Association (DCRA) olarak adlandırılıyor.

Ekranda ayrıca Azure Monitor Agent’ın gerekli olması durumunda otomatik kurulacağı belirtiliyor. Biz AMA kurulumunu önceki adımlarda manuel olarak gerçekleştirdiğimiz için tekrar kurmamız gerekmiyor.

Bir diğer ayrıntı ise System Assigned Managed Identity. Azure, bu sunucu için sistem tarafından atanan yönetilen kimliği etkinleştirebiliyor. Bu kimlik sayesinde sunucu, desteklenen Azure servisleriyle kimlik doğrulaması gerçekleştirebiliyor.

Sunucumuzu seçtikten sonra Collect bölümüne geçerek hangi Windows güvenlik olaylarını toplayacağımızı belirleyeceğiz.

DCR Üzerinden Toplanacak Windows Güvenlik Loglarının Belirlenmesi

Resources bölümünde WEC01 sunucumuzu seçtikten sonra Collect sekmesine geçiyoruz.

Burada Microsoft Sentinel’e hangi Windows Security Event kayıtlarının gönderileceğini belirliyoruz.

Karşımıza dört farklı seçenek çıkıyor: All Security Events, Common, Minimal ve Custom.

Daha önce bu seçeneklerin ne işe yaradığından bahsetmiştik. Biz bu kurulumda Custom seçeneğiyle ilerleyeceğiz.

Çünkü amacımız yalnızca logların Sentinel’e ulaştığını görmek değil, hangi güvenlik olaylarını topladığımızı da kendimiz belirlemek.

İlk testimizde Windows Event ID 4624 (başarılı oturum açma) ve 4625 (başarısız oturum açma) kayıtlarını toplayacağız.

Böylece Windows sunucumuz üzerinde gerçekleşen oturum açma işlemlerini Microsoft Sentinel’in SecurityEvent tablosunda inceleyebileceğiz.

Gerçek bir kurum ortamında ise toplanacak Event ID’lerinin, güvenlik izleme ihtiyaçlarına ve kullanılacak korelasyon kurallarına göre belirlenmesi gerekiyor. Özellikle 4624 gibi sık oluşan olayların veri hacmini artırabileceğini de unutmamak gerekiyor.

DCR Yapılandırmasının Kontrol Edilmesi

Log toplama seçeneklerimizi belirledikten sonra Review + create bölümüne geçiyoruz.

Bu ekranda oluşturacağımız DCR’nin adını, Subscription ve Resource Group bilgilerini, ilişkilendirdiğimiz sunucuları ve seçtiğimiz güvenlik olaylarını kontrol edebiliyoruz.

Üst tarafta Validation passed mesajını görmemiz, yapılandırmamızın Azure tarafından doğrulandığını gösteriyor.

Burada özellikle Selected events alanını kontrol etmemiz gerekiyor. Çünkü seçtiğimiz log toplama yöntemine göre Sentinel’e aktarılacak veri miktarı değişebilir.

Ayarlarımızı doğruladıktan sonra Create butonuyla DCR oluşturma işlemini başlatıyoruz.

Sonuç

Microsoft Sentinel rehberimizin üçüncü bölümünde, Azure dışında çalışan bir Windows sunucusunun güvenlik loglarını Sentinel ortamımıza aktarabilmek için gerekli yapılandırmaları ele aldık.

İlk olarak Azure Arc kullanarak Windows sunucumuzu Azure’a bağladık. Ardından Azure Monitor Agent kurulumunu gerçekleştirdik ve son aşamada Data Collection Rule oluşturarak hangi Windows güvenlik olaylarının toplanacağını belirledik.

Bu çalışmada laboratuvar ortamımız için All Security Events seçeneğini tercih ettik. Gerçek kurum ortamlarında ise toplanacak logların ihtiyaçlara göre belirlenmesi, hem maliyet hem de güvenlik analizlerinin verimliliği açısından önemli.

Burada unutulmaması gereken nokta, bir sunucudan log toplamanın tek başına güvenlik izleme sürecini tamamlamadığıdır. Topladığımız kayıtları analiz etmemiz, şüpheli aktiviteleri tespit edebilmemiz ve gerektiğinde alarm oluşturabilmemiz gerekiyor.

Bir sonraki yazımızda Microsoft Sentinel üzerinde KQL (Kusto Query Language) sorgularını inceleyecek, topladığımız Windows güvenlik kayıtları üzerinden örnek sorgular gerçekleştireceğiz.

Bir sonraki rehberde görüşmek üzere.