Audit Log Nedir ve Yönetim Panelinde Nasıl Kullanılır?

audit log, yazılım sistemlerinde “kim, ne zaman, neyi, neden değiştirdi?” sorusunun cevabını veren değişmez (immutable) kayıtlar bütünüdür. Compliance (KVKK, GDPR, SOX, HIPAA), güvenlik olay yönetimi, hata ayıklama ve operasyonel görünürlük için vazgeçilmezdir. Bu rehber, audit log’un teknik tasarımından yönetim paneli entegrasyonuna kadar uçtan uca bir yol haritası sunar.

audit log nedir ve neden önemlidir?

audit log, basit bir “logs” tablosundan çok daha fazlasıdır. Audit log’un dört temel özelliği vardır: değişmezlik (immutable — bir kez yazılır, silinmez veya değiştirilmez), bütünlük (her kayıt önceki kayıtlara zincirlenir, hash’lenir), zaman damgası (güvenilir bir saat kaynağından alınır, UTC), bağlam (kullanıcı, IP, user-agent, işlem türü, etkilenen kayıt). Bu özellikler, audit log’u sıradan bir log dosyasından ayırır.

audit log hangi durumlarda kullanılır?

Kullanım senaryoları: (a) Kullanıcı yönetiminde kritik işlemler (şifre değişikliği, yetki güncelleme, hesap silme), (b) Finansal işlemler (sipariş oluşturma, iade, ödeme), (c) Veri gizliliği gerektiren alanlar (kişisel veri erişimi, KVKK talepleri), (d) Yönetim paneli aksiyonları (ayar değişikliği, içerik düzenleme), (e) API erişim kayıtları (özellikle OAuth ve admin endpoint’ler için).

audit log nasıl yapılır?

audit log için temel kavramlar

Audit log’un kalbinde dört kavram vardır: event (olay), actor (eylemi yapan), subject (etkilenen kayıt), context (ek bilgiler). Event; login, update, delete, export, view gibi tiplere ayrılır. Actor; kullanıcı id, rol, IP adresi, user-agent içerir. Subject; etkilenen entity tipi (User, Order) ve id’si. Context ise eski/yeni değer, değişen alanlar, neden (action reason) gibi ek bilgileri taşır.

audit log adım adım uygulama rehberi

Adım adım uygulama akışı:

1. Şema tasarımı: audit_logs tablosu: id, actor_id, actor_type, action, subject_type, subject_id, old_values (JSONB), new_values (JSONB), context (JSONB), ip, user_agent, created_at (UTC).
2. Değişmezlik kuralı: Database seviyesinde INSERT-only policy; uygulama seviyesinde güncelleme/silme yasak. BEFORE UPDATE ve BEFORE DELETE trigger’ları ile hard-block uygulanır.
3. Zincirleme bütünlük: Her kayıt bir önceki kaydın hash’ini içerir (blockchain benzeri). Bu, geçmişe yönelik tahrifatı tespit eder.
4. Service katmanı: AuditService::log($action, $subject, $oldValues, $newValues, $context) tek giriş noktası; tüm controller/service’ler bu metodu çağırır.
5. Event sourcing opsiyonu: Çok kritik sistemlerde audit log, event store olarak da kullanılabilir; her değişiklik bir event’tir, state event’lerden türetilir.
6. Asenkron yazım: Yanıt süresini etkilememek için queue’ya (Redis/RabbitMQ) atılır, background worker işler.

Örnek minimal audit kaydı:

{
  "id": 12345,
  "actor": {"id": 7, "type": "user", "email": "admin@example.com"},
  "action": "user.update",
  "subject": {"type": "user", "id": 42},
  "old_values": {"role": "editor"},
  "new_values": {"role": "admin"},
  "context": {"ip": "85.102.x.x", "user_agent": "Mozilla/5.0..."},
  "created_at": "2026-07-16T21:00:00Z"
}

audit log ayarları ve dikkat edilmesi gerekenler

audit log için gerekli araçlar ve ön hazırlık

Yaygın paketler: spatie/laravel-activitylog (Laravel için en popüler, otomatik model değişiklik takibi), owen-it/laravel-auditing (daha detaylı, çoklu modül desteği), Audit.NET (.NET için), django-auditlog (Django için), act_as_audit (Ruby on Rails için). Hepsinin ortak özelliği: model değişikliklerini otomatik yakalamak, panel üzerinden görüntülemek, filtrelemek. Ancak kritik sistemlerde elle yazılmış bir AuditService daha güvenilirdir çünkü paketlerin esnekliği sınırlıdır.

audit log yaparken sık yapılan hatalar

Yapılan hatalar: (1) Audit log’u silinebilir bir tabloda tutmak, (2) Eski/yeni değer yerine sadece mesaj saklamak (analiz zorlaşır), (3) Kullanıcı kimliği yerine username saklamak (username değişirse log kopar), (4) IP saklamamak (güvenlik analizi imkansızlaşır), (5) Log’u production’da senkron yazmak (her işlem yavaşlar), (6) Log’u arşivlememek (disk dolduğunda sistem durur). Bunların en kritik olanı birincisidir; audit log silinebiliyorsa, audit anlamını yitirir.

