1. Başlangıç

Güvenlik Sıfırdan serisinin ikinci yazısı. Geçen hafta SQL Injection’a karşı savunma katmanlarını işledik; bu hafta verinin kendisini şifreliyoruz. Always Encrypted, Microsoft’un 2016’da SQL Server 2016 ile gelen ‘client-side encryption’ yaklaşımı. Secure Enclaves bu yaklaşımı 2019’da bir adım öteye taşıdı, şifreli kolonlar üzerinde range query, LIKE, ORDER BY çalıştırabilmeyi mümkün kıldı.

DBA olarak bilmeniz gereken kritik tema: Always Encrypted ile şifreli kolonlardaki verinin düz hâlini SQL Server engine bile göremez. Şifreleme/çözme istemci driver’da yapılır. Yani DBA olarak ben, hassas kolondaki SSN’i sorgulasam bile binary garbage görürüm. Bu compliance (GDPR, HIPAA, PCI DSS) dünyasında tartışılmaz bir kazanç.

Üç workshop yapacağız. Workshop 1’de klasik AE’yi (enclave’siz) kuracağız ve deterministic vs randomized encryption arasındaki farkı göreceğiz. Workshop 2’de VBS enclave kuracak, in-place encryption ile mevcut şifresiz veriyi tabloyu boşaltmadan şifreleyeceğiz. Workshop 3’te enclave-enabled CMK/CEK ile şifreli kolonda LIKE ve range query çalıştırıp execution plan’ında server-side enclave computation’ı izleyeceğiz.

Yazıdaki kod örneklerini SQL Server 2025 + SSMS 22 üzerinde çalıştırdım. Setup kısmı emek istiyor (HGS attestation veya VBS-NONE konfigürasyonu, enclave-enabled key oluşturmak), ama bir kez kurulduğunda günlük operasyon hayatınızı çok değiştirmiyor, uygulama kodunuza dokunmadan veriyi şifrelemiş oluyorsunuz.

2. Always Encrypted Nedir, Hangi Sorunu Çözer?

Klasik veri şifreleme yaklaşımları (TDE, Cell-Level Encryption) verinin diskte şifreli olmasını sağlar, yani çalınan disk yedeğinden bilgi okunamaz. Ama engine bellekte düz veriyi tutar; root yetkisi olan biri (sysadmin DBA, sunucu yöneticisi, malware) bellek dökümünden veriyi okuyabilir.

Always Encrypted bu boşluğu kapatır. Veri client driver’da şifrelenir (sürücü Windows Certificate Store veya Azure Key Vault’taki anahtara erişir), şifreli olarak server’a gelir, server şifreli olarak diske yazar, sorgu sonuçlarını şifreli döner, client tarafında çözülür. Server hiçbir aşamada düz veriyi görmez.

Always Encrypted veri akışı. Şifreleme client driver’da, server yalnızca şifreli payload görür.

Bu mimarinin getirdiği kısıt: server düz veriyi görmediği için şifreli kolonlar üzerinde standart SQL operasyonları (LIKE, BETWEEN, ORDER BY, JOIN) kısıtlı. Deterministic encryption ile equality search yapılabiliyor (aynı plaintext aynı ciphertext üretir), ama LIKE veya range mümkün değildi — ta ki Secure Enclaves gelene kadar.

3. Encryption Tipleri Deterministic vs Randomized

İki şifreleme tipi var:

• Deterministic: Aynı plaintext her zaman aynı ciphertext üretir. Equality search (=, IN), JOIN, GROUP BY mümkün. Trade-off: ciphertext’ten plaintext’e patern analizi yapan saldırgan için daha az güvenli. Düşük cardinality kolonlarda (cinsiyet, ülke kodu) frequency analysis ile pattern çıkarılabilir.
• Randomized: Aynı plaintext farklı ciphertext üretir (her şifrelemede yeni IV). En güvenli yaklaşım. Trade-off: equality search bile mümkün değil (enclave olmadan); kolonu sadece read/write için tutabilirsiniz, query içinde filter olarak kullanamıyorsunuz.

