Replay ve Key Design: Veriyi Arşivden Geri Çıkarmak

Object storage'daki veriyi gerektiğinde isabetli biçimde geri çağırmanın iki koşulu: doğru key prefix tasarımı ve çalışan bir replay mekanizması

Arşivin asıl sınavı geri çağırmadır

Telemetriyi S3 uyumlu object storage'a yazmak zor bir iş değildir. Her pipeline bunu yapabilir, depolama maliyeti SIEM'in çok altındadır ve ilk aylarda konu çözülmüş görünür.

Asıl sınav daha sonra gelir. Bir soruşturma kapsamında, iki yüz terabyte sıkıştırılmış object arasından tek bir müşteriye ait tek bir firewall'ın belirli bir öğleden sonrasına ilişkin dört saatlik kaydı istenir. Bu talebin dakikalar içinde mi yoksa günler süren bir çalışmayla mı karşılanacağı, o soru sorulmadan aylar önce verilmiş iki karara bağlıdır: object'lerin nasıl isimlendirildiği ve verinin nasıl geri getirileceği.

Bu iki karar, arşivi bir compliance yükümlülüğü olmaktan çıkarıp operasyonel bir kabiliyete dönüştürür.

Object storage'da index yoktur; isimlendirme sorgunun kendisidir

Bir depoda her kutunun üzerinde yalnızca "kutu" yazıyorsa, belgeler arşivlenmiş değil düşük maliyetle kaybedilmiş olur. Etiketlerde müşteri, belge tipi, yıl ve ay bilgisi yer alıyorsa aynı depoda aranan kutu, tek bir kapak açılmadan dakikalar içinde bulunabilir.

Object key'leri bu etiketlerle aynı işlevi görür. Object storage'da sorgulanacak bir index, filtrelenecek bir alan yoktur; elde yalnızca key prefix vardır. İyi tasarlanmış bir key şu yapıdadır:

Bu path'teki her parça, veri yazılırken event'in kendi alanlarından üretilir. Tenant ve log type event pipeline'dan geçerken atanır; tarih ve saat bilgisi event'in timestamp'inden gelir. Belirli bir müşterinin belirli bir güne ait firewall kayıtlarını isteyen kişi yalnızca ilgili prefix'i seçer ve arşivin geri kalanına hiç dokunulmaz. 

Key'e Hangi Alanlar Girmelidir

Key'e yalnızca kardinalitesi düşük, yazma anında bilinen ve neredeyse her geri çağırma talebinde kullanılan alanlar konulmalıdır.

Key'e Hangi Alanlar Girmemelidir

Kardinalitesi yüksek alanlar key'e konulmamalıdır. Kullanıcı adı, session identifier veya raw source address gibi alanlar ilk bakışta faydalı görünür; ancak her biri tek bir küçük object içeren milyonlarca dizin oluşturur. Listeleme operasyonları yavaşlar ve request maliyetleri karşılığı olmadan artar.

Buna karşın address seviyesinde kırılım gerçekten gerekiyorsa üç uygulanabilir yaklaşım vardır.

Subnet seviyesinde kesmek. Path'e yazılan bir /24, altmış beş bin ayrı address'i tek bir dizinde toplar. Soruşturmaların büyük bölümü zaten network seviyesinde başladığı için pratikte yeterli olur.

Sabit sayıda bucket'a dağıtmak. Address'ler otuz iki veya altmış dört gibi sabit bir bucket kümesine deterministik biçimde eşlenir. Her address tam olarak bir bucket'ta bulunur ve dizin sayısı ortamdaki farklı address sayısından bağımsız kalır.

Yalnızca kritik varlıkları ayırmak. Sınırlı sayıda kritik sisteme kendi prefix'i verilir, geri kalan tüm veri ortak path'te tutulur. Karmaşıklığın küçük bir bölümüyle geri çağırma faydasının büyük bölümü elde edilir.

Zaman kırılımı hacme göre belirlenir

Temel kural şudur: sağlıklı boyutta object üretmeye devam eden en ince zaman kırılımı seçilmelidir.

Günde sekiz yüz gigabyte üreten bir tenant için saatlik dizinler uygundur; her dizin verimli okunabilecek büyüklükte bir object kümesi tutar. Aynı kırılım günde iki gigabyte üreten bir tenant'a uygulandığında çok sayıda küçük parça oluşur; bu durumda günlük kırılım daha doğrudur. Multi-tenant ortamlarda bu ayarın tenant bazında değiştirilebilmesi, tek bir varsayılan değerden çok daha fazla değer üretir.

Object boyutu da aynı ölçüde önemlidir. Her yazma yolunda, bir object kapanmadan önce ne kadar veri birikeceğini veya ne kadar süre geçeceğini belirleyen eşikler bulunur. Bu eşikler düşük tutulduğunda milyonlarca küçük object oluşur; request maliyeti yükselir ve geri çağırma sırasında listeleme belirgin biçimde yavaşlar. Beş-on beş dakikada kapatılan, birkaç yüz megabyte'lık object'ler her iki sorunu da önler.

Format tarafında newline-delimited JSON basit, okunabilir ve geniş uyumluluğa sahiptir. Arşiv üzerinde doğrudan analitik sorgu çalıştırılması planlanıyorsa kolon tabanlı bir dosya formatı daha uygun olabilir. Syslog metninde sıkıştırma her iki durumda da sekiz-on kat seviyesine ulaşır.

Key'e Yazılan Alan Event'in İçinde de Bulunmalıdır

