Çalıştırılan SQL, Onaylanan SQL miydi?

Üretim veritabanınızda bir şema değişikliği yapıldı. Bilet sisteminde talep var, onay kaydı var, veritabanı denetim günlüğünde de çalışan cümle görünüyor. Şimdi denetçi tek bir soru soruyor: çalıştırılan bu cümle, onaylanan cümlenin aynısı mıydı? Çoğu kurumda bu sorunun cevabı vardır ama kanıtı yoktur. Bilet neyin istendiğini söyler, veritabanı günlüğü ne çalıştığını söyler, ikisini birbirine bağlayan bağ ise genellikle bir insanın hafızasıdır.

Bu yazı, o bağın nasıl kurulacağını ve neyin gerçekten kanıtlanabildiğini anlatır. Konu bir SQL cümlesinin nasıl yazılacağı değil; bir değişikliğin talepten çalıştırmaya kadar izinin nasıl bütün kalacağıdır.

Denetçinin Sorduğu Asıl Soru

Denetim görüşmelerinde soru nadiren "logunuz var mı" biçiminde gelir. Log çoğu kurumda vardır. Soru şu üç parçayı birleştirmenizi ister:

• Yetki: Bu değişikliği kim istedi ve kim onayladı? Onaylayan, onaylamaya yetkili miydi?
• İçerik: Onaylanan tam olarak neydi? Onaydan sonra içerik değişti mi?
• Sonuç: Üretimde ne oldu? Ne zaman, kim tarafından, hangi sonuçla çalıştı?

Bu üç parçadan biri eksikse cevap ikna edici olmaz. En sık eksik olan ortadaki parçadır: onaylanan içerik ile çalıştırılan içeriğin aynı olduğunu gösteren kayıt.

İki Kayıt Neden Birbirini Tutmuyor?

Çünkü iki kayıt iki farklı sistemde ve iki farklı amaç için tutulur. Her ikisi de kendi işini doğru yapar; sorun aradaki boşluktadır.

Veritabanının kendi denetim özellikleri (SQL Server Audit ve Extended Events, Oracle Unified Auditing, PostgreSQL tarafında pgaudit) bu tabloda ikinci satırdır. Ne çalıştığını güvenilir biçimde söylerler. Neden çalıştığını ve kimin onayladığını bilmezler, çünkü o bilgi veritabanına hiç girmez.

Bu yüzden "denetim günlüğümüz açık" cümlesi tek başına denetçiyi rahatlatmaz. Kapsam sorunu değil, bağ sorunu vardır.

Kanıtlanabilir Zincirin Dört Halkası

Bağı kurmanın yolu, değişikliği tek bir yaşam döngüsü içinde tutmak ve her adımı aynı kimliğe bağlamaktır. Dört halka yeterlidir.

1. Tek kimlik

Talep, betikler, onay adımları, çalıştırma sonucu ve denetim kayıtları aynı talep numarasına bağlanmalıdır. Bilet numarası ayrı bir alan olarak taşınır ama zincirin taşıyıcısı olamaz: bilet çoğu zaman birden fazla değişikliği kapsar.

2. Onay anında dondurulan kural seti

Bir talep hangi kurallara göre değerlendirildiyse o kural seti talebe kaydedilmelidir. Aksi halde altı ay sonra bakan kişi bugünün kurallarını görür ve o günkü kararı yanlış yorumlar. Kuralları sonradan gevşetmek de bir değişikliktir ve ayrıca kayda geçmelidir.

3. Çalıştırma anının kaydı

Çalıştırmayı başlatan kişi, çalıştırma zamanı, hedef sunucu ve veritabanı, sonuç, süre, etkilenen satır sayısı ve varsa hata mesajı kaydedilmelidir. Burada sık yapılan hata, çalıştıranı arka plan servisi olarak yazmaktır. Düğmeye basan kişi ile işi yürüten servis farklı şeylerdir ve denetçi ilkini sorar.

4. İçeriğin parmak izi

Zincirin en çok atlanan halkası budur ve asıl soruyu cevaplayan halka odur. Çalıştırma anında her betiğin içeriğinden bir özet değeri üretilip denetim kaydına yazılmalıdır. Sonradan bakıldığında bugünkü betiğin özeti yeniden hesaplanır ve iki değer karşılaştırılır.

