SQL Server Audit, CDC, Temporal, Ledger: Hangisi Neyi Kanıtlar?

Denetçi sorar: "Bu veritabanında kim neyi değiştirdi, kanıtınız ne?" Ekip beş ayrı özellik sayar: Audit açık, CDC var, temporal tablo kullanıyoruz, Extended Events oturumu çalışıyor, yeni sürüme geçince ledger da geldi. Hepsi doğrudur ve hepsi farklı bir soruya cevap verir. Bu yazı SQL Server'ın bu beş özelliğini aynı beş soruyla sınar: her biri neyi kaydeder, neyi kaydetmez ve hangisi kanıt olarak tek başına ayakta durur.

Bir İz Hangi Soruları Cevaplamalı

Denetim sorusunu beş parçaya bölmek seçimi kolaylaştırır:

1. Şema: kim tablo, görünüm, yordam oluşturdu, değiştirdi, sildi?
2. Veri: kim satır ekledi, güncelledi, sildi?
3. Değer: değişiklikten önce ve sonra değer neydi?
4. Okuma: kim hassas tabloyu okudu?
5. Bütünlük: kaydın kendisi sonradan değiştirilirse bu fark edilir mi?

SQL Server Audit

SQL Server Audit uyum ve denetim için tasarlanmış özelliktir. Sunucu düzeyinde (oturum açma, rol üyeliği, izin değişikliği) ve veritabanı düzeyinde (şema değişikliği, belirli tablolarda SELECT, INSERT, UPDATE, DELETE) olayları kaydeder. Her kayıtta zaman, oturum açma adı, oturum numarası, nesne ve çalıştırılan ifadenin metni bulunur. Kayıtlar veritabanının dışında, bir dosyaya ya da Windows olay günlüğüne yazılır. SQL Server 2016 SP1'den bu yana veritabanı düzeyindeki denetim bütün sürümlerde vardır. Şema değişikliklerini ve silmeleri kaydeden hazır bir kurulum betiği tabloyu kim sildi yazısındadır.

Kaydetmediği: değişen değerleri. UPDATE ifadesinin metni yazılır, ama hangi satırın hangi değerden hangi değere geçtiği yazılmaz. Bütünlük açısından: denetimin durdurulması ve yeniden başlatılması denetim kaydına bir oturum değişikliği olayı olarak düşer, bu yüzden aradaki boşluk görünür. Ama dosyaların durduğu klasöre yazabilen biri dosyayı silebilir; klasör yetkisi ve dosyaların SIEM'e taşınması bu yüzden kontrolün parçasıdır.

Extended Events

Extended Events SQL Server'ın genel amaçlı olay altyapısıdır; SQL Server Audit de bunun üzerine kurulmuştur. Tamamlanan ifadeleri, oturum açma adını ve uygulama adını yakalayan bir oturum tanımlanabilir ve performans sorunlarını incelemek için çok değerlidir. Ama tasarımı tanılama içindir: oturumu yetkili biri sessizce durdurabilir, hedef dosyalar sıradan dosyalardır ve olay kaybına izin veren bir tutma ayarı varsayılandır. Denetim için kullanılabilir, ama SQL Server Audit varken kanıt olarak onun yerini tutmaz.

Change Data Capture ve Change Tracking

Change Data Capture (CDC) işlem günlüğünü okuyup değişen satırların önceki ve sonraki değerlerini ayrı değişiklik tablolarına yazar. Veri ambarına artımlı yükleme için tasarlanmıştır ve bu işi iyi yapar. SQL Server Agent ister ve SQL Server 2016 SP1'den bu yana Standard sürümde de vardır. Kaydetmediği: değişikliği kimin yaptığı. CDC tablolarında kullanıcı kolonu yoktur. Varsayılan saklama süresi üç gündür; temizleme işi eski kayıtları siler.

Change Tracking daha da hafiftir: yalnız hangi satırın değiştiğini ve bir sürüm numarasını tutar. Değer de kullanıcı da yoktur. Uygulamaların eşitleme işi içindir, denetim için değil.

Temporal Tablolar

Sistem sürümlü temporal tablolar (SQL Server 2016 ve sonrası) her satırın eski sürümünü geçerlilik zaman aralığıyla birlikte bir geçmiş tablosunda tutar. "Bu müşterinin 3 Mart'taki adresi neydi" sorusuna FOR SYSTEM_TIME AS OF ile doğrudan cevap verir. Kaydetmediği: değişikliği yapan kişi. Kullanıcı bilgisi istenirse tabloya ayrı bir kolon eklenip uygulama ya da tetikleyiciyle doldurulmalıdır. Bütünlük açısından: tabloda ALTER yetkisi olan biri sürümlemeyi kapatıp (SYSTEM_VERSIONING = OFF) geçmiş tabloyu değiştirebilir ve tekrar açabilir. Temporal tablo bir geçmiştir, kurcalanmaya karşı kanıt değildir.

Ledger Tabloları

