Denetçi Kapıdan Girdiğinde Hazır mısınız? SQL Change Guard ile Veritabanı Değişiklik Yönetiminin Yeni Standardı

Senaryo şu: BDDK denetçisi sabah geldi. İlk sorusu şu oldu: "Geçen 6 ayda production veritabanlarınızda yapılan tüm değişikliklerin listesini, kim onayladı bilgisiyle birlikte verir misiniz?" Bu soruyu duyduğunuzda içinizde ne hissediyorsunuz? "Tabii, şu an çıkarıyorum" diyorsanız tebrikler. Ama Türkiye'deki kurumların büyük çoğunluğu bu soruyu duyduğunda geriye dönük e-posta taramaya, geliştiricileri arayıp sormaya ya da "tam kayıt tutmuyorduk" açıklaması yapmaya başlıyor. SQL Change Guard bu tablonun değişmesi için geliştirildi.

Neden Bu Kadar Zor? Veritabanı değişiklik yönetiminin neden bu kadar çok kurumda eksik kaldığını anlamak için biraz geriye gitmek gerekiyor. DBA bir stored procedure güncelledi. Geliştirici bir tablo değişikliği yaptı. Sistem yöneticisi gece bir şeyler düzeltti. Bunların tamamını kim, ne zaman, hangi onaylayla yaptı? Bu bilgiyi tutmak için sistematik bir yapı gerekiyor. Çoğu kurum bunu e-posta, Excel ya da "ekip biliyor" güvencesiyle yönetmeye çalışıyor. Denetim gelene kadar bu yeterliymiş gibi görünüyor. Denetim gelince değil. SQL Change Guard bu sistematik yapıyı kuruyor. Ama bunu yaparken geliştirici ve DBA akışını boğmadan, hızı koruyarak yapıyor. İşte bu denge en kritik nokta.

Platform Bir Bütün Olarak Nasıl Çalışıyor? Her değişiklik bir talep ile başlar. Bu talep platformda kayıt altına alınır, analiz edilir, onaylanır, test edilir ve production'a alınır. Her adım belgelenir. Platform dışından yapılan bir değişiklik olursa bu da tespit edilir ve alarm üretilir. Kulağa basit geliyor. Ama her adımın arkasında güçlü bir altyapı var. Modül modül açıklayalım.

Modüller Change Management: Sürecin Omurgası Her şey buradan geçiyor. Geliştirici değişiklik talebini oluşturur, script'i platforma yükler, açıklama yazar. Sistem otomatik analizi başlatır. Analiz tamamlandıktan sonra talep onay akışına girer. Onay tamamlandığında deployment gerçekleşir. Her adım zaman damgasıyla kayıt altına alınır. Bu yapı görevler ayrılığı prensibini zorla uygular. Değişikliği yükleyen kişi aynı değişikliği onaylayamaz. Bu teknik bir kısıtlama, politika belgesi değil. BDDK ve COBIT denetimlerinde "değişiklik yönetim sürecinizi gösterir misiniz?" sorusuna cevap bu modülden geliyor. Talep, onay, deployment, kimin ne zaman ne yaptığı — eksiksiz kayıt.

Validation: 65+ Kural, Sıfır Sürpriz Script platforma yüklendiği anda 65'ten fazla kural devreye giriyor. WHERE koşulsuz DELETE veya UPDATE var mı? DROP TABLE içeriyor mu? Büyük tabloda kilit riski taşıyan bir operasyon mu? Naming convention'a uygun mu? Foreign key ihlali yaratıyor mu? Bu kurallar hem teknik hataları hem de yönetişim ihlallerini yakalıyor. Önemli bir detay: kural seti kuruma göre özelleştirilebilir. Bankacılık sektörünün ihtiyaçları farklı, e-ticaretin farklı. Validasyon sonuçları hem geliştirici hem onaylayan için şeffaf. "Neden reddedildi?" sorusu sormak gerekmiyor, sistem gösteriyor.

Risk Scoring: Her Değişiklik Aynı Değil Validasyon sonuçlarına göre 0-100 arası bir risk skoru hesaplanıyor. Bu skor sadece bir sayı değil. Onay akışını şekillendiriyor. Düşük riskli değişiklikler hızlı onay alıyor. Yüksek riskli değişiklikler ek onay seviyelerine gidiyor. Kritik skordaki değişiklikler otomatik olarak engelleniyor, manuel inceleme zorunlu hale geliyor. Denetim açısından bu skor altın değerinde. "Neden bu değişiklik ek onay gerektirdi?" sorusuna sistem kendisi cevap veriyor.