Betiğin Özeti Neden Gerekli?

Betiğin metnini denetim kaydına olduğu gibi yazmak ilk bakışta yeterli görünür. İki pratik sorunu vardır: uzun betikler denetim izini şişirir, ve metnin kendisi kayıt içinde durduğu için "bu metin sonradan düzenlendi mi" sorusu yine cevapsız kalır.

Özet değeri iki sorunu birden çözer. Sabit boyuttadır ve içerikteki tek karakterlik bir değişiklik bile özeti tamamen değiştirir. Bugün saklanan betiğin özeti çalıştırma anındaki özetle aynıysa, betik o günden beri değişmemiştir. Farklıysa değişmiştir ve bu bir soru işaretidir; kendi başına suç değildir ama açıklama ister.

Aynı mantık denetim izinin kendisi için de kurulabilir: kayıtlar birbirine bağlanır ve zincirin bütünlüğü sonradan doğrulanabilir. Bu konuyu ayrıca denetim izi nasıl değiştirilemez hale gelir yazısında ele aldık.

Bu Yöntemin Sınırları

Bir kontrolün ne yapmadığını söylemek, ne yaptığını söylemek kadar önemlidir. Denetçiye fazlasını vaat eden bir kontrol, ilk incelemede güven kaybettirir.

• Özet karşılaştırması, saklanan betiğin çalıştırma anından beri değişmediğini gösterir. Veritabanı motorunun o metni harfi harfine aldığını motorun kendi kaydından bağımsız olarak kanıtlamaz. Bu ikisi birlikte kullanıldığında tablo tamamlanır.
• Uygulamanın dışından, doğrudan veritabanına bağlanılarak yapılan işler bu zincire girmez. Onları kapsamak ayrı bir konudur ve veritabanı tarafında yetki daraltmayı gerektirir.
• Özet, içeriğin ne yaptığını değil ne olduğunu söyler. Zararlı ama onaylanmış bir betik de bütünlük kontrolünden geçer. İçeriğin değerlendirilmesi doğrulama ve risk adımlarının işidir.

Kontrol Listesi

Kendi ortamınızda şu soruları sırayla sorun. Hepsine belge göstererek cevap verebiliyorsanız zincir bütündür.

Son madde çoğu kurumda "ekran görüntüsü topluyoruz" diye cevaplanır. Denetim döneminin gerçek maliyeti de oradadır: kontrolün yokluğu değil, kanıtın dağınıklığı.

Sık Sorulan Sorular

Veritabanının kendi denetim özelliği bu soruyu cevaplamaya yetmez mi?

Yetmez, çünkü farklı bir soruyu cevaplar. SQL Server Audit, Oracle Unified Auditing ve pgaudit hangi cümlenin çalıştığını güvenilir biçimde kaydeder. Onayın kim tarafından, hangi politikaya göre verildiği bilgisi veritabanına hiç girmediği için orada bulunamaz. İki kayıt birlikte kullanıldığında tablo tamamlanır.

Betiğin tamamını denetim kaydına yazmak yerine neden özet kullanılıyor?

Özet sabit boyuttadır ve denetim izini şişirmez. Daha önemlisi, karşılaştırmayı mümkün kılar: bugünkü betiğin özeti yeniden hesaplanıp çalıştırma anındaki değerle karşılaştırılabilir. Metnin kendisi kayıtta dursaydı, o metnin sonradan düzenlenip düzenlenmediği sorusu yine açık kalırdı.

Bilet numarası zinciri taşımaya yetmez mi?

Yetmez, çünkü bir bilet çoğu zaman birden fazla değişikliği kapsar ve bilet üzerinde hangi betiğin hangi sunucuda çalıştığı görünmez. Bilet numarası taşınmalıdır, ama zincirin taşıyıcısı talebin kendi kimliği olmalıdır.

Acil bir değişiklikte bu zincir kopar mı?

Kopmamalıdır. Acil değişiklik onayın atlanması değil, önceden tanımlanmış daha kısa bir onay yolunun işletilmesidir. Talep, gerekçe, uygulanan politika ve çalıştırma kaydı acil durumda da aynı şekilde tutulur. Konuyu acil veritabanı değişikliği yazısında ayrıntılı ele aldık.