audit log performans, güvenlik ve SEO etkileri

Performans: asenkron yazım ile ana işlemden ayrılır, overhead 1-2 ms. Yüksek hacimli sistemlerde partitioning (ay bazlı) + arşivleme (1 yıldan eski log’lar cold storage’a) uygulanmalıdır. Güvenlik: log’a yazan hesap ile log’u okuyan hesap farklı olmalı; log DB’si ana DB’den ayrı tutulmalı; yedekleme 3-2-1 kuralına göre yapılmalı. Compliance: KVKK/GDPR için kişisel veri maskelenmeli veya anonimleştirilmeli; retention policy belirlenmeli (genelde 1-7 yıl arası, sektöre göre değişir).

audit log kontrol listesi ve sık sorulan sorular

audit log yayın öncesi son kontrol listesi

Yönetim paneli entegrasyonu kontrol listesi:

• Filtreleme: tarih aralığı, kullanıcı, aksiyon tipi, etkilenen kayıt
• Detay görünümü: eski vs yeni değer karşılaştırması (diff)
• İndirme: CSV/JSON export (filtreye göre)
• Görselleştirme: günlük aksiyon sayısı grafik
• Alarm: anormal aktivite tespiti (ör. gece 03:00’te toplu silme)
• Yetkilendirme: sadece “auditor” rolü okuyabilsin
• Arama: full-text search (kullanıcı adı, IP, aksiyon)

Sıkça Sorulan Sorular

Audit log ile uygulama log'u arasındaki fark nedir?
Uygulama log'u geliştirici içindir; hata ayıklama, performans, sistem olayları. Audit log ise yasal/operasyonel kanıttır; "kim neyi değiştirdi" sorusunu cevaplar. Uygulama log'u silinebilir, audit log değişmezdir. İkisi farklı sistemler olarak ele alınmalıdır.

Hangi aksiyonlar audit log'a yazılmalı?
Kritik aksiyonlar: kimlik doğrulama (login/logout/failed login), kullanıcı yönetimi (oluştur/sil/yetki değişikliği), veri değişikliği (oluştur/güncelle/sil), finansal işlemler, ayar değişiklikleri, kişisel veri erişimi, export işlemleri. Her aksiyon için "action" alanı farklı olmalıdır (user.create, order.update vb.).

Audit log ne kadar süre saklanmalı?
Sektöre ve yasal düzenlemeye bağlıdır. Finans sektöründe 5-10 yıl, sağlık sektöründe 7-30 yıl, e-ticarette genelde 2-5 yıl. KVKK gereği kişisel veri için "işleme amacı sona erene kadar" saklanabilir, ancak talep halinde anonimleştirme zorunludur. Policy net belgelenmelidir.

Log'a yazan kişi kendi aksiyonlarını görebilir mi?
Güvenlik açısından "hayır" önerilir. Audit log'u okuma yetkisi sadece "auditor" rolüne verilmeli; yazan kişi ise herhangi bir kullanıcı olabilir. Bu separation of duties prensibidir.

Audit log performansı düşürür mü?
Asenkron yazım ile ana işlemden ayrıldığında overhead 1-2 ms'dir. Senkron yazımda her işlem 10-30 ms yavaşlayabilir; bu kabul edilemez. Mutlaka queue (Redis, RabbitMQ, Beanstalkd) kullanın. Yüksek hacimli sistemlerde ayrı bir audit DB ve partitioning önerilir.

Audit log'u arşivleme stratejisi nedir?
Sıcak veri (0-3 ay) ana DB'de, sıcak arşiv (3-12 ay) compressed partitioned tablolarda, soğuk arşiv (1+ yıl) S3 Glacier veya Azure Blob Archive'de tutulur. Arşivden geri okuma nadir olduğu için retrieval time yüksek olabilir; bu trade-off kabul edilir. Arşivleme sırasında şifreleme (AES-256) zorunludur.

Audit log'a yazma işlemi için hangi teknolojiler kullanılır?
Yaygın seçenekler: (a) RDBMS (PostgreSQL, MySQL) + partitioning, (b) Time-series DB (InfluxDB, TimescaleDB, ClickHouse), (c) Document store (MongoDB capped collection), (d) Dedicated audit platform (Splunk, Elastic, AWS CloudTrail). Ölçek ve sorgu ihtiyacına göre seçim yapılır; örnek yüksek hacimli sistemlerde ClickHouse, standart SaaS'ta PostgreSQL yeterlidir.

Audit log'da kişisel veri nasıl korunur?
İki temel yaklaşım: (1) Kişisel veriyi log'a yazmamak (sadece hash'lenmiş ID), (2) Log'a yazmak ama encryption-at-rest + access control + anonymization. KVKK/GDPR için retention period belirlenmeli; talep halinde ilgili log kayıtları anonimleştirilmeli veya silinmelidir. Veri sınıflandırması (public/internal/confidential/restricted) ile log'a hangi verinin yazılabileceği kontrol altına alınır.

