Bir log kaydının sonradan değiştirilmediğini nasıl anlarsınız?

‘Logları saklıyoruz’ hangi soruları cevapsız bırakır?

Bir olay incelemesinde yalnızca bir dosyanın bulunması yeterli olmayabilir. İnceleyen kişi, dosyanın kaynaktan geldiğini, içeriğinin değişmediğini, aradan kayıt silinmediğini ve gösterilen zaman aralığının gerçekten kapsandığını ayrı ayrı bilmek ister. Bunlar aynı özellik değildir. Dosya erişimini sınırlamak değişiklik riskini azaltır; geçmişteki bir yöneticinin hangi işlemi yaptığını kriptografik olarak göstermez. Güvenilir bir tasarım, korunmak istenen iddiayı önce açıklar ve her iddia için kanıtın nerede üretildiğini belirler.

Örnek tehdit modelimiz, sonradan arşiv dosyasını değiştirebilen bir aktörün önceden dışarıda saklanan kontrol noktasını değiştiremediğini varsayar. Kaynak cihaz ele geçirilmişse yanlış olay üretebilir; imza bu olayın gerçekte yaşandığını ispatlamaz. İmza anahtarı da ele geçirilirse başka bir risk sınıfı doğar. Bu sınırlar açık yazılmadığında ‘değiştirilemez log’ ifadesi, hiçbir teknik mekanizmanın tek başına karşılamadığı geniş bir vaade dönüşür. Burada anlatılanlar Batur'un iç mimarisinin açıklaması değildir.

İmzadan önce kayıt biçimi ve zaman nasıl düzenlenir?

Her olay için kaynak kimliği, sıra veya olay kimliği, kaynak zamanı, kabul zamanı, şema sürümü ve ham yükün ilişkisi korunmalıdır. Ayrıştırılmış alanlar aramayı kolaylaştırır, fakat özgün kayıtla bağları kopmamalıdır. Bir adaptörün boş alanı silmesi veya sayısal değeri metne çevirmesi imzalanacak baytları değiştirir. Bu yüzden hangi temsilin imzalandığı, hangi dönüştürmelerin yapıldığı ve aramada gösterilen kaydın hangi özgün baytlardan üretildiği belgelenmelidir. Kaynakta bulunmayan alanlar türetilmiş olarak işaretlenebilir.

JSON nesnelerinde alan sırası, boşluk ve sayı gösterimi farklı olabilir; aynı anlama gelen iki belge farklı bayt dizileridir. RFC 8785, JSON için kanonikleştirme yaklaşımı tanımlar. Ancak aşağıdaki küçük örnek bu standardı uyguladığını iddia etmez: yalnızca sabit konumlu metin dizileri kullanır ve aynı JavaScript kodlamasıyla doğrulanır. Üretimde farklı diller ve sürümler arasında birlikte çalışabilirlik gerekiyorsa kanonik temsil için test vektörleri hazırlanmalıdır. Kaynak ve gözlem zamanı ayrımı için OpenTelemetry veri modeli ayrıca başvuru sağlar.

Bölüm kaynakları: RFC 8785 — JSON Canonicalization Scheme ↗OpenTelemetry — Logs Data Model ↗

Hash zinciri hangi değişiklikleri görünür kılar?

Bağımsız dosya özeti yalnızca karşılaştırılacağı güvenilir bir özet varsa yararlıdır. Zincirde ise her adım önceki adımın özetini de içerir. Örnek yapımızda H_i = SHA-256(alan ayracı || sıra || H_önceki || yük uzunluğu || yük) kullanılır. Sıra ve uzunluk sabit genişlikli olarak kodlanır, böylece alanların nerede başlayıp bittiği belirsiz kalmaz. Başlangıç özeti ve kodlama sürümü de sabittir. Bir olay değiştiğinde kendisinden sonraki zincir sonucu değişir; doğrulama bunu güvenilir son özetle karşılaştırır.

Zincirin tamamını yeniden hesaplayabilen biri, aynı klasördeki son özeti de değiştirebiliyorsa yalnızca hash kullanılması tahrifatı engellemez. Ayrıca ilk iki kayıt korunup son kayıtlar silindiğinde kısa zincir kendi içinde tutarlı olabilir. Bu nedenle dış kontrol noktası yalnızca kök özeti değil, beklenen kayıt sayısını ve dönem kimliğini de taşımalıdır. Bir dönemin hiç başlamadığını göstermek için de dönem envanteri gerekir. Kriptografik bütünlük, kaynağın üretmesi gerekirken hiç üretmediği kaydı kendiliğinden keşfetmez.

Değiştirme, silme ve yeniden sıralama nasıl denenir?

Aşağıdaki Node.js örneği ek paket gerektirmez. Üç olay için kök özeti hesaplar, güvenilir kabul edilen bir kontrol noktası oluşturur ve değiştirilmiş yük, kısaltılmış liste, yeniden sıralanmış liste için doğrulamanın başarısız olduğunu kontrol eder. Kontrol noktasının aynı süreçte oluşturulması yalnızca gösterim kolaylığıdır; gerçek koruma için bu değerin saldırganın değiştiremeyeceği bağımsız bir kanaldan gelmesi gerekir. Kod dijital imza, anahtar saklama veya standart uyumlu syslog uygulaması içermez.

