Audit Log Tasarımı: Kim, Neyi, Neden Değiştirdi?

Teknik hata günlüğünden farklı bir amaç belirleyin

Uygulama günlükleri performans ve hata araştırmak için kullanılabilir. Audit log ise kimlik, eylem, hedef kayıt ve sonuç arasındaki ilişkiyi korur. Bu iki amacı aynı serbest metin dosyasında çözmeye çalışmak, arama ve erişim yönetimini zorlaştırabilir.

Önce hangi iş olaylarının izlenmesi gerektiğini belirleyin: yetki verme, fiyat değiştirme, toplu dışa aktarma, sipariş iptali veya belge onayı. Her tıklamayı kaydetmek zorunlu değildir. Kritik kararlar için yeterli bağlamı tutarken gereksiz kişisel veri toplamamaya dikkat edin.

İşlemi bir kimlikle uçtan uca bağlayın

Kullanıcı, arayüz, API ve arka plan işi aynı değişikliğin farklı adımlarını yürütebilir. Kararlı işlem referansı, bu parçaları ilişkilendirmeye yardımcı olur. “Sistem yaptı” ifadesi tek başına yeterli olmayabilir; işi hangi kullanıcı veya kuralın başlattığı da bilinebilmelidir.

Kayıt zamanı ile işlemin gerçekleştiği zaman farklı olabilir. Kaynak ve kayıt zamanını ayırmak, geciken olayları araştırmayı kolaylaştırır. Bütün saatlerin aynı hassasiyet ve zaman dilimiyle yönetildiğini varsaymayın; teknik tasarımda bu tercihleri belgeleyin.

Örnek: fiyat değişikliği müşteri itirazına dönüşüyor

Varsayımsal destek ekibi, teklif fiyatının neden değiştiğini araştırıyor. Yalnızca son değeri görmek yeterli değildir. Hangi kullanıcı, hangi sürümde, hangi gerekçeyle ve hangi onaya dayanarak değiştirdi? Değişiklik bir toplu içe aktarmadan geldiyse kaynak iş kimliği de izlenmelidir.

Parola, oturum anahtarı ve gereksiz hassas içeriği eski-yeni değer kaydına koymayın. OWASP günlük rehberi hangi bilgilerin dışarıda tutulacağı ve kayıtların korunması için önemli uyarılar içerir. [1]

Denetim kaydının işlemle tutarlılığını düşünün

İş değişikliği başarılı olup denetim kaydı kaybolursa araştırma izi eksik kalır. Denetim kaydı yazılıp işlem başarısız olursa da yanlış başarı izlenimi oluşabilir. Aynı veri tabanı içindeki değişikliklerde işlem sınırları; dağıtık akışlarda ise kalıcı olay ve sonuç modeli değerlendirilmelidir. Veri tabanının izolasyon davranışı bu tasarımın parçasıdır. [2]

Her kayda sonuç durumu eklemek yardımcı olabilir: istendi, uygulandı, reddedildi veya başarısız. Ancak bu durumlar gerçek akıştan üretilmeli, tek bir başarı mesajıyla varsayılmamalıdır. Tekrar deneme yeni bir denetim olayı oluşturuyorsa orijinal işle ilişkisi korunmalıdır.

Kayıtları herkesin düzenleyebildiği tabloya bırakmayın

Audit log erişimi ayrı yetki gerektirebilir. Bir kullanıcının müşteri kaydını değiştirebilmesi, değişiklik geçmişini silme hakkı vermemelidir. Saklama, arşivleme ve bütünlük kontrolleri risk düzeyine göre belirlenmelidir. “Değiştirilemez” iddiası kullanılacaksa teknik kapsamı ve sınırları açıkça açıklanmalıdır.

Bu rehber belirli bir saklama süresi veya mevzuata uygunluk garantisi vermez. İhtiyaçlar sektör ve veri türüne göre değişebilir. Hukuki gereksinimler ile operasyonel araştırma ihtiyaçları birlikte değerlendirilmelidir.

Arama ekranını olay çözümüne göre tasarlayın

Destek ekibi kullanıcı, müşteri, zaman aralığı ve işlem kimliğiyle filtreleyebilsin. Toplu işlemler alt kayıtlarla ilişkilendirilsin. Bir değişikliğin etkilediği siparişler veya yetkiler, gerekli erişim sınırları içinde izlenebilir olsun.

Kabul testinde reddedilen işlem, geri alınan değişiklik, arka plan işi, toplu güncelleme ve yetkisiz log erişimi senaryolarını çalıştırın. Yalnızca log dosyasının büyümesi başarı değildir; gerçek bir soru doğru kayıtlarla cevaplanabilmelidir.

Sık sorulan sorular

### Her alanın eski değerini saklamalı mıyım? Hayır. Gerekli bağlam ile veri minimizasyonu arasında denge kurulmalıdır. Hassas alanlar için maskeleme, özet veya olay kaydı daha uygun olabilir.

Audit log yedekleme yerine geçer mi?

Hayır. Denetim izi değişiklikleri araştırmayı, yedekleme ise uygun koşullarda veriyi geri getirmeyi amaçlar. İki ihtiyacın tasarımı ve testleri farklıdır.