Veritabanı Audit'i Neden Çoğu Kurumda Sadece Kağıt Üzerinde Kalıyor?
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
Bir kurumun IT politikasını açın. Büyük ihtimalle şu cümleyi bulursunuz:
"Veritabanı değişikliklerine ilişkin tüm işlemler kayıt altına alınır ve düzenli olarak denetlenir."
Şimdi aynı kurumda bir DBA'ya sorun: "Geçen Salı gece 23:00'de production veritabanında ne değişti?"
Sessizlik.
İşte bu iki şey arasındaki uçurum, Türkiye'deki kurumların büyük çoğunluğunun yaşadığı audit problemi.
Audit Ne Demek, Gerçekten?
Audit kelimesi dilden dile dolaşıyor. Herkes "auditimiz var" diyor. Ama audit tam olarak ne?
Gerçek bir veritabanı audit'i şu soruların tamamını yanıtlayabilmek demek:
Kim? Bu değişikliği kim yaptı? Hangi kullanıcı, hangi uygulama üzerinden?
Ne? Tam olarak ne değişti? Hangi nesne, hangi satır, hangi değerden hangi değere?
Ne zaman? Tarihi ve saati. Saniye hassasiyetinde.
Neden? Değişikliğin gerekçesi ne? Hangi iş ihtiyacı?
Kim onayladı? Bu değişiklik onay sürecinden geçti mi? Kim onayladı?
Sonuç ne oldu? Deployment başarılı mıydı? Sistem nasıl etkilendi?
Bu altı sorudan birine bile "bilmiyorum" cevabı veriliyorsa audit eksik demektir.
Türkiye'de Audit'i Zorunlu Kılan Düzenlemeler
Audit artık iyi niyet meselesi değil. Yasal zorunluluk.
KVKK
Kişisel Verileri Koruma Kanunu, kişisel veri barındıran sistemlerde teknik güvenlik tedbirlerinin alınmasını zorunlu kılıyor.
Bu tedbirler arasında erişim loglarının tutulması, değişiklik kayıtlarının saklanması ve bu kayıtların düzenli denetimi açıkça bekleniyor.
Kişisel Verileri Koruma Kurulu bir ihlal soruşturması başlattığında ilk istenen şeylerden biri şu oluyor: "İlgili veritabanında son 6 ayda hangi değişiklikler yapıldı, kim erişti?"
Bu soruyu yanıtlayamayanlar için yaptırım riskinin yanı sıra itibar kaybı da gündemdeki yerini koruyor.
BDDK
Bankacılık Düzenleme ve Denetleme Kurumu'nun bilgi sistemleri yönetmeliği, değişiklik yönetimi süreçlerini açıkça düzenliyor.
Onay zincirleri, test süreçleri, deployment kayıtları — bunların tamamının belgelenmesi zorunlu. BDDK denetçileri artık sadece finansal tabloları değil, IT sistemlerini ve süreçlerini de inceliyor.
"Değişiklik yönetim sürecinizi göster" talebi bankacılık denetimlerinde standart hale geldi.
ISO 27001
A.12.1.2 maddesi: Bilgi işleme olanaklarını etkileyen değişiklikler kontrol altında olmalı.
Bu madde için denetçi kanıt istiyor. Politika belgesi değil, somut kanıt: değişiklik talep kayıtları, onay belgeleri, test sonuçları, deployment geçmişi.
Sertifikasyon yenilemesinde bu kanıtları sunamamak hem sertifikayı tehlikeye atıyor hem de kurumun gerçek güvenlik olgunluğunu sorgulatıyor.
SPK ve Diğerleri
Sermaye Piyasası Kurulu, SEDDK, Hazine ve Maliye Bakanlığı denetimleri — hepsinin ortak noktası şu: IT sistemlerinde ne olduğunu belgeleyebilmek.
Mevcut Audit Yöntemlerinin Kırılgan Yapısı
Kurumların çoğu audit ihtiyacını şu yöntemlerle karşılamaya çalışıyor:
SQL Server Native Audit Teknik olarak var. Ama logları analiz etmek ayrı bir uzmanlık gerektiriyor. Alarm mekanizması yok. Onay süreciyle entegre değil. "Kim onayladı?" sorusunu yanıtlamıyor.
DDL Trigger Hızlı kurulum. Ama sysadmin tarafından devre dışı bırakılabiliyor. Bildirim yok. Onay kaydı yok.
E-posta ve Excel "Onay aldım" diye bir e-posta zinciri. Denetimde bu kabul edilmiyor. Kim gönderdi, kim onayladı, hangi versiyonu onayladı, onay öncesi ne incelendi — bunlar e-postada yok.
Bu yöntemlerin ortak sorunu şu: hepsi reaktif. Bir şey olduktan sonra bakılıyor. Önleme yok, gerçek zamanlı tespit yok, bütünleşik kayıt yok.
Gerçek Audit Trail Nasıl Görünmeli?
Bir denetçinin önüne koyabileceğiniz gerçek bir audit kaydı şöyle görünmeli:
Değişiklik ID: CHG-2024-0847
Talep Eden: Ahmet Yılmaz (Kıdemli Geliştirici) Talep Tarihi: 15 Mart 2024, 14:23
Değişiklik Açıklaması: dbo.SP_SiparisHesapla stored procedure güncelleme — KDV hesaplama mantığı düzeltmesi
Validasyon Sonucu: 12 kural kontrol edildi, 2 uyarı, 0 kritik hata Risk Skoru: 34 / 100 (Orta Risk)
Sandbox Test: 15 Mart 2024, 15:10 — 847 satır etkilendi, sonuçlar beklenen değerlerle eşleşti
Teknik Onay: Mehmet Kaya (DBA) — 15 Mart 2024, 16:45 — "Validasyon sonuçları incelendi, uygun" Yönetici Onay: Elif Demir (IT Müdürü) — 15 Mart 2024, 17:20 — "İş gereksinimi doğrulandı, onaylıyorum"
Deployment: 15 Mart 2024, 22:00 — Otomatik çalıştırma (Auto Execution) Deployment Süresi: 4 dakika 12 saniye Sonuç: Başarılı
Doğrulama: 15 Mart 2024, 22:15 — Kritik sorgular test edildi, performans beklenen aralıkta
Rollback Script: Mevcut (Otomatik üretildi, arşivlendi)
Bu kayıt denetçinin sorduğu her soruyu yanıtlıyor. Kim, ne, ne zaman, neden, kim onayladı, sonuç ne oldu.
Prosedür Dışı Değişiklik: Audit'in En Zor Kısmı
Kontrollü değişiklikleri kayıt altına almak görece kolay. Asıl zor olan şu: ya biri süreci atlayıp doğrudan değişiklik yaparsa?
Sysadmin SSMS'i açar, gece production'a bağlanır, bir şeyler değiştirir, çıkar. Hiçbir platforma kayıt düşülmedi. Sabah kimsenin haberi yok.
Gerçek audit'in bu durumu da kapsaması gerekiyor.
SQL Change Guard'ın External Database Changes Monitoring modülü tam bu boşluğu kapatıyor.
Platform, veritabanı şemasının düzenli anlık görüntülerini alıyor. Her kontrol döngüsünde mevcut durum bir öncekiyle karşılaştırılıyor. Platform üzerinden yapılmamış bir değişiklik tespit edildiğinde ilgili kişilere anında alarm gidiyor.
Bu tespitin denetim değeri çok yüksek. "Prosedür dışı değişiklikleri nasıl yakalıyorsunuz?" sorusuna "otomatik alarm üretiyoruz ve kayıt altına alıyoruz" cevabı vermek, "bilmiyoruz" demekten çok farklı bir konumu ifade ediyor.
Object History: Geçmişi Yeniden Kurmak
Denetçi soruyor: "Bu stored procedure 3 ay önce nasıldı?"
Object History modülü bu soruyu saniyeler içinde yanıtlıyor. Her veritabanı nesnesinin tüm değişim tarihçesi, versiyon bazında saklanıyor. İki versiyon arasındaki fark diff görünümüyle yan yana gösteriliyor.
Hangi satır eklendi, hangisi silindi, hangisi değiştirildi — kelimesi kelimesine görünüyor.
Bu özellik sadece denetim için değil. Bir sorun yaşandığında "bu nesne en son ne zaman değişti" sorusu da aynı ekrandan yanıtlanıyor.
Audit Raporları: Denetim Paketiniz Hazır
SQL Change Guard'ın Reporting modülü denetim gereksinimlerini karşılamak üzere tasarlandı.
KVKK Audit Raporu Kişisel veri içeren tablolarda yapılan değişiklikler, erişim kayıtları, veri maskeleme logları. Kişisel Verileri Koruma Kurulu formatına uygun.
BDDK Değişiklik Geçmişi Raporu Belirli dönemdeki tüm deployment'lar, onay zincirleri, başarı/başarısızlık durumları. BDDK bilgi sistemleri yönetmeliği gereksinimleriyle örtüşen format.
ISO 27001 Kanıt Paketi A.12.1.2 maddesi kapsamında değişiklik kontrolü kanıtları. Talep, onay, test, deployment — eksiksiz belgelenmiş zincir.
Prosedür Dışı Değişiklik Raporu Platform dışından yapılan değişikliklerin dönemi, tespit zamanları, alarm kayıtları ve takip durumları.
Erişim ve Yetki Raporu Platforma erişimi olan kullanıcılar, yetki seviyeleri, son aktivite tarihleri.
Denetim öncesinde "rapor topluyoruz, birkaç güne bakın" dönemi bitiyor. Bu raporlar her an, dakikalar içinde üretiliyor.
Audit'in Görünmez Faydası
Audit genellikle denetim hazırlığı olarak düşünülüyor. Ama gerçek faydası çok daha geniş.
Ekip içi hesap verebilirlik: Herkes yaptığının kaydedildiğini biliyor. Bu bilgi davranışı değiştiriyor. "Birileri bakıyor" hissi disiplin üretiyor.
Hızlı sorun çözümü: Bir şeyler ters gittiğinde "bu ne zaman değişti, kim değiştirdi" sorusu saniyeler içinde yanıtlanıyor. Saatlerce log karıştırmak tarihe karışıyor.
Güvence: DBA veya geliştirici "ben yapmadım" demek istediğinde kanıtı var. Ya da yaptığını doğrulamak istediğinde de kanıtı var. Her iki durumda da sistem kişiyi koruyor.
Kurumsal hafıza: 2 yıl önce yapılan bir değişikliği araştırmak gerekiyor. Kayıt var. Geçmiş erişilebilir.
Başlamak İçin Ne Gerekiyor?
Audit altyapısı kurmak büyük bir proje gibi görünüyor. Aslında değil.
SQL Change Guard kurulum gereksinimleri minimal: DLL ve EXE dosyalarının kopyalanması. Setup paketi yok, ağır bağımlılık yok. Tamamen kurum içi ağda çalışıyor, hiçbir veri dışarıya çıkmıyor.
Kurulum tamamlandıktan sonra her değişiklik otomatik olarak kayıt altına alınmaya başlıyor. Geçmiş inşa ediliyor. Denetim hazırlığı birikmeye başlıyor.
Son Söz
Denetçi kapıdan girdiğinde iki cümleden birini söyleyeceksiniz.
"Raporları hazırlıyoruz, biraz zaman verin."
Ya da:
"Hangi dönemi, hangi sistemi istiyorsunuz? Şu an üretiyorum."
Bu fark bir yazılım farkı. Ama aynı zamanda kurumun veritabanı yönetimine ne kadar hakim olduğunun farkı.
Audit bir zorunluluk. Ama doğru araçla bu zorunluluk yük olmaktan çıkıp kurumsal güce dönüşüyor.
Ücretsiz demo ve daha fazla bilgi için: sqlchangeguard.com