SQL Server 2022 ile gelen ledger tabloları kurcalanmanın fark edilmesi için tasarlanmıştır. İki türü vardır. Yalnız ekleme yapılabilen (append-only) ledger tablosunda UPDATE ve DELETE veritabanı motoru tarafından reddedilir. Güncellenebilir ledger tablosunda değişikliğe izin verilir ama her satırın eski sürümü bir geçmiş tablosunda tutulur. İki türde de her işlem kriptografik olarak zincirlenir ve sys.database_ledger_transactions görünümü işlemin zamanını ve işlemi yapan veritabanı kullanıcısını (principal_name) gösterir.

Kurcalamanın fark edilmesi bir koşula bağlıdır: veritabanı özeti (sys.sp_generate_database_ledger_digest) düzenli alınıp veritabanı yöneticisinin değiştiremeyeceği bir yerde saklanmalıdır. Doğrulama sys.sp_verify_database_ledger ile bu özetlere karşı yapılır. Azure SQL'de özetler değiştirilemez bir depoya kendiliğinden yazılabilir; kurum içi SQL Server'da bu işi siz kurarsınız. Ledger tablosu silinebilir, ama silinen tablo yeniden adlandırılıp saklanır ve silme defterde görünür. Ledger yalnız ledger olarak oluşturulmuş tabloları kapsar; mevcut bir tablo sonradan ledger'a çevrilemez, yeni bir ledger tabloya taşınır.

Tek Tabloda Karşılaştırma

Tablonun dikey okuması basittir: hiçbir özellik beş sorunun beşini birden cevaplamaz. Yatay okuması daha önemlidir: "kim" ve "değer" soruları farklı araçlarda durur ve ancak zaman ve oturum bilgisiyle birleştirilebilir.

Birlikte Nasıl Kullanılır

Kurumsal bir kurulumda tipik birleşim şudur: SQL Server Audit şema değişikliklerini, izin değişikliklerini ve hassas tablolardaki okuma ile yazmaları kaydeder; dosyalar SIEM'e akar. Değer geçmişi gereken tablolar temporal ya da ledger olarak tasarlanır. Ledger kullanılıyorsa veritabanı özeti düzenli alınıp değiştirilemez bir depoya yazılır. Bu üçü "ne oldu" sorusunu cevaplar.

Açık kalan soru "neden ve kimin onayıyla" sorusudur; bu, veritabanının içinde hiçbir zaman durmaz. SQL Change Guard bu soruyu yalnız kendi üzerinden giden iş için cevaplar ve yukarıdaki özellikleri hedef sunucularda kurmaz ya da yönetmez. Ürünün kendi kaydı SQL Server'ın append-only ledger tablosunda durur; imza anahtarı ve dış özet klasörü tanımlı kurulumda defterin imzalı özeti saatte bir veritabanı dışına yazılır. Her çalıştırmada ürün, hedef sunucunun bildirdiği oturum numarasını ve zamanı kaydeder; bu iki bilgi, hedefteki SQL Server Audit kayıtlarıyla (session_id ve event_time) eşleştirmeyi mümkün kılar. "Expected Access Principals" raporu her sunucu için ürünün kullandığı SQL hesabını ve bağlandığı makineleri listeler; bu listeye uymayan bir oturumun ürün üzerinden gelmediği SIEM kuralına çevrilebilir.

Sık Sorulan Sorular

SQL Server Audit performansı etkiler mi?

Kayıtları varsayılan olarak bir saniyeye kadar biriktirip zaman uyumsuz yazar (QUEUE_DELAY = 1000), bu yüzden şema ve izin olayları için etkisi küçüktür. Çok sık okunan bir tabloda her SELECT ifadesini kaydetmek ise ciddi hacim üretir; kapsamı hassas tablolarla sınırlayın ve açmadan önce test ortamında ölçün.

PostgreSQL ve Oracle'da karşılığı nedir?

PostgreSQL'de çekirdekte bir denetim özelliği yoktur; yaygın çözüm pgAudit eklentisidir ve kayıtları sunucu günlüğüne yazar. Oracle'da Unified Auditing vardır; denetim politikalarıyla şema, veri ve okuma olayları kaydedilir. Soruların mantığı aynıdır: kim, ne, eski değer ve izin bütünlüğü ayrı ayrı sorulmalıdır.

Ledger'a geçersek Audit'e gerek kalır mı?

Evet. Ledger yalnız ledger olarak oluşturulmuş tablolardaki değişikliği ve bunun kurcalanmadığını gösterir. Diğer tabloları, okumaları, oturum açmaları ve izin değişikliklerini kaydetmez. İkisi farklı sorulara cevap verir.

Audit dosyalarını kim okuyabilmeli?

Okuma yetkisi denetim ve güvenlik ekibinde olmalı; yazma ve silme yetkisi yalnız SQL Server servis hesabında. Veritabanı yöneticisinin bu klasörü silebildiği bir kurulumda denetim, denetlenen kişinin elindedir.