Pratik öneri: yüksek cardinality kolonlarda (SSN, email, customer_id) deterministic kullan, çünkü equality search’e ihtiyacın olur. Düşük cardinality kolonlarda (gender, country_code) randomized tercih et, query içinde filter olarak kullanmıyorsan.

Secure Enclaves geldikten sonra randomized kolonlar üzerinde de range, LIKE, ORDER BY mümkün hale geldi. Yani randomized’in eski ‘sadece tut, sorgulayamazsın’ kısıtı kalktı. Aşağıdaki tablo karar matrisi:

4. Anahtar Mimarisi CMK ve CEK

İki anahtar tipi var: Column Master Key (CMK) ve Column Encryption Key (CEK). CMK, client’ın güvendiği bir lokasyonda saklanan ana anahtar (Windows Cert Store, Azure Key Vault, hardware HSM). CEK, kolonu şifrelemek için kullanılan anahtar; veritabanında şifreli (CMK ile) saklanır.

İlişki şöyle: client şifrelenmiş bir veri görmek istediğinde, CMK’yı kendi tarafında çözer, sonra CMK ile DB’deki CEK’i çözer, ardından CEK ile veriyi çözer. Server hiç CMK’yı görmez, sadece CEK’in şifreli halini bilir.

Bu yaklaşımın avantajı: anahtar rotasyonu nispeten kolay. CEK’i değiştirmek kolon datasını yeniden şifrelemek demek (büyük tablolarda bakım penceresi); ama CMK rotasyonu sadece DB’deki CEK kayıtlarını yeniden şifrelemek anlamına geliyor, data tarafına dokunmadan.

5. Secure Enclaves VBS vs SGX

Secure Enclave, CPU içinde izole bir bellek bölgesi. İçindeki veriyi root yetkili biri bile (kernel debugger, hypervisor) okuyamaz. SQL Server bu enclave’i şifre çözme operasyonu için kullanıyor, yani query LIKE’ı çalıştırırken veriyi enclave içinde geçici olarak çözüyor, eşleştirme yapıyor, sonra ciphertext döndürüyor. Engine’in geri kalanı (buffer pool, log) hâlâ düz veriyi görmüyor.

İki enclave teknolojisi var:

• VBS (Virtualization-Based Security) SQL Server 2019+ on Windows. Hyper-V hypervisor’una dayanan bir izolasyon. CPU’nuzun Hyper-V’yi desteklemesi yeterli, özel chip gerekmez.
• Intel SGX, Sadece Azure SQL Database DC-series VM’lerde. CPU-level enclave instructions kullanır, en güçlü güvence ama on-prem’de mainstream destek yok.

On-prem SQL Server için pratik seçim VBS. Setup gerektiriyor: Hyper-V feature’ını yüklü tutmak, sp_configure ile ‘column encryption enclave type’ = 1 ayarlamak, instance’ı restart etmek.

6. Attestation Enclave’in Genuine Olduğunu Doğrulamak

Enclave kuruyoruz ama ‘malicious bir DBA enclave’in koduna müdahale etmiş olabilir’ problemi var. Attestation bu probleme çare. Client uygulaması, enclave’i kullanmadan önce harici bir ‘attestation service’e başvurup ‘bu enclave gerçek mi, içindeki kod Microsoft-signed Always Encrypted kütüphanesi mi’ diye doğrulatır.

Üç attestation seçeneği var:

• Host Guardian Service (HGS) On-prem VBS enclave için klasik. Ayrı bir Windows Server kuruyorsunuz, HGS rolü çalıştırıyor. SQL Server bu HGS’ye attest oluyor, client driver da SQL Server’ın attestation’ını HGS’den doğruluyor.
• Microsoft Azure Attestation (MAA) Azure SQL Database SGX enclave için. Microsoft’un yönettiği bir cloud service.
• None (No attestation) Versiyon 18.1+ ODBC ve modern .NET driver’larda mevcut. VBS enclave’i kullanırsınız ama attest etmezsiniz. Production için önerilmez ama geliştirme/test için pratik.