Sandbox: Önce Gör, Sonra Yap Production'a geçmeden önce değişikliği gerçek veriyle test etmek istiyorsunuz ama production'u etkilemek istemiyorsunuz. Sandbox tam bunu yapıyor. BEGIN-ROLLBACK mekanizmasıyla script production verisine karşı çalıştırılıyor, sonuçlar görülüyor, geri alınıyor. Production'da hiçbir iz kalmıyor. Geliştirici şunu görüyor: kaç satır etkilenecek, hangi kayıtlar değişecek, tahmini çalışma süresi ne. Sürpriz yok. KVKK perspektifinden bakıldığında bu özellik kritik. Kişisel veri içeren tablolarda değişiklik yapmadan önce etkinin görülmesi veri ihlali riskini ciddi ölçüde azaltıyor.

Rollback: Her Deployment'ın Güvencesi Değişiklik onaylandı ve production'a alındı. Bir şeyler ters gitti. Rollback modülü bu an için var. Platform her deployment öncesinde otomatik rollback script'i üretiyor. Stored procedure değiştirildiyse eski versiyonu saklıyor. Tablo değişikliği yapıldıysa geri alma adımlarını hazırlıyor. Bir kriz anında "nasıl geri döneceğiz?" sorusu zaten yanıtlanmış oluyor. Panik değil, prosedür. Denetim açısından ise rollback planının varlığı ISO 27001 gereksinimlerinden biri. "Değişiklikleriniz için geri alma prosedürünüz var mı?" sorusu artık "evet, her deployment için otomatik üretiliyor" cevabıyla yanıtlanıyor.

Auto Execution: Onaylı Değişiklik, Otomatik Deployment Onay süreci tamamlandı. Deployment penceresini bekliyorsunuz. Gece 02:00'de biri deployment'ı manuel başlatacak. Auto Execution bu ihtiyacı ortadan kaldırıyor. Onaylanan değişiklik, belirlenen zamanda otomatik olarak çalıştırılıyor. Kimsenin gece bağlanmasına gerek yok. Ama kritik güvence: otomatik çalışacak olan değişiklik onaylı ve kayıtlı. "Otomatik oldu, kontrol edemedik" söylemi tarih oluyor.

Release Package: Toplu Değişiklikleri Düzenli Yönetmek Gerçek hayatta değişiklikler tek gelmez. Bir özellik geliştirmesi 12 script içerebilir. Bu script'lerin doğru sırayla, doğru ortamlara alınması gerekiyor. Release Package bu karmaşıklığı çözüyor. İlgili değişiklikler paket altında gruplanıyor, bağımlılık sırası tanımlanıyor, paket bütünüyle onaylanıyor ve bütünüyle deploy ediliyor. "Şu script atıldı mı? Hangisi önce gitmeliydi?" soruları tarihe karışıyor.

Query Result: Hassas Veri Görünürlüğünü Kontrol Altına Almak DBA platform üzerinden bir sorgu çalıştırdı. Sorgu sonucu TC kimlik numaraları, IBAN'lar, tıbbi kayıtlar içeriyor. Query Result modülü bu sonuçları kullanıcının yetki seviyesine göre maskeleyerek gösteriyor. Ad: ali **** TC: 12345* IBAN: TR33 **** **** **** **** ** Bu özellik KVKK'nın teknik güvenlik tedbirleri yükümlülüğünü doğrudan karşılıyor. "Kişisel verilere yetkisiz erişimi nasıl önlüyorsunuz?" sorusuna somut bir teknik cevap.

Performance Report: Değişiklik Performansı Nasıl Etkiledi? Deployment öncesi kritik sorgular ne kadar sürüyordu? Deployment sonrası ne kadar sürüyor? Performance Report bu karşılaştırmayı görselleştiriyor. Hangi sorgular yavaşladı, hangileri hızlandı, ortalama response time nasıl değişti. Bu modül hem teknik hem yönetim için değerli. Teknik ekip regresyonu erken yakalıyor. Yönetim ise değişikliklerin sistem üzerindeki etkisini somut metriklerle görüyor.

Object History: Geçmişe Tek Tıkla Bakmak Bir stored procedure'ün 8 ay önceki versiyonu ne içeriyordu? Object History modülü her veritabanı nesnesinin tüm değişim tarihçesini tutuyor. Kim değiştirdi, ne zaman, hangi release package içinde, hangi onaylayla. İki versiyon arasındaki fark diff görünümüyle yan yana gösteriliyor. Kelimesi kelimesine ne değişti, görünüyor. Denetimde "bu nesne nasıl evrildi?" sorusu artık saniyeler içinde yanıtlanabiliyor.

