Denetim günlüğü

Kısaca: Güvenlik ve yönetimle ilgili eylemlerin (kim, ne zaman, kime ne yaptı) sürekli bir kaydı — örneğin rol atamaları ya da diğer yönetici müdahaleleri için sonradan izlenebilirliğe hizmet eder.

Biraz daha ayrıntılı: Bir denetim günlüğü bilinçli olarak hataya dayanıklı yazılmalıdır — bir günlükleme hatası asıl eylemin kendisini asla engellememeli veya çökertmemelidir. Tipik yapı: kim eylemde bulundu (aktör), ne yapıldı (eylem), hangi nesne üzerinde (hedef), artı isteğe bağlı yapılandırılmış ayrıntılar.

Bizim bağlamımız: Emzett’te app/utils/auditLog.ts, yönetici panelinde “Denetim günlüğü” altında görünür (ona erişim denetimi için bkz. Dinamik rol sistemi (ayrıntılı RBAC)). Yazmalar try/catch ile korunur, böylece günlüklerken bir veritabanı hatası örneğin bir rol atamasını engellemez.

Ayrıntılı

Bir denetim günlüğü, normal uygulama günlüklemesinden (bir noktada döndürülen/silinen hata/debug çıktısı) amaç ve gereksinimler bakımından ayrılır: eksiksiz, kalıcı ve kurcalamaya karşı korumalı olmalıdır, çünkü şüphe hâlinde kanıt olarak hizmet eder — kim hangi yetkiyi ne zaman değiştirdi, kimin hangi verilere eriştiği. Bu yüzden bir denetim günlüğü genellikle kendi, çoğunlukla yalnızca ekleme yapılan tablosunda sonlanır (kayıtlar asla değiştirilmez ya da silinmez, yalnızca eklenir), çoğu zaman veritabanının geri kalanından daha sıkı erişim haklarıyla — ideal olarak bir yönetici bile tekil kayıtları, bu da günlüklenmeden sonradan silemez.

Bir kaydın yapısı

Tipik bir denetim günlüğü kaydı aktör-eylem-hedef şemasını izler:

• Aktör — kim eylemde bulundu (kullanıcı kimliği, ancak cron işi gibi sistem süreçleri de aktör sayılır)
• Eylem — ne yapıldı, genellikle açıklayıcı bir dize olarak (role.grant, user.delete, settings.update)
• Hedef — hangi nesne üzerinde (etkilenen kaydın kimliği)
• Ayrıntılar — isteğe bağlı yapılandırılmış ek bilgi (örneğin bir değişiklik için eski ve yeni değer)
• Zaman damgası ve çoğu zaman aktörün IP adresi ya da oturum kimliği, böylece olaylar sonradan belirli bir oturuma atfedilebilir

Güvenlik açısından kritik değişikliklerde (örneğin yetki değişiklikleri) yalnızca yenisini değil, hem eski hem yeni değeri ({ from: "user", to: "admin" }) saklamaya değer — aksi hâlde sonradan önceki durumun ne olduğu yeniden kurulamaz.

Temel ilke olarak hata toleransı

“Hataya dayanıklı yaz” ilkesi belirleyicidir: bir denetim günlüğü kaydı asıl eylemin kendisi değil, onun bir yan etkisidir. Bir günlükleme hatası ana eylemi engellerse, bozuk bir günlükleme sistemi kazara tüm uygulamayı felç edebilirdi — “kontrol, kontrol edilen şeyden daha önemli olmamalı”nın klasik bir örneği. Aynı zamanda başarısız bir denetim günlüğü kaydı sessizce yok olmamalıdır — en azından hatayı normal hata günlüklemesine (örneğin Sentry) yazmak yaygındır, böylece denetim günlüğündeki boşluklar ana eylemi engellemese bile fark edilir.

async function grantRole(userId: string, role: string) {
  await db.update(users).set({ role }).where(eq(users.id, userId))
  try {
    await logAudit({ actor: currentUser.id, action: "role.grant", target: userId, details: { role } })
  } catch (err) {
    console.error("Audit log failed:", err) // rol ataması yine de gerçekleşti
  }
}

İlgili kavramlardan farkı

Bir denetim günlüğü sıklıkla bir olay günlüğü veya etkinlik akışıyla karıştırılır, ancak farklı bir amaca hizmet eder: bir etkinlik akışı (örneğin “X, Y’yi yorumladı”) kullanıcılar içindir ve eksik ya da kısaltılmış olabilir; bir denetim günlüğü izlenebilirlik/uyumluluk içindir ve eksiksiz olmalıdır. Bir veritabanı değişiklik günlüğü (örneğin Postgres’in pg_audit uzantısı ya da tetikleyici temelli geçmiş tabloları aracılığıyla) uygulama mantığından bağımsız olarak veritabanı düzeyinde HER değişikliği otomatik kaydeder — bu daha kapsamlıdır ama çok daha gürültülüdür, çünkü “bu bir rol atamasıydı” gibi anlamsal bir sınıflandırma sunmaz, yalnızca ham satır değişiklikleri.

Hukuken bir denetim günlüğü GDPR bağlamında da önemlidir: kişisel verilere kimin eriştiğini belgeler; bu, bir erişim talebinde ya da bir veri ihlalinde (m. 33 GDPR, 72 saat içinde bildirim yükümlülüğü) bir olayın kapsamını daraltabilmek için belirleyici olabilir.

Ayrıca bak: Dinamik rol sistemi (ayrıntılı RBAC), Protokol, GDPR