Sql & Veritabanı İle Uygulamalar İçin Veri Erişim Loglaması Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Veri erişim loglaması yapabilmek için öncelikle kararlı bir veritabanı yönetim sistemine (RDBMS) ve uygun bir uygulama çatısına ihtiyacınız vardır. 2026 yılı itibarıyla PostgreSQL veya MySQL 9.x sürümleri, gelişmiş loglama özellikleri ve performanslı JSONB/JSON veri tipleri ile bu iş için idealdir.

• Veritabanı: PostgreSQL 17+ veya MySQL 9.0+
• Uygulama Katmanı: Modern bir backend çatısı (Laravel, .NET 9, veya Node.js/Prisma)
• Log Depolama: Logların veritabanını şişirmemesi için ayrı bir tablo yapısı veya merkezi bir log yönetim sistemi (ELK Stack gibi)

Adım 1: Veritabanı Seviyesinde Denetim (Audit) Tablosu Tasarımı

Veri erişim loglaması için en temel yöntem, her tablonun yanına bir "audit" veya "log" tablosu eklemektir. Bu tablo, değişikliğin yapıldığı satırı, işlemi gerçekleştiren kullanıcıyı ve eski/yeni değerleri tutmalıdır.

CREATE TABLE audit_logs (
    id BIGSERIAL PRIMARY KEY,
    table_name VARCHAR(100) NOT NULL,
    record_id INT NOT NULL,
    action_type VARCHAR(10) NOT NULL, -- INSERT, UPDATE, DELETE
    changed_by INT NOT NULL,
    old_data JSONB,
    new_data JSONB,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

Yukarıdaki SQL kodu, tüm veritabanı işlemlerini izlemek için merkezi bir yapı oluşturur. JSONB veri tipi, esnek bir şema yapısı sunarak farklı tablolardaki verilerin tek bir sütunda saklanmasına olanak tanır.

Adım 2: Veritabanı Tetikleyicileri (Triggers) ile Otomatik Loglama

Manuel loglama yerine veritabanı tetikleyicilerini kullanmak, uygulama kodundan bağımsız olarak tüm veri değişimlerini yakalamanızı sağlar. Bu yöntem, doğrudan SQL konsolu üzerinden yapılan müdahaleleri bile kayıt altına alır.

CREATE OR REPLACE FUNCTION log_user_changes()
RETURNS TRIGGER AS $$
BEGIN
    IF (TG_OP = 'UPDATE') THEN
        INSERT INTO audit_logs (table_name, record_id, action_type, changed_by, old_data, new_data)
        VALUES ('users', OLD.id, 'UPDATE', current_setting('app.current_user_id')::INT, to_jsonb(OLD), to_jsonb(NEW));
        RETURN NEW;
    END IF;
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_users_audit
AFTER UPDATE ON users
FOR EACH ROW EXECUTE FUNCTION log_user_changes();

Bu tetikleyici, users tablosunda bir güncelleme olduğunda otomatik olarak audit_logs tablosuna veri yazar. current_setting kullanımı, uygulama katmanından gelen kullanıcı bilgisini veritabanı oturumuna bağlamak için kullanılır.

Adım 3: Uygulama Katmanında (ORM) Veri Erişim Loglaması

Tetikleyiciler veri değişimlerini yakalamak için harikadır, ancak "SELECT" (okuma) işlemlerini loglamak için uygulama katmanındaki ORM (Object-Relational Mapping) araçlarını kullanmak daha performanslıdır. Aşağıdaki örnek, modern bir çatıda (örneğin Laravel veya benzeri) bir model gözlemcisi (Observer) mantığını gösterir.

// Örnek bir Model Observer yapısı
public function retrieved($model) {
    Log::info('Veri okundu', [
        'table' => $model->getTable(),
        'id' => $model->id,
        'user_id' => Auth::id(),
        'timestamp' => now()
    ]);
}

Bu yaklaşım, veritabanı üzerindeki yükü azaltır ve uygulama mantığına daha yakın loglar üretir. Ancak, çok yüksek trafikli sistemlerde tüm SELECT işlemlerini loglamak veritabanı performansını düşürebilir; bu yüzden sadece kritik tablolarda kullanılmalıdır.

Kritik Güvenlik Uyarısı: Loglama yaparken asla kullanıcı şifrelerini, kredi kartı bilgilerini veya kişisel verileri (KVKK/GDPR kapsamında) log tablolarına açık metin (plain-text) olarak yazmayın. Veri maskeleme (data masking) tekniklerini mutlaka uygulayın.

Adım 4: Performans ve Depolama Stratejileri

Log tabloları zamanla milyonlarca satıra ulaşabilir. Bu durum veritabanı sorgularını yavaşlatır. Bölümleme (Partitioning) stratejisi kullanarak logları aylık veya yıllık tablolara ayırmalısınız.

-- PostgreSQL'de tablo bölümleme örneği
CREATE TABLE audit_logs_2026_01 PARTITION OF audit_logs
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

Bu yöntem, eski logları silmeyi veya arşivlemeyi kolaylaştırır. Performansı artırmak için log tablosunda created_at sütununa mutlaka bir indeks (index) eklemelisiniz.

Veri Erişim Loglama Yöntemlerinin Karşılaştırılması

Adım 5: Logların İzlenmesi ve Debug İpuçları

Loglamak kadar, bu logları okumak da önemlidir. Hatalı bir işlemde "Kim, ne zaman, hangi veriyi değiştirdi?" sorusuna hızlı yanıt verebilmek için basit bir arama arayüzü veya SQL sorgusu hazırlayın.

SELECT * FROM audit_logs 
WHERE table_name = 'users' 
AND record_id = 123 
ORDER BY created_at DESC;

Debug yaparken logların eksik gelmesi durumunda, veritabanı kullanıcısının audit_logs tablosuna yazma yetkisinin olup olmadığını GRANT komutları ile kontrol edin.

Sorumluluk Reddi: Bu rehberde sunulan kod örnekleri eğitim amaçlıdır. Üretim ortamında (production) kullanmadan önce mutlaka yük testi yapın ve veritabanı yedeklerinizi aldığınızdan emin olun. Veri güvenliği sorumluluğu yazılımcıya aittir.

Sıkça Sorulan Sorular

Loglama yapmak veritabanımı yavaşlatır mı?

Evet, özellikle çok yüksek yazma işlemi olan sistemlerde her işlem için bir log kaydı oluşturmak ek yük getirir. Bu yüzden asenkron loglama yöntemlerini veya sadece kritik tabloları loglamayı tercih etmelisiniz.

SELECT işlemlerini loglamak mantıklı mı?

Sadece hassas veriler (finansal veriler, kişisel bilgiler) için mantıklıdır. Genel bir uygulama için tüm SELECT işlemlerini loglamak devasa bir veri yığını oluşturur ve sistem performansını ciddi oranda düşürür.

Loglarımı nerede saklamalıyım?

Küçük ölçekli uygulamalarda aynı veritabanında, ancak büyük ölçekli uygulamalarda ELK (Elasticsearch, Logstash, Kibana) veya Graylog gibi merkezi bir log yönetim sisteminde saklanması önerilir.

Veri maskeleme nedir ve nasıl yapılır?

Veri maskeleme, loglara yazılacak hassas verilerin (örneğin e-posta adresi veya telefon numarası) bir kısmının gizlenmesidir (örn: e****@email.com). Bu, KVKK uyumluluğu için zorunludur.

Hangi veritabanı işlemleri mutlaka loglanmalıdır?

INSERT, UPDATE ve DELETE işlemleri mutlaka loglanmalıdır. Özellikle yetki değişiklikleri, şifre güncellemeleri ve finansal kayıtlar loglamanın öncelikli olduğu alanlardır.

Log Verilerinin Analizi ve Anomali Tespiti İçin İleri Teknikler

Loglama altyapısını kurduktan sonra, toplanan verilerin yığınlar halinde birikmesi kaçınılmazdır. Bu verilerin anlamlı birer güvenlik aracına dönüşmesi için "Anomali Tespiti" (Anomaly Detection) yöntemlerini uygulamak gerekir. Özellikle, normal bir kullanıcı davranışının dışına çıkan (örneğin gece 03:00'te toplu veri çekme veya kısa sürede çok sayıda hatalı güncelleme denemesi) işlemleri tespit etmek için basit SQL sorguları yerine istatistiksel analizler kullanılmalıdır.

Aşağıdaki SQL sorgusu, son 24 saat içerisinde normalin üzerinde işlem yapan kullanıcıları tespit etmek için kullanılabilir:

SELECT user_id, COUNT(*) as transaction_count
FROM audit_logs
WHERE created_at > NOW() - INTERVAL '24 hours'
GROUP BY user_id
HAVING COUNT(*) > 100
ORDER BY transaction_count DESC;

Bu tür sorguları bir zamanlanmış görev (cron job) ile çalıştırarak, eşik değerini aşan kullanıcılar için sistem yöneticisine otomatik e-posta veya Slack bildirimi gönderen bir uyarı mekanizması kurgulayabilirsiniz.

Loglama Stratejilerinde "Cold Storage" ve Veri Arşivleme

Veritabanı üzerinde tutulan loglar, zamanla tablonun boyutunu büyüterek indeks performansını düşürür. Bu nedenle, "Sıcak" (Hot) ve "Soğuk" (Cold) veri depolama stratejisi izlenmelidir. Aktif olarak kullanılan loglar veritabanında tutulurken, 3 aydan eski veriler daha düşük maliyetli depolama birimlerine (S3, Azure Blob Storage veya CSV/Parquet dosyaları) aktarılmalıdır.

Veritabanı üzerinde arşivleme yaparken aşağıdaki prosedürü izlemek performans kaybını minimize eder:

1. Veri Taşıma: Belirli bir tarihten eski verileri INSERT INTO archive_logs SELECT * FROM audit_logs WHERE created_at < '2023-01-01' komutu ile taşıyın.
2. Veri Silme: Taşıma işlemi doğrulandıktan sonra ana tablodan DELETE işlemini gerçekleştirin.
3. Tablo Bakımı: Silme işleminden sonra veritabanı parçalanmasını (fragmentation) gidermek için VACUUM veya REINDEX komutlarını çalıştırın.

Bu strateji, veritabanınızın her zaman yüksek performansla çalışmasını sağlarken, yasal uyumluluk (KVKK/GDPR) gereği tutmanız gereken logların da güvenli bir şekilde saklanmasına olanak tanır.

Log Bütünlüğünü Koruma: Değiştirilemez (Immutable) Loglama

Güvenlik ihlallerinde saldırganların ilk hedefi genellikle log kayıtlarını silmek veya değiştirmektir. Log verilerinizin değiştirilemezliğini sağlamak için veritabanı seviyesinde "Append-Only" (Sadece Ekleme) yetkilendirmesi uygulayın. Uygulama kullanıcısının log tablosuna UPDATE veya DELETE yetkisi vermeyin.

İpucu: Eğer kritik finansal verilerle çalışıyorsanız, log kayıtlarını veritabanına yazdıktan sonra bir "hash" değerini (SHA-256) alıp harici bir log sunucusuna veya blok zinciri tabanlı bir kayıt sistemine göndermek, verinin sonradan değiştirilmediğini kanıtlamanızı sağlar.

Sonuç

Sql & veritabanı ile uygulamalar için veri erişim loglaması, sadece bir "kayıt tutma" işlemi değil, aynı zamanda sisteminizin güvenliğini ve izlenebilirliğini sağlayan stratejik bir yatırımdır. Bu rehberde öğrendiğiniz tetikleyiciler, ORM gözlemcileri ve bölümleme stratejileri ile kendi loglama altyapınızı kurabilirsiniz.

Bir sonraki adım olarak, log verilerinizin üzerine bir görselleştirme paneli (dashboard) kurarak, sistemdeki şüpheli hareketleri anlık olarak takip eden bir uyarı mekanizması (alerting) geliştirmeyi düşünebilirsiniz.