Örneği genişletirken boş dönem, çok uzun kayıt, geçersiz kodlama, tekrar olay kimliği ve eksik kontrol noktası ekleyin. Başarısızlık türlerinin aynı ‘hash yanlış’ mesajına sıkışmaması incelemeyi kolaylaştırır. Boyut veya kayıt sayısı bekleneni aşıyorsa sınırsız bellek ayırmadan doğrulama durmalıdır. Büyük arşivlerde akış üzerinden hesaplama yapılabilir; fakat hangi dosya sınırlarının hangi imzalı döneme karşılık geldiği korunmalıdır. Doğrulayıcıyı arşivi üreten yazılımdan bağımsız çalıştırabilmek de faydalı bir kabul koşuludur.

const { createHash } = require('node:crypto');
const assert = require('node:assert/strict');
const u64 = (n) => {
  const b = Buffer.alloc(8);
  b.writeBigUInt64BE(BigInt(n));
  return b;
};
function root(events) {
  let previous = Buffer.alloc(32);
  for (const [i, event] of events.entries()) {
    const payload = Buffer.from(JSON.stringify(event), 'utf8');
    previous = createHash('sha256')
      .update('editorial-chain-v1\0')
      .update(u64(i)).update(previous)
      .update(u64(payload.length)).update(payload).digest();
  }
  return previous.toString('hex');
}
const events = [
  ['2026-10-19T10:00:00Z', 'login', 'operator-1'],
  ['2026-10-19T10:01:00Z', 'read', 'record-7'],
  ['2026-10-19T10:02:00Z', 'logout', 'operator-1']
];
// Treat this checkpoint as independently trusted input.
const checkpoint = { count: events.length, root: root(events) };
const verify = (rows, c) => rows.length === c.count && root(rows) === c.root;
assert(verify(events, checkpoint));
const changed = structuredClone(events);
changed[1][2] = 'record-9';
assert(!verify(changed, checkpoint));
assert(!verify(events.slice(0, 2), checkpoint));
assert(!verify([events[1], events[0], events[2]], checkpoint));
console.log('Original accepted; edit, truncation and reorder rejected.');

Dijital imza ve bağımsız kontrol noktası ne ekler?

İmzalı kontrol noktası; dönem kimliği, başlangıç ve bitiş sınırları, kayıt sayısı, kök özet, şema sürümü ve anahtar kimliğini birlikte bağlayabilir. Doğrulayan tarafın doğru açık anahtarı hangi güvenilir kayıt üzerinden aldığı açıklanmalıdır. RFC 8032, EdDSA imza algoritmalarının teknik tanımını verir; bu referans Batur'da belirli bir algoritma kullanıldığı iddiası değildir. İmzalanacak temsil değişirse doğrulama başarısız olabilir. Anahtar değişimini arşiv dönemiyle ilişkilendirmek, eski imzaların hangi anahtarla kontrol edileceğini belirler.

RFC 5848, imzalı syslog mesajları için ayrı bir standart yaklaşımıdır; buradaki basitleştirilmiş zincir onun yerine geçmez. Tasarım seçilirken mevcut cihaz desteği, kolektör mimarisi ve doğrulayıcı ihtiyacı değerlendirilmelidir. İmzalı kontrol noktasının farklı yönetim alanında saklanması, arşiv yöneticisinin geçmişi sessizce yeniden yazmasını zorlaştırabilir. Buna rağmen anahtar ele geçirilmesi, yanlış kaynak verisi ve bir dönemin hiç gönderilmemesi ayrı risklerdir. Zamanın güvenilirliği de yalnızca kayıt içindeki tarih metnine dayanılarak kabul edilmez.

Bölüm kaynakları: RFC 5848 — Signed Syslog Messages ↗RFC 8032 — EdDSA ↗

Bütünlük, eksiksizlik ve saat doğruluğu nasıl ayrılır?

Bütünlük, eldeki verinin beklenen temsil ile eşleşmesini sorgular. Eksiksizlik, beklenen olayların veya dönemlerin elinizde olup olmadığını sorgular. Saat doğruluğu ise kaydın anlattığı zamanın güvenilirliğidir. Kolektör bağlantısı kesildiğinde kaynak sıra numarası, kalp atışı ve dönem envanteri eksik aralığı görünür kılabilir. Fakat her kaynak bütün bu alanları sağlamaz. Eksik alanları varsayarak doldurmak yerine kaynağa özgü güven seviyesi belirtilmeli ve raporun neleri doğrulayamadığı açıklanmalıdır.

