İçindekiler
"Denetim kayıtlarımız değiştirilemez" cümlesi ürün sunumlarında sık geçer. Denetçi bu cümleyi duyduğunda sorduğu soru hep aynıdır: nasıl? Bu yazı, o soruya verilebilecek teknik cevabı ve cevabın sınırlarını anlatır.
Değiştirilemez mi, Değişiklik Belli mi?
Önce terimi düzeltmek gerekir. Sunucuya tam yetkiyle erişen biri, sonunda her şeyi yapabilir. Gerçekçi hedef, değişikliği her koşulda imkansız kılmak değil, fark edilebilir kılmaktır. Sektörde bunun adı tamper evident, yani kurcalamanın belli olmasıdır.
Bu ayrım önemlidir çünkü "değiştirilemez" iddiası denetçi karşısında çürütülebilir ve tek bir çürütülen iddia diğerlerinin de sorgulanmasına yol açar. "Değişiklik yapılırsa fark edilir ve şu şekilde doğrulanır" cümlesi hem doğrudur hem de daha güçlüdür.
Hash Zinciri ve Sınırı
En bilinen yöntem hash zinciridir. Her kayıt yazılırken içeriği ve bir önceki kaydın özeti birlikte özetlenir; sonuç bir sonraki kayda girdi olur. Ortadaki bir kaydı değiştiren kişi, sonraki bütün kayıtların özetlerini de yeniden hesaplamak zorunda kalır. Özet gizli bir anahtarla hesaplanırsa (HMAC), anahtarı bilmeyen biri geçerli bir zincir üretemez.
Sınırı da buradadır. Zinciri uygulama yazar ve doğrulamayı da çoğu zaman uygulama yapar. Anahtar kurumun içinde durur; anahtara ulaşan biri geçmişi baştan yazıp zinciri yeniden hesaplayabilir ve sonuç kendi içinde kusursuz tutarlı görünür. Denetçi de doğrulama için ya anahtarı istemek ya da ürünün kendi ekranına güvenmek zorunda kalır. İkisi de bağımsız bir doğrulama değildir.
Motorun Zorladığı Defter
SQL Server 2022 ile gelen append-only ledger tablosu korumayı uygulamadan alıp veritabanı motoruna verir. Bu tabloda motor kayıt değiştirmeyi ve silmeyi herkes için reddeder, veritabanı yöneticisi dahil. Her işlem bir bloğa bağlanır, bloklar birbirine özetle bağlanır ve her kaydı hangi veritabanı kimliğinin, ne zaman yazdığı da defterde tutulur.
Doğrulamayı da motor yapar: sys.sp_verify_database_ledger yordamı defteri verilen özetlere karşı denetler. Denetçinin bunun için bir anahtara ya da ürünün yazılımına ihtiyacı yoktur; bir SQL Server kopyası ve özetler yeter.
Dışarıdaki Tanık
Defter de veritabanının içindedir. Veritabanını eski bir yedeğe döndüren ya da baştan kuran biri, kendi içinde tutarlı yeni bir defter üretebilir. Bu yüzden defterin özeti düzenli olarak veritabanının dışına, sonradan değiştirilemeyecek bir yere yazılmalıdır: saklama kilidi olan bir nesne deposu ya da WORM paylaşımı. Veritabanı ekibinin o depoda silme yetkisi olmamalıdır.
Özet dosyası küçüktür ve kayıt içeriği taşımaz: veritabanı adı, blok numarası, özet ve son commit zamanı. İmzalanırsa, dosyanın kurumdan çıktığı da doğrulanabilir. Aynı olayın güvenlik ekibinin SIEM'ine de gitmesi, veritabanı ekibinden bağımsız ikinci bir kopya sağlar.
Doğrulama: İddiadan Kanıta
Yapının en önemli parçası, denetçinin kendi başına çalıştırabildiği bir doğrulamadır. Doğrulama üç soruya cevap vermelidir:
- Özet dosyaları gerçekten o saatte kurumdan mı çıktı? (imza ve kurumun ayrıca yayımladığı açık anahtar parmak izi)
- Yedekten geri yüklenen kopyadaki defter, o özetlerle uyuşuyor mu? (sys.sp_verify_database_ledger)
- Kayıtları kim yazdı? (defterin tuttuğu yazan kimlik; yalnız uygulamanın kendi hesapları görünmeli)
Doğrulamanın sonucu ikili bir cevap olmamalıdır. Defter doğrulaması uyuşmayan ilk bloğu, yazan kimlik sorgusu da beklenmeyen hesabı adıyla gösterir. Denetimde asıl değerli olan neyin, nerede ve kim tarafından bozulduğunu görebilmektir.
Denetçiye ne söylemeli?
"Kayıtlarımız SQL Server ledger tablosunda duruyor, defter özeti saatte bir imzalanıp kilitli depoya yazılıyor. Yedeği test sunucumuza geri yükleyelim; özetleri depodan siz çekin ve sp_verify_database_ledger'ı kendiniz çalıştırın." Bu cümle, "loglarımız değiştirilemez" cümlesinden çok daha ikna edicidir çünkü kurumun söylediğine güvenmeden test edilebilir.
Dürüstçe Kabul Edilmesi Gereken Sınırlar
Güven sınırı uygulama kimliğidir. Defter, kaydın yazıldıktan sonra değişmediğini gösterir; yazılanın doğru olduğunu göstermez. Uygulama hesabının parolasına sahip biri, yazma yolunu kullanarak tutarlı görünen bir kayıt ekleyebilir. Buna karşı kontrol, uygulama hesaplarının sırlarının korunması ve hedef veritabanındaki bağımsız izleme (DAM ya da SQL Server Audit) kayıtlarının eşleştirilmesidir.
Dış deponun kilidi kurumun sorumluluğudur. Özet dosyalarının silinmemesi, deponun saklama kilidine dayanır. Bu kilidi uygulama sağlayamaz; depo seçimi ve yetkileri kurulumun parçası olarak yazılmalıdır.
Kayıt olmayan işlem korunamaz. En güçlü defter bile yazılmamış bir kaydı koruyamaz. Kapsam dışı bırakılan bir ekran ya da ürünü atlayan doğrudan bir müdahale defterin dışında kalır. Bu yüzden hangi işlemlerin kayıt ürettiği listesi, kriptografiden daha çok tartışılmalıdır.
Sık Sorulan Sorular
Değiştirilemez ile değişiklik belli arasındaki fark nedir?
Değiştirilemez, kaydın hiçbir koşulda değiştirilemediğini iddia eder; sunucuya tam yetkiyle erişen birine karşı bu iddia genellikle savunulamaz. Değişiklik belli ise daha dürüst bir hedeftir: bir değişiklik yapılırsa kanıtlanabilir biçimde ortaya çıkar. Denetimde işe yarayan ikincisidir.
Veritabanı yöneticisi denetim izini silerse ne olur?
Append-only ledger tablosunda motor satır silmeyi reddeder. Yönetici veritabanını eski bir yedeğe döndürebilir ya da tabloyu düşürüp yeniden kurabilir; ama dışarı yazılmış özetler o eski hali kapsamadığı için doğrulama başarısız olur ve tablonun düşürüldüğü defter geçmişinde görünür. Silmeyi imkansız kılmaz, sessiz kalmasını engeller.
Anahtarlı hash zinciri yetmez mi?
Ucuz müdahaleleri engeller ama iki zayıflığı vardır: anahtar kurumun içinde durur ve doğrulama çoğu zaman ya o anahtarı ya da ürünün kendi ekranını gerektirir. Motorun zorladığı defter ile dışarı yazılmış özet, denetçinin anahtara ve ürüne ihtiyaç duymadan doğrulama yapabilmesini sağlar.
Doğrulamayı canlı çalıştıralım
Demo görüşmesinde defter doğrulamasını çalıştırıp sonucu birlikte okuyalım.
Demo Planlayın →