Pip: Yavuz Filizlibay bu hafta SQL Server’ın içine giriyor ve soruyor: ya veritabanı yöneticisinin kendisi de veriyi göremeseydi?
Mara: Tam olarak. Bu bölümde Always Encrypted konusunu işliyoruz; şifreleme mimarisinden enclave kurulumuna, sorgu kısıtlarından production geçiş listesine kadar. Veri güvenliğinin motor katmanında ne anlama geldiğini ele alıyoruz. Şifrelemenin nasıl çalıştığından başlayalım.
Always Encrypted: Güvenli Veri Şifreleme Yöntemleri
Mara: Klasik şifreleme yaklaşımları, TDE ve hücre düzeyinde şifreleme, veriyi diskte korur. Ama SQL Server motoru bellekte düz veriyi tutar; yeterli yetkiye sahip biri bellek dökümünden veriyi okuyabilir. Always Encrypted bu boşluğu kapatmak için tasarlandı ve mimari olarak farklı bir yerde duruyor.
Pip: Yazı bu farkı net bir cümleyle koyuyor ortaya: “DBA olarak ben, hassas kolondaki SSN’i sorgulasam bile binary garbage görürüm.”
Mara: Bu cümle mimarinin özü. Şifreleme ve çözme işlemi istemci sürücüsünde gerçekleşiyor; sunucu hiçbir aşamada düz veriyi görmüyor. GDPR, HIPAA, PCI DSS gibi uyumluluk çerçeveleri için bu, görev ayrımının teknik kanıtı anlamına geliyor.
Pip: Yani DBA yetkisi artık “her şeyi görebilirsin” garantisi değil. Denetçi için altın değerinde, DBA için biraz egzistansiyel bir an.
Mara: Yazı iki şifreleme tipini karşılaştırıyor. Deterministik şifrelemede aynı düz metin her zaman aynı şifreli metni üretiyor; eşitlik araması, JOIN ve GROUP BY mümkün. Rastgele şifrelemede ise her seferinde farklı şifreli metin üretiliyor, en güvenli yaklaşım bu, ama enclave olmadan eşitlik araması bile yapılamıyor.
Pip: Pratik öneri yüksek kardinaliteli kolonlarda, SSN ve e-posta gibi, deterministik; düşük kardinaliteli kolonlarda, cinsiyet veya ülke kodu gibi, rastgele. Çünkü ikinci grupta zaten filtre olarak kullanmıyorsunuz.
Mara: Secure Enclaves bu denklemi değiştiriyor. Enclave, CPU içinde izole bir bellek bölgesi; root yetkisiyle bile içindeki veriye erişilemiyor. SQL Server bu bölgeyi şifre çözme operasyonu için kullanıyor. Yazı VBS ve Intel SGX olmak üzere iki enclave teknolojisini ele alıyor; on-prem SQL Server için pratik seçim VBS.
Pip: Enclave devreye girince rastgele şifrelenmiş kolonlar üzerinde de LIKE, range sorgusu ve ORDER BY çalışıyor. Yazıda bunu doğrulayan bir performans notu var: yüz bin satırlık tabloda LIKE sorgusu şifresiz kolonda sekiz milisaniye, enclave-enabled kolonda üç yüz seksen milisaniye.
Mara: Elli kat fark, ama yazı bunu kabul edilebilir buluyor; veri hassassa bu maliyet mantıklı. Enclave kurulumu için attestation meselesine de değiniyor: istemci uygulama, enclave’in gerçekten Microsoft imzalı kütüphane çalıştırdığını harici bir servise doğrulatıyor. On-prem için Host Guardian Service, geliştirme ortamları için attestation’sız mod mevcut.
Mara: Production geçiş listesi de ayrıntılı: CMK’yı Azure Key Vault veya HSM’de tutmak, sürücü versiyonlarını güncel tutmak, bağlantı dizesinde şifreleme parametrelerini doğru ayarlamak ve anahtar rotasyon planı kurmak. Yazı şunu da hatırlatıyor: anahtar kaybı veri kaybı demek, break-glass senaryoları önceden belgelenmeli.
Pip: Kısıtlar listesi de kapsamlı; text, xml, identity kolonları, computed columns, replication ve CDC ile uyumluluk sorunları var. Kurulum emek istiyor, ama yazı günlük operasyona neredeyse hiç yansımadığını söylüyor.
Mara: Serinin bir sonraki durağı SQL Server Audit ve Ledger; uyumluluk için izleme ve kurcalamaya karşı dayanıklı veri saklama.
Pip: Yani motor katmanında şifreleme, DBA’in bile düz veriyi göremediği bir mimari. Uyumluluk dünyası için bu çok güçlü bir argüman.
Mara: Bir sonraki bölümde denetim ve Ledger tarafına geçiyoruz; şifrelemenin yanına oturan ikinci uyumluluk sütunu.