External Database Changes Monitoring: En Kritik Özellik Bir gerçeği kabul edelim: sysadmin yetkisine sahip biri SSMS'i açıp doğrudan production'da istediği değişikliği yapabilir. Bunu engellemek SQL Server mimarisi gereği mümkün değil. Ama tespit etmek mümkün. External Database Changes Monitoring, platform dışından yapılan her değişikliği otomatik tespit ediyor. Biri gece SSMS'ten bir stored procedure güncelledi. Platform bunu yakaladı. Sabah ilgili kişilere bildirim gitti: "23:47'de dbo.SP_SiparisHesapla nesnesi platform dışından değiştirildi." Engelleyemediniz. Ama haberdar oldunuz. Ve bu fark, kontrollü yönetim ile kör kalmak arasındaki farktır. Denetim açısından ise bu özellik son derece güçlü bir kanıt: "Sistem dışından yapılan değişiklikleri nasıl tespit ediyorsunuz?" sorusuna verilen yanıt artık "otomatik alarm üretiyoruz ve kayıt altına alıyoruz."

Reporting: Denetim Paketi Hazır Tüm bu modüllerin ürettiği veri Reporting modülünde anlam kazanıyor. KVKK Denetim Raporu Kişisel veri içeren tablolarda yapılan değişiklikler, erişim logları, maskeleme kayıtları. Kişisel Verileri Koruma Kurulu'na sunulmak üzere biçimlendirilmiş. BDDK Değişiklik Yönetim Raporu Belirli bir dönemdeki tüm değişiklikler, onay zincirleri, deployment geçmişi. BDDK bilgi sistemleri yönetmeliği gereksinimlerine uygun format. ISO 27001 Denetim Raporu A.12.1.2 maddesi kapsamında değişiklik yönetimi kanıtları. Talep, onay, test, deployment, doğrulama — her adım belgelenmiş. Prosedür Dışı Değişiklik Raporu Platform dışından yapılan değişikliklerin dönemi ve dağılımı. Tespit zamanları, alarm kayıtları, takip durumları. Risk Dağılımı Raporu Hangi risk seviyesinde kaç değişiklik yapıldı? Kritik değişiklikler nelerdi, nasıl yönetildi? Kullanıcı Aktivite Raporu Kim kaç değişiklik talebi oluşturdu, kaçı onaylandı, kaçı reddedildi? Bir denetimde bu raporları dakikalar içinde üretmek, "elimizde bu kayıtlar yok" demek ile aranızdaki farkı belirliyor.

Türkiye'nin Özgün Gereksinimleri Yabancı araçlar teknik olarak güçlü olabilir. Ama Türkiye'de çalışan kurumların özgün gereksinimleri var. KVKK: Kişisel Verileri Koruma Kanunu sadece bir uyum gerekliliği değil, ihlali halinde ağır yaptırımları olan bir yasal zorunluluk. SQL Change Guard KVKK teknik tedbirlerini karşılamak üzere tasarlandı. BDDK: Bankacılık sektörü bilgi sistemleri yönetmeliği değişiklik yönetimini açıkça düzenliyor. Bu düzenlemeye uyum SQL Change Guard ile belgeli ve kanıtlanabilir. Türkçe Arayüz: Operasyon ekibinin İngilizce bilen uzman olması gerekmiyor. Tüm arayüz Türkçe. Yerel Destek: Türkiye'den, Türkçe teknik destek. Tamamen On-Premise: Hiçbir veri dışarıya çıkmıyor. Kurumun kendi ağında, kendi kontrolünde.

Kim İçin? DBA: Tüm değişiklikleri tek noktadan görme, nesne geçmişine anında erişim, platform dışı değişiklik alarmları. Geliştirici: Sandbox ile güvenli test, otomatik rollback, validasyon geri bildirimi. IT Yöneticisi: Risk bazlı onay mekanizması, deployment görünürlüğü, performans raporları. Compliance Ekibi: KVKK ve BDDK'ya hazır raporlar, prosedür dışı değişiklik geçmişi. Üst Yönetim: Kurumun veritabanı değişiklik riskini özetleyen yönetim raporları.

Sonuç: Denetçi Tekrar Kapıdan Girecek BDDK denetçisi tekrar gelecek. KVKK soruşturması başlayabilir. ISO 27001 sertifikasyon denetimi yaklaşıyor. O an geldiğinde iki kurumdan biri olacaksınız. Birincisi: "Raporları şimdi hazırlıyoruz, birkaç güne bakın." İkincisi: "Hangi dönemi istiyorsunuz? Raporları şu an üretiyorum." Bu fark bir araç farkı. Ama aynı zamanda bir olgunluk farkı, bir hazırlık farkı. SQL Change Guard bu olgunluğu inşa etmek için geliştirildi.

Ücretsiz demo ve daha fazla bilgi için: sqlchangeguard.com