Production’da kullanmaktan kaçınılmaz olarak HGS gelir. Setup’ı uzun ama bir kez kurulduktan sonra bakım minimum. None mode geliştirme ortamlarında setup süresini kısaltır; production’a açmadan attestation’ı mutlaka eklemelisiniz.

7. Klasik Always Encrypted (Enclave’siz)

Önce klasik AE’yi kurup deterministic ve randomized arasındaki farkı göreceğiz. Bu setup enclave gerektirmiyor, hızlı bir başlangıç.

-- Test database
CREATE DATABASE AELab; GO
USE AELab; GO
-- Hassas veri tutan tablo
CREATE TABLE dbo.Employees
(
    EmployeeID INT IDENTITY PRIMARY KEY,
    FirstName  NVARCHAR(50),
    LastName   NVARCHAR(50),
    SSN        NVARCHAR(11),  -- sifrelenecek
    Salary     MONEY,         -- sifrelenecek
    Department NVARCHAR(50)
);
-- Test verisi
INSERT INTO dbo.Employees (FirstName, LastName, SSN, Salary, Department)
VALUES
    (N'Yavuz', N'Filizlibay', N'123-45-6789', 8500, N'IT'),
    (N'Ahmet', N'Yilmaz',     N'987-65-4321', 7200, N'Sales');

Şimdi SSMS üzerinde CMK ve CEK oluşturma sihirbazını kullanalım. Object Explorer’da AELab DB → Security → Always Encrypted Keys → New Column Master Key. Wizard adım adım:

• Key name: CMK1
• Key store provider: Windows Certificate Store – Current User (test için)
• Generate Certificate (yeni cert üret)

• Allow enclave computations: şimdilik UNCHECKED (Workshop 2’de açacağız)
• Sonra Column Encryption Key: New CEK with name CEK1, master key CMK1.

Columnn Encryption Keys den CEK ekliyoruz

Ardından kolonları şifreliyoruz. SSMS’in ‘Encrypt Columns’ wizard’ı (Tasks → Encrypt Columns) dokümana akıştır:

• SSN: Deterministic Encryption, CEK1
• Salary: Randomized Encryption, CEK1
• Diğer kolonlar: No encryption

Seçim ekranı geliyor bundan sonra

Wizard, encrypted bir kopya tablo oluşturuyor, mevcut veriyi şifreliyor, atomic switch yapıyor. Tablonuz aynı isimle ama içeriği şifreli. Şimdi T-SQL’den veriye bakın:

-- AE etkin OLMAYAN baglantida
SELECT EmployeeID, FirstName, SSN, Salary FROM dbo.Employees;
-- Sonuc: SSN ve Salary VARBINARY garbage gorur
-- AE etkin baglantida (SSMS'in connection options'inda 'Enable
-- Always Encrypted' kutusu isaretli)
SELECT EmployeeID, FirstName, SSN, Salary FROM dbo.Employees;
-- Sonuc: gercek degerleri gorur — driver client tarafinda cozuyor

Şifreleme nereden açılıyor kapanıyor bakalım

Sorgu ya bakalım

Always Encrypted false yapıp deneyelim sorguyu

Equality search test edelim:

-- AE-enabled connection + Parameterization for AE = ON
DECLARE @ssn NVARCHAR(11) = N'123-45-6789';
SELECT * FROM dbo.Employees WHERE SSN = @ssn;
-- Calisir — SSN deterministic oldugu icin equality search mumkun
DECLARE @sal MONEY = 8500;
SELECT * FROM dbo.Employees WHERE Salary = @sal;
-- HATA — Salary randomized, equality bile mumkun degil (enclave yok)
-- LIKE ve range tum kolonlarda CALISMIYOR (enclave yok)
SELECT * FROM dbo.Employees WHERE SSN LIKE N'123%';
-- HATA

8. Secure Enclave Kurmak ve In-Place Encryption

Şimdi VBS enclave’i devreye alalım. SQL Server’a:

-- Enclave type = VBS
EXEC sys.sp_configure 'column encryption enclave type', 1;
RECONFIGURE;
-- Restart SQL Server!
-- Restart sonrasi dogrula
SELECT [name], [value], [value_in_use]
FROM sys.configurations
WHERE [name] = 'column encryption enclave type';

Şimdi enclave-enabled CMK ve CEK oluşturalım. Object Explorer → New Column Master Key sihirbazında bu sefer ‘Allow enclave computations’ KUTUSU İŞARETLİ olarak. Test için ‘No attestation’ veya ‘Host Guardian Service’ seçin (HGS varsa).

Yeni CEK’i oluştururken bu enclave-enabled CMK’yı kullanın. Sonra mevcut kolonları enclave-enabled CEK’e re-encrypt etmek gerekiyor:

-- ALTER COLUMN ile in-place re-encryption
-- Bu komut enclave-enabled connection'da calisir
ALTER TABLE dbo.Employees
    ALTER COLUMN SSN NVARCHAR(11)
    ENCRYPTED WITH (
        COLUMN_ENCRYPTION_KEY = CEK_Enclave,
        ENCRYPTION_TYPE = Randomized,
        ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
    ) NULL;
ALTER TABLE dbo.Employees
    ALTER COLUMN Salary MONEY
    ENCRYPTED WITH (
        COLUMN_ENCRYPTION_KEY = CEK_Enclave,
        ENCRYPTION_TYPE = Randomized,
        ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
    ) NULL;
-- ALTER plan cache'i temizle
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

Bu ALTER, eski yaklaşıma göre çok daha yumuşak — eskiden yeni tabloyu kuruyor, veriyi taşıyor, switch yapıyorduk. Enclave’li ALTER aynı kolonun üstünde in-place re-encryption yapıyor, downtime yok (büyük tablolarda da wizard içinden online progress takip edilebilir).

9. Rich Queries: LIKE, Range, ORDER BY

Enclave aktif ve kolonlar enclave-enabled CEK ile şifreli. Şimdi rich query’leri deneyelim. SSMS connection options’da ‘Enable Always Encrypted’ + ‘Enable secure enclaves’ + ‘Protocol: Host Guardian Service’ (veya ‘None’) + attestation URL ayarlanmış olmalı.

-- LIKE — eskiden imkansiz, simdi mumkun
DECLARE @prefix NVARCHAR(11) = N'123%';
SELECT FirstName, LastName, SSN
FROM dbo.Employees
WHERE SSN LIKE @prefix;
-- Range — eskiden imkansiz, simdi mumkun
DECLARE @minSal MONEY = 7000, @maxSal MONEY = 9000;
SELECT FirstName, LastName, Salary
FROM dbo.Employees
WHERE Salary BETWEEN @minSal AND @maxSal;
-- ORDER BY
SELECT FirstName, LastName, Salary
FROM dbo.Employees
ORDER BY Salary DESC;

Engine bu sorguları işlerken enclave’i kullanıyor. Plan’a baktığımızda Properties pane’inde ‘Enclave Computation Used’ = True bilgisini görebilirsiniz. Yani şifre çözme operasyonu enclave içinde, geri kalan engine düz veriyi hiç görmüyor.

Performans tarafına gelince: enclave operasyonlarının kendi maliyeti var. Enclave’siz equality search çok hızlıyken, enclave’li LIKE veya range predicate üzerinden çalışan binlerce satır CPU yiyor. Test ortamımda 100K satırlık tabloda LIKE ‘123%’ sorgusu klasik (şifresiz) kolon için 8 ms, enclave-enabled için 380 ms. 50x fark, ama yine de production’da kabul edilebilir bir aralık eğer veri hassassa.

10. Prod’a Almadan Yapılacaklar

Always Encrypted’ı production’a almadan önce şu listeyi geçin:

• CMK’yı Azure Key Vault veya HSM’de tutun, Windows Certificate Store sadece test için.
• Anahtar rotasyon planı: CEK her yıl, CMK her 2-3 yılda bir. Otomatik script’le rotation kuracaksanız wizard adımlarını PowerShell ile karşılığını yazın (Set-SqlColumnEncryptionKey, etc.).
• Application driver versiyonu kritik .NET için Microsoft.Data.SqlClient 5+, ODBC 18+, JDBC 12+. Eski driver enclave’siz mode’da çalışır.
• Connection string’de Column Encryption Setting=Enabled ve Enclave Attestation URL parametreleri zorunlu (production).
• İndeks tasarımı dikkat: Randomized kolonlar üzerine standart NCI kurulamıyor (engine düzeni göremıyor); enclave-enabled deterministic ile kolon üzerinde NCI mümkün.
• Backup tarafı: AE şifreli kolonlar zaten şifreli yedeklenir, ek bir TDE’ye gerek yok diyebilir misin? TDE hâlâ önerilir, defense in depth.
• Monitoring: SQL Server enclave health bilgisini extended event ‘always_encrypted_enclave_*’ eventleriyle yayınlıyor; izleyin.
• DBA hesabı CMK’yı görmediği için break-glass scenarios düşünülmeli anahtar kaybı = veri kaybı. Anahtar yönetim kontrolünü dökümante edin.

11. Sınırlar – Kısıtlar

• Bazı veri tipleri AE ile uyumsuz: text, ntext, image, hierarchyid, geography, geometry, xml, sql_variant, timestamp, rowversion.
• Identity kolonları, sparse columns, computed columns AE ile şifrelenemez.
• Triggers ve constraints kısıtlı, şifreli kolon üzerinde kontrol yapamaz.
• Replication / CDC / Change Tracking şifreli kolonlarla çalışırken sınırlar var; pre-deployment test gerekir.
• Linked server üzerinden AE şifreli kolonlara JOIN/SELECT kısıtlı.
• Bulk insert için BCP/SSIS özel parametreler bekliyor (encryption=CipherOnly veya CipherText).
• Eski clients (.NET Framework 4.7 öncesi, eski JDBC) enclave-enabled CMK ile çalışamaz.
• Performance: enclave operasyonlari CPU yiyor; planlamadan önce test yapın.

12. Bölüm Sonu

Always Encrypted with Secure Enclaves, hassas veri saklayan organizasyonların compliance’ı için en güçlü araçlardan biri. DBA olarak veriyi düz göremıyorum demek, regulâtör tarafında ‘separation of duties’ kanıtı anlamına geliyor, banking, healthcare, public sector için altın madeni.

Setup tarafı emek istiyor: enclave kurulumu, attestation infrastructure, key management, driver version’ları, connection string’ler. Ama bir kez kurulduktan sonra günlük operasyona neredeyse hiç yansımıyor; uygulama kodu değişmiyor, sorgu syntax’ı aynı.

Workshop 3’teki LIKE ve range query özellikle önemli, eski klasik AE’nin büyük kısıtıydı bu. Secure Enclaves bu kısıtı çözünce randomized encryption’ı yaygın olarak kullanmamızın önü açıldı; en güçlü güvence modu artık daily SQL workload’da kullanılabilir.

Sonraki yazıda Güvenlik Sıfırdan serisinin son parçası SQL Server Audit + Ledger’a geçeceğiz. Compliance için izleme ve tamper-evident veri saklama, Always Encrypted’ın yanına oturan ikinci compliance sütunu.

AE deneyimlerinizi yorumlara yazın. Özellikle production’da CMK rotasyonu, key vault entegrasyonu, performans gözlemleri, bu deneyimler diğer okurlara altın değerinde.