Aşağıdaki matrisi kabul incelemesinde kullanabilirsiniz. Örneğin bütün hash'ler doğruyken son saatlik dosya eksik olabilir; bu durumda bütünlük doğrulaması geçmiş olan kısım için geçerlidir, kapsam ise eksiktir. Benzer biçimde saat yanlışken sıralı zincir doğru olabilir. İnceleme ekranı bu durumları ayrı göstermelidir. Olay kaydı görüntülenirken hesaplanan durum ile özgün kaynak alanlarını ayırmak, operatörün sistemin çıkarsamasını kaynak tarafından söylenmiş bir gerçek sanmasını önler.

Günlük saklama kapasitesi nasıl hesaplanır?

Varsayımsal olarak saniyede 5.000 olay ve olay başına ortalama 700 bayt özgün yük alalım. Ham akış 3.500.000 bayt/s, günlük hacim 302,4 GB olur. Otuz gün için 9,072 TB gerekir; iki kopya için yalnızca ham yük 18,144 TB'dir. Bunlar ondalık birimlerdir. İndeksler, ayrıştırılmış alanlar, kontrol noktaları, yedekler ve boş çalışma alanı bu toplamda yoktur. Sıkıştırma ölçülmeden düşülmez; farklı kaynakların ortalama boyutu ve tepe hızı ayrıca örneklenmelidir.

Saklama süresinin sonunda hangi kopyanın ne zaman silineceği ve kontrol noktalarının ne kadar korunacağı planlanmalıdır. Arşiv silinmişken kök özetin kalması, içerik olmadan olayları yeniden oluşturmaz. Bir yedeğin varlığı da geri yükleme ve doğrulama deneyi yapılmadıkça yeterli değildir. Temsili bir dönemi geri yükleyip imza anahtarı geçmişiyle birlikte doğrulayın. Depolama maliyetini azaltmak için kaynak filtrelenecekse dışlanan olay sınıfları ve kapsam değişikliği rapora açıkça yansıtılmalıdır.

Bir log bütünlüğü çözümünü nasıl sınarsınız?

Kabul kümesi özgün kayıtları, beklenen dönem listesini ve bağımsız kontrol noktalarını içermelidir. Tek bayt değiştirme, orta kayıt silme, dosya sonunu kesme, iki kaydı yer değiştirme ve eski dönemi yeni adla sunma ayrı denenir. Her değişiklik için beklenen sonuç yazılmalıdır. Ayrıca imza doğru ama dönem kapsamı eksik gibi birleşik durumlar hazırlanır. Böylece doğrulayıcı yalnızca beklenen dosyada beklenen özeti bulmayı değil, yanlış dosyanın doğruymuş gibi sunulmasını da sınar.

Anahtar değişimi, kayıp açık anahtar kaydı, bozuk imza ve farklı şema sürümü için sonuçlar da raporlanmalıdır. Bilinmeyen anahtarı ‘imzasız ama geçerli’ saymak yerine doğrulanamadı durumu üretmek gerekir. Testleri üretim arşivinin kopyaları üzerinde ve yetkili bir ortamda gerçekleştirin; gerçek kayıtları bozarak deneme yapmayın. Kabul raporu, bütünlük ve kapsam sonuçlarını ayrı tutmalı, her bulguyu ilgili dosya kimliğiyle eşleştirmeli ve sonucun hangi doğrulayıcı sürümüyle üretildiğini belirtmelidir.

• Tahrifat, eksik kapsam ve bilinmeyen anahtar ayrı hata durumlarıdır.
• Kontrol noktaları arşivden bağımsız güven ilişkisiyle alınır.
• Geri yüklenen arşiv bağımsız doğrulayıcıyla tekrar kontrol edilir.

Batur ile teknik görüşmede ne istenmeli?

Batur kamuya açık olarak günlük toplama, imzalama ve adaptör tabanlı analiz alanında, seçili müşterilere yönelik pilot ürün olarak konumlanır. Buradaki hash zinciri ve kontrol noktası örneği ürünün algoritma seçimini açıklamaz. Görüşmede desteklenen kaynaklar, ham kayıt koruma yöntemi, imzanın tam olarak hangi alanı kapsadığı ve bağımsız doğrulama yolu sorulmalıdır. Kanıtlanmamış sertifikasyon, hukuki geçerlilik veya bütün mevzuata otomatik uyum iddiası yerine gösterilebilir teknik çıktılar üzerinden ilerlenmelidir.

Örnek bir inceleme paketi; kaynak örneği, arşiv örneği, dönem manifesti, doğrulama çıktısı ve hata senaryolarını birlikte içerebilir. Veri ve gözlemlenebilirlik yetenekleri ise akışın sağlığını, gecikmeyi ve eksik aralıkları izlemek için ilgili çalışma alanıdır. Başarılı tasarım yalnızca ‘dosya değişmedi’ cevabını üretmez; hangi dosya, hangi zaman aralığı, hangi anahtar ve hangi kapsam için bu sonuca varıldığını da anlaşılır biçimde gösterir. Böyle bir paket ürün değerlendirmesini pazarlama terimlerinden ölçülebilir kabul adımlarına taşır.