Prefix hızlı seçim için tasarlanır; veri taşıma aracı değildir. Tenant bilgisi yalnızca path'te tutuluyorsa, event geri okunduğu anda bu bilgiyi kaybeder. Tenant'ı olmayan bir replay verisi ise yönlendirilemez, filtrelenemez ve hangi müşteriye ait olduğu belirlenemez. Key, event'lerin üzerinde duran bir index olarak ele alınmalı; event'in bir parçası olarak değil.

Replay: Verinin Geri Getirilmesi

Şekil 1 — Replay, seçilen object'leri arşivden alır, aynı pipeline üzerinden yeniden işler ve soruşturmanın gerektirdiği hedefe iletir.

Süreç şu şekilde işler. Analist control plane üzerinde tenant, tarih aralığı ve prefix seçer; bu sırada hiçbir dosyanın içeriğini açmaz. Seçilen object'ler bir replay pipeline'ının kaynağı hâline gelir. Veri, ilk gün onu işleyen aynı processing engine üzerinden yeniden akar; bu aşamada tekrar filtrelenebilir, tekrar parse edilebilir, maskelenebilir veya ilk toplandığı dönemde henüz mevcut olmayan bir hedefe göre yeniden şekillendirilebilir. Sonuç, ihtiyaç duyulan yere iletilir: SIEM'e, log management katmanına, farklı bir platforma ya da teslim edilecek bir dosyaya.

Buradaki en önemli özellik şudur: ilk aşamada verilen yönlendirme kararları bağlayıcı değildir.

Üç makineyi ve altı saatlik bir pencereyi kapsayan bir soruşturmada, ilgili prefix'lerin altındaki sekiz yüz gigabyte'ın tamamı geri yüklenmez. Yalnızca ilgili prefix'ler seçilir, akış pipeline içinde bu üç address'e daraltılır ve SIEM'e birkaç yüz megabyte iletilir. Lisans etkisi ihmal edilebilir düzeyde kalırken görünürlük tam olarak sağlanır.

Ucuz arşiv ile isabetli geri çağırma arasındaki bu denge, veri girişinde uygulanan filtrelemeyi güvenli hâle getirir. Girişte verilen her yönlendirme kararı, çıkışta geri alınabilir kalır. Bunun tek koşulu, replay mekanizmasının filtreleme yapabilmesidir; yalnızca tüm veriyi geri yükleyebilen bir yapı pratikte ikinci kez kullanılmaz.

Replay Hangi Durumlarda Kullanılır

Detection kuralının geriye dönük testi. Yeni yazılan bir kuralın son doksan günde kaç kez tetikleneceği, ilgili kaynaklar log management katmanına replay edilerek kural üretime alınmadan önce ölçülebilir.

Geç gelen bir olayın incelenmesi. İhbar altı ay öncesine ait bir aktiviteyle ilgiliyken SIEM yalnızca doksan gün saklıyorsa, ilgili prefix'ler replay edilir ve inceleme kesintiye uğramadan yürütülür.

Platform geçişi veya değerlendirmesi. Yeni bir SIEM, sentetik trafik yerine gerçek tarihsel veriyle beslenebilir; iki platform aynı event kümesi üzerinde karşılaştırılabilir. Bu, geçiş riskini azaltmanın en etkili yollarından biridir ve ancak geçmiş veri platformdan bağımsız bir katmanda tutuluyorsa mümkün olur.

Parser onarımı. Vendor tarafındaki bir format değişikliği parser'ı bozduğunda, düzeltme sonrasında etkilenen dönem raw veriden yeniden işlenir ve aranabilir katmandaki boşluk kapatılır. Bu katmana parse edilmiş veri yerine raw veri yazılmasının operasyonel karşılığı budur.

Denetim veya hukuki taleplerin karşılanması. Belirli bir tarih aralığı arşivden çekilerek teslim edilir; veri hiç filtrelenmemiş kopyadan alındığı için içeriğinde eksilme olmaz.

Lifecycle Politikalarında Dikkat Edilmesi Gereken Nokta

Veriyi deep archive sınıflarına taşıyan cloud lifecycle kuralları maliyet tablosunda olumlu görünür; ancak geri çağırma kabiliyetini fark edilmeden sınırlayabilir. Veri bu sınıflara indiğinde geri getirme süresi dakikalardan saatlere çıkar ve retrieval ile egress ücretleri devreye girer. Yedi yıllık bir compliance yükümlülüğü için bu kabul edilebilir; devam eden bir incelemenin üçüncü saatinde ise kullanılabilir değildir.

Bu nedenle baştan netleştirilmesi gereken soru şudur: arşivin hangi bölümünün incident response zaman ölçeğinde erişilebilir olması gerekir? Bu bölüm, gerçekten o sürede veri döndürebilecek bir depolama sınıfında tutulmalıdır. On-premise object storage bu sorunu tamamen ortadan kaldırır ve replay'i müdahale sürecinin parçası olarak kullanan ekipler için önemli bir avantaj sağlar.

Sonuç

Key design ve replay, fiilen kullanılan bir arşiv ile yalnızca maliyeti ödenen bir arşiv arasındaki farkı belirler. İsimlendirme doğru kurgulandığında arşiv, kendisine yöneltilen soruları dakikalar içinde yanıtlar. Replay doğru kurgulandığında ise veri girişinde verilen her filtreleme kararı geri alınabilir hâle gelir. Tiered storage'ı bir risk olmaktan çıkarıp bilinçli bir tasarım tercihine dönüştüren de bu iki mekanizmadır.

Bu konuda detaylı bilgi için storage tiering blogumuzu bu linkten  okuyabilirsiniz. 

Kron Telemetry Pipeline ile veriyi bir kez saklayın, yalnızca ihtiyaç duyduğunuzu geri çağırın.