Gerçek Dünya Senaryoları

Bir bankacılık uygulaması düşünün: regülatör (BDDK) denetimi geldiğinde "bu hesaba kim ne zaman erişti?" sorusu soruluyor. Audit log olmadan cevap verilemiyor, ceza geliyor. Audit log ile 6 ay içindeki tüm erişim kayıtları saniyeler içinde sorgulanabiliyor. Düzenleyici denetimler audit log olmadan yapılamaz hale geldi.

Bir SaaS ürününde KVKK talebi geldi: "kullanıcım tüm verilerini sil" denildi. Audit log'da kullanıcının tüm aksiyonları (hangi kayıtlara erişti, hangi verileri gördü, hangi export'ları aldı) görüldü. Yasal yükümlülük eksiksiz yerine getirildi. Audit log olmadan hangi verilerin "kişisel" olduğu bile tespit edilemezdi.

Bir e-ticaret sitesinde şüpheli sipariş: aynı kullanıcı 5 dakikada 10 sipariş verdi, ödemeler farklı kartlardan. Audit log'da IP sıçraması, user-agent değişikliği, kart masked'i pattern'i görüldü. Fraud ekibi 1 saat içinde aksiyon aldı. Audit log olmadan bu correlation yapılamazdı.

Yaygın Tuzaklar ve Çözümleri

Tuzak 1: Audit log'u silinebilir tabloda tutmak. Veritabanı erişim izni olan herhangi biri TRUNCATE yapabilir. Çözüm: DB seviyesinde INSERT-only policy (PostgreSQL'de row-level security, MySQL'de trigger), uygulama seviyesinde ORM'in update/delete'ini override edin.

Tuzak 2: Eski/yeni değer yerine sadece mesaj saklamak. "User updated" yazmak analiz için yetersiz. Çözüm: JSONB ile eski/yeni değer saklayın, diff görüntüleme aracı ile müşteriye sunun.

Tuzak 3: Username saklamak, user id sakmamak. Username değişince log'daki kayıtlar kopuyor. Çözüm: user_id (immutable) + username_snapshot (görüntüleme için) ayrı ayrı saklayın.

Tuzak 4: Senkron yazım. Her işlem 20-30 ms yavaşlıyor, yüksek trafikte sistem durma noktasına geliyor. Çözüm: queue (Redis/RabbitMQ) ile asenkron yazım, batch insert (100ms'de bir 50 kayıt birikim).

Tuzak 5: Arşivleme yapmamak. 2 yılda 50 GB log, tablo şişiyor, sorgular yavaşlıyor. Çözüm: aylık partitioning (PostgreSQL'de native, MySQL'de manual), 1 yıldan eski kayıtları cold storage (S3 Glacier, Azure Archive) taşıyın.

Gelecek Trendleri

Trend 1: Immutable database. Yeni veritabanları (Amazon QLDB, Azure Immutable Blob Storage) doğal olarak append-only. Audit log için özel olarak tasarlanmış; zincirleme bütünlük ve cryptographic verification built-in.

Trend 2: AI tabanlı anomali tespiti. Audit log'a akan olaylar gerçek zamanlı analiz ediliyor; "Bu kullanıcı son 24 saatte 50 farklı IP'den giriş yaptı, şüpheli" gibi uyarılar üretiliyor. SIEM sistemleri (Splunk, Elastic SIEM, IBM QRadar) bu alanda öncü.

Trend 3: User activity monitoring + audit. Kullanıcı ekranındaki aksiyonlar (mouse hareketi, tuş vuruşu, ekran görüntüsü) ile audit log birleştiriliyor. Özellikle yüksek güvenlik gerektiren finans ve sağlık sektörlerinde yaygınlaşıyor.

Trend 4: Compliance-as-code. Audit log gereksinimleri kod olarak tanımlanıyor (örn. "her veri silme işlemi KVKK Article 17 ile uyumlu olmalı"); CI/CD pipeline'da otomatik doğrulanıyor. Hata tespiti release'den önce yapılıyor.

Loglama Türlerinin Karşılaştırması

Sonuç ve Öneriler

audit log, yazılım projelerinin olgunluk göstergelerinden biridir. Sadece compliance için değil, hata ayıklama, güvenlik analizi ve operasyonel görünürlük için de kritik öneme sahiptir. Başlangıç için en kritik 5 aksiyonu seçin (login, user create/update/delete, order create), bunlar için AuditService yazın, yönetim paneli üzerinden görüntüleyin. Zaman ihtiyaca göre genişletin. Önemli olan “her aksiyon yazılır” disiplinini sağlamak ve yazılan log’ların gerçekten geri alınamaz olduğunu garanti etmektir.

İlgili Makaleler

• Activity Log Sistemi Nedir, Nasıl Yapılır?
• WordPress Block Theme ile Site Tasarımı Nasıl Yapılır?
• Laravel Route Cache Nedir ve Nasıl Kullanılır?

Daha fazla bilgi için resmi kaynakları inceleyebilirsiniz: OWASP.