Bu makalede Always Encrypted özelliğine değişmiş olacağız. Bazen hassas olan verilerimizin görünmesini istemeyebiliriz.
Always Encrypted, SQL Server’da hassas verileri şifrelemek için geliştirilmiş bir güvenlik özelliğidir. Temel mantığı, verilerin istemci tarafında şifrelenip sunucuya gönderilmesi ve sunucu tarafında hiçbir zaman şifresinin çözülememesidir. Veri, uygulama/driver seviyesinde şifrelenir. SQL Server’a zaten şifrelenmiş halde gelir. Sunucu şifrelenmiş veriyi depolar ama çözemez.
Always Encrypted özelliğini aktif etmek için aşağıdaki adımları sırasıyla izleyerek sağlayabiliriz.
Encrypted özelliğini kullanmamız için tablo altında bulunan security bölümünden bu özellik açılabilir.
Column Master Keys bölümüne sağ tıklayıp New Column Master Key.. diyiyoruz.
Gelen ekranda Master key ismi verdikten sonra oluşturma işlemine geçiyoruz.
1. “Windows Certificate Store – Current User” Ne Demek?
Bu seçenek, Column Master Key (CMK) dediğimiz ana anahtarın, SQL Server’ın yüklü olduğu sunucuda değil, sorguyu çalıştıran kişinin (senin) kullandığı bilgisayarın sertifika deposunda tutulacağını belirtir.
- Anahtar Nerede? Senin kullandığın bilgisayarın (Windows) içinde.
- SQL Server Ne Biliyor? SQL Server sadece bu anahtarın ismini ve nerede olması gerektiğini (yolunu) bilir, anahtarın kendisi (private key) SQL Server’a asla gönderilmez.
2. Şifreleme Anahtarı SQL Server Üzerinde mi?
Hayır. Always Encrypted’ın temel kuralı şudur: Anahtar asla veritabanı motorunun (SQL Engine) erişebileceği bir yerde olmaz.
- Eğer anahtarı SQL Server sunucusundaki bir klasöre koysaydın, sysadmin yetkisine sahip birisi o anahtarı çalıp veriyi çözebilirdi.
- Bu resimdeki ayar ile anahtar senin yerel bilgisayarında olduğu için, SQL Server sadece “şifreli veri yığınını” tutar. Şifre çözme işlemi senin bilgisayarındaki SSMS (istemci) sürücüsü tarafından yapılır.
3. Diğer Seçenekler Neler? (Key Store)
Açılır menüye (Dropdown) tıkladığında genellikle şu seçenekleri görürsün:
- Windows Certificate Store: Anahtarı Windows sertifikaları arasına koyar.
- Azure Key Vault: Anahtarı bulutta güvenli bir kasada tutar. En güvenli yöntemlerden biridir çünkü erişim loglarını takip edebilirsin.
- Hardware Security Module (HSM): Fiziksel bir cihaz içerisinde tutar.
4. Önemli Uyarı: “Current User” vs “Local Machine”
Resimde Current User seçili. Bu, anahtarın sadece o an Windows’ta oturum açmış olan “Yunus” kullanıcısının sertifika deposunda olduğu anlamına gelir.
Eğer sen bu anahtarı “Current User” olarak kendi bilgisayarında oluşturursan ve başka bir iş arkadaşın SSMS ile aynı veritabanına bağlanıp Column Encryption Setting = Enabled yazarsa, veriyi yine de göremez. Çünkü anahtar onun bilgisayarında veya onun kullanıcı profilinde yoktur.
Buradan yaptığın ayar, şifrenin nereye saklanacağını belirler. Eğer anahtar SQL Server üzerinde olsaydı, Always Encrypted’ın TDE’den (Transparent Data Encryption) bir farkı kalmazdı. Bu yöntemle anahtarı SQL Server’dan tamamen izole etmiş oluyorsun.
Daha sonra Column Encryption Keys bölümünden bir encryption key oluşturulur.
Gelen ekranda Name kısmında bir isim belirtilir aşağı kısımda önceden oluşturulan Column master key seçilmektedir.
Yukarıdaki işlemleri tamamladıktan sonra Herhangi bir tablo üzerinde Ecrypted işlemi yapmış olacağız.
Bu özelliği açmış olduğumuz veritabanında hangi tablo üzerinde şifreleme işlemi yapılacaksa ilgili tabloya sağ tıklayıp Encrypt Columns.. seçilir.
Gelen ekranda şifrelemek istediğimiz kolonu şeçiyoruz. Encryption Type kısmında Deterministic aynı veri her zaman aynı şifreli sonucu üretir. Daha az güvenlidir. Randomized ise aynı veri farklı şifre sonuçları üretmektedir. Daha çok güvenlidir. İlgili seçimi yaptıktan sonra Next deyip bir sonraki aşamaya geçiyoruz.
Gelen ekranda tekrardan Next işlemi yapılmaktadır.
Gelen ekranda herhangi bir değişiklik yapmadan Next diyiyoruz.
Gelen ekranda özet bölümü gördükten sonra işlemlerimi tamamlıyorum.
Şifreleme işlemi yapıldıktan sonra tablomuza select çektiğimizde şifreleme işlemi uyguladığımız kolonun nasıl değiştiğini gözlemlemiş olalım.
Tablomuza şifreleme uygulanmadan önceki hali aşağıdaki resimde görülmektedir.
Avantajları
- Sunucu tarafında şifre çözülemez
- Şifreleme/şifre çözme veritabanı dışında yapılmaktadır.
Dezavantajları ve Sınırlamalar
- Şifreleme/şifre çözme işlem yükü getirmektedir.
- Randomized şifrelemede LIKE, BETWEEN yok
- Sadece belirli veri türleri şifrelenebilir.
Bağlantı sağlayacak son kullanıcının verileri şifreli bir şekilde görmesi istemiyorsa connection string’e Column Encryption Setting= Enabled ifadesi yazması gerekmektedir.
Bir dba Always Encrypted olarak oluşturulmuş bir tabloyu aşağıdaki parametreyle okuyabiliyorsa nasıl güvenli olabilir. Eğer sen bir DBA (Veritabanı Yöneticisi) olarak o parametreyi ekleyip veriyi açık halde görebiliyorsan, bunun tek bir sebebi vardır: Şifre çözme anahtarına (Column Master Key) erişimin olması.
Always Encrypted sisteminde süreç şöyle işler:
- İstemci (SSMS): “Ben veriyi okumak istiyorum” der.
- SQL Server: “Veri bende şifreli (binary), ama anahtarın nerede olduğu bilgisi bende var (örneğin Windows Certificate Store veya Azure Key Vault)” der.
- İstemci (SSMS): Eğer o bilgisayarda oturum açan kullanıcı, anahtarın tutulduğu sertifikaya erişim yetkisine sahipse, şifreyi kendi üzerinde (client-side) çözer.
Yani veriyi çözen SQL Server değil, senin bilgisayarındaki SSMS’tir. Eğer o sertifika senin bilgisayarında yüklü olmasaydı, o parametreyi yazsan bile sadece anlamsız karakterler (0x0234…) görürdün.
Eğer bir DBA’nın veriyi görmesini kesin olarak engellemek istiyorsan, şifreleme anahtarını (Master Key) sunucudan bağımsız bir yerde (örneğin sadece uygulama sunucusunun erişebildiği bir Azure Key Vault veya donanımsal bir HSM cihazında) tutmalısın.
A1 kullanıcısının verileri şifresiz bir şekilde görmektedir.
Uygulama tarafında, Connection String’lere (Dotnet üzerinden) ”ConnStrBuilder.ColumnEncryptionSetting = SqlConnecitonColumnEncryptionSetting.Enabled ” crypto’lu kolonu normal okuyabilirler.
Veri SQL Server’dan dışarı şifreli (binary) olarak çıkar. Şifre çözme işlemi SQL Server’ın işlemcisinde değil, uygulamanın çalıştığı sunucunun (Web Server/Application Server) belleğinde gerçekleşir. SQL Server, verinin gerçek içeriğini (örneğin bir kredi kartı numarası olduğunu) asla öğrenmez.
Uygulamanın veriyi “normal” (plain text) okuyabilmesi için, koduna o parametreyi eklemesi yetmez. Aynı zamanda uygulamanın çalıştığı servis hesabının (IIS AppPool veya bir gMSA hesabı gibi), Column Master Key‘in tutulduğu yere (sertifika deposu veya Azure Key Vault) erişim yetkisi olmalıdır.
- Senaryo: Bir saldırgan veritabanına sızıp SELECT * FROM Kullanicilar çekerse, sadece anlamsız şifreli veriler görür.
- Senaryo: Aynı saldırgan uygulama sunucusuna sızarsa ama sertifikaya erişim yetkisi yoksa, kodda o ayar olsa bile hata alır ve veriyi çözemez.
Always Encrypted, özellikle bulut ortamlarında ve yüksek güvenlik gerektiren senaryolarda kritik veri koruması sağlayan güçlü bir güvenlik katmanıdır.
“Şifreleme” dendiğinde aslında önümüzde iki ana yol var. Hangisini seçeceğiniz ihtiyacınıza bağlıdır:
| Özellik | TDE (Transparent Data Encryption) | Always Encrypted |
| Amacı | Diskin/Dosyanın çalınmasına karşı koruma. | DBA (Veritabanı Yöneticisi) dahil kimsenin veriyi görememesi. |
| Uygulama | Veritabanı seviyesindedir, kod değişikliği gerekmez. | Sütun seviyesindedir, uygulama tarafında sürücü desteği gerekir. |
| Performans | Çok düşük maliyet (%3-%5 civarı). | Şifreleme istemci tarafında olduğu için işlemci yükü artabilir. |
| Görünürlük | Yönetici veriyi görebilir. | Yönetici sadece şifreli (anlamsız) karakterler görür. |
1. Sertifikayı Uygulama Sunucusuna Aktarma (Export/Import)
Sertifikayı kendi bilgisayarında oluşturdun, şimdi bunu uygulamanın (IIS veya Windows Service) çalıştığı sunucuya taşıman gerekiyor.
Adımlar:
- Kendi Makinen (Export): * certmgr.msc (Current User) konsolunu aç.
- Sertifikanı bul, sağ tıkla -> All Tasks -> Export.
- ÖNEMLİ: “Yes, export the private key” seçeneğini seçmelisin. Şifre çözme işlemi için “Private Key” şarttır.
- .pfx uzantılı bir dosya oluşturup bir şifre belirle.
- Uygulama Sunucusu (Import):
- .pfx dosyasını sunucuya kopyala.
- Sağ tıkla -> Install PFX.
- Store Location: Genellikle “Local Machine” seçilir (Böylece sunucudaki servis hesapları erişebilir).
- İçeri aktarırken “Mark this key as exportable” seçeneğini güvenlik gereği kapatabilirsin.
2. Uygulama Hangi Kullanıcıyla Sertifikayı Kullanacağını Nasıl Anlar?
İşte burası en çok kafa karıştıran kısım. Uygulama tarafındaki o tek satırlık kod (ColumnEncryptionSetting = Enabled), sihirli bir şekilde sertifikayı “bulmaz”. Süreç şu şekilde işler:
A. Metadata Eşleşmesi
Uygulama SQL’e bağlandığında, SQL Server ona şunu der: “Bak, bu kolon şifreli ve bunu çözmek için şu ‘Thumbprint’ (parmak izi) değerine sahip bir sertifikaya ihtiyacın var.”
B. Sertifika Mağazası Kontrolü (Store Location)
Uygulama (ADO.NET sürücüsü), sunucudaki sertifika deposuna (Certificate Store) bakar. “Bu Thumbprint’e sahip bir sertifika bende var mı?” diye sorar.
C. Yetki Tanımlama (Kritik Adım)
Sertifikayı sunucuya yüklemek yetmez. Uygulamanın çalıştığı kullanıcı hesabına o sertifikanın “Private Key”ini okuma yetkisi vermen gerekir.
Nasıl Yapılır:
- Sunucuda certlm.msc (Local Machine) aç.
- Sertifikaya sağ tıkla -> All Tasks -> Manage Private Keys.
- Buraya uygulamanın çalıştığı hesabı ekle (Örn: IIS AppPool\UygulamaAdi veya Domain\SQLServiceAccount).
- Sadece Read yetkisi verilmesi gerekir..
Bu makalede Always Encrypted özelliğini görmüş olduk. Başka makalede görüşmek dileğiyle..
İyilik edin. Şüphesiz Allah, iyilik edenleri sever. Bakara Suresi-195
