Windows File Server’da silinen dosya nasıl araştırılır?

Her silme olayı geriye dönük olarak görünmez

Windows File Server’da silme işlemini yapan hesabı belirlemek için ilgili sunucu ve paylaşım üzerinde denetim politikalarının önceden yapılandırılmış ve gerekli olay kayıtlarının tutuluyor olması gerekir. Denetim olaydan önce etkin değilse, yalnızca dosyanın artık görünmediği bilgisi kullanıcıyı kanıtlamaz. Eksik kayıt sonradan üretilemez.

Rokunet AI-Agent, File Server rolü bulunan Windows sistemlerde uygun olay kontrollerini ve mevcut log bulgularını değerlendirmeye yardımcı olabilir. Kontrolün kapsamı yapılandırmaya, erişim yetkilerine ve olayların tutulduğu döneme bağlıdır. Sonuçta veri yoksa veya kayıt alınamıyorsa rapor bunu açıkça belirtmelidir.

İncelemeye başlamadan önce

1. Dosya adı veya yolu, yaklaşık zaman aralığı ve etkilenen paylaşımı belirleyin.
2. İlgili File Server ve paylaşım için audit politikasının olaydan önce açık olup olmadığını doğrulayın.
3. Güvenlik olaylarının saklama süresi içinde olup olmadığını ve logların üzerine yazılıp yazılmadığını kontrol edin.
4. Varsa olay kimliği, hesap, dosya yolu ve zaman bilgisini bir arada inceleyin.
5. Yedeğin varlığını ve geri yükleme seçeneğini ayrıca değerlendirin; geri yükleme silme nedenini açıklamaz.

Kanıt ile tahmini ayırın

Paylaşılan klasöre erişimi olan bir hesabın listelenmesi, o hesabın dosyayı sildiğinin kanıtı değildir. Audit kaydı bulunuyorsa olayın zamanı ve kapsamı raporlanmalı; bulunmuyorsa bu sınırlama açıkça yazılmalıdır. Dosya adının değişmesi, taşınması, senkronizasyon veya uygulama işlemi de araştırılmalıdır.

AI-Agent tanı ve kanıtları toparlamaya yardımcı olur; otomatik olarak kullanıcıyı suçlamaz, dosyayı geri getirmez veya denetim ayarlarını değiştirmez. Uzman ekibimiz log, yedek ve işletim kapsamını birlikte inceler.

File Server izleme yaklaşımını konuşalım →

Denetim ayarları olaydan önce hazırlanmalı

Windows dosya erişim denetimi, işletim sistemi ve paylaşım için ilgili audit politikalarının açılmasına, hangi nesne veya klasörlerin izleneceğinin seçilmesine ve log saklama kapasitesine bağlıdır. Bütün klasörlere kapsamı düşünmeden ayrıntılı denetim eklemek yüksek olay hacmi oluşturabilir. Yöneticiler, yasal ve operasyonel gereksinimlere göre izlenecek yolları ve saklama düzenini önceden belirlemelidir.

Olay sonrası araştırmada güvenlik logları saklanmış mı, doğru sunucuya mı bakılıyor, istemci/kimlik saatleri uyumlu mu ve paylaşım üzerinde başka bir otomasyon çalışıyor mu kontrol edilir. Kullanıcı hesabı kaydı, aynı kişinin fiziksel olarak işlemi yaptığı anlamına gelmez; paylaşılan hesaplar, servis kimlikleri veya devredilmiş oturumlar ayrı değerlendirilmelidir.

Dosya kurtarma ayrı bir iş akışıdır

Denetim kayıtları “kim/ne zaman” incelemesine yardımcı olur; yedek ise verinin geri alınmasına hizmet eder. Birinin mevcut olması diğerinin yerine geçmez. Geri yükleme öncesi dosyanın doğru sürümü, etkilenen kullanıcılar ve hedef klasör belirlenmeli; üzerine yazma riski kontrol edilmelidir. Yedeklerin saklama süresi ve geri dönüş yöntemi hizmet kapsamına göre kararlaştırılır.

Agent raporunda olay bulunmuyorsa, bu “kimse silmedi” anlamına gelmez; denetim ayarı kapalı, log silinmiş veya retention penceresi dolmuş olabilir. Sonuç, veri kapsamı ve eksik kanıtla birlikte sunulmalıdır.

Gelecek olaylar için hazırlık

File Server sahipleri hangi paylaşımların kritik olduğunu ve olay kayıtlarının kim tarafından inceleneceğini belirlemelidir. Audit politikası değişikliği öncesinde log boyutu, saklama süresi ve kişisel veri/çalışan gizliliği gereksinimleri kurum içinde değerlendirilmelidir. Fazla geniş denetim, incelenmesi güç miktarda olay üretebilir; kapsamı bilgi güvenliği sorumlusu ve sistem sahibi birlikte tanımlamalıdır.

Geri dönüş planı için yedeklerin dosya seviyesinde nasıl aranacağı, önceki sürümlerin olup olmadığı ve geri yükleme onayının kimde bulunduğu netleştirilmelidir. Kritik bir dosyayı geri getirmek için kaynak klasöre doğrudan yazmak yerine ayrı konumda doğrulama yapılması, yanlış sürümün üzerine yazılmasını önlemeye yardımcı olur. Bu adımlar kurumun mevcut yedek ürününe ve hizmet kapsamına göre değişir.

Olay sonrası raporda bulunan ve bulunamayan kanıtlar, kullanılan zaman aralığı ve kontrol edilen sunucular açıkça yazılmalıdır. Böyle bir kayıt, gelecekte denetim ayarı, log saklama veya yedek politikasını geliştirmek için temel sağlar.

Olay kaydını koruyun ve kapsamı yazın

Şüpheli silme fark edildiğinde ilgili sunucunun loglarının korunması, denetim kayıtlarının üzerine yazılmasını önlemek için önem taşıyabilir. Kurumun olay müdahale ve kişisel veri süreçleri izlenmelidir. Log dışa aktarımı ve erişim, yalnızca yetkili kişiler tarafından güvenli şekilde yapılmalıdır. Araştırma kapsamına kullanıcı hesabı, dosya yolu, paylaşım, tarih aralığı ve ilgili yedek noktası eklenir.

Olaylar birden fazla kaynaktan gelebilir: Windows güvenlik denetimi, dosya paylaşımı kayıtları, yedekleme kataloğu veya senkronizasyon uygulaması. Bu kayıtlar aynı zaman dilimi ve saat dilimiyle karşılaştırılmalıdır. Bir kaynaktaki eksik olay, diğer kaynakta kayıt olmadığı anlamına gelmez; her kaynak ayrı belirtilir.

Sonuç raporu kimlik bilgilerini gereksiz yere çoğaltmamalı; yalnızca olay için gerekli erişim ve bulguları içermelidir. Teknik bulgular, kurumun insan kaynakları veya hukuk süreçlerinin yerine geçmez.